Re: [fpc-pascal] A question or two regarding the FPC

2009-05-09 Thread Graeme Geldenhuys
On Sat, May 9, 2009 at 12:24 AM, Vinzent Höfler
jellyfish.softw...@gmx.net wrote:

 Actually, you should answer one simple question for yourself: If your life 
 really depended
 on the system, would you still trust it?

In that case we should all be very worried. Many critical systems out
there run on Windows - we as technical people know that Windows is not
the most stable platform out there.  :-)

The basic question is: Can we fully trust computers?  NO - but we have
to unfortunately. Computers are built up of many components. We have
no idea how well those components have been tested and simply have to
trust that sufficient testing has been applied. The software compiler
is just one of those many components.


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] A question or two regarding the FPC

2009-05-09 Thread Mehmet Erol Sanliturk

fpcl...@silvermono.co.za wrote:

Hi guys,

Over the last few years, I have written hundreds of thousands of lines of 
object pascal code that compiles successfully using the FPC and Delphi. To 
date, I have not encountered any problems with the code generated by the 
FP Linux compiler. I don't have much experience with FPC within the MS Windows 
environment as my current interest lies in developing console Linux apps.


Like most developers, I strive to write code that is as bug free as possible 
and at the end of each day, I'm left with a feeling of great satisfaction and 
achievment.


IMO and experience, the code generated by the FPC is as resilient as the 
operating system it runs on. 

My question is directed to the FPC team and in particular, to those involved 
in the development of the compiler and more specific, the Linux compiler. (I 
would expect that Florian would have a say here).


In your opinion, how would you rate the suitability of the FPC generated code 
for use in an environment where there is near zero tolorance to failure? 
Consider the question assuming that the ideal condition where that the source 
code is as close to being perfect as possible, (and I'm not suggesting that 
this perfect code would be written by me. I'm not that good).


...

Regards,
Nino

  


Actually this is a very difficult question to answer properly .
As a very productive program writer since ( approximately ) 1973
I can say that the problem has a significant number of parameters
to consider such as :

- Specifications about software
- Algorithm design of the software by the programmer
- Used language constructs of selected compiler
- Compiler itself
- Libraries used by the compiler
- Operating system
- Testing the developed software
- Hardware running the software
- and others ...

There is a definition that reliability of a system can not be greater 
than  its reliability of weakest

component ( having minimum reliability ) .

All of the above components and other unspecified components will 
comprise a system as a whole .


When considering FPC :

- There are internal error points generated during run time triggered by 
the user program .
  It is necessary to write programs which avoid those points ( if 
possible ) .


  For an error free program , FPC generates very good code with the 
reminder that all of the
  software may contain bugs and an exhaustive  test of FPC to generate 
a fault-tolerant compiler  
  may require combinatorial  steps which is beyond the existing 
capabilities .


  In that respect ADA could not be adopted widely because its 
compilation depended on C compilers which they ( C compilers ) are not 
conforming to ADA specifications .


- FPC is NOT compliant to Delphi ( a very obvious feature , at least FPC 
is for cross-platform whereas Delphi is only for Windows platform ) .
A program compiled and working perfectly in one of them is not a 
guarantee that it will work perfectly when compiled by the other .


- FPC ( and Lazarus are ) is  using  external libraries such as GTK  
and/or QT  which those are beyond of  FPC team control .  Bugs in FPC ( 
and Lazarus ) are corrected promptly by generating a very good work by 
the FPC teams , but other libraries have their own development teams and

work schedules .

Since May 2008 I am trying to learn FPC as much as possible . Nearly all 
of my problems are caused by the  libraries  used  , NOT  by the FPC 
itself  ( except a few )  .


-  It is necessary to write programs to handle run-time exceptions 
properly . Compiler can not do anything much about that . A ( try ... 
except raise exception ) structure may have disastrous effects on  
outcome of a program when it is run when a life-critical system is 
controlled by such a program . The program should be designed properly 
to handle such situations without  causing  disasters .
For example , in an airplane  fall-down  many years before ( 
approximately 110 deaths ) it has
been found that in the automatic pilot software an error situation used 
a STOP statement . During landing it caused release of control of the 
airplane by the automatic pilot ( then the related company   had 
discontinued  the software  automatic pilot and reverted to mechanical  
control  )  .


These are my ( partial ) opinions about the above question .

Thank you very much .

Mehmet Erol Sanliturk













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


[fpc-pascal] fpselect does not work on linux

2009-05-09 Thread Rainer Stratmann
To find out if a nonblocking socket has connected I use the following piece of 
code:

With windows that works, but with linux I get alwas the result that the socket 
is writable.

function is_writable_socket( sck : integer ) : boolean;
var
  fds : tfdset;
  tv  : timeval;
begin
  {$ifdef linux}   fpfd_zero( fds ); fpfd_set( sck , fds ); {$endif}
  {$ifdef windows}   fd_zero( fds );   fd_set( sck , fds ); {$endif}
  tv.tv_sec  := 0;
  tv.tv_usec := 0;
  // socket+1 , read , write , except , timeout
  {$ifdef linux}
  result := fpselect( sck + 1 , nil  , @fds  , nil, @tv )  0;
  {$else}
  result :=   select( sck + 1 , nil  , @fds  , nil, @tv )  0;
  {$endif}
end;
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] A question or two regarding the FPC

