Path: utzoo!attcan!uunet!snorkelwacker!tut.cis.ohio-state.edu!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!VTVM1.BITNET!GRANGERG From: GRANGERG@VTVM1.BITNET (Greg Granger) Newsgroups: comp.lang.modula2 Subject: Re: JPI M2 V2.0 Message-ID: Date: 12 Jun 90 16:19:26 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Modula2 List Organization: The Internet Lines: 43 On Thu, 7 Jun 90 19:59:10 GMT said: >Hello! > >We are using r1.04b of JPI M2 V2.00 too. And we are not satisfied with it!! > >Have you noticed that Storage.Available returns always TRUE! Even if no >more memory is available. > >I faxed to JPI in UK, but they didn't answered til today. > >Greetings > Stephan Schwab > > >-- >uucp: uunet!m2xenix!puddle!2!241!2.1221!Stephan.Schwab >Internet: Stephan.Schwab@p1221.f2.n241.z2.fidonet.org I too have noticed that the Storage module is buggy, fortunately (or perhaps unfortunately) I don't have to depend on the compiler for production work. Note also that in the large(r) code models that the HeapAllocate (FarHeapAllocate), allocates memory in paragraphs (real useful for elements that are multiples of 16, stupid for everything else), further when I tried to correct this I got link errors out the wazoo (course I didn't spend a lot of time trying to figure it out). I like JPI TopSpeed C (whoops, I mean Modula-2 :-) , but the version 2.0 r 1.04, could use have used a few more minutes in the oven. All in all it's considerably better than a great deal of the PC software out there (which is still no excused for such bugs). I plan to write them with my compliants and then happily order the upgrade when it becomes available. ----- Someone mentioned that they felt that TopSpeed C was a bad idea and I have to agree. I'm sure it made them (JPI) a lot of $$, but after looking at M2 manuals that reference C (when they such say Modula-2) and working with _var-name variables, you begin to think that JPI considers M2 a bastard child. Stony Brook begins to look better and better ;-) Greg