[fpc-pascal] Trash variables (-gt) - Translation

[LacaK via fpc-pascal]

Hi *,
I am translating "Trash variables" (from English to Slovak), but I can 
not find appropriate words.

That's why I want to describe it in more words.
Is this correct: "Initialize local variables with random values" ? Or 
better suggestion?

Thanks
-Laco.

https://www.freepascal.org/docs-html/user/userap1.html:
-gt    Trash local variables (to detect uninitialized uses; multiple 
't' changes the trashing value)

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] no array support in sqldb/sqldbrestbridge?

[LacaK via fpc-pascal]

Hi,


So, is there no array field support in sqldb and/or in sqldbrestbridge?

there was added into DB.pas : TObjectField and TArrayField 
https://gitlab.com/freepascal.org/fpc/source/-/blob/main/packages/fcl-db/src/base/db.pas

but implementation is incomplete. Methods in fields.inc are empty.

Also in TSQLConnection descendants (like TPQConnection) there is no support.

-Laco.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] converting to UTF8

[LacaK via fpc-pascal]

procedure TestString;
var
  Original:string;
  Converted:string;
begin
  original:='ESPA'#209'A'; //ESPAÑA WIN1252
  Converted:=ansiToUtf8(original);  // converts to 'ESPA'#239#191#189'A'
 // converted Should be 'ESPA'#195#145'A'
end;

I've tried playing with strings types, string, rawstring,ansistring, 
utf8string. No way. Any hint?




To explicityly convert between run-time code pages you can use 
procedure: SetCodePage(var s: RawByteString; CodePage: TSystemCodePage; 
Convert: Boolean = True)


SetCodePage(original, 1252, False);
SetCodePage(original, CP_UTF8, True);

-Laco.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Text Only printing on Windows.

[LacaK via fpc-pascal]

Look at TPrinter.RawMode : 
https://lazarus-ccr.sourceforge.io/docs/lcl/printers/tprinter.rawmode.html 
and TPrinter.Write


 Printer.Title := 'xyz';
 Printer.RawMode := True;
 Printer.BeginDoc;
 Printer.Write('^MTD'); //direct thermal media
 Printer.EndDoc;

L.


Does anyone know of a way to just send pain text

to a USB printer with FPC ,preferably without Lazarus?




___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Repost: TFieldType declaration change in FPC fixes_3_2 branch

[LacaK via fpc-pascal]

/Reposted with correct branch identifier/.

I thought that a fixes branch was only for bug fixes and not for 
issuing non-backwards compatible changes. However, TFieldType in 
db.pas now has 6 extra elements.


The result is that IBX no longer compiles with the fixes_3_2 branch. I 
have also heard the same for zeoslib.


As far as I can see ZEOS is full of checks like:
{$IF FPC_FULLVERSION>=30100} ...

So I think that one more check:
{$IF FPC_FULLVERSION>30200}
  {$DEFINE WITH_FTSHORTINT} // ftShortInt 
is supported
  {$DEFINE WITH_FTBYTE} // ftByte is 
supported
  {$DEFINE WITH_FTEXTENDED} // ftExtended 
is supported

  {$DEFINE WITH_FTLONGWORD} // ftLongWord is
{$ENDIF}
... is not so big problem? (I see there is already in ZEOS such check 
added ...)


In IBX there you have "DefaultFieldClasses" array which is affected, right?

I agree that it is not ideal situation, but release cycle for major 
versions of FPC are so long that postpone all these additions to major 
releases means that users must wait years ...


L.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FreePascal and MySQL 8.0

[LacaK via fpc-pascal]

https://github.com/fpc/FPCSource/tree/main/packages/mysql

I do not understand. I see a source file for mysql80dyn.pp, but
shouldn't tthere also be a mysql80conn.pp?
It is in 
https://github.com/fpc/FPCSource/tree/main/packages/fcl-db/src/sqldb/mysql

L.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Conversion from C to Pascal - Left bit shift

[LacaK via fpc-pascal]

Can we say that in Pascal the result of:
    E1 shl E2
is of same type as E1 ?
(so if E1 is LongWord then result is LongWord also?)

What if there is an expression on left side:
    (E1*x) shl E2
Will E1*x promote to 64 bits (on 64 bit target)?


See documentation on automatic type conversion (the remarks section 
below table 3.3): 
https://www.freepascal.org/docs-html/ref/refsu4.html#x26-26004r3 

While this doesn't explicitly mention shift behaviour, it implies that 
E1 and (E1*x) will be promoted to native sized integer if smaller.  For 
the first example, if E1 is a longword on a 32 bit machine, the result 
should also be a longword.




But look at Delphi documentation: 
https://docwiki.embarcadero.com/RADStudio/Sydney/en/Expressions_(Delphi)#Logical_.28Bitwise.29_Operators


"The operations x shl y and x shr y shift the value of x to the left or 
right by y bits, which (if x is an unsigned integer) is equivalent to 
multiplying or dividing x by 2^y; the result is of the same type as x"


My understanding is, that in case:
  E1 shl E2 result is of E1 type (so if E1 is LongWord on 64 bit 
platform result is still LongWord?)


Case
  (E1*x) shl E2 is subject to native integer promotion I guess?

L.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Conversion from C to Pascal - Left bit shift

[LacaK via fpc-pascal]

Can we say that in Pascal the result of:
  E1 shl E2
is of same type as E1 ?
(so if E1 is LongWord then result is LongWord also?)

What if there is an expression on left side:
  (E1*x) shl E2
Will E1*x promote to 64 bits (on 64 bit target)?

-Laco.


Hello *,

I have code in C like this:
  E1 << E2
If E1 is of unsigned type then "The value of E1 << E2 is E1 
left-shifted E2 bit positions; vacated bits are zero-filled. If E1 has 
an unsigned type, the value of the result is E1 × 2^E2, reduced modulo 
one more than the maximum value representable in the result type."


I understand this as result of such operation does not grow over 32 
bits, right?


In Pascal I have:
  E1 shl E2
where E1 is of LongWord type.

On 64-bit target this result of shl can overcome 32 bits (iow operates 
on 32 bits)?
(does also bit shift operations works on 64 bits or this only affect 
arithmetic operations like multiply?)


Assembler suggests that shl works on 32 bits: shl    %cl,%r11d

-Laco.



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Conversion from C to Pascal - Left bit shift

[LacaK via fpc-pascal]

Hello *,

I have code in C like this:
  E1 << E2
If E1 is of unsigned type then "The value of E1 << E2 is E1 left-shifted 
E2 bit positions; vacated bits are zero-filled. If E1 has an unsigned 
type, the value of the result is E1 × 2^E2, reduced modulo one more than 
the maximum value representable in the result type."


I understand this as result of such operation does not grow over 32 
bits, right?


In Pascal I have:
  E1 shl E2
where E1 is of LongWord type.

On 64-bit target this result of shl can overcome 32 bits (iow operates 
on 32 bits)?
(does also bit shift operations works on 64 bits or this only affect 
arithmetic operations like multiply?)


Assembler suggests that shl works on 32 bits: shl    %cl,%r11d

-Laco.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Raise exception in libray which will not halt host application

[LacaK via fpc-pascal]

Please note that you won't be able to catch such an exception with 
the type from within the application, e.g.:


=== code begin ===

try
  SomeLibraryFunction;
except
  on e: TMyObject do
 Whatever;
  else
 WhateverElse;
end;

=== code end ===

The above code would go to the first branch *inside* your library, 
but it will *always* go to the else-branch outside your library, 
cause the comparison is done on the pointer to the VMT (the class 
type) which will be *different* between library and application 
(even if you use the same unit!). This is one of the main reasons 
why dynamic packages are needed for comfortable use of libraries in 
Object Pascal, because it allows such types to be shared across 
module boundaries.



My situation is even worser :-)
Library DLL is writen in Pascal, but main application is C/C#.


Then it will probably be caught as some external exception or such... 
don't know, never tried it.
*“System.Runtime.InteropServices.SEHException (0x80004005): External 
component has thrown an exception.”*





When I call in library RunError() then whole application aborts.
I need throw exception in library which can be catched in application.

I now use in unit which is used by library:

  if System.IsLibrary then
    raise TObject.Create // raise exception - type of exception is 
not important ...
    // can I call here also Windows's RaiseException()? ... so it 
will be propagated to linking application?

  else
    System.RunError(w);


"raise" internally uses . The only difference would be that you'd have 
a bit more control of exception code and such if you want to ensure 
that it's caught nicely by the C/C++/C# code.


Ok, then if raise TObject.Create; calls RaiseException then I think that 
I will use raise TObject.Create;

Thanks
L.*
*
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Raise exception in libray which will not halt host application

[LacaK via fpc-pascal]

Am 26.08.2021 um 10:10 schrieb LacaK via fpc-pascal:

Thank you for both answers!


Please note that you won't be able to catch such an exception with the 
type from within the application, e.g.:


=== code begin ===

try
  SomeLibraryFunction;
except
  on e: TMyObject do
 Whatever;
  else
 WhateverElse;
end;

=== code end ===

The above code would go to the first branch *inside* your library, but 
it will *always* go to the else-branch outside your library, cause the 
comparison is done on the pointer to the VMT (the class type) which 
will be *different* between library and application (even if you use 
the same unit!). This is one of the main reasons why dynamic packages 
are needed for comfortable use of libraries in Object Pascal, because 
it allows such types to be shared across module boundaries.



My situation is even worser :-)
Library DLL is writen in Pascal, but main application is C/C#.
When I call in library RunError() then whole application aborts.
I need throw exception in library which can be catched in application.

I now use in unit which is used by library:

  if System.IsLibrary then
    raise TObject.Create // raise exception - type of exception is not 
important ...
    // can I call here also Windows's RaiseException()? ... so it will 
be propagated to linking application?

  else
    System.RunError(w);

L.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Bookmark, TBookmarkStr, TBytes and BytesOf

[LacaK via fpc-pascal]

I have considered to convert the TBytes to AnsiString, but instead to 
doing a research about AnsiString internals, or creating a function 
that copies bytes in a loop, I supposed that there was already a 
function to do that. I found BytesOf

https://www.freepascal.org/docs-html/rtl/sysutils/bytesof.html
The abstract is  "Return the bytes in a string", when in fact, 
according with the text below,  it does the opposite, returns the 
string in an array of bytes.


Is there any function that move the bytes to an AnsiString?

AFAICS there is only 
https://www.freepascal.org/docs-html/rtl/sysutils/stringof.html

L.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Raise exception in libray which will not halt host application

[LacaK via fpc-pascal]

Thank you for both answers!
L.





On Thu, 26 Aug 2021, LacaK via fpc-pascal wrote:


Hello,
is there way how to raise exception in library without using SysUtils?


Raise TMyObject.Create()

Where TMyObject does not descend from Exception.

Sysutils is needed for the definition of the Exception class, and 
because it

installs some runtime error to exception conversion hooks, but you can
perfectly use exceptions without using the sysutils unit.

Michael.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Raise exception in libray which will not halt host application

[LacaK via fpc-pascal]

Hello,
is there way how to raise exception in library without using SysUtils?
Now I call System.RunError() in case unexpected situation occurs in 
library (DLL), but this exits also application which links library.
Is there way how to exit library in a way that application can catch 
exception (without SysUtils).
If there is Windows call which can be used it is sufficient, as library 
is Win64 only.

Thanks
-Laco.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Conditional compilation using {$IFOPT ...} and {$IF OPTION(...)}

[LacaK via fpc-pascal]

Hello,
looking at 
https://www.freepascal.org/docs-html/prog/progsu126.html#x139-142.4.1


There is mentioned "OPTION(opt)" with comment: "evaluates to TRUE if a 
compiler option is set (mode MacPas only). It is equivalent to the 
{$IFOPT } directive."


1. What is equivalent usage for {$IFOPT R+}?
{$IF OPTION(R)} ?

2. What means comment "(mode MacPas only)"?
It will does not work for example for ObjPas mode? In my case 
Compilation fails ... (with single {$IF OPTION(R)} ) -> Error: Compile 
time expression: Wanted Boolean but got AnsiString at IF or ELSEIF

Can this OPTION be enabled for all modes?

3. Is there way how to do OR with {$IFOPT}?
if I use {$IF OPTION(R) OR OPTION(D)}  I get: "Error: Compile time 
expression: Wanted Boolean but got AnsiString at IF or ELSEIF" ...

So is there way how to do it with {$IFOPT R+D+}?

Thanks
-Laco.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to get fpc and lazarus sources when svn has shut down?

[LacaK via fpc-pascal]

It's like switching car brands from a VW to an Audi or so.
Some buttons are in different places, your key will maybe look
different,
but that's it. It's a car, it brings you from a to b.

It's not switching brands, it's switching the type of the car.
from a passenger i.e. to a bus.
It's still a car, but the concept is a little different.

A file version system manages versions of files.
The actual commands differ a little, but that's it.


The human psychology. There were no particular problems for anyone to 
use SVN.
It worked fine. So for the people it doesn't seem like an obvious 
reason for the change.
The change is not recognized by the brain as a needed change, as a 
cure of some sort.

Instead it's recognized as an unnecessary burden.


I must say that I have similar feelings.
No matter ...
I have related question: in SVN was possible to checkout specific 
sub-directory (for example if I am interested in fcl-db package only I 
checkedout only this sub-directory).
Is it possible with gitlab? Or I must clone whole 
https://gitlab.com/freepascal.org/fpc/source ?

Thanks ...
-Laco.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Will the size of an executable depend on the uses clause

[LacaK via fpc-pascal]

Since the final binary size after using strip -s on the exe file is
271 kb it seems a bit big!
Or is there a lot behind the scenes I have missed?

Classes is a hog.


I had a look, and only tthreadlist (and with that tlist) were 
instantiated in the startupcode.
There are also global variables, which involve for example TComponent 
(and interfaces) ...
(see also thread "Minimal size of compiled library (DLL under Windows)" 
in this list from April 2021)

L.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Will the size of an executable depend on the uses clause

[LacaK via fpc-pascal]

Since the final binary size after using strip -s on the exe file is
271 kb it seems a bit big!
Or is there a lot behind the scenes I have missed?

Classes is a hog.

If you want smallest executable size you must get rid of SysUtils also.
And you must call platform dependent OS API ...

L.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] non-virtual class methods called from virtual regular method

[LacaK via fpc-pascal]

Dňa 29.4.2021 o 9:26 Michael Van Canneyt via fpc-pascal napísal(a):



On Thu, 29 Apr 2021, LacaK via fpc-pascal wrote:


Hi *,

consider the following example

T1 = class
  class procedure CP1;
  procedure P1; virtual;
end;

T2 = class(T1)
  class procedure CP1;
end;

procedure T1.P1;
begin
  CP1; // here is called allways T1.CP1, right?
  // if I want call T2.CP1 then class procedure CP1 must be also 
virtual, right?


Yes

  // so Self.CP1 does not take runtime type but is staticaly resolved 
at compile time to T1.CP1 ?


Yes.


This is bit counter-intuitive for me:

In regular virtual method, I expect, that Self resolves to runtime class 
type, thust calling CP1 should resolve to runtime type class method.


But from compiler POV I understand, that symbol CP1 must be somehow 
resolved at compile time, so compiler looks at CP1 method definition 
(and if not virtual then resolves to class method of type where is used).


In principle *virtual* class methods as such are for me strange ;-)




end;

var
  c1: T1;

begin
  c1:=T2.Create;
  c1.P1; // here is called T2.P1 - runtime class type
end.

Thanks

Btw If I need for various class descendants define various class 
constants, it is possible only by using class functions (getters), 
where descendant class getter hides parents getter?


If they depend on the class, they're not "constants" to begin with, so a
getter function is the right approach. For such purposes I use virtual 
class

functions.


Yes, on other side virtual constants will be construct which I would 
understand better:


If I need override some class wide parameter:

T1 = class
  private const CPORT=0; // virtual
end;

T1 = class (T2)
  private const CPORT=2; // override
end;

Now I must do:

T1 = class
  private class procedure GetPORT: integer; virtual;
end;

T2 = class(T1)
  private class procedure GetPORT: integer; override;
end;

class procedure T1.GetPORT: integer;
begin
  Result := 0;
end;

class procedure T2.GetPORT: integer;
begin
  Result := 2;
end;

I accept, that polymorphism in class inheritance work this way ...

L.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] non-virtual class methods called from virtual regular method

[LacaK via fpc-pascal]

Hi *,

consider the following example

T1 = class
  class procedure CP1;
  procedure P1; virtual;
end;

T2 = class(T1)
  class procedure CP1;
end;

procedure T1.P1;
begin
  CP1; // here is called allways T1.CP1, right?
  // if I want call T2.CP1 then class procedure CP1 must be also 
virtual, right?
  // so Self.CP1 does not take runtime type but is staticaly resolved 
at compile time to T1.CP1 ?

end;

var
  c1: T1;

begin
  c1:=T2.Create;
  c1.P1; // here is called T2.P1 - runtime class type
end.

Thanks

Btw If I need for various class descendants define various class 
constants, it is possible only by using class functions (getters), where 
descendant class getter hides parents getter?


-Laco.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Inline assembler m32 source operand

[LacaK via fpc-pascal]

Hi,

how can I address m32 source operand in inline assembler instruction like :

asm
  ...
  VBROADCASTSS m32, %xmm1;
  ...
end;

if I would like broadcast to %xmm10 single 32bit value at given memory 
location in:


const SI:single=0.1;
or
var SI:single=0.1;

Now I do it by (it works):
asm
  ...
  mov $SI, %rax;
  vbroadcastss (%rax), %xmm10;
  ...
end;

00010020C4CF 48b8b04327000100 movabs $0x1002743b0,%rax
00010020C4D9 c462791810   vbroadcastss (%rax),%xmm10

Is there shorter - one liner - way? Something like:
  vbroadcastss SI, %xmm10; // compiles, but causes A/V when executed, 
because only low 32bit of address is taken (x86_64):


00010020C4D9 c46279181425b0432700 vbroadcastss 0x2743b0,%xmm10

Thanks

-Laco.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Minimal size of compiled library (DLL under Windows)

[LacaK via fpc-pascal]

May be, that important word is here "referenced" code.
Once some code (procedure, class) is referenced then this code is linked 
/ included.
It does not play role if it is really required by program / library ... 
right?


L.


So we see that classes like TComponent and also interfaces are touched,
but they are used only in conjuction with initilizing some global
variables like InitHandlerList, GlobalNameSpace.

But these variables are never used in my library. Only again in
finalization sections of above mentioned units.

They are used in your library as far as the linker is concerned, because
the init and finalisation sections are code like any other code.


Does it means, that smart-linking can not remove this code due to usage
of this global variables in finalization section (resp. initialization
sections)?

Indeed.


Probably it is too hard task for linker to determine which code is realy
not needed ... WPO in this regard can not help?

No. There is no way for WPO to know what side effects the initialisation
of those variables could have.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Minimal size of compiled library (DLL under Windows)

[LacaK via fpc-pascal]

I am guessing, that there must be something in initialization 
sections of units (SysUtils and Classes), which cause that some code 
is included, right?
Can I somehow to avoid this grow of size (for example I need from 
Classes only TFPList)?


Not in an easy way at the moment, I don't expect it to change anytime 
soon.


The problem is probably the streaming system that the compiler can't 
easily determine if it is used runtime. This also has resourcestrings 
as errors, uses typeinfo etc etc.  I also see interface related 
support probably because tcomponent also implements interfaces.



What I can say is, that in initialization sections are touched:

SysUtils: WidestringManager, Exceptions, FormatSettings
Classes: TCriticalSection, TList, TThreadList, TComponent 
(IUnknown,IDispatch, RegisterInitComponentHandler() -> var 
InitHandlerList), Interface (var GlobalNameSpace: IReadWriteSync)


So we see that classes like TComponent and also interfaces are touched, 
but they are used only in conjuction with initilizing some global 
variables like InitHandlerList, GlobalNameSpace.


But these variables are never used in my library. Only again in 
finalization sections of above mentioned units.


Does it means, that smart-linking can not remove this code due to usage 
of this global variables in finalization section (resp. initialization 
sections)?


Probably it is too hard task for linker to determine which code is realy 
not needed ... WPO in this regard can not help?


-Laco.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Minimal size of compiled library (DLL under Windows)

[LacaK via fpc-pascal]

Hi,I did small test project for library:(with -CX -WR -O3 -Xs -XX options set)library library1;{$mode objfpc}{$H+}uses  SysUtils, Classes;beginend.  Compilation produces DLL with size 200+ KB.When in uses is only SysUtils then size is under 100 KB.Whene there are not units in uses clause then size is under 40 K
 B.I am guessing, that there must be something in initialization sections of units (SysUtils and Classes), which cause that some code is included, right?Can I somehow to avoid this grow of size (for example I need from Classes only TFPList)?TIA-Laco.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Smart-linking versus Whole Program Optimization

[LacaK via fpc-pascal]

It will be nice have this in documentation. For example in
https://www.freepascal.org/docs-html/prog/progse30.html#x195-207.3

At least explain:
- relation of -CX and -XX

Indeed.


- what is to be removed: non-referenced non-virtual methods, global
variables, and regular procedures/functions

Disagreed. Those are implementation details, may vary from target to
target, may depend on the assembler/linker rather than on FPC, etc. What
I wrote is just the high level idea. When you have e.g. published
properties and their RTTI, you can easily start having a lot of hidden
references.
I do not insist that it must be written in this way, but something 
should be there explained.


Goal is that: reader should understand what can expect from smart-linking.

-Laco.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Smart-linking versus Whole Program Optimization

[LacaK via fpc-pascal]

It will be nice have this in documentation. For example in 
https://www.freepascal.org/docs-html/prog/progse30.html#x195-207.3


At least explain:
- relation of -CX and -XX
- what is to be removed: non-referenced non-virtual methods, global 
variables, and regular procedures/functions

- (may be some infos about behavior on various targets)

-Laco.



On 10/03/2021 13:17, Yuriy Sydorov via fpc-pascal wrote:

On 10.03.2021 11:34, LacaK via fpc-pascal wrote:

A.) I compile my (units) program/library with -CX -XX (set in Project
Options)


Just a small note:

-CX -XX are not needed for the top-tier targets nowadays. The section
based smart linking is a default option in recent FPC versions.

At least -XX is still necessary, otherwise we don't enable dead
code/data stripping in the linker (at least not on Linux). And on macOS,
-CX is also needed, otherwise the compiler does not emit a directive in
the object files that dead code/data stripping should be enabled based
on whether or not there are references to the global symbols preceding them.

Neither parameter may be necessary on Windows, but that's probably the
only one.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Smart-linking versus Whole Program Optimization

[LacaK via fpc-pascal]

Hi,

my goal is DO NOT include unused procedures, methods in final 
program/library on Win32 target exe/dll.


A.) I compile my (units) program/library with -CX -XX (set in Project 
Options)


B.) I did also experiments with WPO: -OWall -FWprogram.wpo -Xs- (plus 
-Owall -Fwprogram.wpo)


Questions:

1. I did not notice difference between A and B (it seems like WPO did 
not reduce size of EXE (may be that I do something wrong))
1.1 is there way how I can check which procedures were striped out or 
vice-versa included?


2. Is smart-linking/WPO capable to remove unused:
2.1  regular procedures/functions ?
2.2  methods of classes (non virtual, virtual) ?
2.3  class methods of classes ?

Thank you

-Laco.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Cannot write datetime field on sqlite3 database on ARM

[LacaK via fpc-pascal]

Dňa 9.3.2021 o 15:34 Toru Takubo via fpc-pascal napísal(a):

On 2021/03/09 18:11, LacaK via fpc-pascal wrote:
I did run test program on RaspberryPI: Linux+ARM and results are as 
expected.

(FPC 3.2.0)

-Laco.

Thank you for your reproduction test. It may be a good news that the 
problem would

not be in the compiler but around configuration or environment.

Do you have a native compiler on RaspberryPI, or using cross compiler?


I am using cross compiler. (build by FpcUpDeluxe)



My compiler setting is below. Does something missing or wrong?


My settings are:

-Tlinux
-Parm
-MObjFPC
-Scghi
-O1
-g
-gl
-l
-vewnhibq
-Filib\arm-linux
-Fu.
-FUlib\arm-linux
-FE.
-oproject1



---
C:\lazarus\fpc\3.2.0\bin\i386-win32\fpc.exe
-Tlinux
-Parm
-MObjFPC
-Sh
-CX
-O3
-XX
-l
-vewnibq
-vh-
-vm5057,5028,5024,3042
-Fiobj\arm-linux
-Fu.
-FEobj\arm-linux
-oobj\arm-linux\project1
---

If possible, would you publish your executive of the test program to 
try it?


Uploaded to 
http://moja.uschovna.zoznam.sk/link/af6c3620-b919-4d64-9ab4-978af3d84717


-Laco.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Cannot write datetime field on sqlite3 database on ARM

[LacaK via fpc-pascal]

I did run test program on RaspberryPI: Linux+ARM and results are as 
expected.

(FPC 3.2.0)

-Laco.

Dňa 9.3.2021 o 1:47 Toru Takubo via fpc-pascal napísal(a):

On 2021/03/08 16:54, Michael Van Canneyt via fpc-pascal wrote:



On Mon, 8 Mar 2021, Toru Takubo via fpc-pascal wrote:


Hi,

I am developing my app on Windows and building apps for other
platforms by using cross compiler. Now I have a problem only
occurred on Linux ARM.

The problem is that it cannot write datetime field on sqlite3
database. It can read/write other fields like int, varchar
or blob, but always write zero in datetime (maybe float as well)
field.

Does anyone have an idea about this issue? I am not sure it is
fpc issue, but better to report bug?


It sounds like a floating point problem. As you probably know, a 
TDateTime

type is actually a double type. Did you try with a float value ?

The DB explorer tools probably just use strings to read/write from the
database, so they will not be bothere by such things, but FPC stores 
dataset

values in 'native' formats in memory.

I don't know what to advise to further investigate the issue, One 
thing to
try would be to test whether normal float arithmetic or date 
arithmetic works.

If not, then the compiler people will need to give more advice.



I created a simple test code, and ran on linux-i386 and linux-arm.
Test on linux-i386 is OK but on linux-arm, I got unexpected values
"30-12-99" as datetime and "2.12199579096527E-314" as float, which are 
different

