Re: [fpc-pascal] ppcjvm issues

[Jonas Maebe]

On 27/01/17 22:18, Dmitry Boyarintsev wrote:

How about moving "nil"-ing of the reference into default FreeInstance
for JVM target?


FreeInstance is a regular instance method. Instance methods cannot nil 
the self pointer (well, they can, but that will just nil the local copy 
of the self-pointer).



The whole point of removing the reference, is to let the collector to
dispose of the object as soon as possible.


The collector only runs very occasionally. If you need instant freeing, 
a garbage-collected platform is not what you want.



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

Re: [fpc-pascal] ppcjvm issues

[Dmitry Boyarintsev]

On Fri, Jan 27, 2017 at 1:41 PM, Jonas Maebe  wrote:

>  It is defined as "if the instance is not nil, then it calls the destroy
> method, and next it calls FreeInstance". You could override FreeInstance to
> not free memory on any platform.
>
> However, if JVM free method would at least reset "o" reference to nil,
>> then the semantic of "o" being an invalid object remains.
>>
>
> There is no need to do this.
>
> It also suggests to the garbage collector that the memory could be
>> recycled earlier, that the variable leaves the scope.
>>
>
> That is true.


How about moving "nil"-ing of the reference into default FreeInstance for
JVM target?

The whole point of removing the reference, is to let the collector to
dispose of the object as soon as possible.

I'm thinking about classes that consume a lot of (system) resources and
release them only in during destruction.
Releasing them as soon as possible **might** be a benefit for the code
behavior over all.

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

Re: [fpc-pascal] ppcjvm issues

[Jonas Maebe]

On 27/01/17 19:37, Dmitry Boyarintsev wrote:

Object Pascal semantic of calling .Free suggests that "o" would no
longer be a valid object.
If a dummy Free method is available for JVM, then such semantic is violated.


Calling Free is not defined as "any further access to this object must 
now crash or return invalid data". It is defined as "if the instance is 
not nil, then it calls the destroy method, and next it calls 
FreeInstance". You could override FreeInstance to not free memory on any 
platform.



However, if JVM free method would at least reset "o" reference to nil,
then the semantic of "o" being an invalid object remains.


There is no need to do this.


It also suggests to the garbage collector that the memory could be
recycled earlier, that the variable leaves the scope.


That is true.


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

Re: [fpc-pascal] TProcess vs RunProcess()

[Marco van de Voort]

In our previous episode, Graeme Geldenhuys said:
> > 
> > if you are talking about executeprocess, test again with trunk.
> 
> At the moment we are using FPC 2.6.4 and might move to FPC 3.0.2 when
> that is final. Not using Trunk I'm afraid.
> 
> Was the 260 char limit removed/fixed in FPC trunk?

First, I'm not aware of a different between the two, so if you have tests
for that I'm interested. (at least if you are testing 3.0 or newer, but that
I can easily do myself if you have simple reproduction case).

The strange thing is that all variants use CreateProcess, but afaik only
executeprocess in trunk uses the -w variant. I started upgrading tprocess,
but it got out of hand, and I shelved the work.

Afaik by prefixing with \\.\ you can use larger paths with -w variants.

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

Re: [fpc-pascal] ppcjvm issues

[Dmitry Boyarintsev]

On Fri, Jan 27, 2017 at 12:52 PM, Jon Foster 
wrote:

> Correct me if I'm wrong: It would seem like that your free implementation
>> doesn't actually do anything, other than fulfilling the obligation of
>> having a "free". If I do this:
>>
>
> var
> o: TObject;
> begin
> o:=TObject.create;
> { do something ... }
> o.free;
> end.
>
> Wouldn't "o" still contain a reference after "free" is called? In non-JVM
> FPC "self" is just another variable, who's origin is somewhat hidden by the
> compiler. The call to "o.free" would do something like "TObject.free(o)"
> where "o" is passed by *value* into the procedure variable "self". "Self"
> comes and goes with the scope of the "TObject.free" procedure. Which is why
> if I'm concerned about detecting whether or not "o" still contains a
> correct object reference I would need to do something like this: "o.free;
> o:=nil;" so I can test for "nil" later. Although I think FPC added a
> procedure to do that some time back. Yup, I see it "SysUtils.FreeAndNil".
>
> I'm not sure of the specific semantics of the JVM calls but from what I
> read in the various FPC JVM related pages on the wiki it would seem to use
> similar semantics.


Object Pascal semantic of calling .Free suggests that "o" would no longer
be a valid object.
If a dummy Free method is available for JVM, then such semantic is violated.

However, if JVM free method would at least reset "o" reference to nil, then
the semantic of "o" being an invalid object remains.

It also suggests to the garbage collector that the memory could be recycled
earlier, that the variable leaves the scope.

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

Re: [fpc-pascal] ppcjvm issues

[Jon Foster]

On 01/27/2017 08:48 AM, Jonas Maebe wrote:

On 27/01/17 02:31, Jon Foster wrote:

But any classes defined in Pascal provide those methods, if they descend
from the default TObject. I think I read somewhere that classes can be
defined that descend from the base Java class but I haven't done it.


All classes on the JVM descend from a Java class. The Java Runtime does 
not support classes that don't descend directly or indirectly from 
java.lang.Object.
Yes, BUT: TObject is provided by the "system" unit in FPC and although it 
descends from JLObject it provides basic FPC like semantics, including 
free/destroy. FPC treats " TMyClass = class ..." just like it does in the 
native code versions and TMyClass would descend from TObject inheriting its 
methods. So unless you tried to create a class which directly descended 
from JLObject, instead of TObject you inherit "free" and "destroy", so you 
can call them as you usually would.


Other than missing unit functionality I've found the JVM implementation 
makes Java seem very Pascal like. The devs have done a splendid job IMO. It 
did take me a while to find the Java lib equivalent of StrToInt. :-D


-Jon

--
Jon Foster
JF Possibilities, Inc.

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

Re: [fpc-pascal] ppcjvm issues

[Jon Foster]

On 01/27/2017 06:36 AM, Dmitry Boyarintsev wrote:
On Tue, Jan 10, 2017 at 6:14 AM, Michael Schnell > wrote:



If destroying an object is not necessary, the class should provide a
dummy Free procedure. So the application programmer always can/should
use Free.

Why dummy? if it should be like this

procedure TObject.Free;
begin
if Self<>nil then Self:=nil;
end;

Destroying object is not necessary, but dereferencing is.
If the code keeps the reference to an object, it would not be collected.
[...]
Correct me if I'm wrong: It would seem like that your free implementation 
doesn't actually do anything, other than fulfilling the obligation of 
having a "free". If I do this:


var
o: TObject;
begin
o:=TObject.create;
{ do something ... }
o.free;
end.

Wouldn't "o" still contain a reference after "free" is called? In non-JVM 
FPC "self" is just another variable, who's origin is somewhat hidden by the 
compiler. The call to "o.free" would do something like "TObject.free(o)" 
where "o" is passed by *value* into the procedure variable "self". "Self" 
comes and goes with the scope of the "TObject.free" procedure. Which is why 
if I'm concerned about detecting whether or not "o" still contains a 
correct object reference I would need to do something like this: "o.free; 
o:=nil;" so I can test for "nil" later. Although I think FPC added a 
procedure to do that some time back. Yup, I see it "SysUtils.FreeAndNil".


I'm not sure of the specific semantics of the JVM calls but from what I 
read in the various FPC JVM related pages on the wiki it would seem to use 
similar semantics.


- Jon

--

Jon Foster
JF Possibilities, Inc.

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

Re: [fpc-pascal] TProcess vs RunProcess()

[Marco van de Voort]

In our previous episode, Graeme Geldenhuys said:
> > pause it, write to stdin, read from stdout.
> > 
> > These things cannot be done with RunProcess. 
> > That's one-shot and wait till it exits.
> 
> Another difference simply so others might learn from this discussion
> (like I did).

> If you have a huge list of parameters, RunProcess() - at least under
> Windows - will most likely hit a 260 character limit, and then fail to
> actually execute. I don't actually know where that 260 limit originates
> from (Windows API, Command Prompt, FPC etc).

Which runprocess are you talking about? I know a process.runcommand and a
sysutils.executeprocess, but not a runprocess.

> Whereas if you use TProcess and the Parameters (TStrings) property, you
> don't have such a limitation.
> 
> This was what I experienced.

if you are talking about executeprocess, test again with trunk.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] TProcess vs RunProcess()

[Graeme Geldenhuys]

On 2017-01-26 14:28, Michael Van Canneyt wrote:
> TProcess gives you full access to the process. You can kill it,
> pause it, write to stdin, read from stdout.
> 
> These things cannot be done with RunProcess. 
> That's one-shot and wait till it exits.

Another difference simply so others might learn from this discussion
(like I did).

If you have a huge list of parameters, RunProcess() - at least under
Windows - will most likely hit a 260 character limit, and then fail to
actually execute. I don't actually know where that 260 limit originates
from (Windows API, Command Prompt, FPC etc).

Whereas if you use TProcess and the Parameters (TStrings) property, you
don't have such a limitation.

This was what I experienced.

Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] ppcjvm issues

[Jonas Maebe]

On 27/01/17 02:31, Jon Foster wrote:

But any classes defined in Pascal provide those methods, if they descend
from the default TObject. I think I read somewhere that classes can be
defined that descend from the base Java class but I haven't done it.


All classes on the JVM descend from a Java class. The Java Runtime does 
not support classes that don't descend directly or indirectly from 
java.lang.Object.



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

Re: [fpc-pascal] Pipe vs Memory buffer.

[fredvs]

Hello.

> Some streams requires you set its cursor to 0 before writing/reading
> buffer, so you need to check it:

> OutPipe.Seek(0, soBeginning);
> InPipe.Seek(0, soBeginning);
> InPipe.Read(BufferURL[0],PipeBufferSize);

=>

"Exception at 0043A720: EPipeSeek:
Cannot seek on pipes."

> So to resume, you file is a raw opus audio or an Ogg file ? 

Huh, I do not know. It was converted from a mp3.
Localy, from a hard-disk:

Using op_test_file("test.opus") + op_open_test() is working perfectly.

IMO, the problem comes from abuffer in op_test_memory(abuffer,lengthb).

I am not sure that a array of byte is what op_test_memory want.
It is not a pipe (like lot of other audio lib use), if it is not a array of
byte, what does he want...?

> Said that, I had never touched opus in my life :) 

So I am not the only one. ;-)

PS: On Opus forum, there is only one topic this year. Without answer. (And
this topic is from me !).

Fre;D











-
Many thanks ;-)
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Pipe-vs-Memory-buffer-tp5727435p5727462.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] ppcjvm issues

[Dmitry Boyarintsev]

On Tue, Jan 10, 2017 at 6:14 AM, Michael Schnell  wrote:

>
> If destroying an object is not necessary, the class should provide a dummy
> Free procedure. So the application programmer always can/should use Free.
>
> Why dummy? if it should be like this

procedure TObject.Free;
begin
  if Self<>nil then Self:=nil;
end;

Destroying object is not necessary, but dereferencing is.
If the code keeps the reference to an object, it would not be collected.

For example. In pascal:
var
  b : TSomeClass;
begin
  b := TSomeClass.Create; // allocated
  ..
  b.Free;  // freed (b becomes an invalid pointer)
  ...
end.

JVM with dummy Free
var
  b : TSomeClass;
begin
  b := TSomeClass.Create; // allocated
  ..
  b.Free;  // does nothing (b remains a valid pointer)
  ...
end.// a might be freed after leaving  the scope of visibility

JVM with nil-ing Free.
var
  b : TSomeClass;
begin
  b := TSomeClass.Create; // allocated
  ..
  b.Free;  // derefering a, (a, become nil)

  ... // a might be Freed here somewhere, whenever gc occurs
end.

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

Re: [fpc-pascal] Pipe vs Memory buffer.

[José Mejuto]

El 27/01/2017 a las 3:52, fredvs escribió:

Hello Silvio:

Yes, we are on the good way.
Following your advice, here from https-url-opus the result of :



Hello,

The first thing to debug this problems is to determine the expected data 
for opus_test_memory. Usually streams (audio, video, etc...) are 
composed by two pieces the raw data and the transport envelope. In this 
case opus usually uses Ogg as transport envelope but it could be 
streamed in another container like MP4, MKV, etc.


Opus library should provide a play engine that decodes raw streams, 
extracted from its transport layer and maybe another series of APIs for 
the default transport layer, Ogg in this case. This last job seems to be 
done by the OpusFile API.


So to resume, you file is a raw opus audio or an Ogg file ?

Before using pipes with http try pipes with a local file. If your pipes 
on local file works but http does not maybe you are receiving the http 
headers, or any other unexpected situation, so dump the piped data to a 
local file and match it against the remote one.


Said that, I had never touched opus in my life :) so take my comments 
with care.


--

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