[fpc-devel] [PATCH] Low-level invoke implementation for Linux x86_64

[silvioprog]

Hi.

It was sent here: https://bugs.freepascal.org/view.php?id=34743

Could you check the possibility to apply (or refuse) it?

I'm totally open for questions/improvements to make it available in the
RTL. I opened a poll at Facebook and received a good amount of positive
votes to make RTTI.Invoke() available for many platforms as possible (I
have plans to implement it for ARM and Win32, but will wait some feedback
regarding this first patch).

Best,

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Let's Encrypt cert and mantis.freepascal.org

[silvioprog]

On Tue, May 2, 2017 at 6:59 PM, Michael Van Canneyt 
wrote:

> On Tue, 2 May 2017, Tomas Hajny wrote:
>
>> On Tue, May 2, 2017 19:20, Michael Van Canneyt wrote:
>>
>>> On Tue, 2 May 2017, Dimitrios Chr. Ioannidis via fpc-devel wrote:
>>>
>>
>> Hi Michael,
>>
>
Hello dudes,


>   is it possible to add the domain mantis.freepascal.org in the let's
 encrypt cert or change the subversion bugtrack:url property from
 mantis.freepascal.org to bugs.freepascal.org ?

>>>
>>> Changed the bugtraq:url. Revision 36062.
>>>
>>
>> That's probably good as the fastest / short-term solution, but as long as
>> both DNS records are valid and point to the same IP address (and http
>> access to both is redirected to the https version), the certificate should
>> cover both domain names as well.
>>
>
> That mayb be so, but I have no idea how to do this.
>

Which client was used in the challenge, certbot? It allows to specify many
domains (however, I'm using acme-client today, but some time ago I used
certbot and got success with sub-domains too, eg: www.mydomain.com,
smtp.mydomain.com, docs.mydomain.com etc.).

As far as I know, lets encrypt does not support wildcard certificates.
>
> Michael.


I have some knowledge about this issue and I would be glad to help on that.

I've replaced certbot with acme-client because it have just some KBs
against many MB of certbot and its dependencies. Acme-client was written in
C, and its dependencies are just libbsd and libressl.

I did some changes in my copy to make it working in my Ubuntu Server
16.04, and I created a cron job that checks twice a day (time recommended
by certbot/acme-client team) if the certificate is still valid.

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows

[silvioprog]

On Sun, Mar 19, 2017 at 5:43 AM, Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org> wrote:

> Am 19.03.2017 04:53 schrieb "silvioprog" <silviop...@gmail.com>:
>
> Unfortunately you can't use the static libraries (.a) of Intel because
> they are generated for Linux, in spite of static libraries be
> cross-platform.
>
> Non-sense. Static libraries are as platform specific as any other binary
> code, after all it needs to call OS functions.
>

Well, I understand by cross-platform anything that is implemented on
multiple platforms, so once ar archives can be generated for multiple ones,
it makes sense for me. :-)

> I'm not sure about the .lib files. MS's COFF files adopt the .lib
> extension, but it is a little bit strange these sizes below:
> >
> > `libippi.a`:
> > . original - 251 MB;
> > . striped - 192 MB.
> >
> > `libippi.lib`:
> > . original - 853 KB;
> > . striped - no strip needed, it is already small.
>
> Seems like the second one is merely an import library for the DLL instead
> of a real static library.
>

Indeed.

And of course that is COFF as well. MSVC only supports COFF.
>

There isn't only one kind of COFF, AFAIK MS has an own COFF style and MSVC
supports only that. Sure, Intel must have used MSVC ones. However, my
*suggestion* about LacaK confirming that was just because he can generate
an object or a shared library from a MS COFF file, solving his problem!

--
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows

[silvioprog]

On Wed, Mar 15, 2017 at 4:38 AM, LacaK  wrote:
>
> I forgot a question, could you send your ippi .a files for us? If so, I
>> can try a test here. :-)
>>
>
> Yes of course: I have uploaded them here http://uschovna.zoznam.sk/down
> load?code=1342688547227-EZyyeVzToDVVkkbJNCbN
> But be aware of that I am on Windows, not Linux (Despite this I have added
> to ZIP also .a files as they are installed by Intel into direcotry "Linux".
> In direcory "Windows" are installed only .lib files).
> If I can repeat my question: Can I use ".a" libraries also on Windows ? If
> not can I use ".lib" created by C/C++ (I do not know how they are build)
> Thank you
>
> -Laco.
>

Unfortunately you can't use the static libraries (.a) of Intel because they
are generated for Linux, in spite of static libraries be cross-platform.

I'm not sure about the .lib files. MS's COFF files adopt the .lib
extension, but it is a little bit strange these sizes below:

`libippi.a`:
. original - 251 MB;
. striped - 192 MB.

`libippi.lib`:
. original - 853 KB;
. striped - no strip needed, it is already small.

Huge difference, so I'm not sure if the .lib are really COFF files (even
the owns MS COFF style). I tried to convert it to OMF (the .obj for testing
on Delphi, because I don't know if FPC supports OMF) via the VS LIB.EXE
tool and I didn't have success. The .obj was generated, but it doesn't work
because it was generated with only the library "interface", so I'm
suspecting the `libippi.lib` requires external libraries, something like
other .libs or .dlls, because 853 KB is a very small size for the same
library that requires 250 MB on Linux... you need to check about it at
Intel support (or trying it in C or C++ just to check if these .lib files
are really OK).

Anyway, I'm on Linux and I did this test below, it worked fine (just
sharing it, but I know you need it on Windows :-) ):

type
  cchar = AnsiChar;
  Pcchar = PAnsiChar;
  cint = Int32;

  IppLibraryVersionPtr = ^IppLibraryVersion;
  IppLibraryVersion = record
major: cint;
minor: cint;
majorBuild: cint;
build: cint;
targetCpu: packed array [0 .. 3] of cchar;
Name: Pcchar;
Version: Pcchar;
BuildDate: Pcchar;
  end;

function ippGetLibVersion: IppLibraryVersionPtr; cdecl; external;
{$LINKLIB  ippcore.a}
{$LINKLIB ippi.a}

var
  ver: IppLibraryVersionPtr;
begin
  ver := ippGetLibVersion;
  writeln(ver^.Version);
end.

// result: 2017.0.2 (r54644)

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows

[silvioprog]

On Tue, Mar 14, 2017 at 12:39 PM, silvioprog <silviop...@gmail.com> wrote:

> On Tue, Mar 14, 2017 at 12:26 PM, LacaK <la...@zoznam.sk> wrote:
>
>> Dňa 14.3.2017 o 15:57 silvioprog napísal(a):
>
> [...]
>
>> here I get (without {$linklib}):
>>   Error: Undefined symbol: IPP__IPPITHRESHOLD_LTVAL_8U_C1
>> IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$$IPPSTATUS
>>
>> test 2: put the library implementation below function declaration, eg:
>>>
>>> function _ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u; srcDstStep:
>>> int;
>>>roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u;
>>> thresholdGT: Ipp8u;
>>>valueGT: Ipp8u): IppStatus; external;
>>> {$linklib libippi}
>>>
>> here I get:
>>   Error: Undefined symbol: IPP__IPPITHRESHOLD_LTVAL_8U_C1
>> IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$$IPPSTATUS
>> (same error if I add: {$linklib ippi} or {$linklib libippi} ... ippi.lib
>> and libippi.a are in directory where -Fl points)
>
>
>>> fix 1: check which convention your library was compiled,
>>>
>> I think it is stdcall and I have this calling convention there (extdecl
>> is macro: {$DEFINE extdecl:=stdcall}  ):
>>   function _ippiThreshold_LTVal_8u_C1IR(pSrcDst: PIpp8u;srcDstStep:
>> int;  roiSize: IppiSize; threshold: Ipp8u; value: Ipp8u): IppStatus;
>>extdecl; external;
>
>
> Awesome. Now we need to check how libippi had exported its symbols. :-)
> For example, to check the symbols from the libfoo.a sent in my previous
> message:
>
> $ objdump -t libfoo.a
> In archive libfoo.a:
>
> libfoo.o: file format pe-i386
>
> SYMBOL TABLE:
> [  0](sec -2)(fl 0x00)(ty   0)(scl 103) (nx 1) 0x foo.c
> File
> *[  2](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 1) 0x _bar*
> AUX tagndx 0 ttlsiz 0x0 lnnos 0 next 0
> [  4](sec  1)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x .text
> AUX scnlen 0xa nreloc 1 nlnno 0
> [  6](sec  2)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x .data
> AUX scnlen 0x0 nreloc 0 nlnno 0
> [  8](sec  3)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x .bss
> AUX scnlen 0x0 nreloc 0 nlnno 0
> [ 10](sec  4)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x .rdata
> AUX scnlen 0x4 nreloc 0 nlnno 0
> [ 12](sec  5)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x .rdata$zzz
> AUX scnlen 0x2a nreloc 0 nlnno 0
> [ 14](sec  6)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x .eh_frame
> AUX scnlen 0x38 nreloc 1 nlnno 0
>
> Notice the _bar, now you need to check if libippi exported it as
> ippithreshold_ltvalgtval_8u_c1ir, _ippithreshold_ltvalgtval_8u_c1ir or
> ipp__ippithreshold_ltval_8u_c1ir. :-)
>

I forgot a question, could you send your ippi .a files for us? If so, I can
try a test here. :-)

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows

[silvioprog]

On Tue, Mar 14, 2017 at 12:26 PM, LacaK <la...@zoznam.sk> wrote:

> Dňa 14.3.2017 o 15:57 silvioprog napísal(a):

[...]

> here I get (without {$linklib}):
>   Error: Undefined symbol: IPP__IPPITHRESHOLD_LTVAL_8U_C1
> IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$$IPPSTATUS
>
> test 2: put the library implementation below function declaration, eg:
>>
>> function _ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u; srcDstStep:
>> int;
>>roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u;
>> thresholdGT: Ipp8u;
>>valueGT: Ipp8u): IppStatus; external;
>> {$linklib libippi}
>>
> here I get:
>   Error: Undefined symbol: IPP__IPPITHRESHOLD_LTVAL_8U_C1
> IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$$IPPSTATUS
> (same error if I add: {$linklib ippi} or {$linklib libippi} ... ippi.lib
> and libippi.a are in directory where -Fl points)


>> fix 1: check which convention your library was compiled,
>>
> I think it is stdcall and I have this calling convention there (extdecl is
> macro: {$DEFINE extdecl:=stdcall}  ):
>   function _ippiThreshold_LTVal_8u_C1IR(pSrcDst: PIpp8u;srcDstStep: int;
> roiSize: IppiSize; threshold: Ipp8u; value: Ipp8u): IppStatus;
>extdecl; external;


Awesome. Now we need to check how libippi had exported its symbols. :-) For
example, to check the symbols from the libfoo.a sent in my previous message:

$ objdump -t libfoo.a
In archive libfoo.a:

libfoo.o: file format pe-i386

SYMBOL TABLE:
[  0](sec -2)(fl 0x00)(ty   0)(scl 103) (nx 1) 0x foo.c
File
*[  2](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 1) 0x _bar*
AUX tagndx 0 ttlsiz 0x0 lnnos 0 next 0
[  4](sec  1)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x .text
AUX scnlen 0xa nreloc 1 nlnno 0
[  6](sec  2)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x .data
AUX scnlen 0x0 nreloc 0 nlnno 0
[  8](sec  3)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x .bss
AUX scnlen 0x0 nreloc 0 nlnno 0
[ 10](sec  4)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x .rdata
AUX scnlen 0x4 nreloc 0 nlnno 0
[ 12](sec  5)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x .rdata$zzz
AUX scnlen 0x2a nreloc 0 nlnno 0
[ 14](sec  6)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x .eh_frame
AUX scnlen 0x38 nreloc 1 nlnno 0

Notice the _bar, now you need to check if libippi exported it as
ippithreshold_ltvalgtval_8u_c1ir, _ippithreshold_ltvalgtval_8u_c1ir or
ipp__ippithreshold_ltval_8u_c1ir. :-)

--
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows

[silvioprog]

On Tue, Mar 14, 2017 at 11:29 AM, silvioprog <silviop...@gmail.com> wrote:

> On Tue, Mar 14, 2017 at 10:36 AM, Sven Barth via fpc-devel <
> fpc-devel@lists.freepascal.org> wrote:
> [...]
>
>> Small correction: I meant "static COFF libraries", not "COFF import
>> libraries" (the later can be considered a special case of the former
>> though).
>>
> Is there any plan to support COFF object on Windows? I've used it fine on
> Linux ({$l blah.a}), but on Windows it breaks the compilation with "illegal
> coff magic while reading blah".
>

Please ignore my question. :-D

I have fpc 3 and trunk in same machine, now after testing in trunk version
it work like a charm. ^^'

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows

[silvioprog]

On Tue, Mar 14, 2017 at 11:57 AM, silvioprog <silviop...@gmail.com> wrote:
[...]

> Anyway I've tried to use COFF objects on Windows, but I'm not sure if FPC
> supports that because it returns a "illegal COFF magic while reading some
> lib". :-/ (on Linux it works like a charm)
>

Oh, sorry. It works on Windows too. I've used the wrong compiler version,
because I have fpc 3 and trunk in same machine. ^^' I'm going to share the
steps I've done ...

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows

[silvioprog]

On Tue, Mar 14, 2017 at 9:30 AM, LacaK  wrote:

> Hi,
>
> I have C/C++ librarby (".lib" for Windows and ".a" for Linux) from Intel
> IPP package (they distribute ".lib" and also ".dll" for Windows and ".a"
> for Linux)
>
> Can I link in FPC (on Windows) at compile time to this ".lib" versions ?
> Or only possible way is link at runtime using ".dll" (and distribute DLLs
> with my EXE)?
> (I guess, that FPC can not link to libraries not created in FPC itself. So
> format of supplied ".lib" is not compatible with what FPC expects)
>
> I am trying do something like:
> {$linklib libippi}
> function ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u; srcDstStep:
> int;
>roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u; thresholdGT:
> Ipp8u;
>valueGT: Ipp8u): IppStatus; external; // 'ippi.dll';
>
> (In Project Options I have path to libippi.a in -Fl)
>
> But I get error: test_IPP.lpr(24,1) Error: Undefined symbol:
> IPP_IPPITHRESHOLD_LTVALGTVAL_8U_C1IR$PIPP8U$LONGINT$IPPISIZE
> $BYTE$BYTE$BYTE$BYTE$$IPPSTATUS
>

test 1: are you on win32? If so, did you try using prefix "_"? eg:

function _ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u; srcDstStep: int;
   roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u; thresholdGT:
Ipp8u;
   valueGT: Ipp8u): IppStatus; external;

test 2: put the library implementation below function declaration, eg:

function _ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u; srcDstStep: int;
   roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u; thresholdGT:
Ipp8u;
   valueGT: Ipp8u): IppStatus; external;
{$linklib libippi}

fix 1: check which convention your library was compiled, supposing it was
compiled supporting CDECL, you need to specify it on your Pascal binding,
avoiding low-level errors at runtime:

function _ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u; srcDstStep: int;
   roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u; thresholdGT:
Ipp8u;
   valueGT: Ipp8u): IppStatus; cdecl; external;

Anyway I've tried to use COFF objects on Windows, but I'm not sure if FPC
supports that because it returns a "illegal COFF magic while reading some
lib". :-/ (on Linux it works like a charm)


> I am doing something wrong or just this is not possible ?
>
> Thank you
> -Laco.


-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows

[silvioprog]

On Tue, Mar 14, 2017 at 10:36 AM, Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org> wrote:
[...]

> Small correction: I meant "static COFF libraries", not "COFF import
> libraries" (the later can be considered a special case of the former
> though).
>
Is there any plan to support COFF object on Windows? I've used it fine on
Linux ({$l blah.a}), but on Windows it breaks the compilation with "illegal
coff magic while reading blah".

--
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] How to get pointer to class VMT in assembler block

[silvioprog]

On Sun, Feb 19, 2017 at 6:42 PM, Bishop  wrote:

> I need to get pointer to class VMT in assembler block. In pascal code this
> can be done very simple, like Ptr := Pointer(SomeClass). But when i try in
> assembler do like "MOV RAX, SomeClass" this make assembler syntax error. If
> i try "LEA RAX, [SomeClass]" this compiled like "LEA RAX, [0]".
>
> So, how get pointer to specefic class VMT in assembler block?
>

The assembler window (ctrl+alt+d) may help you to check what asm block fpc
generated for its pascal code, for example, in my target (64 bits) the
following asm block code was generated for a `ptr := pvmt(classtype)`:

...
unit1.pas:36  ptr := pvmt(classtype);
0045E7A1 488b45f0 mov-0x10(%rbp),%rax
0045E7A5 488b00   mov(%rax),%rax
0045E7A8 488945e0 mov%rax,-0x20(%rbp)
0045E7AC 488945e8 mov%rax,-0x18(%rbp)

and iirc the default asm syntax for my system (linux) is at

hth

--
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] RTTI module and "IsManaged" critical problem

[silvioprog]

On Mon, Dec 12, 2016 at 4:52 AM, Maciej Izak  wrote:

>
> 2016-12-11 13:18 GMT+01:00 Maciej Izak :
>
>> http://bugs.freepascal.org/view.php?id=31102
>
>
> I can provide proper patch for #31102 and for #31108 (for fields part).
>

Could you do that please? :-)


> TotalFieldCount seems redundant (finally we have in conception RecFldCnt),
> we could point deprecated ManagedFldCount property to RecFldCnt. New
> ManagedFieldCount might be compromise solution. Anyway I have feeling that
> keeping both : ManagedFldCount and ManagedFieldCount is very bad idea
> (especially with new layout for ManagedFields which must contains managed
> fields only).
>
> --
> Best regards,
> Maciej Izak
>

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC SetDynArrayProp

[silvioprog]

On Mon, Nov 28, 2016 at 3:52 PM, silvioprog <silviop...@gmail.com> wrote:
[...]

> It can be a starting for implementing it at typinfo definitively.
>

Done: http://bugs.freepascal.org/view.php?id=31029 .

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC SetDynArrayProp

[silvioprog]

On Mon, Nov 28, 2016 at 3:25 PM, silvioprog <silviop...@gmail.com> wrote:
[...]

> Anyway including (Get)SetDynArrayProp() to typinfo solve the problem
> because it can check if property's set is a field or a method.
>

This version (inspired by FPC's SetRawInterfaceProp()) can handle property
(indexed or not) setting fields or methods:

procedure SetDynArrayProp(AInstance: TObject; APropInfo: PPropInfo; const
AValue: Pointer);
type
  TSetPointerProcIndex=procedure(index:longint;const i:Pointer) of object;
  TSetPointerProc=procedure(i:Pointer) of object;
var
  AMethod: TMethod;
begin
  case (APropInfo^.PropProcs shr 2) and 3 of
ptField:
  CopyArray(PPointer(Pointer(AInstance)+PtrUInt(APropInfo^.SetProc)),
@AValue, APropInfo^.PropType, 1);
ptStatic,
ptVirtual:
  begin
if ((APropInfo^.PropProcs shr 2) and 3)=ptStatic then
  AMethod.Code:=APropInfo^.SetProc
else

AMethod.Code:=PCodePointer(Pointer(AInstance.ClassType)+PtrUInt(APropInfo^.SetProc))^;
AMethod.Data:=AInstance;
if ((APropInfo^.PropProcs shr 6) and 1)<>0 then
  TSetPointerProcIndex(AMethod)(APropInfo^.Index,AValue)
else
  TSetPointerProc(AMethod)(AValue);
  end;
  end;
end;

It can be a starting for implementing it at typinfo definitively.

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC SetDynArrayProp

[silvioprog]

On Mon, Nov 28, 2016 at 3:25 PM, silvioprog <silviop...@gmail.com> wrote:
[...]

> Yes, and it seems you can't handle properties setting field, eg: "property
> Data: TBytes read FData write FData".
>
> An workaround just for testing:
>

*A workaround just for testing

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC SetDynArrayProp

[silvioprog]

On Mon, Nov 28, 2016 at 2:31 PM, Ondrej Pokorny  wrote:

> On 28.11.2016 17:37, Ondrej Pokorny wrote:
>
>> Is SetObjectProp safe?
>>
>
> OK, no it is not - it doesn't increment the reference count for properties
> without a setter:
> property Data: TBytes write FBytes;
>
> Ondrej


Yes, and it seems you can't handle properties setting field, eg: "property
Data: TBytes read FData write FData".

An workaround just for testing:

procedure SetDynArrayProp(AInstance: TObject; APropInfo: PPropInfo; const
AValue);
begin
  // Caution: it works only with fields! But we can implement the full
version checking methods too, getting some ideas from SetRawInterfaceProp
  CopyArray(PPointer(Pointer(AInstance)+PtrUInt(APropInfo^.SetProc)),
@AValue, APropInfo^.PropType, 1);
end;

...
//{$IFDEF FPC}
SetDynArrayProp(O, PropInfo, A);
//{$ELSE}
//SetDynArrayProp(O, PropInfo, A);
//{$ENDIF}
...

Anyway including (Get)SetDynArrayProp() to typinfo solve the problem
because it can check if property's set is a field or a method.

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC SetDynArrayProp

[silvioprog]

On Mon, Nov 28, 2016 at 1:37 PM, Ondrej Pokorny  wrote:

> Hello!
>
> What is the correct way to set a published dynamic array property in FPC?
> In Delphi, you use SetDynArrayProp.
>
> Is SetObjectProp safe (packages\fcl-web\src\base\restbase.pp uses this
> approach)? See the attached project.
>
> Ondrej



It seems a great time to including the
tkDynArray/GetDynArrayProp()/SetDynArrayProp()
to RTL.

Could you open an issue?

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Raw ARC objects preview

[silvioprog]

On Tue, Nov 8, 2016 at 5:44 PM, Maciej Izak <hnb.c...@gmail.com> wrote:

>
> 2016-11-08 17:56 GMT+01:00 silvioprog <silviop...@gmail.com>:
>
>> NewPascal is now on my wishlist. :-)
>>
>
> Thanks. But sadly that was my last job for Pascal community.
>

I think you should stay with us, you are an important contributor for the
Pascal (FPC/Delphi) community!

I'm using one of your works: Generics.Collections classes. It is helping me
a lot (despite some bugs, but it isn't a problem). I remember you talked
about planning to implement the extended RTTI and custom attributes on FPC,
I hope you keep that in mind.

Unfortunately, I'm in a temporary problem that interrupts me to stay
working in my free time, but I'm following all changes in FPC/Lazarus,
contributing when I can do that, and I don't have plan to leave Pascal,
even working with C/Java/JavaScript/Python nowadays.

Dude, all your effort is enjoyed here, the C++/C# community is already
crowded, so you'd be just another one there hehe :-D
-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Raw ARC objects preview

[silvioprog]

On Tue, Nov 8, 2016 at 1:24 PM, Maciej Izak <hnb.c...@gmail.com> wrote:

>
> 2016-11-08 17:02 GMT+01:00 silvioprog <silviop...@gmail.com>:
>
>> I need to test this new features soon... Can I use nextPascal on Linux?
>> (I'm using latest Xubuntu version)
>
>
> sure! try this: https://github.com/LongDirtyAnimAlf/Reiniero-fpcup/
> releases/tag/0.99
>
> Great tool made by Alf :)
>
> --
> Best regards,
> Maciej Izak
>

Awesome!

NewPascal is now on my wishlist. :-)

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Raw ARC objects preview

[silvioprog]

On Tue, Nov 8, 2016 at 6:10 AM, Maciej Izak  wrote:

> I became outlaw (permanent ban) on Delphi G+ for this :D . Seems my work
> is serious danger for Delphi (single programmer can kill their business? I
> have no idea).
>
> ARC objects preview for newpascal.org (will be probably used for Delphi
> NEXTGEN mode in NewPascal). Fully compilable and backward compatible. Some
> work is still required (additional Delphi compatible interface, compiler
> magic and and few changes in RTL):
>
> https://github.com/maciej-izak/PascalSmartPointers/blob/
> master/examples/SmartObj01.pas
> https://github.com/maciej-izak/PascalSmartPointers/blob/
> master/sources/SmartObj.pas
>
> --
> Best regards,
> Maciej Izak
>

Great job!

I need to test this new features soon... Can I use nextPascal on Linux?
(I'm using latest Xubuntu version)

Thank you for sharing that with us! (y)

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] TBufferedFileStream

[silvioprog]

On Sat, Sep 3, 2016 at 10:58 PM, silvioprog <silviop...@gmail.com> wrote:
[...]

> ... under compressed files ...
>

Sorry, I meant "within compressed files".

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] TBufferedFileStream

[silvioprog]

On Sat, Sep 3, 2016 at 9:39 PM, José Mejuto <joshy...@gmail.com> wrote:

> El 04/09/2016 a las 2:04, silvioprog escribió:
>
> If I understood right, did you create something like GIO or GVFS? Or
>> neither of them hehe
>>
>
> Hello,
>
> Yes and no :) It's something like GVFS but at your program level only. I
> originally develop it to be used in a forensic tool (which was not finally
> developed) to allow the same data scan engine to work in compressed files
> as they were real files so the file access logic is completly isolated from
> the information gather engine as this one works over a TVirtualFileSystem,
> how you implement your TVirtualFileSystem is up to your decision.
>
> You basically need to implement this functions:
>
> function intfOpenFile(const AFileName: UTF8String; const AMode: cardinal):
> TvlHandle; virtual; abstract;
>
[...]

Nice API.

As far as you can implement those functions yes, in fact I started (almost
> nothing) to write an http access using a remote zip file for read only and
> using the http byte ranges to access it.
>

I spent a much time working in an efficient byte serving layer, because the
company needed to provide files allowing resume of up/download contents. I
did it with raw TFileStream, but I need to spend some time testing
TBufferedFileStream, I think this class can be very useful for creating
fast layer allowing download acceleration of big files (that has sequencial
small repetitive reads), and I've already implemented a structure allowing
the following simultaneous byte range groups:

 HTTP/1.1 206 Partial Content
 Date: Wed, 15 Nov 1995 06:25:24 GMT
 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
 Content-Length: 1741
 Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

 --THIS_STRING_SEPARATES
 Content-Type: application/pdf
 Content-Range: bytes 500-999/8000

 ...the first byes range...
 --THIS_STRING_SEPARATES
 Content-Type: application/pdf
 Content-Range: bytes 7000-7999/8000

 ...the second bytes range
 --THIS_STRING_SEPARATES--

ASAP I'm going to redo my benchmarking tests replacing the TFileStream to
TBufferedFileStream and checking if I really can get any performance gain.

Maybe I should retake this work :) if there are some interest in the
> community.
>

Searching files under compressed files seems really seems a very useful
feature.


> Attached is a sample (some folder names erased) of the explorer I use to
> test the different file systems in "real" situations.


I took a look at it, thanks! :-)

--
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] TBufferedFileStream

[silvioprog]

On Sat, Sep 3, 2016 at 8:20 PM, José Mejuto <joshy...@gmail.com> wrote:

> El 04/09/2016 a las 0:23, silvioprog escribió:
>
> --
>> CACHE 100 byte sequential reads in 46 ms.
>> FILE 100 byte sequential reads in 2200 ms.
>> --
>>
>> [...]
>>
>> Did you get this result from some sample? If so, could you share it?! I
>> would be glad to test it checking the TBufferedFileStream performance. :-)
>>
>>
> Hello,
>
> Yes, the code is in the test for TBufferedFileStream in the bug ticket
>
> http://bugs.freepascal.org/view.php?id=30549


Great. I'm going to download it.

Delphi TBufferedFileStream should be faster as I think it implementes a
> dumb buffer, or just better a read ahead buffer, so it works better for
> sequential read and worst for butterfly reads on same zones.
>
> For my works I just use my class TCacheStream which applies the same cache
> code but over any stream already created. I need this as a stream filter
> because I'm working on virtual file systems which access a stream
> (whichever class) as a blocks device stream, so I can in example work with
> ZIP files as they was a disk with functions to browse the ZIP entries,
> create files, delete, read and write, once each "file" is closed and the
> stream that holds the whole file is freed in destroy it updates the zip
> according, compressing new and modified streams and copying/moving the
> blocks not touched.
>
> Part of this code is in the Excel reader/writer in fpspreadsheet package.
>
> Most of this classes are mostly beta versions, operative in my environment
> but not valid for wide use, that's the reason I had not published them (and
> the lack of comments, and code convolution).
>
> Currently I have, more or less:
>
> Native filesystem: Read/Write. Maps the native filesystem to my virtual
> filesystem.
>
> ZIP filesystem: Read/Write. Up to 2GB zip files.
>
> FAT16: Read. Typical dd images.
>
> FAT32: Read. Typical dd images.
>
> Microsoft Binary Compound: Read/Write with limitations. Used in XLS,
> DOC,...
>
> Sample filesystem: Read/Write. Very limited sample filesystem.
>
> MBR Partition: Read. Used to access dd images when partition information
> is available.
>
> RAR: Browse only. With special crafted dll for windows also decompress,
> but it is a dirty hack.
>
> ISO: Read only. Limited and based in GPL code.
>
> The virtual file system allows to mount an filesystem (above) in a folder
> for browsing, open, and so on, so in example you open a ZIP and inside you
> find another zip, you can mount the inner stream in a folder and access to
> inner files transparently to your code, with a path like

F:=VirtualLayerRoot.CreateStream("/zip1/zip2/myfile.txt",fmOpenRead);


If I understood right, did you create something like GIO or GVFS? Or
neither of them hehe

Another question, does it work remotely too?

I can publish the code but I can not provide any guarantee of correct work
> and that it will not delete all your hard disk :)


Lol! :-D

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] TBufferedFileStream

[silvioprog]

On Sat, Sep 3, 2016 at 5:28 PM, José Mejuto  wrote:
[...]

> ... Typical example is TFileStream.GetByte which I'm using in a parser,
> because the file could be very big, and I don't want to read everything in
> a TMemoryStream, performance of cache/buffered and regular is dramatically
> different:
>
> --
> CACHE 100 byte sequential reads in 46 ms.
> FILE 100 byte sequential reads in 2200 ms.
> --
>
[...]

Did you get this result from some sample? If so, could you share it?! I
would be glad to test it checking the TBufferedFileStream performance. :-)

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Variant Records and Duplicate Identifiers

[silvioprog]

On Thu, Apr 21, 2016 at 3:00 AM,  wrote:
[...]

> ex.pas(19,18) Error: Duplicate identifier "marriageDate"
> ex.pas(21,3) Error: Duplicate identifier "marriageDate"

[...]

Same problem on Delphi (Seattle):

"[dcc32 Error]: E2004 Identifier redeclared: 'marriageDate'".

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC implementation of attributes for language parts.

[silvioprog]

On Wed, Apr 13, 2016 at 10:06 AM, Maciej Izak  wrote:
[...]

>  No one really won't this but it is the must. IFDEF hell is much more
> visible for "constref/[ref] const" than in any other place... :(
>

I need this feature too, but for Delphi compatibility. It could avoid a lot
of IFDEFs in Delphi mode.

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics.Collections as package for Lazarus or package for FPC RTL

[silvioprog]

On Sat, Jan 30, 2016 at 2:19 PM, silvioprog <silviop...@gmail.com> wrote:

> On Fri, Jan 29, 2016 at 8:28 AM, Marco van de Voort <mar...@stack.nl>
> wrote:
>
>> In our previous episode, silvioprog said:
>> > > The format of interface VMTs could also differ per platform so
>> considering
>> > > that as more stable only holds true because of what we currently
>> support.
>> > >
>> >  Sorry for ask here, but, don't you recomment to use interfaces? I'm
>> making
>> > a project and I'm planning to use some COM interfaces to make something
>> a list
>> > adapter
>> > <http://developer.android.com/reference/android/widget/ListAdapter.html
>> >.
>>
>> Interfaces are relatively slow. Not only because of the refcounting, but
>> returning interfaces in a tight loop (e.g. to get the elements of an
>> enumeration) would be a new allocation each time.
>
>
> Hm... I didn't know that.
>
> I need to take a test using some profiling tool to check the real cost
> using interfaces, because in my case I'm using lists. However, I still
> can't understand why some programmers avoid to use interfaces in Pascal.
> :-/
>

Well, I did a simple test. Result:

C: 00:00:11.008
I: 00:00:14.555
I: 00:00:14.511
C: 00:00:10.880
Press [ENTER] to exit ...

Source: http://pastebin.com/x74V4gEx .

It seems that the COM interfaces is a little bit slower than classes.
Anyway, I don't have problem to use interfaces, however I'll use it only
when it is really necessary.

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics.Collections as package for Lazarus or package for FPC RTL

[silvioprog]

On Fri, Jan 29, 2016 at 8:28 AM, Marco van de Voort <mar...@stack.nl> wrote:

> In our previous episode, silvioprog said:
> > > The format of interface VMTs could also differ per platform so
> considering
> > > that as more stable only holds true because of what we currently
> support.
> > >
> >  Sorry for ask here, but, don't you recomment to use interfaces? I'm
> making
> > a project and I'm planning to use some COM interfaces to make something
> a list
> > adapter
> > <http://developer.android.com/reference/android/widget/ListAdapter.html
> >.
>
> Interfaces are relatively slow. Not only because of the refcounting, but
> returning interfaces in a tight loop (e.g. to get the elements of an
> enumeration) would be a new allocation each time.


Hm... I didn't know that.

I need to take a test using some profiling tool to check the real cost
using interfaces, because in my case I'm using lists. However, I still
can't understand why some programmers avoid to use interfaces in Pascal.
:-/

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics.Collections as package for Lazarus or package for FPC RTL

[silvioprog]

On Fri, Jan 29, 2016 at 1:24 PM, Marco van de Voort  wrote:

> In our previous episode, Sven Barth said:
> > > Interfaces are relatively slow. Not only because of the refcounting,
> but
> > > returning interfaces in a tight loop (e.g. to get the elements of an
> > > enumeration) would be a new allocation each time.
> >
> > Note: the enumerator of a for-in is only fetched once before the loop, so
> > it does not really matter whether it's an interface or record as long as
> > the elements themselves aren't on demand allocated interfaces.
>
> The trouble is that you then have to avoid for-in for many potentially
> small
> iterations as in the hash case.


Hm... that's my case. I have an object list that the key is an integer and
the value is an object, ie a hash map.

However, some years ago I got a problem using interfaces in an old draft
that I made, so to fix the problem I chose abstract class instead of
interface. I don't know if it is a compiler behaviour or something that I
forgot, the test is:

=== begin code ===

  ITest = interface
['{1DB8BD50-FCA2-40B3-B25B-A858DD206D26}']
procedure SetTest(ATest: ITest);
  end;

  TTest1 = class(TInterfacedObject, ITest)
  private
FTest: ITest;
  public
procedure SetTest(ATest: ITest);
property Test: ITest read FTest write FTest;
  end;

  TTest2 = class(TInterfacedObject, ITest)
  private
FTest: ITest;
  public
procedure SetTest(ATest: ITest);
property Test: ITest read FTest write FTest;
  end;

...

procedure TTest1.SetTest(ATest: ITest);
begin
  FTest := ATest;
end;

procedure TTest2.SetTest(ATest: ITest);
begin
  FTest := ATest;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  VTest1, VTest2: ITest;
begin
  VTest1 := TTest1.Create;
  VTest2 := TTest1.Create;
  VTest1.SetTest(VTest2);
  VTest2.SetTest(VTest1);
end;

=== end code ===

It throws some memory leaks, so to fix the problem I used abstract class:

=== begin code ===

  TTest = class abstract
  public
procedure SetTest(ATest: TTest); virtual; abstract;
  end;

  TTest1 = class(TTest)
  private
FTest: TTest;
  public
procedure SetTest(ATest: TTest); override;
property Test: TTest read FTest write FTest;
  end;

  TTest2 = class(TTest)
  private
FTest: TTest;
  public
procedure SetTest(ATest: TTest); override;
property Test: TTest read FTest write FTest;
  end;

...

procedure TTest1.SetTest(ATest: TTest);
begin
  FTest := ATest;
end;

procedure TTest2.SetTest(ATest: TTest);
begin
  FTest := ATest;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  VTest1, VTest2: TTest;
begin
  VTest1 := TTest1.Create;
  VTest2 := TTest1.Create;
  VTest1.SetTest(VTest2);
  VTest2.SetTest(VTest1);
  VTest1.Free;
  VTest2.Free;
end;

=== end code ===

However, I need to use the ARC feature in some occasions, and it seems that
the better FPC entity that already implements that is the
TInterfacedObject. :-/

--
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics.Collections as package for Lazarus or package for FPC RTL

[silvioprog]

On Thu, Jan 28, 2016 at 7:34 AM, Sven Barth 
wrote:
[...]

> The format of interface VMTs could also differ per platform so considering
> that as more stable only holds true because of what we currently support.
>
 Sorry for ask here, but, don't you recomment to use interfaces? I'm making
a project and I'm planning to use some COM interfaces to make something a list
adapter
.

> The more stable approach would definitely be the one that does not rely on
> implementation details, but only on the specified, documented language
> behavior (bugs not withstanding of course), thus the approach I've
> mentioned above.
>
> I consider the approach with manual interfaces as hackish. Period.
>
[...]

What is manual interfaces, does it mean CORBA interfaces?

I'm asking about using interfaces because I could easily change my project
to use abstract classes, however I don't know if the interfaces choice can
be a good choice.

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics.Collections as package for Lazarus or package for FPC RTL

[silvioprog]

On Wed, Jan 27, 2016 at 6:22 AM, Michael Van Canneyt  wrote:
[...]

> Assume we introduce namespaces, do things 'Properly' and introduce
> Core.FileUtils
> Core.StringUtils
> (the names are just examples, to make a point)
>
> Now let's take example existing routines such as
> ExtractFilePath
> ExtractFileName
> Where do we put them ?
>
> Both units are a candidate. The former because it is about filenames.
> The latter because they are purely string operations.
> Your namespace doesn't solve this problem.
>

ExtractFilePath/ExtractFileName sounds more related to file operations, so:

Core.File:
...
  TFile = class sealed(TObject)
  public
class function ExtractPath ... ; static;
class function ExtractName ... ; static;
...

writeln(TFile.ExtractPath(...));
writeln(TFile.ExtractName(...));

or:

Core.File:
...
function ExtractPath ...;
function ExtractName ...;

writeln(File.ExtractPath(...));
writeln(File.ExtractName(...));

(btw the example above needs the -NS feature)

IMHO, if the  already is called "file", you don't need to add the
context name again in the function name, so instead of:

writeln(ExtractPath(...));
writeln(ExtractPath(...));

just use:

writeln(.ExtractPath(...));
writeln(.ExtractName(...));

So, you can do .code-completation to get all the features to this
context.

Once more, the above is purely theoretical discussion; I am not opposing
> anything, just pointing out that the use of namespaces is
> and remains a matter of preference (or even fashion/hype).


Both approaches compiles, but I agree the it is a preferencial thing.

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics.Collections as package for Lazarus or package for FPC RTL

[silvioprog]

On Wed, Jan 27, 2016 at 10:06 AM, Ondrej Pokorny  wrote:

> On 27.01.2016 14:05, Marco van de Voort wrote:
>
>> fpc.core.filesystem.file.utils is better I think.
>>
>
> +1 :D


Or:

System.File:
...
TUtils
  static methods for file utilities;

TFile
  static methods for file operations;

The fpc.core.filesystem.file.utils sounds just a dotted unit name, I can't
see how it could help in something like a code-completation. :-/

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics.Collections as package for Lazarus or package for FPC RTL

[silvioprog]

On Tue, Jan 26, 2016 at 6:29 PM, Maciej Izak  wrote:

> Hi!
>
> we need to decide what to do with Generics.Collections implementation.
>
> Lazarus team suggest to add this package as one of sparta packages (for
> example components/sparta/generics) but in some of my experimental branches
> it is used deeper than in sparta packages only (LCL, main IDE files or even
> in other basic libraries unrelated to Lazarus). I'd like to see it as part
> of RTL.
>
> Any feedback or suggestion?
>

The Generics.Collections should be added to RTL or as a FPC package.

Is there some problem in your implementation that Laz team decided to add
it as Lazarus package? If so, is it fixable? :-/


> current version: https://github.com/dathox/generics.collections
>

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics.Collections as package for Lazarus or package for FPC RTL

[silvioprog]

On Tue, Jan 26, 2016 at 7:27 PM, Anthony Walter  wrote:

> I guess this is good time to ask, how would the community feel about
> setting a new standard for Free Pascal units going forward? I am thinking
> that since FPC 3.0 is now official we don't really have a good excuse to
> start using many of the great new language features it brings, such as
> dotted name spaces, type helpers on intrinsic types, and of course the now
> good working generics.
>
> I would propose we start migrating new units to this type of standard:
>
> unit Core.Text;
>
[...]

I already use dotted namespaces for my units, and IMHO it is a nice
Delphi/FPC feature. :-)

I agree with all your ideas, but I don't know how FPC/Laz team would accept
and adopt this new standard.

Anyway, is there any place where I can find the code that you proposed? It
sounds a very nice feature.

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Generics.Collections as package for Lazarus or package for FPC RTL

[silvioprog]

On Tue, Jan 26, 2016 at 8:06 PM, Anthony Walter  wrote:

> I'd also like to add that there might be more names under a namespace than
> just two (e.g "Core.Text"). For example:
>
> unit Core.Collections;
> unit Core.Collections.Specialized;
> unit Core.Text;
> unit Core.Text.Xml;
> unit Core.Text.Regex;
> unit Core.Network;
> unit Core.Network.Http;
> unit Core.Network.Ftp;
> unit Core.Network.Storage;
> unit Core.Encryption;
>
> And so on.
>

Wow, it would be awesome. *-*

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 3.0.0-rc1 release

[silvioprog]

On Tue, Aug 25, 2015 at 12:50 PM, Joost van der Sluis jo...@cnoc.nl wrote:

 Hello

 We have placed the first release candidate of the Free Pascal Compiler
 version 3.0.0 on our ftp servers.

 You can help improve the upcoming 3.0.0 release by downloading and
 testing this release. If you want you can report what you have done here:
 http://wiki.freepascal.org/Testers_3.0.0

 New features are listed at
 http://wiki.freepascal.org/FPC_New_Features_3.0

 Changes that may break backwards compatibility are documented at
 http://wiki.freepascal.org/User_Changes_3.0.0

 Issues with this release candidate that we already know of are listed in
 the wiki: http://wiki.freepascal.org/Issues_3.0.0

 A preview of the 3.0.0 docs is available at
 http://www.freepascal.org/docs-html/3.0.0/

 Downloads are available at:
 * ftp://freepascal.stack.nl/pub/fpc/beta/3.0.0-rc1
 * ftp://gd.tuwien.ac.at/languages/pascal/fpc/beta/3.0.0-rc1
 * ftp://ftp.freepascal.org/pub/fpc/beta/3.0.0-rc1

 Enjoy!

 The Free Pascal Compiler Team


 Free Pascal Compiler

  Version 3.0.0-rc1


 
 * Introduction

 

 Please also read the platform specific README file, if it exists.

 This package contains an advanced freeware 32-bit/64-bit/16-bit pascal
 compiler for several platforms. The language and the runtime library are
 almost compatible with Turbo Pascal 7.0 and recent Delphi releases. There
 is also partial support for the Macintosh pascal dialect.

 News and changes related to this release are described in whatsnew.txt.

 Free Pascal 3.0.0 is currently available for the following platforms:
 - Linux-i386
 - Linux-x86_64 (amd64)
 - Linux-powerpc
 - Linux-sparc
 - Linux-ARM
 - Win32-i386 (Win95/98/Me/XP/2000/2003/Vista/7 and WinNT)
 - Win64-x86_64 (XP/Vista/2003)
 - Wince-ARM (cross compiled from win32-i386)
 - FreeBSD-i386
 - FreeBSD-x86_64
 - Mac OS X/Darwin for PowerPC (32 and 64 bit)
 - Mac OS X/Darwin for Intel (32 and 64 bit)
 - iOS, iPhoneSimulator
 - OS/2-i386 (OS/2 Warp v3.0, 4.0, WarpServer for e-Business and
 eComStation)
 - GO32v2-i386

 There are other platforms (like other BSD variants) which are more or less
 working, but there is currently no maintainer for them and thus we cannot
 provide adequate support. If you want to change this and create and
 maintain versions for other platforms and targets, feel free to contact us,
 e-mail addresses are listed below.



 
 * Features

 

 - high speed compiler
 - fully 16, 32 or 64-bit code
   - 32 bit compiler can be used on x86_64 Linux distributions to compile
 32 bit applications
 - language features:
   - almost fully compatible with Borland Pascal and Borland Delphi
   - ansi strings
   - wide strings
   - exception support
   - RTTI support
   - procedure overloading
   - generics (experimental)
   - operator overloading
   - COM, CORBA and raw interfaces support
   - dynamic array support
   - variant support
   - inlining
 - code optimizer:
   - peephole optimizer (80x86 only)
   - jump optimizer
   - loading of variables into registers
   - assembler level dataflow analyzer (80x86 only)
   - stack frame eliminations
   - sophisticated register allocator
 - integrated BASM (built-in assembler) parser
   - supports ATT syntax used by GNU C
   - supports Intel syntax used by Turbo Pascal (80x86-only)
 - can compile code into assembler source code for these assemblers:
   - GNU Assembler (GAS)
   - Netwide assembler (Nasm)
   - Microsoft Assembler/Turbo Assembler (Masm/Tasm)
   - Watcom assembler (wasm)
 - internal assembler for ultra fast object file generation
 - can call external C code
   - h2pas utility to convert .h files to Pascal units
 - smart linking (also known as dead code stripping)
 - support for the GNU debugger
 - integrated development environment (disabled by default on Mac OS X)
   - powerful user friendly Wordstar compatible multi file editor
   - context sensitive help supports help files in HTML, Windows HLP and
 Borland TPH format.
   - debugger on most platforms
 - can create binaries running natively under both DOS and OS/2 (EMX
 version)
 - no need for Linux distribution specific binaries, programs you write run
   on all distributions
 - high quality documentation



 
 * Minimum requirements

 

 i386, x86_64, PowerPC or Sparc processor
 Win32:
  - MS Windows NT/2000/2003/XP/Vista/7 (Win95, 98 and ME are not supported
in FPC officially any longer).
  - 16 MB RAM
 OS/2:
  - OS/2 Warp v3.0 with one of late fixpaks - FP 35 should be fine,
 

Re: [fpc-devel] New FPC language/dialect MODE, Generics.Collections and new branch

[silvioprog]

On Fri, Jul 17, 2015 at 4:00 AM, Maciej Izak hnb.c...@gmail.com wrote:

 New modern Pascal dialect is subject of this topic.

 Is any way to get branch for new pascal dialect and for
 generics.collections improvements? For me ObjFPC is too much conservative
 and Delphi after XE2 version, really sucks, so $MODE Delphi is not option.

 I think is good idea to discuss new dialect. I really like some elements
 from ObjFPC, also from Delphi and from Oxygene (we can't implement pure
 $MODE Oxygene but some ideas are good). To combine best of mentioned
 dialects elements we need to create new $MODE. I call my new dialect
 Sparta (yes it is related to freesparta.com) but I can change this
 name.

 I have some concerns, that all my effort for new dialect even if I done
 some work will be useless.

 If you wish, I can prepare some manifest document related to new
 language dialect details.

 Let me know if there is no option for that initiative.

 Best Regards,
 Maciej Izak


I don't know if a new dialect would be widely accepted by all developers
(specially veteran pascal programmers), but if it could become things more
practical and more productive, I would be in favor of just {$ mode
ObjPas}. =)

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] What do you think about TSQLScript using 'TextReader'?

[silvioprog]

On Mon, Jun 15, 2015 at 6:29 AM, Michael Van Canneyt mich...@freepascal.org
 wrote:

 On Sun, 14 Jun 2015, silvioprog wrote:

 Hello,

 A few weeks ago, I took a look at the TSQLScript (that IMHO is a very
 nice class!) source, and I noticed that it seems slow for processing big
 files.

 I did some tests with this class. My SQL file: 90 MB, with CREATE TABLE,
 CREATE PROCEDURE, CREATE TRIGGER, ALTER TABLE, several INSERT INTO and
 more. Using the current TSQLScript
 implementation, the execution of this file is very slow, and the
 CPU/memory usage is extremely large(*), but after make some changes in the
 original TSQLScript source code, adapting it to
 use this[1] new class (recently applied in FCL), I got a significant
 difference, ie, the CPU/memory usage now is amazing less, increasing the
 performance +-80%. =) The answer to the
 significant gain is simple: using a textreader, the TSQLScript class read
 the SQL (from string, stream or file) by demanding (line by line, and using
 a low level byte reading too), instead
 of loading an entire file to a buffer in a stringlist.


 I think you hit the stringlist performance limit with 90 mb =)


 So, after this explanation, what do you think about TSQLScript using
 textreader? I can send a patch showing this idea as a real implementation,
 of course, keeping the 'Script' as a
 stringlist, just adding a new property, called 'Source' and declared as
 'TTextReader'.


 I think this is a good idea.


 An observation: I suspect it has a small bug at this line[2]: the
 'Directive' variable could break the loop skipping for the next line after
 its assignment. OK, if it is a bug, it is very
 easy to fix.


 Please report it in the bugtracker.


 (*) In a specific case on a Linux server, the kernel killed my executable
 while importing my SQL file, see more details here[3].
 [1] http://bugs.freepascal.org/view.php?id=28075
 [2]
 https://github.com/graemeg/freepascal/blob/master/packages/fcl-db/src/base/sqlscript.pp#L387
 [3]
 http://unix.stackexchange.com/questions/136291/will-linux-start-killing-my-processes-without-asking-me-if-memory-gets-short


 If you want, you can create a patch and put it in the bugtracker. Anything
 to improve performance is welcome.

 Michael.



Very nice, I'll do that ASAP. =)

Thank you!

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] What do you think about TSQLScript using 'TextReader'?

[silvioprog]

Hello,

A few weeks ago, I took a look at the TSQLScript (that IMHO is a very nice
class!) source, and I noticed that it seems slow for processing big files.

I did some tests with this class. My SQL file: 90 MB, with CREATE TABLE,
CREATE PROCEDURE, CREATE TRIGGER, ALTER TABLE, several INSERT INTO and
more. Using the current TSQLScript implementation, the execution of this
file is very slow, and the CPU/memory usage is extremely large(*), but
after make some changes in the original TSQLScript source code, adapting it
to use this[1] new class (recently applied in FCL), I got a significant
difference, ie, the CPU/memory usage now is amazing less, increasing the
performance +-80%. =) The answer to the significant gain is simple: using a
textreader, the TSQLScript class read the SQL (from string, stream or file)
by demanding (line by line, and using a low level byte reading too),
instead of loading an entire file to a buffer in a stringlist.

So, after this explanation, what do you think about TSQLScript using
textreader? I can send a patch showing this idea as a real implementation,
of course, keeping the 'Script' as a stringlist, just adding a new
property, called 'Source' and declared as 'TTextReader'.

An observation: I suspect it has a small bug at this line[2]: the
'Directive' variable could break the loop skipping for the next line after
its assignment. OK, if it is a bug, it is very easy to fix.

(*) In a specific case on a Linux server, the kernel killed my executable
while importing my SQL file, see more details here[3].
[1] http://bugs.freepascal.org/view.php?id=28075
[2]
https://github.com/graemeg/freepascal/blob/master/packages/fcl-db/src/base/sqlscript.pp#L387
[3]
http://unix.stackexchange.com/questions/136291/will-linux-start-killing-my-processes-without-asking-me-if-memory-gets-short

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] RTTI interface variant late binding issue (mORMot)

[silvioprog]

On Sun, Mar 22, 2015 at 6:38 AM, Michael Van Canneyt mich...@freepascal.org
 wrote:

 On Sun, 22 Mar 2015, Alfred wrote:

 Hello again to all,

 I am enjoying variant late binding AND interface RTTI for a while now !
 Thanks again !

 As far as I know, the patch for RTTI has not yet been included in trunk.
 But correct me if I am wrong.

 I would like to ask to include the RTTI patch for i386 in trunk.
 With i386 interface RTTI, FPC is on level with Kylix for the RTTI part.

 To ease introduction, I would like to suggest to include a new
 HASINTERFACERTTI flag, which will let the FPC user know, the new RTTI is
 available for use.

 At this moment, it will only be i386.


 I can't remember when I last used i386 code. Must have been more than 10
 years ago.

  But I hope also ARM will be included in the trunk.
 On my Raspberry Pi2, the new RTTI works flawless.


 The core developers are divided on the approach to take. Hence it is not
 yet included.
 The code is highly non-portable, which means that each platform must be
 maintained separately.
 This means additional pressure on people who maintain these other
 platforms.

 The idea is to use a manager approach (as for instance for threads,
 locale, widestrings)
 using a libffi wrapper as fallback for platforms for which no native
 manager is available.
 (see https://sourceware.org/libffi/)


It seems that somebody implemented that in FPC:

https://code.google.com/p/la-pe/

Not tested yet.


 However this means the RTTI info must be written in a format that can be
 fed directly to libffi.
 (or using a conversion routine). In each case, additional work is needed.

 My - and Florian Klaempfl's, if I understood correctly - idea is to
 include what exists, and then modify the code as needed so it can work with
 libffi. Others fear that this will mean the ffi wrapper will not get
 written anytime soon.

 Michael.


-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proof of Concept ARC implementation

[silvioprog]

Very good initiative Sven!

Can you create a branch on Github (https://github.com/graemeg/freepascal)?

Thank you very much!

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Suggestion: reference counted objects

[silvioprog]

On Mon, Oct 13, 2014 at 2:23 PM, hinsta...@yandex.ru hinsta...@yandex.ru
wrote:

 Great!

 Sorry for misspelling your name btw

 13.10.2014, 20:44, Sven Barth pascaldra...@googlemail.com:

  Am 13.10.2014 16:17 schrieb hinsta...@yandex.ru:

  Maybe; however I am asking about reference counted objects feature. I
 thought Svan Barth said that he considered implementing it

  I have a working proof of concept implementation of my RFC and am
 currently' commiting it to branches/svenbarth/arc. I'll write a mail once
 I'm done with committing with details about the usage, etc..

  Regards,
  Sven

 Where I click in +1 or I like this? =)

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Suggestion: reference counted objects

[silvioprog]

On Tue, Sep 23, 2014 at 1:11 PM, Boian Mitov mi...@mitov.com wrote:

 Hi Sven,

 There is no one list.
 We have N number o data sources of many different types. The data from
 each source is processed in a pipeline of threads that cane be reconfigured
 at any time.
 New sources and new data types can be added during the runtime by the
 customers.
 The data from different pipelines can be merged split, sent over network
 and anything in between.
 This is 100% universal high performance high troghput graph parallel
 processing of very much any type of data solution. You can learn more by
 looking at the OpenWire Studio as example, (free download), but all the
 solutions are working this way.
 Any other approach has limitations, and indeed more overhead (i.e.
 additional lists and code just to maintain the data)

 With best regards,
 Boian Mitov

 ---
 Mitov Software
 www.mitov.com
 ---


Is OpenWire compatible with FPC?

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Suggestion: reference counted objects

[silvioprog]

On Tue, Sep 23, 2014 at 1:22 PM, silvioprog silviop...@gmail.com wrote:

 On Tue, Sep 23, 2014 at 1:11 PM, Boian Mitov mi...@mitov.com wrote:

 Hi Sven,

 There is no one list.
 We have N number o data sources of many different types. The data from
 each source is processed in a pipeline of threads that cane be reconfigured
 at any time.
 New sources and new data types can be added during the runtime by the
 customers.
 The data from different pipelines can be merged split, sent over network
 and anything in between.
 This is 100% universal high performance high troghput graph parallel
 processing of very much any type of data solution. You can learn more by
 looking at the OpenWire Studio as example, (free download), but all the
 solutions are working this way.
 Any other approach has limitations, and indeed more overhead (i.e.
 additional lists and code just to maintain the data)

 With best regards,
 Boian Mitov

 ---
 Mitov Software
 www.mitov.com
 ---


 Is OpenWire compatible with FPC?


Oops, yes. :-)

http://en.wikipedia.org/wiki/OpenWire_(library)

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Suggestion: reference counted objects

[silvioprog]

On Tue, Sep 23, 2014 at 1:53 PM, Boian Mitov mi...@mitov.com wrote:

   It used to be compatible, however since we rewrote it to use anonymous
 methods, and attributes (And reduced the code to 1/4 of the original size
 in the process) ~2 years ago, the new versions are not any more Lazarus
 compatible :-( .


:-(

Currently I'm programming a lot in Java (for Android) and jQuery (for web),
and I miss the dynamic methods in Object Pascal of Free Pascal (Delphi
already has, which are anonymous methods) too.

Nonproductive:

procedure TApp.DoMyButtonClick(Sender: TObject);
begin
  Alert('Button clicked');
end;

...

procedure TApp.Create(Sender: TObject);
begin
  MyButton.OnClick := @DoMyButtonClick;
end;

or:

procedure TApp.Create(Sender: TObject);
begin
  MyButton.AddOnClickHandler(@DoMyButtonClick);
end;

Productive:

procedure TApp.Create(Sender: TObject);
begin
  MyButton.SetOnClick(procedure Test; begin
  Alert('Button clicked');
  end);
end;

I have a lot of ideas to be implemented in two projects (Brook, dOpf) that
I maintain. But unfortunately it will take a while to release the new
version of the compiler (FPC 2.8), and this prevents me from continue
working to release new versions of this projects.

I'm thinking to make the new version of this projects compatible with
Delphi XE (the company that I work purchased the Delphi XE 2), so I can
increase my productivity using new features like the new RTTI, generics and
anonymous methods. But for now it will take, because I'm focused on the
Java studies.

I have reflected that in the Wikipedia OpenWire page.
 I hope one day OpenWire will again be Lazarus/FPC compatible.


Me too! (y)

I have a RESTful API written with Free Pascal 2.6.4 working like a charm
and providing data to my clients via JSON in secure HTTPS connections, but
the maintainability of this API could be improved, if the compiler decides
to follow the evolution of OO languages.

I have no knowledge to help to create this improvements in the compiler,
but I believe that the greatest difficulty here will be to convince the
guys to break paradigms and accept that the linguangens are evolving. Our
customers are increasingly demanding, so our productivity must accompany
their needs, or they look for our competitors companies!

With best regards,
 Boian Mitov


-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Suggestion: reference counted objects

[silvioprog]

On Tue, Sep 23, 2014 at 1:55 PM, Boian Mitov mi...@mitov.com wrote:

   If you read the history:

 June 12, 2013 | 6.0 | Dropped Lazarus support due to lack of language
 features.

 It is not compatible any more :-( . Hope this will change.

 With best regards,
 Boian Mitov

 ---
 Mitov Software
 www.mitov.com
 ---


:-(

Sad but true.

Me too. Hope this will change! (y)

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Suggestion: reference counted objects

[silvioprog]

On Sun, Sep 21, 2014 at 9:15 AM, Chriss Kalogeropoulos 
iz.iznog...@gmail.com wrote:

 Hi Sven,

 This design means that old classes need to be subclassed in order to
 enable this feature,  correct?
 Would it be possible instead of declaring this on the class definition, to
 declare it on the actual variable? Something like

 var aArcObj: TFooObj; refcounted;

 Or similar.

 This would allow the same classes to be used both ways.

 Also how about a smart pointer record  implementation with generics? Is it
 possible ?

 Thanks,
 Chriss


Or enabling via compiler switch, like:

http://docwiki.embarcadero.com/RADStudio/XE4/en/Automatic_Reference_Counting_in_Delphi_Mobile_Compilers

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Suggestion: reference counted objects

[silvioprog]

On Sat, Sep 20, 2014 at 10:24 AM, Chriss Kalogeropoulos 
iz.iznog...@gmail.com wrote:

 Hello all,

 IMO the best way to implement this is by controlling the TObject behaviour
 through a compiler switch, something like enable globally, disable
 globally, enable for specific class and in the latter case another
 switch should mark the class that should have this behaviour enabled.

Very nice idea, somethink like {$ARC+}, enabled by default in FPC 2.8.0,
IMHO. :-)

And it could provide an object like TManagedObject too, to use if
{$ARC-}.

 This should allow the compiler to emit different code per case.

 But the question is what should be the behaviour for genetics and also how
 should it work for packages (when and if they are implemented).
 Also should this reference count be shared for interfaced classes or not?

 Chriss


-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Suggestion: reference counted objects

[silvioprog]

On Sat, Sep 20, 2014 at 8:02 AM, Chriss Kalogeropoulos 
iz.iznog...@gmail.com wrote:

 Hi all,

 Why would anyone want something like that? Both languages have interfaces
 that can be used for auto reference counting and they also provide us with
 a very powerful abstraction mechanism.
 This also adds overhead on the performance (and locking calls) which might
 be important in some cases like embedded devices.

 The fact that embarcadero added this feature unconditionally is a huge
 mistake IMHO unless they needed it for some compatibility reasons with java
 for android or iOS or just marketing, I don't know. If someone knows any
 other reason please post it on the list.

Yes. Embarcadero thinks in productivity. See the new IDE of them, it is
extremely productive.

Unfortunately, who doesn't modernize, tied in old concepts, can lose your
market/product/space/people to your competitors, IHMO. :-/

 It's the same bad decision they made with the zero based strings, at least
 the used a switch for that.

 The only gain I can see from that is that with objects someone can use
 reference counting and still benefit from some aggressive optimisation like
 inlining which is not possible for interfaces. The same with simple
 properties that they need getter and setter methods in interfaces that
 cannot be optimized but in objects it might be possible or they can access
 the data member directly.

 In my opinion this is a very small gain compared to the huge change in the
 language semantics that you propose.

 Chriss
  Στις 20 Σεπ 2014 1:41 μ.μ., ο χρήστης Hans-Peter Diettrich 
 drdiettri...@aol.com έγραψε:

 Fabrício Srdic schrieb:

 Hello,

 In platforms with managed code (.NET, Java), objects are automatically
 freed by the memory manager / garbage collector.

 Would not it be interesting to have a similar feature in FPC?


 AFAIK some Delphi XE made TObject itself managed, by reference counting.
 It would be easy to introduce the same feature in FPC, so that no special
 base class would be required. Like with extended RTTI a decision should be
 made, whether managed objects should be enabled or disabled by default.
 Afterwards automatic management can be turned on or off for every single
 class or object individually.

  For example, through a root class where its objects are counted by
 reference, like the TInterfacedObjects. Thus, the programmer would be free
 from having to manually release objects.


 In practice it turned out that the automatic destruction of objects still
 requires assistance of the coder, in many cases, in all languages with
 garbage collection. I.e. a destructor (or finalizer) still is required to
 prepare an object for subsequent destruction.

 IMO it's sufficient to use Interfaces for all objects that should be
 subject to garbage collection.

 DoDi

 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel




-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] RTTI generating

[silvioprog]

On Fri, Sep 19, 2014 at 9:08 PM, Boian Mitov mi...@mitov.com wrote:

  Hi Hans,

 I am sorry to disagree with you.


+1.


 The attributes in particular allow you to do real magic, and reduce your
 code by at least 4 times, and speed up your development up to 10 times.


I tested the new RTTI in Delphi XE and it reduced my typing alot. See:

(* credits: https://code.google.com/p/delphi-orm/ *)
var
  person: TPerson; oid: Integer;
begin
  person := TPerson.Create('Daniele', 'Teti',32);
  Session.Save(person);
  oid := person.id;
  person.Free;
...
  person := Session.LoadTPerson(oid);
  WriteLn(‘Person name is: ‘, person.FirstName);
  person.Free;
end;

I'm using an approach like this in Android development (with Java:
http://ormlite.com/sqlite_java_android_orm.shtml).

We have done that in Delphi.
 I actually did a session in the PasCon few days on that.
 Here is example:

 TMyInterfacedClass1 = class;

 [CreateType( typeinfo( TMyInterfacedClass1 ))] // Specifies the default
 creation type as TMyInterfacedClass1
 IMyInterface = interface
  ['{EB12CEBD-42C3-4259-AE2C-70267B67F454}']

  function GetValue() : String;

 end;

 TMyInterfacedClass1 = class( TBasicInterfacedObject, IMyInterface )
 public
  function GetValue() : String;

 end;

 TMyInterfacedClass2 = class( TBasicInterfacedObject, IMyInterface )
 public
  function GetValue() : String;

 end;

 TMyNestedClass = class( TBasicObject )
 protected
  [Default( True )] // FValue1 will be initialized with True
  FValue1 : Boolean;

  [Default( 11.5 )] // FValue2 will be initialized with 11.5
  FValue2 : Real;

  [AutoManage( TMyInterfacedClass2 )] // FInterfaceValue will be created as
 TMyInterfacedClass2
  FInterfaceValue  : IMyInterface;

 public
  property Value1 : Boolean   read FValue1;
  property Value2 : Real  read FValue2;
  property InterfaceValue : IMyInterface  read FInterfaceValue;

 end;

 TMyClass = class( TBasicObject )
 protected
  [Default( 100 )] // FValue1 will be initialized with 100
  FValue1   : Integer;

  [Default( 'Helo World!' )]
  FValue2   : String; // FValue1 will be initialized with 'Helo World!'

  [AutoManage] // FNested will be automatically created and destroyed
  FNested   : TMyNestedClass;

  [AutoManage( TStringList )] // FStrings will be automatically created as
 TStringList and destroyed
  // [AutoDestroy] // - If AutoDestroy is used instead of AutoManage, the
 object will not be created but will be automatically destroyed!
  FStrings  : TStrings;

  [AutoManage] // FNested will be automatically created as TStringArrayList
  FStringArrayList  : IStringArrayList;

  [AutoManage]  // FInterfaceValue will be created as TMyInterfacedClass1
  FInterfaceValue  : IMyInterface;

 public
  property Value1 : Integer   read FValue1;
  property Value2 : Stringread FValue2;
  property Nested : TMyNestedClassread FNested;
  property Strings : TStrings read FStrings;
  property StringArrayList : IStringArrayList read FStringArrayList;
  property InterfaceValue : IMyInterface  read FInterfaceValue;

 end;


I intend to do the following if the new RTTI  (of Delphi XE) come in FPC
2.8.0 (like Java annotations):

TPerson = class(TObject) // or TSerializableObject
published
  { @code(Id): Field used to store the ID of each *Person*. }
  ['integer', 'notnull', 'autoinc', 'primarykey']
  property Id: Int64;
  { @code(Name): Field used to store the name of each *Person*. }
  ['string:50', 'nonull', 'unique']
  property Name: string;
end;

And from this object above, my framework will generate the metadata for the
table creation, generation of HTML/JS forms, generation of object mappers,
generation of CRUD web actions with their REST paths, generation of
documentation and UML, among others.


 As you can see all the management of all the classes and interfaces is
 done without the need of even one line of code.
 No constructors, no destructors, nothing.
 This alone cuts vast amounts of code.
 This however only scratches the surface of the RTTI power. You have no
 idea about some of the other possibilities ;-) .
 The RTTI does not only work with properties and fields, but with functions
 as well, allowing easy implementation of RPC and network distributed
 execution.
 It is a whole ball game.
 Frankly some of the arguments you provide ware the same I have heard 20
 years ago when I programmed in C++ and people ware telling me I should be
 doing it in Assembler.
 They simply had no idea what power OOP had as example, as you probably
 have no idea what is the real power of modern RTTI when properly used.

 I am at the same time huge fan of strong typed languages. The advanced
 RTTI does not really mean the code should and will not be strongly typed.
 Indeed I have done my own RTTI API which is stronger typed than the one
 Delphi provides.


I was very curious to see your RTTI API. :-)

-- 
Silvio Clécio
My public projects - github.com/silvioprog

Re: [fpc-devel] RTTI generating

[silvioprog]

On Sat, Sep 20, 2014 at 12:56 AM, Boian Mitov mi...@mitov.com wrote:

 Hi Silvio,

 Please contact me at mi...@mitov.com, and I will send it to you.
 It is for XE4 and higher only however since older XE versions have some
 compiler issues.
 It is a new API design from the ground up, making everything extremely
 easy to do, fixing some hierarchy design bugs in the Emb. version, and
 adding some missing information.

 We will release it in few weeks as a free download, working on the
 documentation and the demos at the moment.


This is one of the best news I've heard this week!


 With best regards,
 Boian Mitov

 ---
 Mitov Software
 www.mitov.com
 ---


I sent a private e-mail for you.

Thank you very much! (y)

@off: A long time ago, when I worked with electronics (I created PWM
amplifiers and distortion pedals for guitars), I used your library:
InstrumentalLab. Good times. :-)

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 2.6.4 release!

[silvioprog]

2014-03-11 16:36 GMT-03:00 Marco van de Voort mar...@stack.nl:


 Finally, FPC 2.6.4 has landed. FPC 2.6.4 is an update to 2.6.2 and 2.6.0
 that
 contains most library progress over the 2.6.2. It will probably conclude
 the
 2.6.x branch.

 Building is still in progress and some formats (deb) and targets might
 not be available yet.

 Changes that may break backwards compatibility are documented at:
 http://wiki.freepascal.org/User_Changes_2.6.4

 Due to issues with mirroring, please use sourceforge as much as possible,

 http://sourceforge.net/projects/freepascal/files/

 or the main (Hungarian) FTP server at

 ftp://www.hu.freepascal.org/pub/fpc/dist/2.6.4/

 We hope the freepascal.stack.nl mirror will come into sync again in the
 coming
 days.

 Enjoy!

 The Free Pascal Compiler Team


 Free Pascal Compiler

 Version 2.6.4


 **
   What's New in 2.6.4

 **

 Free Pascal 2.6.4 is a point release from the 2.6.0 fixes branch.

 Please also see http://wiki.freepascal.org/User_Changes_2.6.4 for a list
 of changes that may affect the behaviour of previously working code, and
 how to cope with these changes.

 Some highlights are:

 Packages:
   * Lots and lots fixes and improvements for fcl-db
   * web and json packages synchronized.
   * improvements to the chmcmd compiler.
   * Several fixes for winunits (and winceunits)

 Docs:
   * Many additions
   * fpjson documented.

 See http://bugs.freepascal.org/changelog_page.php for the list of reported
 bugs which have been fixed in this release.

 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Congratulations to all to the great effort! (y)

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Mailing list server migration

[silvioprog]

2014/1/3 Florian Klämpfl flor...@freepascal.org

 Ok, it looks like that things are working again. Please tell me if
 something does not work anymore.
 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Test.

Please ignore.

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Odyssey: SSockets and Threads.

[silvioprog]

 Ludo Brands ludo.brands at free.fr
 Fri Apr 26 19:25:52 CEST 2013
 If your socket is in blocking mode and you don't want your thread to
 block, yes. Server or client, there is no difference.
 The same for send. When you have a small block to send that fits in the
 socket buffer and the socket buffer is empty, send will return
 immediately. But if you have more data to send, your second send will
 block until the first send is completed.
 The same select can be used to return when the recv buffer is not empty
 or the send buffer empty  or when an exception occurs. See
 http://linux.die.net/man/2/select

 Ludo

I had not seen this reply, thanks for the explanation, Ludo. :)

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] TFPHTTPClient.FileFormPost: remove recursive path in filename.

[silvioprog]

Hello,

Please see:

http://bugs.freepascal.org/view.php?id=23977

Thanks.

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] TFPHTTPClient.FileFormPost: remove recursive path in filename.

[silvioprog]

2013/3/1 Michael Van Canneyt mich...@freepascal.org

  On Fri, 1 Mar 2013, silvioprog wrote:

  Hello,
 Please see:

 http://bugs.freepascal.org/**view.php?id=23977http://bugs.freepascal.org/view.php?id=23977


 Applied and committed. Thank you.

 Michael.


Thank you very much! :)

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] PPU version checking

[silvioprog]

2013/2/25 Sven Barth pascaldra...@googlemail.com

 Am 25.02.2013 08:27 schrieb silvioprog silviop...@gmail.com:
 
  2013/2/21 Florian Klämpfl flor...@freepascal.org
 
  Am 21.02.2013 19:43, schrieb silvioprog:
   Hello,
  
   I generates some PPUs in a version of FPC. I try to use it in other
   version of FPC, but it not compiles.
  
   So, can I disable the PPU version checking to I use my PPUs in any
   versions of FPC?
 
  It won't help, we don't change the ppu version for fun but when the
  format changes.
 
 
  So the only way that I see for using protected code and keep
 compatibility with any version of FPC, is implementing it in libraries.
 
  Thanks Florian and guys! :)

 Or you provide units only for released versions (e.g. 2.6.0, 2.6.2, etc).

 Regards,
 Sven

Yes. Very nice. Thank you very much! :)

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] PPU version checking

[silvioprog]

2013/2/25 DaWorm daw...@gmail.com

 Is the project one that can use shared libraries?  Or does the code
 require inheritance from the code you want to hide the implementation of?

 Jeff.


Is the code for a component that will be commercial. It will use classes
and inheritance.

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] PPU version checking

[silvioprog]

2013/2/25 Sven Barth pascaldra...@googlemail.com

 On 25.02.2013 15:19, silvioprog wrote:

 2013/2/25 DaWorm daw...@gmail.com mailto:daw...@gmail.com

 Is the project one that can use shared libraries?  Or does the code
 require inheritance from the code you want to hide the
 implementation of?

 Jeff.


 Is the code for a component that will be commercial. It will use classes
 and inheritance.


 Just state that your binary packages will only support selected releases.
 Most developers who buy components (and thus likely work for some company)
 are more likely to use stable versions anyway. E.g. altough I know about
 the many nice improvements in 2.7.1 I only use 2.6.0 (and in the future
 2.6.2) for development of the Free Pascal based programs in our company.

 Regards,
 Sven


Now, with the arrival of FPC 2.6.2 I believe that I'll use PPUs. Is very
annoying maintain DLLs/SOs. :S

Thank very much friend! :)

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] PPU version checking

[silvioprog]

2013/2/21 Sven Barth pascaldra...@googlemail.com

 On 21.02.2013 19:43, silvioprog wrote:

 Hello,

 I generates some PPUs in a version of FPC. I try to use it in other
 version of FPC, but it not compiles.

 So, can I disable the PPU version checking to I use my PPUs in any
 versions of FPC?


 No you can't. The PPU version is there for a purpose. We increase it if we
 did incompatible changes in the PPU file format and thus older compiler
 versions would error out with cryptical errors.
 That's one of the reasons why it might be more reasonable to use releases,
 because there the PPU version is fixed.

 Regards,
 Sven


Hum... I imagined that. Delphi also works in this way.

Thanks.

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] PPU version checking

[silvioprog]

2013/2/21 Florian Klämpfl flor...@freepascal.org

 Am 21.02.2013 19:43, schrieb silvioprog:
  Hello,
 
  I generates some PPUs in a version of FPC. I try to use it in other
  version of FPC, but it not compiles.
 
  So, can I disable the PPU version checking to I use my PPUs in any
  versions of FPC?

 It won't help, we don't change the ppu version for fun but when the
 format changes.


So the only way that I see for using protected code and keep compatibility
with any version of FPC, is implementing it in libraries.

Thanks Florian and guys! :)

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] PPU version checking

[silvioprog]

Hello,

I generates some PPUs in a version of FPC. I try to use it in other version
of FPC, but it not compiles.

So, can I disable the PPU version checking to I use my PPUs in any versions
of FPC?

Thank you!

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Extract the color data and alpha from a PNG image

[silvioprog]

Hello friends,

I'm trying to extract the color data and alpha from a PNG image. In PHP it
is very easy to implement, but in FPC I don't know how to do it. I tried to
do it via chunk.data, ZData etc., but, without success.

Attached two files to test it. To test the PHP code run this command in
your terminal:

php -f fpdf.php

The in FPC code is partially complete.

Thank you!

ps. can ZData be public?

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] FPJSONRTTI: Case insensitive.

[silvioprog]

Hello,

I have this JSON:

{ id: 1, name: Silvio Clécio }

And my object is:

TPerson = class
private
  FID: Int64;
  FName: string;
published
  property ID: Int64 read FID write FID;
  property Name: string read FName write FName;
end;

But, FPJSONRTTI don't find the fields, except if I change my class to:

  property id: Int64 read FID write FID;
  property name: string read FName write FName;

Or my JSON to:

{ ID: 1, Name: Silvio Clécio }

So, how to I find all fields but in case insensitive? (like TypInfo
functions)

Thank you!

ps. Marshal of Delphi is case insensitive.

ps2. So, I send this my questions only to fpc-devel or fpc-pascal? :/

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] [OFF-TOPIC] EazyRSS - A simple writer and reader for the RSS protocol

[silvioprog]

Hello guys,

I have forwarded this message to FPC-Pascal since it's possible that more
people is interested in this unit. :)

Thank you!

2012/11/24 Sven Barth pascaldra...@googlemail.com

 On 24.11.2012 11:48, Michael Van Canneyt wrote:



 On Sat, 24 Nov 2012, Sven Barth wrote:

  On 24.11.2012 10:55, Michael Van Canneyt wrote:



 On Sat, 24 Nov 2012, Sven Barth wrote:

  On 24.11.2012 00:41, silvioprog wrote:

 Hello,

 The Freepascal has been important to my life, so it's very nice to
 contribute with some code.
 I didn't know FPHTTPClient. But it helped me a lot since I got a
 native
 implementation for a component.
 I have implemented a component to download and parse RSS. There is
 aclass to provide the RSS service and another to read news from a
 channel.

 The result of this work is here:

 https://github.com/silvioprog/**easyrsshttps://github.com/silvioprog/easyrss


 Perhaps I should finally revive the idea of programming my own RSS
 reader (using WebKit for rendering). :D


 Should I regard this as a sign that you'd approve of including this in
 FPC ?
 I don't use RSS myself, but I know many people like it, so why not
 include it:
 With so many things moving to web, it might be useful to have...


 I would use it regardless of whether we include it or not just because
 it saves me work. :)


 That does not really answer my question... ;-)


 I don't mind including it, but I'm more a compiler hacking than
 including package guy ;)

 Regards,
 Sven

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] [OFF-TOPIC] EazyRSS - A simple writer and reader for the RSS protocol

[silvioprog]

Hello,

The Freepascal has been important to my life, so it's very nice to
contribute with some code.
I didn't know FPHTTPClient. But it helped me a lot since I got a native
implementation for a component.
I have implemented a component to download and parse RSS. There is aclass
to provide the RSS service and another to read news from a channel.

The result of this work is here:

https://github.com/silvioprog/easyrss

I liked the result of this work. There is no native units in Freepascal to
manage RSS. If the team of Freepascal regards this code can be intersting
and wants to add it to native units, for me, of course, it would be an
honor to participate in this fantastic project.
Is the FPC team likes, I will exclude this project from Github since, in
this case, it wouldn't make sense to stay there.
But whatever is the will, here I offer my work and I hope the friends like
it.

Thank you,
-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Please remove unecessary files from FPC

[silvioprog]

Hi,

Please see:

http://imagebin.org/223288

Thx.

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] MoveChars - docs.embarcadero.com ...

[silvioprog]

2012/7/22, Jonas Maebe jonas.ma...@elis.ugent.be:

 On 22 Jul 2012, at 04:54, silvioprog wrote:

 There MoveChars* function (or similar) native on Free Pascal?

 (*) -
 http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/System_MoveChars.html

 As far as I can tell,

   MoveChars(Source,Dest,Length);

 is exactly the same as

   Move(Source,Dest,Length*2);


 Jonas

Hm... I think that MoveChars copy a string to another string, but
maintaining the contents of the second string (I'm without delphi for
test it).

So, I'll try to explain my problem ...

I am needing to move a string to another string, eg:

var
  d, s: string;
begin
  d := 'the on the table';
  s := 'books ';
  SetLength(d, Length(d) + Length(s));
  Move(s, d[4], Length(s));
  writeln(d); // the result should be 'the books on the table', but I
get 'the|?S  |?e table  ?'
end;

I could easily do this using copy, but I'm trying (without success)
to do this at low level.

Thank you Jonas! :)

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] MoveChars - docs.embarcadero.com ...

[silvioprog]

2012/7/22, silvioprog silviop...@gmail.com:
[...]
 to do this at low level.

... in low level ...

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] MoveChars - docs.embarcadero.com ...

[silvioprog]

2012/7/22, Jonas Maebe jonas.ma...@elis.ugent.be:
 On 22 Jul 2012, at 20:18, silvioprog wrote:

 2012/7/22, Jonas Maebe jonas.ma...@elis.ugent.be:

 On 22 Jul 2012, at 04:54, silvioprog wrote:

 There MoveChars* function (or similar) native on Free Pascal?

 (*) -
 http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/System_MoveChars.html

 As far as I can tell,

  MoveChars(Source,Dest,Length);

 is exactly the same as

  Move(Source,Dest,Length*2);

 Hm... I think that MoveChars copy a string to another string, but
 maintaining the contents of the second string (I'm without delphi for
 test it).

 MoveChars just moves data. It has no special support for strings or anything
 else. See the example code on the Embarcadero site.

 So, I'll try to explain my problem ...

 I am needing to move a string to another string, eg:

 var
  d, s: string;
 begin
  d := 'the on the table';
  s := 'books ';
  SetLength(d, Length(d) + Length(s));
  Move(s, d[4], Length(s));

 This moves the contents of the string pointer (I suppose you are in a mode
 where string=ansistring), you have to use s[1] instead.

  writeln(d); // the result should be 'the books on the table', but I
 get 'the|?S  |?e table  ?'

 What you want is

 var
  d, s: string;
 begin
  d := 'the on the table';
  s := 'books ';
  insert(s,d,4);
  writeln(d);

 end;
 I could easily do this using copy, but I'm trying (without success)
 to do this at low level.

 I would strongly recommend against it. You'll mainly run into problems by
 combining reference counted data and low level routines. The RTL versions
 already use the low level routines in the correct ways.


 Jonas

I'll use Insert, because now I can see what is really recommended. :)

Thank you again Jonas!

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] MoveChars - docs.embarcadero.com ...

[silvioprog]

Hi,

There MoveChars* function (or similar) native on Free Pascal?

(*) - 
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/System_MoveChars.html

Thanks,

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] How to delete cookie in fcl-web?

[silvioprog]

Hello,

What better way to delete a cookie using fcl-web? Remembering that to
delete a cookie simply set the 'Thu, 01-Jan-70 00:00:01 GMT' date to
expires property.

There is a demo in freepascal showing how to do this?

I think it would be interesting to have a method to do this. :/

Thx.

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] How to delete cookie in fcl-web?

[silvioprog]

2012/7/2  michael.vancann...@wisa.be:
 On Mon, 2 Jul 2012, silvioprog wrote:

 Hello,

 What better way to delete a cookie using fcl-web? Remembering that to
 delete a cookie simply set the 'Thu, 01-Jan-70 00:00:01 GMT' date to
 expires property.

 There is a demo in freepascal showing how to do this?

 I think it would be interesting to have a method to do this. :/


 Presumably a ExpireCookie method can be added to TCookie.
 This simply sets the date to the correct value.

 Michael.

I'll make a patch to implement this. Thx guy! :)

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] How to delete cookie in fcl-web?

[silvioprog]

2012/7/2 silvioprog silviop...@gmail.com:
 2012/7/2  michael.vancann...@wisa.be:
 On Mon, 2 Jul 2012, silvioprog wrote:

 Hello,

 What better way to delete a cookie using fcl-web? Remembering that to
 delete a cookie simply set the 'Thu, 01-Jan-70 00:00:01 GMT' date to
 expires property.

 There is a demo in freepascal showing how to do this?

 I think it would be interesting to have a method to do this. :/


 Presumably a ExpireCookie method can be added to TCookie.
 This simply sets the date to the correct value.

 Michael.

 I'll make a patch to implement this. Thx guy! :)

Patch and demo to test it in:

http://bugs.freepascal.org/view.php?id=22361

thx.

ps. plz sorry for my english. ^^'

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] How to set code page in terminal? (Windows)

[silvioprog]

2012/6/21 Paul Ishenin paul.ishe...@gmail.com:
 22.06.12 5:39, silvioprog пишет:

 Hello,

 I'm trying to write Atenção in terminal, but it writes At├º├úo
 instead of Atenção (please see http://imagebin.org/217387 ). :(

 ...

 program test;

 {$mode objfpc}{$H+}


 try {$codepage utf8} or add an utf8 BOM because your constant is encoded in
 utf8.

 Best regards,
 Paul Ishenin

Oh yeah! Worked fine with this define: http://imagebin.org/217405.

Thank you! ^^

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] There is a FTP/HTTP to download only daily snapshots of the Free Pascal? (setup for Windows)

[silvioprog]

2012/6/15 Tomas Hajny xhaj...@hajny.biz:
 On Fri, June 15, 2012 03:27, silvioprog wrote:

 Hi,

 For Lazarus, I get daily snapshots on this link:

 ftp://freepascal.dfmk.hu/pub/lazarus/snapshots/

 Right, but if I want to download only the Free Pascal?

 Well, normally it should be available on
 ftp://ftp.freepascal.org/pub/fpc/snapshot/. The trouble is that there are
 no recent snapshots available there for some reason. :-( I suspect that it
 may be related to issues we had with the virtual host providing the FTP
 service. We need to check what's going on there...

 Tomas

This is the official URL, but it's very outdated. :(

Please see: http://imagebin.org/216645

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] There is a FTP/HTTP to download only daily snapshots of the Free Pascal? (setup for Windows)

[silvioprog]

Hello,

For Lazarus, I get daily snapshots on this link:

ftp://freepascal.dfmk.hu/pub/lazarus/snapshots/

Right, but if I want to download only the Free Pascal?

Thanks,

ps. Please update this link: ftp://freepascal.dfmk.hu/pub/fpc/snapshot/

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server

[silvioprog]

2012/3/20 Marcos Douglas m...@delfire.net:
 On Tue, Mar 20, 2012 at 5:57 PM, silvioprog silviop...@gmail.com wrote:
 This error occurs to me too. Please see this video:

 http://silvioprog.com.br/video/bug/sqldb

 Lazarus 0.9.30.4 r35940 FPC 2.6.0 i386-win32-win32/win64 + openSUSE 12
 / Windows 7 + PQConnection + PostgreSQL 8.4.

 Silvio,
 Thanks for the video... but I think did you wanted to post in this thread:
 http://lists.freepascal.org/lists/fpc-pascal/2012-March/032845.html

 Am I right?  ;-)

 Marcos Douglas

Oops, I confused the link, sorry. ^^'

-- 
Silvio Clécio

Site - silvioprog.com.br
LazSolutions - code.google.com/p/lazsolutions
LazWebSolutions - github.com/silvioprog/lazwebsolutions

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel