Proper precedure to update/correct third party packages that has bugs?

[jamie]

I installed the ACS audio component suite from the online packager and it of course has issues.

One of them being that with fpc 3.2.x apparently its no longer allowed to index out of bounds array types with [0..0] via a pointer reference,
the compiler is inserting bounds check regardless of debugging set points in project.

 I corrected that with a unknown range set so the compiler does not fault there..

 
Another issue I found was using one of the components of the package, the TMemoryOut had a first time initial starting index out of whack
and caused memory alignment issues with the memory blocks going out to the sound system.

 That is now correct.

So the real question here is, what do  you do with the package you now have modified ?

 do I zipped the complete tree from where it was originally installed from the down load package manager? And if so, is that enough for a complete installation for others to use ?

[Fred vS]

I installed the ACS audio component suite from the online packager and it of course has issues.

One of them being that with fpc 3.2.x apparently its no longer allowed to index out of bounds array types with [0..0] via a pointer reference,
the compiler is inserting bounds check regardless of debugging set points in project.

 I corrected that with a unknown range set so the compiler does not fault there..

 
Another issue I found was using one of the components of the package, the TMemoryOut had a first time initial starting index out of whack
and caused memory alignment issues with the memory blocks going out to the sound system.

 That is now correct.

So the real question here is, what do  you do with the package you now have modified ?

 do I zipped the complete tree from where it was originally installed from the down load package manager? And if so, is that enough for a complete installation for others to use ?

ACS is on Github:
https://github.com/serbod/acs

Please do a pull-request or create a issue including your new source.

[jamie]

well thanks for pointing me to th  Gitbub and it looks like someone else found the same issue I did but their correction is in fact wrong.

with their fix the first buffer gets processed before you have a chance to put anything in it. they set the BufStart to the end of the size of the buffer during Init() which does nothing more than call the BudderDone event to get more..

 The proper fix is to set BufStart := 1 during the constructor, that seems to allow the first buffer with a clean bill of health to get processed.

 however, I saw looking at the sources the buf with 3.2.x fpc is not corrected..

 I don't see how I am able to contribute to that GitHub and it looks like the package that is offered in the online package manager is coming from a different site ?

 We need to research this more I guess..

 if any one here wants it I think I could zipped the tree up of what I have..

[Fred vS]

I don't see how I am able to contribute to that GitHub and it looks like the package that is offered in the online package manager is coming from a different site ?

Hum, afaik, OPM does use the same Github site (see picture).

About how to contribute, I am sure Serbod will be very happy is you open a issue, explain what is wrong and add in attachment your zip fixed file.

And I am sure too that Serbod would be totally happy if you do a pull-request with your code modified.

Fre;D

[jamie]

ok, but what is in the zip file which is what I installed is not what is shown as source files at GitHub

I compared the file "acs_misc" and the patch which is incorrect that shows at the GitHub sources is not in the zip file I downloaded.

so the compressed files do not match

anyways. I don't know how this is all done because looking at the GitHub I don't see the package there in a complete zip format unless I missed it..

[Fred vS]

ok, but what is in the zip file which is what I installed is not what is shown as source files at GitHub

I compared the file "acs_misc" and the patch which is incorrect that shows at the GitHub sources is not in the zip file I downloaded.

so the compressed files do not match

anyways. I don't know how this is all done because looking at the GitHub I don't see the package there in a complete zip format unless I missed it..

Maybe ask this to GetMem, the OPM maintainer.

It is possible that the zip file from the OPM server is not the one from last commit of GitHub.

[Fred vS]

Hello.

I think that OPM uses the release version of ACS:
https://github.com/serbod/acs/releases/tag/3.0.1

But, yes, there is 5 new commits after this (trunk).
Anyway, it is better to work on the last commit and make your change there.

After this, Serbod will decide if a new release should be done.

[jamie]

3.0.1 is what I have and the files do not match what i have.,.

i think there is some mix up as to how they maintain their files, most likely SVN version higher than what is in the ZIp package..

I can later link to it via a Tor.... i guess to see if that works for updates. Does not look like it's a very active site for this.

[Fred vS]

3.0.1 is what I have and the files do not match what i have.,.

i think there is some mix up as to how they maintain their files, most likely SVN version higher than what is in the ZIp package..

I can later link to it via a Tor.... i guess to see if that works for updates. Does not look like it's a very active site for this.

I dont understand what you want to do.

The original ACS source is maintained on Github: https://github.com/serbod/acs/

Afaik, ACS dont use svn but git.

[jamie]

I guess we don't understand each other..

I am trying to tell you that the code at git is defective. it has fixes in there that does not exist in the same release numbers and these fixes are not correct.

 I won't go with this any more. I am not installing the git files since I've already looked at them and they are not worthy of doing so..

 if the package manager in Laz is actually getting the zip file from there then the contents of the zip are not what is on git.. that is what i am trying to convey to you.

 And the files present at git, those that are not in the ZIP file are incorrectly patched and still don't work correctly.

 either case, none of them will work with the 3.2.x and up compiler in their present form..

I will compress a working zip archive to put here if it fits for any to look at for use with newer laz.

and if i can figure out how to contact the author I can take this up with them because its not like dealing with the trunk which has a forum and site specific for the project.

[wp]

The files distributed by OPM usually are not the development versions found in git or svn repositories; they are special release versions provided by the package maintainers. The reason is that OPM should only provide stable versions.

[PascalDragon]

One of them being that with fpc 3.2.x apparently its no longer allowed to index out of bounds array types with [0..0] via a pointer reference,
the compiler is inserting bounds check regardless of debugging set points in project.

Can you please provide an example (or point to the code in question), cause the following works for me in 3.2.0 with range checks disabled:

Code: Pascal  [Select][+][-]

1. program tarrtest;
2.  
3. {$mode objfpc}{$H+}
4.  
5. uses
6.   SysUtils;
7.  
8. type
9.   TTest = record
10.     f: array[0..0] of Byte;
11.   end;
12.  
13.   TTest2 = record
14.     f: array[0..20] of Byte;
15.   end;
16.  
17. var
18.   b: TTest2;
19.   a: TTest absolute b;
20.   p: PByte;
21.   i: SizeInt;
22. begin
23.   try
24.     for i := 0 to 10 do
25.       a.f[i] := i;
26.     p := @a.f[0];
27.     for i := 0 to 10 do
28.       Writeln(p[i]);
29.   except
30.     on e: Exception do
31.       Writeln('Exception (', e.ClassName, '): ', e.Message);
32.   end;
33. end.
34.  

With range checking enabled (-Cr) the access in the first loop will fail, but adjusting it as follows will make it work correctly again:

Code: Pascal  [Select][+][-]

1.     {$push}
2.     {$R-}
3.     for i := 0 to 10 do
4.       a.f[i] := i;
5.     {$pop}

In any case the loop that uses access through the pointer is not affected by the range checking.

[jamie]

I found the problem..

for what ever reason there are two package files that come with that bundle. I open the package files and check the settings. the second package file had all of the debug options on and some other option in there that didn't make any sense why they were on to begin with..

 of course one of them was range checking..

so that part is fine now and the only bug at this point on that package bundle was the initial index setting for the component..

Sorry for wasting your time..

[PascalDragon]

Sorry for wasting your time..

Thank you for checking.