from values previously set. (except INT and VARCHAR fields)

---linux-i386
INT, VARCHAR,   DATETIME,   DOUBLE
0, 9-3-21 08:50:23, 9-3-21 08:50:23, 0
1, 9-3-21 12:16:06, 9-3-21 12:16:06, 0.142857142857143
2, 9-3-21 15:41:49, 9-3-21 15:41:49, 0.285714285714286
3, 9-3-21 19:07:32, 9-3-21 19:07:32, 0.428571428571429
4, 9-3-21 22:33:15, 9-3-21 22:33:15, 0.571428571428571
5, 10-3-21 01:58:58, 10-3-21 01:58:58, 0.714285714285714
6, 10-3-21 05:24:40, 10-3-21 05:24:40, 0.857142857142857
7, 10-3-21 08:50:23, 10-3-21 08:50:23, 1
8, 10-3-21 12:16:06, 10-3-21 12:16:06, 1.14285714285714
9, 10-3-21 15:41:49, 10-3-21 15:41:49, 1.28571428571429

---linux-arm-
INT, VARCHAR,   DATETIME,   DOUBLE
0, 9-3-21 08:55:53, 30-12-99, 2.12199579096527E-314
1, 9-3-21 12:21:36, 30-12-99, 2.12199579096527E-314
2, 9-3-21 15:47:18, 30-12-99, 2.12199579096527E-314
3, 9-3-21 19:13:01, 30-12-99, 2.12199579096527E-314
4, 9-3-21 22:38:44, 30-12-99, 2.12199579096527E-314
5, 10-3-21 02:04:27, 30-12-99, 2.12199579096527E-314
6, 10-3-21 05:30:10, 30-12-99, 2.12199579096527E-314
7, 10-3-21 08:55:53, 30-12-99, 2.12199579096527E-314
8, 10-3-21 12:21:36, 30-12-99, 2.12199579096527E-314
9, 10-3-21 15:47:19, 30-12-99, 2.12199579096527E-314

I used a shared library libsqlite3.so included in the "DB Browser for 
SQLite",
so it should work. What can cause such a problem only in the specific 
field

on the specific platform?

Thank you in advance for any advice.

Toru




___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Initialization of constant pointer type - bug? [was: Re: Initialization of constant record member of pointer type]

[LacaK via fpc-pascal]

Hello,

this compiles under FPC 3.0.4

const
  s: AnsiString = 'abc';
  p: pointer = @s[1];

but not under FPC 3.2.0
(I checked old Delphi XE and there it does not compile also)

Is it regression bug or not?

-Laco.






Thank you, yes it works. I have used:

const
   MyConst1: AnsiString = 'abc'
   MyConst2: TMyRec = (a: @MyConst1[1]);


It doesn't compile with fpc 3.2.0 (I'm trying, without success so 
far, your open62541 translation).



Yes, you are right. That ^ compiles under FPC 3.0 but not under FPC 3.2

I have updated test program (now compiles also under FPC 3.2)

Thanks

-Laco.



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Initialization of constant record member of pointer type

[LacaK via fpc-pascal]

Because MyConst1 is not an *untyped* constant. Only untyped 
constants can be used in constant expressions (a pointer to 
something can be considered an untyped constant).


The following might work though I did not test it:

=== code begin ===

const
   MyStr = 'abc'
   MyConst1: AnsiString = MyStr;
   MyConst2: TMyRec = (l: Length(MyStr); a: @MyConst1[1]);


=== code end ===


Yes it works, but I must define 2 constants (MyStr and MyConst1),
which is not so nice ;-)

It would be nice to have support for true constants:

const
   MyConst1 = 'abc' ;
   MyConst2: TMyRec = (l: Length(MyConst1); a: @MyConst1[1]);

But may be that there are technical reasons why it is problematic 
(may

be that true constants are stored in another memory locations, which
can not be easy addressed)


Yes, that's one of possible reasons.

Regarding Length in constant value assignment - remember that 
Length is a function. In case of real constants, the call may be 
replaced by the compiler with the constant value. However typed 
constants may not be constant, so generic replacement throughout 
the source code at compile time is not possible (if it appears in 
the main body or some function, the length may already be changed 
to something else) and selective replacement may result in a 
behaviour not expected by the user. The only questionable case is 
IMHO the case of {$WRITEABLECONST OFF} - the compiler _might_ be 
able to perform the compile-time substition in that case (and thus 
allow using Length of such a constant in constant value 
assignment), but it doesn't do that in that case either apparently.


Yes I have no problem with {$WRITEABLECONST OFF} if it will allow 
Length().


Somewhere I read (may be in Delphi documentation) that some intristic
functions like Low(), High(), Pred() and also Length() etc. can be
used in constant expressions because compiler can evaluate them if
theirs arguments are also constants.
Which is the case in my example.
For now {$WRITEABLECONST OFF} does not help ;-)


Yes, that's what I mentioned as well, but it might be changed for 
this particular case. You might create a ticket for that if Delphi 
allows to use Length that way; obviously, you might create such a 
ticket even if Delphi doesn't allow to do that. ;-)


I checked it with older Delphi XE and it seems, that Delphi XE does 
not support Length() for typed constant also when {$WRITEABLECONST OFF}


I do not believe that this will be accepted for FPC, so I don not 
open new feature request in bug tracker.


On other side FPC developers read this mailing list so if they 
consider this as a useful/doable feature may be that someone will 
take look at it 


I just happened to write a construct like this (in Delphi):

const
  X_0: array[0..4276] of SmallInt = (.

  MAP: array['0'..'9'] of TSomething = (
    (Samples: @X_0; Count: Length(X_0)), ...



In FPC is possible also (with "array of AnsiChar"):

   MyConst1: array[0..2] of AnsiChar = 'abc';
   MyConst2: TMyRec = (l: Length(MyConst1); a: @MyConst1);

(but it does not work with plain "AnsiString" as mentioned above)

-Laco.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Initialization of constant record member of pointer type

[LacaK via fpc-pascal]

Thank you, yes it works. I have used:

const
   MyConst1: AnsiString = 'abc'
   MyConst2: TMyRec = (a: @MyConst1[1]);


It doesn't compile with fpc 3.2.0 (I'm trying, without success so far, 
your open62541 translation).



Yes, you are right. That ^ compiles under FPC 3.0 but not under FPC 3.2

I have updated test program (now compiles also under FPC 3.2)

Thanks

-Laco.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Initialization of constant record member of pointer type

[LacaK via fpc-pascal]

Dňa 2.12.2020 o 16:09 Tomas Hajny via fpc-pascal napísal(a):

On 2020-12-02 16:01, LacaK via fpc-pascal wrote:

Dňa 2.12.2020 o 13:55 Tomas Hajny via fpc-pascal napísal(a):

On 2020-12-01 11:39, Ladislav Karrach via fpc-pascal wrote:


Because MyConst1 is not an *untyped* constant. Only untyped 
constants can be used in constant expressions (a pointer to 
something can be considered an untyped constant).


The following might work though I did not test it:

=== code begin ===

const
   MyStr = 'abc'
   MyConst1: AnsiString = MyStr;
   MyConst2: TMyRec = (l: Length(MyStr); a: @MyConst1[1]);


=== code end ===


Yes it works, but I must define 2 constants (MyStr and MyConst1),
which is not so nice ;-)

It would be nice to have support for true constants:

const
   MyConst1 = 'abc' ;
   MyConst2: TMyRec = (l: Length(MyConst1); a: @MyConst1[1]);

But may be that there are technical reasons why it is problematic (may
be that true constants are stored in another memory locations, which
can not be easy addressed)


Yes, that's one of possible reasons.

Regarding Length in constant value assignment - remember that Length 
is a function. In case of real constants, the call may be replaced 
by the compiler with the constant value. However typed constants may 
not be constant, so generic replacement throughout the source code 
at compile time is not possible (if it appears in the main body or 
some function, the length may already be changed to something else) 
and selective replacement may result in a behaviour not expected by 
the user. The only questionable case is IMHO the case of 
{$WRITEABLECONST OFF} - the compiler _might_ be able to perform the 
compile-time substition in that case (and thus allow using Length of 
such a constant in constant value assignment), but it doesn't do 
that in that case either apparently.


Yes I have no problem with {$WRITEABLECONST OFF} if it will allow 
Length().


Somewhere I read (may be in Delphi documentation) that some intristic
functions like Low(), High(), Pred() and also Length() etc. can be
used in constant expressions because compiler can evaluate them if
theirs arguments are also constants.
Which is the case in my example.
For now {$WRITEABLECONST OFF} does not help ;-)


Yes, that's what I mentioned as well, but it might be changed for this 
particular case. You might create a ticket for that if Delphi allows 
to use Length that way; obviously, you might create such a ticket even 
if Delphi doesn't allow to do that. ;-)


I checked it with older Delphi XE and it seems, that Delphi XE does not 
support Length() for typed constant also when {$WRITEABLECONST OFF}


I do not believe that this will be accepted for FPC, so I don not open 
new feature request in bug tracker.


On other side FPC developers read this mailing list so if they consider 
this as a useful/doable feature may be that someone will take look at it ...


Thanks

-Laco.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Initialization of constant record member of pointer type

[LacaK via fpc-pascal]

Dňa 2.12.2020 o 13:55 Tomas Hajny via fpc-pascal napísal(a):

On 2020-12-01 11:39, Ladislav Karrach via fpc-pascal wrote:


Because MyConst1 is not an *untyped* constant. Only untyped 
constants can be used in constant expressions (a pointer to 
something can be considered an untyped constant).


The following might work though I did not test it:

=== code begin ===

const
   MyStr = 'abc'
   MyConst1: AnsiString = MyStr;
   MyConst2: TMyRec = (l: Length(MyStr); a: @MyConst1[1]);


=== code end ===


Yes it works, but I must define 2 constants (MyStr and MyConst1),
which is not so nice ;-)

It would be nice to have support for true constants:

const
   MyConst1 = 'abc' ;
   MyConst2: TMyRec = (l: Length(MyConst1); a: @MyConst1[1]);

But may be that there are technical reasons why it is problematic (may
be that true constants are stored in another memory locations, which
can not be easy addressed)


Yes, that's one of possible reasons.

Regarding Length in constant value assignment - remember that Length 
is a function. In case of real constants, the call may be replaced by 
the compiler with the constant value. However typed constants may not 
be constant, so generic replacement throughout the source code at 
compile time is not possible (if it appears in the main body or some 
function, the length may already be changed to something else) and 
selective replacement may result in a behaviour not expected by the 
user. The only questionable case is IMHO the case of {$WRITEABLECONST 
OFF} - the compiler _might_ be able to perform the compile-time 
substition in that case (and thus allow using Length of such a 
constant in constant value assignment), but it doesn't do that in that 
case either apparently.


Yes I have no problem with {$WRITEABLECONST OFF} if it will allow Length().

Somewhere I read (may be in Delphi documentation) that some intristic 
functions like Low(), High(), Pred() and also Length() etc. can be used 
in constant expressions because compiler can evaluate them if theirs 
arguments are also constants.

Which is the case in my example.
For now {$WRITEABLECONST OFF} does not help ;-)

-Laco.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Initialization of constant record member of pointer type

[LacaK via fpc-pascal]

Dňa 30.11.2020 o 23:26 Sven Barth via fpc-pascal napísal(a):

Am 30.11.2020 um 13:20 schrieb LacaK via fpc-pascal:

Hi,

is there a way how to initialize record member of pointer type (other 
than PChar) in the following example:


type
  TMyRec=record
    a: PByte; // if I change PByte to PAnsiChar then it works
  end;

const
  MyConst: TMyRec = (a: 'abcd'); // I want to a points to static 
memory where 'abcd' is stored


I would like to initialize a to be pointer to another known constant 
or directly to supplied string constant.


For example something like:

const
  MyConst1='abcd';
  MyConst2=TMyRec = (a: @MyConst1);


Untyped constants don't have an address you can take. You need to use 
a typed constant:


=== code begin ===

const
  MyConst1: Byte = 123;
  MyConst2: TMyRec = (a: @MyConst1);

=== code end ===


Thank you, yes it works. I have used:

const
  MyConst1: AnsiString = 'abc'
  MyConst2: TMyRec = (a: @MyConst1[1]);

unfortunately it seems, that I can not use Length(MyConst1) in:

type
  TMyRec=record
    l: integer;
    a: PByte;
  end;

const
  MyConst1: AnsiString = 'abc';
  MyConst2: TMyRec = (l: Length(MyConst1); a: @MyConst1[1]);

Why is it prohibited?

-Laco.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Initialization of constant record member of pointer type

[LacaK via fpc-pascal]

Hi,

is there a way how to initialize record member of pointer type (other 
than PChar) in the following example:


type
  TMyRec=record
    a: PByte; // if I change PByte to PAnsiChar then it works
  end;

const
  MyConst: TMyRec = (a: 'abcd'); // I want to a points to static memory 
where 'abcd' is stored


I would like to initialize a to be pointer to another known constant or 
directly to supplied string constant.


For example something like:

const
  MyConst1='abcd';
  MyConst2=TMyRec = (a: @MyConst1);

TIA

-Laco.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] -Fu unit search path and network paths

[LacaK via fpc-pascal]

are supported in -Fu (unit search path) networks paths? i.e. 
-Fu\\server\share -Fu\\server\share\path ?
Correction: unit cannot be found only if it is placed in "share 
root" \\server\share !

When is placed in \\server\share\path then it is found.

Why?


Possibly Share vs directory.   A directory has 4 slashes 
(\\x\y\

Try \\server\share\.
*Does not works. More confusing is that, when I map \\server\share 
to F:\ and I add F:\ to search path it does not work also!

*

*(if unit is in any subdirectory i.e. F:\something then it works ... 
so only root does not work!)*


*
*


[0.015] Handling option "-Fud:\"
[0.015] interpreting option "-Fud:\"
[0.015] Path "D:\" not found

So the path exist function probably fails on root dirs.


This looks like the infamous wrong implementation of checking of 
directory existence based on reading its attributes (which doesn't 
work for the root directory, because it has no specific entry on the 
file-system and thus also no attributes, at least on DOS-like systems) 
without special handling of the special case of the root directory:


cfileutl.pas, line 361-375 (trunk):

    function TCachedDirectory.DirectoryExists(const 
AName:TCmdStr):boolean;

  var
    Attr : Longint;
  begin
    if not TryUseCache then
  begin
    Result:=PathExists(Name+AName,false);
    exit;
  end;
    Attr:=GetItemAttr(AName);
    if Attr<>0 then
  Result:=((Attr and faDirectory)=faDirectory)
    else
  Result:=false;
  end;

I suggest filing a bug report.


Reported https://bugs.freepascal.org/view.php?id=37793

If you can add there more details please do it ;-)

-Laco.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] -Fu unit search path and network paths

[LacaK via fpc-pascal]

Dňa 21.9.2020 o 12:35 Marco van de Voort via fpc-pascal napísal(a):


Op 2020-09-21 om 08:57 schreef LacaK via fpc-pascal:



Hi *,

are supported in -Fu (unit search path) networks paths? i.e. 
-Fu\\server\share -Fu\\server\share\path ?
Correction: unit cannot be found only if it is placed in "share root" 
\\server\share !

When is placed in \\server\share\path then it is found.

Why?


Possibly Share vs directory.   A directory has 4 slashes 
(\\x\y\

Try \\server\share\.
*Does not works. More confusing is that, when I map \\server\share to 
F:\ and I add F:\ to search path it does not work also!

*

*(if unit is in any subdirectory i.e. F:\something then it works ... so 
only root does not work!)*


*
*



Note that probably none of this is supported, just coincidence because 
Windows functions interpret it themselves.


*But how to explain cause with F:\ ?*

*
*

*L.*
**


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] -Fu unit search path and network paths

[LacaK via fpc-pascal]

Hi *,

are supported in -Fu (unit search path) networks paths? i.e. 
-Fu\\server\share -Fu\\server\share\path ?
Correction: unit cannot be found only if it is placed in "share root" 
\\server\share !

When is placed in \\server\share\path then it is found.


Addition:

when I use in *uses* clause:

use unit1 in '\\server\share\unit1.pas'

then *it works* also when I omit search path from -Fu (no search paths 
specified in Project Options)


strange, does not?


Why?


When I am compiling project, which is located on local drive, but 
uses units from network, error is raised while compiling project file 
.lpr "Cannot find XYZ used by ..."

(when I map network path to drive letter then it works as expected)

TIA

-Laco.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] -Fu unit search path and network paths

[LacaK via fpc-pascal]

Hi *,

are supported in -Fu (unit search path) networks paths? i.e. 
-Fu\\server\share -Fu\\server\share\path ?
Correction: unit cannot be found only if it is placed in "share root" 
\\server\share !

When is placed in \\server\share\path then it is found.

Why?


When I am compiling project, which is located on local drive, but uses 
units from network, error is raised while compiling project file .lpr 
"Cannot find XYZ used by ..."

(when I map network path to drive letter then it works as expected)

TIA

-Laco.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] -Fu unit search path and network paths

[LacaK via fpc-pascal]

Hi *,

are supported in -Fu (unit search path) networks paths? i.e. 
-Fu\\server\share -Fu\\server\share\path ?
When I am compiling project, which is located on local drive, but uses 
units from network, error is raised while compiling project file .lpr 
"Cannot find XYZ used by ..."

(when I map network path to drive letter then it works as expected)

TIA

-Laco.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] String literals and code page of .pas source file

[LacaK via fpc-pascal]

<<< text/html;charset=utf-8: Unrecognized >>>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Sending Hex codes over TCP/IP

[LacaK via fpc-pascal]

Dňa Fri, 11 Sep 2020 19:13:38 -0400 James Richters via fpc-pascal  napísal:> What I'm trying to do is control some different ethernet relays. > They use> MODBUS TCP.   I'm trying to keep it as simple as possible.  I found >a modbus> library for Pascal but it was way over complicated for that I need >to do,> and while it  looks like it would do some cool stuff,  the one >function I> need wasn't implemented yet.> You can look at my simple MODBUS TCP implementation ... http://lacak.users.sourceforge.net/freepascal.htmlI think that it is simple/straightforward to understand.If there is something not implemented yet I can add it
  ... (I just implemented what I needed for my work project)-Laco.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] String literals and code page of .pas source file

[LacaK via fpc-pascal]

>  .>>> The implicit conversion is explicitly expected by the user>>> in this case if I understand it correctly (source in CP1250), right?>> >> If you mean the "non implicit conversion" requires explicit>> conversion by the user, then yes.> > No, I mean that the original poster explicitly mentioned that he >expected the implicit conversion to be performed as necessary when he >specified that his source code was in CP1250.> Yes It was my first strict expectation: - code page of source file explicityl specified {$cod
 epage 1250}- string constants are in this encoding so compiler is aware of encoding string constantsMy second relaxed expectation was:- if string variable is of type String(1250) (and initialized to string constant) then if assigned to string(CP_ACP), which I take as two distinct types, conversion should happen. But something goes wrong "in Lazarus".To be fair, pure FPC console program (with DefaultSystemCodePage set to UTF-8) shows correct results, but in Lazarus the behavior is "strange". I believe, that this "strange" behavior can be explain
 ed, but for me is it hard to follow.My conclusion up to now is, that dynamic code page of strings is not taken into account when assigned to Caption. Caption expects UTF-8, but supplied is cp1250. So only way how to handle this is do conversion explicitly in my code or use WideString, which works as expected and can be shared between Delphi7 and Lazarus.Questions which remains for me unanswered:1. does FPC checks for dynamic code page of strings parameters in WriteLn() ? It should explain why strings are displayed correctly in console application2. does my guess "if code page of source file = declared code page of string then compiler does not insert conversion code" is right?3. does my guess "if destination code page of string is CP_ACP and source is string literal (in source file code page) then no conversion code is inserted" is right?-Laco.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] String literals and code page of .pas source file

[LacaK via fpc-pascal]

> This is a bit counter intuitive to me.

It is explained here:
https://wiki.freepascal.org/Unicode_Support_in_Lazarus

IMO "c4" case (c4: String1250 = 'áéíóčž';) is not fully explained. 
Probably what here happens is, that declared code page of c4 = source 
file code page and in that case compiler does not insert conversion 
code. StringCodePage(c4)=1250 (also StringCodePage(c2)=1250) so dynamic 
code page is right, but when assigning to TLabel.Caption current dynamic 
code page is not taken into account



For LacaK I recommend using UTF-8 encoding as much as possible. Then 
everything "/just works/".


yes I use this, but I have "one" specific case where I want share one 
file between Delphi7 and Lazarus



You could have a unit or .inc file with WinCP constants for Delphi7, 
and then some IFDEFs. They should be explicitly converted to UTF-8 for 
LCL.


UnicodeString constants can also be a good solution. It triggers an 
automatic conversion when assigned to a String variable. The 
conversion is usually fast enough.


Yes this is what I use (WideString constants) and it is only solution 
which works for me in Delphi7/Lazarus


Thanks

L.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] String literals and code page of .pas source file

[LacaK via fpc-pascal]

attached simple Lazarus compilable project (one Form).

...
type
   String1250 = type AnsiString(1250);

const
   c2: AnsiString = 'áéíóčž';
   c3: WideString = 'áéíóčž';
   c4: String1250 = 'áéíóčž';

{ TForm1 }

procedure TForm1.FormShow(Sender: TObject);
begin
   label1.Caption:='áéíóčž'; // FAIL
   label2.Caption:=c2;   // FAIL
   label3.Caption:=c3;   // OK
   label4.Caption:=c4;   // FAIL
end;

The attached pure FPC-variant of your project works fine with FPC 3.2.0
for me (except for the very first writeln, because that one gets
interpreted as "writeln(shortstring)"),


*yes for me on Windows it works also (under Lazarus 2.0.8 with FPC 3.0.4)
*

*
*


  so it may be Lazarus-specific.
Best ask it on the Lazarus list or post it on their bug tracker instead.


*I add CC also to Lazarusdev group
(attached simple project)
*

*
*



Also make sure you did *not* build your Lazarus with -dDisableUTF8RTL


*I do not build Lazarus with -dDisableUTF8RTL (I simply use default 
installation)*


*As Sven wrote there is at least "c4" case, where declared code page 
(AnsiString(1250)) is different from AnsiString (CP_ACP) codepage and 
also from dynamic code page (DefaultSystemCodepage which is under 
Lazarus (UTF8=65001))*


*I am still confused how this CodePage aware stuff is expected to work 
and when implicit conversios are included (as far as I understand here 
ONLY declared/static codepage plays role) and when dynamic codepage is 
taken into account and when not?*


*L.*


<>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] String literals and code page of .pas source file

[LacaK via fpc-pascal]

Hello Jonas,

attached simple Lazarus compilable project (one Form).

...
type
  String1250 = type AnsiString(1250);

const
  c2: AnsiString = 'áéíóčž';
  c3: WideString = 'áéíóčž';
  c4: String1250 = 'áéíóčž';

{ TForm1 }

procedure TForm1.FormShow(Sender: TObject);
begin
  label1.Caption:='áéíóčž'; // FAIL
  label2.Caption:=c2;   // FAIL
  label3.Caption:=c3;   // OK
  label4.Caption:=c4;   // FAIL
end;

TIA

-Laco.



I would like to have source file in Windows-1250 encoding, where are
stored literal strings like 'áéíóčž' in Windows-1250 encoding (I share
this one file between FPC/Lazarus and Delphi 7). Windows-1250 is also
ANSI code page of my Windows OS. In source file I have:

{$IFDEF FPC}
   {$CODEPAGE cp1250}
{$ENDIF}

and in Lazarus I have set: File settings / Encoding / CP1250
(at this point in .pas file are all characters correctly encoded in
Windows-1250 code page)

When I compile application and run it, string literals (characters with
accents) are not preserved.
Is there way how to get it working?

The attached program uses the same environment as Lazarus
(DefaultSystemCodePage forced to UTF-8) and prints the string correctly
for me (under Mac OS X).

Please always provide a compilable program when reporting issues.


Jonas
<>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] String literals and code page of .pas source file

[LacaK via fpc-pascal]

Hi *,

I would like to have source file in Windows-1250 encoding, where are 
stored literal strings like 'áéíóčž' in Windows-1250 encoding (I 
share this one file between FPC/Lazarus and Delphi 7). Windows-1250 
is also ANSI code page of my Windows OS. In source file I have:


{$IFDEF FPC}
  {$CODEPAGE cp1250}
{$ENDIF}
A pure string constant will still have CP_ACP as code page (which in 
Lazarus will by default mean UTF-8) also when you declare it as a 
typed String constant. The $CodePage directive will only influence the 
binary encoding of the string. 


*and probably this is something non intuitive for me. Also after reading 
https://wiki.freepascal.org/FPC_Unicode_support#String_constants it is 
hard to understand for me. After reading "The compiler has to know the 
code page according to which it should interpret string constants, as it 
may have to convert them at compile time." my expectation is, that when 
I explicitly define encoding of source file by using **{$CODEPAGE 
cp1250} then compiler will be aware of string encoding in that file and 
will handle it appropriate. Now it works in another way which is not 
clear to me ... can it be better explained in wiki (any example)?*


*
*


What you need to do is the following:

type
  String1250 = type String(1250);

const
  MyString: String1250 = 'áéíóčž';

This way the string itself will have code page 1250 and if you assign 
to a normal String or a UnicodeString the compiler will insert the 
appropriate conversions.


*yes, this I can understand, but it will not work in Delphi 7 ...*

*TIA*

*L.*


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] String literals and code page of .pas source file

[LacaK via fpc-pascal]

Hi *,

I would like to have source file in Windows-1250 encoding, where are 
stored literal strings like 'áéíóčž' in Windows-1250 encoding (I share 
this one file between FPC/Lazarus and Delphi 7). Windows-1250 is also 
ANSI code page of my Windows OS. In source file I have:


{$IFDEF FPC}
  {$CODEPAGE cp1250}
{$ENDIF}

and in Lazarus I have set: File settings / Encoding / CP1250
(at this point in .pas file are all characters correctly encoded in 
Windows-1250 code page)


When I compile application and run it, string literals (characters with 
accents) are not preserved.

Is there way how to get it working?

Only work-around which worked for me (in both Delphi and Lazarus) was use:

const
  STRINGLITERAL1: WideString = 'áéíóčž';

Thanks

-Laco.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal