[fpc-pascal] Windows unit and SyncObjs unit clash
Hi, I've noticed this ages ago and found a work-around, but never reported it. I hit the same error again today and thought this time I would mention it. In tiOPF we have some IFDEF's for the 'Windows' unit. Some units also use the 'SyncObjs' unit for critical section handling. If 'SyncObjs' unit appears before the 'Windows' unit, our code fails to compile with a error referring to the TCriticalSection class. Does anybody know about this? Is there any permanent fix to that FPC doesn't depend on specific order in uses clause? I'm now using FPC 2.2.0, but this issue has been around since 2.0.2. [ copy ]-- C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3491,13) Error: Unknown record field identifier ENTER C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3491,18) Error: Illegal expression C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3497,15) Error: Unknown record field identifier LEAVE C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3497,20) Error: Illegal expression C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3503,13) Error: Unknown record field identifier ENTER C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3503,18) Error: Illegal expression C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3509,15) Error: Unknown record field identifier LEAVE C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3509,20) Error: Illegal expression C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3526,32) Error: Unknown record field identifier CREATE C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3532,13) Error: Unknown record field identifier FREE C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3532,17) Error: Illegal expression C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3544,13) Error: Unknown record field identifier ENTER C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3544,18) Error: Illegal expression C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3548,15) Error: Unknown record field identifier LEAVE C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3548,20) Error: Illegal expression C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3560,13) Error: Unknown record field identifier ENTER C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3560,18) Error: Illegal expression C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3564,15) Error: Unknown record field identifier LEAVE C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3564,20) Error: Illegal expression C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3569) Fatal: There were 19 errors compiling module, stopping [ end ]--- And here is an example of where the cursor lands to show the error... function TtiMultiReadExclusiveWriteSynchronizer.LockForRead: boolean; begin FCritSect.Enter; // Cursor showing error try result:= CanLockForRead; if Result then Inc(FReadCount); finally FCritSect.Leave; end; 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] Windows unit and SyncObjs unit clash
On 26/03/2008, Michael Van Canneyt [EMAIL PROTECTED] wrote: Yes, use fully qualified names. windows.tcriticalsection. syncobjs.tcriticalsection. That should work For lower level stuff, you should use TRTLCriticalSection, never TCriticalSection. It has the advantage of being portable. I'm surprised you actually use the windows unit. That is Evil(tm). The code in question is the tiOPF project which is shared with Delphi FPC users. They (Delphi users) are all out of luck with the cross-platform abilities of FPC, so we have to use what both compilers support. For Delphi, that would be the 'Windows' unit. 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] Windows unit and SyncObjs unit clash
On Wed, 26 Mar 2008, Graeme Geldenhuys wrote: Hi, I've noticed this ages ago and found a work-around, but never reported it. I hit the same error again today and thought this time I would mention it. In tiOPF we have some IFDEF's for the 'Windows' unit. Some units also use the 'SyncObjs' unit for critical section handling. If 'SyncObjs' unit appears before the 'Windows' unit, our code fails to compile with a error referring to the TCriticalSection class. Does anybody know about this? Is there any permanent fix to that FPC doesn't depend on specific order in uses clause? Yes, use fully qualified names. windows.tcriticalsection. syncobjs.tcriticalsection. For lower level stuff, you should use TRTLCriticalSection, never TCriticalSection. It has the advantage of being portable. I'm surprised you actually use the windows unit. That is Evil(tm). Michael. I'm now using FPC 2.2.0, but this issue has been around since 2.0.2. [ copy ]-- C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3491,13) Error: Unknown record field identifier ENTER C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3491,18) Error: Illegal expression C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3497,15) Error: Unknown record field identifier LEAVE C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3497,20) Error: Illegal expression C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3503,13) Error: Unknown record field identifier ENTER C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3503,18) Error: Illegal expression C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3509,15) Error: Unknown record field identifier LEAVE C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3509,20) Error: Illegal expression C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3526,32) Error: Unknown record field identifier CREATE C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3532,13) Error: Unknown record field identifier FREE C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3532,17) Error: Illegal expression C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3544,13) Error: Unknown record field identifier ENTER C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3544,18) Error: Illegal expression C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3548,15) Error: Unknown record field identifier LEAVE C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3548,20) Error: Illegal expression C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3560,13) Error: Unknown record field identifier ENTER C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3560,18) Error: Illegal expression C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3564,15) Error: Unknown record field identifier LEAVE C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3564,20) Error: Illegal expression C:\Programming\tiOPF2\Source\Core\tiUtils.pas(3569) Fatal: There were 19 errors compiling module, stopping [ end ]--- And here is an example of where the cursor lands to show the error... function TtiMultiReadExclusiveWriteSynchronizer.LockForRead: boolean; begin FCritSect.Enter; // Cursor showing error try result:= CanLockForRead; if Result then Inc(FReadCount); finally FCritSect.Leave; end; 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
Re: [fpc-pascal] Windows unit and SyncObjs unit clash
On 26/03/2008, Michael Van Canneyt [EMAIL PROTECTED] wrote: Yes, use fully qualified names. windows.tcriticalsection. syncobjs.tcriticalsection. Why doesn't Delphi compiler complain about it? A quick search revealed that Delphi's Windows.pas unit doesn't contain a TCriticalSection type definition, so why does FPC's Windows.pas unit? Why must FPC have two TCriticalSection type definitions? 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] Windows GetLastError doesn't work with threads
I hate to be obnoxious, but I posted a patch for the issue in the subject (WSAGetLastError/GetLastError is reset by the rtl when one is using threads) and I'd like some feedback (if it's the proper solution or is there a better one). http://bugs.freepascal.org/view.php?id=10205 Bye -- Luca ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows unit and SyncObjs unit clash
On Wed, 26 Mar 2008, Graeme Geldenhuys wrote: On 26/03/2008, Michael Van Canneyt [EMAIL PROTECTED] wrote: Yes, use fully qualified names. windows.tcriticalsection. syncobjs.tcriticalsection. Why doesn't Delphi compiler complain about it? A quick search revealed that Delphi's Windows.pas unit doesn't contain a TCriticalSection type definition, so why does FPC's Windows.pas unit? Why must FPC have two TCriticalSection type definitions? It was translated automatically with the h2pas tool, probably with the -t option, which prepends a T to all types. For backwards compatibility we cannot revert this. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Question on low-level functions for ttySxx
Hello,
I am currently modernizing my serial communications unit, which actually is
a OOP wrapper around IOCtrl and termio.
It currently supports the following functions:
--
functionOpen(portdev: string): boolean; // Open serial port
procedure Close; // Close serial port
functionSetComm(baud: integer; parity: char; dbits, sbits: byte): \
boolean; // Configure data format
procedure SetFlow(Flow: string); // Set Flow Control
{RTS/XON/BOTH}
functionSetBaud(bd: longint): boolean; // Set Baudrate {50/75/../115200}
functionSetParity(c: char):boolean; // Set Parity {N,E,O}
functionSetDBits(n: byte):boolean; // Set Data-Bits {5/6/7/8}
functionSetSBits(n: byte):boolean; // Set Stop-Bits {1/2}
procedure SetDTR(b: boolean); // Rise/Lower DTR
procedure SetRTS(b: boolean); // Rise/Lower RTS
procedure SetTXecho(b: boolean); // Echo sent chars locally
procedure SetRXecho(b: boolean); // Echo received char to remote
procedure DumpFlags; // Dump Flags to screen (for
debugging)
procedure send(OutString:string); // Put string into Transmit
Queue
functionrecv: string;// Read from Receive Queue
procedure DrainOutput; // Wait until all chars have
been sent
procedure FlushInBuf; // Empty Input Buffer
procedure FlushOutBuf; // Empty Output Buffer
procedure FlushBothBuf;// Empty Both Buffers
Most of this functionality will be familiar to one or the other of you,
because I took them over from the OPUS FOSSIL driver X00.SYS.
What I am actually missing are functions for monitoring data flow. Means, that
I want to be able to verify that data are really sent or received.
Currently I can only set handshaking, queue something in the sending buffer,
and then hope that the data will really go out. But I cannot differentiate
between buffer is filled and emptying slowly, or buffer is filled and nothing
goes out.
Is there a possibility to test how many bytes are in the
sending/receibing buffer? This would allow me to read from time to time
and find out this way if dataflow is active.
Thanks for any help.
Rainer
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows unit and SyncObjs unit clash
On 26/03/2008, Marco van de Voort [EMAIL PROTECTED] wrote: Hmm, didn't older (6) versions simply have this, and did synobjs get introduced later? In that case, if Delphi can break compat, so can we. I think I still have my copy of Delphi 5 lying around. If I can find it, I'll see if TCriticalSection is in that Windows unit and if SyncObjs unit existed in v5. 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] Windows unit and SyncObjs unit clash
On Wednesday 26 March 2008 08:51:53 Graeme Geldenhuys wrote: On 26/03/2008, Marco van de Voort [EMAIL PROTECTED] wrote: Hmm, didn't older (6) versions simply have this, and did synobjs get introduced later? In that case, if Delphi can break compat, so can we. I think I still have my copy of Delphi 5 lying around. If I can find it, I'll see if TCriticalSection is in that Windows unit and if SyncObjs unit existed in v5. Hi, Graeme. I've got D5 installed under Wine here, and the only thing found when grepping for tcriticalsection in the ./Source/Rtl/Win directory is the function SetCriticalSectionSpinCount. The SyncObjs unit does exist in D5. ~/.wine/drive_c/Program Files/Borland/Delphi5 $ find . -iname 'syncobj*' ./Lib/Debug/syncobjs.dcu ./Lib/syncobjs.dcu ./Source/Vcl/syncobjs.pas Best regards, Pete C. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows unit and SyncObjs unit clash
Marco van de Voort wrote: On Wed, 26 Mar 2008, Graeme Geldenhuys wrote: On 26/03/2008, Michael Van Canneyt [EMAIL PROTECTED] wrote: Yes, use fully qualified names. windows.tcriticalsection. syncobjs.tcriticalsection. Why doesn't Delphi compiler complain about it? A quick search revealed that Delphi's Windows.pas unit doesn't contain a TCriticalSection type definition, so why does FPC's Windows.pas unit? Why must FPC have two TCriticalSection type definitions? It was translated automatically with the h2pas tool, probably with the -t option, which prepends a T to all types. For backwards compatibility we cannot revert this. Hmm, didn't older (6) versions simply have this, and did synobjs get introduced later? In that case, if Delphi can break compat, so can we. D5 has Windows.TRTLCriticalSection, and SyncObjs.TCriticalSection which encapsulates a TRLTCriticalSection. -- Joao Morais ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows unit and SyncObjs unit clash
Graeme Geldenhuys wrote: For lower level stuff, you should use TRTLCriticalSection, never TCriticalSection. It has the advantage of being portable. I'm surprised you actually use the windows unit. That is Evil(tm). The code in question is the tiOPF project which is shared with Delphi FPC users. They (Delphi users) are all out of luck with the cross-platform abilities of FPC, so we have to use what both compilers support. For Delphi, that would be the 'Windows' unit. What about use uses Windows under ifndef fpc? -- Joao Morais ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows unit and SyncObjs unit clash
On 26/03/2008, Joao Morais [EMAIL PROTECTED] wrote: What about use uses Windows under ifndef fpc? That will work for some units, but not all of them. Some units reference things in Windows unit not related to Critical Section, but I am definitely going to give this a try and see how far it takes me. Thanks for the suggestion. 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] connection problem
Hi, I'm experiencing connection problems to bugs.freepascal.org and svn.freepascal.org. [EMAIL PROTECTED]:~/temp svn co http://svn.freepascal.org/FPC/svn/lazarus/trunk l svn: requerimiento PROPFIND falló en '/FPC/svn/lazarus/trunk' svn: PROPFIND de '/FPC/svn/lazarus/trunk': 405 Method Not Allowed (http://svn.freepascal.org) [EMAIL PROTECTED]:~ ping bugs.freepascal.org PING bugs.freepascal.org (x.x.x.x) 56(84) bytes of data. 64 bytes from cust198-202.dsl.versadsl.be (x.x.x.x): icmp_seq=1 ttl=40 time=358 ms 64 bytes from cust198-202.dsl.versadsl.be (x.x.x.x): icmp_seq=2 ttl=40 time=386 ms 64 bytes from cust198-202.dsl.versadsl.be (x.x.x.x): icmp_seq=3 ttl=40 time=539 ms I tried at least since monday. Given absent of reports, and the bug tracker notices in mail and CIA at IRC I suppose it's working, any idea? Jesus Reyes A. ¡Capacidad ilimitada de almacenamiento en tu correo! No te preocupes más por el espacio de tu cuenta con Correo Yahoo!: http://correo.yahoo.com.mx/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] connection problem
Hello Jesus, Wednesday, March 26, 2008, 7:55:39 PM, you wrote: JR Hi, I'm experiencing connection problems to bugs.freepascal.org and JR svn.freepascal.org. Same problem from Spain but no problem if I access (in browser mode) using a proxy located in the United States :-? Maybe it is a carrier problem :-? Using my regular link I'm unable to get http://svn.freepascal.org/feeds/fpcsvn.rss but using http://www.lockproxy.info/ ,in example, I'm able to watch it. I'm using Telefonica Data carrier. Trying to access using Ya.com carrier no problem in accessing the feed, so it looks like a Telefónica Data problem. -- Best regards, JoshyFun ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] connection problem
Hi JoshyFun, thanks for your feedback. --- JoshyFun [EMAIL PROTECTED] escribió: Hello Jesus, Wednesday, March 26, 2008, 7:55:39 PM, you wrote: JR Hi, I'm experiencing connection problems to bugs.freepascal.org and JR svn.freepascal.org. Same problem from Spain but no problem if I access (in browser mode) using a proxy located in the United States :-? Maybe it is a carrier problem :-? I asked to my ISP about this, they find effectively there is some block but not from their part, I asked if they are sure they are not blocking something and they swear they don't, so it must be something else... Using my regular link I'm unable to get http://svn.freepascal.org/feeds/fpcsvn.rss but using http://www.lockproxy.info/ ,in example, I'm able to watch it. Thanks for the hint. Jesus Reyes A. ¡Capacidad ilimitada de almacenamiento en tu correo! No te preocupes más por el espacio de tu cuenta con Correo Yahoo!: http://correo.yahoo.com.mx/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
