Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

5.9 release thread

kas1e
2014-02-08
2014-05-19
1 2 3 .. 7 > >> (Page 1 of 7)
  • kas1e
    kas1e
    2014-02-08

    @All
    As it seems we lately loose a bit of energy as goals a bit vague, my idea is to make some final attempt to made a 5.9 official release, so we then can concetrate on 5.91, but at least now, we can upload 5.9 release everywhere.

    My idea is all "feature requests" leave for next release and just fixing bugs we have. I for now will sort all the bug reports , so will keep only really necessary for 5.9, and leave not so necessary till next release and so we can concetrate on remaining ones.

    Personally i see that we need to deal with patches removing as #1 problem. And fix bugs : 5,9,10. With 10, it even can be something in os4 (as bszili says it didn't happens on aros), but we need to find what, so i can annoy core-devs to fix it.

    Also in progress of fixing those 4 bugs, i think we need cleanup a bit structures as well about which i told month or two ago (when structures are duplicated in the includes, and in the main programm directory).

    What you all think ?

     
  • xenic
    xenic
    2014-02-13

    @kas1e
    Bug #10 appears to be a bug in the OS4 graphics.library TextFit() function. In the autodocs it states that prior to version 39 the TextFit() function could return one too few characters for proportional fonts. It seems like that bug has returned. Dopus5 gets the menu text width (in pixels) with the TextLength() function and later uses TextFit() to check how many characters it can put in the pixel length returned by TextLength(). TextFit() should return the same number of characters as the number of characters passed to TextLength().

    If we bump the number of characters returned by TextFit(), there could be problems if they fix the TextFit() function. Just to be safe I'm going to bump the popup menu width by one pixel instead. I'll commit a fix for bug #10 later today.

    EDIT: Fix for bug #10 committed (revision 887) and closed.

     
    Last edit: xenic 2014-02-13
  • kas1e
    kas1e
    2014-02-13

    @Xenic

    Bug #10 appears to be a bug in the OS4 graphics.library TextFit() function

    Thanks ! Reported with all the info to os4 devs.

    EDIT: Fix for bug #10 committed (revision 887) and closed.

    Cool!

     
  • kas1e
    kas1e
    2014-02-14

    @Xenic
    I have talked in os4beta list with SBA, and that what he says (copy+paste from his agreement):

    ===========================

    ----SBA:
    That is unlikely a bug in the graphics.library.

    TextLength() gives the advance of the cursor while TextFit() tries to fit the text in the given extent without that any pixel would be rendered outside that extent. This is the same for fixed width fonts, but often not the same for proportional fonts (kerning). Depending on what one tries to accomplished, TextExtent() can be used instead of TextLength() as the former gives more information.

    ---ME:
    Then question is: why the same code works for os3, mos and aros, but give such visual glitch for os4 only ?

    ---SBA:
    It depends on the properties of the used font and especially how the font is rendered.

    To see if there could be really a bug in graphics.library, use TextExtent() and look if the extent differs from the cursor advance. Basically, TextFit() is the "inverse" of TextExtent() and not TextLength().

    ---ME:
    It is topaz:8 in tests (on all other oses too).

    ---SBA:
    For topaz 8, it should be the same as no kerning is involved. I suggest to write a small snippet demonstrating the problem.

    ========================

    In other words, maybe you can make a small test-case which show the problem, so i can just make a BZ for it with attaching test-case, and they can fix it fast ?

     
    Last edit: kas1e 2014-02-14
  • xenic
    xenic
    2014-02-14

    @kas1e
    Forget reporting a bug. I wrote a test case and it works correctly. I don't know why it doesn't work correctly in Dopus5, but it may be due to a miscalculation in the menu padding that leaves room for sub-menu bullets. The fix I applied seems to work so let's just forget about it.

     
  • BSzili
    BSzili
    2014-02-25

    I'd say the clean removal of the patches is no longer a pressing issue. Since AddAppIcon has been fixed, I'm not aware of any side effects of not being able to expunge dopus5.library from the memory. Instead of refactoring the WB_Remove_Patch function, I'd prefer to spend my time with fixing issues, which actually affect the usability from the user's perspective. One of these is the lack of 4G+ support for volume sizes. I've already come up with two different ways to add 64-bit math support. I'll soon open a new thread to discuss which one would you prefer.

     
  • kas1e
    kas1e
    2014-02-27

    @BSZili

    I'd say the clean removal of the patches is no longer a pressing issue. Since AddAppIcon has been fixed, I'm not aware of any side effects of not being able to expunge dopus5.library from the memory.

    Problem with removing of patches is not only removing of patches, but also some additional code which left in, without doing which i had to comment out closing of dos iface. Once i manually add all that removing of patches (i.e. hardcore call , without checking on open counts), it then no crashes when i uncomment closing of dos iface. We that problem need to deal 100%, as it still stays commented as in other way it will crashes always on os4 for second run.

    I'd prefer to spend my time with fixing issues, which actually affect the usability from the user's perspective. One of these is the lack of 4G+ support for volume sizes. I've already come up with two different ways to add 64-bit math support. I'll soon open a new thread to discuss which one would you prefer.

    That all may take forever. Our original plan when we start all that stuff with dopus5 was:

    5.90 : pure port to gcc
    5.91 : bug fixing
    5.9x : only then new feature requests

    Now we even bypass any plan, and that what we should't do, as in end we will ends with all that usual "whole project is always work in progress without any dates". Sure, feel free to work on new features , but we need to release something as i start to loosing faith a bit and want to make one single proper release, until project will go to all that feature requests which can make a lot of time.

    Of course, not many amiga coders want to heard about any data, or heard from anyone what to do and when, but we still should have plan (and that one, we do together at begining, me , xenic, jens and others).

    You of course feel free to add that 4gb+ stuff, its anyway need it soon or later, but i prefer to follow plan, as it show what to do , and when release come.

    @Xenic
    Are you still alive ?:) Maybe you can deal with those #5 and #9 bugs ?

     
    Last edit: kas1e 2014-02-27
  • BSzili
    BSzili
    2014-02-27

    Forever? Hehe, thanks for putting so much faith in me! :) I don't really consider this a new feature, unlike the 64-bit DOS support for files larger than 2GB. Having bogus sizes for every volume except RAM is a bit annoying, especially because I can't tell how much free space I have without bringing up the shell. I have no problem with assigning this to 5.91 if you don't want to delay the first release, but I might finish it before it gets finalized.

     
  • kas1e
    kas1e
    2014-02-27

    @BSzili
    Sure if you can make it fast it can be only good. go ahead :)

     
  • BSzili
    BSzili
    2014-02-27

    @kas1e
    Using static inlined functions or macros I could probably hack it together in a matter of a few hours, since all the code is ready to make it happen. A user at amiga.org have done it already, but I didn't get any response from him. He also used SendRawDisk, so I'm going to do the same to save time. I'd still like to add these function to dopus5.library, so the modules can do 64-bit math too, without duplicating code. The only catch is that the library headers/glue code has to be re-generated after I add the new functions.

     
  • kas1e
    kas1e
    2014-03-01

    @BSzili
    Found that thread on a.org about which you told, and see that Olaf responce as well about, so if we will have any questions i have changed few mails between him lately, so can ask questions if need it directly. Dit that man from a.org answer you btw ?

    @Xenic
    Related to our bug about missing "R" character at end, that what Thore says when i ask about that problem:

    This is my replacement function for graphics/TextFit() I implemented for MUI, because I ran into the very same problem. It could have happened that even single characters were not displayed, because graphics/TextFit() internally calculated a horizontal space which was one pixel too narrow for i.e. a "V". 
    
    I also checked the AROS implementation of graphics/TextFit() and there the following approach is used, which seems to be a better choice from my point of view:
    
    static ULONG textFit(struct RastPort *rp, CONST_STRPTR string, ULONG strLen, struct TextExtent *ex, 
    LONG maxWidth, LONG maxHeight)
    {
       // TextFit() doesn't seem to return the correct result for certain strings
       // for example a single "V" of DejaVu Sans, size 14, maximum width 8
       // - TextExtent calculates a width of 7
       // - TextFit calculates zero fitting characters, although the pixel size is smaller
       // than the maximum width
       // this how TextFit() got called before:
       // struct TextExtent ex;
       // return TextFit(rp, (STRPTR)string, strLen, &ex, NULL, 1L, maxWidth, maxHeight);
       while(strLen > 0)
       {
         TextExtent(rp, string, strLen, ex);
    
         if(ex->te_Height > maxHeight)
         {
           // the height doesn't fit, display nothing
           strLen = 0;
           break;
         }
    
         if(ex->te_Width <= maxWidth)
         {
           // at least "strLen" characters are fitting, that's ok
           break;
         }
    
         // omit one more character
         strLen--;
       }
    
       return strLen;
    }
    

    So, there is still bug in os4's TextFit imho, and it is reported already. But, in meanwhile, and to avoid any problems we imho can make textFit_dopus() and use it in whole dopus.

     
  • BSzili
    BSzili
    2014-03-01

    @kas1e
    As I've said, he never replied to my PM. It doesn't really matter, I've already noted all the places which need to be changed. I'll hack together a proof of concept version after I'm done with the patches

     
  • xenic
    xenic
    2014-03-01

    @kas1e

    Are you still alive ?:) Maybe you can deal with those #5 and #9 bugs ?

    I'm still alive but am tired of Dopus5 after working on it for over a year. I'm looking at bug #9 and I'll let you know if I find a solution.

    So, there is still bug in os4's TextFit imho, and it is reported already. But, in meanwhile, and to avoid any problems we imho can make textFit_dopus() and use it in whole dopus.

    Since I couldn't reproduce the bug in a test program, I fixed that specific bug in the popup menus by increasing the menu pixel width by one pixel. If you want to replace graphics library TextFit() with an internal Dopus5 textfit() function, it won't be affected by my bug fix. You can leave my fix as it is and add your replacement function. However, TextFit() is used in 19 Dopus5 source files and I'd rather try to fix other bugs instead of refixing existing fixes that work. You or BSzili can add the replacement function if you want; it doesn't matter to me.

     
  • xenic
    xenic
    2014-03-01

    @BSzili
    The #9 bug originates in dopus.library IFFOpen(). I can't imagine why they needed to use DOS packets to rename a file but your AROS fix also works for OS4 and should work for all platforms. I only have one question: Why does your fix only apply if the DOS library version is less than 50? Why is this line needed?:

    if (((struct Library *)DOSBase)->lib_Version<50)

    I need to know if that line is needed before I fix the #9 bug for other platforms.

     
  • BSzili
    BSzili
    2014-03-01

    @xenic
    I added the lib version check, because older versions of AROS dos.library didn't have DOS packet support at all. I have no clue why they used DOS packets at certain places, and normal dos.library functions at other ones. You can ifdef out the library version check on OS4 if it fixes the bug.

     
    Last edit: BSzili 2014-03-01
  • xenic
    xenic
    2014-03-02

    @BSzili
    Since that bug was listed for MOS too, I just eliminated the idef's for the renaming/restoring code and used your replacement function that used DOS Rename() for all platforms and versions. I tested it with OS4/OS3 binaries and it works. Unless you have objections, I will commit dopus5.library iff.c with the packet stuff removed.

     
  • BSzili
    BSzili
    2014-03-02

    @xenic
    Sure, replace it. I'd say they only used dos packets out of convenience, so they don't have to expand the parent lock with NameFromLock.

     
  • xenic
    xenic
    2014-03-03

    @BSzili
    I committed the fix for bug #9 (FTP site file writing failure). If you can comfirm that there is no negative impact on the AROS binary, I will close that bug report.

     
  • xenic
    xenic
    2014-03-03

    @kas1e
    Assuming no problems in AROS, the fix I just committed takes care of bug #9. That leaves bug #5, which I will investigate when I have time later this week.

     
  • kas1e
    kas1e
    2014-03-03

    @Xenic
    Thanks a bunch, will test it tomorrow as well.

     
  • xenic
    xenic
    2014-03-03

    @kas1e
    I just tested for bug #5 by connecting to Aminet and using the "parent" command. It works with no crash. Could you retest that bug to be sure it wasn't "accidently" fixed since you first reported it?

     
  • kas1e
    kas1e
    2014-03-03

    @Xenic
    Will try tomorrow of course, but imho that bug can be catched only via debug kernel with enabled munge option, as 0xCCCCCCCC in the DAR register point on exactly that. I just didn't note about in the report, but will update it tomorrow if that still here and happens only with debugkernel/munge

     
  • kas1e
    kas1e
    2014-03-04

    @Xenic
    Retested: bug still here. And you need to be on debug.kernel + munge to catch that one.

    Checked fix for ftp config writing: it works, yeah ! :) Less and less to release

     
    Last edit: kas1e 2014-03-04
  • xenic
    xenic
    2014-03-04

    @kas1e

    Retested: bug still here. And you need to be on debug.kernel + munge to catch that one.

    Sorry, but there is conflicting information between the Serial Debugging Guide at OS4 Coding and the CFE manual for my X1000. Besides, I'm not going to risk an expensive computer by messing with my CFE settings. Someone else will need to trace bug #5 and fix it if changing my CFE is required just to see the bug.

    Less and less to release

    Except that attempting to make patch removal work has introduced other problems. BSzili says that the OS3 binary works for him so I need to update my local copy from the repository and compile the OS3 binary again to see if it works.

     
  • BSzili
    BSzili
    2014-03-04

    @xenic
    I know the patch removal has become the new scapegoat, but I haven't modified the installation of the patches at all, so it is very unlikely that it would affect the startup process.

     
1 2 3 .. 7 > >> (Page 1 of 7)