[fpc-pascal] loadlibrary() unsafe ?

2015-06-11 Thread Fred van Stappen 

Hello.


Here the thing: a open-source program, eSpeak (voice synthezer) uses 2 
libraries: espeak-library and portaudio.


In eSpeak source =>


- For the Windows version, the libraries are included in the executable (static 
linked).

  To do run the program => it is easy => just run the executable via TProcess 
(espeak.exe).


- For Linux, the eSpeak source produces a executable with static
 espeak-library included but without static portaudio-library included 
in executable.

  So portaudio library must be installed in library path of the system.

  If portaudio is not installed in library path of the system, a trick that 
works is:


  To do run the program => 

  - first dynamic load portaudio with 
loadlibrary('/the_path_you_want/libportaudio.so').

  - run the executable via TProcess (espeak).


- For freeBSD, the eSpeak source produces a executable without 
static espeak-library nor static portaudio-library included in 
executable.

  So both espeak-library and portaudio-library must be installed in library 
path of the system.

  If libraries are not installed in library path of the system, a trick that 
works is:


  To do run the program => 

  - first dynamic load portaudio with 
loadlibrary('/the_path_you_want/libportaudio.so').

  - then dynamic load libespeak with 
loadlibrary('/the_path_you_want/libespeak.so').

  - run the executable via TProcess (speak).


All is working like charms.


Now i heard that this trick is unsafe.


Why ?


Many thanks.


Fre;D
  ___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC roadmap?

2015-06-11 Thread Juha Manninen 
On Mon, Jun 1, 2015 at 12:17 AM, Jonas Maebe  wrote:
> I don't think much will still change to that branch before the release.

Then please release ASAP.

I have one sincere question: Will FPC 3.0 happen this year?
Typically from RC1 it takes ~3-4 months to the release. Now we don't
have even RC1 in sight.
Say you build RC1 after 2 months, that's August.
3-4 months from that will be November or December, still (barely) in this year.

Sorry I am joining the group asking about schedule but the situation
is getting annoying.
More and more often a development version of FPC must be recommended
for people because of Unicode, generics and many other improvements.
It does not feel right. Fortunately fpcup is now maintained again but
it cannot replace an FPC release obviously.

Are there open issues blocking the release? Do you need help with them?

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

[fpc-pascal] loadlibrary() unsafe ?

2015-06-11 Thread fredvs 
Hello.

Here the thing: a open-source program, eSpeak (voice synthezer) uses 2
libraries: espeak-library and portaudio.

In eSpeak source =>

- For the Windows version, the libraries are included in the executable
(static linked).
  To do run the program => it is easy => just run the executable via
TProcess (espeak.exe).

- For Linux, the eSpeak source produces a executable with static
espeak-library included but without static portaudio-library included in
executable.
  So portaudio library must be installed in library path of the system.
  If portaudio is not installed in library path of the system, a trick that
works is:

  To do run the program => 
  - first dynamic load portaudio with
loadlibrary('/the_path_you_want/libportaudio.so').
  - run the executable via TProcess (espeak).

- For freeBSD, the eSpeak source produces a executable without static
espeak-library nor static portaudio-library included in executable.
  So both espeak-library and portaudio-library must be installed in library
path of the system.
  If libraries are not installed in library path of the system, a trick that
works is:

  To do run the program => 
  - first dynamic load portaudio with
loadlibrary('/the_path_you_want/libportaudio.so').
  - then dynamic load libespeak with
loadlibrary('/the_path_you_want/libespeak.so').
  - run the executable via TProcess (speak).

All is working like charms.

Now i heard that this trick is unsafe.

Why ?

Many thanks.

Fre;D




-
Many thanks ;-)
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/loadlibrary-unsafe-tp5721801.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC roadmap?

2015-06-11 Thread Michael Van Canneyt 



On Wed, 10 Jun 2015, Juha Manninen wrote:


On Mon, Jun 1, 2015 at 12:17 AM, Jonas Maebe  wrote:

I don't think much will still change to that branch before the release.


Then please release ASAP.

I have one sincere question: Will FPC 3.0 happen this year?
Typically from RC1 it takes ~3-4 months to the release. Now we don't
have even RC1 in sight.
Say you build RC1 after 2 months, that's August.
3-4 months from that will be November or December, still (barely) in this year.

Sorry I am joining the group asking about schedule but the situation
is getting annoying.
More and more often a development version of FPC must be recommended
for people because of Unicode, generics and many other improvements.
It does not feel right. Fortunately fpcup is now maintained again but
it cannot replace an FPC release obviously.

Are there open issues blocking the release? Do you need help with them?


The documentation is the only 'blocking' issue. 
Maybe for good measure some extra fixes need to be merged.


I have documented the remaining identifiers in the reference documentation, 
but the new language features still need to be documented; 
Normally, the biggest part can be done tomorrow and the day after.


After that (as in: as of monday) as far as I am concerned, RC1 may be built.

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

Re: [fpc-pascal] FPC roadmap?

2015-06-11 Thread Juha Manninen 
On Thu, Jun 11, 2015 at 5:33 PM, Michael Van Canneyt
 wrote:
> After that (as in: as of monday) as far as I am concerned, RC1 may be built.

That would be sooner than I expected. Cool! Thanks in advance.

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

Re: [fpc-pascal] FPC roadmap?

2015-06-11 Thread Maciej Izak 
any chance to release FPC 3.0 with Generics.Collections library?

2015-06-11 16:33 GMT+02:00 Michael Van Canneyt :
>
> The documentation is the only 'blocking' issue. Maybe for good measure
> some extra fixes need to be merged.
>

best regards,
Maciej Izak
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] [PATCH] Extends SetPropValue/GetPropValue making it compatible with new versions of Delphi

2015-06-11 Thread silvioprog 
Hello,

Please see it in:

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

Thank you!

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

Re: [fpc-pascal] FPC roadmap?

2015-06-11 Thread Jonas Maebe 

Maciej Izak wrote:

any chance to release FPC 3.0 with Generics.Collections library?


No, FPC 3.0 was already feature frozen around September last year.


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

Re: [fpc-pascal] FPC roadmap?

2015-06-11 Thread Sven Barth 
Am 11.06.2015 19:31 schrieb "Jonas Maebe" :
>
> Maciej Izak wrote:
>>
>> any chance to release FPC 3.0 with Generics.Collections library?
>
>
> No, FPC 3.0 was already feature frozen around September last year.
>

And as written in the corresponding bug report I'm not really happy with
these interface hacks.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC roadmap?

2015-06-11 Thread Maciej Izak 
>
> And as written in the corresponding bug report I'm not really happy with
> these interface hacks.
>
> Regards,
> Sven
>
So please give any alternative solution (with reasonable efficiency /
performance).

Current solution is inspired by you in 2013 :P

2013/5/23 Sven Barth

>
> Why fall back to pointers for something like this if we can use static
> types?! And if that means that the comparer needs to be implemented for
> each type, then so be it
>
>
My first idea for Generics.Defaults in 2013 was much simpler (and faster
than using interfaces), new compiler intrinsic:

  function GetReferenceToValue(Value: T): Pointer;
  function GetValueSize(Value: T): Integer;


Best regards,
Maciej Izak
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC roadmap?

2015-06-11 Thread Maciej Izak 
Hi,

btw. there is no info about few functions introduced by
Generics.Collections patch, as I can see all of my work for RTL is now part
of FPC 3.0 compiler ^^ :)

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

procedure InitializeArray(p: Pointer; typeInfo: Pointer; elemCount:
NativeUInt);
procedure CopyArray(Dest, Source, TypeInfo: Pointer; Count: NativeInt);
procedure FinalizeArray(P: Pointer; TypeInfo: Pointer; Count: NativeUInt);
procedure DynArrayClear(var A: Pointer; TypeInfo: Pointer);
procedure DynArraySetLength(var a: Pointer; typeInfo: Pointer; dimCnt:
NativeInt; lengthVec: PNativeInt);
function DynArrayIndex(P: Pointer; const Indices: array of NativeInt;
TypInfo: Pointer): Pointer; overload;
function DynArrayIndex(P: Pointer; const Indices: array of Integer;
TypInfo: Pointer): Pointer; overload;
function DynArrayDim(typeInfo: Pointer): Integer;
function DynArraySize(A: Pointer): NativeInt;
function IsDynArrayRectangular(const DynArray: Pointer; typeInfo: Pointer):
Boolean;
function DynArrayBounds(const DynArray: Pointer; typeInfo: Pointer):
TBoundArray;


2015-06-11 16:33 GMT+02:00 Michael Van Canneyt:
>
> The documentation is the only 'blocking' issue. Maybe for good measure
> some extra fixes need to be merged.
>
> I have documented the remaining identifiers in the reference
> documentation, but the new language features still need to be documented;
> Normally, the biggest part can be done tomorrow and the day after.
>
> After that (as in: as of monday) as far as I am concerned, RC1 may be
> built.


best regards,
Maciej Izak
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC roadmap?

2015-06-11 Thread Maciej Izak 
>
> btw. there is no info about few functions introduced by
> Generics.Collections patch, as I can see all of my work for RTL is now part
> of FPC 3.0 compiler ^^ :)
>
>
ofc. except generics.* units :)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC roadmap?

2015-06-11 Thread Michael Van Canneyt 



On Thu, 11 Jun 2015, Maciej Izak wrote:


Hi,
btw. there is no info about few functions introduced by Generics.Collections 
patch, as I can see all of my work for RTL is now
part of FPC 3.0 compiler ^^ :)
http://bugs.freepascal.org/view.php?id=27206

procedure InitializeArray(p: Pointer; typeInfo: Pointer; elemCount: NativeUInt);
procedure CopyArray(Dest, Source, TypeInfo: Pointer; Count: NativeInt);
procedure FinalizeArray(P: Pointer; TypeInfo: Pointer; Count: NativeUInt);
procedure DynArrayClear(var A: Pointer; TypeInfo: Pointer);
procedure DynArraySetLength(var a: Pointer; typeInfo: Pointer; dimCnt: 
NativeInt; lengthVec: PNativeInt);
function DynArrayIndex(P: Pointer; const Indices: array of NativeInt; TypInfo: 
Pointer): Pointer; overload;
function DynArrayIndex(P: Pointer; const Indices: array of Integer; TypInfo: 
Pointer): Pointer; overload;
function DynArrayDim(typeInfo: Pointer): Integer;
function DynArraySize(A: Pointer): NativeInt;
function IsDynArrayRectangular(const DynArray: Pointer; typeInfo: Pointer): 
Boolean;
function DynArrayBounds(const DynArray: Pointer; typeInfo: Pointer): 
TBoundArray;


These functions have been documented. 
All existing identifiers in documented units have been documented.


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

Re: [fpc-pascal] FPC roadmap?

2015-06-11 Thread Maciej Izak 
2015-06-11 22:24 GMT+02:00 Michael Van Canneyt:
>
>
> These functions have been documented. All existing identifiers in
> documented units have been documented.
>
>

Thanks for replay.
I looked elsewhere (and there is no info):

http://wiki.freepascal.org/FPC_New_Features_3.0
http://wiki.freepascal.org/User_Changes_3.0

regards,
Maciej Izak
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC roadmap?

2015-06-11 Thread Michael Van Canneyt 



On Thu, 11 Jun 2015, Maciej Izak wrote:



2015-06-11 22:24 GMT+02:00 Michael Van Canneyt:

  These functions have been documented. All existing identifiers in 
documented units have been documented.



Thanks for replay.
I looked elsewhere (and there is no info):

http://wiki.freepascal.org/FPC_New_Features_3.0
http://wiki.freepascal.org/User_Changes_3.0


Some new functions are never considered new features.

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