Hello,

at the moment I write a unit to control X terminals.

There I also have a procedure to resize the window. After resizing the window I call the procedure "window" from the crt unit. It's okay when I make the window smaller, but it doesn't work correctly when I try to make it larger.

P.S.: Is there any xterm for Windows?

I use pretty good.

P.S.: Is there any xterm for Windows?

Yes. You can download several X-Window servers for Windows; Some come with native x-term. I have successfully run the one from cygwin; that one is free.

Michael.

Forgot to answer this. I think the cause is that the size of 80x25 is still hardcoded in the CRT unit; We would have to check this.

Michael.

No, but it's depending on the variables "ScreenWidth" and "ScreenHeight". These are set they can not easily be changed, because under Linux there's a buffer assigned for these sizes - and not larger.

I'm going to send you my draft of this unit. Perhaps you can find a solution.

Tschuess
Andreas

Try the nCrt unit, as it allows for different screen sizes.

Ken

Is there a port of fpc for the sun sparc yet?

g.

you wrote

Is there a port of fpc for the sun sparc yet?

No.

Ken J. Wright wrote

Try the nCrt unit, as it allows for different screen sizes.

And how?
When I use it natively, it even ignores the startup size. The normal Crt unit at least accepts that.

Ok. Is one planned by chance?

Thanks.

g.

Sorry, it really accepts resizing.
I just had an error in my testprogram.

I threw away all CRT specific stuff from my unit now and leave it to the programmer what CRT unit to use. But he then has to update the window command himself.

Not at the moment. We currently focussing on m68k (because that one's nearly done), PowerPC (because I want FPC on my Mac) and Alpha (Michael wants it on his Alpha). As you can see, whether or not a port happens depends mainly on personal interest and available time.

Jonas

Quoting Jonas Maebe :

On donderdag, augustus 23, 2001, at 07:54 , Gene Buckle wrote: PowerPC (because I want FPC on my Mac)

Yay Mac, yay Mac :-)

