@NutsAboutAmiga

For a WIP library yes there can be lots of changes. But for a published library this shouldn't be an issue where the API should be set in stone.

Of course a major API change between versions would introduce redundant code for backwards compatibility. But it does help to design it so it can be upwards compatible in a clean room type of manner.

And also things like tag lists and private structures should be used to seperate the API from the internals as much as possible. This way major changes can be made internally while on the surface things can remain the same. As well as the usual adding of functions which is the main Amiga way of making major changes.

Last edited by Hypex on 02-Dec-2017 at 02:44 PM.

@Hypex

Quote:

And also things like tag lists

Var args and tag list, you need to process the list loop, that’s not efficient.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

Var args and tag list, you need to process the list loop, that's not efficient.

You do need to process it but in OS2.0 this became the standard for passing parameters to functions. In reality functions that only needed a few parameters work fine or can be replaced by a new one that takes more. But tag lists replaced things like static structures so that a dynamic array of parameters could be passed to the function. As many or as few as needed. If a new parameter was introduced or an old one made redundant all that was needed was a change in function code and the exposed API stayed the same.

@Raziel

Quote:

That, and gcc 5.x not supporting SOBJS builds (right now), made me switch back to static.

It should, but if it's written in C++11 or later, then you'll have to bundle libstdc++.so (and possibly libgcc.so). If you build a program then try to run it straight away, it's going to load the one from SOBJS: and crash the program. I don't know if the old one can be overwritten and maintain compatibility with old software that uses it.

If it's possible to avoid sobjs, then do so. By the way I noticed no-one has mentioned "ListDynDep" which will list the .so files a program needs.

Last edited by MickJT on 03-Dec-2017 at 04:06 PM.
Last edited by MickJT on 03-Dec-2017 at 04:06 PM.

@NutsAboutAmiga

Not in critical loops perhaps but for initializing things etc. the overheads are minor.

On a modern system a call is often translated in several layers anyway and I wonder if the efficiency would be worse with tag lists+ proper design.

@MickJT

broadblues answered in another forum.

@megol

slow * 1000 = extremely slow.

If you have loops and using functions that are not optimized the result is horrible, by paying attention bad code, programs run a lot better.

Quote:

a call is often translated in several layers anyway

this kind of programs are often not, speed critical.

VB front end, hardly notifiable compared to assembler one. but the database back end has to be really optimized.

Last edited by NutsAboutAmiga on 03-Dec-2017 at 09:00 PM.
Last edited by NutsAboutAmiga on 03-Dec-2017 at 08:59 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Daedalus

Only just spotted your reply...

Quote:

Daedalus wrote: @Hans Quote: However, really is pretty outdated. Have you looked at updating to the new OS4 installer system? It's much more capable. AFAIK, it is now documented. I did look at it a while back, but the documentation was nonexistent. InstallerGen is written in a pretty Commodore-Installer-centric way, so I think support for the OS4 installer would be easier to implement from scratch. But can the OS4 installer deal with the mess that is the .so system intelligently? I can't really see how that would be doable without complete package management (and even then it's dubious), since different versions are not always backward- or forward-compatible, and without a registry (ugh) it's impossible to tell which applications actually need which installed files.

Leave handling .so dependencies to the developers that decide to use them.

Being able to easily create installers using the modern OS4 installer system would be great. The installers look much nicer, and the installation system is more versatile.

BTW, the issue of *.so's not being backward compatible isn't the *.so system's fault, or even a property of shared objects. We could easily cause a similar mess with *.librarys, but we don't because we follow the rule that publicly released APIs must be backward compatible.**

@all

Regarding package managers, as a developer I'd rather my software can be installed without relying on a third-party tool & database (neither of which are under my control). This is especially true for any software that people have to pay for. Users should be able to buy, download, & install without needing an extra tool to get the dependencies.

Package managers are nice (I do like the ones on Linux), but you're really just deferring the issue of dependencies to a third-party. Someone still has to figure out the dependencies and make sure they're installed. When you release software then that someone is you (or your team, or whoever you outsource it to).

What might be useful is if installers could use the AmiUpdate to automatically pull in and install dependencies. However, I'd still prefer the installer to work without being dependent on a third-party tool or database.

Hans


** On AmigaOS 4 it is possible to create a new API that's not backward compatible by having a new interface version. However, IExec->GetInterface() not only makes it impossible for old software to accidentally use the incompatible interface, but the old v1 interface can be included for backward compatibility.

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Daedalus

I just found the wiki page with some documentation for the new OS4 installation utility. Hope that helps.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans

Quote:

Hans wrote: BTW, the issue of *.so's not being backward compatible isn't the *.so system's fault, or even a property of shared objects. We could easily cause a similar mess with *.librarys, but we don't because we follow the rule that publicly released APIs must be backward compatible.**

Yeah, I know, but it's about the only system component that has this issue, which is why I associate it. The underlying issues to deal with are, as I see them:

- Not enforcing backwards compatibility as you pointed out (and yep, I know the interfaces system allows different levels of backward compatibility in one library, but .so files don't use them either.

- Not containing version strings, which makes telling them apart or even knowing anything about their contents impossible without trying them to see if something breaks.

Both of these combine to make things uncomfortable from an installation perspective, unless you do as some suggest and keep them application-specific.

Quote:

I just found the wiki page with some documentation for the new OS4 installation utility. Hope that helps.

Cheers, I'll give it a look at some stage

_________________
RobTheNerd.com | InstallerGen | SMBMounter | Atoms-X

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @megol slow * 1000 = extremely slow. If you have loops and using functions that are not optimized the result is horrible, by paying attention bad code, programs run a lot better.

So don't use taglists in the inner loop? They are mostly used for initialization which shouldn't be in a critical loop.

But that wouldn't matter in most cases anyway, a taglist with 10 entries will take at most 10 "loops" to read. Most lists are shorter.

O(n) isn't considered slow by most people.

Quote:

Quote: a call is often translated in several layers anyway this kind of programs are often not, speed critical. VB front end, hardly notifiable compared to assembler one. but the database back end has to be really optimized.

Even critical things have many layers. Modularity, object orientation and libraries that depend on libraries that depends on libraries are the reasons.

@megol

some times people unroll loops to make things faster, that that only works know how many loops you have.

the lower layers are what is impotent to optimize yes, the primitives that is used the most.

imagine slow pixel plot routine used to draw a rectangle.

that you factor of.

slow * x *y = major slow down.

Did this mistake once, assuming can do all conversion of the RGB/ARGB/BGRA/16bit PC RGB, 16bit PPC RGB, and on stuff in pixel routine.

taking the time to evaluate what is slow or not help, making better programs, I often time part of my code, to see what is slow, things are not always obvious.

optimizing code is maybe more interesting aseptic of coding, if don't count debuging your own code to find the missing ";" that is... just joking.

Last edited by NutsAboutAmiga on 09-Dec-2017 at 06:30 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@megol

What might not thanked about is you might have program that works fine, but your code is running on Multitasking operating system where time is divided by the programs.

the issue here is if your program suck, peek loads the CPU, (runs at 100% for short period of time) this can result in under buffering or jitters in audio playback.

Yes audio stuff should be running higher priority so should happen, but if audio stuff run too higher pri, it mess with drivers that run low priority, and mess up USB and disk loading, so this not so easy.

Last edited by NutsAboutAmiga on 09-Dec-2017 at 08:16 PM.
Last edited by NutsAboutAmiga on 09-Dec-2017 at 06:35 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS