Re: [fpc-pascal] Language constructs and types that dependent upon system unit

[Lars]

Forgot to mention,  you can also write your own system unit and swap it in
place (in delphi and fpc).  You can modify existing system unit or even
rewrite your own system unit from scratch..

KOL/mck project does this sort of thing to decrease executable size to a
miniature size. Embedded programmers sometimes write their own system unit
too, for size constraints or special situations on embedded systems.

So don't feel that you are limited to the system.pp unit that you are
provided with delphi for fpc, as you can modify it... or even rewrite it
from scratch (not for faint of heart, but Kol/mck does something like it)

On Thu, January 19, 2017 1:28 pm, gabor wrote:
> I was hoping that maybe there is an easy answer. But I understand.
> Thanks.
>
>
> Michał.
>
>
> W dniu 2017-01-19 o 20:28, Jonas Maebe pisze:
>
>> It is therefore not possible to give an answer to your question that is
>>  generally valid. Furthermore, the answer could become wrong at any
>> time because all of that is implementation-dependent.
>>
>>
>> Jonas
>>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

Re: [fpc-pascal] FPC run (run program after compile)

[Lars]

On Mon, January 16, 2017 1:21 pm, Lars wrote:
..
> On Mon, January 16, 2017 3:59 am, Sven Barth wrote:
>> No, FPC is a compiler, not a "runner" or debugger. That would even be
>> one of the few points where patches would *not* be welcome.
>>
>
> fpcrun.exe is an alternative to "fpc run"
>
> fpcrun.exe is trivial, and I can copy it into my fpc directory.. but
> wondered if others needed it.

trivial indeed...

https://github.com/z505/fpcRun

Project started on github. Tested to work on Windows.

Now I just have to try Unix, as, executeprocess works slightly different
on that system and some absolute path configuration to fpc might be
needed.

So basically FPCRUN.EXE project is now known as fpr.exe... as fpr is
easier to type at the command line for the lazy
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Array as result in function.

[fredvs]

And this one ?

op_read: function(OpusFile: TOggOpusFile; pcm : pcint; SampleCount: Integer;
li: pcint): Integer;
op_read_float: function(OpusFile: TOggOpusFile; pcm : pcfloat; SampleCount:
Integer; li: pcint): Integer;
op_read_stereo: function(OpusFile: TOggOpusFile; pcm : pcint; SampleCount:
Integer): Integer;
op_read_float_stereo: function(OpusFile: TOggOpusFile; pcm : pcfloat;
SampleCount: Integer): Integer;

PS: I agree with you : op_read needs a pcm=pcint.
Is it a big crime to use pcm=pcfloat ?
This because I want to use the same main buffer for all formats (16int,
32int and float 32).
And because it is working perfectly.

But, yes, maybe using a int-temp-buffer and then copy its data to the main
float-buffer would be more academic.

Other thing.

On Linux, LibOpus.so and LibOpusFile.so home-compiled are working like
charms.

Sadly, on Windows, using the pre-compiled dll downloaded from Opus-site, I
have problem with OpusFile.dll.

I have checked the dependencies, they are installed.

Opus.dll loads and all methods can be accessed.

But with OpusFile.dll, it loads but trying to access any method gives:

Program received signal SIGSEGV, Segmentation fault.
0x74728ff0 in strlen () from C:\WINDOWS\SYSTEM32\msvcrt.dll

Aaargh, Google did not help.

Many thanks.

Fre;D



-
Many thanks ;-)
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Array-as-result-in-function-tp5727366p5727394.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] Array as result in function.

[silvioprog]

On Sat, Jan 21, 2017 at 11:11 AM, fredvs  wrote:

> Hello everybody.
>
> Do you agree with this ? :
>
> type
>   TOggOpusFile = ^OggOpusFile;
>   OggOpusFile = record
>   end;
>
> op_read: function(OpusFile: TOggOpusFile; pcm : pcfloat; SampleCount:
> Integer; li: pointer): Integer;
>

It's almost there. :-)

Notice my message regarding the op_read's pcm and li parameters type ...

op_read_float: function(OpusFile: TOggOpusFile; pcm : pcfloat; SampleCount:
> Integer; li: pointer): Integer;
> op_read_stereo: function(OpusFile: TOggOpusFile; pcm : pcfloat;
> SampleCount:
> Integer): Integer;
> op_read_float_stereo: function(OpusFile: TOggOpusFile; pcm : pcfloat;
> SampleCount: Integer): Integer;
>
> Fre;D
>
> -
> Many thanks ;-)


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

Re: [fpc-pascal] Array as result in function.

[fredvs]

Hello everybody.

Do you agree with this ? :

type
  TOggOpusFile = ^OggOpusFile;
  OggOpusFile = record
  end;

op_read: function(OpusFile: TOggOpusFile; pcm : pcfloat; SampleCount:
Integer; li: pointer): Integer;
op_read_float: function(OpusFile: TOggOpusFile; pcm : pcfloat; SampleCount:
Integer; li: pointer): Integer;
op_read_stereo: function(OpusFile: TOggOpusFile; pcm : pcfloat; SampleCount:
Integer): Integer;
op_read_float_stereo: function(OpusFile: TOggOpusFile; pcm : pcfloat;
SampleCount: Integer): Integer;

Fre;D




-
Many thanks ;-)
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Array-as-result-in-function-tp5727366p5727392.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] Array as result in function.

[Vojtěch Čihák]

Hi,
 
that's why portaudio.pp declares types like this:
 
PaStream = Pointer;
PPaStream = ^PaStream;
PPPaStream = ^PPaStream;
 
V.
__

Od: Sven Barth 
Komu: fpc-pascal@lists.freepascal.org
Datum: 21.01.2017 12:29
Předmět: Re: [fpc-pascal] Array as result in function.



If the C code however is the one allocating the array (in which case the
type is usually a pointer to a pointer, like "float**" or "^pcfloat" in
Pascal) then you *must not* use a Pascal array, but instead simply pass
in a "pcfloat" variable like this:

some_func(@mypcfloat);

I hope this clears up a few points for mixing C and Pascal arrays.

Regards,
Sven

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


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

Re: [fpc-pascal] Array as result in function.

[fredvs]

@ Silvio

> Try two tests:

>$ echo -e '#include \nint main(){printf("size of float: %zu\\n",
sizeof(float));return 0;}'
> fredvs.c && gcc -o fredvs fredvs.c && clear && ./fredvs # it prints "size
> of float: 4" on your terminal

==> size of float: 4

> $ echo "program fredvs;begin writeln('sizeof double: ',
> sizeof(double));writeln('size of single: ', sizeof(single));end."
> fredvs.pp && fpc fredvs.pp && clear && ./fredvs # it prints "sizeof
> double: 8" and "size of single: 4

==> sizeof double: 8
   size of single: 4

Indeed, not the same.

@ Sven.

Many thanks for your tips.
I will study it deeply and see (+understand) what is wrong in my code.

The most strange is that with my code it is working perfectly.

Fre;D




-
Many thanks ;-)
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Array-as-result-in-function-tp5727366p5727390.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] Array as result in function.

[Sven Barth]

On 20.01.2017 23:36, fredvs wrote:
> Re-hello.
> 
> Ok, thanks Silvio, I will take this one from your advice, it works like
> charm:
> 
> type
>   TOggOpusFile = THandle;
>   TDArFloat = array of cfloat;
>   PDArFloat = ^TDArFloat;
> 
> op_read: function(OpusFile: TOggOpusFile; pcm : PDArFloat; SampleCount:
> Integer; li: pointer): Integer;
> op_read_float: function(OpusFile: TOggOpusFile; pcm : PDArFloat;
> SampleCount: Integer; li: pointer): Integer;

Gah! No!

If a C function has a parameter of e.g. "float*" and it's an array you
should use the same type in FPC, in that case "pcfloat". *DO NOT* use a
Pascal dynamic array or (even worse) a pointer to a Pascal dynamic array.

You can of course use a Pascal array when calling it like this:

op_read_float(f, @arr[0], 42, whatever);

If the C code however is the one allocating the array (in which case the
type is usually a pointer to a pointer, like "float**" or "^pcfloat" in
Pascal) then you *must not* use a Pascal array, but instead simply pass
in a "pcfloat" variable like this:

some_func(@mypcfloat);

(though in that case to avoid confusion you *might* declare the
parameter as "var arg: pcfloat" or "out arg: pcfloat" which would be the
equivalent and then using "somefunc(mypcfloat) would work as well")

You can then access the C array like you'd do with a Pascal array with
"[]", like "mypcfloat[42]". Of course the C function should also tell
you the resulting length somehow ;)

I hope this clears up a few points for mixing C and Pascal arrays.

Regards,
Sven

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