uucp@ucdavis.ucdavis.edu (uucp) (02/20/88)
Reply To: jedeline@deneb.ucdavis.edu.UUCP (Jim Deline) Distribution: usa Organization: University of California, Davis Keywords: LightSpeed Pascal, SigmaEdit, Not enough memory. From: g099508030ea@deneb.ucdavis.edu (0040;0000007630;0;190;142;) Path: deneb.ucdavis.edu!g099508030ea I have discovered a problem while using LightSpeed Pascal, I hope someone can shed some light on it. I have an open project and have just finished building and linking it. Total project sized is < 30000 bytes. I try to "Go" to the compiled application and I get an error that says something to the effect that "Not enough memory to run...Perhaps you have an open desk accessory..." Like I said, the project is small, and also I tried closing all open text windows (by choosing close from menu, not clicking the close box). By the way, no desk accessories are open when this occurs. HOWEVER...I notice that the problem seems to occur after I use SigmaEdit to edit a source file (sorry Think, but the LSP editor is too slow). I close SigmaEdit, compile, try to run, and get the error message. Any ideas, Rich? I notice you field most of the THINK questions. I am running the "Updated" version 1.11 of LSP. Thanks for any help, in advance. ---Jim Deline---
rcb@rti.UUCP (Random) (02/22/88)
I have also seen this problem. I can reproduce it every time. I am in a
project with open files going through modify/build/go loops with no
problem. At some point, I open a desk accessory (like DiskTop) and
then close it. The next Go gives me the message not enough memory.
If I exit LSP and come back in again, the problem is gone.
--
Randy Buckland (919)-541-7103
Research Triangle Institute
rcb@rti.rti.org [128.109.139.2]
{decvax,ihnp4}!mcnc!rti!rcbdrew@wolf.UUCP (Drew Dean) (02/23/88)
The LS Pascal "not enough memory bug..." occurs with some other DA's too.
(Although I've also found it in SigmaEdit....)
Of course, quitting LS Pascal (or even Transfering to LS Pascal) solves the
problem, as all DA's are automatically closed upon application termination.
Again I'm using LSP 1.11 (updated), System 4.2/Finder 6.0 (WHEN WILL LSP SUPPORT
MultiFinder ???).
Can Think fix this bug in LSP 2.0 ? Please, guys :-)))...
Drew Dean
UUCP: {sdcsvax,ihnp4}!jack!wolf!drew
FROM Disclaimers IMPORT StdDisclaimer;Doug_Strauss@castle (Doug Strauss) (02/23/88)
Well, I rember that type of error from one of my CS assignments, I think
it invloved pointers, but it was over a year ago, I'll put it in the back
of my mind and try to rember exactly what it was, but my mind is silghtly
fried from studying though. I might have also occured from opening many
files, The only thing I can think of right now is make sure you do house
cleaning and return unused memory back to the system. And I agree LSP
is very slow, Turbo is nice and fast though.
Later Dug, :-)
---
* Origin: The Corntown Connection: 152/203 (503)753-7250 (Opus 1:152/203)
SEEN-BY: 152/200 201 203
--
---------------------
Gatewayed from FidoNet to Usenet by castle.IFNA.ORG.
FidoNet: 152/201 The Castle (503) 757-8841
UUCP: {tektronix,hp-pcd}!orstcs!castle!user_name
Internet: user_name%castle.IFNA.ORG@CS.ORST.EDU
(user_name is the first and last name of originator)rs4u+@andrew.cmu.edu (Richard Siegel) (02/23/88)
Lightspeed Pascal is sensitive to heap blockages; one cause of heap blockage is a Desk Accessory that leaves garbag behind after it's closed. From what you describe,DiskTop does this. The Control Panel under System 4.1 did it as well. I suspect that the message isn't "not enough memory" but a message that something's blocking memory. --Rich
leonardr@uxe.cso.uiuc.edu (02/23/88)
uucp@ucdavis.ucdavis.edu(Jim Deline) writes in comp.sys.mac >I have discovered a problem while using LightSpeed Pascal, I hope >someone can shed some light on it. > >I have an open project and have just finished building and linking >it. Total project sized is < 30000 bytes. I try to "Go" to the >compiled application and I get an error that says something to the >effect that "Not enough memory to run...Perhaps you have an open >desk accessory..." > >Like I said, the project is small, and also I tried closing all open >text windows (by choosing close from menu, not clicking the close >box). By the way, no desk accessories are open when this occurs. > >HOWEVER...I notice that the problem seems to occur after I use >SigmaEdit to edit a source file (sorry Think, but the LSP editor is >too slow). I close SigmaEdit, compile, try to run, and get the >error message. > >Any ideas, Rich? I notice you field most of the THINK questions. >I am running the "Updated" version 1.11 of LSP. > The problem is a known (and since corrected) bug with SigmaEdit which would leave some handles hanging around in memory after it deserted the scene. LSP on the other hand requires that it have ALL of memory and that you can not have ANYTHING else there or it refuses to compile. So I will take some blame for leaving my "dirty laundry" hanging around, but I also think that LSP is TOOO sensitive to these type of things!! +---------------------------------+-----------------------------------+ + + Any thing I say may be taken as + + Leonard Rosenthol + fact, then again you might decide+ + President, LazerWare, inc. + that it really isn't, so you + + + never know, do you?? + + leonardr@uxe.cso.uiuc.edu + + + GEnie: MACgician + + + Delphi: MACgician + + + + + +---------------------------------+-----------------------------------+
rs4u+@andrew.cmu.edu (Richard Siegel) (02/25/88)
Recently there's been discussion of why Lightspeed Pascal "gives an out of
memory message" after using SigmaEdit.
As I've said before, and will say again, the bug is not a shortage of free
memory; the message is:
"Can't run your program due to a memory blockage (perhaps an open Desk
Accessory?)"
This is quite different from being out of memory.
The reason that Lightspeed Pascal is sensitive to this is that when you
execute a program it needs to create a block large enough to hold your
program's stack and heap (the sizes set in "Run Options"), plus some swap
space. So the first thing it does is a heap compaction to get the block big
enough. If some unfriendly desk accessory has left some things locked down, or
has gone away without releasing ALL of its storage, there's going to be heap
fragmentation such that Lightspeed Pascal gives this message.
If you get this message and you don't have any open DA's, a likely cause is
that you have use a DA or an FKEY or CDEV or some other bit of code that is
guilty of sloppy memory management. and leaves locked blocks behind.
>Can Think fix this bug in LSP 2.0 ? Please, guys :-)))...
It's not a Lightspeed Pascal bug. It's a bug in SigmaEdit (in this particular
instance) and in other auxillary stuff that leaves garbage behind (in general
instances). The Control Panel in System 4.1 was another offender; it would
load and lock the cross-shaped cursor and leave it locked; this cause exactly
the same symptoms.
It is worth noting that these offending DA's will cause problems in other
applications' memory management too. It's not just Lightspeed Pascal; however,
Lightspeed Pascal is more sensitive to heap constipation than most
applications, because of the unique nature of its heap demands.
Remember, Desk Accessories are supposed to "take only pictures, leave only
footprints". Applications have priority here. In short, if an application
misbehaves after a certain DA has been used, it's because the DA has done
something to the environment and is therefore the DA's fault, not the
applications.
Lightspeed Pascal will support MultiFinder, probably in the next release.
--Rich
===================================================================
Richard Siegel
THINK Technologies, QA Technician (on leave)
I'm not physically at THINK, so my information may be out
of date. Be forewarned.
Arpa: rich.siegel@andrew.cmu.edu
UUCP: {decvax,ucbvax,sun}!andrew.cmu.edu!rich.siegel
==================================================================omh@nancy (Owen M. Hartnett) (02/28/88)
In article <1199@ucdavis.ucdavis.edu> uucp@ucdavis.ucdavis.edu (uucp) writes: >I have discovered a problem while using LightSpeed Pascal, I hope >someone can shed some light on it. > >I have an open project and have just finished building and linking >it. Total project sized is < 30000 bytes. I try to "Go" to the >compiled application and I get an error that says something to the >effect that "Not enough memory to run...Perhaps you have an open >desk accessory..." > >Like I said, the project is small, and also I tried closing all open >text windows (by choosing close from menu, not clicking the close >box). By the way, no desk accessories are open when this occurs. >HOWEVER...I notice that the problem seems to occur after I use >SigmaEdit to edit a source file (sorry Think, but the LSP editor is >too slow). I close SigmaEdit, compile, try to run, and get the >error message. This is not just a problem with SigmaEdit, but with any desk accessory which allocates any appreciable space (Even some DAs which use only a little memory will cause it if called often enough from the environment). As a matter of fact, once you get this message there's no way out except returning to the finder. I talked to one of the original authors about it at a BCS Techgroup meeting last year. He indicated that he would look at it seriously for the next release (whenever that may be). (I heard a rumor, however, that he is no longer with Think.) Anyway, you can reduce the number of times that you'll encounter it by watching your memory allocations (in the Run Options menu). One hint I got from the original author was not to set the stack size above 31K. (There's really no reason that you should, that's a lot of stack.) It seems there was a bug which appeared at stack size 32K or greater. I don't know if it's been fixed in the newest release. I run with a heap size of 200K for a fairly medium size program and most desk accessories run OK. But if you open up a text editor DA with it's ensuing memory (like a big TE record), you're bound to hit this wall. I don't know if it's the DA that isn't cleaning up after itself, or that LSP can't detect the clean-up. Certain DA Certain DAs will cause this error every time they're run. I ran out of memory on a Mac II with 2MB Ram trying to run ResPeek. Also, the MacMan Da that was posted a while back allocates a lot of non-relocatable blocks which of course cause LSP to run out of room very quickly. -Owen Owen Hartnett Brown University Computer Science omh@cs.brown.edu.CSNET omh%cs.brown.edu {ihnp4,allegra}!brunix!omh "Don't wait up for me tonight because I won't be home for a month." -W.C. Fields
paul@tasis.utas.oz (Paul Stevenson) (03/02/88)
The problem was with DAs when using LSP. "Can't run because of memory blockage." In article <23207@brunix.UUCP> omh@nancy.UUCP (Owen M. Hartnett) writes: > >As a matter of fact, once you get this message there's no way out except >returning to the finder. > Actually there is another way (quicker too!) *Transfer* to LSP (saves a trip to the finder) Paul. Paul Stevenson, Computing Centre, University of Tasmania, Australia. ACSnet: paul@tasis.utas.oz.au ARPA: paul%tasis.utas.oz@uunet.uu.net UUCP: {enea,hplabs,mcvax,uunet,ukc}!munnari!tasis.utas.oz!paul SPEARNET: paul@utas.edu.au
leonardr@uxe.cso.uiuc.edu (03/02/88)
omh@nancy(Owen Hartness) writes in comp.sys.mac >In article <1199@ucdavis.ucdavis.edu> uucp@ucdavis.ucdavis.edu (uucp) writes: >>I have discovered a problem while using LightSpeed Pascal, I hope >>someone can shed some light on it. >> >>[description of problem follows ... includes mentioning SigmaEdit as culprit] > >This is not just a problem with SigmaEdit, but with any desk accessory >which allocates any appreciable space (Even some DAs which use only a little >memory will cause it if called often enough from the environment). > >As a matter of fact, once you get this message there's no way out except >returning to the finder. > After having spent the last couple of days (and nights) working with Rich Siegel (from Think) to solve the problem and to figure out the reason. Let me see what I can do to clear up the problem and offer a solution. When a DA is opened, one of the things that happens is that it is allocated storage by the system itself as well as then being able to allocate add'l storage for other things by itself. Well SigmaEdit does a pretty good job of cleaning up after itself, but I realized that I WAS NOT cleaning up after the system (an oversight on my part). Well now that SigmaEdit also does this clean up job, it runs just fine with Lightspeed Pascal without the memory message. I will be putting together an intermediate version (1.11, I think) for distribution which has this fix in it, as well as a few new features that will later be seen in the 1.2 release (I don't feel like taking them out.) I will post it to the net as soon as I get it togetther for shipping (tommorrow maybe ???) so that this is cleared up once and for all!! +---------------------------------+-----------------------------------+ + + Any thing I say may be taken as + + Leonard Rosenthol + fact, then again you might decide+ + President, LazerWare, inc. + that it really isn't, so you + + + never know, do you?? + + leonardr@uxe.cso.uiuc.edu + + + GEnie: MACgician + + + Delphi: MACgician + + + + + +---------------------------------+-----------------------------------+