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' char
^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,
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
afici
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
htt
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 w
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 o
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 s
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 mo
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 we
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
> un
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
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
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 an
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 -
__
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 au
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.free
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.
_
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, M
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 (...Mov
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
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
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
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 -
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 F
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 detai
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.
26 matches
Mail list logo
