Recent

Recent Posts

Pages: [1] 2 3 ... 10
1
Other / Re: Interesting article about AI
« Last post by lainz on Today at 01:27:09 pm »
I think a lot of people don’t understand what programming is  :D

From me is making instructions to a machine. Translating from human language to machine code.

That can be done with assembler, with Pascal or with AI. All do the same.
2
General / Re: Who catches the Linux signals?
« Last post by Warfley on Today at 01:20:47 pm »
When SysUtils is used somehwere in the project, it registers the default error signal handlers to convert signals into exceptions. So in any project of non trivial size SysUtil will probably be used and thereby Exceptions are used

Note Signals are EXTREMELY restrictive, be very careful with them. Without knowing your code, I would already bet that you did things which are not allowed. From the POSIX Standard:
Quote
the behavior is undefined if:
  • The signal handler refers to any object other than errno with static or thread storage duration that is not a lock-free atomic object, and not a non-modifiable object (for example, string literals, objects that were defined with a const-qualified type, and objects in memory that is mapped read-only), other than by assigning a value to an object declared as volatile sig_atomic_t, unless the previous modification (if any) to the object happens before the signal handler is called and the return from the signal handler happens before the next modification (if any) to the object.
  • The signal handler calls any function defined in this standard other than one of the functions listed in 2.4 Signal Concepts.
3

Your image looks weird to me. You confused with terminology. F.e., DTR_CONTROL is the name of line (signal). It can be set to one of three states: DTR_CONTROL_DISABLE (0), DTR_CONTROL_ENABLE (1), and DTR_CONTROL_HANDSHAKE (auto switching). You have to read about RS232 control lines and flow controls, and this https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-dcb.
That is what the sniffer shows. My cunning plan is to make those routines once and forget about them. Anyway, here https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddser/ns-ntddser-_serial_handflow the listed values are SERIAL_DTR_CONTROL and SERIAL_DTR_HANDSHAKE. But I assume SERIAL_DTR_CONTROL  and SERIAL_DTR_HANDSHAKE cannot both be equal to zero at the same time.


Your help worked, I have now:


Code: Pascal  [Select][+][-]
  1. procedure SetHandFlow(HandFlow: THandFlow; var aLazSerial: TLazSerial);
  2. begin
  3.   with aLazSerial.SynSer.DCB do
  4.   begin
  5.     Flags := dcb_Binary; //$00000001;
  6.     case HandFlow of
  7.       hfNone    : Flags := Flags and not dcb_RtsControlEnable;
  8.       hfXonXoff : begin Flags := Flags or dcb_OutX or dcb_InX; Flags := Flags or dcb_DtrControlEnable; end;
  9.       hfDTR_DSR : Flags := Flags or dcb_DtrControlEnable;
  10.       hfRTS_CTS : Flags := Flags or dcb_OutxCtsFlow or dcb_RtsControlHandshake; //aka Hardware
  11.       hfXonXoff_and_RTS_CTS : begin Flags := Flags or dcb_OutX or dcb_InX; Flags := Flags or dcb_DtrControlEnable; Flags := Flags or dcb_OutxCtsFlow or dcb_RtsControlHandshake; end;
  12.       hfXonXoff_and_DTR_DSR : begin Flags := Flags or dcb_DtrControlHandshake or dcb_OutxDsrFlow or dcb_OutX or dcb_InX or dcb_RtsControlToggle; Flags := Flags and not dcb_RtsControlHandshake; end;
  13.     end; //case
  14.   end; //with
  15.   aLazSerial.SynSer.SetCommState;
  16. end;
  17.  
   




But it seems that everyone has a different idea about what DTR/DSR shall be.
I sniffed several terminal apps, two of them set it as:
SERIAL_DTR_HANDSHAKE = 1; SERIAL_DSR_HANDSHAKE =1; SERIAL_RTS_CONTROL = 1; everything else = 0.


One of them sets different values each time.
And another one sets SERIAL_DTR_CONTROL = 1; SERIAL_CTS_HANDSHAKE = 1; everything else = 0.


In order to connect to the multimeter I need SERIAL_DTR_CONTROL = 1; SERIAL_CTS_HANDSHAKE = *; everything else = 0;
Most terminal apps do not have this mode (once is named DTR/DSR, once is RS485, the multimeter is actually a regular RS232 on 9V).
4
General / Program running on after exiting Lazarus
« Last post by jollytall on Today at 12:31:55 pm »
I have another problem https://forum.lazarus.freepascal.org/index.php/topic,69558.0.html and to test that I wrote a small command line program. If I run it in a terminal then it ends up in an infinite error loop (it is interesting in itself why a loop when the whole program is linear - see there). So, if I kill it with Ctrl-C it stops.
However if I run it from Lazarus (without debugging) the error is not shown in the terminal window (CtrlAlt-O) and it seems that the program ended. I can even normally exit Lazarus.
However the program runs in the background on and as it is an infinite loop of errors it generates lot os entries in the syslog and in the user log. As you do not notice that the program is still running (it has no terminal, nothing) and it does not end when the mother process (Lazarus) exits, it can just eat disk space slowly.
So, after a while I got a disk full error and a system crash.

Is it a bug somewhere or is it normal behavior?
5
General / Re: Who catches the Linux signals?
« Last post by jollytall on Today at 12:25:55 pm »
Ooops... The real disaster came after. I got a disk full error. See my other post regarding this.
6
General / Re: Who catches the Linux signals?
« Last post by jollytall on Today at 12:16:30 pm »
So, I made a thorough test. The following things were mentioened: GUI or not GUI, Is there a try..except structure or not, SysUtils is added to the uses or not, fpSignal is defined or not. It gave me 16 combinations. I used the following two programs (with commenting out the parts not needed for a test:
Code: Pascal  [Select][+][-]
  1. program projectt;
  2.  
  3. uses
  4.   BaseUnix
  5.   , SysUtils
  6.   ;
  7. procedure signal_callback_handler(signum : integer); cdecl;
  8.   begin
  9.   Writeln('Signal caught ', SigNum);
  10.   end;
  11.  
  12. var
  13.   a, b, c : double;
  14.  
  15. begin
  16. fpsignal(SIGFPE, SignalHandler(@signal_callback_handler));
  17. a := 1;
  18. b := 0;
  19. try
  20.   c := a / b;
  21. except
  22.   Writeln('Except caught');
  23.   end;
  24. Writeln(c);
  25. Readln;
  26. end.
and
Code: Pascal  [Select][+][-]
  1. unit Unit1;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5. interface
  6.  
  7. uses
  8.     BaseUnix, Classes,
  9.     SysUtils,
  10.     Forms, Controls, Graphics, Dialogs, StdCtrls;
  11.  
  12. type
  13.  
  14.   { TForm1 }
  15.  
  16.   TForm1 = class( TForm)
  17.     Button1 : TButton;
  18.     LabelFinish : TLabel;
  19.     LabelC : TLabel;
  20.     LabelExcept : TLabel;
  21.     LabelSignal : TLabel;
  22.     procedure Button1Click( Sender : TObject);
  23.   end;
  24.  
  25. var
  26.   Form1 : TForm1;
  27.  
  28. implementation
  29.  
  30. {$R *.lfm}
  31.  
  32. procedure signal_callback_handler(signum : integer); cdecl;
  33.   begin
  34.   Form1.LabelSignal.Caption := 'Signal caught';
  35.   end;
  36.  
  37.  
  38. { TForm1 }
  39.  
  40. procedure TForm1. Button1Click( Sender : TObject);
  41.   var
  42.     a, b, c : double;
  43.   begin
  44.   fpsignal(SIGFPE, SignalHandler(@signal_callback_handler));
  45.   a := 1;
  46.   b := 0;
  47.   try
  48.     c := a / b;
  49.   except
  50.     LabelExcept.Caption := 'Except caught';
  51.     end;
  52.   if C = 1 then
  53.     LabelC.Caption := 'LabelC reached';
  54.   LabelFinish.Caption := 'LabelFinish reached';
  55.   end;
  56. end.
  57.  

I got the following results:
Code: [Select]
GUI Try     SysU fps Result
No No No No Runtime error 208
No No No Yes Infinite loop with SigNum 8
No No Yes No Unhandled exception Div0
No No Yes Yes Infinite loop with SigNum 8
No Yes No No Except catches properly
No Yes No Yes Infinite loop with SigNum 8
No Yes Yes No Except catches properly
No Yes Yes Yes Infinite loop with SigNum 8
Yes No No No Finishes, No Signal, No Except, No Error
Yes No No Yes Finishes, No Signal, No Except, No Error
Yes No Yes No Finishes, No Signal, No Except, No Error
Yes No Yes Yes Finishes, No Signal, No Except, No Error
Yes Yes No No Finishes, No Signal, No Except, No Error
Yes Yes No Yes Finishes, No Signal, No Except, No Error
Yes Yes Yes No Finishes, No Signal, No Except, No Error
Yes Yes Yes Yes Finishes, No Signal, No Except, No Error

- So if it is a GUI application, nothing matters. I find it very strange, however as my program is command line, it was not part of the original question. Still, does it mean that in Linux a GUI can never detect anyway a Div0 (or other serious) error? (8 cases covered)
- From the remaining 8 command line versions, if the fpSignal is set then regardless of the other two settings, it always ended up in an infinite loop. Again, I do not understand. At what point does it turn back in code and starts running again (i.e. a loop)? (4 more cases covered)
- If fpSignal is not set, but the try..except is set, then it is captured by the Except. The difference between SysUtils added or not is whether
Code: Pascal  [Select][+][-]
  1. On E:Exception Do
can be used or not. This is as expected. (2 cases covered).
- If not even try..except is switched on then the program crashes. If SysUtil is not added the with a RunTime error 8 (I guess it is the OS Code), while if SysUtils is added then it catches it, coverts it to text and then crashes with unhandled Div0 error. Again this is as expected. (the last 2 cases covered).

So after all it seems that GUI overwrites everything, then it a command line program fpSignal overwrites everything, and SysUtils and try..except is only used otherwise. What bothers me now are the GUI and the infinite loop of fpSignal.
7
Other / Re: had a question and found answer
« Last post by Joanna from IRC on Today at 12:02:14 pm »
I once helped someone solve a programming problem which I knew nothing about simply by encouraging them to talk about it.  :D
Was there a couch involved?   :P
No couch involved, it was Back on freenode  ;)
8
Other / Re: Interesting article about AI
« Last post by Joanna from IRC on Today at 11:59:30 am »
I think a lot of people don’t understand what programming is  :D
9
Other / Re: Interesting article about AI
« Last post by VisualLab on Today at 11:55:42 am »
The day that thing can figure out a shorter (and correct) proof to Fermat's last theorem entirely by itself, that day there will be something to be concerned about.

Exactly. And it probably won't end as positively as in Lem's book "Golem XIV" (this can be considered a positive ending for people).
10
Other / Re: Interesting article about AI
« Last post by Joanna from IRC on Today at 11:54:35 am »
This is where we start to delve into a philosophical discussion. Why do you think it’s so important to just strive for “productivity” at all costs. Historically there was competition over resources and those who advanced their population and technology the fastest had the best chance of winning wars and plundering everyone they could defeat.

What price are we willing to pay for increased productivity? Would it be ok to eliminate all superfluous members of the population? That would certainly increase productivity. What benefits does “increased productivity” is it really necessary to replace all possible jobs with substandard bots.

It’s a well known fact that modern life is not making the majority of the population happier and healthier. Many people are lonely/isolated and/or working long hours under stressful conditions. Endlessly pursuing materialistic goals. Modern so called food is Often full of weird substances which can hardly be pronounced.

I don’t think most people could ever benefit from stuffing AI Into everything possible. Based upon history it will benefit very few people who want to get rich by cutting costs. AI squanders resources which could be better used elsewhere.
Pages: [1] 2 3 ... 10

TinyPortal © 2005-2018