Will you be supporting all PowerPC models? Some of us could only afford second hand Performer 6100's ( £50, 601 processor, MacOS 8.0, 72mb RAM, 500mb hdd, 2x CDRom), and so we would love a PowerPC compiler too. I have a couple of versions of Think Pascal, including the hard to find final official release (not 4.5, 4.01 or something??) but as it's 68k, that's not really what I'm after :-(

If you need testing, please call on me.

If you'll only be supporting one of the flavours of Linux on the mac, please support the mkLinux, as nothing else runs on the 6100, with it's crappy hardware and PDS slot. I wish I had a PDS > NUBUS converter and a decent graphics card!! My apple monitor only does 640x480, and my APPLE > VGA converter will only work with my crappy main monitor that's heading for the scrap heap asap (it has issues with working.. keeps flipping into standby mode..)

Matt

It's not very difficult to support all PowerPC models, since at the instruction level there's little difference (at least for "normal" programs, for OS'es there are significant differences for some things). Only on the G4 you have the extra AltiVec stuff, but that won't be immediately supported anyway.

If you need testing, please call on me.

It'd be very nice if you could start testing the RTL support routines I've already wirtten for PowerPC (see in the PowerPC subdirectory of <ftp://ftp.freepascal.org/pub/fpc/source/rtl.zip>). Simply throw the body of the code in a C assembler function and you should be able to test them.

I'm mainly interested in Darwin, since I use almost exclusively Mac OS X nowadays. Since Darwin was partly derived from MkLinux, it may be not too difficult to support MkLinux as well. There's also a bunch of people who want to do a classic Mac OS port already. I definitely intend to support different calling conventions from the start (they're different for LinuxPPC and Mac OS, and Mac OS X is again slightly different I've heard, even though it's derived from the classic Mac OS's calling conventions)

Jonas

Hi all,

does anyone believe that it's possible to start the AMD Hammer port using the available emulators and tools?

Vitek

Hi!

Am 24.08.2001 11:05:40 schrieb Full_Name
:

Yay Mac, yay Mac :-)

Jepp!

If you need testing, please call on me.

Me two. ;-)

I could provide testing on a Apus 2000 (Power PC 603e, MacOS 9.1), but not under Linux for Mac, I've got other computers to run Linux on.

Tschau!

Michael

you wrote

Hi all, does anyone believe that it's possible to start the AMD Hammer port using the available emulators and tools?

Of course, why not? You need only a machine running a Hammer emulation and the possibility to copy files to this machine. Furthermore, a linker and assembler is required.

Thanks for the quick reply Jonas.
g.

Hi,

Not that I am interested in a concrete port at this moment, but just a general question (perhaps doesn't make sense).

Due to the POSIX compliance, wouldn't it be possible to make a port based on POSIX, for every Unix which runs over a x86 family processor, regardless of the flavour?
I just say this in case the Linux port could be used for other x86 based Unices...

Aitor

___________________________________________________________________ Consigue tu e-mail gratuito TERRA.ES
Haz clic en http://www.terra.es/correo/

I am having trouble with polymorphism in a unit I am working on.

I have several classes defined as follows:

type
         TStackElem = class
                 public
                 constructor Init; virtual;
                 destructor Done; virtual;
                 Prolog : TRPLObjectType;
                 Next : TStackElem;
                 function Decomp : string; virtual; abstract;
         end;
         TStackReal = class(TStackElem)
                 public
                 constructor Init; override;
                 Data : real;
                 function Decomp : string; override;
         end;
         TStackCharString = class(TStackElem)
                 public
                 constructor Init; override;
                 Data : string;
                 function Decomp : string; override;
         end;

Note the Data field: it is not present in the parent class, and is defined as two different types in the child class.

I also have defined the function:

function Parse(Command : string) : TStackElem;
begin
         // Decide type of data based on Command
         // Define Parse as being TStackReal or TStackCharString (running
Parse := TStackReal.Init, etc.)
         // Put properly parsed data in Data field
end;

I haven't written the internal part of this function this time, but in previous attempts, the part of this function that 'Puts properly parsed data in Data field' of the TStackElem causes a compilation error, due to the Data field not being defined for TStackElem. In the absence of a Variant type (with which I would define Data : variant in TStackElem), how should I implement
the above function?

You can't. You'll either have to typecast to the actual type, or provide abstract functions as SetDataFromReal() and SetDataFromString() in TStackElem which are implemented in the descendents, and which set the data, based on the actual type.

In TStackReal the SetDataFromString can do 2 things: Attempt to convert the string to a real (which would be my choice), or raise an error saying that the data type is not supported.

TStackCharString can do the opposite with SetDataFromReal.

Michael.

We are already doing this: see the rtl/posix dir in the sources. This should allow an easy first port to a new system (beos, solaris etc), after which a more thorough, native port can be started.

Michael.

The rtl/posix directory is only available in the 1.0.5 development tree.

Quoting Michael Van Canneyt :

You can't.

Although it might get messy, surely he could defire a variant record? Something like:

type
  TStackElemType = (stNull, stString, stReal);
  TStackElem = record
    ElemType: TStackElemType;
    case tag: integer of
      0: (RealResult: Real);
      1: (StringResult: String[255]);
  end;
  PStackelem = ^TStackElem;
  procedure setStringElemData(st: string); //sets Elemtype to 'stReal'
  procedure setRealElemData(re: real); //sets Elemtype to 'stString'
  procedure CrearElem; //sets Elemtype to 'stNull'

But, to be honest, if you go that far you may as well use classes.

A more elegant solution is to go the Smalltalk route, and create classes that descend from a single ancestor. But that's not actually all that easy or gracefull in Pascal.

I think a more worrying thing is your following class:

This class will never call 'Done'. Not in the Delphi sense of the word. Try the following:

destructor TStackElem.Done;
begin
  //whatever you already did
  writeln('hello, I have destroyed myself');
  //whatever you already did
end;

You will never see the line 'hello, I have destroyed myself' unless you explicitly call 'done' and that is wrong. What you should actually do (and this is in the standard btw, it's not just me being pedantic) is call 'free'. Because Delphi has a policy of only having a single destructor, and this through polymorphism should be called 'destroy' and should be 'overridden' you are *never* freeing your resources. You may as well change the Destructors name to 'HelloIamAMemoryLeak'.

Before anyone jumps on me, this is tested under FPC 1.02 *and* FPC 1.04, compiled with '-S2'. The destructor never gets called if you call 'free'. It would be *really* nice if you could write this into the docs for 1.2, I expect it's already there, but it's obviously not evident coz people keep making this mistake. If you're going to allow people to use Delphi stle classes, they should always inherit from TObject (even if the user doesn't specify this) and therefore the destructor has to be called Destroy.

Breaking this is really bad, unless calling 'done' directly does call 'destroy'. I note however that if I create a class with 2 destructors, firstly FPC1.04 complains that I do have 2, and secondly only 'done' gets called if I call 'done' and only 'destroy' gets called if I call 'free'.

Sorry to moan again, but this is something that will cause many people problems if it's not addressed. The simplest, cheapest and less painfull would be to 'warn' people if they are using 'class' style constructs and their 'destructor' is not called 'destroy'.

Matt

This is implicit: _ALL_ classes descend from TObject (it states so in the docs, I think) So the 'Destroy' destructor must always be used.

But I will explicitly state this in the docs.

This is correct behaviour, But maybe not the expected behaviour.

1)
You *can* use a destructor that is not called destroy, as long as it calls the parent destructor 'Destroy':

Destructor TMyObject.DoMyDestroy;
begin
  Destroy;
end;

But it means that you must explicitly call the DoMyDestroy destructor.

2)
When using 'Free' you must know what 'Free' does: It checks for Nil, and then calls destroy -> ergo, if you don't call your destructor 'Destroy' (thus overriding TObject's implementation), using Free will not call your destructor.

