Vladimir Karpenko writes:
> How can i access harware ports if there is no ports unit on Linux
> x64 port?
There is a tutorial for Hardware Access here:
http://wiki.lazarus.freepascal.org/Hardware_Access
--
Regards, Paul Csanyi
http://www.freewebs.com/csanyi-pal/index.htm
_
To add my two cents to this debate.
I have always thought the ideal form of standards (or de facto thereof) came
from benevolent dictators. Borland did that job well for quite a long time,
a single vision developed well beats the design-by-committee half-compromise
path any day.
The problem
How can i access harware ports if there is no ports unit on Linux x64 port?
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
2008/7/7 Jonas Maebe <[EMAIL PROTECTED]>:
>
> Because the scanner only handles shortstrings for speed reasons. You can
> construct longer strings by concatenating multiple shorter strings (they
> will be concatenated at compile time).
>
> someproc('this string can be 255 characters' + 'and this one
Jonas Maebe schrieb:
On 07 Jul 2008, at 18:26, Graeme Geldenhuys wrote:
I've got a few functions defined with 'const' string parameters. When
I tried to pass a large string, I got the following error message. Why
is that?
Because the scanner only handles shortstrings for speed reasons. You c
On 07 Jul 2008, at 18:26, Graeme Geldenhuys wrote:
I've got a few functions defined with 'const' string parameters. When
I tried to pass a large string, I got the following error message. Why
is that?
Because the scanner only handles shortstrings for speed reasons. You
can construct longer
I forgot to mention, I'm using FPC 2.2.0 under Linux (32bit system).
Graeme.
2008/7/7 Graeme Geldenhuys <[EMAIL PROTECTED]>:
> Hi,
>
> I've got a few functions defined with 'const' string parameters. When
> I tried to pass a large string, I got the following error message. Why
> is that? I thou
Hi,
I've got a few functions defined with 'const' string parameters. When
I tried to pass a large string, I got the following error message. Why
is that? I thought string type can hold as much as the memory you
have in your system. I am using the following compiler mode in all my
units: {$mode
> I found your answers to my naive questions really interesting. And
> certainly I agree. Would it be possible to make them more visible on the
> web site of Free Pascal? In practice, include the texts you pointed to
> (iso-ansi discussion and delphilater) in the web site? Or did I missed
> them?
Hi Marco,
I found your answers to my naive questions really interesting. And
certainly I agree. Would it be possible to make them more visible on the
web site of Free Pascal? In practice, include the texts you pointed to
(iso-ansi discussion and delphilater) in the web site? Or did I missed
them?
> the question is interesting in my opinion. The standard for a language
> (C, Fortran, C++)
> or an authority able to define the language (Java)
Sun has owned Java for much of the time, as well as CG did
Delphi. I wouldn't place them in the same part as the former.
> helps to write code that w
leledumbo wrote:
Why Modern Pascal isn't standardized? Take a look at its other brothers and
sisters, for example C & Fortran. (AFAIK) C has been standardized in 1989
and 1999 (there perhaps earlier ones), while Fortran in 60,77,..(I forgot
these ones, there are too many),2000,2003(,2005?). Pasca
[ Charset ISO-8859-1 unsupported, converting... ]
> > Ask your OS vendor. These are OS errors.
> > But:
> > 11 is iirc EAGAIN, which means "try again", which is due to a potential
> > deadlock in the kernel not being handled properly.
>
> You say that SocketErrors are OS errors but some influence
Hi,
the question is interesting in my opinion. The standard for a language
(C, Fortran, C++) or an authority able to define the language (Java)
helps to write code that will be as unrelated as possible of a precise
"dialect" or community.
As I understand, the main problem is the relation with Cod
> Ask your OS vendor. These are OS errors.
> But:
> 11 is iirc EAGAIN, which means "try again", which is due to a potential
> deadlock in the kernel not being handled properly.
You say that SocketErrors are OS errors but some influence the FPC
compiler must have.
I modified my program a bit. It no
> I have a simple TCP program and I want to see when the client breaks the
> line.
> With the 205 compiler this is not a problem SocketError tells me, but with
> the 220 compiler nothing happens. Do I have to do something else?
>
> When compiled to 386 SocketError always returns 0, but when comp
So, what's the purpose of having them?
--
View this message in context:
http://www.nabble.com/Flush%28StdOut%29-doesn%27t-mean-Flush%28Output%29-tp18311722p18313575.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-p
On Mon, Jul 7, 2008 at 12:22 PM, Michael Van Canneyt
<[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 7 Jul 2008, leledumbo wrote:
>
>>
>> Why Modern Pascal isn't standardized? Take a look at its other brothers and
>> sisters, for example C & Fortran. (AFAIK) C has been standardized in 1989
>> and 1999 (th
I have a simple TCP program and I want to see when the client breaks the
line.
With the 205 compiler this is not a problem SocketError tells me, but with
the 220 compiler nothing happens. Do I have to do something else?
When compiled to 386 SocketError always returns 0, but when compiled to
ARM
On Mon, 7 Jul 2008, leledumbo wrote:
>
> Why Modern Pascal isn't standardized? Take a look at its other brothers and
> sisters, for example C & Fortran. (AFAIK) C has been standardized in 1989
> and 1999 (there perhaps earlier ones), while Fortran in 60,77,..(I forgot
> these ones, there are to
On Mon, July 7, 2008 09:55, leledumbo wrote:
>
> In the rtl documentation, StdOut is defined as an alias for Output.
> Therefore, (I think) flushing one will also flush the other. But the
> truth,
> it's not. In fact, only Flush(Output) will really flush standard output.
> So,
> what will Flush(Std
Why Modern Pascal isn't standardized? Take a look at its other brothers and
sisters, for example C & Fortran. (AFAIK) C has been standardized in 1989
and 1999 (there perhaps earlier ones), while Fortran in 60,77,..(I forgot
these ones, there are too many),2000,2003(,2005?). Pascal has only 2
stand
In the rtl documentation, StdOut is defined as an alias for Output.
Therefore, (I think) flushing one will also flush the other. But the truth,
it's not. In fact, only Flush(Output) will really flush standard output. So,
what will Flush(StdOut) do?
PS: This might apply to StdErr (and StdIn, but I
23 matches
Mail list logo
