Re: [fpc-pascal] LibXML2
Currently, libxml2 headers are outdated and partially incorrect/incomplete. I updated the headers a couple of years ago. You can find the patch file here: https://gitlab.com/freepascal.org/fpc/source/-/issues/38905 Michał. W dniu 2023-06-12 o 17:12, David Connolly via fpc-pascal pisze: Hi all, I upgraded to Debian 12 today and I've noticed some weird behaviour with libxml2. Free Pascal Compiler version 3.2.2+dfsg-20 [2023/03/30] for x86_64 program xml; uses xml2; begin end. This program compiles fine, but will not run against the updated version of libXML2. The call of xmlXPathInit seems to be causing the error. Regards, David Connolly ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Different levels of the same compiler message
Why am I getting a different level (hint/warning) of the same compiler message in similar code, only differing in return type? The following example: program Project1; uses SysUtils; function Test1: String; begin SetLength(Result, 0); end; function Test2: TBytes; begin SetLength(Result, 0); end; begin Test1; Test2; end. compiles with messages: Free Pascal Compiler version 3.3.1-11052-g621f3b8387-dirty [2022/05/19] for i386 Copyright (c) 1993-2022 by Florian Klaempfl and others Target OS: Win32 for i386 Compiling project1.lpr project1.lpr(7,19) Hint: Function result variable of a managed type does not seem to be initialized project1.lpr(12,19) Warning: Function result variable of a managed type does not seem to be initialized Regards, Michał. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bit manipulation helpers
W dniu 2022-02-21 o 13:34, gabor via fpc-pascal pisze: W dniu 2022-02-21 o 13:18, Ryan Joseph via fpc-pascal pisze: Oh my, I was confusing my terms I think. I wanted to do bit masking (I think it's called). I was expecting there to be something like TestFlag in the RTL since I can never remember the syntax "Value = (Value or Index)" function TestFlag(Value: QWord; Index: Byte): Boolean; begin result := Value = (Value or Index); end; Should you use the "AND" operator instead of "OR" for bit testing? result := Value = (Value AND Index); Of course not. My mistake. Michał. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bit manipulation helpers
W dniu 2022-02-21 o 13:18, Ryan Joseph via fpc-pascal pisze: Oh my, I was confusing my terms I think. I wanted to do bit masking (I think it's called). I was expecting there to be something like TestFlag in the RTL since I can never remember the syntax "Value = (Value or Index)" function TestFlag(Value: QWord; Index: Byte): Boolean; begin result := Value = (Value or Index); end; Should you use the "AND" operator instead of "OR" for bit testing? result := Value = (Value AND Index); Michał. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TMemoryStream.SetSize question.
W dniu 2021-06-14 o 22:25, Michael Van Canneyt via fpc-pascal pisze: On Mon, 14 Jun 2021, gabor via fpc-pascal wrote: W dniu 2021-06-14 o 21:27, Michael Van Canneyt via fpc-pascal pisze: On Mon, 14 Jun 2021, gabor via fpc-pascal wrote: Why does TMemoryStream only implement one version of SetSize method? https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/objpas/classes/classesh.inc?revision=49038=markup#l1225 The TStream class has two versions of SetSize method (virtual, overload) - one with a parameter of LongInt type and the other with the Int64 type. Since function is virtual, child classes can override it and can be called from code, but then a version of the SetSize function not implemented for a given platform in the TMemoryStream class can be called. The base method checks which one is overridden. So it does not matter which one you override in the child. The "other" one will always fall back to the method in TStream. Unfortunately, on the 64bit platform it does not fully work. See the project below. Sorry, I was mixing up seek and setsize. Indeed. You should not be calling the integer SetSize() directly. People creating descendent classes are expected to know what to do, i.e. to use the 64-bit version. You are absolutely right. But why do we have different function for different platforms? Wouldn't it be better to implement either one function with an Int64 parameter for both platforms, or even both variants of this function? The Size property is of type int64 on both platforms so why should SetSize (that is public in TMemoryStream) be platform dependent? Michał. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TMemoryStream.SetSize question.
W dniu 2021-06-14 o 21:27, Michael Van Canneyt via fpc-pascal pisze:
On Mon, 14 Jun 2021, gabor via fpc-pascal wrote:
Why does TMemoryStream only implement one version of SetSize method?
https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/objpas/classes/classesh.inc?revision=49038=markup#l1225
The TStream class has two versions of SetSize method (virtual,
overload) - one with a parameter of LongInt type and the other with
the Int64 type. Since function is virtual, child classes can override
it and can be called from code, but then a version of the SetSize
function not implemented for a given platform in the TMemoryStream
class can be called.
The base method checks which one is overridden. So it does not matter
which one you override in the child.
The "other" one will always fall back to the method in TStream.
Unfortunately, on the 64bit platform it does not fully work. See the
project below.
program Project1;
{$mode objfpc}
uses
Classes;
type
TMyMemStream = class(TMemoryStream)
procedure Foo;
procedure Bar;
end;
procedure TMyMemStream.Foo;
begin
SetSize(10);
end;
procedure TMyMemStream.Bar;
begin
SetSize(Int64(10));
end;
var
MS: TMyMemStream;
begin
MS := TMyMemStream.Create;
MS.Foo;
WriteLn(MS.Size);
MS.Bar;
WriteLn(MS.Size);
MS.Free;
ReadLn;
end.
Michał.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] TMemoryStream.SetSize question.
Why does TMemoryStream only implement one version of SetSize method? https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/objpas/classes/classesh.inc?revision=49038=markup#l1225 The TStream class has two versions of SetSize method (virtual, overload) - one with a parameter of LongInt type and the other with the Int64 type. Since function is virtual, child classes can override it and can be called from code, but then a version of the SetSize function not implemented for a given platform in the TMemoryStream class can be called. Michał. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Traits Proposal
W dniu 2021-02-13 o 20:38, Sven Barth via fpc-pascal pisze: Of course this does not provide any mechanism to directly add fields, however the compiler could in theory optimize access through property getters/setters if they're accessed through the surrounding class instance instead of the interface. So the complement could be generic classes like this: type generic TTestGeneric = class(, ITest, IInterface2) private fTest: TTestImpl; public property Test: TTestImpl read fTest implements ITest; default; end; TMyTest = specialize TTestGeneric(); Something similar has already been asked: https://www.mail-archive.com/fpc-pascal@lists.freepascal.org/msg53599.html Michał. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TurboVision is reborn as FOSS (again)
W dniu 2020-12-26 o 16:34, Tomas Hajny via fpc-pascal pisze: On 2020-12-26 15:45, gabor via fpc-pascal wrote: W dniu 2020-12-22 o 04:57, Nikolay Nikolov via fpc-pascal pisze: . . Very interesting. But in a future version of the FV (or other TUI framework) apart from migrating from objects to classes, using component streaming, collections, etc... it would be good if the unit "drivers" were more abstract and not strictly dependent on Video, Mouse and Keyboard units. Then it will be possible to create a driver that, for example, renders the screen buffer in a win32-gdi window, or even in html5 canvas or LCL. There's nothing preventing you to implement unit video in these environments, IMHO. Of course, but then we need to finish what Charlie started - unicode. And think about possibility of including multiple drivers in single executable. Michał. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TurboVision is reborn as FOSS (again)
W dniu 2020-12-22 o 04:57, Nikolay Nikolov via fpc-pascal pisze: Anyway, any interest to develop Free Vision further is very welcome one, so we can move it from past tense to a future one. I still think text mode UI for console and terminals still has a place, but sadly the current FV implementation doesn't necessarily plays well on some Un*x terminals (it's highly dependent on the font, and many other factors), also a mono mode is sorely missing, which is a problem for both some modern and retro use cases. And yeah, on the high-end, Unicode would be needed. Speaking of Unicode, I have started working on adding Unicode support to the keyboard, video and mouse units (which are used internally by FV) in the unicodekvm branch. So, if anyone is interested in adding Unicode support to FV, take a look at this branch. Very interesting. But in a future version of the FV (or other TUI framework) apart from migrating from objects to classes, using component streaming, collections, etc... it would be good if the unit "drivers" were more abstract and not strictly dependent on Video, Mouse and Keyboard units. Then it will be possible to create a driver that, for example, renders the screen buffer in a win32-gdi window, or even in html5 canvas or LCL. Michał -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TurboVision is reborn as FOSS (again)
W dniu 2020-12-23 o 14:27, Graeme Geldenhuys via fpc-pascal pisze: On 22/12/2020 10:20 pm, gabor via fpc-pascal wrote: Sorry, I keep mistaking code point for character. I thought that the code point is a value in the range 0..10. I don't think I fully understand Unicode... Here in an example: https://en.wikipedia.org/wiki/Combining_character Two or more code points combined can form a "single character" when rendered on screen or paper. Sometimes you can replace those with a single "precomposed character" too. The Unicode standard includes many of them, but not all. https://en.wikipedia.org/wiki/Precomposed_character Hope that helps. Thanks, that is very helpful. But if I understand correctly, each such combination of code points can be properly represented by one code point (NFC normalization). Michał. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TurboVision is reborn as FOSS (again)
W dniu 2020-12-22 o 11:13, Marco van de Voort via fpc-pascal pisze: The problem is that multiple unicode codepoints might translate to one character. But that character might have variable width (1, 1.5, 2). And the rendering of codepoints to characters is output device (terminal, GUI canvas) dependent. Sorry, I keep mistaking code point for character. I thought that the code point is a value in the range 0..10. I don't think I fully understand Unicode... First and for all, I would keep the buffer private. This allows to keep the buffer in a format suitable to quickly convert to the output device, and access won't be simple array like anyway. This also abstracts final writing API and end device encoding. Maybe have multiple arrays, one for one codepoint per character, and one larger ones for additional ones. This way you can simply scan the larger array if there are additional ones, and if not, emit the primary one in a straightforward way. But an off-screen drawing buffer would also be useful. For example, FV uses such a buffer to draw views (TDrawBuffer = Array [0..MaxViewWidth - 1] Of Word). Buffer declared as an array of records with character and color elements could be easily and quickly drawn in another buffer. Michał. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TurboVision is reborn as FOSS (again)
W dniu 2020-12-21 o 23:41, Sven Barth via fpc-pascal pisze: > The main restriction is that it only supports ShortString and thus has > no Unicode support. I wonder which type would be best suited to store a unicode character (code point) for the screen buffer? type TScreenBuffer = array of record Character: TypeForUnicodeCodepoint; AttributeAndColor: TAttributeAndColor; end; Michał ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Are record fields zeroed on declaration of a record?
OK, is it possible to define the TMyRecord with default values so that when I do Default(TMyRecord) it will be non-zero defaults written instead of zeros? You can define typed constant and assign it to variable. type TMyRecord = record X, Y: Integer; S: String; end; const MYDEFREC: TMyRecord = (X: 1; Y: 2; S: 'ABC'); var R: TMyRecord; begin R := MYDEFREC; end. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Dynamic Arrays in Procedures
W dniu 2020-10-04 o 21:58, James Richters via fpc-pascal pisze: DoSomethingElse([$12,$1A,$2B]);for example… of course this doesn’t work, but is there a syntax that would work? This expression works fine with FPC 3.2.0 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