2009-05-09 Thread Graeme Geldenhuys
On Sat, May 9, 2009 at 3:58 AM, Mehmet Erol Sanliturk
sanlit...@ttmail.com wrote:
 For example , in an airplane  fall-down  many years before ( approximately
 110 deaths ) it has
 been found that in the automatic pilot software an error situation used a
 STOP statement . During landing it caused release of control of the airplane

This happens more often than you think.  I watched a few days ago a
program about a SAAB military aircraft test pilot that survived 3
airplane crashes. Each crash destroying a $24mil plane. The first two
crashes where caused by the on-board software failing - software
crashed. They then did some serious software bug fixing and were
confident that the software defects are solved. The 3rd crash was
caused by the now nervous pilot, over compensating for what the
software wanted to do. This overloaded the software with inputs it
simply couldn't handle fast enough and the software simply started
dropping instructions to try and keep up. Needless to say, that plane
crashed as well.

After that the pilot stopped being a test pilot for that specific
model aircraft, but SAAB did eventually manage to fix all the software
bugs. Quite an expensive debugging session.

Moral of the story?  Test, test and TEST! And when in doubt, test some more!


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] A question or two regarding the FPC

2009-05-09 Thread Graeme Geldenhuys
On Sat, May 9, 2009 at 3:58 AM, Mehmet Erol Sanliturk
sanlit...@ttmail.com wrote:
 For example , in an airplane  fall-down  many years before ( approximately
 110 deaths ) it has
 been found that in the automatic pilot software an error situation used a
 STOP statement . During landing it caused release of control of the airplane

This happens more often than you think.  I watched a few days ago a
program about a SAAB military aircraft test pilot that survived 3
airplane crashes. Each crash destroying a $24mil plane. The first two
crashes where caused by the on-board software failing - software
crashed. They then did some serious software bug fixing and were
confident that the software defects are solved. The 3rd crash was
caused by the now nervous pilot, over compensating for what the
software wanted to do. This overloaded the software with inputs it
simply couldn't handle fast enough and the software simply started
dropping instructions to try and keep up. Needless to say, that plane
crashed as well.

After that the pilot stopped being a test pilot for that specific
model aircraft, but SAAB did eventually manage to fix all the software
bugs. Quite an expensive debugging session.

Moral of the story?  Test, test and TEST! And when in doubt, test some more!


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] fpselect does not work on linux

2009-05-09 Thread Michael Van Canneyt


On Sat, 9 May 2009, Rainer Stratmann wrote:

 To find out if a nonblocking socket has connected I use the following piece 
 of 
 code:
 
 With windows that works, but with linux I get alwas the result that the 
 socket 
 is writable.
 
 function is_writable_socket( sck : integer ) : boolean;
 var
   fds : tfdset;
   tv  : timeval;
 begin
   {$ifdef linux}   fpfd_zero( fds ); fpfd_set( sck , fds ); {$endif}
   {$ifdef windows}   fd_zero( fds );   fd_set( sck , fds ); {$endif}
   tv.tv_sec  := 0;
   tv.tv_usec := 0;
   // socket+1 , read , write , except , timeout
   {$ifdef linux}
   result := fpselect( sck + 1 , nil  , @fds  , nil, @tv )  0;
   {$else}
   result :=   select( sck + 1 , nil  , @fds  , nil, @tv )  0;
   {$endif}
 end;

And why do you think that this is a bug ?

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] fpselect does not work on linux

