Re: [fpc-pascal] Parse unicode scalar
El 03/07/2023 a las 10:27, Hairy Pixels via fpc-pascal escribió: Right now I've just read the file into an AnsiString and indexing assuming a fixed character size, which breaks of course if non-1 byte characters exist I also need to know if I come across something like \u1F496 I need to convert that to a unicode character. Hello, You are intermixing a lot of concepts, ASCII, Unicode, grapheme, representation, content, etc... Talking about Unicode you must forget ASCII, the text is a sequence of bytes which are encoded in a special format (UTF-8, UTF-16, UTF-32,...) and that must be represented in screen using Unicode representation rules, which are not the same as ASCII. Just to keep this message quite short, think in a text with only one "letter": "á" This text (text, not one letter, Unicode is about texts) can be transmitted or stored using Unicode encoding rules which are a sequence of bytes with its own rules to encode the information. Each byte is hexadecimal: UTF8: C3 A1 UTF16LE: 00 E1 UTF32: 00 00 00 E1 You must know in advance the encoding format to get the text from the bytes sequence. There is also a BOM (Byte Order Mark) which is sometimes used in files as a header to indicate the encoding, but in general it is not used. Now decoding that sequence of bytes, using the right decoding format you get a text which represent the letter "a" with an acute accent, but Unicode is *not* so *simple* and the same text could be represented in screen using letter "a" + "combining acute accent" and bytes sequence is totally different, different at encoding level but identical at renderization level. So this two UTF8 sequences: "C3 A1" and "61 CC 81" are different at grapheme level and encoding level but identical at representation level. Just as final note, this is the UTF-8 sequence of bytes for one single "character" in screen: F0 9F 8F B4 F3 A0 81 A7 F3 A0 81 A2 F3 A0 81 B3 F3 A0 81 A3 F3 A0 81 B4 F3 A0 81 BF Unicode is far, far from easy. Have a nice day. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] SetFileTime
El 03/05/2023 a las 8:48, Carsten Bager via fpc-pascal escribió: > I am trying to change the file date on a SYMLINK (not the file that the > link points to). > Does anyone know if there is a method for this under Windows. > Carsten Hello, Attached is a dirty implementation of "touch" for junctions that I need in the past. I think it can help you to do the same over other kind of links. Have a nice day. program touchjunction; {$mode objfpc}{$H+} uses {$IFDEF UNIX}{$IFDEF UseCThreads} cthreads, {$ENDIF}{$ENDIF} Classes, SysUtils, windows, CustApp { you can add units after this }; const FILE_FLAG_OPEN_REPARSE_POINT=DWORD($0020); FileTimeBase = -109205.0; FileTimeStep: Extended = 24.0 * 60.0 * 60.0 * 1000.0 * 1000.0 * 10.0; // 100 nSek per Day type { TTouchJunction } TTouchJunction = class(TCustomApplication) protected procedure DoRun; override; function DateTimeToFileTime(DateTime: TDateTime): TFileTime; public constructor Create(TheOwner: TComponent); override; destructor Destroy; override; procedure WriteHelp; virtual; end; { TTouchJunction } function TTouchJunction.DateTimeToFileTime(DateTime: TDateTime): TFileTime; var sysTime: TSYSTEMTIME; temp: TFILETIME; begin DateTimeToSystemTime(DateTime,sysTime); SystemTimeToFileTime(@sysTime,@temp); LocalFileTimeToFileTime(@temp,@result); end; procedure TTouchJunction.DoRun; var ErrorMsg: String; TheDate,TheTime: string; TheFile: UTF8String; TheFileW: WideString; ParamList: TStringList=nil; TheHandle: THandle=INVALID_HANDLE_VALUE; FT: TFormatSettings; TheFileModify: TDateTime; lCreationTime, lAccessTime, lModificationTime: FILETIME; Arroba: Boolean=false; F: TFileStream; B: String; U: UnicodeString; begin // quick check parameters ErrorMsg:=CheckOptions('h', 'help'); if ErrorMsg<>'' then begin ShowException(Exception.Create(ErrorMsg)); Terminate; Exit; end; // parse parameters if HasOption('h', 'help') then begin WriteHelp; Terminate; Exit; end; if ParamCount=0 then begin WriteHelp; Terminate; Exit; end; { add your program here } TheFile:=ParamStr(1); TheDate:=ParamStr(2); TheTime:=ParamStr(3); if TheFile<>'' then begin if TheFile[1]='"' then begin TheFile:=copy(TheFile,2); end; if TheFile[1]='@' then begin TheFile:=copy(TheFile,2); Arroba:=true; end; if TheFile[1]='"' then begin TheFile:=copy(TheFile,2); end; if TheFile[length(TheFile)]='"' then begin TheFile:=copy(TheFile,1,Length(TheFile)-1); end; if Arroba then begin if not FileExists(TheFile) then begin writeln('File "',TheFile,'" does not exists.'); Terminate(1); exit; end; //Each line is a parameter //so //Junction Name //2020-01-01 //19:23:00 ParamList:=TStringList.Create; try F:=TFileStream.Create(TheFile,fmOpenRead or fmShareDenyNone); SetLength(B,F.Size); F.Read(B[1],F.Size); FreeAndNil(F); ParamList.Text:=B; TheFile:=Utf8String(Utf8decode(ParamList[0])); TheDate:=ParamList[1]; TheTime:=ParamList[2]; finally FreeAndNil(ParamList); end; end; end; FT:=DefaultFormatSettings; FT.DateSeparator:='-'; FT.LongDateFormat:='-MM-DD'; FT.ShortDateFormat:='-MM-DD HH:mm:SS'; TheFileModify:=StrToDateTime(TheDate+' '+TheTime,FT); TheFileW:=WideString(TheFile); TheHandle:=CreateFileW(@TheFileW[1], GENERIC_READ or GENERIC_WRITE, FILE_SHARE_READ or FILE_SHARE_WRITE, Nil, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS or FILE_FLAG_OPEN_REPARSE_POINT or FILE_ATTRIBUTE_REPARSE_POINT, INVALID_HANDLE_VALUE); if TheHandle<>INVALID_HANDLE_VALUE then begin if GetFileTime(TheHandle,@lCreationTime,@lAccessTime,@lModificationTime) then begin lModificationTime:=DateTimeToFileTime(TheFileModify); if not SetFileTime(TheHandle,lCreationTime,lAccessTime,lModificationTime) then begin writeln('SetFileTime Last Error: ',GetLastError()); CloseHandle(TheHandle); Terminate(3); exit; end else begin CloseHandle(TheHandle); writeln ('Touched "'+TheFile+'" with '+DateTimeToStr(TheFileModify)); Terminate(0); exit; end; end else begin writeln('GetFileTime Last Error: ',GetLastError()); Terminate(2); exit; end; end else begin writeln('CreateFileW Last Error: ',GetLastError()); Terminate(5); exit; end; // stop program loop Terminate(0); end; constructor TTouchJunction.Create(TheOwner: TComponent); begin inherited Create(TheOwner); StopOnException:=True; end; destructor TTouchJunction.Destroy; begin inherited Destroy; end; procedure TTouchJunction.WriteHelp; begin {
Re: [fpc-pascal] RTLEventWaitFor
El 05/04/2022 a las 1:03, Mattias Gaertner via fpc-pascal escribió: Hi Michael, Under Linux a RTLEventWaitFor(e,1) usually waits at most 1ms. But under Windows it usually waits at least 15ms. It seems to round to nearest 1/64 of a second. Googling this lead me to question the sanity of some bloggers. Has anyone an idea if this is normal on Windows and if there is an alternative? Mattias Hello, On Windows the timer resolution is 1/64, that's 15,6 ms. You can change it by using "NtSetTimerResolution" but it is system wide and other programs can fail or have strange behaviour. MS recommends to not change it, but some programs like Chrome do it for some chuncks of time. You can check the 15.6 ms using a tight loop of GetTickCount. Have a nice day. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reading Serial Hex Data
El 28/12/2020 a las 2:02, James Richters via fpc-pascal escribió: I think I figured out why my writeln's are causing an issue.. they are introducing a delay between the SerWrite and SerRead... and the device I am reading is timing out and sending it's response a second time. Hello, None of the serial devices I have seen do something like that, in fact usually they do exactly the opposite, fire and forget, or in other words send a message and do not check for errors unless they wait for an answer from the host. Your problem seems to be or a documentation misinterpretation or the connection or the device is not using any kind of flow control. I was under the impression that there was a hardware buffer on the serial ports, my packets are very small, some only a few bytes, but even those are not going into any kind of a hardware buffer. Hardware buffers in serial device is 16 bytes (In fact 14 for receive) at most and it is managed by the Windows serial driver to garantee no byte is lost. The operation scheme is something like: 1- Serial byte received 2- IRQ signal issued 3- Windows serial driver read serial port and copy byte(s) to driver buffer. 4- Signal IRQ as handled. The 16 bytes hardware (FIFO) buffer is present to garantee that if steps between 2 and 4 takes too much time (this is time scaled in 1990's CPU power) no byte is lost. If an Intel 8088 can read 115200bps without any byte lost think what a today computer can read. In order to perform tests there are programs where you create an hex string to be sent and inspect the answer from the device. Read documentation about how to open the port, specially about the flow control sync. XOn/XOff, RTS/CTS. In example some need that you raise the RTS line and wait for CTS line to be high before write, if you do not wait the device can misinterpret your request and hang or answer something stupid, this is automatically done by the Windows serial driver if you select the RTS/CTS flow control when open the port. Have a nice 2021! -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 3.2fixes UTF8Decode strange place
El 01/11/2020 a las 20:36, AlexeyT via fpc-pascal escribió: @/José Mejuto, can you pls simplify this place, ie remove "if /IBYTE = 10" + then/else. Hello, I don't have write access, so no, I can not. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 3.2fixes UTF8Decode strange place
El 27/10/2020 a las 21:25, AlexeyT via fpc-pascal escribió: rtl/inc/ustrings.inc function UTF8ToUnicode(Dest: PUnicodeChar; MaxDestChars: SizeUInt; Source: PChar; SourceBytes: SizeUInt): SizeUInt; a) it has "If (PreChar<>13) and FALSE then" and later some big block. with a comment which tells that "and FALSE" is on purpose and block is ignored. ? b) after I removed "that block" I got such trimmed src Hello, As the author of that piece of code, UTF8 recommends expanding LF line endings to CR+LF but this will generate some troubles and to try to 100% conform the spec. the conversion has been added, but disabled so code maintainers can easily remove them if needed. If you remove the piece of code about #13 you can safely remove the check about #10 which is now nonsense so you end with: --- while (OutputUnicodehttps://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
El 16/08/2019 a las 20:45, James Richters escribió: Jose, Can you tell me which relays work with your project at: https://github.com/JoshyFun/VUSBRelayPascal ? "spam" sent by private. I have inputs from my device working but not outputs, I think it would be helpful for me to learn how to output to anything as a stepping stone... and actually USB relays sound like fun. Hello, In the case of USB relays you must invoke a "GetReport" with ReportID = 0 and you get a bitmasked state in 8 bytes of data. To activate and deactivate the code invoke a "SetReport" in the same way. Without a proper API description it could be really hard to implement you hardware :-( -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] where to find materials about MP3 file format
El 15/08/2019 a las 11:04, George Bakhtadze escribió: mp3 is a loosy audio format. It means that some part of information is lost while encoding. So doing a decoding/encoding cycle just to remove some piece of file is a bad idea. I'd try to find a way to remove piece of audio data without decompressing the file similar to lossless operations on JPEG files. Hello, As JPEG only have limited operations without decompressing (limited rotation and limited cropping), mp3 also have limited operations without decompressing, in this case only frame volume change. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
El 15/08/2019 a las 15:11, James Richters escribió: Yes, in device manager I see it listed as "HID-compliant vendor-defined device" also Zadig identifies it as "USB Input Device" and it shows Driver: HidUsb (v10.1.17763.1) Is there a way to use the windows system HID interface with FPC already in place as there is for other windows APIs? Hello, You can find a HID interface for windows at: https://libstock.mikroe.com/projects/view/528/usb-hid-dll-for-delphi-and-perhaps-other-languages In the "Basic" package. Anyway, if possible, the use of libusb-1.0 is recommended as it will give you crossplatform support. You can check my project to see how devices are enumerated, based in the libusb-1.0 function calls. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] where to find materials about MP3 file format
El 14/08/2019 a las 22:23, Mgr. Janusz Chmiel escribió: I have A very big and non easy dream. Making similar MP3 editor like MP3 direct cut for Windows is. But sure! [...] operations to assign beginning of block and its end. And mainly, I want to use remove block command, which will hae immediate effect. So MP3 [...] Who of us would have some tip how to find MP3 file format technical specifications? Hello, There are several documents about the MP3 format, but you only need for sure ID3V1, ID3V2 and MP3 frame format. You need ID3V1 and ID3V2 in order to skip this information (if you will not use it, as it is metadata only) and the MP3 frame format if you want to fast scan MP3 time duration and scan for stream errors. https://www.mp3-tech.org/programmer/frame_header.html All other operations should be done with decompressed audio and in this situation nothing is different from MP3, WAV, AAC, OGG, etc. There are only a few operations that you can apply to a MP3 stream without decompressing it, mainly volume change, as you can not, in example, remove a block directly from the MP3 stream even if the block is an MP3 frame because each frame is dependent of previous frames and if you remove one an audible "bleep" can happen (high chance). So you only need something to decompress MP3 (and maybe other formats). -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
El 14/08/2019 a las 16:29, James Richters escribió: I'll have a look at your project.. maybe it will give me some clues. Can you tell me how to get hid.dll? I find it all very confusing, can I just download the dll somewhere or do I have to get this huge confusing package and built it myself? The sample code that is able to access my device with python on Linux uses hid.dll I would like to at least be able to try the hid.dll... if I can get hid.dll somewhere. Hello, hid.dll is the windows system HID interface, the API provided by Windows. In the other hand, the hardware you are trying to manage is 10CE:EB93 ? Yes, I got a listing of all devices, then I plugged in the new one, and that is the ID that was not there before. If the answer is yes, that device is *not* HID compatible so you can not use hid.dll for native access, you must use WinUSB API set, or the libusb-1.0 abstraction layer. I'm curious how you can tell that by looking at the number of it? No, I just look for the product and try to find its drivers, no one name the HID interface. Do you see the device in windows device manager under the HID section "Human Interface Devices (HID)" ? -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
El 14/08/2019 a las 1:41, James Richters escribió: I wonder if HID devices will work at all on Windows the same as they do on Linux. I have not been able to get the HID part of the python code to work on windows yet either because the instructions given to install the packages needed Hello, HID devices works in the same way, you need a device driver for the hardware that exposes a HID interface and you can manage that HID interface using native hid.dll or use an abstraction layer like libusb-1.0. https://github.com/JoshyFun/VUSBRelayPascal My code to manage HID USB relays uses hid.dll (32 & 64 bits) or libusb-1.0 (32 bits only tested) on Windows, and libusb-1.0 or libusb-0.1 in Linux. Of course, functions on hid.dll and libusb are no the same, they work in different way, but the libusb-1.0 works the same way in both platforms. Implementation of hid.dll, libusb, etc, in my code only have relevant functions used in USB relays, so they can not used as a complete implementation. In the other hand, the hardware you are trying to manage is 10CE:EB93 ? If the answer is yes, that device is *not* HID compatible so you can not use hid.dll for native access, you must use WinUSB API set, or the libusb-1.0 abstraction layer. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
El 26/07/2019 a las 12:39, James Richters escribió: Anyone have any suggestions for an FPC only console application method or demo I could use to access this USB HID device? Hello, This is not a complete HID interface but it can help you to start working with them. It has been designed to handle USB Relays which are managed using HID interface. Demos with and without GUI. https://github.com/JoshyFun/VUSBRelayPascal -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MD5 Hash of StringList
El 04/07/2019 a las 18:13, James Richters escribió: Thanks you! That got me on the right path. Here's the working sample: Hash := Md5Print(MD5String(MyStringlist.Text)); Warning! That's platform dependent code due the new line sequences. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Public key algo pascal only
El 08/04/2019 a las 11:49, Santiago A. escribió: There is no simple solution for a complex problem. RSA implies a lot of backend: several symmetric ciphers (AES, Blowfish..., that are complex by their own. You don't want to use Caesar cypher), acceptable random generator, big integer arithmetic, prime numbers, several hash algorithms. And the library is leaving aside all PKI stuff: certificates, authorities etc. And forget about memory protection etc I think it is a minimal RSA lib. In fact, maybe it's too simple. As far as I've seen it only has MD5 and SHA1 hash algorithms, many environments require at least sha256. But if it is only for internal use (you are in charge of both ends of communication) and not for critical top secret, it could be enough. I don't think you will find anything much more simpler. Hello, For serious stuff complex libraries are needed, I know, but in this case a simple algo like a XOR (if it was a public/private key one) would be enough. The only requirement is that the "client" can not generate easily commands so the generation key must not be compiled in the code. It is not a security algo, it's more like make it difficult and nothing more, no real security is broken if the choose code is broken. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Public key algo pascal only
El 07/04/2019 a las 8:22, Jy V escribió: Give a look at Crypto.pas in Ultibo project at github, from memory it requires very few other pascal unit (and of course no external library or obscure binary code) I also know that XMLRAD is sharing similar feature in unit XCrypto.pas, the project is hosted at SourceForge (and still of course no external library or obscure binary code). Hello, Thank you, I'll put an eye on both of them. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Public key algo pascal only
El 05/04/2019 a las 19:08, Виктор Матузенко escribió: Hi, try this https://github.com/delphi-pascal-archive/Pascal-RSA Hello, Thank you. It is a bit "monster" but maybe I can split the necessary code. Thank you again. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Public key algo pascal only
El 05/04/2019 a las 13:01, Michael Van Canneyt escribió: Maybe DCrypt has the necessary routines, Graeme Geldenhuys maintains a version that works with FPC. Hello, Thank you, I have code from DCrypt but I was looking for something much more simple which can generate the keys/certificates and handle all operations or at least sign/check-sign, even a 32 bits algo would be valid :-) Anyway thank you, your answer confirms my suspects. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Public key algo pascal only
Hello, Is there any public/private key algorithm, pascal only, implemented in the distribution of fpc ? Degree of security is not important, also a 3rd party unit which does not depends on a DLL or depends on another software to generate key pairs, or other tasks, would be valid too. Thank you. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpPDF and support of Latin2 charset
El 19/03/2019 a las 15:00, LacaK escribió: It seems that there is problem specific to CourierNew font (cour.ttf). With Arial (arial.ttf) it works as expected. Attached program which demonstrates problem. Hello, Can you send me by direct mail the pdf result for that program ? I´ll try to spot the differences. The name "CourierNew" while the TTF name is "Courier New" may force a typographic fallback to a standard font. PDF font handling is a mess, design patch over patch, several ways to render the same glyphs, ... It's almost incredible that a program can render successfully any document :-) -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Embedding DLL into EXE for Windows 32 bit?
El 07/07/2018 a las 11:01, Bo Berglund escribió: 1) Include the DLL as a resource and extract it to a temp location before loading it I have seen these suggestions but the comments indicated that writing a binary file to the filesystem on startup and then calling stuff inside likely will trigger antivirus detection... See: http://www.delphipages.com/forum/showthread.php?t=216147 Hello, This behavior raises a warning in the antivirus for sure. Not a good choice. This I don't understand, it does not look like they have embedded the dll into the application at all... In the example both tests use the same code to load the dll from the file system: ms := TMemoryStream.Create; ms.LoadFromFile(ParamStr(1)); (Paramstr(1) is the required DLL path) It uses a memory stream, no disk is touched, but in the example, for simplicity, it reads the DLL from disk instead a resource in the EXE. I found another MemoryModule at GitHub named BTMemoryModule: https://github.com/nedich/memorymodule But it too looks rather involved, and is pretty old... In my Delphi times I was using it with good results. I was trying to port it to FPC but drop the attempt. Anyway, using a DLL only complicates the distribution. Security is the same as an OBJ file, a hacker can not simply replace the DLL with an empty stub as some operations must be performed in the dongle which are verified in the main code, the DLL is just a tunnel between application and dongle. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to list USB devices on Windows?
El 28/06/2018 a las 13:44, Marco van de Voort escribió: I hesitate calling it public domain, but the code snippets I collect are exactly that, visible for everyone, from postings on forums and the like. JVCL also has such code. I use it to get descriptive names for usb serials. Hello, Maybe this code may help browsing USB HIDs across platforms: https://github.com/JoshyFun/VUSBRelayPascal -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpsockets
El 30/10/2017 a las 15:40, Victor Campillo escribió: You have the function "FpIOCtl" with the option FIONREAD, I use it to read the amount of data of the reception buffer before call "fprecv" but if I remember correctly this only work when you configure the socket as asynchronous. Hello, fpioctl seems to not be implemented in Windows, but anyway your help give me a clue about a possible solution to my problem. Thank you. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] fpsockets
Hello, Do exists any way using the fpsockets family to know if a "fprecv" will block ? In other words do exists a call that return the amount of bytes that are ready to be read/received ? In the case the answer is no, does fpc has another family of socket functions ? I know synapse, lNet, ... but I wish to use only fpc packages. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] {$DEFINE DEVEL}
El 11/10/2017 a las 11:00, pasc...@piments.com escribió: {$DEFINE DEVEL} Can anyone suggest a similar one key trick ? Hello, I'm using {.$DEFINE DEVEL} -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Using Serial in a TCP/RS232 gateway, how to set buffer sizes?
El 06/09/2017 a las 21:22, Bo Berglund escribió: Inc(RxTcp, Length(Buf)); SerWrite(FComH, Buf[0], Length(Buf)); Inc(TxSer, Length(Buf)); Where could I be losing incoming serial data? Hello, Where do you check that "Length(Buf)" has been sent ? if SerWrite(FComH, Buf[0], Length(Buf))<>Length(Buf) then Raise Exception.Create("KBOOM"); -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] SVN RSS
El 26/07/2017 a las 0:37, Andrew Haines via fpc-pascal escribió: If you only want to see commits in a feed you can use this link to the unofficial github mirror: https://github.com/graemeg/freepascal/commits/master.atom It's synced every 15 minutes. Thank you :-) -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] SVN RSS
El 25/07/2017 a las 8:33, Michael Van Canneyt escribió: Is it possible that the SVN RSS is stuck at day 21 ? https://svn.freepascal.org/feeds/fpcsvn.rss Yes. The post-commit script that creates the feed has been disabled due to time-out problems. Hello, Will it be re-enabled ? -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] SVN RSS
Hello, Is it possible that the SVN RSS is stuck at day 21 ? https://svn.freepascal.org/feeds/fpcsvn.rss -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] for loops performance problems?
El 04/07/2017 a las 11:09, Anthony Walter escribió: I can convert to static buffers and get good performance (if I know the text isn't changing), but I'm now curious if this specific performance issue is related to fpc's for loop code generation. What do you think? Hello, AFAIK the problem was/is some floating point maths not loops, and the partial/full SSA missing in fpc. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Serial to TCP gateway in FPC?
El 29/06/2017 a las 10:39, Bo Berglund escribió: 3) I also noted in the comments in TurSeriale.pas: "The Windows port driver does receive callbacks in chunks that are typically 8 bytes long. With ReceiveMode = rmRAW, TSeriale will simply pass this chunks on to the application without any processing." Does this mean that if a single character is received it is not passed along? My protocol is exchanging single bytes for state changes and Hello, I'm quite sure no, it means that the driver will try to queue 8 bytes before sending back data, but the tricky word is "try", probably after a context switch or similar the available data will be reported by the driver whichever the amount of bytes are. Kernel to userland data pass is very expensive so drivers usually try to queue a data amount limit or a data time limit whichever it happens first. Also forget the usual 15 bytes buffering in serial comms, it is expected that the kernel driver can buffer much more data before overflow, probably around 8 Kbs. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing AggPas with PtcGraph
El 28/06/2017 a las 23:50, James Richters escribió: The two color schemes are nothing alike. 16bit is using this RGB565 format, but 8bit colors (at least the version I was using) the colors have no real relation to their bits (see thishttps://pasteboard.co/2K38l6Gk1.png) I can't figure out any pattern to this at all and while some colors I can figure out, others would be quite difficult. Hello, Your palette looks like standard Int Mode 13h VGA palette (yes, I'm older). This are the RGB values (I'm quite sure): palette[ 0] = rgb( 0, 0, 0) palette[ 1] = rgb( 0, 0,170) palette[ 2] = rgb( 0,170, 0) palette[ 3] = rgb( 0,170,170) palette[ 4] = rgb(170, 0, 0) palette[ 5] = rgb(170, 0,170) palette[ 6] = rgb(170, 85, 0) palette[ 7] = rgb(170,170,170) palette[ 8] = rgb( 85, 85, 85) palette[ 9] = rgb( 85, 85,255) palette[ 10] = rgb( 85,255, 85) palette[ 11] = rgb( 85,255,255) palette[ 12] = rgb(255, 85, 85) palette[ 13] = rgb(255, 85,255) palette[ 14] = rgb(255,255, 85) palette[ 15] = rgb(255,255,255) palette[ 16] = rgb( 0, 0, 0) palette[ 17] = rgb( 20, 20, 20) palette[ 18] = rgb( 32, 32, 32) palette[ 19] = rgb( 44, 44, 44) palette[ 20] = rgb( 56, 56, 56) palette[ 21] = rgb( 68, 68, 68) palette[ 22] = rgb( 80, 80, 80) palette[ 23] = rgb( 97, 97, 97) palette[ 24] = rgb(113,113,113) palette[ 25] = rgb(129,129,129) palette[ 26] = rgb(145,145,145) palette[ 27] = rgb(161,161,161) palette[ 28] = rgb(182,182,182) palette[ 29] = rgb(202,202,202) palette[ 30] = rgb(226,226,226) palette[ 31] = rgb(255,255,255) palette[ 32] = rgb( 0, 0,255) palette[ 33] = rgb( 64, 0,255) palette[ 34] = rgb(125, 0,255) palette[ 35] = rgb(190, 0,255) palette[ 36] = rgb(255, 0,255) palette[ 37] = rgb(255, 0,190) palette[ 38] = rgb(255, 0,125) palette[ 39] = rgb(255, 0, 64) palette[ 40] = rgb(255, 0, 0) palette[ 41] = rgb(255, 64, 0) palette[ 42] = rgb(255,125, 0) palette[ 43] = rgb(255,190, 0) palette[ 44] = rgb(255,255, 0) palette[ 45] = rgb(190,255, 0) palette[ 46] = rgb(125,255, 0) palette[ 47] = rgb( 64,255, 0) palette[ 48] = rgb( 0,255, 0) palette[ 49] = rgb( 0,255, 64) palette[ 50] = rgb( 0,255,125) palette[ 51] = rgb( 0,255,190) palette[ 52] = rgb( 0,255,255) palette[ 53] = rgb( 0,190,255) palette[ 54] = rgb( 0,125,255) palette[ 55] = rgb( 0, 64,255) palette[ 56] = rgb(125,125,255) palette[ 57] = rgb(157,125,255) palette[ 58] = rgb(190,125,255) palette[ 59] = rgb(222,125,255) palette[ 60] = rgb(255,125,255) palette[ 61] = rgb(255,125,222) palette[ 62] = rgb(255,125,190) palette[ 63] = rgb(255,125,157) palette[ 64] = rgb(255,125,125) palette[ 65] = rgb(255,157,125) palette[ 66] = rgb(255,190,125) palette[ 67] = rgb(255,222,125) palette[ 68] = rgb(255,255,125) palette[ 69] = rgb(222,255,125) palette[ 70] = rgb(190,255,125) palette[ 71] = rgb(157,255,125) palette[ 72] = rgb(125,255,125) palette[ 73] = rgb(125,255,157) palette[ 74] = rgb(125,255,190) palette[ 75] = rgb(125,255,222) palette[ 76] = rgb(125,255,255) palette[ 77] = rgb(125,222,255) palette[ 78] = rgb(125,190,255) palette[ 79] = rgb(125,157,255) palette[ 80] = rgb(182,182,255) palette[ 81] = rgb(198,182,255) palette[ 82] = rgb(218,182,255) palette[ 83] = rgb(234,182,255) palette[ 84] = rgb(255,182,255) palette[ 85] = rgb(255,182,234) palette[ 86] = rgb(255,182,218) palette[ 87] = rgb(255,182,198) palette[ 88] = rgb(255,182,182) palette[ 89] = rgb(255,198,182) palette[ 90] = rgb(255,218,182) palette[ 91] = rgb(255,234,182) palette[ 92] = rgb(255,255,182) palette[ 93] = rgb(234,255,182) palette[ 94] = rgb(218,255,182) palette[ 95] = rgb(198,255,182) palette[ 96] = rgb(182,255,182) palette[ 97] = rgb(182,255,198) palette[ 98] = rgb(182,255,218) palette[ 99] = rgb(182,255,234) palette[100] = rgb(182,255,255) palette[101] = rgb(182,234,255) palette[102] = rgb(182,218,255) palette[103] = rgb(182,198,255) palette[104] = rgb( 0, 0,113) palette[105] = rgb( 28, 0,113) palette[106] = rgb( 56, 0,113) palette[107] = rgb( 85, 0,113) palette[108] = rgb(113, 0,113) palette[109] = rgb(113, 0, 85) palette[110] = rgb(113, 0, 56) palette[111] = rgb(113, 0, 28) palette[112] = rgb(113, 0, 0) palette[113] = rgb(113, 28, 0) palette[114] = rgb(113, 56, 0) palette[115] = rgb(113, 85, 0) palette[116] = rgb(113,113, 0) palette[117] = rgb( 85,113, 0) palette[118] = rgb( 56,113, 0) palette[119] = rgb( 28,113, 0) palette[120] = rgb( 0,113, 0) palette[121] = rgb( 0,113, 28) palette[122] = rgb( 0,113, 56) palette[123] = rgb( 0,113, 85) palette[124] = rgb( 0,113,113) palette[125] = rgb( 0, 85,113) palette[126] = rgb( 0, 56,113) palette[127] = rgb( 0, 28,113) palette[128] = rgb( 56, 56,113) palette[129] = rgb( 68, 56,113) palette[130] = rgb( 85, 56,113) palette[131] = rgb( 97, 56,113) palette[132] = rgb(113, 56,113) palette[133] = rgb(113, 56, 97) palette[134] = rgb(113, 56, 85) palette[135] = rgb(113, 56, 68) palette[136] = rgb(113, 56, 56) palette[137] = rgb(113, 68, 56) palette[138] = rgb(113, 85, 56) palette[139] =
Re: [fpc-pascal] Serial to TCP gateway in FPC?
El 21/06/2017 a las 1:37, Bo Berglund escribió: The problem I have is that it seems only to work for COM1 or COM3, as soon as I use a higher numbered port like COM33 then it fails. What have I missed here? Is serial only able to work with the low numbered ports (single digit)? Hello, COM ports in windows can only be 1-9, to open high numbered COM ports you must use the extended name syntax (without quotes) "\\.\COM99" you can also use "\\.\COM1" for COM1-9. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] SIGSEGV in fpc_check_object
El 13/06/2017 a las 21:04, Gabor Boros escribió: Cannot have a simple test case just a dumb example. procedure TForm1.FormCreate(Sender: TObject); var x:TPanel; begin x.Free; end; With Linux no error (x is Nil before the Free call), with Windows got SIGSEGV (x is not Nil before the Free call). Is it a Lazarus thing or come from FPC? Hello, That's wrong for sure, x is not initialized to nil, not in Linux nor in Windows. Procedure variables must be always initialized by hand. With that code you will get a warning from the compiler about uninitialized variable use. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Windows - Force files to write to disk
El 22/03/2017 a las 19:17, James Richters escribió: Copy the file to the hard drive with a temporary name Flush all writes to above file Delete previous backup file Rename the original file to backup file name Rename the new recently copied file to the original name Hello, Your problem seems to be that you are using an SSD without a big capacitor (or partially damaged one) to preserve writes on power loss. This fact combined with how TRIM works could create that effect. You can try this steps: 1) Copy file content to .bak 2) Create new file with data (.datnew) 3) Close file (This forces SSD to write to an spare block) 4) Delete old file (This forces a TRIM sent to the SSD) 5) Rename file to original name. In step 4, the delete should send a TRIM which could force a SSD-RAM to NAND-SSD write to handle the TRIM. You must not delete 0 bytes (no TRIM) nor files with a size less than 1024 (no TRIM in NTFS as most of them are stored as resident data in MFT). -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] WebAssembly Target
El 16/03/2017 a las 16:27, Graeme Geldenhuys escribió: On 2017-03-16 14:45, Karoly Balogh (Charlie/SGR) wrote: I think there's still a master switch to disable this in the browsers. So far Firefox 52 has none. Not in the Preferences, and not in about:config either. Hello, about:config javascript.options.wasm;true/false -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Adding a array of float in ressource and use it ?
El 08/03/2017 a las 0:03, Vojtěch Čihák escribió: there are different informations about *.wav, so maybe there are different impementations too. http://soundfile.sapp.org/doc/WaveFormat/ https://blogs.msdn.microsoft.com/dawate/2009/06/23/intro-to-audio-programming-part-2-demystifying-the-wav-format/ Hello, Wav (AKA RIFF WAVE) is a container (RIFF), not an audio format, inside a wav you can put many audio formats and other informations like author, copyright, cues, some of them standard (defined by Microsoft) and others proprietary. Usual wav files that most people use are PCM (Pulse Code Modulation) or in more programmer words int16 per channel. This is the usual format, but you can put inside floats, mp3, GSM, ADPCM, and many more. @Fredvs: If your wav is noise in audacity the reason is quite sure because you are writing float audio buffer with a wav PCM header. Wav PCM is 4 bytes per sample in stereo while float is 8 bytes and almost never used for wav. Header and audio data (format, channels, bit depth) must match. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpc and voip ?
El 02/02/2017 a las 18:25, fredvs escribió: - Opus: only one sample-rate: 48k (easier for mixing + DSP) AbbreviationAudio bandwidth Effective sample rate NB (narrowband) 4 kHz 8 kHz MB (medium-band) 6 kHz12 kHz WB (wideband) 8 kHz16 kHz SWB (super-wideband) 12 kHz24 kHz FB (fullband)20 kHz48 kHz And please move opus related to fpc-other. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpc and voip ?
El 02/02/2017 a las 16:32, Santiago A. escribió: El 17/01/2017 a las 16:48, José Mejuto escribió: Maybe you may think in Opus http://opus-codec.org/ as it is open, royalty free (mp3 is not free, you must pay royalties for the encoder side) and source code is C89 so it must be compilable (libopus) in almost any platform without a titanic effort. mp3 is not free? According with https://en.wikipedia.org/wiki/MP3#Licensing.2C_ownership_and_legislation It's royalty free in European Union. And, in USA, still valid patents will expire along 2017. After 31 December 2017 will be completely royalty free in USA also. Don't know rest of the world. Can it be worse than in USA? Hello, You are right, my working with MP3 technology was in 1999 so my "standards" are very old :-) Anyway Fraunhofer Institute which holds most known patents about MPEG Layer III does not say "Patents expired" so maybe they can have a later patent over technology trying to enforce it in a future and keep control of the royalties. Releasing a mp3 codec now could be safe in Europe (and 2018 in EEUU) but a hardware piece could be a problem if a later patent appears in the game. In the other hand as all known patents has expired I think no court will be against you, maybe a "cease and desists" at most. Anyway mp3 technology is surpassed a lot by others. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to use pipes ?
El 01/02/2017 a las 19:55, fredvs escribió: Outframes := op_read_float(HandleOP, @Buffer[0], FramesWanted , nil); if Outframes = 0 then exit; Hello, if OutFrames < 0 then exit; The fact that op_read_float is zero is not an error, simply the amount of samples read by opus engine is zero, maybe because internal buffer is full and do not need more data by now. Reading from internet is usually faster than playing bitrate. Maybe you should sleep for a bit and retry. From docs: Returns: The number of samples read per channel on success, or a negative value on failure. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pointer hashing
El 30/01/2017 a las 3:37, Ryan Joseph escribió: I’m trying to hash a pointer value and found some example of hash function but not sure about translations and the process in general. Hello, After addressing the ^ conversion showed by other people I have a question. Why you need to hash a pointer ? Hashing a value is interesting to reduce its compare time (taking collisions into account) and/or verify message integrity, and hashing a pointer does not meet none of this goals as it is process wide unique (no collisions) and its size is the fastest compare operation (most architectures). -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pipe vs Memory buffer.
El 28/01/2017 a las 13:32, fredvs escribió: TOpusFileCallbacks = record read: op_read_func; seek: op_seek_func; tell: op_tell_func; close: op_close_func; end; This does not work: HandleOP := op_test_callbacks(pointer(InPipe),op_callbacks, BufferURL[0], PipeBufferSize, err); Hello, As you need to use records you should specify {$PACKRECORDS C} or you could get a different record layout than C expects. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pipe vs Memory buffer.
El 27/01/2017 a las 3:52, fredvs escribió: Hello Silvio: Yes, we are on the good way. Following your advice, here from https-url-opus the result of : Hello, The first thing to debug this problems is to determine the expected data for opus_test_memory. Usually streams (audio, video, etc...) are composed by two pieces the raw data and the transport envelope. In this case opus usually uses Ogg as transport envelope but it could be streamed in another container like MP4, MKV, etc. Opus library should provide a play engine that decodes raw streams, extracted from its transport layer and maybe another series of APIs for the default transport layer, Ogg in this case. This last job seems to be done by the OpusFile API. So to resume, you file is a raw opus audio or an Ogg file ? Before using pipes with http try pipes with a local file. If your pipes on local file works but http does not maybe you are receiving the http headers, or any other unexpected situation, so dump the piped data to a local file and match it against the remote one. Said that, I had never touched opus in my life :) so take my comments with care. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpc and voip ?
El 17/01/2017 a las 16:28, fredvs escribió: What do you think about the flac format ? It seams to have all the feature needed on... (and flac is already integrated in uos). Hello, FLAC is basically a compressed WAV (advanced compression), so high quality sound but low compression ratio, also it is not resilient to dropouts, it was not designed for streaming. If you can not find a suitable codec for your application just use a streaming one like mp3, is not the best for the task, but can do it, FLAC can not. Maybe you may think in Opus http://opus-codec.org/ as it is open, royalty free (mp3 is not free, you must pay royalties for the encoder side) and source code is C89 so it must be compilable (libopus) in almost any platform without a titanic effort. Of course a RTP or alike transport is desirable, but it will introduce much more complex tasks. I think that if you like to continue this discussion we should move it to fpc-other. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpc and voip ?
El 17/01/2017 a las 12:56, fredvs escribió: @ Jose => many thanks I will deeply study your advices. In the other side, mp3 is not a suitable format for voIP, as it have a big latency. Huh, what format would be better for voice over ip ? Hello, For conversation: G.7* (G.711 - G.7229) Speex Opus And maybe some others. https://en.wikipedia.org/wiki/Comparison_of_audio_coding_formats -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpc and voip ?
El 16/01/2017 a las 23:10, fredvs escribió: Hello, What must be done to make: - a url-mp3-file like 1) on server That's just a file, you send it like a file with the proper MIME type, is the client that reads information from the stream as needed. - a url-mp3-chunk like 2) on server This is a chuncked send, you start to send information, in the header you do not express the length, so the client will read the file up to to the socket close (and play it). From the send side you must write to the socket instead to a file as you are sampling from the media input. MP3 is not a stateless compression format, this means that each audio frame may need several previous frames to be able to play the current one. This need is the reason that you sometimes ears a "bleep" sound at broadcast start (non professional). Also this dependency means that you can not compress each source audio chunck in an mp3 and broadcast it, you must compress audio portion in chuncks as part of a single stream. Pseudocode: AcceptRemoteSocket(SocketID); mp3compress:=TMP3Compressor.Create; mp3compress.Open; while SocketID.Active do begin XBytes:=AudioGrabber.Grab(RawAudio,MaxRawAudio,250 millisec); CompressedSize:=mp3Compress(RawAudio,XBytes,Mp3Output,Mp3OutBufferSize); SocketID.Send(Mp3Output,CompressedSize); end; mp3compress.Close; mp3compress.Free; SocketID.Close; This is a very basic guide as this code will need checks to avoid remote contention and audiograbber overflow (usually handled by the audio grabber library). In the other side, mp3 is not a suitable format for voIP, as it have a big latency. This usable for uos_AddFromURL()? I do not know, you need a chuncked send data, something that let you send an amount of data unknown while sending, and usually you will need at least one thread plus the main one if you need to handle more requests at the same time. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] C# translatation
El 08/01/2017 a las 17:31, Bernd Oppolzer escribió: Please keep in mind that & is a bitwise and in C whereas && is a logical and; this makes much difference and has to be implemented or converted differently with Pascal, IMO. the closest equivalence to bitwise and in Pascal are set intersections, IMO. If I had to implement that on integers using standard pascal, this would cause me some headache ... Both bitwise operations (vars are integers). C / C++: a = b & c; Pascal: a := b and c; Both work the same way but pascal does not have the assignment and testing mess that can be written in C like: C / C++: a = b && c; Pascal: a := (b<>0) and (c<>0); -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] file identification using libmagic
El 14/12/2016 a las 19:53, Marc Santhoff escribió: Hi, I have made a header port of libmagic which is used by the file(1) command to identify the type of files. Usage examples are availble, too. Hello, Just a note, I was using magic.dll for Windows a few years ago and I was being forced to use dynamic loading as my code must process thousands of streams/files and in magic_close the dll left an allocated memory block and the only way to remove it was unloading the DLL. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TFileStream.WriteBuffer() and RAM used ?
El 13/12/2016 a las 0:48, fredvs escribió: IMO, the problem does not come from PortAudio but from TFileStream.WriteBuffer that does not have enough RAM for writing. But maybe I do not catch something :-( Hello, In your code you were writing from uos to TMemoryStream (RAM) and when finished copy everything to TFileStream (Disk), so instead the TMemoryStream use a TFileStream and skip the last copy. Of course you may need to rewrite file header when the process is finished. Currently (pseudo code): TMemoryStream.Create; while Recording do begin TMemoryStream.Write(AudioBuffer); end; TFileStream.Create; TFileStream.CopyFrom(TMemoryStream); TFileStream.Free; TMemoryStream.Free; So change it by: TFileStream.Create; while Recording do begin TFileStream.Write(AudioBuffer); end; // Here you may need to rewrite file header (if any). TFileStream.Free; -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TFileStream.WriteBuffer() and RAM used ?
El 11/12/2016 a las 14:39, fredvs escribió: @ Jose : uos uses PortAudio library to grap input from devices. I will deeply study your propositions. Hello, After a fast view of PortAudio API you can produce a code like: procedure WriteStreamToFile; var F: TFileStream; lAvailableFrames: integer; lAvailableBytes: integer; lLocalBuffer: array [0..16383] of Byte; begin F:=TFileStream.Create('YourFile.Extension',fmCreate); F.write(SomeHeaderData,SizeOf(SomeHeaderData)); while NotUserBreak_OrLimitReached do begin lAvailableFrames:=Pa_GetStreamReadAvailable(YourAudioStream); lAvailableBytes:=lAvailableFrames * (YourStream_BYTES_PER_FRAME); if lAvailableBytes<16384 then begin // Don't read, just wait a bit. Sleep(1); end else begin Pa_ReadStream( YourAudioStream, @lLocalBuffer[0], 16384 div (YourStream_BYTES_PER_FRAME ); F.WriteBuffer(lLocalBuffer[0],16384); end; end; F.WriteBuffer((SomeTailData,Sizeof(SomeTailData)); F.Position:=; F.WriteBuffer(SomeDataWithStreamSize,Sizeof(SomeDataWithStreamSize)); F.Free; end; This code should work because PortAudio (and almost 100% APIs of this kind) has an internal buffer which is large enough to hold new data while you are writing to disk and performing other tasks. Some even use a dynamic buffer which can hold audio for several seconds before you extract them using the API. Note: Of course the maths are the expected ones, you must know the BYTES_PER_FRAME size and the format of that frames, maybe int16, maybe float, maybe -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TFileStream.WriteBuffer() and RAM used ?
El 09/12/2016 a las 12:15, fredvs escribió: Hello. Thanks Michael for answer. What happens with the buffer in which you had data, this we do not know. Here is the schema of recording: Hello, You working schema for recording is memory related, you must transform it in a static approach based in expected requirements. In other words, you are about to write a WAVE, in a regular PC you can grab it directly to the TFileStream from InputBuffer, if you are in a very low power device you can use a doble buffer and if your requirements are a low power PC with very high bitrate spike you must swap to threading model (but it is overkill for almost anything nowadays). It you don't want to directly write to TFileStream use the double buffer, let the audio grabber write in a block of memory while you dump the other one to TFileStream. It is quite difficult to show an example because I do not known the API you are using to grab the audio, most of them work with callbacks, some blocks execution, and others uses Windows events. If execution in API is blocking your thread I'm quite sure there is another one that do not block it. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Missing messages
Hello, Today I had detected that some emails does not reach me in this mailing list, in fact the last ones from "leledumbo" about JSON parsing, but Graeme and Michael ones arrive successfully -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] C translation question
El 25/10/2016 a las 3:56, Lars escribió: If you want to test it I can provide .exe or source code, but do not expect it to translate anything far than some trivial functions. Do you have github account... or sourceforge, I think a few other people may find it useful... Hello, No sorry, no github, sourceforge (maybe yes, I can not recall). Anyway I had sent you off the list a link to download my current implementation, test it and if you think it could be useful for anybody you can publish it or maybe I should open a github account :-) Let me know if you was able to compile it. Thank you. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] C translation question
El 24/10/2016 a las 1:40, Lars escribió: Hi, what is the status of automated conversion tools? Last I remember reading about them was when I read a delphi page on how to convert header files. Are you saying that nowadways you can actually convert plain C code to fpc, not just header files but all C code? Just certain types of C code? Are there any competing tools or everyone uses just one main tool? Hello, I don't know, wrote this tool to help me in the past to translate Zint barcode source from C to pascal, in special the maths involving "++", "--" and other funny "C" expressions. It is far away from a real code translator, and it is dummy as it does not analyze the type of each variable, instead it uses them as a variable of any type and it simply try to put it in the same context as the "C" one. When it finds things like: if (a) { ... It will convert it to if IsTrue(a) then ... So you must provide an IsTrue function for that case (integer, char, byte...) and many times you need to manually adjust some lines. Or if it finds: a++; It will output: PostInc(a); Where PostInc is: function PostInc(var aValue: integer): integer; begin Result:=aValue; aValue:=aValue + 1; end; It uses GoldParser so maybe it only works in Windows :-?, only very basic "C" is handled and is mostly function by function oriented. If you want to test it I can provide .exe or source code, but do not expect it to translate anything far than some trivial functions. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] importtl tool
El 24/10/2016 a las 8:17, LacaK escribió: I'm not "sure" because if the flag does not tell us nothing (no IN, no OUT) I do not know if there is a "default behavior" except the "ByRef" flag and both "constref" and "var" are "ByRef". I have found: https://msdn.microsoft.com/en-us/library/windows/desktop/aa367051(v=vs.85).aspx "The*[in]*attribute is applied to a parameter by default when no directional parameter attribute is specified." Hello, I was not aware about that "default" so, yes you are right. Take a look in you TLB looking for a widestring that should return information, if with this code is marked as "var" everything should be ok, if it will be marked as "constref" something in the logic is wrong. ? I do not understand what do you mean When I use Microsofts OLEView to look at TLB I see only: long ScGetStringValue(long Type, BSTR* Value); There is no attribute [in],[out],... specified I'm quite sure that using "var" in both cases is safe in 99.9% of the cases. OLEView will not show you the "attributes", only in the IDL source. According to: https://msdn.microsoft.com/en-us/library/cc237804.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms221019(v=vs.85).aspx *"PARAMFLAG_NONE: *The behavior of the parameter is not specified." I guess, that my case is PARAMFLAG_NONE so patch should look like: case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and (PARAMFLAG_FIN or PARAMFLAG_FOUT) of PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var '; PARAMFLAG_FOUT:sPar:='out '; *PARAMFLAG_NONE,* PARAMFLAG_FIN:sPar:='var '; //constref in safecall? TBD end; I leave 'var ' for Delphi compatibility ... Yes. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] C translation question
El 22/10/2016 a las 11:59, Ryan Joseph escribió: j := i + 1; might want this at the end of the loop. Doing that defiantly broke it. I think “j” is being set inside the for() construct and before each pass of the loop. The author explains the for loop even but the fact it requires an explanation makes my worry about how easy it is to mess up. :) Hello, It is at the end of the loop for sure, it points to the "previous" point in the polygon and in the case of the first testing point the "previous" one is the last one. So the correct code is: j := i; This is my automated C code conversion for that function: function pnpoly(nvert: Integer; vertx: PointerTo_Single; verty: PointerTo_Single; testx: Single; testy: Single): Integer; var c: Integer = 0; j: Integer = 0; i: Integer = 0; begin {INITCODE} c := 0; {INITCODE} j := 0; {INITCODE} i := 0; i := 0; j := nvert - 1; while i < nvert do begin if IsTrue(IsTrue(((verty[i] > testy) <> (verty[j] > testy))) AND IsTrue((testx < (vertx[j] - vertx[i]) * (testy - verty[i]) div (verty[j] - verty[i]) + vertx[i]))) then begin c := BooleanNot (c); end; j := PostInc(i); end; exit (c); end; -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] importtl tool
El 21/10/2016 a las 13:57, LacaK escribió: To note that both "constref" are intentional. Ok I can create patch if we (you ;-)) are sure that it is okay ? -Laco. Hello, I'm not "sure" because if the flag does not tell us nothing (no IN, no OUT) I do not know if there is a "default behavior" except the "ByRef" flag and both "constref" and "var" are "ByRef". Take a look in you TLB looking for a widestring that should return information, if with this code is marked as "var" everything should be ok, if it will be marked as "constref" something in the logic is wrong. In the other hand I do not have information about how TLBs are defined, my fixes were based in experience with some TLBs that I had and that should use, and in my case fortunately I had an equivalent C API to match against. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] importtl tool
El 21/10/2016 a las 12:32, LacaK escribió: So result should be: case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and (PARAMFLAG_FIN or PARAMFLAG_FOUT) of PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var '; PARAMFLAG_FOUT:sPar:='out '; else sPar:='constref '; end; Hello, Maybe a big note should be added if it is fixed in that way. Or even better PARAMFLAG_FOUT:sPar:='out '; PARAMFLAG_FIN:sPar:='constref '; else sPar:='constref '; To note that both "constref" are intentional. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] importtl tool
El 21/10/2016 a las 12:05, LacaK escribió: - in typelib.pas is on line 631 vt=VT_PTR and sl='PWideString' ('P' is deleted on line 635) wParamFlags=0 When I add "else" part: case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and (PARAMFLAG_FIN or PARAMFLAG_FOUT) of PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var '; PARAMFLAG_FOUT:sPar:='out '; PARAMFLAG_FIN:sPar:='var '; //constref in safecall? TBD /*added*/ else sPar:='var '; end; it works for me. But I have no idea if it can negative impact other cases ? Hello, Looking again to the code I think you are right and is the third case "PARAMFLAG_FIN" which may be wrong, it should be "constref" (IN only). Have you tried to use constref in the else case ? -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] importtl tool
El 20/10/2016 a las 15:20, LacaK escribió: There is: if bParamByRef then case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and (PARAMFLAG_FIN or PARAMFLAG_FOUT) of PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var '; PARAMFLAG_FOUT:sPar:='out '; PARAMFLAG_FIN:sPar:='var '; //constref in safecall? TBD end; In my case bParamByRef = True, but wParamFlags=0 so no "var" nor "out" is added ... (as I do no known about type libraries I fear, that any modification which fixes my case can cause problems in another cases) So I have posted bug report: http://bugs.freepascal.org/view.php?id=30764 may be somebody experienced can fix it ... Hello, If wParaFlags is 0 then no "var" or "out" must be added (unless bug in filling wParamFlags with value) as it should be something like "constref" as "const" is not valid because it will try to perform a copy. Maybe "var" could be used :-? but it could be a problem if the called function changes the param expecting it to be discarded on return. For native types like int and so on a const will work, but for interfaces, widestring, ... inclusion of var can crash some functions and not adding it could crash another ones. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] importtl tool
El 20/10/2016 a las 11:09, LacaK escribió: Hi, I have noticed, that tool for importing type library into pas incorrectly imports interface methods, which should have "var" parameter. For example in my case imported: function ScGetStringValue(Type_:Integer;Value:WideString):Integer;dispid 33; but it should be: function ScGetStringValue(Type_:Integer;var Value:WideString):Integer;dispid 33; I think, that it is bug as far as delphi imports same type library with "var". Has somebody similar experience? Hello, I had fixed some of this bugs in: http://bugs.freepascal.org/view.php?id=27486 And my patch was applied with small modification (as noted by Michael Van Canneyt) and I'm not sure if this modification alters the "var" inclusion in some fields. Unfortunatly I'm not working with the TLBs anymore so I can not perform more tests. Maybe you can try to look at my patch and replace the last lines in your typelib.pas and recompile fpc tool. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] teventobject.create fails with error 161
El 14/10/2016 a las 20:11, Snorkl e escribió: Since I solved it by giving the name param a giud, the next thing to ask is why does teventobject fail kind of silently when the name parm is blank over time? Hello, To me it looks like a memory corruption, in your program or in the library. Have you checked the code with heaptrc activated ? -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Asci85
El 16/09/2016 a las 10:16, Santiago A. escribió: Hello, StrmEnc85:=TAscii85EncoderStream.Create(StrmOut,72,True); try StrmEnc85.CopyFrom(StrmIn,0); Result:=StrmOut.DataString; finally StrmEnc85.Free; Maybe there is something wrong in ASCII85 encoder, but this code is wrong, it should be something like: try StrmEnc85.CopyFrom(StrmIn,0); StrmEnc85.Free; Result:=StrmOut.DataString; finally Because stream must be flushed before extracting result and the flush is performed in the destroy. Saludos!. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GZip - Stream decompress only in memory
El 04/09/2016 a las 19:17, Marcos Douglas escribió: try Buf.LoadFromFile('data.txt'); showmessage(inttostr(ExtractStream(Buf, Buf2))); //<< result is 0, ie, OK Buf2.SaveToFile('result.txt'); There is no error, but Buf2 is empty. Hello, I'm not sure but I think that code at least should look like: try Buf.LoadFromFile('data.txt'); --- Buf.Position:=0; showmessage(inttostr(ExtractStream(Buf, Buf2))); Buf2.SaveToFile('result.txt'); Because I think the stream position is just at the end after LoadFromFile. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TTestSuite
El 02/09/2016 a las 15:24, Graeme Geldenhuys escribió: information will pollute the generated XML to stdout. Why not specify a output file for the generated XML, instead of letting it go to stdout. Run the FPCUnit console test application with the -h parameter to see what options are available. Maybe that will help. Hello, With file output there is no problem as only the XML data is stored there, so writeln could be valid as a progress indicator because I think that stdout will not be used by automated tools. Best regards and thanks. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TTestSuite
El 02/09/2016 a las 14:39, Graeme Geldenhuys escribió: If the tests may show some kind of progress information I'm assuming you are talking about FPCUnit? If so, there is already a test progress listener implemented in the form of the TProgressWriter class (see the consoletestrunner.pas unit). Simply run your test suite from the command line and specify the -p (or --progress) command line parameter. Hello, Yes, but I'm writing the test so in code I can write something like: if a=0 then FAIL('Value must not be 0'); And I wish to write something like: if a>1 then MESSAGE('Value 2 or bigger is OK'); if a=1 then MESSAGE('Value 1 is quite dangerous'); if a=0 then FAIL('Value 0 is KBOOM!'); Because some test are slw and I like to have a screen feedback when running manually in the console, but if I use the writeln this information will pollute the generated XML to stdout. Maybe using stderr for progress messages will be valid and that's my question, will stderr cause pollution when the test is added to an automated test set ? PS: I need to contact you out of the list about a project I'm finishing and that would be of your interest. My last try looking for your email (not mailinglists@...) was unsuccessful and never get an answer. Could you please contact me to this email address ? Thank you. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] TTestSuite
Hello, In the TTestSuite class when process is finished a XML is written to stdout. If the tests may show some kind of progress information, for manually run tests, this information must be in stdout, stderr, is there a specific method available for progress output ? Cheers, José Mejuto -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] String concatenation failure (again)
El 02/08/2016 a las 16:51, Jürgen Hestermann escribió: I would expect that with the new string encoding handling widestring will be converted automatically to "MyStringType" (which is string in my case). This assumption is encouraged by the fact that "Liste" is shown with the correct list of all strings in the evaluate window when debugging. The interesting thing is, that *one* (the first) string from "Liste" is added to "S" (but all others are missing). Hello, Check the length of the string I think you have a NULL char at the end of every string, so only the first one (up to #00 char) is displayed. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Single threaded application on multicore CPU
El 22/06/2016 a las 15:01, Mattias Gaertner escribió: I don't doubt that it is swapping. I would like to know why it is swapping. Is it avoiding hotspots, or for longevity, or turbo boost, or system processes, or security, or Related: What is the downside of pinning the process to a cpu? Hello, AFAIK it's more related to heat and whole system response, a heat core can enter in speed throttling thus lowering performance loosing the computing power in the other core(s). Also there are more threads than cores, when a thread finish its time slice if there are more threads scheduled for this core, current process will be directly remapped to another already free cpu core, or if there is not other free cpu core it is queued to the less loaded core given a better opportunity to be executed before. After all this is a statistical game, in average you get better system performance (all threads) if you swap and mix the threads across all cores, better system performance is the gain, and less per given thread performance is the pay ;) -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Need help with a backtrace from fpc 2.6.4
El 17/06/2016 a las 13:18, Dimitrios Chr. Ioannidis escribió: Hello, This looks completly wrong: #3 0x0053bf1f in TIDENTITYHEADERINFO__PROCESSHEADERS ( this=) at C:/Users/dimitris/Programming/Projects/R_1.2.4/3rdparty/indy/Pro tocols/IdHTTPHeaderInfo.pas:452 LSECS = 546620041212591096 Such amount of seconds (or milliseconds) is more than one million years. So looks like the HTTP headers are not correctly parsed, maybe an unexpected format or a not initialized variable in the Indy code. Start by dumping the headers. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Incompatible types: got "SYSTEM.PChar" expected "SYSTEM.PChar"
El 09/06/2016 a las 8:04, Sven Barth escribió: {$DEFINE THISDONTCOMPILE} TConstRecord: TFirstRecord = ( {$IFDEF THISDONTCOMPILE} Ident: TSomePcharArray[1] {$ELSE} Ident: @TSomePcharArray[1] {$ENDIF} ); One can only use untyped constants to initialize other constants or variables in their declarations. The TsomePCharArray is a typed constant, thus not suitable for assignments (a pointer to it's element is however legal as you noticed). Hello, The strange thing is that if I use a pointer, an integer or any other type instead a Pchar the error message is completely different "Error: Can't read or write variables of this type" which is a bit more informative. I understand that untyped is the only source for assign a constant to so using @ I get an untyped pointer and the assign is performed, but is there a way to convert a pointer (typed) to untyped one ? I think that the solution is to pollute the symbol table with a lot of consts, one of each text string. Thank you for your help and enlightenment. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Incompatible types: got "SYSTEM.PChar" expected "SYSTEM.PChar"
Hello, I have a lot of constant strings and some array of records that should be initialized in one field with one of this entries, so I found two solutions, one is create a symbol for each string, something like: const TMyStringSymbol='String one'; But also I need to be able to enumerate all of them at runtime, so I wrote an array and initialize it at compile time (this also produces less symbol pollution for the compiler): const TMyStrings: array [0..1] of pchar = ( 'String One','String Two'); As I need this names in other places I try to create a record and initialize it at runtime using the pchar of the previous array, and here is the problem: --- program testpossiblebug; type TFirstRecord=record Ident: pchar; end; const TSomePcharArray: array [0..1] of pchar = ( 'pcharONE','pcharTWO'); {$DEFINE THISDONTCOMPILE} TConstRecord: TFirstRecord = ( {$IFDEF THISDONTCOMPILE} Ident: TSomePcharArray[1] {$ELSE} Ident: @TSomePcharArray[1] {$ENDIF} ); var R: TFirstRecord; begin R:=TConstRecord; {$IFDEF THISDONTCOMPILE} writeln(R.Ident); {$ELSE} writeln(PPchar(R.Ident)^); {$ENDIF} end. This does not compile and outputs the funny error in the subject. I think it should compile as information is static and previously defined, but if it is indeed an error by my side maybe the error message should be a bit different :-? To test the example, define or undefine the "THISDONTCOMPILE", with it defined it does not compile, without it it compiles and the modified writeln shows the expected pchar string. Should I report it ? -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-pdf: Extracting a page...
El 11/04/2016 a las 22:52, Marcos Douglas escribió: On Mon, Apr 11, 2016 at 5:45 PM, Graeme Geldenhuyswrote: I'm sure it is possible - there are PDF-to-Text tools around. Is it possible with the current fcl-pdf code? No. The fcl-pdf was designed to work the other way take content (code, JSON etc) and create PDF's. Right. PDF-to-text is not an option because I need to extract the page with the same appearance as the original so I can't rewrite the page. Hello, Use qpdf: http://qpdf.sourceforge.net/files/qpdf-manual.html http://qpdf.sourceforge.net/files/qpdf-manual.html#ref.page-selection -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to compile Lazarus program using only FPC?
El 03/10/2015 a las 20:24, Bo Berglund escribió: Is there some way one can reset all unused sectors on the disk to only contain 0xFF or Ox00? That would make the image file compressible to a few GB and possible to share. Hello, Just two links: http://manpages.ubuntu.com/manpages/natty/man8/zerofree.8.html https://www.raspberrypi.org/forums/viewtopic.php?t=97832=678959 -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Assembler output
El 12/09/2015 a las 14:10, Karoly Balogh (Charlie/SGR) escribió: There are two motivations, the first one is to learn how to do it manually, take a .pas, get the .s and assemble them (and link) to geta final executable. IIRC it was arguments: -a -st This won't assemble or link the executable, but generate a script to compile and link on the target OS. I used this often during early days of the Amiga and MorphOS ports. :) You can even use the resulting script as a base for your own compile/link experiments. Hello, Great, sure it would be a great start/base point. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Assembler output
El 11/09/2015 a las 20:18, Florian Klämpfl escribió: FPC dependents on a lot of tools like cross binutils which are not provided by FPC itself. So install nasm separately. Hello, Thank you, so the presence of nasm should make the compiler finish the compilation ? I was thinking that to generate .s output no assembler is needed at all as I do not need the final .exe produced by fpc. Anyway I'll try to install nasm (or other) and see what happends. Thank you again. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Assembler output
El 11/09/2015 a las 21:18, Sven Barth escribió: What is the reason you're trying to do this? Maybe we can help you a bit more if we know your motivation to pursue this. Hello, There are two motivations, the first one is to learn how to do it manually, take a .pas, get the .s and assemble them (and link) to geta final executable. The second one is to perform some manual changes in the asm code (I know that is very easy to trash it) in order to try to catch some possible optimizations and apply/test them before reach a conclusion about them. I currently had written a small SQL parser (very limited options, just for the simple purpose of extract some fields from a large dump) and I think the code (tokenizer) should run faster (currently 28 Megabytes / sec in my i7-3770). It has been written with speed in mind, so no ansistrings, not realloc data, fixed and large read buffers, minimized conditionals as much as possible, inline critical functions, etc... There is still a bit of possible optimizations like replacing indirect access (pointer[n]) by running pointers but it will degrade too much the "easy reading" so I thought maybe I can gain some cycles here and there and find a small set of rules (asm sequences) which can be rewritten, something like WPO. But as noted it is more a training in the "how to" than a need to achieve an objective. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Assembler output
Hello, Can anybody enlight me in how to: - Compile a program outputting assembler in intel format. - Assemble the .s files in a final .exe I can get assembler in AT format using "-a" but if I add "-Anasmwin32" the program is not compiled as "nasm is not found", only main.lpr is compiled, none of the included units (no RTL ones). It would be great if I only need tools provided by fpc but I think that "as.exe" can not read Intel asm format. In the case that "as.exe" can not be used for intel format, is there any option out there in order to get the final .exe from the .s files ? Thank you. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [Windows] FileGetAttr reports faHidden on e.g. C:\
El 04/03/2015 a las 16:01, Bart escribió: Hi, Kind of off-topic. While working on Lazarus' TShellTreeView component, it was brought to my attention that FileGetAttr('C:\') returns an attribute that has faHidden in it. This is kind of unexpected. Well actually it reports $16: faDirectory + faHidden + faSysFile on Win7-64 (32-bit fpc) On Win98SE it reports $10: faDirectory. On Win7 FileGteAttr reports $16 on any path that is the root of a drive, unless it is a 'substituted drive (subst X: path/to/folder). Does anybody know when this behaviour of Windows changed, and why? Hello, That difference is between FAT and NTFS. In NTFS C:\ is not a directory, it is a drive and it also holds data references about the media it contents. Of course it could be considered a folder but it can not be used as a reparse point (like folders), you can not RMDIR it and other differences. Also the path C:\ refers to folder C: which enters in conflict because C: is the notation for current process folder not C:\. Resume, in Windows [OneLetter]:\ is a drive which mostly works at 99% as a folder, but it is not, and its attributes does not have the same meaning as a regular folder and it should be operated as a drive concept (no attributes). Side note: Programming of FileExists and DirectoryExists should be changed (rethink, retest,...) in 32 bits Windows programs in a 64 bit platform as GetFileAttributes does not perform the virtual aliasing like Program Files - Program Files (x86) and a call to FileExists (32 bits) could report that a file exists that could not be opened because it exists in the one that FileExists can see but not in the one that would FileCreate try to use. Jose Mejuto ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] 512bit (or higher) file encryption
El 11/10/2014 a las #4, Krzysztof escribió: Hi, Need to encrypt file with 512bit (or higher) key. Looking at DCPCrypt but seems that none of them can do that. Any advice? Hello, Which is the reason for such a big symmetric key size ? -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is TFPList thread safe?
El 03/10/2014 a las #4, Xiangrong Fang escribió: I don't intend to do any optimization. I just think that I need to enter a critical section, add item to the list, then leave the critical section. Hello, You must protect with a CriticalSection, Add and any other kind of access, like indexed access. As you must protect indexed access you are in the same penalty as using TThreadList. Threading example to a crash (numbers are execution steps): Thread 1 1-Resolve TList data access to $0001 2-calculate item 23 is at $00010023 3-Read $00010023 4-Crash or read from unalocated memory (content undefined). Thread 2 1-Enter Add function and resolve Tlist data to $0001 2-Lock thread and find that it need to relocate data to $0002. Move data 3-Unlock 4-Continue -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reproducible code: DLL calling Firebird crashes
El 29/09/2014 a las #4, Reinier Olislagers escribió: What I would like to know what is the cause of this problem - dlls being loaded before some kind - what kind? - of initialization is complete? Anyway, I'll keep digging; probably first looking at geting postgresql support in anyway. ___ Hello, You must not initialize dbengine in the Initialization section and must not finalize it in that place (maybe only as last chance) because initialization order and finalization order is undefined by fpc and finalization of your code could happen after the whole DB structure has been finished, so the call to DBLayer.Free could try to free an object controlled by an engine which is not loaded yet. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Imagemagick: magickwand doesn't convert to TIFF 1 bit
El 13/09/2014 17:34, Reinier Olislagers escribió: (Earlier posted on forum) See subject - I've posted this on stackoverflow http://stackoverflow.com/questions/25719495/magickwand-conversion-to-tiffccitt-group-4-compression-gives-uncompressed-image Link to example program + demo image is included in that question. Hope some of you guys can help solve this for me - and earn a StackOverflow bounty in the process (if that helps ;) ) Hello, For some reason the bindings in Pascal, and/or the wand bindings (maybe internally to imagemagick) are broken. Use this enumeration to get the expected result in the TIFF module: - UndefinedCompression, NoCompression, BZipCompression, DXT1Compression, DXT3Compression, DXT5Compression, FaxCompression, Group4Compression, JPEGCompression, JPEG2000Compression, /* ISO/IEC std 15444-1 */ LosslessJPEGCompression, LZWCompression, RLECompression, ZipCompression, ZipSCompression, PizCompression, Pxr24Compression, B44Compression, B44ACompression, LZMACompression,/* Lempel-Ziv-Markov chain algorithm */ JBIG1Compression, /* ISO/IEC std 11544 / ITU-T rec T.82 */ JBIG2Compression/* ISO/IEC std 14492 / ITU-T rec T.88 */ -- So in your code use: status := MagickSetImageCompression(wand,CompressionType(7)); if (status = MagickFalse) then HandleError; I had downloaded the imagemagick sources in order to reach this fact. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] JS: \u00C1 = Á; Pascal: $00C1 = ?
El 24/07/2014 2:12, silvioprog escribió: In JavaScript, if I code: alert('\u00C1'); It shows: Á Is \u00C1 of JS same to $00C1 in Pascal? Hello, \u means Unicode char, so \u00c1 = #$00C1 (widestring) -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] typelib.pas
Hello, A few days ago I was trying to convert a COM DLL into a *_TLB.pas file using the importtl.exe and the result does not compile at all due some missing parameter names in some functions/procedures. After note that typelib.pas is the heart of the importtl.exe file I was looking for the reason and fixes the bug and proposed a patch in this bug report http://bugs.freepascal.org/view.php?id=26352 After this patch the code is compilable but some functions fails with a SIGSEGV. Looking at code again I found that some function names AddRef, Invoke and others that are present in base interface (IUnknown and IDispatch) are removed from the generated output. After comment out this lines the code generated works mostly as expected (except another bug explained later) and a function AddRef appears in the middle of some interface definitions. So my question is. Is fpc binding interface functions based in its index ? I think the answer is yes so removing that reserved names crash the binding when a custom function with that name appears in the middle of an interface. To solve this problem there are 2 solutions from my point of view, one is add it as is as (what my internal patch does now) or rename the function so it does not clash with inherited AddRef in example. The other bug is that I had found intefaces which export a property_put with ByRef parameter, so it can not be mapped to a pascal property, so I had changed this conflictive functions to no emit a property read code. Currently tipelib.pas generated code like this interface: procedure Set_Value(var Param1: Widestring); function Get_Value: WideString; property Value read Get_Value write Set_Value; Which can not be compiled due the var in the Set_* procedure. I hope that one devel can review and apply the patch in the bug report noted above. Best regards, José Mejuto -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] paszlib problem: integer overflow
El 14/11/2013 18:15, Dennis Poon escribió: I'd love to just use the paszlib in Lazarus/fpc but I also need the same unit for Delphi 5 (Dephi 5 program will compress data and send to linux /lazarus/fpc program ) so both sides need to understand the same compress/decompress protocol. I tried using the lazarus/fpc paszlib unit in Dephi 5 but it does not compile. Too many errors. The paszlib-sg is the only pascal unit that produces compressed data readable by FPC's zstream and zipper units. Hello, Both paszlib implementation are very, very similar, so try to spot the differences. Also are you trying to compress the 70 MB in one shot ? Post a piece of code that works by itself (just compiles) but that fail with 70 MB files. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] math round vs banker's round
El 13/08/2013 23:47, David Emerson escribió: Hi all, I have just discovered that the system.round function has this very odd behavior of rounding towards an even number when the fractional part is .5 -- in the system.round documentation this is described as banker's rounding I do not like this behavior. How can I use a more mathematically-traditional round function, which always rounds .5 up, and everything below .5 down? Do I need to write this function myself? Hello, SimpleRoundTo I think. Maybe documentation should be changed to add SimpleRoundTo in cross referenced functions and note that SimpleRoundTo uses classic round system instead bankers one. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 2.6.2 throws SEGV in fpc_AnsiStr_Decr_Ref(). How is this possible?
El 09/05/2013 5:19, Bruce Tulloch escribió: If there is no other explanation, then it means I need to find out how the string variable referred to by (%eax) could have been been accessed (or even known to exist) by any other thread in the same address space.-- Hello, In the past I had suffered a problem like yours and the culprit was another different function that passes result (string) as a parameter when calling a function without initialization, something like this: function foo(var para: string): string; begin //Something with para end; function bar(): string; begin result:=foo(result); end; I hope this helps... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Same code from LCL project throw error in console application
El 16/04/2013 22:46, Krzysztof escribió: Thanks! exInvalidOp exception mask solved problem. But I don't understand. Same error I had in fpGUI project. fpGUI interface doesn't use GTK, QT etc, it drawing over pure X11 so how it is possible that application catch GTK errors? Hello, Almost any 'C' library mask that errors, so the programmers do not take them in account and anyone, like the X11, can raise that exceptions. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Same code from LCL project throw error in console application
El 16/04/2013 21:23, Krzysztof escribió: Hi, I have strange issue. Simple mpg123 player which work fine on LCL project, on console application throw floating error in line mh_e := mpg123_read(mh, @outbuf[0], buffer_size, done); Hello, I'm not sure but I think that the GTK2 Widgetset disables some exception masks because GTK2 code here and there raises some float exceptions (division by cero, and others). Try to do it in your console code before the mpg123 calls. Unit math SetExceptionMask (if my memory serves me). -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TStream descendant to compress/decompress gzip data from another stream
El 28/03/2013 1:06, Ewald escribió: Google found an old thread on lazarus mailing list about this (FPC, gzip and stream) but without any solution, everything mentioned there has either the limitations of TCompressionStream/TDecompressionStream (no gzip format) or TGZFileStream (not able to work wit ObjectPascal streams). Hello, .gz is a quite simple format, but it can not be implemented as a TStream (only) descendant because in a single .gz file many files could be added so something like the class to handle .zip files should be used. Sorry to just drop in on this quite late, but isn't gzip a compression algorithm and not a file format as such? gzip (the command line utility) only compresses one file and *doesn't* put this in a multi-file container. To get `multi-file gzips`, you will first want to bundle the files and compress this bundle (files - tar - gzip) or compress the files separately and then bundle them together (files - multiple separate gzipped files - tar). Or are we talking about a different gzip here? Hello, Just quoting the RFC1952 about .gz format: --- http://tools.ietf.org/html/rfc1952 2.2. File format A gzip file consists of a series of members (compressed data sets). The format of each member is specified in the following section. The members simply appear one after another in the file, with no additional information before, between, or after them. --- So I think it is legal to concatenate several .gz files and get a final .gz with several files inside. In the other hand, yes, the usual behavior in .gz is to store only one file. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TStream descendant to compress/decompress gzip data from another stream
El 27/03/2013 19:22, Michalis Kamburelis escribió: Google found an old thread on lazarus mailing list about this (FPC, gzip and stream) but without any solution, everything mentioned there has either the limitations of TCompressionStream/TDecompressionStream (no gzip format) or TGZFileStream (not able to work wit ObjectPascal streams). Hello, .gz is a quite simple format, but it can not be implemented as a TStream (only) descendant because in a single .gz file many files could be added so something like the class to handle .zip files should be used. Parsing the .gz header is easy, and calling TCompressionStream and TDecompressionstream over the payload should be easy, but only for the first file in the .gz -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Sigsegv with refcounting interface
El 07/03/2013 12:29, Joao Morais escribió: Hello list, what's the problem with RoundThree procedure (below)? Here it raises a sigsegv trying to read an internal field. The difference from RoundTwo is that I create an implementation of the interface within the first param of tinterfacedlist.add method. writeln('typecasting to v1...'); v1 := iintf(vintf[0]); Hello, AFAIK you are casting a IUnknown to iintf instead requesting the iintf interface. I think the right procedure should be: v1 := vintf[0] as iintf; -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Result: string
El 06/03/2013 10:40, Jonas Maebe escribió: FPC 2.6.2 does give a warning (code is from http://bugs.freepascal.org/view.php?id=20907#c55064 ): [...] It could also fail in 2.6.x, just less often. Hello, 2.6.0, 2.6.2 and 2.7.1 trunk produces a warning with that code, but with this one 2.6.0, and 2.7.1 trunk does not generate it (I do not have 2.6.2 to test): \fpc\svn\bin\i386-win32\fpc test.pp Free Pascal Compiler version 2.7.1 [2013/03/03] for i386 Copyright (c) 1993-2013 by Florian Klaempfl and others Target OS: Win32 for i386 Compiling test.pp Linking test.exe 26 lines compiled, 0.1 sec, 29680 bytes code, 1236 bytes data \fpc\fpc\2.6.0\bin\i386-win32\fpc.exe test.pp Free Pascal Compiler version 2.6.0 [2011/12/25] for i386 Copyright (c) 1993-2011 by Florian Klaempfl and others Target OS: Win32 for i386 Compiling test.pp Linking test.exe 26 lines compiled, 0.0 sec , 27264 bytes code, 1692 bytes data -- program test; {$mode objfpc} {$h+} procedure TheB(var aTheA: string); begin aTheA:=aTheA+'A'; end; function TheA(): string; begin TheB(Result); end; Var C : String; begin C:='B'; C:=TheA; C:=TheA; Writeln('= ',C,''); end. --- And the effect is the same as using a non initialized variable, so it must generate a warning AFAIK. So passing Result as var does not generate a warning. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Result: string
El 06/03/2013 13:47, Jonas Maebe escribió: 2.6.0, 2.6.2 and 2.7.1 trunk produces a warning with that code, but with this one 2.6.0, and 2.7.1 trunk does not generate it (I do not have 2.6.2 to test): That's because you are passing an uninitialized value to a var-parameter. That only generates a hint, because a lot of code uses var-parameters also for parameters that do not yet have to be initialized (because the code predates the existence of the out keyword, or simply out of habit). This is unrelated to string results specifically. OK, I see now. I had changed the code to perform the same with integers and yes, it also does not report a warning only a hint which is enought to me. I'm quite sure that the library that starts this thread does not show a hint, so maybe in some situations it could fail. I'll try to reproduce it in a small code (if there is a problem, of course), meanwhile everything seems to work as expected. Thank you for your help. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Result: string
El 06/03/2013 13:47, Jonas Maebe escribió: 2.6.0, 2.6.2 and 2.7.1 trunk produces a warning with that code, but with this one 2.6.0, and 2.7.1 trunk does not generate it (I do not have 2.6.2 to test): That's because you are passing an uninitialized value to a var-parameter. That only generates a hint, because a lot of code uses var-parameters also for parameters that do not yet have to be initialized (because the code predates the existence of the out keyword, or simply out of habit). This is unrelated to string results specifically. Hello, I had found why I was unable to see the hint, because it is not shown due the special contruction of the function. This code produces a hint for the Result: String not initialized, but not for the Result: integer one: -- program test; {$mode objfpc} {$h+} procedure TheB(var aTheA: string); begin aTheA:=aTheA+'A'; end; function TheA(): string; begin TheB(Result); end; procedure TheNumberB(var aTheB: integer); begin aTheB:=aTheB*2; end; function TheNumberA: integer; procedure HideTheHint; begin //As it is a procedure the Result var is taken //from the function scope. TheNumberB(Result); end; begin HideTheHint; end; Var C : String; N : integer; begin C:='B'; C:=TheA; C:=TheA; Writeln('= ',C,''); N:=1; N:=TheNumberA; N:=TheNumberA; Writeln('= ',N,''); end. --- Yes, it is a bit obfuscated. I do not known if this is a bug in the hint. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Result: string
El 05/03/2013 11:23, Howard Page-Clark escribió: The code that makes me wonder something is wrong is this one: [...] For me (win32, FPC 2.6.2) the output is identical (= A) whether or not Result in TheA() is initialised manually or not. Perhaps 2.7.1 has a regression here if it differs for you? Hello, The problem is not the different behavior as it is or will be noted in documentation, the problem is the lack of warning of using a not initialized variable, so it is hard to fix code that works fine in 2.6.x and that could fail with Trunk. Should I report a bug in Mantis about the warning ? -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Result: string
Hello, What's the expected output of this code ? function TheA(): string; begin Result:=Result+'A'; end; writeln(TheA()); I thought that when the result type is an automated one its value gets initialized... Maybe I'm wrong... -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Result: string
El 04/03/2013 22:16, Michael Van Canneyt escribió: That report says the issue was assigned to Jonas and fixed in revision 20427 (ver 2.6.1). I find the current release (2.6.2) initialises a string function result to EmptyStr as you would hope. [...] Prints AA Hello, I'm asking because today I has updated my old 2.7.1 SVN since 8-9 months and a library starts to fail and the bug was the Result string which enters the function with a value while it does not happend in the old one. If Result as string is not initialized a warning should be issued do not ? This happends in your simple test, but I was unable to find it in the library that I'm using. The code that makes me wonder something is wrong is this one: --- {$mode objfpc} {$h+} procedure TheB(var aTheA: string); begin aTheA:=aTheA+'A'; end; function TheA(): string; begin //Result:=''; TheB(Result); end; Var C : String; begin C:='B'; C:=TheA; C:=TheA; Writeln('= ',C,''); end. --- In this situation no warning happends and result is different if I uncomment the Result:=''; line. I think the missing warning is a bug, the missing warning or the non initialization. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
El 12/02/2013 13:29, Giuliano Colla escribió: My conclusion is that one can't properly handle INI files with just a try..finally construct, as all examples show, because a possible error will propagate outside the construct, with unpredictable effects (in this case the FormClose procedure doesn't properly complete). Hello, Finally always propagate the exception bubbling up looking for other exception handler, and that's its job, in comparation to except handler which eat the exception and if you need to propagate it again you must Raise in the exception handler. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal