[fpc-pascal] Command prompt
In the old days you could write exec(C:\DOS\COMMAND.COM',' COM1'); and then get access to the command prompt via a serial interface Could someone give me a hint how to do this in a Linux environment? Carsten ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Command prompt
En/na Carsten Bager ha escrit: In the old days you could write exec(C:\DOS\COMMAND.COM',' COM1'); and then get access to the command prompt via a serial interface Could someone give me a hint how to do this in a Linux environment? /sbin/getty -L ttyS0 115200 vt100 man getty for the gory details, if you want a console permanently on the first serial port, you can put the following in /etc/inittab (again, man inittab for details) 1:2345:respawn:/sbin/getty -L ttyS0 115200 vt100 Bye -- Luca ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] String to PString assignment?
Hi, I'm converting a project from Sibyl (a old OS/2 IDE implement in SpeedSoft Pascal). Below is the code I'm trying to convert to Free Pascal. I see FPC has a PString type, but not FreePString() or NewPString(). Searching the FPC source code, I found the FP Text IDE using PString all over. The FP Text IDE uses this... := NewStr(); Do I need this when I use String = AnsiString in my projects? Or can I simply do the following assignment: _Title := @NevValue; - _Title: PString; ... procedure TTopic.SetTitle( const NewValue: string ); begin FreePString( _Title ); _Title:= NewPString( NewValue ); end; - Sorry if this sounds dumb, but I have never used PString before. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] String to PString assignment?
No worries, I solved my problem by using AnsiString across the board. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] String to PString assignment?
In our previous episode, Graeme Geldenhuys said: > > I'm converting a project from Sibyl (a old OS/2 IDE implement in > SpeedSoft Pascal). > > Below is the code I'm trying to convert to Free Pascal. I see FPC has a > PString type, but not FreePString() or NewPString(). Searching the FPC > source code, I found the FP Text IDE using PString all over. The FP Text > IDE uses this... := NewStr(); > Do I need this when I use String = AnsiString in my projects? Or can I > simply do the following assignment: _Title := @NevValue; If you want to ansistringify, assume that pstring as a whole is ansistring, and remove all pointers and let ansistrings automatic maintenance work. Be careful with newstr, there are multiple versions of it. (a TP and Delphi version) see http://wiki.freepascal.org/Textmode_IDE_development#ansistringification Don't ever include objects and sysutils in the same unit. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] String to PString assignment?
2009/9/29 Marco van de Voort : > > If you want to ansistringify, assume that pstring as a whole is ansistring, > and remove all pointers and let ansistrings automatic maintenance work. Thanks Marco. That's what I did. I read bit more about PString and it seems pretty safe for me to simply replace it with AnsiString. So far so good. > Don't ever include objects and sysutils in the same unit. Good to know. I'm converting all Objects types to Class types too. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Move() vs MemCopy()
Hi,
I'm still porting code from SpeedSoft's Pascal compiler. The code I am
porting often uses MemCopy(), but Free Pascal doesn't seem to have
such an implementation. So I looked at the next best thing... Move()
But as the name suggests (...Move()...), I would have expected it to
actually move the data and not copy the data. The following example
program demonstrates this. Shouldn't S1 = '' after the Move() call?
Program Example42;
{ Program to demonstrate the Move function. }
Var S1,S2 : String [30];
begin
S1 := 'Hello World!';
S2 := 'Bye, bye !';
Move (S1,S2,Sizeof(S1));
Writeln ('S2:', S2);
Writeln ('S1:', S1); // Why does this still hold "Hello World!"
end.
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Move() vs MemCopy()
In our previous episode, Graeme Geldenhuys said: > I'm still porting code from SpeedSoft's Pascal compiler. The code I am > porting often uses MemCopy(), but Free Pascal doesn't seem to have > such an implementation. So I looked at the next best thing... Move() > > But as the name suggests (...Move()...), I would have expected it to > actually move the data and not copy the data. The following example > program demonstrates this. Shouldn't S1 = '' after the Move() call? No. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Move() vs MemCopy()
2009/9/29 Marco van de Voort : > > No. So why is the function called MOVE instead of COPY? :-) I grep searched the *full* FPC source and found a implementation of MemCopy() in the packages/pasjpeg/* directory... So it seems to confirm what you (Marco) said. MOVE = MEMCOPY.It that case, MOVE is a pretty stupid and confusing name for a procedure that actually copies memory and not move memory. Just my 2c worth. ;-) procedure MEMCOPY(dest, src : pointer; size : size_t); begin Move(src^, dest^, size); end; Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Move() vs MemCopy()
On Tue, 29 Sep 2009, Graeme Geldenhuys wrote: 2009/9/29 Marco van de Voort : No. So why is the function called MOVE instead of COPY? :-) Because move predates memcopy. memcopy is a windows function. Move existed in the system unit of TP even before windows existed. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Move() vs MemCopy()
Graeme Geldenhuys schrieb: > 2009/9/29 Marco van de Voort : >> No. > > > So why is the function called MOVE instead of COPY? :-) Because it doesn't copy your ram modules ;) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Move() vs MemCopy()
2009/9/29 Michael Van Canneyt : > > Because move predates memcopy. memcopy is a windows function. > Move existed in the system unit of TP even before windows existed. Windows has 'memcpy()', not 'memcopy()' ;-) As for the origins of Move(), I can't comment except to say that the original author of that procedure is trying to f*ck with my mind. :-) I would have imagined that with all our new found knowledge we might have come up with a better name for that procedure by now. Maybe it is worth adding a MemCopy() method in FPC? Which simply calls Move() internally. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Move() vs MemCopy()
2009/9/29 Florian Klaempfl : > > Because it doesn't copy your ram modules ;) Well, if I move something (no matter what it is), it doesn't exist in the original location any more. Hence my confusion about the Move() procedure. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Move() vs MemCopy()
On 29 Sep 2009, at 15:46, Graeme Geldenhuys wrote: Windows has 'memcpy()', not 'memcopy()' ;-) memcpy() is from the C library. And the C library also has memmove(), for that matter. The difference between memcpy() and memmove() is that memcpy() has undefined behaviour if the source and destination overlap, while memmove() ensures that everything always works fine. As a result, calling the Pascal version "move" is logical. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Move() vs MemCopy()
In our previous episode, Graeme Geldenhuys said: > > No. > So why is the function called MOVE instead of COPY? :-) Historical reasons apparantly. > I grep searched the *full* FPC source and found a implementation of > MemCopy() in the packages/pasjpeg/* directory... So it seems to > confirm what you (Marco) said. MOVE = MEMCOPY.It that case, MOVE > is a pretty stupid and confusing name for a procedure that actually > copies memory and not move memory. Just my 2c worth. ;-) I've no idea what memcopy is, and why we should support it. Probably it is some pascalized version of the standard C memcpy command. Move is in use for 20 years, and I think it will generate 1000 times more confusion than it will ever solve if you change or add to it. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Move() vs MemCopy()
Graeme Geldenhuys schrieb: > 2009/9/29 Florian Klaempfl : >> Because it doesn't copy your ram modules ;) > > Well, if I move something (no matter what it is), it doesn't exist in > the original location any more. Hence my confusion about the Move() > procedure. Indeed, the serious answer is: move handles overlapping memory blocks correctly (so the data might not existing anymore at the old location), memcpy doesn't do this and screws things up when handling overlapping blocks. This is why e.g. C++ has memmove as well which is more expensive than memcpy due to overlap checks. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Move() vs MemCopy()
Jonas Maebe schrieb: > > On 29 Sep 2009, at 15:46, Graeme Geldenhuys wrote: > >> Windows has 'memcpy()', not 'memcopy()' ;-) > > memcpy() is from the C library. And the C library also has memmove(), > for that matter. > > The difference between memcpy() and memmove() is that memcpy() has > undefined behaviour if the source and destination overlap, while > memmove() ensures that everything always works fine. > > As a result, calling the Pascal version "move" is logical. Jonas was quicker ;( ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Move() vs MemCopy()
2009/9/29 Florian Klaempfl : > > Indeed, the serious answer is: > move handles overlapping memory blocks correctly (so the data might not > existing anymore at the old location), memcpy doesn't do this and screws > things up when handling overlapping blocks. This is why e.g. C++ has > memmove as well which is more expensive than memcpy due to overlap checks. I thought simple pointer arithmetic would solve the issue of memcpy()? Anyway, so based on your answer, if we apply the following code (shown belowe) to FPC, we have the best of both worlds! :-) MemCopy() does exactly what Move() does - but without the name confusion. :-) Could this "alias" procedure be applied somewhere in FPC? This was done before - the case of AssignFile() vs Assign() procedure MemCopy(src, dest: pointer; size: SizeInt); begin Move(src^, dest^, size); end; Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Move() vs MemCopy()
Marco van de Voort schreef: In our previous episode, Graeme Geldenhuys said: No. So why is the function called MOVE instead of COPY? :-) Historical reasons apparantly. I never thought that mov ax, bx (8086 assembler) would clear the register after the move. So I never thought that move would clear the memory (or leave it in a undefined state). Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Move() vs MemCopy()
2009/9/29 Graeme Geldenhuys : > > Could this "alias" procedure be applied somewhere in FPC? This was > done before - the case of AssignFile() vs Assign() > > procedure MemCopy(src, dest: pointer; size: SizeInt); > begin > Move(src^, dest^, size); > end; here is an improved MemCopy(), with the same parameter list as Move(). procedure MemCopy(const src; var dest; size: SizeInt); begin Move(src, dest, size); end; - Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Move() vs MemCopy()
2009/9/29 Vincent Snijders : > > I never thought that > mov ax, bx (8086 assembler) > would clear the register after the move. If you put it like that, it never (for some strange reason) confused be either. :-) I guess that's probably because everything in assembler confused me, so nothing stood out above the rest. ;-) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Move() vs MemCopy()
Graeme Geldenhuys schrieb: > 2009/9/29 Florian Klaempfl : >> Indeed, the serious answer is: >> move handles overlapping memory blocks correctly (so the data might not >> existing anymore at the old location), memcpy doesn't do this and screws >> things up when handling overlapping blocks. This is why e.g. C++ has >> memmove as well which is more expensive than memcpy due to overlap checks. > > I thought simple pointer arithmetic would solve the issue of memcpy()? > > > Anyway, so based on your answer, if we apply the following code (shown > belowe) to FPC, we have the best of both worlds! :-) MemCopy() does > exactly what Move() does - but without the name confusion. :-) It does not. MemCopy is simpler and because of the missing overlapping checks, it as faster and it can be often inlined. > > Could this "alias" procedure be applied somewhere in FPC? This was > done before - the case of AssignFile() vs Assign() > > procedure MemCopy(src, dest: pointer; size: SizeInt); > begin > Move(src^, dest^, size); > end; > > > > Regards, > - Graeme - > > > ___ > fpGUI - a cross-platform Free Pascal GUI toolkit > http://opensoft.homeip.net/fpgui/ > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Meaning of "^M^J"
I read a source file,found it writes "^M^J" to a output. I don't know what is it's meaning, after test,I think it should be a return char, my question is, where can i find defination of this? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Meaning of "^M^J"
At 08:48 PM 9/29/2009, yu ping wrote: I read a source file,found it writes "^M^J" to a output. I don't know what is it's meaning, after test,I think it should be a return char, my question is, where can i find defination of this? It's simply the byte sequence 0Dh, 0Ah (or 0x0d, 0x0a of C aficionados, "Carriage Return"-"Line Feed") which is the end-of-line sequence for CP/M,DOS/Windows since the early '70s, and in contrast to Unix/Linux, which uses only a 0Ah, while at least the older Mac OS was using only a 0Dh to mark the end of a line in a text file... Ralf ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Meaning of "^M^J"
^A= 1 ^b= 2 ^c= 3 ^d= 4 ^e= 5 ^f= 6 ^g= 7 ^h= 8 ^i= 9 ^j= 10 ^k= 11 ^l= 12 ^m= 13 ^n= 14 ^o= 15 ^p= 16 ^q= 17 ^r= 18 ^s= 19 ^t= 20 ^u= 21 ^v= 22 ^w= 23 ^x= 24 ^y= 25 ^z= 26 I wander how "^" symble works 2009/9/30 Ralf A. Quint : > At 08:48 PM 9/29/2009, yu ping wrote: >> >> I read a source file,found it writes "^M^J" to a output. >> I don't know what is it's meaning, >> after test,I think it should be a return char, >> my question is, where can i find defination of this? > > It's simply the byte sequence 0Dh, 0Ah (or 0x0d, 0x0a of C aficionados, > "Carriage Return"-"Line Feed") which is the end-of-line sequence for > CP/M,DOS/Windows since the early '70s, and in contrast to Unix/Linux, which > uses only a 0Ah, while at least the older Mac OS was using only a 0Dh to > mark the end of a line in a text file... > > Ralf > ___ > fpc-pascal maillist - fpc-pas...@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Meaning of "^M^J"
At 09:38 PM 9/29/2009, yu ping wrote: ^A= 1 ^b= 2 ^c= 3 ^d= 4 ^e= 5 ^f= 6 ^g= 7 ^h= 8 ^i= 9 ^j= 10 ^k= 11 ^l= 12 ^m= 13 ^n= 14 ^o= 15 ^p= 16 ^q= 17 ^r= 18 ^s= 19 ^t= 20 ^u= 21 ^v= 22 ^w= 23 ^x= 24 ^y= 25 ^z= 26 I wander how "^" symble works It's a common abbreviation for the the 'Control' characters (decimal values 0-31, hex 00h-1Fh) in the ASCII alphabet representation. This should be the very basic of any programming introduction. A good online reference can be found at http://www.asciitable.com Ralf ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