2009-05-09 Thread Rainer Stratmann
Am Samstag, 9. Mai 2009 12:17 schrieb Michael Van Canneyt:
 On Sat, 9 May 2009, Rainer Stratmann wrote:
  To find out if a nonblocking socket has connected I use the following
  piece of code:
 
  With windows that works, but with linux I get alwas the result that the
  socket is writable.
 
  function is_writable_socket( sck : integer ) : boolean;
  var
fds : tfdset;
tv  : timeval;
  begin
{$ifdef linux}   fpfd_zero( fds ); fpfd_set( sck , fds ); {$endif}
{$ifdef windows}   fd_zero( fds );   fd_set( sck , fds ); {$endif}
tv.tv_sec  := 0;
tv.tv_usec := 0;
// socket+1 , read , write , except , timeout
{$ifdef linux}
result := fpselect( sck + 1 , nil  , @fds  , nil, @tv )  0;
{$else}
result :=   select( sck + 1 , nil  , @fds  , nil, @tv )  0;
{$endif}
  end;

 And why do you think that this is a bug ?
I know that the socket I tested is not writable, but the function returns 
writable... always with linux.

It is not working on linux operating system. With windows os that works.

Someone else have (had?) exactly the same problem:
http://community.freepascal.org:1/bboards/message?message_id=270583forum_id=24083
Rainer

 Michael.
 ___
 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


Re: [fpc-pascal] A question or two regarding the FPC

2009-05-09 Thread fpclist
Hi Graeme

You have a point.

About two months ago, I had to visit the dentist because one of my filings was 
playing up. The diagnosis was that an old silver filing was leaking and 
needed to be replaced. Becase of all the hype about mercury poisoning caused 
by silver filings (which from my knowledge silver filings contains basically 
silver nitrate), the dentist suggested using an inlay which is made of some 
composite plastic etc.

I agreed and a mobile PC on wheels was rolled in by his nurse. I noticed the 
familiar green start button on the bottom left corner of the screen and asked 
what version of Windows XP this box was running. The dentist's reply was that 
this was a special version of windows specifically designed to run medical 
related critical software. Not being an offensive character, I gave him the 
benefit of the doubt. While he was attempting to start the 'tooth profiling' 
program, he clicked on a tab on the taskbar and up popped MS Solitare! 
Obviously this medical box was trying to pay for itself in more ways than its 
intended use.

To cut a long story short, during the three dimensional scan of my tooth, the 
Windows box blue screened. After a reboot, it worked fine until the tooth 
inlay cutting process, where the program controls a milling machine. The 
milling process takes close to half an hour to complete, and half way through 
the milling process, yes you guessed it, the controlling program crashed in 
Windows. I remarked that the inlay would now be useless, but the dentist's 
reply was no, it's okay, it happens quite often. Just can't restart the 
program or the milling will stop.

When I peeked at the back of the Windows box, I was quite surprised to find a 
Siemens logo!

Also, a few weeks later, my inlayed tooth required a root treatment.

IMO, A good programmer using FPC and Linux will produce a more stable product 
than the same programmer using anything (MSVS, Delphi, DotNet, whatever) and 
running in Windows. By the way, I have nothing against MS or Windows. I think 
that MS has done a pretty good job since NT4, mostly thanks to Dave Cutler 
and his team (ex Digital VMS OS architect - is that why NT was more stable 
than 95, cause it's based on Unix?). Apart from poorly written software, 
poorly written device driver are the major cause of Windows OS crashes. Of 
course viruses and trojans etc don't help either.

Anyway, In my opinion and experience, I think that Free Pascal is suitable for 
mission critical work and yes the system as a whole must comply. The OS, the 
hardware the software. Redundancy must also be factured in. Most embedded 
device have a hardware watchdog that will reset the device when required.

Signing off,
Nino

//-

On Saturday 09 May 2009 10:08:50 Graeme Geldenhuys wrote:
 On Sat, May 9, 2009 at 12:24 AM, Vinzent Höfler

 jellyfish.softw...@gmx.net wrote:
  Actually, you should answer one simple question for yourself: If your
  life really depended on the system, would you still trust it?

 In that case we should all be very worried. Many critical systems out
 there run on Windows - we as technical people know that Windows is not
 the most stable platform out there.  :-)

 The basic question is: Can we fully trust computers?  NO - but we have
 to unfortunately. Computers are built up of many components. We have
 no idea how well those components have been tested and simply have to
 trust that sufficient testing has been applied. The software compiler
 is just one of those many components.


 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


Re: [fpc-pascal] fpselect does not work on linux

2009-05-09 Thread Michael Van Canneyt


On Sat, 9 May 2009, Rainer Stratmann wrote:

 Am Samstag, 9. Mai 2009 12:17 schrieb Michael Van Canneyt:
  On Sat, 9 May 2009, Rainer Stratmann wrote:
   To find out if a nonblocking socket has connected I use the following
   piece of code:
  
   With windows that works, but with linux I get alwas the result that the
   socket is writable.
  
   function is_writable_socket( sck : integer ) : boolean;
   var
 fds : tfdset;
 tv  : timeval;
   begin
 {$ifdef linux}   fpfd_zero( fds ); fpfd_set( sck , fds ); {$endif}
 {$ifdef windows}   fd_zero( fds );   fd_set( sck , fds ); {$endif}
 tv.tv_sec  := 0;
 tv.tv_usec := 0;
 // socket+1 , read , write , except , timeout
 {$ifdef linux}
 result := fpselect( sck + 1 , nil  , @fds  , nil, @tv )  0;
 {$else}
 result :=   select( sck + 1 , nil  , @fds  , nil, @tv )  0;
 {$endif}
   end;
 
  And why do you think that this is a bug ?
 I know that the socket I tested is not writable, but the function returns 
 writable... always with linux.
 
 It is not working on linux operating system. With windows os that works.
 
 Someone else have (had?) exactly the same problem:
 http://community.freepascal.org:1/bboards/message?message_id=270583forum_id=24083


The call functions correctly, IMHO, but the behaviour of the call is not as you 
expect.

Select does *not* tell you if a file descriptor is writeable or readable. 
It tells you if the read/write operation will block. 
This is something subtly different.

For instance, it reports file descriptor 0 as writable, which is rather 
strange, since it
is read-only, but correct, because the write call will not block. Indeed the 
write call
will return at once with an error condition. 

This is what the kernel sees (I used strace to test your code with descriptor 
0):

select(1, NULL, [0], NULL, {0, 0})  = 1 (out [0], left {0, 0})

Which is exactly what I sent. 

In short, is_writable_socket should be implemented differently, not using 
select.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] fpselect does not work on linux

2009-05-09 Thread Jonas Maebe


On 09 May 2009, at 09:38, Rainer Stratmann wrote:

To find out if a nonblocking socket has connected I use the  
following piece of

code:

With windows that works, but with linux I get alwas the result that  
the socket

is writable.

function is_writable_socket( sck : integer ) : boolean;
var
 fds : tfdset;
 tv  : timeval;
begin
 {$ifdef linux}   fpfd_zero( fds ); fpfd_set( sck , fds ); {$endif}
 {$ifdef windows}   fd_zero( fds );   fd_set( sck , fds ); {$endif}
 tv.tv_sec  := 0;
 tv.tv_usec := 0;
 // socket+1 , read , write , except , timeout
 {$ifdef linux}
 result := fpselect( sck + 1 ,


Where does the + 1 come from?


nil  , @fds  , nil, @tv )  0;


This is probably unrelated to your problem, but you have a bug here.  
(fp)select can also return EINTR (possibly under Windows as well, I  
don't know), in which case you have to retry. You need something like  
this:


repeat
  res:=fpselect( sck + 1 , nil  , @fds  , nil, @tv );
until (res-1) or (fpgeterrnoESysEIntr);

Note that you have to use this construct for many low level unix  
calls. Check the man pages to see which routines can return EINTR and  
may need restarting.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] fpselect does not work on linux

2009-05-09 Thread Michael Van Canneyt


On Sat, 9 May 2009, Jonas Maebe wrote:

 
 On 09 May 2009, at 09:38, Rainer Stratmann wrote:
 
 To find out if a nonblocking socket has connected I use the following piece
 of
 code:
 
 With windows that works, but with linux I get alwas the result that the
 socket
 is writable.
 
 function is_writable_socket( sck : integer ) : boolean;
 var
  fds : tfdset;
  tv  : timeval;
 begin
  {$ifdef linux}   fpfd_zero( fds ); fpfd_set( sck , fds ); {$endif}
  {$ifdef windows}   fd_zero( fds );   fd_set( sck , fds ); {$endif}
  tv.tv_sec  := 0;
  tv.tv_usec := 0;
  // socket+1 , read , write , except , timeout
  {$ifdef linux}
  result := fpselect( sck + 1 ,
 
 Where does the + 1 come from?

Man select:
  nfds is the highest-numbered file descriptor in any of the three sets, plus 1.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] fpselect does not work on linux

2009-05-09 Thread fpclist
According to the FPC rtl.pdf version 2.2.2 Doc version 2.1 of June 2008, page 
165, states, and I quote: Description:FPSelect checks one of the file 
descriptors in the FDSets to see if its status changed.

//-

On Saturday 09 May 2009 12:50:03 Michael Van Canneyt wrote:
 On Sat, 9 May 2009, Rainer Stratmann wrote:
  Am Samstag, 9. Mai 2009 12:17 schrieb Michael Van Canneyt:
   On Sat, 9 May 2009, Rainer Stratmann wrote:
To find out if a nonblocking socket has connected I use the following
piece of code:
   
With windows that works, but with linux I get alwas the result that
the socket is writable.
   
function is_writable_socket( sck : integer ) : boolean;
var
  fds : tfdset;
  tv  : timeval;
begin
  {$ifdef linux}   fpfd_zero( fds ); fpfd_set( sck , fds ); {$endif}
  {$ifdef windows}   fd_zero( fds );   fd_set( sck , fds ); {$endif}
  tv.tv_sec  := 0;
  tv.tv_usec := 0;
  // socket+1 , read , write , except , timeout
  {$ifdef linux}
  result := fpselect( sck + 1 , nil  , @fds  , nil, @tv )  0;
  {$else}
  result :=   select( sck + 1 , nil  , @fds  , nil, @tv )  0;
  {$endif}
end;
  
   And why do you think that this is a bug ?
 
  I know that the socket I tested is not writable, but the function returns
  writable... always with linux.
 
  It is not working on linux operating system. With windows os that works.
 
  Someone else have (had?) exactly the same problem:
  http://community.freepascal.org:1/bboards/message?message_id=270583f
 orum_id=24083

 The call functions correctly, IMHO, but the behaviour of the call is not as
 you expect.

 Select does *not* tell you if a file descriptor is writeable or readable.
 It tells you if the read/write operation will block.
 This is something subtly different.

 For instance, it reports file descriptor 0 as writable, which is rather
 strange, since it is read-only, but correct, because the write call will
 not block. Indeed the write call will return at once with an error
 condition.

 This is what the kernel sees (I used strace to test your code with
 descriptor 0):

 select(1, NULL, [0], NULL, {0, 0})  = 1 (out [0], left {0, 0})

 Which is exactly what I sent.

 In short, is_writable_socket should be implemented differently, not using
 select.

 Michael.
 ___
 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


Re: [fpc-pascal] fpselect does not work on linux

2009-05-09 Thread dmitry boyarintsev
hello Rainer,

do you check the socket's writability by fpFD_ISSET(sck, fds) ?

thanks,
dmitry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] fpselect does not work on linux

2009-05-09 Thread Michael Van Canneyt


On Sat, 9 May 2009, fpcl...@silvermono.co.za wrote:

 According to the FPC rtl.pdf version 2.2.2 Doc version 2.1 of June 2008, page 
 165, states, and I quote: Description:FPSelect checks one of the file 
 descriptors in the FDSets to see if its status changed.

I'll change it to something closer to the actual behaviour.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] fpselect does not work on linux

2009-05-09 Thread Rainer Stratmann
Select does *not* tell you if a file descriptor is writeable or readable. 
It tells you if the read/write operation will block. 
This is something subtly different.
This is interesting for blocking mode.
But since you can switch to nonblocking mode every operation will return 
immediately.

Here are some descriptions I found about select:
http://publib.boulder.ibm.com/infocenter/tpfhelp/current/index.jsp?topic=/com.ibm.ztpf-ztpfdf.doc_put.cur/gtpc2/cpp_select.html
http://docs.sun.com/app/docs/doc/816-5168/select-3c?a=view
http://www.developerweb.net/forum/showthread.php?p=13486

...The select socket function monitors a list of file descriptors for 
readability, readiness for writing, and exception pending conditions.

Of course if you are in a blocking mode then a call does not block.
...if the select call returns that what we expect.

