mnkonar@srcsip.UUCP (Murat N. Konar) (07/08/88)
I read somwhere (MacWeek, I think) that a new version of LSP is comming out soon. Is this true? Will it also need 2Megs of RAM? Will it be less flakey than LSP 1.11 on a Mac II? Perhaps defender of the faith Rich Segal could shed some light (or at least a warm glow) on the matter. Personally, I feel that running LSP 1.11 on a Mac II is quite a test of faith! _________________________________________________________________ Any thoughts expressed above are my own; we are not paid to think. MNK
thecloud@pnet06.cts.com (Ken Mcleod) (07/09/88)
Well, the slick ads for Lightspeed Pascal 2.0 are out. Here is a rundown
of new features:
o New multi-pass optimizing compiler for smaller, faster code
o 44,000 lines/minute on a MacII
o Object Pascal support
o Enhanced source level debugger
o Relaxed size limitations, allowing 'virtually unlimited' program size
o Configurable automatic formatting in editor (yeah!!!!!)
o Source file compatibility with MPW
o Converter for MPW .o files
o 68881 and 68020 support
BUT...nothing is said about MultiFinder compatibility! hmmmmm......
Rich, please give us details. What will this upgrade cost me as a
registered owner of LSP 1.11? When will it be available? How do I
go about getting it?
Ken McLeod ========================= ....... ======================
UUCP: {crash uunet}!pnet06!thecloud :. .: Chief Weapons of UNIX:
ARPA: crash!pnet06!thecloud@nosc.mil :::.. ..::: "Fear, surprise, and
INET: thecloud@pnet06.cts.com //// ruthless efficiency."singer@endor.harvard.edu (Rich Siegel) (07/14/88)
In article <5832@altaira.srcsip.UUCP> mnkonar@ely.UUCP (Murat N. Konar) writes: >I read somwhere (MacWeek, I think) that a new version of LSP is comming out Never believe anything the press tells you. :-) >soon. Is this true? Will it also need 2Megs of RAM? Will it be less >flakey than LSP 1.11 on a Mac II? Perhaps defender of the faith Rich Segal >could shed some light (or at least a warm glow) on the matter. Personally, >I feel that running LSP 1.11 on a Mac II is quite a test of faith! Defender of the faith Rich Segal won't say anything, but defender of the faith Rich Siegel says: "Yes, there's a new release coming soon. My best guess is that it'll need two MB only if you're planning to run under MultiFinder; otherwise, the minimum configuration is 1 MB, two 800K floppies, hard disk strongly recommended." Rich
schoaff@marduk.cs.cornell.edu (Peter Schoaff) (07/15/88)
>In article <5832@altaira.srcsip.UUCP> mnkonar@ely.UUCP (Murat N. Konar) writes: >>I read somwhere (MacWeek, I think) that a new version of LSP is comming out >>soon. Is this true? Will it also need 2Megs of RAM? Will it be less >>flakey than LSP 1.11 on a Mac II? Perhaps defender of the faith Rich Segal >>could shed some light (or at least a warm glow) on the matter. Personally, >>I feel that running LSP 1.11 on a Mac II is quite a test of faith! > In case you didn't see it (I don't know how many mags the ad went in) the August MacUser says: 2.0 has multi-pass optimizing compiler Object Pascal support they improved the source level debugger "Relaxed size limitations allow virtually unlimited program size." whatever that means Source file compatibility with MPW, support for MPW object files 68881 math co-processor and 68020 support. and now, for the good part Suggested retail price $125. Owners of version 1.11 or earlier please call 408/446-9994 for upgrade information. I'm calling this afternoon, so I don't know what their policy is yet. L8r dudes | P. Chris Schoaff | We are the coffee generation, we can't afford cocaine | | | We need a healthy dose to make it through the day | | schoaff@ | Don't Care about nuclear war or poverty or pain | | cs.cornell.edu | We are the coffee generation and life is just a game. |
jackiw@cs.swarthmore.edu (Nick Jackiw) (12/06/88)
I'd like to put in a few good words for Lightspeed Pascal 2.0, considering the volume of self-righteous whining that's been going on the past few weeks (but it won't write my applications FOR me...). My update arrived well before the net lead me to believe, and with little or no work I converted my projects and they work fine. A few observations: - MULTIFINDER! ALL of my development tools (Lightspeed, ResEdit, Edit/Asm, InsideMac, Word [for documentation] and the-last-built-version-of-my-app) are corresident and clustered under my Apple menu. I've been wanting this for years... - The new editor is great. Admittedly, those who were upset by the old pretty-printing won't be pleased with the new one: all of the formatting changes (and the "customizable source-code formats") are superficial. But the new cursor-key commands (which work on character, line, page, lexical, and block levels), as well as the popup menu in the title bar which lets you jump to any routine in the file, make navigation such a breeze I've all but stopped relying on hardcopy. (Printing, as far as I was concerned, was the only place the pretty-printing offended me: what a waste of paper!) - I encounter the ubiquitous "Resource not found (-192)" error frequently. I remember these from v1.0 ... the least helpful error message LSP ever produces (except for blind crashes, of course). At any rate, a frequent cause for it in my first weeks with 2.0 has been forgetting to run the library converter on my machine-language subroutine files. - Code size improvement and speed, despite net accusations to the contrary, ARE immediately tangible in commercial (i. e. no TEXT or DRAWING window) applications. One project I'm working on dropped from 180 to 170K, the other from 62 to 50 (!). Compile time is noticably faster, too. - MAJOR ANNOYANCE: Lightspeed stamps its own thumb-print on every application you build. Go into ResEdit and LO! An extra resource not in your rez-file, called--oddly enough--'LSP' (Id#2000; Size 18; locked+preload). If you zap it, you zap your application too... What's the deal with this? It seems like a completely gratuitous bit of egoism on LSP's part. The resource data is fixed (never written to), and gets loaded at the base of your globals somewhere in Code Seg 1 (or wherever your main program is...). It could just as easily be stored as constant data in the CODE seg, and referenced appropriately. Considering the licensing agreement doesn't even require the old 'portions copyright THINK technologies,' there's no reason for this sort of attitude on the part of the compiler. In situations where you want CONTROL over your application (as I assume most commercial app writers do), having LSP play with the resource manager, the heap, and so forth is unacceptable. Especially if there's no explanation other than the "oh leave that there I don't know what it does but it won't work without it" rationale. The next virus author is sure to name his or her nVIR resource as 'LSP'... Lots of other good features (conditional assembly finally offers a clean way to integrate debugging-support code; LightsBug 2 seems real nice), some bad (the new 'LINK error' window doesn't help you find what segment or source file the bad-link reference occurred in...). If LSP 3.0 offers as much of a change as 2.0, I'll keep on upgradin'. -- +-------------------++-UUCP: ...!rugers!bpa!swatsun!jackiw------------------+ | NICHOLAS JACKIW || Internet: jackiw@cs.swarthmure.edu | |("Jacques-Yves"2U!)|| Bitnet jackiw%campus.swarthmore.edu@swarthmr.bitnet | +-------------------++-VGP/MathDept/Swarthmore College, Swarthmore PA 19081-+
siegel@endor.harvard.edu (Rich Siegel) (12/06/88)
In article <2219@ilium.cs.swarthmore.edu> jackiw@cs.swarthmore.edu (Nick Jackiw) writes: > >- MAJOR ANNOYANCE: Lightspeed stamps its own thumb-print on every application >you build. Go into ResEdit and LO! An extra resource not in your rez-file, >called--oddly enough--'LSP' (Id#2000; Size 18; locked+preload). If you zap it, >you zap your application too... What's the deal with this? It seems like a >completely gratuitous bit of egoism on LSP's part. The resource data is fixed Since you don't have a clue as to what the LSP resource does, why don't you ASK, instead of assuming? As it happens, the LSP resource is for runtimeerror recovery; when a Pascal runtime error occurs (range checking, overflow, file i/o error, etc), control is passed to the LSP resource. The standard LSP resource simply does a DebugStr which reports the error. It is possible for a programmer to write a different LSP resource which reports the error in a nicer fashion. >new 'LINK error' window doesn't help you find what segment or source file the >bad-link reference occurred in...). If LSP 3.0 offers as much of a change as >2.0, I'll keep on upgradin'. For a failed link, the Link Errors window simply lists the undefined symbols. However, if you then choose "Check Link", the Link Errors window will show you the files from which the undefined symbols are referenced. --Rich Rich Siegel Staff Software Developer THINK Technologies Division, Symantec Corp. Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel Phone: (617) 275-4800 x305 Any opinions stated in this article do not necessarily reflect the views or policies of Symantec Corporation or its employees.
odawa@well.UUCP (Michael Odawa) (12/09/88)
As one who has the Lightspeed Pascal development system to build several major products over the past year, I have been a great fan of LightsBug, the LSP debugger. In my estimation it has been and remains (despite what follows) the finest source-level debugger on the Macintosh. Similarly, Think's Technical Support staff has ranked far above that of any other tool provider. With release of version 2.0 my esteem for LSP has continued to grow. New facilities have been added, and means have been found even to extend the functionality of LightsBug. However, there appears to have been a single step backward. Previous versions of LightsBug's heap display arranged blocks within each zone in physical (i.e., address) order, making memory management nearly simple. The current 2.0 version appears to have abandoned this sorting, displaying blocks in a seemingly random but definitely not numerical order, rendering LightsBug practically useless for sophisticated memory management. Given the great care with which the whole LSP package has been constructed, one would believe there must have been a good reason for sacrificing this essential feature. I wonder if anyone (Rich, are you there?) would be able to explain why it was dumped overboard.