But the point is taken, and I will add a remark similar to the above, to the docs.

Michael.

One would still have to adapt the system dependant headers for each version. POSIX is build as a fundamentent on C.

The nCrt unit for FreeBSD seems to be broken... but not as bad as the Crt unit...

The Crt unit seems to hang ANY program that uses it. It looks as theough the key buffer is never read... when you break out, all the keypresses are still in the buffer. If you Use nCrt, you get the following problems:

keypressed echos the key
writeing a #13 followed by a #10 deletes the current line before advancing to the next...

A simple test case to show it off is:

program test;
uses ncrt;
var key:        char;
begin
        ClrScr;
        write('This is a test line.');
        write(#13);
        write(#10);
        repeat begin
                if keypressed then begin
                        key:=readkey;
                        write(key);
                end;
        end;
        until key='q';
end.

<snip lots of code and comment>

You can't. You'll either have to typecast to the actual type, or provide abstract functions as SetDataFromReal() and SetDataFromString() in TStackElem which are implemented in the descendents, and which set the data, based on the actual type.

Ahh. Yes, that works quite nicely. Actually, what I'm going to do is similar, I'm just going to set up one SetData* function for each type in TStackElem as abstract, then implement just the appropriate function in each descendant type. This keeps me from having multiple implementations of each SetData* function for each descendant.

Yes, error handling...a good idea (and something I always seem to forget!)

TStackCharString can do the opposite with SetDataFromReal. Michael.

Thank you for your very rapid response.

_______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Yeah, I tried that--major, major problems with memory leaks, though. Not to mention, the implementation wasn't nearly as clean as it would be with classes.

<snip>

I probably should have looked up the definition of TObject in the docs before I started, but now that I have done so, I'm still confused. To destroy an instance of a class, I should call its destructor (which I've changed to Destoy, as you said I should). Thus the following should work *and is the proper way of doing this*:

var
         StackElement : TStackElem;
begin
         StackElement := TStackReal.Init;
         StackElement.Destroy;
end.

Am I correct in that assumption? Also, looking at the docs, I see that TObject defines a constructor, Create. Should I use that name instead of Init and override it, as I have done with Destroy?

In simple tests, everything seems to be working properly. Heaptrc reports no unfreed memory. If there is any other good documentation on classes lying around (don't bother searching for it if you don't know where it is, I plan on doing that myself), let me know. I think I need the help! Thanks for your assistance.

Yeah, I tried that--major, major problems with memory leaks, though. Not to mention, the implementation wasn't nearly as clean as it would be with classes.

It's nasty, but it the way at least some of the VCL works. Because Pascal is a strongly typed language, there's no way round it.

<snip> I probably should have looked up the definition of TObject in the docs before I started, but now that I have done so, I'm still confused.

It's not as straight forward as it could be :-(

To destroy an instance of a class, I should call its destructor (which I've changed to Destoy, as you said I should). Thus the following should work *and is the proper way of doing this*:

You must call 'Free'. There is a special method called 'Free' that through some 'magic' calls 'Destroy'.. don't ask why.. it was the way Delphi was implemented. I'm sure somebody can come up with a reason.

No. That should be:

StackElement.Free;

It seems to work in FPC with 'Destroy', but Delphi would barf at that point.

Also, looking at the docs, I see that TObject defines a constructor, Create. Should I use that name instead of Init and override it, as I have done with Destroy?

You can call your constructor whatever you like - it doesn't matter. 'Create' is the convention, and what most people will expect. You can 'get away' with not overriding your constructor if you call it create, and just marking it virtual. The Tobject class defines no content for the 'Create' method.

e.g.:

TStackElement = class(TObject)
{fields}

  constructor Create; virtual;
  {methods}
  {properties}

end;

In simple tests, everything seems to be working properly. Heaptrc reports no unfreed memory.

FPC lets you get away with it, though strictly 'free' is what you're after for 100% Delphi compatibility.

If there is any other good documentation on classes lying around (don't bother searching for it if you don't know where it is, I plan on doing that myself), let me know. I think I need the help! Thanks for your assistance.

Any document that describes Delphi and Object Pascal will give you a good start. Thake a look at Marco Cantu's site.. I believe he has some free downloads (www.marcocantu.com iirc)

Sorry it's a little later, I dumped (more or less) Windows at the weekend, and so I'm still playing catch up. BeOS rocks ;-)

Matt

The destructor does only what you write in it. If your class is allocated on
the heap, you must actually free the heap. That's what free() is for. free()
calls the destructor and then frees the heap, more or less like that
	free(objptr);
equals
	if objptr != nil then begin
		objptr.Destroy;
		freemem(objptr);
		objptr = nuil; { NO, I DON'T KNOW IF THIS LINE IS ACTUALLY DONE! }
	end;

I hope I didn't mess up things ;-)

Cheerz,
Kuba