For instance, it reports file descriptor 0 as writable, which is rather 
strange, since it
is read-only, but correct, because the write call will not block. Indeed the 
write call
will return at once with an error condition. 

This is what the kernel sees (I used strace to test your code with descriptor 
0):

select(1, NULL, [0], NULL, {0, 0})      = 1 (out [0], left {0, 0})

May be it is better to test it with sockets descriptors.
If I get a result that the call will not block (as you say) and then I write 
data to the descriptor then the program crashes with exitcode 13...

Which is exactly what I sent. 

In short, is_writable_socket should be implemented differently, not using 
select.

How can I find out if a socket connection in a nonblocking mode is 
established?

Michael.

Am Samstag, 9. Mai 2009 12:55 schrieb dmitry boyarintsev:
 hello Rainer,

 do you check the socket's writability by fpFD_ISSET(sck, fds) ?

Yes, before I did it this way, but it was the same behaviour.
Windows ok. Linux failed.

function is_writable_socket2( s : integer ; var error : longint ) : boolean;
var
  fds : tfdset;
  tv : timeval;
  valopt : longint = 1;
  vallen : {$ifdef linux} longword {$else} longint {$endif};
begin
  result := false;
  {$ifdef linux}   fpfd_zero( fds ); fpfd_set( s , fds ); {$endif}
  {$ifdef windows}   fd_zero( fds );   fd_set( s , fds ); {$endif}
  tv.tv_sec  := 0;
  tv.tv_usec := 0;
  //   socket+1 , read , write , except , timeout
  {$ifdef linux}
  if fpselect( s + 1 , nil , @fds , nil , @tv )  0 then begin
if fpfd_isset( s , fds ) = 1 then begin
  vallen := sizeof( valopt );
  if fpgetsockopt( s , sol_socket , so_error , @valopt , @vallen ) = 0 
then begin
error := valopt;
result := valopt = 0;
  end;
end;
  end;
  {$else}
  if select( s + 1 , nil , @fds , nil , @tv )  0 then begin
if fd_isset( s , fds ) then begin
  vallen := sizeof( valopt );
  if getsockopt( s , sol_socket , so_error , valopt , vallen ) = 0 then 
begin
error := valopt;
result := valopt = 0;
  end;
end;
  end;
  {$endif}
end;

 thanks,
 dmitry
 ___
 fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
 http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Rainer
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


[fpc-pascal] -Opentium3 Error

2009-05-09 Thread Lou James
Hi,
 This is a problem troubles me for a long time.You should know I'm a student
in high school and I use Free Pascal to
solve some algorithm problem.
 Sometimes,when I set a new enviroment(school's computer always clean up
after restart)--that is,to set the Properties
of the shortcut Start In : option,and type in the folder I want.
 Then,open the shortcut and type in my code.Then, when I try to compile
it,it may popup a error says something about -opentium3.
And stop compiling.The only way to correct this error seems to be that I
must open the fp.cfg file and manually delete all the -opentium3
strings in that file.

What caused the problem?
Can we avoid it?

I'm a Chinese high school student and new to this mail-list.
Thanks...



-- 
.樓洵
http://www.AquarHEAD.com http://www.aquarhead.com/
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] -Opentium3 Error

2009-05-09 Thread Jonas Maebe


On 09 May 2009, at 14:44, Lou James wrote:


Then,open the shortcut and type in my code.Then, when I try to compile
it,it may popup a error says something about -opentium3.
And stop compiling.The only way to correct this error seems to be  
that I

must open the fp.cfg file and manually delete all the -opentium3
strings in that file.

What caused the problem?


A typing error in the default configuration file of the IDE shipped  
with FPC 2.2.2



Can we avoid it?


Install FPC 2.2.4 instead.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] A question or two regarding the FPC

2009-05-09 Thread Lee Jenkins

fpcl...@silvermono.co.za wrote:

The dentist's reply was that 
this was a special version of windows specifically designed to run medical 
related critical software. Not being an offensive character, I gave him the 
benefit of the doubt. While he was attempting to start the 'tooth profiling' 


Probably Windows XP Embedded.  We use it a lot in the POS industry.

http://www.microsoft.com/windowsembedded/en-us/products/wexpe/default.mspx

--
Warm Regards,

Lee
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] -Opentium3 Error

2009-05-09 Thread Lou James
Oh,it seems so
I upgrade my fpc to 2.2.4 in the Ubuntu OS,but forgot windows.
By the way,Win7 RC is great.

2009/5/9 Jonas Maebe jonas.ma...@elis.ugent.be


 On 09 May 2009, at 14:44, Lou James wrote:

 Then,open the shortcut and type in my code.Then, when I try to compile
 it,it may popup a error says something about -opentium3.
 And stop compiling.The only way to correct this error seems to be that I
 must open the fp.cfg file and manually delete all the -opentium3
 strings in that file.

 What caused the problem?


 A typing error in the default configuration file of the IDE shipped with
 FPC 2.2.2

 Can we avoid it?


 Install FPC 2.2.4 instead.


 Jonas
 ___
 fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
 http://lists.freepascal.org/mailman/listinfo/fpc-pascal




-- 
.樓洵
.AquarHEAD
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] -Opentium3 Error

2009-05-09 Thread Joost van der Sluis
Op zaterdag 09-05-2009 om 20:44 uur [tijdzone +0800], schreef Lou James:
  Then,open the shortcut and type in my code.Then, when I try to
 compile it,it may popup a error says something about -opentium3. And
 stop compiling.The only way to correct this error seems to be that I
 must open the fp.cfg file and manually delete all the -opentium3
 strings in that file. 

iirc, this sounds as an old bug of an old version of fpc. It should be
solved in fpc 2.2.4, or maybe even fpc 2.2.2?

Joost.

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


Re: [fpc-pascal] -Opentium3 Error

2009-05-09 Thread Lord Satan
On Sat, 9 May 2009 21:02:03 +0800
Lou James aquarh...@gmail.com wrote:

 By the way,Win7 RC is great.
Yeah, and pigs can fly.

http://www.infopackets.com/news/software/windows_tips/2009/20090507_windows_7_users_warned_over_filename_security_risk.htm

http://arstechnica.com/microsoft/news/2009/05/r2e-microsoft-intel-goof-up-windows-7s-xp-mode.ars

No need to reply.
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] When is FPC 2.2.4 docs available?

2009-05-09 Thread Gabor Boros

Hi,

ftp://ftp.freepascal.org/pub/fpc/dist/2.2.4/docs

Gabor

Graeme Geldenhuys írta:

Hi,

FPC 2.2.4 has already been released a while back, but the
documentation available for download (PDF files) are rather old. Could
new docs be generated and made available for download. Not everybody
has the skills or package dependencies to generate the PDF
documentation themselves.


From the following documentation download URL:


   http://www.freepascal.org/docs.var


FCL pdf = August 2007
FPDoc pdf = August 29, 2007
Lang Ref pdf = August 2007 for FPC 2.2.0
etc...


Regards,
  - Graeme -


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


Re: [fpc-pascal] -Opentium3 Error

2009-05-09 Thread Jonas Maebe


On 09 May 2009, at 15:36, Lord Satan wrote:


On Sat, 9 May 2009 21:02:03 +0800
Lou James aquarh...@gmail.com wrote:


By the way,Win7 RC is great.

[snip]
No need to reply.


Your reply was just as unnecessary to such an aside. This sort of  
discussions are not welcome on this list.



Jonas
FPC mailing lists admin
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] -Opentium3 Error

2009-05-09 Thread Lord Satan
On Sat, 9 May 2009 16:03:35 +0200
Jonas Maebe jonas.ma...@elis.ugent.be wrote:

 Your reply was just as unnecessary to such an aside.
You are absolutely right. I sincerely apologize and will refrain myself from 
commenting on windows in the future. 

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] When is FPC 2.2.4 docs available?

2009-05-09 Thread Michael Van Canneyt


On Sat, 9 May 2009, Graeme Geldenhuys wrote:

 Hi,
 
 FPC 2.2.4 has already been released a while back, but the
 documentation available for download (PDF files) are rather old. Could
 new docs be generated and made available for download. Not everybody
 has the skills or package dependencies to generate the PDF
 documentation themselves.
 
 From the following documentation download URL:
 
http://www.freepascal.org/docs.var
 
 
 FCL pdf = August 2007
 FPDoc pdf = August 29, 2007
 Lang Ref pdf = August 2007 for FPC 2.2.0
 etc...

I updated them. 
I just unzipped them from the set that is distributed with FPC 2.2.4.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] fpselect does not work on linux

2009-05-09 Thread Michael Van Canneyt


On Sat, 9 May 2009, Rainer Stratmann wrote:

 Select does *not* tell you if a file descriptor is writeable or readable. 
 It tells you if the read/write operation will block. 
 This is something subtly different.
 This is interesting for blocking mode.
 But since you can switch to nonblocking mode every operation will return 
 immediately.

And therefor every select() call will indicate that all is OK.

 
 Here are some descriptions I found about select:
 http://publib.boulder.ibm.com/infocenter/tpfhelp/current/index.jsp?topic=/com.ibm.ztpf-ztpfdf.doc_put.cur/gtpc2/cpp_select.html
 http://docs.sun.com/app/docs/doc/816-5168/select-3c?a=view
 http://www.developerweb.net/forum/showthread.php?p=13486
 
 ...The select socket function monitors a list of file descriptors for 
 readability, readiness for writing, and exception pending conditions.

You should check what the linux manpage says. It describes the exact
behaviour.
 
 Of course if you are in a blocking mode then a call does not block.
 ...if the select call returns that what we expect.
 
 For instance, it reports file descriptor 0 as writable, which is rather 
 strange, since it
 is read-only, but correct, because the write call will not block. Indeed the 
 write call
 will return at once with an error condition. 
 
 This is what the kernel sees (I used strace to test your code with 
 descriptor 
 0):
 
 select(1, NULL, [0], NULL, {0, 0})      = 1 (out [0], left {0, 0})
 
 May be it is better to test it with sockets descriptors.
 If I get a result that the call will not block (as you say) and then I write 
 data to the descriptor then the program crashes with exitcode 13...

Yes, and this is normal: if the socket is not open, you get an error when
attempting to write to it - program exits. select() does not say anything
about that.

In each case, the call functions correctly, because it's simply passed on
to the kernel. I verified several cases.

 
 Which is exactly what I sent. 
 
 In short, is_writable_socket should be implemented differently, not using 
 select.
 
 How can I find out if a socket connection in a nonblocking mode is 
 established?

This, I don't know. 

Michael.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] When is FPC 2.2.4 docs available?

2009-05-09 Thread Graeme Geldenhuys
2009/5/9 Gabor Boros gaborbo...@yahoo.com:
 Hi,

 ftp://ftp.freepascal.org/pub/fpc/dist/2.2.4/docs

Thanks Gabor. That still leaves the documentation on the web server
outdated (the main port of call to most users). But at least now I
have the latest docs. :-)


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] A question or two regarding the FPC

2009-05-09 Thread Luca Olivetti
El Sat, 9 May 2009 10:08:50 +0200
Graeme Geldenhuys graemeg.li...@gmail.com escribió:
 On Sat, May 9, 2009 at 12:24 AM, Vinzent Höfler
 jellyfish.softw...@gmx.net wrote:
 
  Actually, you should answer one simple question for yourself: If
  your life really depended on the system, would you still trust it?
 
 In that case we should all be very worried. Many critical systems out
 there run on Windows - we as technical people know that Windows is not
 the most stable platform out there.  :-)

And many of those are written in visual basic: many years ago I saw a
job ad on a newspaper requesting visual basic programmers for
electromedical machines. I *am* worried.
Not too long ago I saw on digg a photo of a scada controlling a nuclear
plant. The scada was siemens' wincc[*]. Regardless of the fact that the
error message was just complaining about the license, and a scada isn't
actually controlling the plant, I am *very* worried.

[*]a gigantic mess with a bazillon programs and dlls that nobody on
earth could possibly know how they fit together, and with the final
program badly scattered among so many different pieces you can't
never be sure of what is doing.

-- 
Luca



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


[fpc-pascal] RTL deprecated functions

2009-05-09 Thread fpclist
Hi guys 

Are there replacements for the deprecated CreateShellArgV and FreeShellArgV 
functions and procedure that are currently defined in genfuncs.inc?

Regards
Nino

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


Re: [fpc-pascal] How to use OpenGL 2.0 fatures

2009-05-09 Thread dmitry boyarintsev
Hello Lord Satan

uses
  ...gl, glext...

...
  if not Load_GL_version_2_0 then begin
writeln('OpenGL 2.0 is not supported');
Halt;
  end;
...

Load_GL_version_2_0 function is declared at glext unit.
you should call it before calling ANY 2.0 OpenGL function.
also check out functions result, to see if an opengl driver supports
2.0 version.
ANY OS must call it (both Linux and OSX), otherwise function variables
are not initialized!


thanks,
dmitry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal