Click Here
home features news forums classifieds faqs links search
5704 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Channel: #Amigaworld
Channel Policy and Guidelines

(Uses JAVA Applet and Port 1024)
Visit the Chatroom Website

Who's Online
 47 guest(s) on-line.
 3 member(s) on-line.


 amisteph,  thellier,  Signal

You are an anonymous user.
Register Now!
 amisteph:  10 secs ago
 thellier:  26 secs ago
 Signal:  2 mins ago
 Jasper:  12 mins ago
 Trixie:  25 mins ago
 wawa:  25 mins ago
 outrun1978:  28 mins ago
 thomas:  32 mins ago
 IRTheBorg:  44 mins ago
 tonyw:  44 mins ago

/  Forum Index
   /  Amiga OS4 Software
      /  Bleeping bleep developers!
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 )
PosterThread
Hypex 
Re: Bleeping bleep developers!
Posted on 2-Dec-2017 14:42:50
#61 ]
Elite Member
Joined: 6-May-2007
Posts: 9018
From: Greensborough, Australia

@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.

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: Bleeping bleep developers!
Posted on 2-Dec-2017 15:24:52
#62 ]
Elite Member
Joined: 9-Jun-2004
Posts: 10799
From: Norway

@Hypex

Quote:
And also things like tag lists


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

_________________
Please check out my software:
Excalibur, Basilisk 2, AmigaInputAnywhere.
LiveForIt-Music
http://lifeofliveforit.blogspot.no/

 Status: Offline
Profile     Report this post  
Hypex 
Re: Bleeping bleep developers!
Posted on 3-Dec-2017 13:19:51
#63 ]
Elite Member
Joined: 6-May-2007
Posts: 9018
From: Greensborough, Australia

@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.

 Status: Offline
Profile     Report this post  
MickJT 
Re: Bleeping bleep developers!
Posted on 3-Dec-2017 16:04:18
#64 ]
Cult Member
Joined: 13-Jan-2005
Posts: 523
From: Adelaide, South Australia

@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.

 Status: Offline
Profile     Report this post  
megol 
Re: Bleeping bleep developers!
Posted on 3-Dec-2017 17:56:38
#65 ]
Regular Member
Joined: 17-Mar-2008
Posts: 209
From: Unknown

@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.

 Status: Offline
Profile     Report this post  
Raziel 
Re: Bleeping bleep developers!
Posted on 3-Dec-2017 19:03:23
#66 ]
Elite Member
Joined: 17-Apr-2004
Posts: 2461
From: A haunted Castle somewhere in the Bavarian Mountains

@MickJT

broadblues answered in another forum.

_________________
If slaughterhouses had glass walls, everyone would be a vegetarian. ~ Sir Paul McCartney
-
Did everything just taste purple for a second? ~ Philip J. Fry
-
Ain't got no cash, ain't got no style, ladies vomit when I smile. ~ Dr. John Zoidberg

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: Bleeping bleep developers!
Posted on 3-Dec-2017 20:55:16
#67 ]
Elite Member
Joined: 9-Jun-2004
Posts: 10799
From: Norway

@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.

_________________
Please check out my software:
Excalibur, Basilisk 2, AmigaInputAnywhere.
LiveForIt-Music
http://lifeofliveforit.blogspot.no/

 Status: Offline
Profile     Report this post  
Hans 
Re: Bleeping bleep developers!
Posted on 4-Dec-2017 1:02:10
#68 ]
Elite Member
Joined: 27-Dec-2003
Posts: 4856
From: New Zealand

@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.

 Status: Offline
Profile     Report this post  
Hans 
Re: Bleeping bleep developers!
Posted on 5-Dec-2017 3:37:33
#69 ]
Elite Member
Joined: 27-Dec-2003
Posts: 4856
From: New Zealand

@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.

 Status: Offline
Profile     Report this post  
Daedalus 
Re: Bleeping bleep developers!
Posted on 7-Dec-2017 16:05:51
#70 ]
Super Member
Joined: 14-Jul-2003
Posts: 1634
From: Glasgow - UK, Irish born

@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

 Status: Offline
Profile     Report this post  
megol 
Re: Bleeping bleep developers!
Posted on 8-Dec-2017 19:33:26
#71 ]
Regular Member
Joined: 17-Mar-2008
Posts: 209
From: Unknown

@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.

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: Bleeping bleep developers!
Posted on 9-Dec-2017 18:28:55
#72 ]
Elite Member
Joined: 9-Jun-2004
Posts: 10799
From: Norway

@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.

_________________
Please check out my software:
Excalibur, Basilisk 2, AmigaInputAnywhere.
LiveForIt-Music
http://lifeofliveforit.blogspot.no/

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: Bleeping bleep developers!
Posted on 9-Dec-2017 18:34:32
#73 ]
Elite Member
Joined: 9-Jun-2004
Posts: 10799
From: Norway

@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.

_________________
Please check out my software:
Excalibur, Basilisk 2, AmigaInputAnywhere.
LiveForIt-Music
http://lifeofliveforit.blogspot.no/

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright © 2000 - 2017 Amigaworld.net.

Amigaworld.net was originally founded by David Doyle