Amiga.org

Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: guest11527 on July 07, 2014, 01:43:07 AM

Title: Layers.library V45 on the aminet
Post by: guest11527 on July 07, 2014, 01:43:07 AM
With the kind permission from Hyperion, I recently uploaded the V45 version of layers.library to aminet.

Layers.library is responsible for the "slice & dice" operations required for window re-arrangements, computes cliprects, damage regions and provides the backing-store for "smart-refresh windows".  

Layers (up to v40, Os 3.1) was considerably ill-designed for rtg (regargetable graphics, graphics cards) and thus was heavily patched to avoid performance degrations.

The V45 release is an old code that collected dust here on my harddisk which was created as input for Os 4 - and in fact, is the Os 4 version is based on the V45 release.

Besides a major cleanup of the Os 3.1 version of layers (v40), the optimizations for graphic cards and the improvements in memory management, this release also provides new functionalities to hide and show layers, for example to allow window iconification with little or no extra efford from software. The uploaded archive contains a "tech demo" (amisnip) that demonstrates the functionality. Note that Amisnip is a technology demo, not a "good program". Sources are included to inspire authors.

V45 layers also includes support to automatically clip layers at layer_info boundaries, another new functionality. With a proper modification of intuition (which is of course not available), this would allow to easily drag out windows from the screen - something that was not possible before either. There is another technology demo in the archive that shows how to enable the feature (without enabling the drag-out of windows, which is as said something to be done in intuition).

Note well: This is all for classic Amigas. Os 4 has the features anyhow, and (partially) by the same author, and is based on the same code basis. Thus, you loose nothing with Os 4 - you already have it.
Title: Re: Layers.library V45 on the aminet
Post by: F1Lupo on July 07, 2014, 01:50:38 AM
Thank you Thomas for this timely release as I'm just getting ready to set up my first RTG Amiga system in the upcoming weeks :-)
Title: Re: Layers.library V45 on the aminet
Post by: nyteschayde on July 07, 2014, 07:23:55 AM
I am often very impressed by the folks in the Amiga community. Many that remain are incredibly talented software and hardware engineers who are jaded and scorned over something that in a modern day of open source seems trivial but nonetheless their talents and in depth knowledge are the things keeping the platform in a slow but steady state of progress.

To you Thomas, I say thanks. If you are also familiar with making web pages, I say preach and teach your knowledge to others and give as much as you can when/if you find yourself drifting from the community so that it is not lost and can be used by you and others when you return.
Title: Re: Layers.library V45 on the aminet
Post by: Georg on July 07, 2014, 08:13:32 AM
Quote from: Thomas Richter;768383

V45 layers also includes support to automatically clip layers at layer_info boundaries, another new functionality. With a proper modification of intuition (which is of course not available), this would allow to easily drag out windows from the screen - something that was not possible before either. There is another technology demo in the archive that shows how to enable the feature (without enabling the drag-out of windows, which is as said something to be done in intuition).


There is an (evil?) hack on Aminet called PowerWindowsNG (source code: PowerWinNG_Src) which allows dragging out windows from the screen. It includes a BlizKick module to disable some Intuition checks in ROM which usually block window dragging to area outside screen. The checks are disabled if bit 7 of LayerInfo flags is set (used by hack to indicate that screen/layerinfo allows out of screen windows).

You could use this or similiar with the V45 layers.

(The way the hack worked, was to put huge nobackfill layers around the screen and then patch things in layers in such a way that this special layers are alway in front of all normal layers. This way when a normal layer gets moved out of screen it ends up behind the special layers and the library handles damage/refresh/backing correctly all by itself without modification.)
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on July 07, 2014, 08:50:34 AM
Quote from: Georg;768418
You could use this or similiar with the V45 layers.
 Well, V45 has all this functionality built-in, there is no "bit" for that, but instead a new "layer-info" based clipping region layers are optionally clipped to.   Everything outside this region goes into the damage region or the backing-store. It's transparently handled in V45, transparent to the program using intuition. But, as said, no bit, but a rectangle. Demo is included in the archive.  Problem is - as said - intuition. Intuition would a) need to setup the correct layer_info clipping, and b) enable dragging windows out of the screen.  As said, this is all done in 4.0 and above, no black magic. (Except the "how to compile intuition" magic since it's not SAS/C.)
Title: Re: Layers.library V45 on the aminet
Post by: amigakit on July 07, 2014, 08:58:21 AM
Thank you for releasing this Thomas
Title: Re: Layers.library V45 on the aminet
Post by: Georg on July 07, 2014, 09:29:15 AM
Quote from: Thomas Richter;768420
Problem is - as said - intuition. Intuition would a) need to setup the correct layer_info clipping, and b) enable dragging windows out of the screen.


As said you can do something similiar to BlizKick module in PowerWindowsNG to do b) and regarding a) you can add an option to the V45 library to install the correct layer_info clipping rect itself (== set it to layerinfo bitmap dimensions, once they are known).
Title: Re: Layers.library V45 on the aminet
Post by: Ancalimon on July 07, 2014, 09:37:10 AM
Is it safe to use with Cybergraphx (CVisionPPC, BVisionPPC) too?
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on July 07, 2014, 09:57:40 AM
Quote from: FaLLeNOnE;768427
Is it safe to use with Cybergraphx (CVisionPPC, BVisionPPC) too?

Yes, please read the readme. You need to use the "LayersAntiHack". Cgfx patches layers, and thus destroys the logic of the new lib, the above patch avoids the patches. (Sick). Works smoother with P96.
Title: Re: Layers.library V45 on the aminet
Post by: Niding on July 07, 2014, 10:02:17 AM
Thanks for the lib update :)
Title: Re: Layers.library V45 on the aminet
Post by: rockape on July 07, 2014, 10:33:04 AM
Hi Thomas,

Many thanks.

Regards, Michael

aka rockape
Title: Re: Layers.library V45 on the aminet
Post by: itix on July 07, 2014, 12:26:50 PM
Quote from: Thomas Richter;768383

Besides a major cleanup of the Os 3.1 version of layers (v40), the optimizations for graphic cards and the improvements in memory management, this release also provides new functionalities to hide and show layers, for example to allow window iconification with little or no extra efford from software.


This is not real iconification. Hiding layer leaves screen locked preventing Workbench theme and screen resolution changes. It is useful to hide layer temporarily without disposing window but to support real iconification it should always use screennotify.library and CloseWindow() on demand.

Real iconification requires quite lot effort but is worth of it. It is quite bad when Workbench is complaining it cant adjust screen and asks user to close all windows but user cant see any.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on July 07, 2014, 03:10:34 PM
Quote from: itix;768448
This is not real iconification. Hiding layer leaves screen locked preventing Workbench theme and screen resolution changes. It is useful to hide layer temporarily without disposing window but to support real iconification it should always use screennotify.library and CloseWindow() on demand.
Which is, of course, quite impossible for applications that have not written with this use in mind. You probably don't understand the vision here: What it requires is an update of intuition and workbench to allow closing the WB screen *with hidden windows* on it. This is "in principle" no problem because the full window content is in the backing store in first place, so it can be re-rendered when necessary. Of course, lots and lots of things would need to be done for that, not saying that I would do that - I wouldn't. Like conversion between bitdepths (and conversion between screen organizations, but that's something rtg implements anyhow). But a first step needs to be taken, and it is practical to have this limited feature in first place.  
Quote from: itix;768448
Real iconification requires quite lot effort but is worth of it. It is quite bad when Workbench is complaining it cant adjust screen and asks user to close all windows but user cant see any.
 Then un-hide the windows in that case as a first step... (-:   It really makes no sense to request from existing programs that have not been designed with this application in mind to iconify themselves. As you say, it is a *lot* of work. ViNCEd, the 3.9 console, can do that. For that, it has its own "backing store" of the editor contents (ViNCEd is an editor), and it can even make shell output, scrolling, and control sequence handling without any type of window attached to it. It delivers screen sizes, cursor positions and everything to every program running in it. You can iconify the Shell with "list" running in it, and restore it later, seing the "list" being done and complete, it does not stop programs for being iconified (unlike the "ape shell" or whatever its name was).  But, remembering how much work this little feature was, just to get everything worked out correctly, I cannot realistically request that from any arbitrary application. It is the wrong way around. The Os needs to ensure that applications can render themselves to their windows, even if the windows are not "phyically attached" to any display. This is precisely the core functionality of what "HideLayer" does. Well, in essence. There are a couple of corner cases that would require a solution, but that's where the development should have gone should I have had more time and a working hardware to get things done back then.  It's all too late now, but you got what you got, and that's better than nothing.
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on July 07, 2014, 06:47:45 PM
on an opportunity to thank thomas for another act of support towards amiga users i just would like to mention that powerwindows is a little patch that adds up a hell of functionality to a system where its probably most outdated and limited in its genuine shape. especially the relatively low res native amiga resolutions benefit from that feature imho, and it is one of yet not so many advantages of aros68k on genuine hardware. it would probably be worth to incorporate it properly into a system some day.

this said, the amount of reworked and improved libraries and patches has become overhelming these days. from my own experience with the maintenace of an improved kickstart in flash i start to wonder about some simple and unified possibility to dependably maintain and update the (remapped) kicksart, that would be easier for those inexperienced users for whom diassembling the rom image, applaying patches from command line or loading modules on startup remains a major showstopper. as example i wonder if a package could be created that automatically assembles and installs such a kickstart reading out the content of the original roms, applaying appropriate patches and properly modifying the startup sequence. i think an boing bag (4?) archive  along with an a little more sofisticated installation script might play that role.
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on July 07, 2014, 07:10:06 PM
@wawrzon

to tell the truth probaby even someone like me might be able to prepare such a package if it doesnt yet exists. the requirement would be likely that doobrey tools could be used for the task ( if they can be run from console instead graphically from workbench) and also that all the components are available with a proper free license.

but this is an offtopic. sorry.
Title: Re: Layers.library V45 on the aminet
Post by: ssolie on July 07, 2014, 07:35:50 PM
Quote from: Thomas Richter;768383
With the kind permission from Hyperion, I recently uploaded the V45 version of layers.library to aminet.

Ah, I see you finally obtained permission. I was beginning to wonder... ;)

@all
Thomas Richter has made many essential contributions both in the Amiga operating system and via 3rd party contributions. I have stumbled upon his excellent work in many OS components while working on the source code. I think all Amiga fans should thank him for his pioneering efforts.

You can see his name and many others listed on the credits page (http://www.amigaos.net/content/11/credits). If you know of any names that are missing then please let us know via the contact page (http://www.amigaos.net/contact).
Title: Re: Layers.library V45 on the aminet
Post by: tolkien on July 07, 2014, 08:45:05 PM
I have tried to use It with LoadModule LIBS:layers.library but when I insert It in my S-S the script stops.
I have other libraries loaded with Loadmodule with no errors. Perhaps I have added a lot of them? cant understand the error but will try this week again.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on July 07, 2014, 11:15:08 PM
Quote from: tolkien;768478
I have tried to use It with LoadModule LIBS:layers.library but when I insert It in my S-S the script stops.

Most likely and most certainly a typo. This is because LoadModule is the suggested (and tested) way of inserting the library. In case of doubt, post your S-S here.  Note again: If you use Cgfx, you *must* use LayersAntiHack in the S-S to prevent it from patching layers. Unnecessary, because everything Cgfx requires to run fast is already in V45, thus no need to do anything there.  If you are using P96, just rename or delete LIBS:Picasso96/fastlayers.library (P96 was implemented in a more forward-looking, future proof way). The fastlayers.library installs patches into layers similar to that of CGfx, and as above, the corresponding code is already part of layers V45. V45 is "rtg.friendly".  For those that want to know: Unlike earlier versions, V45 allocates the layers backing store from graphics card memory if the layer is on an rtg screen - and not from chip memory.   This is not the only modification, but one of the most important ones.  Once again: Os 4 and above already have that code (plus more!), so you won't miss anything there.
Title: Re: Layers.library V45 on the aminet
Post by: Jose on July 07, 2014, 11:50:47 PM
Thanks
Title: Re: Layers.library V45 on the aminet
Post by: stefcep2 on July 08, 2014, 12:01:39 PM
Excuse me, but I have CGX 4 rev 6.  Why should I use this replacement library?
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on July 08, 2014, 01:03:18 PM
Quote from: stefcep2;768500
Excuse me, but I have CGX 4 rev 6.  Why should I use this replacement library?

I don't know why you should. I'm making an offer. Probably you start with the Readme, because it answers a couple of questions what is wrong with V40 layers.

To keep it very short, besides the new functions, it is much more efficient when depth-arringing windows. V40 had an algorithm that scaled like O(n^2) in the number of overlapping windows, V45 is only O(n). Given CPU driven memory copies in some situations on rtg, this makes a noticable difference. V40 also throws fragmentation bombs at the memory system by allocating and releasing many temporary structures. V45 pools them and reuses them.

But, whatever, it's your choice. Read the docs, make up your mind. Probably you find one or another use for the new functions, too - I don't know. As I already said, this is just a left-over from a Os 4 development I completed enough to make it function, but which was extended for Os 4 again. It's a development snapshot.
Title: Re: Layers.library V45 on the aminet
Post by: stefcep2 on July 08, 2014, 01:20:35 PM
@Thomas I don't mean to be not appreciative of your work.  From the thread I didn't know the difference.  In a nutshell V45 should be more memory efficient and faster, with some new functions?
Title: Re: Layers.library V45 on the aminet
Post by: Ancalimon on July 08, 2014, 01:29:20 PM
Quote from: stefcep2;768504
@Thomas I don't mean to be not appreciative of your work.  From the thread I didn't know the difference.  In a nutshell V45 should be more memory efficient and faster, with some new functions?

That's what I understood. Using the new layers.library instead of the old one in the rom with Cybergrphx patch, we can expect less memory fragments and faster performance when windows overlap each other.

Thanks! ;)
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on July 08, 2014, 11:33:09 PM
Quote from: stefcep2;768504
@Thomas I don't mean to be not appreciative of your work.
That's all understood. But as said, it's not the new "bright and shiny toy". It is an update that I should have done earlier, that should probably be more complete, that was completed in 4.0, but that does what it does.  
Quote from: stefcep2;768504
From the thread I didn't know the difference.  In a nutshell V45 should be more memory efficient and faster, with some new functions?

That pretty much sums it up.
Title: Re: Layers.library V45 on the aminet
Post by: Chain|Q on July 09, 2014, 12:28:40 PM
Hi Thomas, thanks for this release.

It works pretty fine on my AGA/060 machine, it's so fast I could even enable solid window moving in 640x512, 64 colors, with many windows! Very nice.

On the other hand I had slightly different results on my RTG machine. Layers v45 seems to break P96 PIP support (as it's even noted in the release history), which sadly is a huge showstopper on my Amiga 2000 with PicassoIV + PalomaTV. Is there a chance to get a fixed PIP support or some workaround for these systems?

I also noticed that it's incompatible with the old border patch tool Birdie, but admittedly, Birdie is a pretty big hack, so that's OK.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on July 09, 2014, 02:28:22 PM
Quote from: Chain|Q;768562
On the other hand I had slightly different results on my RTG machine. Layers v45 seems to break P96 PIP support (as it's even noted in the release history), which sadly is a huge showstopper on my Amiga 2000 with PicassoIV + PalomaTV. Is there a chance to get a fixed PIP support or some workaround for these systems?

That's interesting, I wouldn't have expected this, though I could neither test since I don't have a PIV. The only PIP support from P96 I am aware of is the LayerObscured() functionality, which is part of P96, and which should actually not depend on whether layers is V40 or V45. Thus, this means that a) either I got something wrong for the simple layer applications, or b) because PIP support depends on something else I'm not aware of.

I probably do not have time right now to look into this (I'm right now in Sapporo, Japan). Maybe I have short chance of checking this next weekend, but I will unlikely be able to provide any type of fix before August (*sigh*).   In worst case, it will be a patch to P96 to be V45 aware.  Greetings, Thomas
Title: Re: Layers.library V45 on the aminet
Post by: Chain|Q on July 09, 2014, 04:26:29 PM
Quote from: Thomas Richter;768573
That's interesting, I wouldn't have expected this, though I could neither test since I don't have a PIV. The only PIP support from P96 I am aware of is the LayerObscured() functionality, which is part of P96, and which should actually not depend on whether layers is V40 or V45. Thus, this means that a) either I got something wrong for the simple layer applications, or b) because PIP support depends on something else I'm not aware of.

Thank you for the quick response. The NOTES/Layers_RelNotes file in the Aminet release states this for version 45.2:
Quote
Found that the P96 rtg.library PIP support depends on the fact that obscured simple refresh layers have at least one dummy cliprect with lobs!=NULL. This is no longer the case for V45 and above. A fix for the rtg.library is available separately [Andrea].
I think this is could be related to my problem, since the PIP shows symptoms like disappearing overlay, and/or overlay not taking window coverage into account (the overlay is always on top), which are clearly layers related. I guess the mentioned rtg.library update which fixes this issue never made it back to 68k... (Or I must have missed it.) Of course, everything works fine with layers v40. When trying v45, I removed LIBS:Picasso96/fastlayers.library from my system as instructed in the Readme.

I can send photos/videos of the problem appearing, if you need that. If you have any patches anytime in the future, I'd be happy to test on my system.
Title: Re: Layers.library V45 on the aminet
Post by: matthey on July 09, 2014, 05:15:18 PM
@ChainIQ

Are you using the more recent unofficial P96 libraries?

http://lilliput.amiga-projects.net/Picasso96.htm

These libraries fix some PIP functionality.

@ThoR
Thanks for the release.
Title: Re: Layers.library V45 on the aminet
Post by: Chain|Q on July 09, 2014, 06:25:06 PM
@matthey
Quote from: matthey;768585
Are you using the more recent unofficial P96 libraries? (...) These libraries fix some PIP functionality.
No, I didn't try these, however the archive on that page doesn't upgrade rtg.library, which is said to have the problem. BTW, where does the claim comes from about the PIP functionality fixes? I can't seem to find any kind of changelog for versions above 2.0.

In fact, the rtg.library I have installed is slightly newer than the one included in that archive. (I think it comes from some UAE-related update.) But I'll give it a try, one can never know.
Title: Re: Layers.library V45 on the aminet
Post by: matthey on July 09, 2014, 08:14:38 PM
Quote from: Chain|Q;768592
No, I didn't try these, however the archive on that page doesn't upgrade rtg.library, which is said to have the problem. BTW, where does the claim comes from about the PIP functionality fixes? I can't seem to find any kind of changelog for versions above 2.0.

I am not aware of a changelog. I found the bug fix myself. In the P96Developer.lha (SDK) archive in the examples directory, there is a program called OpenPIP which failed to open. After installing Gulliver's newer P96 libraries, it works for me. The problem was probably in the Picasso96API.library p96PIP_OpenTags() function but I did not investigate the problem further. It's been awhile too.

Quote from: Chain|Q;768592
In fact, the rtg.library I have installed is slightly newer than the one included in that archive. (I think it comes from some UAE-related update.) But I'll give it a try, one can never know.

Does the rtg.library have the same version number (40.3994) but a newer date? If so, I disassembled a version with a newer date and could see that it was patched (Christian Sauer's patch?) in a way that didn't impress me. It looked like a 3rd party patch job. I didn't figure out what the patch was trying to accomplish but Gulliver and I decided it was better to use the earlier dated (but same version) unmolested version if it didn't cause problems for anyone. You can ask Gulliver if there have been any problems since then. You could probably find the discussions on the amiga.org and/or the EAB forums if you search.

http://eab.abime.net/showthread.php?t=50410
http://aminet.net/driver/video/RTG403994p.readme

I couldn't find the the thread where I talked about disassembling the different rtg.library versions. I don't recall having problems with either of the new 40.3994 versions.
Title: Re: Layers.library V45 on the aminet
Post by: utri007 on July 09, 2014, 09:09:03 PM
This is interesteing, but I have some questions. Solid Windows movin is possible with FBlit and it is over all big performance boost. So I wondering what will happen with FBlit? Will it work hapily with it?
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on July 09, 2014, 11:16:55 PM
Quote from: utri007;768597
This is interesteing, but I have some questions. Solid Windows movin is possible with FBlit and it is over all big performance boost. So I wondering what will happen with FBlit? Will it work hapily with it?

I can't give you an answer because I don't use FBlit. All I can tell is that it hooks into the system at a completely different spot, and if the semantics of the Os interface does not change, I see no reason why it should not work.
Title: Re: Layers.library V45 on the aminet
Post by: utri007 on July 10, 2014, 08:33:45 AM
I hope it works :) Need to test when I get to home. FBlit is one of saddest stories of Amiga land, it is  amazing it makes big diffrence with Workbench and many programs and games.
Title: Re: Layers.library V45 on the aminet
Post by: Chain|Q on July 10, 2014, 10:47:38 AM
Quote from: utri007;768620
I hope it works :) Need to test when I get to home.
Just for the record, I run FBlit on my AGA machine, and I experienced no problems so far with v45 layers there.
Title: Re: Layers.library V45 on the aminet
Post by: itix on July 10, 2014, 03:49:10 PM
Quote from: Thomas Richter;768460
Which is, of course, quite impossible for applications that have not written with this use in mind.


It is not impossible. It takes some effort and no effort at all if you use some high level frame work. Using low level Intuition calls is deprecated anyway... nobody should be using Intuition window calls directly in this century.

Quote
You probably don't understand the vision here: What it requires is an update of intuition and workbench to allow closing the WB screen *with hidden windows* on it. This is "in principle" no problem because the full window content is in the backing store in first place, so it can be re-rendered when necessary. Of course, lots and lots of things would need to be done for that, not saying that I would do that - I wouldn't. Like conversion between bitdepths (and conversion between screen organizations, but that's something rtg implements anyhow). But a first step needs to be taken, and it is practical to have this limited feature in first place.    Then un-hide the windows in that case as a first step... (-:


No I dont understand this functionality that encourages developers to not develop properly functioning software. It is bad design.

Nobody is going to update Intuition. Not you, not anyone else.

Quote
It really makes no sense to request from existing programs that have not been designed with this application in mind to iconify themselves. As you say, it is a *lot* of work. ViNCEd, the 3.9 console, can do that. For that, it has its own "backing store" of the editor contents (ViNCEd is an editor), and it can even make shell output, scrolling, and control sequence handling without any type of window attached to it. It delivers screen sizes, cursor positions and everything to every program running in it. You can iconify the Shell with "list" running in it, and restore it later, seing the "list" being done and complete, it does not stop programs for being iconified (unlike the "ape shell" or whatever its name was).


That is not much. Pretty common in every Amiga shell I have seen in this century.

Quote
But, remembering how much work this little feature was, just to get everything worked out correctly, I cannot realistically request that from any arbitrary application. It is the wrong way around. The Os needs to ensure that applications can render themselves to their windows, even if the windows are not "phyically attached" to any display. This is precisely the core functionality of what "HideLayer" does. Well, in essence. There are a couple of corner cases that would require a solution, but that's where the development should have gone should I have had more time and a working hardware to get things done back then.  It's all too late now, but you got what you got, and that's better than nothing.


Trivial.
Title: Re: Layers.library V45 on the aminet
Post by: itix on July 10, 2014, 03:54:40 PM
Quote from: Thomas Richter;768502
I don't know why you should. I'm making an offer. Probably you start with the Readme, because it answers a couple of questions what is wrong with V40 layers.

To keep it very short, besides the new functions, it is much more efficient when depth-arringing windows. V40 had an algorithm that scaled like O(n^2) in the number of overlapping windows, V45 is only O(n). Given CPU driven memory copies in some situations on rtg, this makes a noticable difference.


That should give huge boost. Even on some vanilla A1200 if you had ten overlapping windows it was already crawling.

Btw is there still noticeable speed penalty when rendering to non-overlapped window that is not the top most one? That was another issue with the original layer code...
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on July 10, 2014, 11:41:17 PM
Quote from: itix;768644
It is not impossible. It takes some effort and no effort at all if you use some high level frame work.
Apparently, you want to troll. Ok, you want it, you get it: Tell me how you can iconify a window of a program you don't have the sources for. There is no "framework" for this. There is only the binary. Actually, most Amiga programs are like that.  
Quote from: itix;768644
 Using low level Intuition calls is deprecated anyway... nobody should be using Intuition window calls directly in this century.
Just in case you did not notice: Nobody uses the Amiga in this century anyhow. Nobody writes new programs in this century anyhow. The majority of programs available for Amiga uses intuition and not a fancy framework. Which of the dozends of incompatible frameworks should I pick today, given that none of them is an integrated part of the Os?  
Quote from: itix;768644
No I dont understand this functionality that encourages developers to not develop properly functioning software. It is bad design.
There are no encouraged developers left - just to remind you. Nobody will rewrite old software. And no, it is not bad design. It keeps the existing functions working in a completely solid way, using the existing functionalities, even in a pretty trivial way.  
Quote from: itix;768644
Nobody is going to update Intuition. Not you, not anyone else.
Wisely said. But whose going to update the old programs then, to use the new fancy frameworks? Oh, right, nobody. In other words, you can have a partial functionality now, completing AmiSnip which is part of the archive, or you can never have anything. Make your pick. My offer stands.  
Quote from: itix;768644
That is not much. Pretty common in every Amiga shell I have seen in this century.
Nothing left in this century. The old broken ape-stuff I know was working on a blank console, and if that console went away, output was not possible.  
Quote from: itix;768644
Trivial.

If things are so trivial, I suggest you start rewriting the old applications using the new fancy frameworks. I wish you luck getting sources and redesigning software made over the last years.
Title: Re: Layers.library V45 on the aminet
Post by: itix on July 11, 2014, 08:36:35 AM
Quote from: Thomas Richter;768666
Apparently, you want to troll. Ok, you want it, you get it: Tell me how you can iconify a window of a program you don't have the sources for. There is no "framework" for this. There is only the binary. Actually, most Amiga programs are like that.

Of course those programs cant be fixed. I guess AmiSnip is some kind of commodity that can hide windows and inserts them to tools menu? It is perfectly OK. Applications having built-in faked iconify with HideLayers() is not. I just wouldnt want see anyone using it on new code.

Quote
Just in case you did not notice: Nobody uses the Amiga in this century anyhow. Nobody writes new programs in this century anyhow. The majority of programs available for Amiga uses intuition and not a fancy framework. Which of the dozends of incompatible frameworks should I pick today, given that none of them is an integrated part of the Os?    There are no encouraged developers left - just to remind you. Nobody will rewrite old software.

I dont know any incompatible frameworks.

Some frameworks do better than others but no any developer should be encouraged to use low level Intuition anymore. It is rude environment and crash prone if you make even small mistake. It was good in 80s but not anymore.

Quote
And no, it is not bad design. It keeps the existing functions working in a completely solid way, using the existing functionalities, even in a pretty trivial way.    Wisely said.

I have got enough with software that cant go away when I am adjusting Workbench screen. It is annoying especially if there is no visual clue which programs are preventing that.

Quote
If things are so trivial, I suggest you start rewriting the old applications using the new fancy frameworks. I wish you luck getting sources and redesigning software made over the last years.

I have done that couple of times. SnoopDos, Frodo and some text adventure game I cant remember right now. It takes some effort but can be worth of it as in result you can throw away old mumbo jumbo. Basically that is all low level stuff to manage windows, IDCMP ports, gadget definitions and many more I cant remember anymore. They take lot space in code yet there is only very rudimentary UI layout that is neither user or developer friendly.

Agreed we dont have developers left. If we had many old software could be modernized and often with relatively little effort.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on July 12, 2014, 03:43:24 AM
Quote from: itix;768705
Of course those programs cant be fixed. I guess AmiSnip is some kind of commodity that can hide windows and inserts them to tools menu?
It is a technology demo, and as such a small commodity which allows you to iconify arbitrary windows on the workbench. It is not particularly sophisticated, and was never supposed to be. I was actually hoping that somebody would pick up the source code and would polish it a bit.

Quote from: itix;768705
 It is perfectly OK. Applications having built-in faked iconify with HideLayers() is not. I just wouldnt want see anyone using it on new code.
I disagree completely. Again, the approach of hand-made support and an isolated iconification solution for every application is just wrong. It is too much code duplication. In fact, other operating systems (or rather, GUI systems) support that out of the box, and it requires some low-level support to allow rendering and interaction with "windows that are not there". A hidden window still has a size, a rastport, can be moved, resized... the full set of features remains available without even the program *knowing* that it does not show. In other words, this approach offers a transition pass to new features without program support that is consistent over the existing infrastructure. Integrating that into a "framework" will make it only available for programs that use this framework.
Quote from: itix;768705
I dont know any incompatible frameworks.
I know too many. Let's see... MUI, Triton, Reaction,... I believe there were a lot more. One looks different from the other, user experience differs... CBMs investment into establishing a higher abstraction layer on top of the intuition primitives came too late (boopsis) and offered too little. Do programs have a consistent L&F? Not beyond what intuition offers as standard L&F, namely window decorations and system boopsis. And no, thank you, I do not need another framework for another feature you can get independent of frameworks.
Quote from: itix;768705
Some frameworks do better than others but no any developer should be encouraged to use low level Intuition anymore. It is rude environment and crash prone if you make even small mistake. It was good in 80s but not anymore.
So what do you encourage to use? There is no established standard framework. And before I make my programs depend on a several 100K framework, or risk license incompatibilities, I'd rather stick with intuition. Yes, that's "back to the 80th", but Amiga *is* the 80ths. Nobody will change this anymore.
Quote from: itix;768705
I have got enough with software that cant go away when I am adjusting Workbench screen. It is annoying especially if there is no visual clue which programs are preventing that.
Actually, that's a design problem intuition has, and the mentioned V45 was a first step around that. Not a solution. Anyhow, I don't think it is was a very serious problem since I rarely changed the resolution or bit-depth of the workbench.

Given the many design problems AmigaOs has, it is actually not a very serious problem. There are definitely more serious ones. The bigger mess is actually gfx.
Title: Re: Layers.library V45 on the aminet
Post by: itix on July 12, 2014, 07:09:47 AM
Quote from: Thomas Richter;768776

I know too many. Let's see... MUI, Triton, Reaction,... I believe there were a lot more. One looks different from the other, user experience differs...


Okay I see what you mean by incompatible frameworks.

Quote
CBMs investment into establishing a higher abstraction layer on top of the intuition primitives came too late (boopsis) and offered too little. Do programs have a consistent L&F? Not beyond what intuition offers as standard L&F, namely window decorations and system boopsis. And no, thank you, I do not need another framework for another feature you can get independent of frameworks.  So what do you encourage to use? There is no established standard framework.


MUI is de facto standard. It has standard L&F if you like. If you dont then MUI programs dont have same L&F with Gadtools or Intuition BOOPSI classes but it is up to user.

If you dont like it then maybe ClassAct.

Quote
And before I make my programs depend on a several 100K framework, or risk license incompatibilities, I'd rather stick with intuition.


Instead you reinvent wheel and reimplement 100K framework to your application. Which is fine, memory is cheap. But my time is not cheap and I prefer to take any shortcut where possible.

Quote
Yes, that's "back to the 80th", but Amiga *is* the 80ths. Nobody will change this anymore.  Actually, that's a design problem intuition has, and the mentioned V45 was a first step around that. Not a solution. Anyhow, I don't think it is was a very serious problem since I rarely changed the resolution or bit-depth of the workbench.


I dont want my Amiga to look like 80s. I have Amiga 500 for that and is perfect for that task. I still have warm feeling when I see Kickstart 1.3 console prints. But for other purposes I want something better. It is good hobby still.

I recall there are many other occasions where Workbench tried to close its screen. But it is not important in this discussion.

Quote
Given the many design problems AmigaOs has, it is actually not a very serious problem. There are definitely more serious ones. The bigger mess is actually gfx.


Is it really so? It is little messy but from developer POV not too messy. To draw graphics primitives (in RTG) you use two different libraries (GFX and CGX API) and sometimes you mix it with some layers.library call to allocate clipped rastports. It is not very clean but as long as developer knows what functions to call it works well enough.

Internally it is bigger mess (in AmigaOS 3) where RTG subsystem must patch system. But that is not so much concern to developers.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on July 12, 2014, 07:05:49 PM
Quote from: itix;768786
MUI is de facto standard. It has standard L&F if you like. If you dont then MUI programs dont have same L&F with Gadtools or Intuition BOOPSI classes but it is up to user.
MUI never worked for me. It's license-incompatible. To remind you, I wrote freeware. Pay-nothing. If I would use it, users would have had to pay for the interface, but not for the software. Pay somebody else for my programs? I beg your pardon.

Anyhow, MUI doesn't solve the problem either. Consider a program that draws on the screen itself, preparing some kind of graphics. For the sake of the argument, consider your average Mandelbrot fractal generator. Now, how do you iconify this? Ok, you can create your *own* off-screen buffer and let the program render into that, and then always copy to the screen whenever there is one. But that's actually complete overshoot, and it also doubles the required resources. If you have a smartrefresh window, or even a superbitmap, this backing-store is already there, and transparently provided by the Os. So why not use it for exactly that, namely backing store while the window is not shown?  
Quote from: itix;768786
Instead you reinvent wheel and reimplement 100K framework to your application.  
Never did that. Gadtools worked nicely. Of course, that's fairly simple, but it was good enough for most cases. There was no need to go for the full-fledged 100K for MUI if I had everything I ever needed in ROM.  
Quote from: itix;768786
I recall there are many other occasions where Workbench tried to close its screen.  
As in? There is actually only a single Os call to do that. It could be called by programs that felt like it - in the beginning to save precious chip-ram - or for games to avoid screen-switching. Or to adjust the screen mode. It's non-crucial for the first applications since the memory situation improved. The latter is where it makes a difference, but this is typically not anoying since you do not adjust your screen every minute.

The purpose of iconification is not so much to get rid of the workbench, but to get a better overview on what's on the screen, and re-organize the windows. As soon as you have a couple of windows open, it becomes rather anoying to shuffle them around, and iconification is a solution.  
Quote from: itix;768786
Is it really so? It is little messy but from developer POV not too messy.  
Yes, it really is. Its entire design is too tightly coupled to the Amiga chipset (bitplanes, blitting) and hard to abstract from. A lot of code in P96 is just there to emulate the bitmap blitting. Gfx also documented too many of its internals and does not have a clean interface. So for example, the view and the viewport are entirely "open" structures, which led to the bizarre hack that gfx stores the monitor and viewmode information in the *colormap* because this one was *not* documented. And uses hacks like "GfxAssociate" to link external published structures that can be messed with by any user by its internal administration structures, simply because the documented structures became too small and unsuitable.

The entire monitor database is an extreme hack and has no clearly documented structure. Instead, it depends on a couple of Gfx-internal databases that were never documented.

Instead of using clearly defined "creation and destruction" functions like intuition does (OpenWindow/CloseWindow) - nowadays one would call this "constructors" and "destructors", gfx relies upon the user that he builds such structures "correctly", which is a nightmare for forwards compatibility - see above: Such structures cannot be extended.

Count for example the number of patches that go into gfx to make rtg happen - an entire hack-o-rama necessary for graphics cards, with a lot of emulation overhead due to the poor interface.

Ok, seriously: Gfx was slammed together, probably in a rush, without thinking and without any design. It's an excellent example for teaching people of how *not* to design a graphics primitives library.
Title: Re: Layers.library V45 on the aminet
Post by: vxm on July 13, 2014, 12:23:10 AM
Quote from: itix;768786
MUI is de facto standard.
As far as I remember, MUI does not support the 68000. I do not consider it as a standard.
AmigaOS has flaws but each correction affects third-party softwares. It is a pleasure to note that it is updated. Thanks.
Title: Re: Layers.library V45 on the aminet
Post by: itix on July 13, 2014, 02:07:10 AM
Quote from: Thomas Richter;768817
MUI never worked for me. It's license-incompatible. To remind you, I wrote freeware. Pay-nothing. If I would use it, users would have had to pay for the interface, but not for the software. Pay somebody else for my programs? I beg your pardon.


I dont have problem with that because I am also getting an advantage: I can write UI faster with MUI than without MUI.

Quote

Anyhow, MUI doesn't solve the problem either. Consider a program that draws on the screen itself, preparing some kind of graphics. For the sake of the argument, consider your average Mandelbrot fractal generator. Now, how do you iconify this? Ok, you can create your *own* off-screen buffer and let the program render into that, and then always copy to the screen whenever there is one. But that's actually complete overshoot, and it also doubles the required resources. If you have a smartrefresh window, or even a superbitmap, this backing-store is already there, and transparently provided by the Os. So why not use it for exactly that, namely backing store while the window is not shown?


I would use off screen buffer in *fast ram*. RAM is cheap and everyone is having more fast ram than chip/video ram. Rendering to fast ram is also going to be faster than into chip/video ram. Another advantage is you can have re-sizable window.

Quote
Never did that. Gadtools worked nicely. Of course, that's fairly simple, but it was good enough for most cases. There was no need to go for the full-fledged 100K for MUI if I had everything I ever needed in ROM.


But how do you implement font sensitive UI with Gadtools without writing your own layout manager? You have to find out current font (coding), then calculate gadget sizes and positions (more coding) and then finally open GUI and add gadgets. Then you must write your own event loop and add keyboard handling for shortcuts.

Quote
As in? There is actually only a single Os call to do that. It could be called by programs that felt like it - in the beginning to save precious chip-ram - or for games to avoid screen-switching. Or to adjust the screen mode. It's non-crucial for the first applications since the memory situation improved. The latter is where it makes a difference, but this is typically not anoying since you do not adjust your screen every minute.


If you change fonts it has to reopen WB screen. I dont know why but tuning AOS used to be my favorite hobby in the past.

Quote

The purpose of iconification is not so much to get rid of the workbench, but to get a better overview on what's on the screen, and re-organize the windows. As soon as you have a couple of windows open, it becomes rather anoying to shuffle them around, and iconification is a solution.


I agree.

Quote
Yes, it really is. Its entire design is too tightly coupled to the Amiga chipset (bitplanes, blitting) and hard to abstract from. A lot of code in P96 is just there to emulate the bitmap blitting. Gfx also documented too many of its internals and does not have a clean interface. So for example, the view and the viewport are entirely "open" structures, which led to the bizarre hack that gfx stores the monitor and viewmode information in the *colormap* because this one was *not* documented. And uses hacks like "GfxAssociate" to link external published structures that can be messed with by any user by its internal administration structures, simply because the documented structures became too small and unsuitable.

The entire monitor database is an extreme hack and has no clearly documented structure. Instead, it depends on a couple of Gfx-internal databases that were never documented.


Oh, I see. But it was also typical for that era.

Quote

Instead of using clearly defined "creation and destruction" functions like intuition does (OpenWindow/CloseWindow) - nowadays one would call this "constructors" and "destructors", gfx relies upon the user that he builds such structures "correctly", which is a nightmare for forwards compatibility - see above: Such structures cannot be extended.

Count for example the number of patches that go into gfx to make rtg happen - an entire hack-o-rama necessary for graphics cards, with a lot of emulation overhead due to the poor interface.

Ok, seriously: Gfx was slammed together, probably in a rush, without thinking and without any design. It's an excellent example for teaching people of how *not* to design a graphics primitives library.


When I am reading RKRM gfx part I am getting impression GFX was meant to be low level interface to game developers. It does go in detail how to load views or build copper lists. It explains BOBs and sprites and there are dual playfield examples.

Some of examples in RKRM are not even safe because they bypass Intuition. Which is weird.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on July 18, 2014, 06:33:56 PM
Short update, thus I revive the thread: Christian Sauer reported that you can actually use the V45 layers with CGfx *without* the LayersAntiHack program, provided that 1) you use CGfx version 4 (probably also: or better, if there is such a thing, I do not know) and 2) if you make sure that ENVARC:CyberGraphX/SUPERLAYERS is *not* set. IOW, make sure that you delete this file from ENVARC: Apparently, V45 is "super" enough. (-;
Title: Re: Layers.library V45 on the aminet
Post by: biggun on July 18, 2014, 07:33:59 PM
Hi Thomas,

great work. Nice to see this update. Thanks!

What you say that Intuition could be enabled to support dragging windows out of the screen sound cool.
I like this feature.
How complicated would this be in your opinion?
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on July 18, 2014, 08:52:21 PM
Yes. I think it could be a major enchancement for many to have it at hand without messing with patches. Just fyi its a feature in aros that works on amigas too. You might consult aros v1 sources.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on July 18, 2014, 09:09:02 PM
Quote from: biggun;769326
Hi Thomas,

great work. Nice to see this update. Thanks!

What you say that Intuition could be enabled to support dragging windows out of the screen sound cool.
I like this feature.
How complicated would this be in your opinion?

Just algorithmically, it's rather trivial because it is clear what has to be done, and where it has to be done. There are two "hard" parts. Problem one is a legal problem, namely getting the permission to work on intuition. Problem two is to actually *compile* intuition.  

It currently depends on some old obscure C compiler, I believe the greenhills compiler, which nobody has anymore. Thus, it's a matter of re-organizing the code to make it compile with a more standard compiler. I haven't tried that, I just remember that Olsen was cursing about it, and I didn't dare to look where the problem was, in particular. Probably reaching the elements of IntuitionBase from inside the code, I do not know.
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on July 18, 2014, 09:21:09 PM
What i see as a problem here is that a user needs to look up the whole internet himself to collect and apply those bits and pieces. There is some sort of central repository, bb4 maintained by gulliver i think, but best would be an updated os in a single download. Aros vision by olaf is a good start even if a little messy. Alas aros is still not as fast, complete and stable as the genuine os.
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on July 18, 2014, 10:02:07 PM
Quote from: Thomas Richter;769334
Just algorithmically, it's rather trivial because it is clear what has to be done, and where it has to be done. There are two "hard" parts. Problem one is a legal problem, namely getting the permission to work on intuition. Problem two is to actually *compile* intuition.  

It currently depends on some old obscure C compiler, I believe the greenhills compiler, which nobody has anymore. Thus, it's a matter of re-organizing the code to make it compile with a more standard compiler. I haven't tried that, I just remember that Olsen was cursing about it, and I didn't dare to look where the problem was, in particular. Probably reaching the elements of IntuitionBase from inside the code, I do not know.

The solution if one cared could be to port aros intuition to aos. It compiles with current gcc aros 68k backend 4.6.x or 4.7 now. There is a version 4.5.0 for aos by bernd rosch. He even tried to compile aros intuition for afa-os but has not succeeded. It was before aros68 kickstart replacement has been started though. It might be easier now.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on July 18, 2014, 10:19:55 PM
Quote from: wawrzon;769339
The solution if one cared could be to port aros intuition to aos. It compiles with current gcc aros 68k backend 4.6.x or 4.7 now. There is a version 4.5.0 for aos by bernd rosch. He even tried to compile aros intuition for afa-os but has not succeeded. It was before aros68 kickstart replacement has been started though. It might be easier now.

That could be a viable solution provided the new code is generated in a "clean room" approach, i.e. the author has no access to the original sources. That counts me out, I afraid. The whole situation is unsatisfactory, agreed.
Title: Re: Layers.library V45 on the aminet
Post by: matthey on July 18, 2014, 10:21:05 PM
Quote from: wawrzon;769339
The solution if one cared could be to port aros intuition to aos. It compiles with current gcc aros 68k backend 4.6.x or 4.7 now. There is a version 4.5.0 for aos by bernd rosch. He even tried to compile aros intuition for afa-os but has not succeeded. It was before aros68 kickstart replacement has been started though. It might be easier now.


I believe AROS took a much different approach to implementing layers though. I suppose there is the gfx.library abstraction in between so maybe Intuition wouldn't be too difficult to use. I would love to get development of AmigaOS classic going again but the legal problems remain as ThoR pointed out. There is a thread over on Amigaworld.net talking about buying the Amiga name, AmigaOS and the Amiga.com web site but it's a legal mess.

http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=39217&forum=2

I might make an offer to buy everything myself but I don't know who owns what and I don't really want to give any money to the crooks at Amiga Inc. or a bunch of lawyers. Like I said over there, the legal fees (to insure ownership and property rights) could easily cost more than the purchase price (assuming the low kickstarter target price of only $125,000 U.S. would be enough to buy everything AND fund a new hardware project).
Title: Re: Layers.library V45 on the aminet
Post by: carvedeye on July 18, 2014, 11:02:59 PM
Am i right in thinking that all you need to do to install it is to replace it with the old one and restart system? No editing the s-s?
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on July 18, 2014, 11:19:01 PM
Quote from: matthey;769342
I believe AROS took a much different approach to implementing layers though. I suppose there is the gfx.library abstraction in between so maybe Intuition wouldn't be too difficult to use. I would love to get development of AmigaOS classic going again but the legal problems remain as ThoR pointed out. There is a thread over on Amigaworld.net talking about buying the Amiga name, AmigaOS and the Amiga.com web site but it's a legal mess.

http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=39217&forum=2

I might make an offer to buy everything myself but I don't know who owns what and I don't really want to give any money to the crooks at Amiga Inc. or a bunch of lawyers. Like I said over there, the legal fees (to insure ownership and property rights) could easily cost more than the purchase price (assuming the low kickstarter target price of only $125,000 U.S. would be enough to buy everything AND fund a new hardware project).


PLease not again. Let be done with buying the name, the source whatsoever. Was discused to the death. As for intuition im not sure about dependencies on aos and aros but i guess its graphics lib on both. The hidds are lower below. Some aros dev reading here might comment on that.
@thor
Yes. Alas it seems it counts you out. Hard to tell if there is anybody up to task. I cant think of none.
Title: Re: Layers.library V45 on the aminet
Post by: pawelek on August 20, 2014, 11:17:36 PM
Quote from: Thomas Richter;768573
I probably do not have time right now to look into this (I'm right now in Sapporo, Japan). Maybe I have short chance of checking this next weekend, but I will unlikely be able to provide any type of fix before August (*sigh*).   In worst case, it will be a patch to P96 to be V45 aware.  Greetings, Thomas


   The problem with the new layers.library
http://amiga.ct8.pl/wp-content/uploads/2014/08/MOV_0017.mp4
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on August 20, 2014, 11:37:09 PM
Quote from: pawelek;771342
The problem with the new layers.library
http://amiga.ct8.pl/wp-content/uploads/2014/08/MOV_0017.mp4

That's P96, isn't it? Yes, I afraid that's a P96 bug. I'm not quite sure what the latest version of P96 is. What do you have? It shouldn't be a (major) problem to recompile this with the fix included once I have a chance to look into it.   Otherwise, if that's not the known P96 problem with video overlays, please make a detailed bug report how to reproduce (video is currently not working so well - from Sapporo to San Diego... ;-)
Title: Re: Layers.library V45 on the aminet
Post by: Oldsmobile_Mike on August 20, 2014, 11:52:53 PM
Thanks!  Working great in preliminary testing on my highly patched A2000 system.  As previous commenter noted, Birdie crashes with this installed as soon as you open any window.  Out of idle curiosity, what's the general consensus on this?  I happen to rather like Birdie.  Is there any work-around or similar program that I can use that will allow me to have OS4-like window borders on my system?

Thanks again!  :drink::drink:
Title: Re: Layers.library V45 on the aminet
Post by: pawelek on August 21, 2014, 09:43:08 AM
Quote from: Thomas Richter;771346
That's P96, isn't it? Yes, I afraid that's a P96 bug.

Yes, Picasso96, A1200 Mediator + Radeon 9250.
Recent library:
Picasso96API.library 2310
emulation.library 40395
rtg.library 40.3994
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on August 24, 2014, 08:46:01 PM
Quote from: pawelek;771378
Yes, Picasso96, A1200 Mediator + Radeon 9250.
Recent library:
Picasso96API.library 2310
emulation.library 40395
rtg.library 40.3994

Got it. I'm currently trying to get in touch with Alex whether I can make a re-release of P96 with a fix. Not that the fix is overly complicated, but I cannot really promise anything at this time since it's not my decision - so please stand by, sorry.
Title: Re: Layers.library V45 on the aminet
Post by: pawelek on August 26, 2014, 10:02:18 PM
Demonstration new layers.library (45.19)

new version presented from time 7:20
https://www.youtube.com/watch?v=PzZEscDf9EU
Title: Re: Layers.library V45 on the aminet
Post by: kickstart on August 26, 2014, 10:07:37 PM
What is this?

TomasRitcher= good (have the aeon ok), cosmos (or others)= bad (they are crackers using illegal hackery)?
Title: Re: Layers.library V45 on the aminet
Post by: Oldsmobile_Mike on August 26, 2014, 10:45:10 PM
Quote from: pawelek;771816
Demonstration new layers.library (45.19)

new version presented from time 7:20
https://www.youtube.com/watch?v=PzZEscDf9EU

Could you include some narrative  on the video? Not really sure what I was watching. Then again I just skipped to 7:20 and saw someone run a SysInfo test that said the machine was running 180x the speed of an A4000, LOL. ;)
Title: Re: Layers.library V45 on the aminet
Post by: pawelek on August 26, 2014, 11:00:54 PM
The beginning of the video the old layers.library 40.1 and its test speed of 111 open windows,
   then from 7:20 a new version of the library and the same test
Title: Re: Layers.library V45 on the aminet
Post by: pawelek on September 08, 2014, 05:07:01 PM
Quote from: Thomas Richter;771683
Got it. I'm currently trying to get in touch with Alex whether I can make a re-release of P96 with a fix. Not that the fix is overly complicated, but I cannot really promise anything at this time since it's not my decision - so please stand by, sorry.

   Are there any news on the bug Picasso96?
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 08, 2014, 05:30:40 PM
Quote from: pawelek;772583
Are there any news on the bug Picasso96?

No, unfortunately. I tried several times to contact Alex concerning this problem, but I didn't receive anything. (It's not that I'm unable to fix this in P96 - I have everything I need - except the author's permission). Then, however, it's vacation time, so he's probably somewhere else.  Greetings, Thomes
Title: Re: Layers.library V45 on the aminet
Post by: Cosmos on September 08, 2014, 06:45:06 PM
Quote from: pawelek;771342
The problem with the new layers.library
http://amiga.ct8.pl/wp-content/uploads/2014/08/MOV_0017.mp4


I discovered a compilator branch bug into the rtg.library v40.3994...

Only 4 or 6 bytes to fix, and I'll send you this new version for checking...



:)
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 08, 2014, 07:06:18 PM
Quote from: Cosmos;772591
Only 4 or 6 bytes to fix, and I'll send you this new version for checking...

Would you *please* stop messing with other's people software? This is Alex' decision, and not yours, and also not mine. If I say I'll keep care of it, I'll keep care of it, but it will take as long as it takes.
Title: Re: Layers.library V45 on the aminet
Post by: Cosmos on September 08, 2014, 08:22:27 PM
Quote from: Thomas Richter;772594
Would you *please* stop messing with other's people software? This is Alex' decision, and not yours, and also not mine. If I say I'll keep care of it, I'll keep care of it, but it will take as long as it takes.


I sent a message to Alex on facebook and no answer...
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 08, 2014, 08:49:07 PM
Quote from: Cosmos;772602
I sent a message to Alex on facebook and no answer...

And that gives you which right? Exactly... none-so-ever. Would it help to mention that I had contact with him just months ago? And that we had a friendly exchange on the P96 subject?  Ok, point is that I do not exactly know what the legal situation with P96 is and wether Alex can even decide what can happen with it. But you or me can do that to an even lesser degree. The situation might be delicate, it is delicate to me, and it is probably even more delicate to Alex, I really don't know, but all I can do is to find out and understand where we are.   Now, instead of trying to have some patience and thrusting people that they'll try to do their job properly to their best of their knowledge, you just jump ahead and ruin the entire situation. Thank you for that so much.
Title: Re: Layers.library V45 on the aminet
Post by: Gulliver on September 08, 2014, 11:13:16 PM
Please also keep in mind this bug/missbehaviour of rtg.library

http://eab.abime.net/showthread.php?t=58921&highlight=rtg.library
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 08, 2014, 11:32:27 PM
Quote from: Thomas Richter;772605
And that gives you which right? Exactly... none-so-ever. Would it help to mention that I had contact with him just months ago? And that we had a friendly exchange on the P96 subject?  Ok, point is that I do not exactly know what the legal situation with P96 is and wether Alex can even decide what can happen with it. But you or me can do that to an even lesser degree. The situation might be delicate, it is delicate to me, and it is probably even more delicate to Alex, I really don't know, but all I can do is to find out and understand where we are.   Now, instead of trying to have some patience and thrusting people that they'll try to do their job properly to their best of their knowledge, you just jump ahead and ruin the entire situation. Thank you for that so much.


i dont think you will be able to stop anyone from modding amiga these days, people are modding other stuff not asking the designers for permission. especially when it is obsolete or abandoned anyway. as long as it remains within the low there is nothing to do against it i guess. sometimes they improve things, its just all their own risk if they break something.
Title: Re: Layers.library V45 on the aminet
Post by: Cosmos on September 09, 2014, 05:47:35 AM
Quote from: Thomas Richter;772605
And that gives you which right? Exactly... none-so-ever. Would it help to mention that I had contact with him just months ago? And that we had a friendly exchange on the P96 subject?  Ok, point is that I do not exactly know what the legal situation with P96 is and wether Alex can even decide what can happen with it. But you or me can do that to an even lesser degree. The situation might be delicate, it is delicate to me, and it is probably even more delicate to Alex, I really don't know, but all I can do is to find out and understand where we are.   Now, instead of trying to have some patience and thrusting people that they'll try to do their job properly to their best of their knowledge, you just jump ahead and ruin the entire situation. Thank you for that so much.


And I emailed Tobias about 2 months ago for another reason, and no answer too...

Amiga Classics are old now, they don't care...


Finally I checked this morning the rtg.library branch bug : I changed only one byte ($00 instead of the wrong $04)

Emailed to Pawelek for checking...
Title: Re: Layers.library V45 on the aminet
Post by: psxphill on September 09, 2014, 09:09:48 AM
Quote from: kickstart;771817
What is this?

TomasRitcher= good (have the aeon ok), cosmos (or others)= bad (they are crackers using illegal hackery)?

cosmos went from not reporting bugs and instead releasing hacks for software that Thomas is maintaining, to hacking software that has already been fixed.
 
 It's obvious what is going on and the motives behind it.
Title: Re: Layers.library V45 on the aminet
Post by: Cosmos on September 09, 2014, 09:55:33 AM
It's totally impossible to talk with Thomas Richter : he change is mind like a girl change his clothes...


In June 2014 :

Quote from:
I will likely not have the time to keep it updated. Bug reports
welcome, of course, but without promise that I will provide fixes. If you find
problems, you are on your own. De-install by removing layers.library from LIBS:
and remove the corresponding argument from LoadModule, you should be fine again.


In August 2014 :

Quote from:
With all necessary respect: If you find a bug (or believe to have found a bug, I don't know), please *report it* so it can be fixed upstream.


Where is the logic ? He wrote everything and it's contaire...



Anyways, the branch bug in the rtg.library is really a very big bug : $6004FDA6 must be replaced by $6000FDA6

A bug from the compilator SAS/C, not from the coders I guess well...

Check by yourself, and see...




:)
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 09, 2014, 10:23:24 AM
(double post, removed)
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 09, 2014, 10:23:56 AM
Quote from: Cosmos;772640
It's totally impossible to talk with Thomas Richter : he change is mind like a girl change his clothes...

That means: I have very little spare time to maintain anything, and I cannot make promises. I'm not a professional software vendor were you can come along and request a bugfix within 48 hours because you paid for the software. I can only promise to look at bugs, and fix them if I find them, whenever I have time and access to the Amiga. The next time I'll have access to the Amiga will be in October (yes really, it is really that slow). I cannot fix anything any sooner, it's part of the entire situation here. Thus, if you find a problem, I cannot promise you to fix anything. I can only fix things on a "best-effort" basis, which may or may not be good enough for you. If you are depending on anything on your machine, and things break due to a problem I caused, well, come along, report it, I'll try to take care of it whenever I can. But do not expect this will happen tomorrow. It will happen when I have time to do it. Understood? The text in software is a "disclaimer" (as in "legal speech"), and saying anything else may be a bit risky.

I don't think it is particularly hard to report bugs, though, or to talk to me in general. We might *disagree* though, but that's a normal part of an argument.
Title: Re: Layers.library V45 on the aminet
Post by: kolla on September 09, 2014, 01:27:32 PM
Without any single point of communication, reporting bugs for OS3.9 is a PITA. It speaks volumes that even those who are "inside" and know other OS developer by their first names, even they do not know the legal status of a rather core component of the OS.
Title: Re: Layers.library V45 on the aminet
Post by: kolla on September 09, 2014, 01:41:24 PM
Quote from: Thomas Richter;772643
The next time I'll have access to the Amiga will be in October (yes really, it is really that slow).


Why not build yourself an Amiga in the cloud? :hammer:
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 09, 2014, 02:24:14 PM
Quote from: kolla;772645
Why not build yourself an Amiga in the cloud? :hammer:

Yes, it's kind of ironic. I'm here working at a computing center with a big bunch of machines for my disposal, but none of them is a working Amiga.

Anyhow. Please understand that none of those that contributed code to 3.9 were lawers, only engineers, so how could one know the status of the components given that we don't even know the contracts of each other? These were negotiated individually, BTW.
Title: Re: Layers.library V45 on the aminet
Post by: stefcep2 on September 09, 2014, 02:25:35 PM
Quote from: Thomas Richter;772585
No, unfortunately. I tried several times to contact Alex concerning this problem, but I didn't receive anything. (It's not that I'm unable to fix this in P96 - I have everything I need - except the author's permission). Then, however, it's vacation time, so he's probably somewhere else.  Greetings, Thomes


Amiga software authors must be the most difficult to contact

I remember the owner of Miami years ago "disappearing", then the MUI guy, the IBrowse guy.

Everyone these days is contactable but no, not Amiga programmers.

And if you do manage to contact him it would not surprise they refuse, well because they can.

Unbelievable.
Title: Re: Layers.library V45 on the aminet
Post by: kolla on September 09, 2014, 02:30:17 PM
Luckily there is Cosmos ;)
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 09, 2014, 02:41:27 PM
Quote from: stefcep2;772648
And if you do manage to contact him it would not surprise they refuse, well because they can.

Unbelievable.

It's not "because they can". Nobody is needlessly destructive here. It is just that software was created under contract, the authors are not necessarily the owners, and the actual owners have no business anymore in the Amiga market, with the responsble persons having already left the company a long time ago, along with insight knowledge on the contract, or possibly even the contract itself.

So what can an author say? If "yes", he's pobably breaching a contract that still exists, even though the owners do not care. Contacting the owners might be hard or even impossible, leave alone they may not even know anything from back then - though that doesn't invalidate the contract. Thus, from a legal perspective, it is of course the safest option not to say anything.
Title: Re: Layers.library V45 on the aminet
Post by: LoadWB on September 09, 2014, 03:11:00 PM
Quote from: stefcep2;772648
Amiga software authors must be the most difficult to contact

I remember the owner of Miami years ago "disappearing", then the MUI guy, the IBrowse guy.


I understand that after Holger Kruse went to work for Rebol he lost the Miami key generation ability in a hard drive crash.  I have often chided him for being completely non-responsive as I'm certain he's not flooded with emails from Amiga users.  As for Stuntz (MUI,) I have received emails from him recently in response to inquiries about purchasing additional MUI licenses for my 68k machines; quickly, no less.

I don't think anyone's heard from the IBrowse front since the fall of the Berlin Wall. :laugh1:
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 09, 2014, 04:47:24 PM
Quote from: stefcep2;772648
Amiga software authors must be the most difficult to contact

I remember the owner of Miami years ago "disappearing", then the MUI guy, the IBrowse guy.

Everyone these days is contactable but no, not Amiga programmers.

And if you do manage to contact him it would not surprise they refuse, well because they can.

Unbelievable.
This may sound harsh, but people's lives change greatly between their twenties and forties, and the behaviour you criticize is most definitely a result of that.

Many of us Amiga developers started out when we were in our early twenties, and it has been almost 20 years since Commodore folded. That's a lot of time in which we went to university, moved, married, got a job, changed jobs, etc. As soon as you have a family to care for, your life is never going to be the same as it was before. You lose contact with your friends, your spare time shrinks, you have commitments to your job and your company which take priority over what used to be more fun.

Now, I'm still single, don't have a family of my down to care for, but many of my friends I knew since school, friends I met at university, friends I met in the Amiga field, their lives have changed so much in 20 years that it baffles me, and it humbles me, too.

So, please don't consider the lack of "love" for the old Amiga material to be arrogance or negligence. Things change, and they change at different speeds for different people.

There's that, and technology has changed, too. How do you contact somebody on the Internet whom you could reach 20 years ago via e-mail or IRC? This has become more difficult, not less difficult. You don't need to go back 20 years, it's been difficult for even 10 years.
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 09, 2014, 04:57:43 PM
yes, having a family is greatly overrated, but the whole talk here is just another proof that open source is the only sensible solution in a given situation. alas neither great part of developers nor users seem to acknowledge it.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 09, 2014, 05:47:08 PM
Quote from: wawrzon;772656
alas neither great part of developers nor users seem to acknowledge it.

Isn't that another way of saying it's not a solution? Anyhow. It's not really that I'll stop anyone from contributing, I'm even happy to answer questions if I can. Please understand that I have limited time and limited possibilities to contribute.
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 09, 2014, 05:54:02 PM
Quote from: Thomas Richter;772661
Isn't that another way of saying it's not a solution? Anyhow. It's not really that I'll stop anyone from contributing, I'm even happy to answer questions if I can. Please understand that I have limited time and limited possibilities to contribute.

No it is not... it only shows that many of the few that are left are stubborn und unwilling to invest in something new even if it might offer future
Title: Re: Layers.library V45 on the aminet
Post by: psxphill on September 09, 2014, 06:41:36 PM
Quote from: kolla;772649
Luckily there is Cosmos ;)

At one time I would have agreed, recently he's trashed his own reputation in a dick waving contest.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 09, 2014, 09:20:02 PM
Quote from: OlafS3;772662
No it is not... it only shows that many of the few that are left are stubborn und unwilling to invest in something new even if it might offer future

As often, this is really a matter of perspective. Especially on "future". Look, I probably should not open up this discussion, but if I really seriously consider what the future should be - at least as far as computing is concerned - then it is not Amiga. It's a nice hobby, for sure, but it's not the future of computing. It is the past of computing.
Title: Re: Layers.library V45 on the aminet
Post by: Methuselas on September 09, 2014, 11:25:53 PM
Quote from: Thomas Richter;772680
As often, this is really a matter of perspective. Especially on "future". Look, I probably should not open up this discussion, but if I really seriously consider what the future should be - at least as far as computing is concerned - then it is not Amiga. It's a nice hobby, for sure, but it's not the future of computing. It is the past of computing.


+1 We may have had a chance, with things like Amithlon, when they first came out, but now none of the camps have what is needed for any of them to become commercially viable, beyond a hobbyist machine.
Title: Re: Layers.library V45 on the aminet
Post by: psxphill on September 10, 2014, 08:28:12 AM
Quote from: Methuselas;772682
+1 We may have had a chance, with things like Amithlon, when they first came out, but now none of the camps have what is needed for any of them to become commercially viable, beyond a hobbyist machine.

Commercial viability disappeared in the early 90's.
 AOS4 and MorphOS will never be more than a crowd funded hobby.
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 10, 2014, 11:02:17 AM
Quote from: Thomas Richter;772680
As often, this is really a matter of perspective. Especially on "future". Look, I probably should not open up this discussion, but if I really seriously consider what the future should be - at least as far as computing is concerned - then it is not Amiga. It's a nice hobby, for sure, but it's not the future of computing. It is the past of computing.


Future means for me a OS that is in development, new users and perhaps reach a stage where it becomes interesting for small companies. We will never get the big million dollar games or be mainstream again. But even a niche can be interesting. Time will tell.
Title: Re: Layers.library V45 on the aminet
Post by: kolla on September 10, 2014, 11:13:38 AM
Quote from: Thomas Richter;772680
As often, this is really a matter of perspective. Especially on "future". Look, I probably should not open up this discussion, but if I really seriously consider what the future should be - at least as far as computing is concerned - then it is not Amiga. It's a nice hobby, for sure, but it's not the future of computing. It is the past of computing.


Wow, did you figure out this just now?
Title: Re: Layers.library V45 on the aminet
Post by: kolla on September 10, 2014, 11:22:29 AM
Quote from: psxphill;772666
At one time I would have agreed, recently he's trashed his own reputation in a dick waving contest.


And that is relevant how? As long as he uses his skills to explore and improve things, I don't really care about the social aspect.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 10, 2014, 03:03:51 PM
Quote from: kolla;772702
Wow, did you figure out this just now?

No, about ten years ago. Just my reaction if I hear the words "Amiga" and "Future" in the same sentence.
Title: Re: Layers.library V45 on the aminet
Post by: trekiej on September 10, 2014, 04:16:00 PM
I hope this is not too off topic.
How do you think cbm would have used for example an ati graphics card?
Would re-writing or modifying the graphics library made that possible?
Or, is there a whole lot more that would need to be done?
I know that there is rtg and it can be chunky and the amiga had bit-plane graphics.
Title: Re: Layers.library V45 on the aminet
Post by: kolla on September 10, 2014, 04:18:35 PM
Commodore was on their way to Windows NT on PA-RISC for the next "Amiga" :)
Title: Re: Layers.library V45 on the aminet
Post by: LiveForIt on September 10, 2014, 04:47:06 PM
Quote from: psxphill;772698
never be more than a crowd funded hobby.

Founded? Not if was we quit our day jobs (supporting M$ products) and just work on just Amiga projects, the donates most developers get in the amiga community can sponsor a Spotify account, but does not put food on the table.

What the developers do is more out of love/insanity for the OS and computers and not to make a living.

If some one was actually willing to found software development to get video editing programs, and other essentials to AmigaOS then there is future, but as there are no one with deep pockets, things is going to move slow.
Title: Re: Layers.library V45 on the aminet
Post by: LiveForIt on September 10, 2014, 04:56:57 PM
Quote from: Thomas Richter;772707
No, about ten years ago. Just my reaction if I hear the words "Amiga" and "Future" in the same sentence.


Even 10 years ago Amiga was pretty poor shape, 20 years ago they should have done things different, 14 year ago they wasted too match time with OS3.5 and OS3.9, they should moved to PowerPC sooner. 10 years ago Appel moved to Intel, and PowerPC desktop market shrunk. While PowerPC is not dead its not what it used to be.
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 10, 2014, 06:10:30 PM
Quote from: LiveForIt;772719
Even 10 years ago Amiga was pretty poor shape, 20 years ago they should have done things different, 14 year ago they wasted too match time with OS3.5 and OS3.9, they should moved to PowerPC sooner. 10 years ago Appel moved to Intel, and PowerPC desktop market shrunk. While PowerPC is not dead its not what it used to be.


Even 14 years ago PPC was predictable a dead-end. They should have moved to the dark side (=X86) then.
Title: Re: Layers.library V45 on the aminet
Post by: modrobert on September 10, 2014, 06:39:59 PM
Quote from: Cosmos;772630
Finally I checked this morning the rtg.library branch bug : I changed only one byte ($00 instead of the wrong $04)

Impressive one byte patch!

Thanks for taking the time to actually debug stuff on the assembly level, and giving me another reason to love the Amiga community.


Quote from: Thomas Richter;772650
It's not "because they can". Nobody is needlessly destructive here. It is just that software was created under contract, the authors are not necessarily the owners, and the actual owners have no business anymore in the Amiga market, with the responsble persons having already left the company a long time ago, along with insight knowledge on the contract, or possibly even the contract itself.

So what can an author say? If "yes", he's pobably breaching a contract that still exists, even though the owners do not care. Contacting the owners might be hard or even impossible, leave alone they may not even know anything from back then - though that doesn't invalidate the contract. Thus, from a legal perspective, it is of course the safest option not to say anything.

In other words an outsider, not bound by old business contracts like the original authors, can pretty much fix/patch anything under "fair use" considering the age of the Amiga software (and hardware). This could be a way forward, right?
Title: Re: Layers.library V45 on the aminet
Post by: LiveForIt on September 10, 2014, 07:21:05 PM
Quote from: OlafS3;772724
Even 14 years ago PPC was predictable a dead-end. They should have moved to the dark side (=X86) then.


Predictable ? Well some did not agree with this predictions.

PowerPC back in 1998 was doing about the same in the benchmarks as the Intel chips.

http://en.wikipedia.org/wiki/IMac_G3

MacOS9 / IMac G3 perty muth saved appel from bankrupcy.

https://www.youtube.com/watch?v=C2rXhKncGRU&list=PLozRe3PHsxkUzla6CtOex3mCwPZs6UtSD#

Power Mac G5 came out in 2003, and was the one thing that made Appel look to Intel, if I remember correct it was late, this way Appel went with to Intel.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 10, 2014, 08:23:00 PM
Quote from: modrobert;772726
In other words an outsider, not bound by old business contracts like the original authors, can pretty much fix/patch anything under "fair use" considering the age of the Amiga software (and hardware). This could be a way forward, right?

No, it rather means that an outsider can make a "hack and slash" attack to the software and make the software infrastructure completely unmaintainable becaues nobody knowns for any future applications which version the software had, where the actual bug was, how to fix the bug in first place, and on which version the software depends.

Again, and sorry to sound arrogant again, but this is the difference between software engineering and hacking. Software engineering means to keep the software maintainable, to have a version managenent, a software repository, a revision history and a process how to update software. You may not believe it, but yes, there is a repository for P96.
Title: Re: Layers.library V45 on the aminet
Post by: modrobert on September 10, 2014, 08:37:37 PM
Quote from: Thomas Richter;772731
No, it rather means that an outsider can make a "hack and slash" attack to the software and make the software infrastructure completely unmaintainable becaues nobody knowns for any future applications which version the software had, where the actual bug was, how to fix the bug in first place, and on which version the software depends.

Again, and sorry to sound arrogant again, but this is the difference between software engineering and hacking. Software engineering means to keep the software maintainable, to have a version managenent, a software repository, a revision history and a process how to update software. You may not believe it, but yes, there is a repository for P96.

This makes sense if the software is maintained, but what happens when it is not maintained due to the limitations you stated yourself in previous post?

Also, think of a solution this time, be constructive, try to think out of the box for a moment instead of stating one excuse after another.
Title: Re: Layers.library V45 on the aminet
Post by: psxphill on September 10, 2014, 08:59:54 PM
Quote from: LiveForIt;772729
Predictable ? Well some did not agree with this predictions.

PowerPC back in 1998 was doing about the same in the benchmarks as the Intel chips.

It was predictable because PowerPC was mostly able to compete with x86.

http://www.theregister.co.uk/1998/10/01/microsoft_killed_the_powerpc/

Things have changed now and Microsoft and Intel aren't so close these days. A dual Arm/X86 chip would be more likely to get support.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 10, 2014, 09:28:26 PM
Quote from: modrobert;772732
This makes sense if the software is maintained, but what happens when it is not maintained due to the limitations you stated yourself in previous post?

It means that somebody must maintain it if there is a demand. Quite obvious? Isn't it that I said multiple times that I'll try to look for a solution? Hacking up the software to infinity is not a solution because it leaves an unmaintainable junk of garbadge. Now tell me again I won't look for solution.
Title: Re: Layers.library V45 on the aminet
Post by: LiveForIt on September 10, 2014, 09:48:37 PM
Quote from: Thomas Richter;772734
because it leaves an unmaintainable junk of garbadge.

Well thats a good thing in my book, because then just maybe people decides to upgrade to AmigaOS4.x, what better way to get people to upgrade because software does not work on AmigaOS3.x because wrong versions and patches that makes system unstable.

maybe its a conspiration :laughing:

Quote
unmaintainable

On the other hand if who is going maintain it if the source code is not obtainable?

I see a catch 22 here. :-)
Title: Re: Layers.library V45 on the aminet
Post by: modrobert on September 10, 2014, 10:37:06 PM
Quote from: Thomas Richter;772734
It means that somebody must maintain it if there is a demand. Quite obvious? Isn't it that I said multiple times that I'll try to look for a solution? Hacking up the software to infinity is not a solution because it leaves an unmaintainable junk of garbadge. Now tell me again I won't look for solution.


At this point you are trapped in a circular argument, defunct by design. We were discussing closed source cases where you claimed the legal rights to the code in question were uncertain effectively preventing existing developers to maintain the source code already in their possession, or releasing it to someone else.

The active Amiga community is pretty small these days, so even though I don't know you or Cosmos personally, I know projects both of you are involved in, past and present.

For example, Cosmos ongoing assembler optimization of classic 68k Amiga libs where performance has been improved and size reduced, mainly because they were written in C to begin with.

Also some of your projects, like this one (the thread) and MMULib.

As mentioned previously in this thread, and where most of us seem to agree, is that the Amiga is mainly used by hobbyists these days and a few hardcore individuals who never really stopped using it productively, at least when it comes to classic hardware.

I for one appreciate the "hack and slash" Cosmos is doing, and your projects as well, one does not rule out the other. When old software needs a fix/update in this community, someone will come up with a working solution, even if it means bare metal hacking of the binary or full source code repository access.
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 10, 2014, 10:46:46 PM
Quote from: LiveForIt;772729
Predictable ? Well some did not agree with this predictions.

PowerPC back in 1998 was doing about the same in the benchmarks as the Intel chips.

http://en.wikipedia.org/wiki/IMac_G3

MacOS9 / IMac G3 perty muth saved appel from bankrupcy.

https://www.youtube.com/watch?v=C2rXhKncGRU&list=PLozRe3PHsxkUzla6CtOex3mCwPZs6UtSD#

Power Mac G5 came out in 2003, and was the one thing that made Appel look to Intel, if I remember correct it was late, this way Appel went with to Intel.


It was predictable because money rules the world and big numbers decide in the chip industry. At that time the PC market was already far ahead in volume and investment. G5 is not bad, I think a little power hungry and I do not know if it was competitive on price but as long as the software runs on one core it was and even is not bad but nevertheless it would have been a better choice to use X86 or have at least a option to change ISA if necessary.
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 10, 2014, 10:48:08 PM
Quote from: Thomas Richter;772734
It means that somebody must maintain it if there is a demand. Quite obvious? Isn't it that I said multiple times that I'll try to look for a solution? Hacking up the software to infinity is not a solution because it leaves an unmaintainable junk of garbadge. Now tell me again I won't look for solution.


Simple question... who maintains it now or will maintain it?
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 11, 2014, 07:36:48 AM
Quote from: modrobert;772737
At this point you are trapped in a circular argument, defunct by design.  
You still don't get it, right? I'm trying to find out what the situation is, understood? How much more explicit do I need to get?  
Quote from: modrobert;772737
For example, Cosmos ongoing assembler optimization of classic 68k Amiga libs where performance has been improved and size reduced, mainly because they were written in C to begin with.
Have you made any measurements showing the efficiency of these "improvements", and have you considered that this leaves the libraries in a pretty unmaintainable state?  
Quote from: modrobert;772737
When old software needs a fix/update in this community, someone will come up with a working solution, even if it means bare metal hacking of the binary or full source code repository access.

Again, what is "working" for you? For me it means that I can also fix something in two years in the future. With the kind of "improvements" I see from Cosmos this is unlikely to be even possible. First of all, it doesn't really improve anything, and second, even if the results were measurable, the improvements were lost or incompatible to any other changes that had to be made.  Anyhow, make your pick. If you don't agree with me, I'm ready to leave and don't touch any of the old stuff anymore.
Title: Re: Layers.library V45 on the aminet
Post by: modrobert on September 11, 2014, 09:26:44 AM
Quote from: Thomas Richter;772753
You still don't get it, right? I'm trying to find out what the situation is, understood? How much more explicit do I need to get?


Sorry about that, my mistake, I interpreted your previous replies as if it was intentionally left in limbo for good reason.

Quote from: Thomas Richter;772753
Have you made any measurements showing the efficiency of these "improvements", and have you considered that this leaves the libraries in a pretty unmaintainable state?


No, I haven't made my own measurements, was just inspired by the idea to optimize the libraries and acknowledgements by others that Cosmos patches were indeed working. I did check some of the assembler code "before/after change" which he posted over at eab a while back, looked good to me.

My 68k assembler knowledge is still a bit rusty compared to what it used to be, slowly getting back in the game. What I love about 68k is the CISC part and that the Amiga hardware is well documented, even binary patches disassembles to decent source code which can be easily worked on and understood.

I thought about this some more last night, and in cases where no one is maintaining the source code (or where the source code indeed is lost), one solution could be disassembling the binaries (eg. with adis or resource). Make sure the source compiles OK, and then post/push that to github for everyone to enjoy, to either improve further or fork into new projects. At least it would provide some structure compared to binary patches.


Quote from: Thomas Richter;772753
Again, what is "working" for you? For me it means that I can also fix something in two years in the future. With the kind of "improvements" I see from Cosmos this is unlikely to be even possible. First of all, it doesn't really improve anything, and second, even if the results were measurable, the improvements were lost or incompatible to any other changes that had to be made.  Anyhow, make your pick. If you don't agree with me, I'm ready to leave and don't touch any of the old stuff anymore.


I hope you will continue, and accept that people have different views on contributions which clearly has good intention.
Title: Re: Layers.library V45 on the aminet
Post by: kolla on September 11, 2014, 10:24:17 AM
Quote from: Thomas Richter;772753

Again, what is "working" for you? For me it means that I can also fix something in two years in the future. With the kind of "improvements" I see from Cosmos this is unlikely to be even possible. First of all, it doesn't really improve anything, and second, even if the results were measurable, the improvements were lost or incompatible to any other changes that had to be made.  Anyhow, make your pick. If you don't agree with me, I'm ready to leave and don't touch any of the old stuff anymore.


i dont understand how unofficial patches like that of Cosmos affect any future "proper" maintainance or whatever you have in mind, or how they in any way makes anything "unmaintainable" - noone is forced to use those patches, they are totally optional and experimental, they may work perfectly for some, but not for all. it reminds me of those who think same-sex marriage somehow affect so called traditional marriage.

But oh well, you are clearly fishing for an external excuse to finally leave Amiga scene behind, which probably would be the best for everyone anyhow.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 11, 2014, 10:49:19 AM
Quote from: kolla;772762
i dont understand how unofficial patches like that of Cosmos affect any future "proper" maintainance or whatever you have in mind, or how they in any way makes anything "unmaintainable" - noone is forced to use those patches, they are totally optional and experimental, they may work perfectly for some, but not for all. it reminds me of those who think same-sex marriage somehow affect so called traditional marriage.
It's not "forcing" anyone. It means if "software X" does not work, where can we look? We have patches A,B and C, and versions D,E and F, from maintainers 1 to 6. Now, how can a developer in such an environment create a working program? You'll never know which version of the software you find, and you'll probably left with the problem of having to support several, mildly but not completely incompatible versions of a library or a software. I don't consider this a working environment.
Quote from: kolla;772762
But oh well, you are clearly fishing for an external excuse to finally leave Amiga scene behind, which probably would be the best for everyone anyhow.

I'm not fishing for an excuse. I'm asking for a honest opinion which type of protocol you prefer for developing software. In case you wonder, I left a long time ago. I'm not developing anything new here, and I will not in the future. I'm only trying to clean up, and maintain what I can maintain. If you believe that "patching" is the better way of maintaining, so might it be, and then please tell me that. I don't, and I will not offer anything like that. I prefer the official way. It may take longer, and it may be harder, but I can try. But again, you may disagree and I will respect your honest opinion. Thank you.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 11, 2014, 10:59:11 AM
Quote from: modrobert;772759
I thought about this some more last night, and in cases where no one is maintaining the source code (or where the source code indeed is lost), one solution could be disassembling the binaries (eg. with adis or resource). Make sure the source compiles OK, and then post/push that to github for everyone to enjoy, to either improve further or fork into new projects. At least it would provide some structure compared to binary patches.

Problem is, in none of the cases the source code is lost in limbo. It's all existing, probably not in perfect shape, but in a repository "somewhere". Problem is, it is not so easy to get access to it, and it is a struggle, but maybe it's worth it. I can try. I may fail. That's what I can say. Will it become accessible for everyone? Unlikely, not my decision.

Disassembly doesn't resolve the legal problems. Thus, on this basis, you cannot really place the disassembled sources somewhere and run from there maintainence of obsolete software. It doesn't work, and you put yourself and everyone participating in that in a risky situation. The only *waterproof* way of getting there - if the originals are lost indeed - is really to take the documentation, and re-implement the API as described by the documentation, from scratch, without having access to the sources. You might not like it, but these are the rules. Thus, if you want to maintain intuition, go ahead, contribute to AROS, make it as good as possible, or better than the original, then you have an "intuition" that works for everyone and satisfies your needs. That's perfectly ok for everyone. Yes, it *also* takes long. There is no easy access, I afraid.
Title: Re: Layers.library V45 on the aminet
Post by: modrobert on September 11, 2014, 11:46:36 AM
Quote from: Thomas Richter;772764
Problem is, in none of the cases the source code is lost in limbo. It's all existing, probably not in perfect shape, but in a repository "somewhere". Problem is, it is not so easy to get access to it, and it is a struggle, but maybe it's worth it. I can try. I may fail. That's what I can say. Will it become accessible for everyone? Unlikely, not my decision.

If it is all "existing" I feel confident it will become open source eventually, at least if someone like you is involved and help to push in that direction.


Quote from: Thomas Richter;772764
Disassembly doesn't resolve the legal problems. Thus, on this basis, you cannot really place the disassembled sources somewhere and run from there maintainence of obsolete software. It doesn't work, and you put yourself and everyone participating in that in a risky situation. The only *waterproof* way of getting there - if the originals are lost indeed - is really to take the documentation, and re-implement the API as described by the documentation, from scratch, without having access to the sources. You might not like it, but these are the rules. Thus, if you want to maintain intuition, go ahead, contribute to AROS, make it as good as possible, or better than the original, then you have an "intuition" that works for everyone and satisfies your needs. That's perfectly ok for everyone. Yes, it *also* takes long. There is no easy access, I afraid.

My life has always been guided by ethics rather than following specific rules/regulations, so taking a little risk can be worthwhile for the sake of the community. Anyway, I can fully understand that messing with a closed source project which is actively maintained is disrespectful to the original author(s) in the community, and for that reason should be left alone.

Legally I can only see a problem if you are living in USA (or hosting the source code in USA), and limited by the harsh laws regarding reverse engineering there. Perhaps some countries in Europe might be a bad idea to base this as well. There are plenty of ways this can be solved while remaining legal, as long as you don't limit the perspective to one country.
Title: Re: Layers.library V45 on the aminet
Post by: HyAmi on September 11, 2014, 11:51:13 AM
Quote from: Thomas Richter;772764
Problem is, in none of the cases the source code is lost in limbo. It's all existing, probably not in perfect shape, but in a repository "somewhere". Problem is, it is not so easy to get access to it, and it is a struggle, but maybe it's worth it. I can try. I may fail. That's what I can say.


Are you saying you're trying at the moment? Or just what you (or anyone else?) could do?
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 11, 2014, 12:58:52 PM
Quote from: HyAmi;772768
Are you saying you're trying at the moment? Or just what you (or anyone else?) could do?

Yes, I'm currently trying with P96. Is that good enough?
Title: Re: Layers.library V45 on the aminet
Post by: stefcep2 on September 11, 2014, 03:00:05 PM
@thomasrichter.

I appreciate your work, and your efforts to respect the legalities.  Its absolutely your call.

But I just find it incredible that after all this time that people would actually care that someone else modified-for the better- their obscure piece of code running on an archaic piece of hardware that has no practical or commercial value.

I could get any SNES ROM I ever wanted all over the net at a time when Nintendo was trying to sell versions for the Wii, and did anyone get sued?

The Amiga situation is insane.  We are just trying to have a bit of fun.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 11, 2014, 04:29:40 PM
Quote from: stefcep2;772778
I could get any SNES ROM I ever wanted all over the net at a time when Nintendo was trying to sell versions for the Wii, and did anyone get sued?

The Amiga situation is insane.  We are just trying to have a bit of fun.

Ok, time for some war-time stories. Want one? It just happened that I'm also a bit engaged in the construction of Atari emulators. The old 8-bit stuff. Another hobbyist was kind enough to provide web-space for hosting this, along with some other Atari programs he wrote, all old stuff. Now it happened that Atari (not the original company, but some French? publisher that accuiquired the rights on the name "Atari") was a bit short of money and send legal claims to any holder of any web site that seemed to hold (in the views of their lawers) "illegal pirated Atari content". Now, for this specific web site, nothing illegal was around, provably, so the mentioned Hobbyist got away, but it was quite some hassle. If that happens, you *definitely* need to call a lawer and pay him some money, just for the required legal action.  

No, you *do not* want to go through this, and throw money behind lawers just because you have an unofficial, non-licenced logo of a corrupt company on your website. These types of "fun" are just an open invitation to any company short of money to collect some cash for nothing.  

So yes, you must be careful these days.
Title: Re: Layers.library V45 on the aminet
Post by: modrobert on September 11, 2014, 04:38:20 PM
I have another war story; some guy made a bet on IRC that he could host the Amiga Kickstart ROMs on a web server, free for anyone to download, and he did just that for a year without complications, until the domain hosting ran out.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 11, 2014, 05:03:41 PM
Quote from: modrobert;772784
I have another war story; some guy made a bet on IRC that he could host the Amiga Kickstart ROMs on a web server, free for anyone to download, and he did just that for a year without complications, until the domain hosting ran out.

Ok, here's an offer. Provided I compile a binary version of P96, will you host it and will you indemnify me from any legal claim? Written contract, signed, by both parties?
Title: Re: Layers.library V45 on the aminet
Post by: modrobert on September 11, 2014, 05:27:24 PM
Quote from: Thomas Richter;772785
Ok, here's an offer. Provided I compile a binary version of P96, will you host it and will you indemnify me from any legal claim? Written contract, signed, by both parties?

I can host the file, but you can forget any contract, because it would be invalid to indemnify you in this case.

Besides, if you really wanted this file hosted somewhere, you could easily have done that without any legal risk by simply remaining anonymous and upload to any free file hosting service out there. This was just some lame attempt to prove a point, sorry, it failed.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 11, 2014, 05:58:27 PM
Quote from: modrobert;772786
This was just some lame attempt to prove a point, sorry, it failed.

Why, it worked quite well. If you don't want to take the risk, why should I?

Anyhow, I guess you understand the point.
Title: Re: Layers.library V45 on the aminet
Post by: modrobert on September 11, 2014, 06:19:28 PM
Quote from: Thomas Richter;772790
Why, it worked quite well. If you don't want to take the risk, why should I?

Anyhow, I guess you understand the point.

If it was possible to indemnify against a lawsuit every corporation out there would hire some poor drug addict to take the legal responsibility for their actions, it doesn't work this way, fortunately.

EDIT:

Apparently it is possible indemnify against copyright lawsuits regarding software in some countries, my mistake. In a way this proves what a crappy racket the copyright legal system can be ethically, creating misery for any poor bastard who happened to sign a paper, probably a system created by lawyers to earn fees as well. Anyway, in this case it would be meaningless since copyright laws where my company resides in Thailand only applies to domestic software.
Title: Re: Layers.library V45 on the aminet
Post by: Thorham on September 11, 2014, 06:42:19 PM
Quote from: stefcep2;772778
that has no practical or commercial value.
No practical value? Tell that to people who use A1200s with 68030s as their main machine. No practical value :lol:
Title: Re: Layers.library V45 on the aminet
Post by: pawelek on September 11, 2014, 08:09:16 PM
Bug in layers?
With layers.library 45.19 when I quit (close) program AmiTradeCenter is suspended and an error #8000000x

with layers 40.1 is all OK.
Title: Re: Layers.library V45 on the aminet
Post by: psxphill on September 11, 2014, 08:45:42 PM
Quote from: modrobert;772786
I can host the file, but you can forget any contract, because it would be invalid to indemnify you in this case.

Why would it be invalid? He purely asked you to provide indemnity insurance, which is "a thing".

http://en.wikipedia.org/wiki/Indemnity

Quote from: modrobert;772791
If it was possible to indemnify against a lawsuit every corporation out there would hire some poor drug addict to take the legal responsibility for their actions, it doesn't work this way, fortunately.

You can indemnify against anything, if someone is willing to take the risk on you. But the insurance is only worth something if they would pay out.
 
 Why would you rely on a poor drug addict to indemnify you knowing they couldn't? He wouldn't be able to pay up and you would still owe the money. It's much better to get insurance from a company that would pay out, usually they will check to make sure you're not doing anything stupidly illegal up front though.

You appear to not understand what you are talking about.
Title: Re: Layers.library V45 on the aminet
Post by: modrobert on September 11, 2014, 09:29:53 PM
Quote from: psxphill;772800
Why would it be invalid? He purely asked you to provide indemnity insurance, which is "a thing".

As I already mentioned in the "EDIT:" part of the post which was written long before your post (check time).


Quote from: psxphill;772800
He wouldn't be able to pay up and you would still owe the money.

So, Thomas Richter just have to trust that I'm good for the money then, hehe.


Quote from: psxphill;772800
You can indemnify against anything, if someone is willing to take the risk on you.

Any kind of crime...really? No wonder the white collar criminals rarely get caught.
Title: Re: Layers.library V45 on the aminet
Post by: stefcep2 on September 12, 2014, 01:49:52 AM
Quote from: Thomas Richter;772785
Ok, here's an offer. Provided I compile a binary version of P96, will you host it and will you indemnify me from any legal claim? Written contract, signed, by both parties?



Hypothetically speaking what could the author claim?

The software is freely available is it not?  What money have they lost?

You didn't make any money from it either.

And you *improved* it.

If he's concerned that your version may introduce defects and his name being associated with it may sully his reputation then that's simple enough to fix in a read.me
Title: Re: Layers.library V45 on the aminet
Post by: Gulliver on September 12, 2014, 05:28:47 AM
Quote from: stefcep2;772807
Hypothetically speaking what could the author claim?


He could claim out loud:_Heresy! You should have contacted me because you are disrespecting the work I no longer give a f*ck about_

And then you could be casted away from Amigaland for you unprofessional "coder" behaviour.

Oh, shame on you!
Title: Re: Layers.library V45 on the aminet
Post by: Heiroglyph on September 12, 2014, 06:15:54 AM
@Thomas:
I just want to say thanks for the update.  That video really drives home what an improvement it is. That's nothing short of amazing.

I may not agree with your point of view on other peoples abandoned software, but I can certainly respect your point of view.

I just wish every thread didn't degrade into this mess and hope your thick skin holds up, we need all the help we can get.

@Thread:
Could we possibly get the thread back on track of discussing the actual library, it's performance and bugs?

I'm guilty too (see Cosmos thread) but come on guys, he's devoting his time to helping us all out, show some respect and start a different thread to debate in.
Title: Re: Layers.library V45 on the aminet
Post by: psxphill on September 12, 2014, 09:44:06 AM
Quote from: modrobert;772803
So, Thomas Richter just have to trust that I'm good for the money then, hehe.

He could sue you for breach of contract if you didn't pay out. If you own nothing and have no income then being sued is not a major problem.

Quote from: modrobert;772803
Any kind of crime...really? No wonder the white collar criminals rarely get caught.

You still misunderstand, it wouldn't stop you getting caught. It only covers your expenses if you were caught. Generally it's only going to cover civil law rather than criminal law (where you end up in prison).
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 12, 2014, 10:14:12 AM
Quote from: psxphill;772829
He could sue you for breach of contract if you didn't pay out. If you own nothing and have no income then being sued is not a major problem.



You still misunderstand, it wouldn't stop you getting caught. It only covers your expenses if you were caught. Generally it's only going to cover civil law rather than criminal law (where you end up in prison).


As far as I know patches are legal as long as you do not distribute a modified version of the original. The aminet is full of those. I also do not really see the problem, people are not forced to use them and as Thomas said noone is developing on the platform anymore (except that he wants to make some bugfixes). From a technical point of view he is certainly right but it is basically a abandoned platform. I think both sides have shared their opinion and we should stop that topic here and return to the topic of the thread.
Title: Re: Layers.library V45 on the aminet
Post by: HyAmi on September 12, 2014, 10:50:25 AM
Quote from: Thomas Richter;772771
Yes, I'm currently trying with P96. Is that good enough?


Yes, definitely! I hope you succeed.
btw; my question wasn't meant to be skeptical.
Title: Re: Layers.library V45 on the aminet
Post by: psxphill on September 12, 2014, 02:08:46 PM
Quote from: OlafS3;772831
I also do not really see the problem, people are not forced to use them.

That is the problem, you're fracturing the user base.
 cosmos isn't just fixing bugs, he's changing fundamental behaviour as he sees fit. This will make software work differently. If someone does come along and starts writing applications for the amiga then it's going to be a nightmare to make sure it's compatible with all the different hacks.
 
 Getting people on the same page was one of the reasons for OS3.5 & 3.9 in the first place.
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 12, 2014, 02:48:24 PM
Quote from: psxphill;772838
That is the problem, you're fracturing the user base.
 cosmos isn't just fixing bugs, he's changing fundamental behaviour as he sees fit. This will make software work differently. If someone does come along and starts writing applications for the amiga then it's going to be a nightmare to make sure it's compatible with all the different hacks.
 
 Getting people on the same page was one of the reasons for OS3.5 & 3.9 in the first place.

Fixing bugs is ok, making it faster is ok, adding new functions is already a little problematic, changing behaviour of existing functions is very problematic indeed. It makes testing much more difficult. Perhaps Cosmos and others should do their own shared libraries?

On the other hand, you cannot do anything against it and people are responsible for themselves. People know that Patches are risky and make everything less compatible (or at least can).
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 12, 2014, 03:29:11 PM
Quote from: OlafS3;772841
Fixing bugs is ok, making it faster is ok, adding new functions is already a little problematic, changing behaviour of existing functions is very problematic indeed. It makes testing much more difficult. Perhaps Cosmos and others should do their own shared libraries?
That is pretty much my central point, and I thank you for mentioning it. I wouldn't have such a big problem if the library interface would either not change, or the library would get a different name, or the changes would be at least coordinated with the Os 4 development team.

As far as layers is concerned: The point is here that the interface was extended, but this was coordinated with Os 4 (in fact, the interface is a subset of the Os 4 interface), and this was also one of the promises I had to make to get it published, i.e. "make sure there is a clear development line". In fact, it is. V45 layers is mid-point between v40 and the Os 4 one.
Title: Re: Layers.library V45 on the aminet
Post by: kolla on September 12, 2014, 04:29:33 PM
There is no official way, whoever wants to do something with AmigaOS for m68k are free to do so, offering patches like Cosmos is doing is perfectly legal and I prefer that people like you stop pretending that it is not. You say you will try to clean up things and do it the proper way - well, then quit talking about it already, and do it, and then show the community what you have managed. You have had 15 years already, dont expect us to quietly sit here doing nothing, we are all getting old and gray while you are "trying". You have been told many times, over and over, that the community prefers open source. You have made it clear that you are scared of open sourcing AmigaOS components, you do not trust the community, you look at us as unworthy and uncapable. What a shame that you are such a wuss. You have also made it clear that you are no longer developing, only maybe fixing a bug here and there if you feel like it. You are not advocating a protocol for development, that is a protocol for stand still.
Title: Re: Layers.library V45 on the aminet
Post by: biggun on September 12, 2014, 04:36:36 PM
Some people should better know when to shut up.
Title: Re: Layers.library V45 on the aminet
Post by: kolla on September 12, 2014, 04:38:28 PM
Quote from: psxphill;772838
If someone does come along and starts writing applications for the amiga then it's going to be a nightmare to make sure it's compatible with all the different hacks.

First or all, that is a huge IF, and secondly, no, it is no more a nightmare than what we have had the last 20 years now.
 
Quote
Getting people on the same page was one of the reasons for OS3.5 & 3.9 in the first place.

In that respect they were total failures :)
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 12, 2014, 04:51:22 PM
Quote from: kolla;772843
There is no official way, whoever wants to do something with AmigaOS for m68k are free to do so, offering patches like Cosmos is doing is perfectly legal and I prefer that people like you stop pretending that it is not. You say you will try to clean up things and do it the proper way - well, then quit talking about it already, and do it, and then show the community what you have managed. You have had 15 years already, dont expect us to quietly sit here doing nothing, we are all getting old and gray while you are "trying". You have been told many times, over and over, that the community prefers open source. You have made it clear that you are scared of open sourcing AmigaOS components, you do not trust the community, you look at us as unworthy and uncapable. What a shame that you are such a wuss. You have also made it clear that you are no longer developing, only maybe fixing a bug here and there if you feel like it. You are not advocating a protocol for development, that is a protocol for stand still.

The community prefers open source? Really? Where is the help regarding Aros 68k? I read lots of excuses why not helping but noone jumping in.

Thomas has said that people should either do their own library or at least not change the existing API. That sounds reasonable to me.
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 12, 2014, 04:57:41 PM
Quote from: kolla;772845
First or all, that is a huge IF, and secondly, no, it is no more a nightmare than what we have had the last 20 years now.
 


In that respect they were total failures :)

Perhaps there are reasons why standards are defined, don´t you think? Microsoft f.e. develops new .NET versions but it is still compatible to prior versions. Developers would jump on their heads if they would "patch" the API all the time. I do not want to compare the situation but it makes sense not to change existing API (even if you think to have good reasons for it) because it might lead to strange errors that are difficult to find for the software developers (who has not installed the patch). "If" you change the API then either add something or do your own library.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 12, 2014, 05:31:48 PM
Quote from: kolla;772843
There is no official way, whoever wants to do something with AmigaOS for m68k are free to do so, offering patches like Cosmos is doing is perfectly legal and I prefer that people like you stop pretending that it is not.  
Once again: If I release the binaries of P96, will you host it and indemnify me?  
Quote from: kolla;772843
You say you will try to clean up things and do it the proper way - well, then quit talking about it already, and do it, and then show the community what you have managed.
Sorry, but I think I did. To my very knowledge, you've a pile of freeware I released to Aminet, you received a new Shell for 3.9, and three updates to that, you received a new Console for 3.9, you received an Update to BenchTrash all the way. I also released updated MMULibs, a new 68060.library because Matthew found a bug. I'm sorry, but I believe I contributed my share. I also believe that I *do* fix bugs when I find them. So please, don't be overly harsh.  
Quote from: kolla;772843
 You have had 15 years already, dont expect us to quietly sit here doing nothing
No. I expect you to do the *right* thing. There are three branches of AmigaOs where you could contribute. Os 4.0, Morphos and Aros. Now, please take your pick. Or you can also try to talk to owners whether releases are possible, a forth possibility. As you can see from the very theme of this thread, I did this and I succeeded. For one library. Apparently, you're still demanding more. It's a slow going, what exactly do you expect? And what exactly have you contributed?  
Quote from: kolla;772843
We are all getting old and gray while you are "trying".  
Then, with all respect, get *your* arse up, man. You want open source, you know what to do. Right in front of your face. All you need to do is to handle the Aros software, update it, and contribute to it. Where is your problem?  
Quote from: kolla;772843
You have been told many times, over and over, that the community prefers open source.  
That's perfectly fine, but I'm not paid by the community. I can only tell you what *you* need to do if *you* want open source. You need to write open source. Yes, it is *really* that simple. Look, what you're basically telling me is that I should work for you for no cost, and should give everything away for no money, so you don't have to work, and you define how I should work, and under which conditions. Please, make a reality check. As long as I write maintain my software, please understand that as long as you don't contribute, it's my role to define the conditions under which I work. If you want other conditions, there are possibilities. I already told you.    
Quote from: kolla;772843
You have made it clear that you are scared of open sourcing AmigaOS components, you do not trust the community, you look at us as unworthy and uncapable. What a shame that you are such a wuss. You have also made it clear that you are no longer developing, only maybe fixing a bug here and there if you feel like it. You are not advocating a protocol for development, that is a protocol for stand still.

There are *three* protocols for development I'm advocating. Please pick one. I have personally other preferences in my life than AmigaOs, so please count me out. I can answer questions, but I won't write software anymore. What I promise is that I take the responsibility for the stuff I wrote serious, and you should at least try to appreciate that this is a lot more than you get from most other people in the AmigaOs scene.
Title: Re: Layers.library V45 on the aminet
Post by: Minuous on September 12, 2014, 06:14:55 PM
>The community prefers open source? Really? Where is the help regarding Aros 68k? I read lots of excuses why not helping but noone jumping in.

I'm interested in working on the proper AmigaOS, not some half-baked clone of it. Probably others feel the same way. Why spend years coding all the missing functionality into AROS just to get us to the point we are already at with OS3.9?

>There are three branches of AmigaOs where you could contribute. Os 4.0, Morphos and Aros. Now, please take your pick.

OS4 and MOS are not open source, and their developers probably wouldn't welcome unsolicited binary patches. So I'm not sure how people are supposed to contribute to them.

>Or you can also try to talk to owners whether releases are possible, a forth possibility. As you can see from the very theme of this thread, I did this and I succeeded. For one library. Apparently, you're still demanding more. It's a slow going, what exactly do you expect?

It might be possible to get sources to a few components by this method, and I certainly do appreciate the effort you are making, but it is never going to lead to full sources for the whole OS. The only realistic method for achieving this is a H&P bounty for the release of OS3.9 sources.
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 12, 2014, 06:21:33 PM
Quote from: Minuous;772852
>The community prefers open source? Really? Where is the help regarding Aros 68k? I read lots of excuses why not helping but noone jumping in.

I'm interested in working on the proper AmigaOS, not some half-baked clone of it. Probably others feel the same way. Why spend years coding all the missing functionality into AROS just to get us to the point we are already at with OS3.9?

>There are three branches of AmigaOs where you could contribute. Os 4.0, Morphos and Aros. Now, please take your pick.

OS4 and MOS are not open source, and their developers probably wouldn't welcome unsolicited binary patches. So I'm not sure how people are supposed to contribute to them.

>Or you can also try to talk to owners whether releases are possible, a forth possibility. As you can see from the very theme of this thread, I did this and I succeeded. For one library. Apparently, you're still demanding more. It's a slow going, what exactly do you expect?

It might be possible to get sources to a few components by this method, and I certainly do appreciate the effort you are making, but it is never going to lead to full sources for the whole OS. The only realistic method for achieving this is a H&P bounty for the release of OS3.9 sources.

It is NOT a halfbaked clone how you call it. I say you have never really used my distribution and are just throwing phrases. And to be honest I do not care about classic hardware anymore and will not push in that direction anymore. Be happy with your 3.9 (or whatelse)...
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 12, 2014, 06:34:12 PM
Quote from: Minuous;772852
I'm interested in working on the proper AmigaOS, not some half-baked clone of it.  
But then make it less half-baked by contributing to it. That's the spirit of open source! Doesn't work how you like it? Change it!  
Quote from: Minuous;772852
Probably others feel the same way. Why spend years coding all the missing functionality into AROS just to get us to the point we are already at with OS3.9?
Because you can't have one without the other. Essentially, you're saying "I want what you have, for free, so I can play with it". If you want it for free, you need to work for free. What do you think?  
Quote from: Minuous;772852
OS4 and MOS are not open source, and their developers probably wouldn't welcome unsolicited binary patches. So I'm not sure how people are supposed to contribute to them.
No serious developer welcomes unsolicitated binary patches. But if you want to contribute, at least for Os 4 there is a contact form on their web page. Guess what, I used exactly that. I'm not aware of any other or better method, but maybe there are. I'm pretty sure you also find a contact form for Morphos. You need to talk to the people and offer your service. The result will not be open source, though. You'll probably need to sign a NDA or some other form of contract. But again, if you want something somebody else spend a lot of time and sweat in building, you shouldn't expect to get this for free. Or only if you *also* invest the same amount of work. Yes, it is *really* that simple.

Nothing is for free in this universe. You can either pay money, or you can pay with your work. One is commercial software, the other open source. Make your pick. I'm not even advocating one or the other. I'm just saying that your demand is quite unrealistic.  
Quote from: Minuous;772852
It might be possible to get sources to a few components by this method, and I certainly do appreciate the effort you are making, but it is never going to lead to full sources for the whole OS. The only realistic method for achieving this is a H&P bounty for the release of OS3.9 sources.

Well, then set this up if you think this is going to work. I don't know how much you're going to pay for that, but if you can pay out Animo and/or H&P, and the developers that contributed to 3.9, that may also work. I don't know how much they would ask for (or whether they would be even willing to contribute), but I can at least ensure you that I'm personally not so much interested in the money itself. I would prefer a different development model, a more open one maybe, but not necessarily the "everything is for free for everyone". But that's a different story.

One way or another, you won't reach your goal by complaining here. The most realistic approach for *your goal*,i.e. Open Source AmigaOs, is really to start programming on AROS.
Title: Re: Layers.library V45 on the aminet
Post by: Minuous on September 12, 2014, 07:07:56 PM
>But then make it less half-baked by contributing to it.

I don't see the point of rewriting ReAction, Installer and all the rest from scratch when I already have them...I don't really have time to do that and write applications too. Even if I did, there's no reason to think they would get put into AROS, as it seems fairly clear that they are MUI zealots, standards be damned. Plus even a complete reimplementation would still be just a reimplementation, not the real thing.

>You need to talk to the people and offer your service. The result will not be open source, though. You'll probably need to sign a NDA or some other form of contract.  Or only if you *also* invest the same amount of work. Yes, it is *really* that simple.

Why would anyone want to do unpaid work on a piece of closed-source commercial software which is still being sold!? In the case of OS4 I don't even have a machine that will run it (not having a spare $5000 or so lying around), so it's out of the question. And as you point out, the result still would not be open source.

>I'm just saying that your demand is quite unrealistic.  
>But again, if you want something somebody else spend a lot of time and sweat in building, you shouldn't expect to get this for free.

I'm not demanding anything, what am I expecting to get for free? I have pointed out some of what's missing from AROS which keeps me on OS3.9, from a user perspective. I'm not demanding anyone else implement this, it seems obvious after 15 years that it won't be implemented. They're wondering why people don't want to use AROS, and I'm giving them the answer. As simple as that. Surely I have the right to say why I don't use something without having to volunteer years of unpaid labour on a piece of software I don't even like. By that logic, if I say why I don't like Windows, I have to go do unpaid work for Microsoft.

>Well, then set this up if you think this is going to work. I don't know how much you're going to pay for that, but if you can pay out Animo and/or H&P, and the developers that contributed to 3.9, that may also work.

I wouldn't be able to contribute much but I would certainly put some money towards such a bounty. I don't know whether I would be the best one to negotiate with them on the community's behalf though. I'd rather such an important bounty be managed by someone who has already a proven track record of managing bounties, if that's at all possible.

More on topic, I can confirm the incompatibility of Birdie with the new layers.library. Do you know which of the two components is to blame?
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 12, 2014, 07:39:42 PM
@minous
i see you want to have a cake and eat it too. what concerns amiga operating systems none is open source, not os4 nor mos but neither the original one. that leaves you with aros or nothing im sorry. this is why i have chosen aros, because there was no alternative to contribute. we can discuss it to death but i dont see anything else happening, none will open source amiga system, none will probably even answer to such enquiries, none will establish a bounty and almost none will contribute to it. lets live with it.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 12, 2014, 07:56:21 PM
Quote from: Minuous;772857
I don't see the point of rewriting ReAction, Installer and all the rest from scratch when I already have them...
But you already made the point...??? If you want it open source, that's the only way that is going to work. Is this really so hard to understand?
Quote from: Minuous;772857
I don't really have time to do that and write applications too.  
But you expect others that they make their work available for free and invest this time? How charming...
Quote from: Minuous;772857
Even if I did, there's no reason to think they would get put into AROS, as it seems fairly clear that they are MUI zealots, standards be damned.  
Drawback of open source. You cannot have an "open source that works only how you want it to work". That's a closed source model.
Quote from: Minuous;772857
Plus even a complete reimplementation would still be just a reimplementation, not the real thing.
What's unreal about a re-implementation?
Quote from: Minuous;772857
Why would anyone want to do unpaid work on a piece of closed-source commercial software which is still being sold!?  
Why would you want to do unpaid work on closed-source commercial software that runs on obsolete hardware? This is neither logical.

Look, it's really all a matter of perspective. You should understand that your demands are not even self-consistent. Step back, think a while about your priorities and what your goals are, pick your decision within the available constraints.
Quote from: Minuous;772857
I'm not demanding anything, what am I expecting to get for free? I have pointed out some of what's missing from AROS which keeps me on OS3.9, from a user perspective. I'm not demanding anyone else implement this, it seems obvious after 15 years that it won't be implemented. They're wondering why people don't want to use AROS, and I'm giving them the answer. As simple as that.  
But then it's your turn to change it. Why don't you implement the missing bits and pieces, after all? If you want a challenge, it's right in front of you. You refuse to contribute because it's not complete enough to compete with 3.9? With that logic, nothing will ever get done because nothing will ever become complete, it's a completely circular argument. It's actually not different with commercial software. At some point, you need to get your arse up and start, no matter how incomplete it is.  
Quote from: Minuous;772857
Surely I have the right to say why I don't use something without having to volunteer years of unpaid labour on a piece of software I don't even like. By that logic, if I say why I don't like Windows, I have to go do unpaid work for Microsoft.
No, by that logic you can either buy another product, or contribute to a product that allows contribution. You can buy Apple, you can contribute to Linux. Same difference. If you want to *contribute* to Windows, well, that's going to be harder - seek employment at Microsoft. But it is no option that Microsoft will release the windows source-code for free, to allow you playing with it. Won't happen. It's their source, they define the rules. You don't like the rules? Pick another product. Your choice. Quite the same here: You don't like Os 4 as a product? Pick another one. The owner does not allow open source? Ok, their product, their rules. Want other rules? Pick another product. You have all the options right in front of your table, you only have to make your pick.  
Quote from: Minuous;772857
More on topic, I can confirm the incompatibility of Birdie with the new layers.library. Do you know which of the two components is to blame?

Birdie goes into the internals of layers, and these had to change slightly - the external API works the same, though. Layers pools now many of its structures, to avoid the "fragmentation bomb" older versions threw at the system for their "slice and dice" implementation. As soon as a program modifies internal layer structures by bypassing layers, this is going to be a problem.  

As far as Birdie is concerned: I don't have a contact to its author. Do you? Does anyone in the community have?  

Essentially, Birdie provides a functionality that would require integration into intuition - not layers, as layers doesn't even draw anything, it only clears out layers optionally by a backfill-hook. Layer is rather the "victim" here as it provides some information on when intuition performs its activity.

One way or another, I don't think that Birdie is an essential miss. It's only eyecandy.
Title: Re: Layers.library V45 on the aminet
Post by: modrobert on September 12, 2014, 08:05:09 PM
Quote from: Minuous;772852
The only realistic method for achieving this is a H&P bounty for the release of OS3.9 sources.


Great idea. OS3.1 as well. Open source or die (trying)!

BTW: I'm typing this on my A1200, so no more recommendations to use Aros, that's best suited for a PC.


PS:

Have a good weekend everyone, especially those who disagree. High time to turn up the volume in HippoPlayer, goose bumps galore. Nothing really beats Amiga, does it? ;)
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 12, 2014, 08:07:31 PM
Quote from: Thomas Richter;772860
Drawback of open source. You cannot have an "open source that works only how you want it to work". That's a closed source model.

as if closed source software behaved always as the user expects..
Title: Re: Layers.library V45 on the aminet
Post by: BSzili on September 12, 2014, 08:10:41 PM
Quote from: Minuous;772857
I don't see the point of rewriting ReAction, Installer and all the rest from scratch when I already have them...I don't really have time to do that and write applications too. Even if I did, there's no reason to think they would get put into AROS, as it seems fairly clear that they are MUI zealots, standards be damned. Plus even a complete reimplementation would still be just a reimplementation, not the real thing.
I understand why you aren't interested in rewriting the ReAction classes, I also get why aren't you wouldn't want anything besides the real thing®, but could you please refrain from making these baseless allegations? There have been interest from many AROS developers for an open source ReAction reimplementation, but no one was interested in writing them.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 12, 2014, 08:15:00 PM
Quote from: wawrzon;772862
as if closed source software behaved always as the user expects..

Sorry, but you don't get my point. A model where "one person defines how it works", is a closed source model. If the makers of AROS prefer MUI, then that's it. If *I* want something else, and I want nobody to talk into my decisions, I have to run my software as closed source. That's then the only option. Of course, the resulting software might still not work as its users want it to work, but at least it works how I want it...
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 12, 2014, 09:16:13 PM
Quote from: Thomas Richter;772865
Sorry, but you don't get my point. A model where "one person defines how it works", is a closed source model. If the makers of AROS prefer MUI, then that's it. If *I* want something else, and I want nobody to talk into my decisions, I have to run my software as closed source. That's then the only option. Of course, the resulting software might still not work as its users want it to work, but at least it works how I want it...


quite contrary it seems, if aros devs prefer zune you are still free to introduce reaction yourself, if os4 devs do not want zune then thats it, the user has to live with it.
Title: Re: Layers.library V45 on the aminet
Post by: yssing on September 12, 2014, 09:23:01 PM
So this awesome update is released, it is just awesome that new stuff are being published for our aging classics.!

I fail to see why some guys need to be so negative about updates, if you don't like updates, don't install them.
Title: Re: Layers.library V45 on the aminet
Post by: psxphill on September 12, 2014, 10:04:39 PM
Quote from: wawrzon;772867
quite contrary it seems, if aros devs prefer zune you are still free to introduce reaction yourself, if os4 devs do not want zune then thats it, the user has to live with it.

You're still missing his point, but I'm now more interested in how os4 devs could stop you running zune?
 
 
Quote from: yssing;772868
I fail to see why some guys need to be so negative about updates, if you don't like updates, don't install them.

If someone graffiti's your house and you don't like it, then you don't have to look at it.
Title: Re: Layers.library V45 on the aminet
Post by: Gulliver on September 12, 2014, 10:29:33 PM
Quote from: psxphill;772871
If someone graffiti's your house and you don't like it, then you don't have to look at it.


They don´t graffiti your house, they just offer the service, it is upto you to decide if you want to. The service is still there, but it is optional ;)
Title: Re: Layers.library V45 on the aminet
Post by: psxphill on September 12, 2014, 10:50:23 PM
Quote from: Gulliver;772874
They don´t graffiti your house, they just offer the service, it is upto you to decide if you want to. The service is still there, but it is optional ;)

No, you agreed to it without realising what it was you were signing up for.
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 12, 2014, 10:52:47 PM
Quote from: Minuous;772857
>But then make it less half-baked by contributing to it.

I don't see the point of rewriting ReAction, Installer and all the rest from scratch when I already have them...I don't really have time to do that and write applications too. Even if I did, there's no reason to think they would get put into AROS, as it seems fairly clear that they are MUI zealots, standards be damned. Plus even a complete reimplementation would still be just a reimplementation, not the real thing.

>You need to talk to the people and offer your service. The result will not be open source, though. You'll probably need to sign a NDA or some other form of contract.  Or only if you *also* invest the same amount of work. Yes, it is *really* that simple.

Why would anyone want to do unpaid work on a piece of closed-source commercial software which is still being sold!? In the case of OS4 I don't even have a machine that will run it (not having a spare $5000 or so lying around), so it's out of the question. And as you point out, the result still would not be open source.

>I'm just saying that your demand is quite unrealistic.  
>But again, if you want something somebody else spend a lot of time and sweat in building, you shouldn't expect to get this for free.

I'm not demanding anything, what am I expecting to get for free? I have pointed out some of what's missing from AROS which keeps me on OS3.9, from a user perspective. I'm not demanding anyone else implement this, it seems obvious after 15 years that it won't be implemented. They're wondering why people don't want to use AROS, and I'm giving them the answer. As simple as that. Surely I have the right to say why I don't use something without having to volunteer years of unpaid labour on a piece of software I don't even like. By that logic, if I say why I don't like Windows, I have to go do unpaid work for Microsoft.

>Well, then set this up if you think this is going to work. I don't know how much you're going to pay for that, but if you can pay out Animo and/or H&P, and the developers that contributed to 3.9, that may also work.

I wouldn't be able to contribute much but I would certainly put some money towards such a bounty. I don't know whether I would be the best one to negotiate with them on the community's behalf though. I'd rather such an important bounty be managed by someone who has already a proven track record of managing bounties, if that's at all possible.

More on topic, I can confirm the incompatibility of Birdie with the new layers.library. Do you know which of the two components is to blame?


I do not understand again what you are saying. As long as we talk about Aros 68k (and this thread is about 68k) you do NOT need to reimplement installer because you simple copy it in C and it works. And on the same way you can add ClassAct (I have not tested Reaction because it is not free). And you can add MUi 38, the same way, and BGUI and ... that is how I created my distribution. Aros 68k on its base (minus Desktop) is reimplementation of a core 3.1. installation including Roms and AHI, CybergraphX 3, Intuition, Gadtools, dos.library and so on. You can easily replace Zune, you can use another desktop, you can do almost everything with it. It is not devil, not "ugly" how you called it. I do not understand your attitude and why you do not react on other comments. You said everything is missing and I asked you to name a few of what is missing. I still await the answer.
Title: Re: Layers.library V45 on the aminet
Post by: warpdesign on September 12, 2014, 11:51:20 PM
Quote
A model where "one person defines how it works", is a closed source model.

I didn't know the Linux kernel was closed source ;)

It's been open source since day one. And Linus has been defining how it should work since
1994. This doesn't prevent lots of unofficial patches, forks,.. though as well as lots of official fixes, patches,.. That were contributed by how many devs ? A hundred ? Yet, only one person decides. This wouldn't have been possible if it had been closed source...

You may decide and stay opened... At least outside of the Amiga circle. I'm not sure this is possible here: most open source projects lack direction/guidance. And lots of people still deciding would rather see their software die rather than risking loosing control and.. Ownership.
Title: Re: Layers.library V45 on the aminet
Post by: Gulliver on September 13, 2014, 12:24:15 AM
Quote from: psxphill;772876
No, you agreed to it without realising what it was you were signing up for.


Then you should better start reading the readme files, they are not there to occupy space ;)

Unless, there is some truth in that there is a secret coven of devilish coders that fool users into installing things that are said to be rock solid and fool proof when they are exclusively created to pervert their soul (and miggy systems) ;)
Title: Re: Layers.library V45 on the aminet
Post by: Thorham on September 13, 2014, 02:57:59 AM
Quote from: yssing;772868
I fail to see why some guys need to be so negative about updates, if you don't like updates, don't install them.
Exactly. Someone updates a system library, and everyone and their cat has an opinion about it.

Quote from: psxphill;772871
If someone graffiti's your house and you don't like it, then you don't have to look at it.
I suppose that means you don't like PeterK's icon.library, either?
Title: Re: Layers.library V45 on the aminet
Post by: Minuous on September 13, 2014, 03:50:00 AM
>But you expect others that they make their work available for free and invest this time? How charming...

Where have I said that I expect this? I don't want anything for free. All my programs are already open source freeware. I don't have unlimited time/motivation for coding, if I work on one thing, it comes at the expense of working on another thing.

I'm not an AROS developer and I don't want to be an AROS developer. Same goes for MOS and OS4. (I'm speaking of OS development here, not application development.) Reimplementing the same things 4 times for 4 similar-but-different OSes doesn't seem a very efficient way of moving things forwards.

>But then it's your turn to change it. Why don't you implement the missing bits and pieces, after all?

I suppose I could answer every bug report I get about my software in this manner: "It's open source, fix it yourself."

>No, by that logic you can either buy another product

Yes, I bought OS3.9.

>What's unreal about a re-implementation?

Neither the source nor the binary would be the same. The handling of undocumented functionality would also probably be erroneous. Unless one was to look at a disassembled AmigaOS to confirm, which is not allowed when reverse engineering. Additionally, a release of official AmigaOS source would be more likely to gain interest and/or attention from the wider (non-Amiga) community.

>Why would you want to do unpaid work on closed-source commercial software that runs on obsolete hardware? This is neither logical.

Well, not to get rich, that's for sure. But it makes more sense than working on OS4/MOS, at least no one would be making money off my hard work.

>If the makers of AROS prefer MUI, then that's it.

Fine, they should stop pretending it's somehow equivalent to the official AmigaOS though. And I certainly am not interested in using, let alone developing, such a program.

>none will open source amiga system, none will probably even answer to such enquiries, none will establish a bounty and almost none will contribute to it.

Why do you say this? There have been many successful bounties to open source Amiga applications, eg. DOpus. Surely it is at least worth making the attempt before giving up.

>But it is no option that Microsoft will release the windows source-code for free

Where did I suggest H&P release OS3.9 source for free? Obviously that would be a good outcome but hardly likely. Which is why I proposed a bounty. And yes, as I said, I'm willing to make a contribution to such a bounty. How is this wanting something for free?

>It is not devil, not "ugly" how you called it. I do not understand your attitude and why you do not react on other comments. You said everything is missing and I asked you to name a few of what is missing. I still await the answer.

Has someone redrawn those atrocious icons by now then? As for what's missing, the answer is most of OS3.5/3.9.

AROS is not the devil, just not something that is of any use to me. And I would not normally do development of software that I do not even use. Surely most contributors to open source projects are the same.

>if aros devs prefer zune you are still free to introduce reaction yourself,

Fork AROS? Then we have 5 Amiga-like OSes instead of 4, hardly an improvement.

>As far as Birdie is concerned: I don't have a contact to its author. Do you?

No, he doesn't seem to be active any more. This is probably a case where a Cosmos-style patch (to Birdie, not layers.library) would be useful.
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 13, 2014, 09:17:35 AM
Quote from: Minuous;772894
Why do you say this? There have been many successful bounties to open source Amiga applications, eg. DOpus. Surely it is at least worth making the attempt before giving up.
there were some successful larger aros bounties (open sourcing poseidon usb stack) and two or three other bigger bounties (dopus magellan and odyssey), all organized by people whom you are arguing against, olaf as example. the bounties were successful because the people in question actually did something instead of bragging and demanding. and remember magellan bounty has not been met. the owners agreed to lesser amount. and now you are talking abut the bounty for whole operating system. it will not be another ten thousand dollar bounty im sure. if it was i might have been interested few years ago when there might have been enough people to support it. anyways if you want to risk money parked on some account for years, go for it and try, but judging by this thread alone there isnt much interest anymore.
Quote
Has someone redrawn those atrocious icons by now then?
i took a shot at it, as well as an iff theme that works well on planar gfx. theme is about half done and proven working, but there is bugs in themeing i had to wait to be fixed but none did. maybe matthias is about to do it now. i dont know. i did some research to find an appropriate icon convention too, but after some basics i have lost motivation for now. takes much more time than just posting in forums, which is what people are primarly interested in so why really bother.
Quote
Fork AROS? Then we have 5 Amiga-like OSes instead of 4, hardly an improvement.

why fork? you can just contribute the missing classes and mui and reaction programs will work fine side by side like they do on aos, or are you demanding to remove the feature of mui compatibility altogether losing this functionality, because you hate it? but in this case why at all improve the system? by this logic everything is fine as is. you are a bit hard to understand i must admit.
Title: Re: Layers.library V45 on the aminet
Post by: biggun on September 13, 2014, 09:32:04 AM
If you read the posts and rantings here,
then one could come to the conclusion :
that for those who actaully  spend time on working on AMIGA software
it will be smart to not publish the software, or it least not to announce it at a forum like this .
Title: Re: Layers.library V45 on the aminet
Post by: Thorham on September 13, 2014, 09:33:39 AM
Quote from: wawrzon;772901
and now you are talking abut the bounty for whole operating system.
A very old OS no less, not to mention the fact that 68020+fast mem can do better than AmigaOS (a new, from scratch, incompatible OS, of course). I wish this whole AmigaOS thing would just go away, but no, we're stuck with it :(

Quote from: biggun;772902
If you read the posts and rantings here,
then one could come to the conclusion :
that for those who actaully  spend time on working on AMIGA software
it will be smart to not publish the software, or it least not to announce it at a forum like this .
I'd say: 'Don't let the party poopers spoil your day.'
Title: Re: Layers.library V45 on the aminet
Post by: Minuous on September 13, 2014, 09:39:54 AM
>there were some successful larger aros bounties (open sourcing poseidon usb stack) and two or three other bigger bounties (dopus magellan and odyssey), all organized by people whom you are arguing against, olaf as example. the bounties were successful because the people in question actually did something instead of bragging and demanding. and remember magellan bounty has not been met. the owners agreed to lesser amount. and now you are talking abut the bounty for whole operating system. it will not be another ten thousand dollar bounty im sure. if it was i might have been interested few years ago when there might have been enough people to support it. anyways if you want to risk money parked on some account for years, go for it and try, but judging by this thread alone there isnt much interest anymore.

I very much doubt they would want >$10000 at this point, considering they have left the Amiga market. I'm not "arguing against" anyone, simply having a discussion, much less "bragging and demanding". So explain what have I bragged about or demanded from anyone? In fact, you are the one demanding that I work on your pet project. At what point in this thread or anywhere else have I ever demanded anyone ever work on one of my programs? I welcome code contributions but I don't go around demanding that everyone else work on my programs. All I've said is that an AmigaOS clone should be like AmigaOS, I don't know why this would even be a controversial point, it's just common sense.

>takes much more time than just posting in forums, which is what people are primarly interested in so why really bother.

Yeah, right, that's all I do, go look on Aminet or my site then before making such stupid statements.

>why fork? you can just contribute the missing classes and mui and reaction programs will work fine side by side like they do on aos, or are you demanding to remove the feature of mui compatibility altogether losing this functionality, because you hate it?

It shouldn't be included in any AmigaOS replacement as it has never been a part of AmigaOS. If people want to download it they can, no one is stopping them.
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 13, 2014, 10:03:37 AM
Quote from: Minuous;772904
>there were some successful larger aros bounties (open sourcing poseidon usb stack) and two or three other bigger bounties (dopus magellan and odyssey), all organized by people whom you are arguing against, olaf as example. the bounties were successful because the people in question actually did something instead of bragging and demanding. and remember magellan bounty has not been met. the owners agreed to lesser amount. and now you are talking abut the bounty for whole operating system. it will not be another ten thousand dollar bounty im sure. if it was i might have been interested few years ago when there might have been enough people to support it. anyways if you want to risk money parked on some account for years, go for it and try, but judging by this thread alone there isnt much interest anymore.

I very much doubt they would want >$10000 at this point, considering they have left the Amiga market. I'm not "arguing against" anyone, simply having a discussion, much less "bragging and demanding". So explain what have I bragged about or demanded from anyone?

>takes much more time than just posting in forums, which is what people are primarly interested in so why really bother.

Yeah, right, that's all I do, go look on Aminet or my site then before making such stupid statements.

>why fork? you can just contribute the missing classes and mui and reaction programs will work fine side by side like they do on aos, or are you demanding to remove the feature of mui compatibility altogether losing this functionality, because you hate it?

It shouldn't be included in any AmigaOS replacement as it has never been a part of AmigaOS. If people want to download it they can, no one is stopping them.


regarding H&P from last contacts I had Mr. Haage is not interested in anything amiga-related anymore. And if the legal situation around 3.5/3.9 is similar complicated than in other amiga-related products it would be complicated to get it free (including problems with AmigaInc. and propably Hyperion who see themselves as the official successor). And you would propably need approvals of all contributors who are propably partly difficult to find and even if have no source codes anymore. That is what I experienced when I tried to contact former amiga programmers. It is all a long time ago.

And regarding MUI (or in case of Aros Zune), there are much more MUI programs than Reaction programs and Classact works in Aros (propably even Reaction but I have not tested that).

"pretending it's somehow equivalent to the official AmigaOS though."

I have explained it, Aros 68k (if you replace the Desktop) is Amiga, Aros is basically 3.1. API + additional Features/Patches. You do not use the nightly on Aros (they are just for testing) but the distributions. You do not like Aros because the devs prefer MUI to Reaction as GUI toolkit? You can add classact, you can add Triton, you can add BGUI, you can propably add Reaction too. You do not need to reimplement installer because you just copy the file.

Examples of GUI toolkits:
http://www.aros-platform.de/html/gui_toolkit.html

Examples of Raytracers running in it:
http://www.aros-platform.de/html/raytracing.html

partly free available, partly included

I do not understand your aversion to Aros, at least for the 68k version. X86 or ARM are different because you can only include software that is reimplemented/compiled for it and that requires sources that are often not available.
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 13, 2014, 11:01:11 AM
Quote from: Thorham;772903
A very old OS no less,
yet magellan was just a very old workbench replacement, just a component of an os in comparison and what did that cost? and odyssey? its "just"a mui frontend for webkit. dont get me wrong, i am all for open sourcing whatever amiga, just do not see it happen.
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 13, 2014, 11:07:28 AM
Quote from: Thorham;772903
A very old OS no less, not to mention the fact that 68020+fast mem can do better than AmigaOS (a new, from scratch, incompatible OS, of course). I wish this whole AmigaOS thing would just go away, but no, we're stuck with it :(


I'd say: 'Don't let the party poopers spoil your day.'


are we really? Most software already runs on Aros 68k, as long as you do not really need certain patches you do not need it anymore. I have amigaforever installed and only use it for testing anymore. Ah and I use the roms in my internal test distribution in Whdload.
Title: Re: Layers.library V45 on the aminet
Post by: Thorham on September 13, 2014, 11:09:13 AM
Quote from: wawrzon;772908
yet magellan was just a very old workbench replacement, just a component of an os in comparison and what did that cost? and odyssey? its "just"a mui frontend for webkit. dont get me wrong, i am all for open sourcing whatever amiga, just do not see it happen.
Not what I meant. The owners of said software obviously decide what they do and don't do with their property, and I'm not complaining about that. What I am complaining about is that we're stuck with AOS on our 68k Amigas, while something much better is possible, where we're also not tied to AOS anymore (including Aros). I'm specifically not talking about other old software.

Quote from: OlafS3;772909
are we really?
Yes, Aros is an AOS derivative after all, and it would be nice to be able to get rid of that completely, because 68k can do better than AOS and Aros.
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 13, 2014, 11:12:07 AM
Quote from: Minuous;772904
>there were some successful larger aros bounties (open sourcing poseidon usb stack) and two or three other bigger bounties (dopus magellan and odyssey), all organized by people whom you are arguing against, olaf as example. the bounties were successful because the people in question actually did something instead of bragging and demanding. and remember magellan bounty has not been met. the owners agreed to lesser amount. and now you are talking abut the bounty for whole operating system. it will not be another ten thousand dollar bounty im sure. if it was i might have been interested few years ago when there might have been enough people to support it. anyways if you want to risk money parked on some account for years, go for it and try, but judging by this thread alone there isnt much interest anymore.

I very much doubt they would want >$10000 at this point, considering they have left the Amiga market. I'm not "arguing against" anyone, simply having a discussion, much less "bragging and demanding". So explain what have I bragged about or demanded from anyone? In fact, you are the one demanding that I work on your pet project. At what point in this thread or anywhere else have I ever demanded anyone ever work on one of my programs? I welcome code contributions but I don't go around demanding that everyone else work on my programs. All I've said is that an AmigaOS clone should be like AmigaOS, I don't know why this would even be a controversial point, it's just common sense.

>takes much more time than just posting in forums, which is what people are primarly interested in so why really bother.

Yeah, right, that's all I do, go look on Aminet or my site then before making such stupid statements.
 went
>why fork? you can just contribute the missing classes and mui and reaction programs will work fine side by side like they do on aos, or are you demanding to remove the feature of mui compatibility altogether losing this functionality, because you hate it?

It shouldn't be included in any AmigaOS replacement as it has never been a part of AmigaOS. If people want to download it they can, no one is stopping them.


then why dont you find out what it really costs? olaf just went and asked. when you have an answer, then we can go talking about concretes. speculations are worthless.

and aros is neither my pet project nor am i demanding you to work on it. i just indicated the available realistic options. i went to support aros because i dont see the possibility that amiga 68k gets much improvements. i dont know your work but im pretty sure that you do your best and i respect that.
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 13, 2014, 11:14:47 AM
Quote from: Thorham;772910
Not what I meant. The owners of said software obviously decide what they do and don't do with their property, and I'm not complaining about that. What I am complaining about is that we're stuck with AOS on our 68k Amigas, while something much better is possible, where we're also not tied to AOS anymore (including Aros). I'm not specifically not talking about other old software.


What classic hardware do you use? 68020? 68030?

If people would at least help testing and send logs to Toni Wilen there would be a higher chance that Aros 68k (and expecially the Roms) would be improved. If only Wawa does something it is hardly motivating Toni Wilen to do something on it. If something is missing report it or set up a bounty for it, if there is enough interest there is a chance that somebody cares for it. Complaining about the situation is not enough...

Ok I understood you wrong, you do not want anything amiga-related. I think you are on the wrong forum now :-)
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 13, 2014, 11:17:15 AM
Quote from: Thorham;772910
Not what I meant. The owners of said software obviously decide what they do and don't do with their property, and I'm not complaining about that. What I am complaining about is that we're stuck with AOS on our 68k Amigas, while something much better is possible, where we're also not tied to AOS anymore (including Aros). I'm specifically not talking about other old software.


Yes, Aros is an AOS derivative after all, and it would be nice to be able to get rid of that completely, because 68k can do better than AOS and Aros.


Get rid of anything amiga-related?

I think I read there was Unix on 68k revived, use that. But for me personally it would not make sense, I can use it on X86 already.

You "could" modernize AmigaOS (or any other related OS) but then you risk that no software runs on it anymore. Then you have a kind of BeOS with zero software, what sense would it make? A "proof of concept"?
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 13, 2014, 11:51:14 AM
Quote from: Thorham;772910
Not what I meant. The owners of said software obviously decide what they do and don't do with their property, and I'm not complaining about that. What I am complaining about is that we're stuck with AOS on our 68k Amigas, while something much better is possible, where we're also not tied to AOS anymore (including Aros). I'm specifically not talking about other old software.


Yes, Aros is an AOS derivative after all, and it would be nice to be able to get rid of that completely, because 68k can do better than AOS and Aros.


im not sure what you are proposing here. as i understand you want to get rid of os and bang the hardware. this is fine as long as all hardware you have is compatible to each other, which in reality is never completely the case. it certainly wasnt on amiga. but the os abstracting the hardware can compensate fr it and this is what we need it for. or do i understand you wrong?
Title: Re: Layers.library V45 on the aminet
Post by: warpdesign on September 13, 2014, 12:39:31 PM
Quote from: wawrzon;772914
It shouldn't be included in any AmigaOS replacement as it has never been a part of AmigaOS. If people want to download it they can, no one is stopping them.

You do not find it legitimate but seems like most developers do since it's used by lots of software still maintained today. In the end, it all comes to what is your target: are you making an OS for people to enjoy? Or are you making an OS for yourself... If you're targetting people you'd better make it easy for people to include the libs needed by most of the apps they are gonna use.. And put aside your own personal thoughts. As if Apple refused to include OpenGL because Tim did not like the lib and thought it wasn't legitimate to include it in Macos..
Title: Re: Layers.library V45 on the aminet
Post by: modrobert on September 13, 2014, 01:59:51 PM
Quote from: takemehomegrandma;665403

Quote from: koaftder;665358
No point in it, it's already been reimplemented 3 times over.

Well, I can *definitely* see the point!

The 3 re-implementations are for "NG Enthusiasts" only, while the fourth one (or really, the first one, since Amiga OS was and is the *original*, the only *real* Amiga)

(http://farm3.static.flickr.com/2369/5795704853_b722d5d487_z.jpg)

This one is still is of very much interest to:

1) Retro fans using real Amiga HW, or UAE
2) Retro fans using new HW that mimics the real Amiga, like Minimig
3) Fans (not sure it's right to call them "retro" only) that wants to *improve* the real Amiga HW, I'm of course thinking of NatAmi!

None of these has the *slightest* interest in any of the three re-implementations. It's not difficult to understand. They want to use the real Amiga 68k apps in the true way, the real classical Amiga games, demos, etc, and flawless compatibility is the most important thing. There is no alternative to the real Amiga OS then, running in a 68k environment with all the custom chips in place (either in HW or in UAE). "NG Enthusiasts" has a different view, they want to use an Amiga environment in a way that is as close to 2011 level computing as possible; modern Internet apps, playing modern media files, etc. Amiga compatibility is an appreciated bonus, but that's not the main thing. To them, it's mostly a matter of choosing one or more of the re-implementations.

What the Amiga 68k fans might be interested in however, might be a continuation and improvements of Amiga OS (and by that I'm *not* talking about Hyperions OS4, which is yet another re-implementation, and the most immature one even). Especially NatAmi would benefit from this, since they will need an OS that can make the most use of the new features of their board. That's what I call "Amiga OS+" in the picture above in lack of a better word. An evolved version of the real Amiga OS 68k. The NatAmi crew will probably make their own third party add-ons and replacement if they ever get this far with their HW, possibly using some stuff from AROS, and writing some stuff themselves. It will however be completely unofficial of course.

Amiga OS 68k can only be distributed by Hyperion AFAIK thanks to that crappy "agreement" (cough cough (read: robbery)). But not even they can release it as open source, since Amiga Inc still owns it. You think it's a mess? It truly is! :(

(Edit: Oh BTW, the time of the first MorphOS release is one month too late in the picture, my bad... ;) )

I agree with takemehomegrandma in this case regarding the "first implementation", quote from this forum thread (http://www.amiga.org/forums/showthread.php?t=59570).
Title: Re: Layers.library V45 on the aminet
Post by: Thorham on September 13, 2014, 02:32:43 PM
Quote from: OlafS3;772912
What classic hardware do you use? 68020? 68030?
AGA with 50Mhz 68030.

Quote from: OlafS3;772912
If people would at least help testing and send logs to Toni Wilen there would be a higher chance that Aros 68k (and expecially the Roms) would be improved.
That sounds perfectly reasonable. Personally I have no problem with using WinUae for testing purposes.

Quote from: OlafS3;772912
Ok I understood you wrong, you do not want anything amiga-related. I think you are on the wrong forum now :-)
No, I'm talking about AOS, not the hardware. The hardware is great, just the OS isn't.

Quote from: OlafS3;772913
You "could" modernize AmigaOS (or any other related OS) but then you risk that no software runs on it anymore. Then you have a kind of BeOS with zero software, what sense would it make? A "proof of concept"?
Yeah, I've had it in the back of my mind for years now. Write something new from scratch. Would be great, but there would also be no software to run.

Quote from: wawrzon;772914
im not sure what you are proposing here. as i understand you want to get rid of os and...
... replace it with something better. Somehow I doubt there's a point, though.
Title: Re: Layers.library V45 on the aminet
Post by: psxphill on September 13, 2014, 04:45:51 PM
Quote from: OlafS3;772913
You "could" modernize AmigaOS (or any other related OS) but then you risk that no software runs on it anymore. Then you have a kind of BeOS with zero software, what sense would it make? A "proof of concept"?

If I were doing it I'd redesign exec with full memory protection and then applications that had problems with it would require compatibility modes. You could start out allocating ram privately and then when it was passed to another component and causes an access violation it would make the memory accessible and mark the original allocation as requiring extra privileges. Kind of like how firewalls on the PC ask you if it's ok to access certain sites.

The work would only need to be done once and files distributed for each application. They could be distributed by a central AmigaOS Update site.
 
 If the application needs access to everything then most applications could also be run inside a virtual machine sandbox.
Title: Re: Layers.library V45 on the aminet
Post by: LiveForIt on September 13, 2014, 05:16:00 PM
Quote from: modrobert;772918
I agree with takemehomegrandma in this case regarding the "first implementation", quote from this forum thread (http://www.amiga.org/forums/showthread.php?t=59570).

It smells lot of morphos fan boy views.

"Hyperions OS4" its not called that and its direct descendent of AmigaOS4. "most immature", well thats depletable MorphOS does not support the latest Graphics cards, AmigaOS4.1 do, and also AmigaOS4.x has memory protection that does work to find bugs and debug applications and it work. MorphOS allows more misbehaving programs to run. Is that a feature or is it a failure well if you ask me its a failure.

Personalty I see no point in improving AmigaOS3.x, every thing worth improving is already fixed is  already improved in AmigaOS4.1, more important its not random hacks, there is offical set of libraries, if you code to support this libraries your programs will run in future as well, they wont stop because some hobbyist decides they wont to do some thing different.

If there was some thing that should be fixed in AmigaOS3.x I think bring it up level that enable some large file system and hard drives to work, with out having to worry about corrupting your data, be the one thing that I think is a "Must" fix issue, every thing else is not mandatory.

Anyway this debate is pretty mutch irrelevant.

I agree with some comments about AmigaOS4.1 being close source is hinderance in some ways, there are things I like to add or improve, I don't care if did not get dime for it, because if did add this features it be useful to me latter on, when I write my programs or games.

But anyway in most/every case I do not need to modify the OS, to add new features, there are otherways, I can for example create my own set of libraries that complements the originals features, this way don't need to change the OS in any unexpected way, so no programs are going to stop working. This is what MUI is, they did not try to hack Gadtools, they created there own GUI system in system fremdly way, and now MUI has become a offical parts of MorphOS and AmigaOS4.1, well in the case of AmigaOS4.1 you need a key to unlock some its less importent features..

Picasso96 is also extension to graphic.library.
Title: Re: Layers.library V45 on the aminet
Post by: LiveForIt on September 13, 2014, 05:26:17 PM
Quote from: Thorham;772920
No, I'm talking about AOS, not the hardware. The hardware is great, just the OS isn't.  


so way don't you install Linux 68k, or NetBSD 68K, or are this also bad or are this also not great?

In any case what ever you do your going to have to deal with limited hardware specifications, so there is trade off between having some thing that can do every thing and some thing that has to be light weight.

Anyway I'm curious what do you think is the most important part of OS that AmigaOS do not have? I ask this question because I know you like to take over the hardware.
Title: Re: Layers.library V45 on the aminet
Post by: psxphill on September 13, 2014, 05:54:27 PM
Quote from: LiveForIt;772932
so way don't you install Linux 68k, or NetBSD 68K, or are this also bad or are this also not great?

In any case what ever you do your going to have to deal with limited hardware specifications, so there is trade off between having some thing that can do every thing and some thing that has to be light weight.

It's possible to do something light weight that can do everything, you just have to design it properly to start with.
 
 AmigaOS and Linux/NetBSD sit at opposite ends of the table, there is middle ground.
Title: Re: Layers.library V45 on the aminet
Post by: LiveForIt on September 13, 2014, 06:04:21 PM
Quote from: psxphill;772935
It's possible to do something light weight that can do everything, you just have to design it properly to start with.  

In software, the more stuff you add the more the CPU has to do, there is limit what it can do. Well yes a good program will take less CPU cycles becouse it do the lest amount of work to active its goals, but still has to do the work.

Quote
AmigaOS and Linux/NetBSD sit at opposite ends of the table, there is middle ground.

in any case its lot of work, and if you wont to have application need to be ported from another OS, and so you need to port the support libs, and so on.

Anyhow its lot of work, most people don't have the time.
Title: Re: Layers.library V45 on the aminet
Post by: NorthWay on September 13, 2014, 07:14:06 PM
Quote from: Thomas Richter;772860

As far as Birdie is concerned: I don't have a contact to its author. Do you? Does anyone in the community have?  

I am pretty confident you will find him at https://www.linkedin.com/in/trondwernerhansen
Title: Re: Layers.library V45 on the aminet
Post by: NorthWay on September 13, 2014, 07:19:14 PM
For the record:

If anyone is interested in setting up a bounty for AOS sources then I'm willing to put down $1000. Personal, hobby, non-commercial money.
Make it for 3.1 only if that makes it any easier.

(The bounty should have some legal-speak that indemnify the buyer(s) if the rights are disputed at a later date.)
Title: Re: Layers.library V45 on the aminet
Post by: bloodline on September 13, 2014, 07:42:07 PM
Quote from: NorthWay;772942
For the record:

If anyone is interested in setting up a bounty for AOS sources then I'm willing to put down $1000. Personal, hobby, non-commercial money.
Make it for 3.1 only if that makes it any easier.

(The bounty should have some legal-speak that indemnify the buyer(s) if the rights are disputed at a later date.)


It's your money, but if I were you I would put that $1000 towards an AROS bounty to develop the 68k port to a better standard. It's more likely to happen (AmigaOS is never going to be open sourced) and has better long term benefits.
Title: Re: Layers.library V45 on the aminet
Post by: psxphill on September 13, 2014, 07:51:31 PM
Quote from: LiveForIt;772936
In software, the more stuff you add the more the CPU has to do, there is limit what it can do. Well yes a good program will take less CPU cycles bedouse it do the lest amount of work to active its goals, but still has to do the work.

The trick is to do more with less. It's definitely possible to do better in comparison to Linux and NetBSD.
 
 With layers.library and the recent AllocMem patches it's shown it's possible to do better than 90's AmigaOS.
Title: Re: Layers.library V45 on the aminet
Post by: Thorham on September 13, 2014, 09:03:56 PM
Quote from: LiveForIt;772932
so way don't you install Linux 68k, or NetBSD 68K
Because I don't want to. Also, what am I going to run under these  operating systems on a 68030? If I want to run Linux, then I'll just  install a current distro on my peecee.

Quote from: LiveForIt;772932
In any case what ever you do your going to have  to deal with limited hardware specifications, so there is trade off  between having some thing that can do every thing and some thing that  has to be light weight.
Of course, but it's certainly possible to do better than AOS on a  68020/30, both in terms of speed, functionality and eye candy. In other  words, as good as possible without needing 60s and GFX cards, and what  not.

Quote from: LiveForIt;772932
Anyway I'm curious what do you think is the most important part of OS that AmigaOS do not have?
Memory protection is the main one, but everything can also be done better, that's the idea.

Quote from: LiveForIt;772932
I ask this question because I know you like to take over the hardware.
No, I don't. The thing I like to do is use the CPU to blit to the screen  memory directly, because it can be so much faster than using those  generic OS blitting routines. And audio, obviously, but what choice is  there?

Quote from: LiveForIt;772936
and if you wont to have application need to be ported from another OS
And that's the second part of what I want. New programs written from scratch just for this new OS, with absolutely NOTHING ported from existing software. Would be too slow anyway. Imagine porting FireFox to 68k :lol:

Yeah, a 68k Amiga software utopia. Sadly, it probably won't ever happen.
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 14, 2014, 11:51:06 AM
Quote from: NorthWay;772942
For the record:

If anyone is interested in setting up a bounty for AOS sources then I'm willing to put down $1000. Personal, hobby, non-commercial money.
Make it for 3.1 only if that makes it any easier.

(The bounty should have some legal-speak that indemnify the buyer(s) if the rights are disputed at a later date.)


how are you going to make sure you are buying from the actual owner and that there will not be any claims from third parties in the future?
Title: Re: Layers.library V45 on the aminet
Post by: Cosmos on September 14, 2014, 12:51:11 PM
Quote from: Thomas Richter;772753
You still don't get it, right? I'm trying to find out what the situation is, understood? How much more explicit do I need to get?   Have you made any measurements showing the efficiency of these "improvements", and have you considered that this leaves the libraries in a pretty unmaintainable state?  

Again, what is "working" for you? For me it means that I can also fix something in two years in the future. With the kind of "improvements" I see from Cosmos this is unlikely to be even possible. First of all, it doesn't really improve anything, and second, even if the results were measurable, the improvements were lost or incompatible to any other changes that had to be made.

Have you watching my changes into my code ? Certainly no...

For example, the function R_AndRegionRegion in the graphics.library use two AllocMem (and of course two FreeMem at the end) for two tiny buffers (only $C) : I replaced by six clr.l -(sp) for these buffers on the stack now...

This function is now more than 1000 times faster, so the improvement is real...


You are a professionnal troller, you talk in the void, you have lost all credibility...



:(
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 14, 2014, 01:06:14 PM
Quote from: Cosmos;772972
For example, the function R_AndRegionRegion in the graphics.library use two AllocMem (and of course two FreeMem at the end) for two tiny buffers (only $C) : I replaced by six clr.l -(sp) for these buffers on the stack now...

What exactly is it that you do not understand with the word "measurement"? It means, making an experiment, showing the efficiency of the changes. It does not mean "guesswork". BTW, do you have an idea *why* there is an AllocMem()? (Actually, there isn't. There is a NewRegion() call). Thus, can you ensure that the buffers that are released there are in fact idental to the buffers allocated? Or did you "just made an experiment and it happened to work for you"?

THe software interfaces used there are there for a reason - the regions have luckely (unlike many other crap in gfx) a clear constructor method (NewRegion()), and it's typically a good idea to use that. Unless there is a very clear reason that this is not a good idea, and the only clear inidicator would be that there is a specific bottleneck in AndRegionRegion() in a specific situation. Thus, I ask you again: Which is the bottleneck, and which is the situation within which this bottleneck appears, and what is the speed improvement you get in this specific situation.

Just for the records, here is my specific bottleneck I addressed in layers V45, just for completeness: Open a lot of overlapping windows on a graphics-card driven screen, then re-arrange the windows (depth-arrangement), then measure. You'll get a noticable speedup.

Now, what's your story that requires this change, and how did you ensure that the change is correct?

Software engineering. You know it...
Title: Re: Layers.library V45 on the aminet
Post by: LiveForIt on September 14, 2014, 02:09:01 PM
Quote from: Cosmos;772972
for these buffers on the stack now...


So by increasing the stack footprint, you have cut down on memory allocations.

Theoretically any program that use this function can run out of stack, because many programs have small $STACK cookie, and default stack for shell commands and wb icons on Amiga is low to begin with.
Title: Re: Layers.library V45 on the aminet
Post by: modrobert on September 14, 2014, 02:53:17 PM
Quote from: Thomas Richter;772973
What exactly is it that you do not understand with the word "measurement"? It means, making an experiment, showing the efficiency of the changes. It does not mean "guesswork". BTW, do you have an idea *why* there is an AllocMem()? (Actually, there isn't. There is a NewRegion() call). Thus, can you ensure that the buffers that are released there are in fact idental to the buffers allocated? Or did you "just made an experiment and it happened to work for you"?

THe software interfaces used there are there for a reason - the regions have luckely (unlike many other crap in gfx) a clear constructor method (NewRegion()), and it's typically a good idea to use that. Unless there is a very clear reason that this is not a good idea, and the only clear inidicator would be that there is a specific bottleneck in AndRegionRegion() in a specific situation. Thus, I ask you again: Which is the bottleneck, and which is the situation within which this bottleneck appears, and what is the speed improvement you get in this specific situation.

Just for the records, here is my specific bottleneck I addressed in layers V45, just for completeness: Open a lot of overlapping windows on a graphics-card driven screen, then re-arrange the windows (depth-arrangement), then measure. You'll get a noticable speedup.

Now, what's your story that requires this change, and how did you ensure that the change is correct?

Software engineering. You know it...


Isn't the original graphics.library written in C?

You can't expect a C compiler to match the optimizations made manually by an assembler programmer. I've heard so many stories about how well C compilers optimize these days and how assembler is made redundant, and then when you actually disassemble the code the compiler produced, it's bloated, filled with jump tables, and inefficient code.
Title: Re: Layers.library V45 on the aminet
Post by: itix on September 14, 2014, 04:21:42 PM
Quote from: LiveForIt;772975
So by increasing the stack footprint, you have cut down on memory allocations.

Theoretically any program that use this function can run out of stack, because many programs have small $STACK cookie, and default stack for shell commands and wb icons on Amiga is low to begin with.


They dont. There are many more OS calls consuming lot more stack and developers are adviced to not cut their stack size too small. The default stack size 4096 bytes is more than enough to most applications and stack command in the shell or WB icon setting dont have any effect to subtasks/processes anyway.

@modrobert
Quote

I've heard so many stories about how well C compilers optimize these days and how assembler is made redundant, and then when you actually disassemble the code the compiler produced, it's bloated, filled with jump tables, and inefficient code.


When you have 68020 or better it becomes irrelevant. On 68000 it can be noticeable, event without a stopwatch, but when it comes to Region functions in graphics library it becomes irrelevant again. If performance is problem you dont probably want to hand optimize Region calls but find better algorithm with O(n) or O(1) processing time.
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 14, 2014, 05:10:29 PM
Quote from: modrobert;772976
Isn't the original graphics.library written in C?

All versions (1.x through 3.x) are written in a mix of 'C' and 68k assembly language, strongly leaning towards 68k assembly code. Looking at the API, you'll find that a large part of the operations are about filling in data structures, hooking them up and then eventually telling the hardware what to do with them. Typically, the "clerical operations" are written in 'C', and the part which talks to the hardware is written in assembly language.

graphics.library, like intuition.library, is one of the more complex operating system components, both in how it uses data structures and how many distinct operations it can carry out. Hence, you'll find that 'C' plays a major part in its implementation.

That said, when you need to talk to the hardware in a very specific manner, you couldn't do that quite so elegantly back in 1986 if you didn't use 68k assembly language. There is complex assembly language code in graphics.library, it even uses its own preprocessor (!) in order to simplify writing loops (while .. do) and control structures (if .. then .. else).

Quote from: modrobert;772976
You can't expect a C compiler to match the optimizations made manually by an assembler programmer. I've heard so many stories about how well C compilers optimize these days and how assembler is made redundant, and then when you actually disassemble the code the compiler produced, it's bloated, filled with jump tables, and inefficient code.
If you have specific requirements for carrying out operations, you may get better control through the use of assembly language than any modern 'C' compiler could provide you with. C11 has just gained new control keywords in order to make interfacing to hardware more straightforward, but it will take a while for the language to evolve to give you the kind of control only assembly language can give you.

As for assembly language becoming largely redundant, it's probably unavoidable. 'C' in particular is a more expressive language which encodes in fewer lines what assembly language, by its very nature, requires much more effort to express. The thing is, if you can say the same thing with fewer words, the chances of mucking it up are somewhat reduced. If you have the right language, you can even verify the correctness of the instructions and data structures you used, which is something that eludes assembly language by its very design.

As for inefficient code, performance nowadays does not necessarily come out of implementing an algorithm through the optimum low level language encoding you could choose (that being assembly language). You can't necessarily predict how your code will be executed, and if you can, you might have to run the gauntlet of observing a handful of operating conditions under which it executes, such as regarding optimum pipeline use, prefetch, etc. This can get so ugly that it has to be automated (look up how one programmed the Motorola 56000 DSP in its day, just to get an idea how weird this can get) just to let the programmer worry about implementing his design correctly.

This is how progress looks like: the gains made through building faster processors are used in such a way that writing more complex software, more secure software and more reliable software becomes an easier goal to achieve through the use of tools and code generation which does not necessarily attempt to squeeze the last cycle out of the machine. This is, in the end a trade-off, if not a sacrifice.
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 14, 2014, 05:29:30 PM
Quote from: Cosmos;772972
Have you watching my changes into my code ? Certainly no...

For example, the function R_AndRegionRegion in the graphics.library use two AllocMem (and of course two FreeMem at the end) for two tiny buffers (only $C) : I replaced by six clr.l -(sp) for these buffers on the stack now...

This function is now more than 1000 times faster, so the improvement is real...


You are a professionnal troller, you talk in the void, you have lost all credibility...



:(

Oh dear, the two of you do not even speak of the same thing when you discuss optimizations.

Replacing a memory allocation, which is guaranteed to be more expensive than substituting stack operations, certainly is an optimization. But the actual gains are likely to be entirely absorbed by the respective functions in graphics.library/intuition.library, etc. calling layers.library.

From what I have learned, there is only so much you can achieve at this level of optimization. You are more likely to get exponentially higher improvements if you perform the optimization at the next higher level, through the use of different data structures and algorithms, which is exactly what Thomas did with his layers.library implementation.

For this reason, I remain doubtful if a 1000-fold improvement is possible at this level. As the saying goes, extraordinary claims requite extraordinary explanations and proof to back them up.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 14, 2014, 05:35:51 PM
Quote from: modrobert;772976
Isn't the original graphics.library written in C?

It's a mix of both, depending on the level of the function. The low-level stuff is in assembly, the higher and more complex operations are in C. Even then, the assembler stuff depends on some macros to provide at least some orientation on the program flow, i.e. the authors have used macros for conditions, loops and so on. The result is not quite as scary as "raw" assembler.

This specific function, and the region functions in particular, are in assembly. It's part of the low-level slice&dice operations that are commonly used between layers and graphics. Ideally, regions (like other layer-like structures) should be pooled, and hence NewRegion() should first try to take the region memory from a graphics specific pool, and recycle regions whenever possible.  

Unfortunately, it's not what it does. If you want such pooling, PoolMem is there to help (it keeps memory pools for small fragments like struct Region, hence *may* help here).

Even more unfortunately, struct Region is documented, so *in principle* an appplication could create such a structure by AllocMem(), bypassing NewRegion() (bad idea!) or on the stack (also a bad idea!) Even then, such a change should be synchronized between graphics, layers, and code parts that re-implementent parts of layers & graphics (P96, cybergraphics, EGS...). Thus, in general, it is not such a good idea to change this lighthearted. It requires a pretty complete code review to understand the possible implications, and potentially a re-compile of graphics, layers, P96 and cybergraphics (in worst case).

One way or another, this example shows a constructional weakness of the whole AmigaOs: Too many internals have been documented, and the API is not always clear. Ideally, all "primitive objects" should have been left undocumented, or should have been equipped with clear constructor/destructor calls. struct Region is one of the "better" implementations by using such an API (partially), but the situation is much worse with other graphics primitivities, such as struct RastPort, struct Bitmap (big outch!), struct ViewPort (bigger outch!) or struct View. To avoid the many problems, V37 graphics jumps in circles and stores private data on the ViewPort not in the view port, but in the color map (even bigger outch!) loaded in the view port just to be able to extend it, and uses hoops such as GfxAssociate to be able to backwards-extend the gfx engine.

Gfx is a clear case of "how not to design a library". Intuition much better code from a software engineering perspective (there are clear structures and a relatively clean API). I guess this is all because gfx was written in a rush, for a deadline that was too close to allow a good implementation, and pretty much in an ad-hoc way.

Then again, all the region low-level calls should, instead of calling NewRegion() internally through gfx, go through the LVO instead. They don't do that, but probably should. Another outch.
Title: Re: Layers.library V45 on the aminet
Post by: biggun on September 14, 2014, 05:44:35 PM
Please let me give my 2cents to it to.

I think what Thomas does is great,
He improved the algorithm resulting in a big improvement.

I also like what Cosmos does.
Cosmos shows great ASM skills and extrem hard will to understand the ASM codes.
His tuning are certainly interesting for many.
But I personally could also envision other great uses for his shown great skills.

For example:
Lets assume Cosmos would develop the bitplane GFX driver for AROS.
This could be great for the free AMIGA future and make AROS become real fast on 68k.

I think what Cosmos does right now is he looks at the compiler generated ASM output
and then figures that there are 10 instructions - which a smart coder could rewrite doen to 6.
And then he does this.
While this is cool and great - I wonder what would happen if he would not change this one routine -
but change the compiler to in the future see and use such optimizations.
Could this work? And how would the gain be if one would then recompile A-OS or AROS with the tuned compiler?
Title: Re: Layers.library V45 on the aminet
Post by: itix on September 14, 2014, 06:06:13 PM
Quote from: biggun;772986

I think what Cosmos does right now is he looks at the compiler generated ASM output
and then figures that there are 10 instructions - which a smart coder could rewrite doen to 6.
And then he does this.
While this is cool and great - I wonder what would happen if he would not change this one routine -
but change the compiler to in the future see and use such optimizations.
Could this work? And how would the gain be if one would then recompile A-OS or AROS with the tuned compiler?


I dont think we are going to see AOS recompiled ever again. It is irreversibly sucked to a black hole.

And I don't think he has interest to that anyway.

But if it has to be done in 68k asm then it would be better rewrite intuition library in machine language only. Being rewrite rather than being based on disassembled binary you can open source this project.
Title: Re: Layers.library V45 on the aminet
Post by: NorthWay on September 14, 2014, 06:08:06 PM
Quote from: wawrzon;772969
how are you going to make sure you are buying from the actual owner and that there will not be any claims from third parties in the future?

That is of course the tricky part. The seller should take some legal/contractual responsibility to accept ownership over future disputes.
Which is basically what they have done anyway by selling 3.5/3.9. An attempted buy-out should say something about their confidence in the legal side.

OTOH, internet exposure of source code can turn the reaction knob to 11 and flush out someone who has been biting their tongue or just been sitting idle (or simply been unknowing) since C= died.
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 14, 2014, 06:18:26 PM
Quote from: itix;772988
I dont think we are going to see AOS recompiled ever again. It is irreversibly sucked to a black hole.

Huh? Been there, done that (1999). OS4 is based upon that work.
Title: Re: Layers.library V45 on the aminet
Post by: itix on September 14, 2014, 06:39:55 PM
Quote from: olsen;772990
Huh? Been there, done that (1999). OS4 is based upon that work.


That is 15 years ago. I don't think we are going to see new 68k release. Only that matters to people here.
Title: Re: Layers.library V45 on the aminet
Post by: modrobert on September 14, 2014, 06:54:46 PM
Quote from: Thomas Richter;772985
It's a mix of both, depending on the level of the function. The low-level stuff is in assembly, the higher and more complex operations are in C. Even then, the assembler stuff depends on some macros to provide at least some orientation on the program flow, i.e. the authors have used macros for conditions, loops and so on. The result is not quite as scary as "raw" assembler.

This specific function, and the region functions in particular, are in assembly. It's part of the low-level slice&dice operations that are commonly used between layers and graphics. Ideally, regions (like other layer-like structures) should be pooled, and hence NewRegion() should first try to take the region memory from a graphics specific pool, and recycle regions whenever possible.  

Unfortunately, it's not what it does. If you want such pooling, PoolMem is there to help (it keeps memory pools for small fragments like struct Region, hence *may* help here).

Even more unfortunately, struct Region is documented, so *in principle* an appplication could create such a structure by AllocMem(), bypassing NewRegion() (bad idea!) or on the stack (also a bad idea!) Even then, such a change should be synchronized between graphics, layers, and code parts that re-implementent parts of layers & graphics (P96, cybergraphics, EGS...). Thus, in general, it is not such a good idea to change this lighthearted. It requires a pretty complete code review to understand the possible implications, and potentially a re-compile of graphics, layers, P96 and cybergraphics (in worst case).

One way or another, this example shows a constructional weakness of the whole AmigaOs: Too many internals have been documented, and the API is not always clear. Ideally, all "primitive objects" should have been left undocumented, or should have been equipped with clear constructor/destructor calls. struct Region is one of the "better" implementations by using such an API (partially), but the situation is much worse with other graphics primitivities, such as struct RastPort, struct Bitmap (big outch!), struct ViewPort (bigger outch!) or struct View. To avoid the many problems, V37 graphics jumps in circles and stores private data on the ViewPort not in the view port, but in the color map (even bigger outch!) loaded in the view port just to be able to extend it, and uses hoops such as GfxAssociate to be able to backwards-extend the gfx engine.

Gfx is a clear case of "how not to design a library". Intuition much better code from a software engineering perspective (there are clear structures and a relatively clean API). I guess this is all because gfx was written in a rush, for a deadline that was too close to allow a good implementation, and pretty much in an ad-hoc way.

Then again, all the region low-level calls should, instead of calling NewRegion() internally through gfx, go through the LVO instead. They don't do that, but probably should. Another outch.


Thanks for taking the time and explain this.

I'm starting to understand that changing one routine, you can break others unknowingly, and even if you test OK, chances are that hardware compatibility is lost through dependencies of other libraries, also depending on the order of the function calls (which in rare circumstances can fail even without changing anything).

Hmm, I think there is a name for it; "Spaghetti code". Maybe we should be happy this isn't open source (joking)? ;)

So, if I understood correctly, anyone playing with this should at least take time and test these libraries in conjunction; graphics, layers, P96 and cybergraphics.
Title: Re: Layers.library V45 on the aminet
Post by: vxm on September 14, 2014, 07:16:56 PM
I have a dream. I'd like to see ThoR and Cosmos working intelligently together without killing each other, each in his field of expertise.
 
But unfortunately, since I saw the little mouse to be eaten by the cat, I do not believe in Christmas.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 14, 2014, 07:57:12 PM
Quote from: modrobert;772993
Hmm, I think there is a name for it; "Spaghetti code". Maybe we should be happy this isn't open source (joking)?

The problem is not even that individual functions are spaghetti. The problem is that it lacks a proper organization and design. Graphics covers functions that would belong into several separate libaries and resources. It covers low-level blitter functions that should have better gone into a blitter.resource.It covers low-level graphic functionalities like line drawing and filling. These should have gone into a library on top of the blitter.resource, with a clear abstraction layer between them such that the blitter could be exchanged with something else for rtg. Then there is a display-builtup functionality of graphics that handles views and viewports. Again, this should have been separated into a low-level copper.resource, and a high-level display management. Then there is the even higher-level monitor setup and the monitor database. We have simple sprite management (better a sprite.resource) and high-level bobs and vsprite handling (should be a sprite or mobs.library). Then we have all the region-management (this should go into layers). Text handling and rendering (should go into a font.library, and diskfont should become obsolete). There are probably a couple of other functions I've forgotten...

One way or another: Gfx is a mixed collection of functions that are "somehow" related to the display system, on various hierarchical levels, without a clear structure and a clear separation into modules. I believe the main problem is that graphics is "too fat".

Concerning your last comment. Yes, it would be probably best to redesign this from scratch, but it doesn't help because it won't be compatible to the existing AmigaOs. Yes, one should probably rewrite several parts of AmigaOs, but again, it doesn't help because nobody would use this Os. There is already Linux and Windows.
Title: Re: Layers.library V45 on the aminet
Post by: modrobert on September 14, 2014, 08:16:53 PM
Quote from: olsen;772983
All versions (1.x through 3.x) are written in a mix of 'C' and 68k assembly language, strongly leaning towards 68k assembly code. Looking at the API, you'll find that a large part of the operations are about filling in data structures, hooking them up and then eventually telling the hardware what to do with them. Typically, the "clerical operations" are written in 'C', and the part which talks to the hardware is written in assembly language.

graphics.library, like intuition.library, is one of the more complex operating system components, both in how it uses data structures and how many distinct operations it can carry out. Hence, you'll find that 'C' plays a major part in its implementation.

Thanks for the explanation.

Quote from: olsen;772983
That said, when you need to talk to the hardware in a very specific manner, you couldn't do that quite so elegantly back in 1986 if you didn't use 68k assembly language. There is complex assembly language code in graphics.library, it even uses its own preprocessor (!) in order to simplify writing loops (while .. do) and control structures (if .. then .. else).

Yes, I assume those are the "macros" Thomas Richter mentioned in his post.


Quote
If you have specific requirements for carrying out operations, you may get better control through the use of assembly language than any modern 'C' compiler could provide you with. C11 has just gained new control keywords in order to make interfacing to hardware more straightforward, but it will take a while for the language to evolve to give you the kind of control only assembly language can give you.

As for assembly language becoming largely redundant, it's probably unavoidable. 'C' in particular is a more expressive language which encodes in fewer lines what assembly language, by its very nature, requires much more effort to express. The thing is, if you can say the same thing with fewer words, the chances of mucking it up are somewhat reduced. If you have the right language, you can even verify the correctness of the instructions and data structures you used, which is something that eludes assembly language by its very design.

As for inefficient code, performance nowadays does not necessarily come out of implementing an algorithm through the optimum low level language encoding you could choose (that being assembly language). You can't necessarily predict how your code will be executed, and if you can, you might have to run the gauntlet of observing a handful of operating conditions under which it executes, such as regarding optimum pipeline use, prefetch, etc. This can get so ugly that it has to be automated (look up how one programmed the Motorola 56000 DSP in its day, just to get an idea how weird this can get) just to let the programmer worry about implementing his design correctly.

This is how progress looks like: the gains made through building faster processors are used in such a way that writing more complex software, more secure software and more reliable software becomes an easier goal to achieve through the use of tools and code generation which does not necessarily attempt to squeeze the last cycle out of the machine. This is, in the end a trade-off, if not a sacrifice.

I agree with this when it comes to modern multi-core CPUs, and especially recent APU architectures. A nightmare to interact with on the low level, way too many opcodes (which look ugly when disassembled...hehe), huge integrated caches to make up for slow external buses, and the die photos looking more like a small city than a CPU.

Thankfully, some of us still have 68k to play with, which is one of the best places to enjoy assembler IMHO.

For me the Amiga is a fun hobby, and since I don't rely on it much for productivity these days, it's all about testing old (and some new) software, trying to code my own programs, playing classic games, and experimenting, even with the hardware building interfaces, coding VHDL and such. The A1200 is my main computer in the electronics lab (that's what I call my little shed with a soldering iron) these days, with proper 25-pin serial interface, parallel port, and mainly TTL signals to play with on the board, it's just great.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 14, 2014, 08:48:28 PM
Quote from: modrobert;772999
Yes, I assume those are the "macros" Thomas Richter mentioned in his post.

Yes. Actually, I did not know that this was done by pre-processing. I would do it with macros, but now we're living in different times. Actually, if you'd see my DevPac macro set, then you'd see that it accomplishes pretty much the same without a preprocessor. But DevPac had a very powerful macro processor, and DevPac wasn't surely available when writing graphics.
Title: Re: Layers.library V45 on the aminet
Post by: psxphill on September 14, 2014, 09:40:22 PM
Quote from: Thomas Richter;772997
These should have gone into a library on top of the blitter.resource, with a clear abstraction layer between them such that the blitter could be exchanged with something else for rtg.

Abstraction layers slow every thing down and they only had one piece of hardware, so it made sense.
 
 I still wouldn't abstract it straight from graphics.library to blitter.resource (or blitter.device), there should be a device that is in control of allocating a screen, displaying it and drawing into it. graphics.library should just deal with managing those devices.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 14, 2014, 09:53:54 PM
Quote from: psxphill;773005
Abstraction layers slow every thing down and they only had one piece of hardware, so it made sense.
Yes and no. There was no reason to stick it all into the same fat library. For example, the whole bunch of BltBitmap() & friends that do not operate on RastPorts but Bitmaps would be simple to lay off into a second library, and it would have cost nothing to make calls into that library for the higher level functions. Unfortunately, this is not what happened.  

If you look for example at all the graphic operations in graphics, they already exist (in a way) in two layers: A core-layer that does the actually graphics hardware banging, and a lot of high-level fuzz that does the clipping of the operation into the available cliprects of the layer of the rast port to draw in. This would be an excellent spot to cut graphics into two. The lower (hardware) resource would get bitmaps and drawing style settings, the higher level would do all the clipping before sending instructions to the lower level. This avoids the kind of mess we see with P96 or cybergraphics where all the clipping operations are duplicated (in P96 *and* graphics) because there is no clean way to tell graphics to leave the hardware access to somebody else.

You would probably be astonished how hard it is to do proper line clipping if you have drawing styles (aka MinTerms), the FirstDot flag and line patterns involved. Graphics gets it *almost* right, cybergraphics messed it completely, and the latest P96 should probably be as fine as the original graphics, hopefully avoiding the one bug I remember in Gfx.
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 15, 2014, 01:08:27 AM
Quote from: Thomas Richter;773008
You would probably be astonished how hard it is to do proper line clipping if you have drawing styles (aka MinTerms), the FirstDot flag and line patterns involved. Graphics gets it *almost* right, cybergraphics messed it completely, and the latest P96 should probably be as fine as the original graphics, hopefully avoiding the one bug I remember in Gfx.

seems so. even though actually working now om aros68k there are cases where it fails to work properly, but then again, not enough reliable testing causes issues not to get fixed. it costed two years that my repeated reports were actually taken seriously and interpreted as completely lacking line clipping implementation on planar screens. thats fun, isnt it?

edit:Btw, im not saying something is wrong on developer side, just of more quality reports would happen it would be easier to fix not that obvious problem.
Title: Re: Layers.library V45 on the aminet
Post by: Cosmos on September 15, 2014, 06:57:23 AM
Quote from: vxm;772995
I have a dream. I'd like to see ThoR and Cosmos working intelligently together without killing each other, each in his field of expertise.
 
But unfortunately, since I saw the little mouse to be eaten by the cat, I do not believe in Christmas.

I only wanna explain that the quality of the code is very important.

(Thomas Richter still compilling most of his programms (like BenchTrash for example) with the -68000 option. BenchTrash is a part of the OS 3.9 who is 68020+ only...)


These mistakes are done by all the other actors in the computers world like Microsoft or Apple : they bypass the quality of the code using crappy compilators most of the time...

With my reworked libraries, I do exactly the opposite : I simpifly the code and make it smaller...

Another example with my 6 autovectors in the exec.library : original ones take 544 bytes. Now with good coding, only 130...


:)
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 15, 2014, 08:44:34 AM
Quote from: itix;772992
That is 15 years ago. I don't think we are going to see new 68k release. Only that matters to people here.

Never say never. Technically, building the operating system is easy enough, and it doesn't work any less good than it did back then.

The hard part is in figuring out if the result is sufficiently robust and does not cause important application software to fail. In short, while the code does work, it needs a QA team to make sure it's up to standards: beta testing, and fixing the bugs.

If you can find somebody to pay for that, then the current owner of the operating system may actually want to sell it, if asked. Mind you, that would only give you an updated OS 3.1, and OS 3.5 and beyond would still require more work for integration into the whole.
Title: Re: Layers.library V45 on the aminet
Post by: biggun on September 15, 2014, 08:57:52 AM
Quote from: olsen;773022
Never say never.
That's the spirit!


Quote from: olsen;773022
The hard part is in figuring out if the result is sufficiently robust and does not cause important application software to fail. In short, while the code does work, it needs a QA team to make sure it's up to standards: beta testing, and fixing the bugs.
QA and testing work might be something which could be distributed well enough on a voluntary team.
There are still some parties put quite some man power and energie in 68K development right now.
I think here of the efforts to design compatible chipsets and 68k cores.
These teams also needs and use QA, to ensure that the chipset is compatible and the CPUs are compatible.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 15, 2014, 10:24:12 AM
Quote from: olsen;773022
If you can find somebody to pay for that, then the current owner of the operating system may actually want to sell it, if asked. Mind you, that would only give you an updated OS 3.1, and OS 3.5 and beyond would still require more work for integration into the whole.

Well, actually, it would give you a bit more than just 3.1 plus an updated workbench because you can surely count me in. But we would be still short of Reaction, the updated FFS, the updated console, the updated RAM, the updated exec, the updated SCSI and the updated SetPatch. The only stuff from my side that depends on Reaction is BenchTrash, and I would hope that I'll find an older release without Reaction (just gadtools) somewhere.

Anyhow, whether that's financially viable is the next big question. I cannot answer that.
Title: Re: Layers.library V45 on the aminet
Post by: biggun on September 15, 2014, 10:40:33 AM
Olsen , Thomas,

I have to ask a stupid question here.

When you would such a possible buyout of AMIGA OS - with the existing free AROS.
Where are the advantages?

Is AROS so far from this?
Or would AROS have already some areas where its ahead - like a MUI clone etc?

What is AROS really missing today?
Title: Re: Layers.library V45 on the aminet
Post by: vxm on September 15, 2014, 10:45:04 AM
Quote from: Cosmos;773018
I only wanna explain that the quality of the code is very important.:)

And the problem is that each of you is right.
One said where to go while the other say how to go.
Then, each of you take one end of the same rope and pull very exactly in the opposite direction of the other. So, inevitably, nothing is moving forward.

Remenber, your discussion is about a 7 MHz clocked hardware.
Synergy will always be more profitable than a true false antagonism.
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 15, 2014, 10:50:43 AM
Quote from: Thomas Richter;773026
Well, actually, it would give you a bit more than just 3.1 plus an updated workbench because you can surely count me in. But we would be still short of Reaction, the updated FFS, the updated console, the updated RAM, the updated exec, the updated SCSI and the updated SetPatch. The only stuff from my side that depends on Reaction is BenchTrash, and I would hope that I'll find an older release without Reaction (just gadtools) somewhere.

Anyhow, whether that's financially viable is the next big question. I cannot answer that.


ReAction is one of H&P's contributions to the 3.5/3.9 product. As for FFS and other operating system modules which Heinz Wrobel worked on (FFS, SCSI, SetPatch), I suppose it would be his call whether or not these could be included. My own contributions to the product make up a sizable bunch, too, so there's a possibility to roll all of that into a product. Let's call it "AmigaOS 𝜋" ;)
Title: Re: Layers.library V45 on the aminet
Post by: warpdesign on September 15, 2014, 10:52:20 AM
Quote from: biggun;773027
Olsen , Thomas,

I have to ask a stupid question here.

When you would such a possible buyout of AMIGA OS - with the existing free AROS.
Where are the advantages?

Is AROS so far from this?
Or would AROS have already some areas where its ahead - like a MUI clone etc?

What is AROS really missing today?


Seems like AROS doesn't run well on true (slow) 68k Amigas.

I don't know if it's far, but it doesn't run correctly. AROS on a real Amiga seems fine to run some (non-DOS) games but it seems to be it.

That's a difference.
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 15, 2014, 10:55:09 AM
Quote from: biggun;773027
Olsen , Thomas,

I have to ask a stupid question here.

When you would such a possible buyout of AMIGA OS - with the existing free AROS.

I do not understand the question, could you reword it?

Quote from: biggun;773027

Where are the advantages?

Is AROS so far from this?
Or would AROS have already some areas where its ahead - like a MUI clone etc?

What is AROS really missing today?

I have no idea, since I did my best not to get involved with AROS. Not out of spite or antagonism, it's just that because of my involvement with the Amiga operating system I did not want to give anybody enough rope to hang the AROS project by.
Title: Re: Layers.library V45 on the aminet
Post by: biggun on September 15, 2014, 11:08:39 AM
Quote from: olsen;773031
I do not understand the question, could you reword it?


I used AROS a couple times on x86.
On x86 AROS looked very amiga-ish and very good.
I compiled a couple of selfwritten Amiga shell tools for it.
This worked fine and the programs ran fine.
From just having a gimse look - it looked very AMIGA like and it looked working to me.

I have not used AROS on 68K so far, so I have no clue what is missing there.
Maybe not much?


I generally like the idea to continue developing AMIGA OS for 68k very much.

When I understood you right you and Thomas were discussing the option to develop a new AMIGA OS version - e.g 3.9.1 or whatever..

My question was : Can someone give a statement how close/far the result would be to what AROS is today.

I wonder what the percentage of AROS to AMIGA completness is today.
If for example AROS has 95% of what is needed to be a 100% AMIGA OS replacement ?
Then maybe a bounty to get a knowledgeable developer that now how to code this part for AMIGA OS would be an option?

Or maybe just buying out the right of this part of AMIGA OS 3.1?
Title: Re: Layers.library V45 on the aminet
Post by: bloodline on September 15, 2014, 11:21:09 AM
Quote from: biggun;773032
I used AROS a couple times on x86.
On x86 AROS looked very amiga-ish and very good.
I compiled a couple of selfwritten Amiga shell tools for it.
This worked fine and the programs ran fine.
From just having a gimse look - it looked very AMIGA like and it looked working to me.

I have not used AROS on 68K so far, so I have no clue what is missing there.
Maybe not much?


I generally like the idea to continue developing AMIGA OS for 68k very much.

When I understood you right you and Thomas were discussing the option to develop a new AMIGA OS version - e.g 3.9.1 or whatever..

My question was : Can someone give a statement how close/far the result would be to what AROS is today.

I wonder what the percentage of AROS to AMIGA completness is today.
If for example AROS has 95% of what is needed to be a 100% AMIGA OS replacement ?
Then maybe a bounty to get a knowledgeable developer that now how to code this part for AMIGA OS would be an option?

Or maybe just buying out the right of this part of AMIGA OS 3.1?
Last time I tested AROS68k two things stuck out:
Workbook (Workbench clone), needs some polish.
Low level hardware drivers need work, the obvious being graphics.library which, IIRC is entirely CPU driven for Amiga Naive modes, was slow on a real Amiga but acceptable on emulation, by which point one would use RTG :-)
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 15, 2014, 11:42:26 AM
Quote from: biggun;773027
Olsen , Thomas,

I have to ask a stupid question here.

When you would such a possible buyout of AMIGA OS - with the existing free AROS.
Where are the advantages?

Is AROS so far from this?
Or would AROS have already some areas where its ahead - like a MUI clone etc?

What is AROS really missing today?

First what do you mean when you say AROS? Here it seems you use it for AROS X86. AROS 68k is very different to the others (even though it inherits most of the advantages and disadvantages) because you can directly mix 68k with AROS 68k. From the view of a application there is no difference. AROS 68k when you download the nightly build is more or less a very basic 3.1. installation with Roms, small editor, more or less good-looking icons, MUI in form of Zune (still missing parts) and Wanderer as desktop. Basic problems with it are that Zune is still not 100% MUI38 resulting that not all MUI programs work or at least only partly work. The desktop Wanderer is based on Zune and slow, has bugs and is limited. That is what people look at and make (misleading) judgements on AROS. Then there are typical basic libs and devices from 3.1. that implement gadtools, intuition, AHI, CybergraphX 3 and so on.

The nice thing about Aros is you can replace almost everything, you can add installer by copying it in C, you can replace Wanderer with another desktop (I use Magellan), you can easily replace Zune with MUI (what I did in my distribution) and you can add almost everything by just copying files. That is how I created my distribution.

I have f.e. added almost any compiler from 68k to my distribution and they all work (including all examples). In newest version I just upload I have included working Modula 2 and Oberon compiler and the newest port of Freepascal (from this weekend). All were not created for Aros 68k because it did not exist at that time but all work on it.

I cannot say much about Aros 68k on real hardware, Toni optimized it recently and Wawa wrote that it becomes usable (on 68060).
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 15, 2014, 12:01:21 PM
as just a noob tester im not likely fully entitled to talk about aros, so take my opinion with a prize of salt.
workbook is a problem or a question here, it has been meant as a basic desktop replacement for limited systems but isnt being developed now. for the time being there is scalos being incorporated into aros (contributions) and also magellan could be put there i guess. also wanderer is being updated afaik, so at some point we will have at least three full blown desktop alternatives. the simplistic floppy based replacement could still need some attention, if any 68k c/asm coder was interested to finish its implementation.

the main problem of aros 68k is low level stuff: device drivers, but also graphics library planar/chunky conversion, some clipping problems. generally efficiency also in exec (i dont know if its possible to reach the aos levels) and probably dos data transfer could be optimised. there is also still missing functionality in gfx drivers for amiga chipset.

having that things like aros version of poseidon could be reintroduced and made working with 68k hardware and existing drivers or their aros replacements if neccessary.
Title: Re: Layers.library V45 on the aminet
Post by: biggun on September 15, 2014, 12:23:24 PM
Hi Olaf,

From what you say AROS 68K is already or can already be a very good AMIGA OS replacement?


If there are areas where performance could be improved like e.g EXEC, or LAYERS.
Would these be areas where some geeks ould help?

I would assume Cosmos would be talented for tuning Exec?

And I would think that Thomas would be the perfect guy to do layer super fast?
Title: Re: Layers.library V45 on the aminet
Post by: itix on September 15, 2014, 12:23:28 PM
Quote from: olsen;773022

If you can find somebody to pay for that, then the current owner of the operating system may actually want to sell it, if asked.


This is the black hole I mean. There is nobody to invest this money and then this current owner, whatever company it is. Re-establishing OS3 development would help MorphOS and AROS but makers of that another OS what I dont mention here surely wont agree.
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 15, 2014, 12:29:43 PM
Quote from: biggun;773037
Hi Olaf,

From what you say AROS 68K is already or can already be a very good AMIGA OS replacement?


If there are areas where performance could be improved like e.g EXEC, or LAYERS.
Would these be areas where some geeks ould help?

I would assume Cosmos would be talented for tuning Exec?

And I would think that Thomas would be the perfect guy to do layer super fast?


Thomas (as Olsen and others) "would" be perfect but he has already explained that he is not allowed to do so because of contracts he signed in the past. Everyone who was involved in AmigaOS development in the past has signed such contracts it seems, almost like a weapon to hinder competition. But nevertheless they cannot directly contribute because it could used against Aros then :(
Title: Re: Layers.library V45 on the aminet
Post by: kolla on September 15, 2014, 12:41:51 PM
Lesson to learn: never sign any NDA when it comes to software development, it can and will work against you.
Title: Re: Layers.library V45 on the aminet
Post by: warpdesign on September 15, 2014, 12:57:02 PM
Maybe these NDAs are time-limited (I wish they are) ?
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 15, 2014, 01:09:57 PM
Quote from: warpdesign;773041
Maybe these NDAs are time-limited (I wish they are) ?


it seems not :(
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 15, 2014, 01:13:37 PM
Quote from: olsen;773029
ReAction is one of H&P's contributions to the 3.5/3.9 product. As for FFS and other operating system modules which Heinz Wrobel worked on (FFS, SCSI, SetPatch), I suppose it would be his call whether or not these could be included. My own contributions to the product make up a sizable bunch, too, so there's a possibility to roll all of that into a product. Let's call it "AmigaOS 𝜋" ;)

Given that I'm a mathematician, I kinna like the name. I believe the fixes for console could be re-done (there isn't really much), there's not much to do for RAM at all, but FFS requires at least a couple of tweaks (ACTION_CLOSE returning the wrong value, ACTION_FLUSH is not waiting, 4GB support, and I would strongly suggest to include NSD *and* TD64 support, and probably a couple of other issues I don't remember). SetPatch... Well, ExAllEnd() was broken, but there are probably more issues that got fixed. scsi.device  - I have no clue.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 15, 2014, 01:15:55 PM
Quote from: kolla;773040
Lesson to learn: never sign any NDA when it comes to software development, it can and will work against you.

Then you will never be able to work in professional (as in: for money) software development. Such NDAs are quite common, and of course, the they forbid you to take the developed software and re-sell that to a competitor. Or would you pay for a software just to see that your competitor would get access to it, too?

It's a bit different for software that was licensed.
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 15, 2014, 01:18:59 PM
Quote from: Thomas Richter;773044
Then you will never be able to work in professional (as in: for money) software development. Such NDAs are quite common, and of course, the they forbid you to take the developed software and re-sell that to a competitor. Or would you pay for a software just to see that your competitor would get access to it, too?

It's a bit different for software that was licensed.

take the software and resell it yes of course, but in this case you have said it forbids you any source contributions to Aros even if there is no original line of code included just because you had access to the old sources. That is completely different...

good to take a lot of devs out of game
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 15, 2014, 01:32:58 PM
Quote from: vxm;773028
And the problem is that each of you is right.
One said where to go while the other say how to go.
Then, each of you take one end of the same rope and pull very exactly in the opposite direction of the other. So, inevitably, nothing is moving forward.

Remenber, your discussion is about a 7 MHz clocked hardware.
Synergy will always be more profitable than a true false antagonism.

Well, look, first of all, I don't think we're "pulling in opposide directions", or that we aren't moving. This thread is about a move, after all, and I hope it's a move in the right direction.

Second, whether a processor is 7Mhz or not does not matter: If a given function (say AndRectRegion()) takes 1% of overall calling time to move a window, it does not matter whether you speed this up by a factor of two (realistic, if AllocMem is bypassed) or a factor of 1000 (unrealistic, unless you replace it by a NOP), the net effect will be NIL. It's really a very elementary truth that is independent of the processor speed. To get a speedup of two, *every single* function in the call path would have to be speed up by the very same factor, and that's not going to happen.

The problem really is that Cosmos has apparently never worked in a larger software project with exploding complexity, and thus has no feeling in what type of modifications one would want to make, and in which step of the project. Yes, of course it makes sense to optimize a bottleneck of a program, and there to use processor-specific code. But it does not make sense if you have additional constraints that are harder to characterize, such as maintainability, or portability. If the code can work on an old machine, and the speed impact by not using the latest processor instructions is below measurable, it makes no sense to use such optimizations. Basically you compromize compatibility and get nothing in return. In the same way, it does not make sense to replace an AllocMem() by a copy on the stack (all provided this is valid) if you don't receive a measurable effect. Again, you would compromize maintainability (as in: There is a single constructor call for a certain object) and would not gain anything measurable in return.

As always, you have to find compromizes in development, especially when it comes to larger and complex problems, and "running time" is not the one and only goal. You not only want to deploy your software on a wide variety of hardware, you also want compatibility to existing software, and you also want to be able to read your code from ten years from now. You also want that customers can install and use the software easily, and are not confused by compatibility issues that version C of a library can only work with programs P and Q, but program R requires version B, and program S may work with C, but only if specific settings are made...

The overall problem cannot be reduced to a simple count of cycles.
Title: Re: Layers.library V45 on the aminet
Post by: psxphill on September 15, 2014, 01:37:40 PM
Quote from: Thomas Richter;773044
Such NDAs are quite common, and of course, the they forbid you to take the developed software and re-sell that to a competitor.

That isn't legal even if you didn't sign an NDA. As long as you don't disclose anything that could only be learnt during your contract then you can contribute to AROS just fine.
 
 What you are describing sounds more like a non-compete clause, which isn't going to be in force by now (if they try to say it is then the court would rule that it was an unfair clause).
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 15, 2014, 01:40:43 PM
Quote from: Thomas Richter;773046
Well, look, first of all, I don't think we're "pulling in opposide directions", or that we aren't moving. This thread is about a move, after all, and I hope it's a move in the right direction.

Second, whether a processor is 7Mhz or not does not matter: If a given function (say AndRectRegion()) takes 1% of overall calling time to move a window, it does not matter whether you speed this up by a factor of two (realistic, if AllocMem is bypassed) or a factor of 1000 (unrealistic, unless you replace it by a NOP), the net effect will be NIL. It's really a very elementary truth that is independent of the processor speed. To get a speedup of two, *every single* function in the call path would have to be speed up by the very same factor, and that's not going to happen.

The problem really is that Cosmos has apparently never worked in a larger software project with exploding complexity, and thus has no feeling in what type of modifications one would want to make, and in which step of the project. Yes, of course it makes sense to optimize a bottleneck of a program, and there to use processor-specific code. But it does not make sense if you have additional constraints that are harder to characterize, such as maintainability, or portability. If the code can work on an old machine, and the speed impact by not using the latest processor instructions is below measurable, it makes no sense to use such optimizations. Basically you compromize compatibility and get nothing in return. In the same way, it does not make sense to replace an AllocMem() by a copy on the stack (all provided this is valid) if you don't receive a measurable effect. Again, you would compromize maintainability (as in: There is a single constructor call for a certain object) and would not gain anything measurable in return.

As always, you have to find compromizes in development, especially when it comes to larger and complex problems, and "running time" is not the one and only goal. You not only want to deploy your software on a wide variety of hardware, you also want compatibility to existing software, and you also want to be able to read your code from ten years from now. You also want that customers can install and use the software easily, and are not confused by compatibility issues that version C of a library can only work with programs P and Q, but program R requires version B, and program S may work with C, but only if specific settings are made...

The overall problem cannot be reduced to a simple count of cycles.

one question... I understand you are not allowed to contribute any changes to Aros because of the contracts. Would you be allowed to look at the Aros sources and give tips what to improve and how (in abstract form) or would that be problematic too? And someone else does the real changes? I think even the Aros devs would be grateful for tips.
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 15, 2014, 01:41:21 PM
Quote from: Thomas Richter;773043
Given that I'm a mathematician, I kinna like the name. I believe the fixes for console could be re-done (there isn't really much), there's not much to do for RAM at all, but FFS requires at least a couple of tweaks (ACTION_CLOSE returning the wrong value, ACTION_FLUSH is not waiting, 4GB support, and I would strongly suggest to include NSD *and* TD64 support, and probably a couple of other issues I don't remember). SetPatch... Well, ExAllEnd() was broken, but there are probably more issues that got fixed. scsi.device  - I have no clue.


just make pfs3 the official filing system, it includes all functionality, is open and currently maintained by toni wilen and include ffs as is for legacy and backwards compatibility and you are done.
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 15, 2014, 01:53:32 PM
Quote from: OlafS3;773045
take the software and resell it yes of course, but in this case you have said it forbids you any source contributions to Aros even if there is no original line of code included just because you had access to the old sources. That is completely different...

good to take a lot of devs out of game


this argument is void in respect to reimplementing aos functionality in a clean room environment. if he had not signed the nda and not gained an insight into amiga system source code he would have no knowledge of its internals to contribute to aros. now, that he did and have its knowledge he could be extremly helpful if only there was a counterpart to cooperate and establish such a clean room approach. ability to read and understand the code en gross and communicate things clearly is as important as coding itself i guess.
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 15, 2014, 01:55:01 PM
Quote from: biggun;773037
Hi Olaf,

From what you say AROS 68K is already or can already be a very good AMIGA OS replacement?

I'm sorry, this is not for me to say because I neither know the current state of affairs of the AROS 68k build, nor am I familiar with the AROS project as it is today. Before I could give you an assessment I ought to know what I'd be talking about, which I don't :(

Quote from: biggun;773037

If there are areas where performance could be improved like e.g EXEC, or LAYERS.
Would these be areas where some geeks ould help?

From the impression I got so far, it seems to me that the interest may be there, but the question is whether this is sufficient to polish the code as it is.

We are not talking about some old, small sized operating system component for which tangible improvements are easily achieved (the "low-hanging fruit" if you want to call it that). Any measurable improvements would have to come through analyzing and re-engineering the code. This requires a bit of experience and knowledge of the technology. Back in the day you could learn all that, and apply it, in a few years.

I have no idea how the talent situation is today. Let's see some code, that is usually the best way to get an impression of how well-prepared a programmer is to tackle Amiga software development.

Quote from: biggun;773037

I would assume Cosmos would be talented for tuning Exec?

And I would think that Thomas would be the perfect guy to do layer super fast?

Frankly, I cannot judge how far Cosmos' talents extend beyond the 68k assembly language optimizations he showed. Exec is pretty well-designed and well-implemented (actually, the InitStruct() stuff was partly obsolete when it shipped, and how Signal exceptions are handled makes you wonder why the API is incomplete), and the best thing you can do without making radical changes to the implementation seems to be to shave off the rough edges through small optimizations. The thing is, for optimizations to made in this type of software you both need to know the context in which your optimization would have to be effective, and you need to measure if the optimization actually did make things better. So far, from Cosmos' own words, he does not seem to be into measuring the effects, he prefers to infer the effect from the changes he made.

As for Thomas, you may not be aware of it, but he is a physicist by training, which accounts for his background in mathematics and computer science. He has lectured, published papers, etc. He's an actual scientist. Why is this important? Physics is an empirical science, which builds models of the world through the use of mathematics. To make sure that your models are sufficiently accurate representations of reality, you need to test and verify them. Any claim you can make about the models must be backed up by evidence. See where I'm going?

Thomas built his layers.library by analyzing how the original worked, built a new one designed to solve the same problem better and verified that it does accomplish this goal. This approach represents best engineering practice. As far as I know the performance improvements are significant and can be measured. These improvements are on a scale which exceeds what could be achieved by fine-tuning the underlying assembly language code. No matter how much effort you put into shaving cycles off an inefficient 'C' compiler translation of the original code, if that code uses a technique (algorithm) that solves the wrong problem, or solves it in such a way that it wastes time, then you still have a poor solution. What's the alternative? Replace the algorithm with something that is more suited to the task. This is what Thomas did.

Replacing the algorithm produces significant leverage. To give you an example: if you have used the standard file requester in AmigaOS 3.1 and 3.5 you may have noticed that there is a performance difference between the two. The original 3.1 version became noticeably slower the more and more directory entries it read and displayed. The 3.5 version did not become noticeably slower. This was achieved by replacing the algorithm by which the file requester kept the directory list in sorted order. In the 3.1 version, doubling the number of directory entries read caused the file requester to spend four times as much effort to keep the list sorted, and no degree of low level assembly optimizations would have helped to improve this. What did bring improvements was to replace the sorting algorithm, so that doubling the number of directory entries only about doubled the amount of time needed to keep it sorted.

This is how you get to "super fast", and Thomas is your man. Cosmos, I'm not so sure about.
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 15, 2014, 02:10:54 PM
Quote from: psxphill;773047
That isn't legal even if you didn't sign an NDA. As long as you don't disclose anything that could only be learnt during your contract then you can contribute to AROS just fine.
 
 What you are describing sounds more like a non-compete clause, which isn't going to be in force by now (if they try to say it is then the court would rule that it was an unfair clause).


i trust that since thor and olsen seriously consider that there is a threat then there must be one. beyond all else they have personal experience with the commercial entities in question they have been working for and im sure they are basing their opinion on some experience, be it personal or general, which may be not available to others.
Title: Re: Layers.library V45 on the aminet
Post by: Thorham on September 15, 2014, 02:19:27 PM
Quote from: olsen;773051
What did bring improvements was to replace the sorting algorithm, so that doubling the number of directory entries only about doubled the amount of time needed to keep it sorted.
It would've been even better if they simply read the whole directory first, then sorted it with the right sorting algorithm, and finally display the results. DirectoryOpus 5.90 does that.

Quote from: olsen;773051
This is how you get to "super fast", and Thomas is your man. Cosmos, I'm not so sure about.
Perhaps, but when you work with some resourced binary, it can't hurt to clean up the compiler mess so that you get much more readable code. After that you can try to replace algorithms.
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 15, 2014, 02:20:01 PM
Quote from: OlafS3;773039
Thomas (as Olsen and others) "would" be perfect but he has already explained that he is not allowed to do so because of contracts he signed in the past. Everyone who was involved in AmigaOS development in the past has signed such contracts it seems, almost like a weapon to hinder competition. But nevertheless they cannot directly contribute because it could used against Aros then :(


Speaking for myself, I am not aware of any NDAs which still cover the field I'm working in that prevent me from contributing to a project such as AROS. With very few exceptions the NDAs I signed are no longer relevant because the companies with which I signed them went out of business a long time ago. Such is the nature of the Amiga business :(

I'm just a cautious fellow, and I don't want to be the guy who compromises a project such as AROS because somebody got it into his head that a knowledge transfer has taken place which must have happened because one guy had access to some original source code. In my humble opinion AROS is better off if its designs are based strictly upon available documentation only (the "clean-room implementation"), and there is no reason whatsoever to suspect that privileged information (if there is such a thing in the Amiga field) may have been used to help it along.
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 15, 2014, 02:37:30 PM
I understand :(

it is a pity that the few experienced devs left cannot contribute because of silly contracts from long ago
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 15, 2014, 02:43:36 PM
Quote from: Thorham;773054
It would've been even better if they simply read the whole directory first, then sorted it with the right sorting algorithm, and finally display the results. DirectoryOpus 5.90 does that.
The standard file request (in asl.library) interleaves reading and sorting the list as new entries come in. This can be done very quickly, in parallel while the file system is reading the directory. It's a reasonably clean design, whose "downfall" was the choice of sorting algorithm which eventually took more time to run than reading the directory.

If you read the entire directory before you start sorting, you're out of luck if reading the directory takes much longer than sorting it would. It happens. The way the standard file requester solves the problem is arguably a solution which handles both the short and the long directory case more elegantly. And you can even change the window size, type in a new directory or file name, etc. while it's reading and sorting the directory contents.

Quote from: Thorham;773054
Perhaps, but when you work with some resourced binary, it can't hurt to clean up the compiler mess so that you get much more readable code. After that you can try to replace algorithms.
I don't think it works any more at a certain size of project. You can't necessarily infer from disassembly, even after cleanup and documentation work, why the original high-level language (that would be 'C' or something more complex such as C++) implementation does what it does, and if the implementation is correct.

For example, at the heart of Intuition there is a state machine which receives, translates and distributes input events depending upon which events arrived earlier. If you move the mouse over the screen title bar and press the left mouse button, Intuition will change into a state in which every movement of the mouse will result in a screen drag operation. This is how it works. If you broke down the entire Intuition binary into plain 68k assembly language, I would venture that you will have hard time identifying the individual event state handlers. For that you are best advised to stick to the original 'C' code, because there you can see plainly how the design fits together, and why it makes sense.

Another example: for OS4 the original timer.device was ported to 'C'. The original timer.device was written in 68k assembly language, and documented source code exists. As it turned out there was a surprise waiting in that code after the initial 'C' language port was complete. Back in 1989/1990 Michael Sinz at Commodore modified the timer.device not to use two different time sources any more (UNIT_VBLANK and UNIT_MICROHZ used different CIA A and CIA B timers, which had different granularities), but to use single CIA timer instead. That timer had much higher resolution and precision, which was a great improvement.

It turned out that when the 'C' port of timer.device was reviewed, all the old obsolete CIA A and CIA B timer code was still in there, and a good part of the 'C' port was effectively useless. Again, observations such as these, which lead to irrelevant code being discovered and removed, require a high level view of the code, which for assembly language (by its very nature) is difficult to find.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 15, 2014, 02:48:08 PM
Quote from: wawrzon;773049
just make pfs3 the official filing system, it includes all functionality, is open and currently maintained by toni wilen and include ffs as is for legacy and backwards compatibility and you are done.

Are we? Ok, to be frank, I do not know (nor have personally met) Toni, nor have I looked at PFS3. Let me tell you why I'm a bit critical about PFS3 (and actually, most alternative filing systems in general, this is not specific to PFS3 which, as said, I really haven't tried).

First of all, the whole dos (Tripos) is written around the FFS construction, with all its weaknesses and benefits. For example, transferal of locks between two drives but the same medium (good), or the almost unimplementable ACTION_EX_NEXT. (bad)

FFS may not be "smart", but it may be faster than you think. Or "fast" depending on which type of operation you want to perform. If I just want to open one (or multiple) files, FFS needs not to read an entire directory (unlike FAT or ext) but uses a pretty fast hash-algorithm. All the information about a file is in a single block, and FFS can block-transfer data between the file on disk and the target buffer by going directly into the device. (Leaving the MaxTransfer and Mask aside). That's not unique to FFS, of course, but what is probably unique (and what I haven't seen anywhere else) is that while FFS is "busy" with a long DMA transfer, additional incoming requests can be handled simultaneously. That is, the FFS is a threaded file system and handles each request in a separate thread (not task, not process). Thus, one can fire off a request, and a second task can do the same at the same time, and FFS will be able to get the second request done while the first is running, provided there are no conflicts. I'm not sure whether PFS3 can do this, but SFS did not (back then, when I checked), and no other FS on the Amiga could.

FFS is *not* slow. Ok, it is slow in *one particular* discipline, and that's listing of directories. This is because every file requires a single block as file header. That is, when reading a directory, more IO transfers have to be made (unfixable) and a lot of disk-gronking happens (avoidable by smarter allocation). This is, as always, a compromize that has been made when FFS was constructed, and the compromize was simply to make "opening and reading of files" as fast as possible, with the drawback of "listing directories" being slow. Which operation is used most? I don't know, and I haven't measured, but my gut feeling is that the FFS decision to optimize for fast data transfer (and not for fast directory transfer) was actually not such a bad decision.

Other filing systems use more complex directory structures, with the benefit of making directory reading faster, but making file manipulation slower.

I haven't measured, but I consider it hard to construct a filing system that requires less disk operations to actually find and open a file on disk than the FFS. That seems to be a good choice if I/O is slow and the CPU is fast. Maybe that's the wrong assumption today (I don't know) but before I would pick another FS, I would prefer to see some hard facts about the performance of PFSn, and I do not only mean speed.

Are all important packets implemented? Correctly? Does it support hard and soft links? File notes? File Dates? Does it operate correctly if multiple tasks operate simultaneously on the disk? Does it perform well if multiple tasks operate on the disk? How many disk operations does it take to open a file? Create a file? Write a file? List a directory? How does it behave if we try to corrupt the disk? Turn the system off (FFS is not exactly a top performer here, don't tell me, I know).

My personal feeling is that the FFS has reached a certain level of stability given that it has been around for such a long time that it's hard to replace it by anything more stable. If any, I would only make minor changes that are backwards compatible to existing FS-structure, such as improving the block-allocation policy (keep directory blocks close to each other, do not scatter them, avoiding the disk gronking) or improving the 64-bit support.

Oh, and last but not least: You surely want a file system that can read your existing disks. From what I read I believe PFS3 can handle this?
Title: Re: Layers.library V45 on the aminet
Post by: modrobert on September 15, 2014, 02:50:38 PM
Quote from: OlafS3;773056
I understand :(

it is a pity that the few experienced devs left cannot contribute because of silly contracts from long ago


They can contribute to Aros if a bounty making OS3.1 open source succeeded. This would effectively end the NDA, or did I miss something (again)?

Also, Thomas Richter and olsen have effectively convinced me that binary patching is bad in the current situation, only took like ten posts of explaining to do it (hehe). Still, I can't help liking Cosmos and respect what he does, it goes beyond logical reasoning, so no need to convince me further.
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 15, 2014, 02:58:25 PM
Quote from: wawrzon;773053
i trust that since thor and olsen seriously consider that there is a threat then there must be one. beyond all else they have personal experience with the commercial entities in question they have been working for and im sure they are basing their opinion on some experience, be it personal or general, which may be not available to others.

We may not agree with the situation, but the fact is that money changed hands to acquire the Amiga operating system, and as such represents a significant investment for the buyer.

The owner of the technology is naturally interested in preserving the value of the investment, which is why programmers who were involved in AmigaOS development work signed contracts governing what we may or may not do with the knowledge we gained. Unless these contracts are canceled, we are bound by them.

How much of a risk there would be in violating the terms of these contracts is difficult to say. Speaking for myself, I don't really want to find out because it is not something which I consider *that* important.
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 15, 2014, 03:04:03 PM
Quote from: modrobert;773059
They can contribute to Aros if a bounty making OS3.1 open source succeeded. This would effectively end the NDA, or did I miss something (again)?

Also, Thomas Richter and olsen have effectively convinced me that binary patching is bad in the current situation, only took like ten posts of explaining to do it (hehe). Still, I can't help liking Cosmos and respect what he does, it goes beyond logical reasoning, so no need to convince me further.


To be honest I do not believe that such a bounty has any chance because of both the money it would need and the parties involved. You read the discussions here, people will say why donating for such a bounty when you can get everything in amigaforever or for free (illegal). Most NG supporter will say for what do we need the old sources (in case of AmigaOS they already have access). It would be of big benefit for AROS and MorphOS to remove unknown compatibility issues and similar but that brings me to the third party I do not need to name who has no interest to support AROS or MorphOS. And a common spirit between the camp is not there (expecially regarding parts of the core developers). AROS certainly is the exception because of the openness. Short: Someone can try it out like I did with Magellan. Ask the known parties and if they really say yes make a bounty.
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 15, 2014, 03:06:36 PM
Quote from: olsen;773060
We may not agree with the situation, but the fact is that money changed hands to acquire the Amiga operating system, and as such represents a significant investment for the buyer.

The owner of the technology is naturally interested in preserving the value of the investment, which is why programmers who were involved in AmigaOS development work signed contracts governing what we may or may not do with the knowledge we gained. Unless these contracts are canceled, we are bound by them.

How much of a risk there would be in violating the terms of these contracts is difficult to say. Speaking for myself, I don't really want to find out because it is not something which I consider *that* important.


We understand that, nobody can expect someone else taking legal risk, even if they would be theoretical (and I do not think that they are totally theoretical even today). Nobody is forced to sign such a contract.
Title: Re: Layers.library V45 on the aminet
Post by: warpdesign on September 15, 2014, 03:46:31 PM
Seeing what happened since 1999 with owners of the OS, I don't see a bounty happening either, or it would be insanely expensive and would come with unacceptable conditions anyway.

A bounty to bring AROS on par with AOS would be possible though, and free of any evil conditions.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 15, 2014, 03:59:52 PM
Quote from: OlafS3;773045
take the software and resell it yes of course, but in this case you have said it forbids you any source contributions to Aros even if there is no original line of code included just because you had access to the old sources. That is completely different...

No, look. It does not forbid me to contribute *anything* to AROS. But if parts of the contribution to 3.9 was created by taking the original AmigaOs source (say, for the sake of the argument "C:more") and this source was improved by modifications paid under contract, it is quite clear that the work created this way cannot be contributed. It is, essentially, still CBM code, under license (or owned by, I don't know) H&P or Hyperion. Same goes for layers - yes, a good deal of code had been replaced, but the majority is still CBM code. If I get code from a client (H&P, or Hyperion) and we have an agreement that this is proprietary code, I believe it is also a matter of trust that it remains proprietary, leaving all legal concerns aside.  

Again, as Olsen said (and I did before) the best possible solution for AROS is really a clean-room development starting from the documented API because you're then really free from any claims from third parties. Again, I can provide answers to "dark spots" in the API (to my very knowledge, which may or may not be correct - and given that there are already very reliable sources like the Guru book) but code brings me (and AROS) into a situation which is quite delicate.
Title: Re: Layers.library V45 on the aminet
Post by: psxphill on September 15, 2014, 04:22:49 PM
Quote from: olsen;773057
Back in 1989/1990 Michael Sinz at Commodore modified the timer.device not to use two different time sources any more (UNIT_VBLANK and UNIT_MICROHZ used different CIA A and CIA B timers, which had different granularities), but to use single CIA timer instead. That timer had much higher resolution and precision, which was a great improvement.

It turned out that when the 'C' port of timer.device was reviewed, all the old obsolete CIA A and CIA B timer code was still in there, and a good part of the 'C' port was effectively useless. Again, observations such as these, which lead to irrelevant code being discovered and removed, require a high level view of the code, which for assembly language (by its very nature) is difficult to find.


Sounds like "Jumpy the Magic Timer Device", are you sure the code was all unused?
 
 
 
Quote from: Thomas Richter;773066
but code brings me (and AROS) into a situation which is quite delicate.

You can't contribute any of the code you received or were paid to write (and that doesn't matter whether you signed an NDA or not), but you were implying that under no circumstances could you contribute anything to AROS ever.
 
It would be pretty easy to prove in court where your contributions came from though, so as long as you are honest then you're fine.
 
 I'm pretty sure that quite a bit of AROS was written by people who had disassembled commodore's code & it already isn't a clean room implementation.
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 15, 2014, 04:36:12 PM
Quote from: Thomas Richter;773058
Are we? Ok, to be frank, I do not know (nor have personally met) Toni, nor have I looked at PFS3. Let me tell you why I'm a bit critical about PFS3 (and actually, most alternative filing systems in general, this is not specific to PFS3 which, as said, I really haven't tried).

First of all, the whole dos (Tripos) is written around the FFS construction, with all its weaknesses and benefits. For example, transferal of locks between two drives but the same medium (good), or the almost unimplementable ACTION_EX_NEXT. (bad)

FFS may not be "smart", but it may be faster than you think. Or "fast" depending on which type of operation you want to perform. If I just want to open one (or multiple) files, FFS needs not to read an entire directory (unlike FAT or ext) but uses a pretty fast hash-algorithm. All the information about a file is in a single block, and FFS can block-transfer data between the file on disk and the target buffer by going directly into the device. (Leaving the MaxTransfer and Mask aside). That's not unique to FFS, of course, but what is probably unique (and what I haven't seen anywhere else) is that while FFS is "busy" with a long DMA transfer, additional incoming requests can be handled simultaneously. That is, the FFS is a threaded file system and handles each request in a separate thread (not task, not process). Thus, one can fire off a request, and a second task can do the same at the same time, and FFS will be able to get the second request done while the first is running, provided there are no conflicts. I'm not sure whether PFS3 can do this, but SFS did not (back then, when I checked), and no other FS on the Amiga could.

FFS is *not* slow. Ok, it is slow in *one particular* discipline, and that's listing of directories. This is because every file requires a single block as file header. That is, when reading a directory, more IO transfers have to be made (unfixable) and a lot of disk-gronking happens (avoidable by smarter allocation). This is, as always, a compromize that has been made when FFS was constructed, and the compromize was simply to make "opening and reading of files" as fast as possible, with the drawback of "listing directories" being slow. Which operation is used most? I don't know, and I haven't measured, but my gut feeling is that the FFS decision to optimize for fast data transfer (and not for fast directory transfer) was actually not such a bad decision.

Other filing systems use more complex directory structures, with the benefit of making directory reading faster, but making file manipulation slower.

I haven't measured, but I consider it hard to construct a filing system that requires less disk operations to actually find and open a file on disk than the FFS. That seems to be a good choice if I/O is slow and the CPU is fast. Maybe that's the wrong assumption today (I don't know) but before I would pick another FS, I would prefer to see some hard facts about the performance of PFSn, and I do not only mean speed.

Are all important packets implemented? Correctly? Does it support hard and soft links? File notes? File Dates? Does it operate correctly if multiple tasks operate simultaneously on the disk? Does it perform well if multiple tasks operate on the disk? How many disk operations does it take to open a file? Create a file? Write a file? List a directory? How does it behave if we try to corrupt the disk? Turn the system off (FFS is not exactly a top performer here, don't tell me, I know).

My personal feeling is that the FFS has reached a certain level of stability given that it has been around for such a long time that it's hard to replace it by anything more stable. If any, I would only make minor changes that are backwards compatible to existing FS-structure, such as improving the block-allocation policy (keep directory blocks close to each other, do not scatter them, avoiding the disk gronking) or improving the 64-bit support.

Oh, and last but not least: You surely want a file system that can read your existing disks. From what I read I believe PFS3 can handle this?


i cannot exactly tell if pfs3 is threaded, but i do even guess it incidentally is. toni, who unfortunately is only a member on eab, but not here, could answer this in detail. the original coder whose name i dont remember was posting here i guess but im not sure anymore, the other person who comes to my mind is piru who did initial port and fixes to current gcc.

im absolutely not advocating sfs whatever in this respect, since from my user experience is rubbish, sorry to say.

also i did not say pfs is able to read ffs formatted media. sory, i realize it sounds like i did. what i wanted to say was, to keep ffs as is for legacy.
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 15, 2014, 05:13:46 PM
Quote from: psxphill;773069
Sounds like "Jumpy the Magic Timer Device", are you sure the code was all unused?
 
Yes. I started rewriting the 'C' port so that I could understand its inner workings better. Also, it provided an opportunity to pull code from subroutines (which became short functions) which were used exactly once into the respective functions which called them.

In the end I found that some of the functions were not getting called or referenced from anywhere else, and sure enough, these were the parts of the old timer.device which used to deal with the UNIT_VBLANK and UNIT_MICROHZ CIA timers, separately.

As far as I recall this specific code was not part of the timer.device in ROM, it was not even linked against it. But this obsolete code was still part of the SVN repository contents (and the CVS repository before that, and the RCS files before that), so it wound up getting ported to 'C'.
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 15, 2014, 05:34:50 PM
Quote from: modrobert;773059
Also, Thomas Richter and olsen have effectively convinced me that binary patching is bad in the current situation, only took like ten posts of explaining to do it (hehe).
It's not necessarily a bad idea, you just have to know to which end the patches are created. Collapsing more complex assembly code to less complex code, saving space and reducing execution time used to get a lot more respect when storage space was scarce and CPUs used to be far less powerful. Like, say, in the 1980'es and 1990'ies.

Let's say you had to ship a hot fix for a criticial firmware error to a few hundred thousand customers (or make that a few million), yet your operating system was firmly planted in ROM and the only way to make the fix work was to put it into a jump table in RAM, and that jump table was so small that you had to rewrite existing patch code to make room for you new patch. Then you'd call upon a specialist who would work on the task of letting the extra air out of the code and build the shortest possible patch that would fit.

This used to be such a highly specialized talent, and it solved such dire and unique problems that I have it on good authority that this kind of assembly language optimization was called a "spell", as in "magic spell".

Cosmos may not view his work this way, but I'd say that the changes he makes work better if considered as optimizations for space than as optimizations for performance. One question which this raises is what you do with the extra space, but let's not go there.

Optimizing assembly code can be a rewarding exercise, like solving a chess puzzle, or doing calculus (yes, some people do that as a hobby, like playing "Candy Crush"; I'm still holding out for "Calculus Crush" for the iPhone). It follows a certain set of rules, there are rigid constraints and the number of possible solutions is small. Perfect entertainment!

Nothing makes this a bad idea, but what you can achieve is limited, especially when you are shooting for performance optimizations. You have to find code that both can be optimized and "wants" to be optimized, too.

Code that can be optimized but "doesn't want" to be optimized is contributing very little to the running time of the software which it is a part of; if you improve its running time by 200%, but it's only getting invoked some 0.2% in total then you may have spent an entertaining evening, but the effect of you change is negligible.

Code than can be optimized and "wants" to be optimized could have its running time improved by 5%, but if it's used 60% in total you'll have a noticeable improvement, and will have spent an entertaining evening, too ;)
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 15, 2014, 06:33:15 PM
Quote from: olsen;773078
It's not necessarily a bad idea, you just have to know to which end the patches are created. Collapsing more complex assembly code to less complex code, saving space and reducing execution time used to get a lot more respect when storage space was scarce and CPUs used to be far less powerful. Like, say, in the 1980'es and 1990'ies.

Yes, indeed, these were the "even older days" of computing. Back then, in the 6502-times, squeezing more program into less RAM was pretty much a necessity given that you had so little of it. I remember back then on the Atari (yes, the Atari 800XL, same chip designer, different company), the file management system (back then called "DOS") was bootstrapped from disk, took probably 5K of your precious RAM space, and had pretty limited capabilities. Plus it took time to bootstrap that 5K (it wasn't a 1541, so it wasn't as bad as on the C64, after all.)

Indeed, one can try to rewrite the whole thing, throw out the less-used part of ROM space (for a parallel port interface that came so late to the market that no devices were ever made to fit into this port), and replace the newly available 3K of ROM with a more powerful version of the 5K DOS, and cleanup the math stuff on the way. For such extremely tiny systems, this type of hobby did make sense because it was a noticeable improvement (as in: 5K more for your programs from the total of 40K available). Not that it was commercially viable - it wasn't.  

Anyhow, byte counting stopped making sense, already when 512K were the norm, and priorities changed. As soon as projects go bigger, one starts to notice that there is no benefit in squeezing out each possible byte, or each possible optimization. There is too much code to look at, and problems are typically related to maintain the full construction rather than to make it fast.

As Olsen already said, either execution time is not critical because I/O or human input is limiting the speed, or 80% of the program time is spend in less than 20% of the program. In such a case, the 20% are then hand-tuned, probably written in assembly. For 68K, I did this myself. Nowadays, not even than anymore, we had a specialist for that in the company when I worked on problems that required this type of activity. Even then, it turns out that the really critical part is not even the algorithm itself, but to keep the data in cache, i.e. construct the algorithm around the "worker" such that data is ideally pipe-lined, and that again was done in a high-level language (C++).

To keep the story short, even today the use of Assembly even for optimization is diminishing. There are hot-spots where you have to use it, but if speed is essential, you typically want to be as flexible as possible to re-arrange your data structures to allow for fast algorithms, and to organize data such that the data access pattern fits to the CPU organization - and you don't get this flexibility in Assembler. It sounds weird, but a high-level language and more code can sometimes make an algorithm faster.

But anyhow, I confess I did byte counting in the really old days, two generations of computers ahead, and yes, it created a good deal of spaghetti code, though requirements were quite a bit different. http://www.xl-project.com/download/os++.tar.gz

It's part of becoming a good engineer to learn which tools you need to reach your goal, and which tools to pick for a specific use case, and foremost to understand what the problem actually is (this is more complicated than one may guess). Ill defined problems create ill program architecture. Not saying that I'm the perfect software engineer - I have no formal education in this sector - but at least I learned a bit of by failing often enough.
Title: Re: Layers.library V45 on the aminet
Post by: Heiroglyph on September 15, 2014, 06:53:14 PM
Byte counting is one thing, but have you seen the size of AROS 68k executables?

There are examples of commands in the c: directory where the OS3.1 version is a few hundred bytes, yet the AROS68k version is multiple thousands of bytes.

That's the type of thing that makes me facepalm when it comes to AROS.

It's not an issue of C vs. assembly either, as I have been working on real native versions based on their C code that are as small and sometimes smaller than the OS3.1 versions.

Sometimes it's added AROS specific calls, sometimes sloppy linking, often just awkward logic, but it's wasteful.

You can't throw away that much memory and disk bandwidth and expect it to run as well as the original OS did on the same hardware.
Title: Re: Layers.library V45 on the aminet
Post by: vxm on September 15, 2014, 07:18:03 PM
Quote from: Thomas Richter;773046
Well, look, first of all, I don't think we're "pulling in opposide directions", or that we aren't moving. This thread is about a move, after all, and I hope it's a move in the right direction.

Second, whether a processor is 7Mhz or not does not matter: If a given function (say AndRectRegion()) takes 1% of overall calling time to move a window, it does not matter whether you speed this up by a factor of two (realistic, if AllocMem is bypassed) or a factor of 1000 (unrealistic, unless you replace it by a NOP), the net effect will be NIL. It's really a very elementary truth that is independent of the processor speed. To get a speedup of two, *every single* function in the call path would have to be speed up by the very same factor, and that's not going to happen.

The problem really is that Cosmos has apparently never worked in a larger software project with exploding complexity, and thus has no feeling in what type of modifications one would want to make, and in which step of the project. Yes, of course it makes sense to optimize a bottleneck of a program, and there to use processor-specific code. But it does not make sense if you have additional constraints that are harder to characterize, such as maintainability, or portability. If the code can work on an old machine, and the speed impact by not using the latest processor instructions is below measurable, it makes no sense to use such optimizations. Basically you compromize compatibility and get nothing in return. In the same way, it does not make sense to replace an AllocMem() by a copy on the stack (all provided this is valid) if you don't receive a measurable effect. Again, you would compromize maintainability (as in: There is a single constructor call for a certain object) and would not gain anything measurable in return.

As always, you have to find compromizes in development, especially when it comes to larger and complex problems, and "running time" is not the one and only goal. You not only want to deploy your software on a wide variety of hardware, you also want compatibility to existing software, and you also want to be able to read your code from ten years from now. You also want that customers can install and use the software easily, and are not confused by compatibility issues that version C of a library can only work with programs P and Q, but program R requires version B, and program S may work with C, but only if specific settings are made...

The overall problem cannot be reduced to a simple count of cycles.

Pedagogically, it would have been more elegant and efficient to directly explain why everything has its reason for being.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 15, 2014, 07:32:35 PM
Quote from: Heiroglyph;773084
Byte counting is one thing, but have you seen the size of AROS 68k executables?

Why do you mind so much? The additional size is most likely due to the compiler startup code and some minimal glue code. If you compile (naively) a C executable on the Amiga, you also end up with an 8K binary (or something in that magnitude). You get only less for the commands in C: because the compiler is there setup to bypass the POSIX compatibility layer; you have a specialized compiler that allows you to jump into the head of your code without any startup code, hence allows you to make the startup yourself.

So for example, your average startup code will parse arguments for you by POSIX rules (AmigaOs does that for you with ParseArgs), will create stdout/stdin/stderr for you (AmigaOs will have its own calls for Output(), Input()) and will open the libraries for you (AmigaOs will require you to do that yourself without a startup code).

On the other hand, POSIX offers you an abstraction layer that makes AROS independent from the underlying Os that was used to compile it, and indpendent from the remaining infrastructure. It is hence much easier to compile executables for it by a standard compiler, without all the environment-specific logic. It's hence easier to contribute.

One way or another, I wouldn't be so worried about this. This problem will go away as soon as the infrastructure becomes more complete if it is a problem in first place. If you compare this with the early 1.2 Workbench disk, there (almost) every command in C: had the BCPL startup glue linked to it (because it was BCPL after all) that only vanished once the Software Distillery rewrote the whole stuff with a more capable compiler (or a compiler that was more adapted to the entire situation), namely Lattice C.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 15, 2014, 07:36:35 PM
Quote from: vxm;773087
Pedagogically, it would have been more elegant and efficient to directly explain why everything has its reason for being.

Yes, certainly. (-: But would that have stopped anyone from arguing? It probably goes without saying that every decision has its reason, and every situation has various perspectives from which you can look at them.
Title: Re: Layers.library V45 on the aminet
Post by: itix on September 15, 2014, 08:01:54 PM
Quote from: Thomas Richter;773058
FFS is *not* slow. Ok, it is slow in *one particular* discipline, and that's listing of directories.

It has been more than 15 years when I used FFS but I recall it had another deficiency: it is slow at seeking large files. This became problem when first Doom ports appeared to Amiga and their WADs were relatively large. This of course was not problem at design time when harddisks were small but expensive.

Quote
Other filing systems use more complex directory structures, with the benefit of making directory reading faster, but making file manipulation slower.

Which is not necessarily what user deem important. Slow directory reading is immediately visible to the user. User can see it, he can measure it with his wris%&$#?@!%&$#?@!%&$#?@!%&$#?@!ch. Faster opening or reading of files, I am not sure if user observes that.

But it should be also mentioned that part of slowness was due to how directory scanning had to be done in the software. Scanning had to go through ExNext() loop and number of context switches and DOS packet traffic between scanning task and fs task. ExAll() solved this (when directly supported by the fs) although it is bit hack.

Edit: haha, wris%&$#?@!%&$#?@!%&$#?@!%&$#?@!ch == w r i s t w a t c h
Title: Re: Layers.library V45 on the aminet
Post by: Heiroglyph on September 15, 2014, 08:15:39 PM
Quote from: Thomas Richter;773088
Why do you mind so much? The additional size is most likely due to the compiler startup code and some minimal glue code.



We'll have to agree to disagree here.  To me this is a symptom of a larger issue with AROS that is related to the current discussion.

IMHO, it's not a viable replacement for the original OS until it can run in reasonably similar resources and 4KB of wasted disk space, bandwidth and memory on a single command is patently ridiculous.

Working on the commands in c: is a stepping stone for me to get a workflow down while I become acquainted with the code base.
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 15, 2014, 08:34:44 PM
Quote from: Heiroglyph;773092
We'll have to agree to disagree here.  To me this is a symptom of a larger issue with AROS that is related to the current discussion.

IMHO, it's not a viable replacement for the original OS until it can run in reasonably similar resources and 4KB of wasted disk space, bandwidth and memory on a single command is patently ridiculous.

Working on the commands in c: is a stepping stone for me to get a workflow down while I become acquainted with the code base.

i agree that these are some of reasons that prevent aros to become real alternative on 68k.

perhaps some aros developer could comment on that. is it some linking issue, perhaps against the arosc lib?

woulnt it be good to disassemble and examine asm of some possibly simple aros68k c: command to actually exactly check where the differences and problems are in order to optimize them away if possible.
Title: Re: Layers.library V45 on the aminet
Post by: Heiroglyph on September 15, 2014, 08:39:04 PM
Quote from: wawrzon;773094
woulnt it be good to disassemble and examine asm of some possibly simple aros68k c: command to actually exactly check where the differences and problems are in order to optimize them away if possible.

You don't have to, just look at the code and compile it yourself.

Disassembly is rarely needed to find stuff like this, you just need someone to care about it.

Edit: Let me rephrase, lest people think that I don't like the AROS devs.  It's not "care" as in giving a damn, I meant care as in making that one of your priorities.
Title: Re: Layers.library V45 on the aminet
Post by: Thorham on September 15, 2014, 08:43:37 PM
Quote from: olsen;773078
Optimizing assembly code can be a rewarding exercise, like solving a chess puzzle, or doing calculus (yes, some people do that as a hobby, like playing "Candy Crush"; I'm still holding out for "Calculus Crush" for the iPhone). It follows a certain set of rules, there are rigid constraints and the number of possible solutions is small. Perfect entertainment!
Indeed :)

Quote from: Thomas Richter;773082
There are hot-spots where you have to use it, but if speed is essential, you typically want to be as flexible as possible to re-arrange your data structures to allow for fast algorithms, and to organize data such that the data access pattern fits to the CPU organization - and you don't get this flexibility in Assembler.
That's just not true, of course. Re-arrange your data, implement a better algorithm. How don't you get this flexibility in assembler, of all things? Of all languages out there, assembler has to be the one with the fewest restrictions. And yes, it's more work, but in assembly language almost everything is more work.

Quote from: Thomas Richter;773082
It sounds weird, but a high-level language and more code can sometimes make an algorithm faster.
That implies that it's not possible to always implement optimal algorithms in an optimal way in assembly language. Guess what all code that's compiled to native becomes. Right, assembly language. For 68020/30 probably NOTHING beats properly written assembly language.

If you know you're right, than post a good example of an algorithm for which this applies, because I sure would like to see it. Or more than one, if possible.
Title: Re: Layers.library V45 on the aminet
Post by: biggun on September 15, 2014, 09:00:05 PM
Quote from: Thorham;773096
Indeed :)
If you know you're right, than post a good example of an algorithm for which this applies, because I sure would like to see it. Or more than one, if possible.


Of course you can in theory implement all and everything in ASM.
The point is that if you write complex algorithms its a lot easier to keep the overview if you use a high level language.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 15, 2014, 09:33:44 PM
Quote from: Thorham;773096
That's just not true, of course. Re-arrange your data, implement a better algorithm. How don't you get this flexibility in assembler, of all things? Of all languages out there, assembler has to be the one with the fewest restrictions. And yes, it's more work, but in assembly language almost everything is more work.
Look, have you ever done a complex project? You seem to say "everything is in assembler, so you can do everything in assembler in first place". That's simply not correct. If I change an interface in a higher level language, I can create objects and interfaces in such a way that I can replace data structures without changing the objects. I would recompile, and the compiler would give me errors and warnings if something is not correct.

If you do the same in assembly, you would need to re-adjust the objects, re-check the interfaces. register assignments, scratch-registers... In other words, your daily work is so much tight up in low-level details that you are losing any type of control on the *real* work, and you're lost in problems usually not worth mentioning. Given that you have only a finite memory, and a finite time to memorize the interfaces, your mental capacities are tight up by nonsense the computer can take care of much better.

Quote from: Thorham;773096
That implies that it's not possible to always implement optimal algorithms in an optimal way in assembly language.
Correct. Because you will sooner or later find yourself in the situation that you're lost in your code and you're unable to do anything without breaking it.
Quote from: Thorham;773096
 Guess what all code that's compiled to native becomes. Right, assembly language. For 68020/30 probably NOTHING beats properly written assembly language.
Many things do, depending on what you want to do. Shell script does for simple file management properties. C does for many every-day problem solving. Arexx does for remote-controlling programs. Even Basic does for a simple throw-away code. On everyday use, I use C, C++, Bash-script, python, sed, perl, make, java, javascript, html,...  

Software engineering means using the right tools to get the job done as best as possible. Assembler rarely ever is. It's hard to see that without having gone through this. I can only suggest to try it once and setup a complex larger project from scratch.
Quote from: Thorham;773096
If you know you're right, than post a good example of an algorithm for which this applies, because I sure would like to see it. Or more than one, if possible.

Pretty much everything I do on an everyday basis. Well, anyhow, just for the means of it, my offer was already that you probably start writing a JPEG 2000 from scratch from the specs in assembler. My prediction is that you'll give up because you'll be lost somewhere within the mess the code becomes. You'll start implementing, then will notice that your overall design will not work, will start again, will make adjustments, will notice that the adjustments fit not to the rest of the code, will start again... You'll be left in a nightmare of development without much hope to get any reasonable program. In the end, if you're lucky, you probably get something that works, but most likely because you have forced program structures together that are sub-optimal, without understanding that your selection of algorithms was more due to low-level ease of implementation than high-level analysis of the problem.

In assembler, you're loosing the view on the problem; you cannot make out the core of the problem because you're lost in details. Or as we say here, "you don't see the wood because your view is blocked by trees".

Professional software is something different than rewriting the "List" command in assembler.
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 15, 2014, 10:21:02 PM
Quote from: Heiroglyph;773095
You don't have to, just look at the code and compile it yourself.

Disassembly is rarely needed to find stuff like this, you just need someone to care about it.

Edit: Let me rephrase, lest people think that I don't like the AROS devs.  It's not "care" as in giving a damn, I meant care as in making that one of your priorities.


im not blaming you in any way, i think you bring some valid points, im just trying to figure out how they could be solved, in absence of better proposals.

the idea to disassemble a binary wasnt exactly to discover what actually gets statically linked or the like, what can be read from sources, just if there is anything particularly strange that happens at compile time. afair aros version of gcc needs to be patched downstream to produce proper aros binaries, it doesnt get pushed and maintained upwards for obvious reasons so some crap might happen, and it might be possible to fix, if it was the case.
Title: Re: Layers.library V45 on the aminet
Post by: Heiroglyph on September 15, 2014, 10:37:17 PM
Quote from: wawrzon;773103
im not blaming you in any way, i think you bring some valid points, im just trying to figure out how they could be solved, in absence of better proposals.


I'm not sure what will become of this work, but here's a sample. I'm having trouble getting a table to format right in here, so read if you can, sizes are in bytes.

These aren't cherrypicked, they're just the ones I've done and tested enough to feel confident in them working like the originals.

Code: [Select]

Command OS3.1 Mine AROS (Vision 2.7)
AddBuffers 444 356 2168
Break 432 504 3732
ChangeTaskPri 460 476 3096
DiskChange 312 248 2052
Lock 536 628 2788
MakeDir 464 364 2732
MakeLink 700 556 2528
Relabel 584 580 3312
SetClock 668 636 4840
SetDate 688 724 3212

Total 5,288 5,072 30,460

Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 15, 2014, 10:47:37 PM
Quote from: Heiroglyph;773106
I'm not sure what will become of this work, but here's a sample. I'm having trouble getting a table to format right in here, so read if you can, sizes are in bytes.

These aren't cherrypicked, they're just the ones I've done and tested enough to feel confident in them working like the originals.

Code: [Select]
Command OS3.1 Mine AROS (Vision 2.7)
AddBuffers 444 356 2168
Break 432 504 3732
ChangeTaskPri 460 476 3096
DiskChange 312 248 2052
Lock 536 628 2788
MakeDir 464 364 2732
MakeLink 700 556 2528
Relabel 584 580 3312
SetClock 668 636 4840
SetDate 688 724 3212

Total 5,288 5,072 30,460


hello! i trust you and i noticed it myself, but one of the possibilities would be for example, that the binaries have not been stripped and still contain the debug symbols. this might amount to the 1/3to half of the size.
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 15, 2014, 11:06:32 PM
Quote from: Heiroglyph;773106
I'm not sure what will become of this work, but here's a sample. I'm having trouble getting a table to format right in here, so read if you can, sizes are in bytes.

These aren't cherrypicked, they're just the ones I've done and tested enough to feel confident in them working like the originals.

Code: [Select]

Command OS3.1 Mine AROS (Vision 2.7)
AddBuffers 444 356 2168
Break 432 504 3732
ChangeTaskPri 460 476 3096
DiskChange 312 248 2052
Lock 536 628 2788
MakeDir 464 364 2732
MakeLink 700 556 2528
Relabel 584 580 3312
SetClock 668 636 4840
SetDate 688 724 3212

Total 5,288 5,072 30,460



My first reaction was "who cares today for disk capacity" but then I thought a little and must admit that this is indeed important when you want to run it on classic hardware. Aros devs use PCs for development so stripping software down from 3 KB to 500 Byte has not a very high priority but if people want it in that direction it would be good if more people become involved. Of course you can replace most components so if you have reprogrammed something it could be used. But this is certainly a basic problem, many components certainly could be optimized.
Title: Re: Layers.library V45 on the aminet
Post by: Heiroglyph on September 15, 2014, 11:29:00 PM
I think Thomas is right on the money about startup and C library code.

My guess is that there's about 2k of startup/clib code duplicated on each command, but it may also be gcc contributing.

Most of my changes involved using native methods that would be in ROM, doing my own startup (2-3 lines of C code, wouldn't work in x86 AROS) and using C that I knew would compile to better assembly.

IMHO it's more readable now and I fixed several bugs along the way. AROS AddBuffers for example won't work correctly on a real ROM, but this works on both back to v37 KS.

I had more of it done with SAS/C but switched to vbcc this weekend for c99 support and a better compiler.
Title: Re: Layers.library V45 on the aminet
Post by: Heiroglyph on September 15, 2014, 11:40:53 PM
Quote from: OlafS3;773109
My first reaction was "who cares today for disk capacity" but then I thought a little and must admit that this is indeed important when you want to run it on classic hardware. Aros devs use PCs for development so stripping software down from 3 KB to 500 Byte has not a very high priority but if people want it in that direction it would be good if more people become involved. Of course you can replace most components so if you have reprogrammed something it could be used. But this is certainly a basic problem, many components certainly could be optimized.

Also when your disk access is measured in KB per second it's a lot more important than on a PC where 60MB per second isn't even considered fast.

Most of my time is still spent working out a good automated workflow for building and testing, but the code itself is pretty easy.

I'm hesitant to put this back into AROS though.  I'm using a compiler they don't want plus I don't have (or want) an x86 AROS development system and I refuse to check in code that I can't test.
Title: Re: Layers.library V45 on the aminet
Post by: Thorham on September 16, 2014, 12:21:15 AM
Quote from: biggun;773097
The point is that if you write complex algorithms its a lot easier to keep the overview if you use a high level language.
Yes, higher level languages are easier for most things.

Quote from: Thomas Richter;773100
Look, have you ever done a complex project?
Not yet, but define complex, or better yet, give some concrete examples of what creates the kind of complexity that is so hard to manage in assembly language (for software that would run well on 68020/30).

Quote from: Thomas Richter;773100
You seem to say "everything is in assembler, so you can do everything in assembler in first place".
For anything that's worth implementing on 68020/30 certainly.

Quote from: Thomas Richter;773100
That's simply not correct.
It is. It simply depends on ones ability. Maybe I can't do it, maybe you can't do it, but that doesn't make it impossible.

Quote from: Thomas Richter;773100
If you do the same in assembly, you would need to re-adjust the objects, re-check the interfaces. register assignments, scratch-registers...
And how exactly is that a problem? What I see as the main problem is when you're changing things all the time. Tells me that you didn't think it through thoroughly enough, and we've all been there.

Quote from: Thomas Richter;773100
In other words, your daily work is so much tight up in low-level details that you are losing any type of control on the *real* work, and you're lost in problems usually not worth mentioning.
You can also try to get it mostly right from the start, so that you can focus on writing actual functional code. Anyone who's lost in the details all the time is simply doing it wrong.

Quote from: Thomas Richter;773100
Software engineering means using the right tools to get the job done as best as possible.
That's only one part of it, and it's not the most important one. True software engineering means that you don't write a single line of code until you have a proper design. Something that works, and won't break when you want to add or change things. It's this part that's the hard part, and it can make the actual implementation process almost seem trivial in comparison. That's why when you're changing a lot of things you're not doing it right. You shouldn't have to, except when designing the software.

Quote from: Thomas Richter;773100
Well, anyhow, just for the means of it, my offer was already that you probably start writing a JPEG 2000 from scratch from the specs in assembler.
Yes, but why JPEG 2000? I'd rather do something that's more interesting. Same for the MPEG decoder you suggested in the other thread. JPEG 2000 isn't widely used, and MPEG on 68020/30s isn't very useful. I suggested a new GUI system, but that's not complex enough. So the big question is what would be really worthwhile to do on 68020/30 that's also reasonably complex? An HTML/CSS engine maybe?

Quote from: Thomas Richter;773100
In the end, if you're lucky, you probably get something that works, but most likely because you have forced program structures together that are sub-optimal, without understanding that your selection of algorithms was more due to low-level ease of implementation than high-level analysis of the problem.
I don't pick algorithms just because they're easier to implement in assembly language. I look for algorithms that get the job done properly and efficiently, and if implementing them sucks, then it sucks and I do it anyway (or I don't because I'm lazy).

Quote from: Thomas Richter;773100
Professional software is something different than rewriting the "List" command in assembler.
I don't doubt it, but we're also not talking about ten million line programs here, we're talking about software that will run well on 68020/30s. Such constraints automatically limit the complexity of a project, because programs that are so huge and heavy won't run well on 68k anyway.
Title: Re: Layers.library V45 on the aminet
Post by: kolla on September 16, 2014, 07:17:36 AM
Quote from: Thomas Richter;773044
Then you will never be able to work in professional (as in: for money) software development.


Not true at all, there are plenty of jobs in open source development.
Title: Re: Layers.library V45 on the aminet
Post by: itix on September 16, 2014, 07:37:56 AM
Quote from: Thorham;773112
Yes, higher level languages are easier for most things.

Not yet, but define complex, or better yet, give some concrete examples of what creates the kind of complexity that is so hard to manage in assembly language (for software that would run well on 68020/30).

For anything that's worth implementing on 68020/30 certainly.


I have an idea: write a web browser. Such thing can run reasonably well on 68020 and is always useful.

I dont mind if you skip development phase and disassemble existing IBrowse 2.4 and just add CSS support.
Title: Re: Layers.library V45 on the aminet
Post by: Oldsmobile_Mike on September 16, 2014, 08:19:03 AM
Quote from: itix;773124
I have an idea: write a web browser. Such thing can run reasonably well on 68020 and is always useful.

I dont mind if you skip development phase and disassemble existing IBrowse 2.4 and just add CSS support.

With the number of programmers that have already commented on this thread, if they pooled their talents and did it exactly as you said this would be cake. ;)  I was just using iBrowse a few minutes ago to snag some stuff off Aminet and check Google News.  It's amazing how well my A2000 holds up, sitting here next to my i7 PC.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 16, 2014, 08:43:27 AM
Quote from: Thorham;773112
It is. It simply depends on ones ability. Maybe I can't do it, maybe you can't do it, but that doesn't make it impossible.
Not really. It is a matter of available mental capacity. The more you invest into the low-level details, the less is left for the high-level structure. Take this as a fact that you only have a limited memory, limited overview, limited time. In other words, when writing assembly, you will be lost in detail, and loose the overview to the really important infrastructure decisions.
Quote from: Thorham;773112
And how exactly is that a problem? What I see as the main problem is when you're changing things all the time. Tells me that you didn't think it through thoroughly enough, and we've all been there.
What I hear from other developers, and what I have experienced myself is that you're continuously refactoring code. It sounds wasteful, but it is just the experience that, when designing the code, you made estimates on complexity, memory footprint, usage etc... that are typically not correct, tasks are ill-defined, the architecture is typically not fully designed... It is just a fact that nobody has a complete overview on the project when started, and the only way how to get an overview is to actually implement it. Then it's better not to waste time in implementing too much, but instead invest time in prototyping and testing, and later refine and improve the implementation as soon as you get a feeling where the complexity is.  
Quote from: Thorham;773112
You can also try to get it mostly right from the start, so that you can focus on writing actual functional code. Anyone who's lost in the details all the time is simply doing it wrong.
You haven't done any complex program, but let me tell you that you *never* get it right from the start. If you do it in assembler, you're at some point in the stage of "oh, the heck of it", and then you start to complete the program in the design you intended originally, knowing that the choices were not ideal. That's different if you work on a higher level - it is easier to change the code, and to throw code away, or to rewrite and adapt the code.  

Yes, you will be lost in detail in assembler - you're moving data from register dx to register an. That's detail, and it is a detail level that is not helpful to structure the problem.  
Quote from: Thorham;773112
That's only one part of it, and it's not the most important one. True software engineering means that you don't write a single line of code until you have a proper design. Something that works, and won't break when you want to add or change things. It's this part that's the hard part, and it can make the actual implementation process almost seem trivial in comparison. That's why when you're changing a lot of things you're not doing it right. You shouldn't have to, except when designing the software.
That's probably what management wants it to be (the "waterfall design"). Believe me, that's nonsense. It doesn't work this way, never did except for trivial programs. Ask other experienced developers. Software design means continuous refactoring, as the code grows, as the problem becomes defined better, as you learn more about the bottlenecks, as the customer learns more what he actually wants... Good programs have been written multiple times until they became good. But not too often, as then you're running in danger of the "second system design effect" (too complex, too much detail). Finding the right balance is the art.  
Quote from: Thorham;773112
Yes, but why JPEG 2000? I'd rather do something that's more interesting. Same for the MPEG decoder you suggested in the other thread. JPEG 2000 isn't widely used, and MPEG on 68020/30s isn't very useful. I suggested a new GUI system, but that's not complex enough. So the big question is what would be really worthwhile to do on 68020/30 that's also reasonably complex? An HTML/CSS engine maybe?
I picked it because that's were I first admired the benefits of high level languages. You can also try to write a HTML engine, but probably a javascript interpreter (or compiler) would be interesting. It doesn't really matter too much. As soon as the problem becomes big enough, and you need to coordinate with other partners or with other software, you'll run into trouble.    
Quote from: Thorham;773112
I don't pick algorithms just because they're easier to implement in assembly language. I look for algorithms that get the job done properly and efficiently, and if implementing them sucks, then it sucks and I do it anyway (or I don't because I'm lazy).
Complex software is more than an algorithm. It mean sticking lots of algorithms together to form a complete architecture, and you usually do not make the right choices for each of the algorithms when you start. Essentially, you can't, it's a chicken and egg problem. You don't have the full problem at your hands when you start (you never have, regardless what management says), you don't have the full data, so you depend on assumptions. Best guess is that these assumptions are usually wrong. Thus, you find yourself in the situation that you have to replace algorithms, put them together in a different way, or rethink your design. It is not unusual that several parts of such a project are dumped and rewritten because you learned more as the project proceeded. That's normal, and nothing to be afraid of.  
Quote from: Thorham;773112
I don't doubt it, but we're also not talking about ten million line programs here, we're talking about software that will run well on 68020/30s. Such constraints automatically limit the complexity of a project, because programs that are so huge and heavy won't run well on 68k anyway.

Why? Program size is only limited by your ability to use the right tools, not the CPU. Most complex programs do not even depend on "heavy work" for the CPU. It is just complex work. Running time does not correlate with program size.

To give you some ideas: The largest scale Amiga program I have written in assembler is ViNCed, which is about 63000 lines assembler. It is *barely* managable in that size. It's hard to change, and its hard to maintain.

The largest C program I wrote on the Amiga is probably VideoEasel, it's about 45000 lines of C and assembly, and even though it does a lot more than just a console and is more complex, it is easier to handle. Both work on the same hardware.

A large C++ program I wrote on *ix is the JPEG 2000 codec, in total about 250000 lines. Yes, it would compile on Amiga, and it is still in a state where it can be maintained. Yet, it is the fastest JPEG 2000 you'll find on the market. Not "despite it uses C++", but "because it uses C++". It would have been simply impossible to do that in assembler. Yes, there are assembler parts in it, but only where it matters. (The reason for the size is that it does a lot more than encoding and decoding of images. JPEG 2000 has multiple parts, and this specific implementation covers parts 1,2,3,9 and 12, and was the basis for many of the reference images in part 4.)

And once again, even this implementation is small compared to a full scale project, such as a web-browser, where a harmless image codec is just one of the many tiny details you need to fit together to make the whole thing work. Then you have products that built on top of web-browsers and java script, and projects that are built on top of java-script again... It's a full hierarchy of complexity. Of course, even if you have a java code, that is compiled into javascript, that is delivered over TCP/IP, that is compiled by a web-browser JIT compiler, that is run in the browser sandbox, it is all asssembler in the end. But only there, in the end. Nobody sane in his mind would develop such an application in assembler.

Or even different: If you as a human would have to think and coordinate every heart-beat, every breath and every mussle by your higher brain functions, you would get nuts. There are automatisms built into the lower areas into the brain that take all the complexity away, and that do that "automatically for you" to reduce the complexity, but that limits your control on these functions. For the better of your life.
Title: Re: Layers.library V45 on the aminet
Post by: Cosmos on September 16, 2014, 09:37:35 AM
Quote from: Thomas Richter;773131
The largest scale Amiga program I have written in assembler is ViNCed, which is about 63000 lines assembler. It is *barely* managable in that size. It's hard to change, and its hard to maintain

Because you are still a beginner in asm : you have a lot of thing to learn, and me too in other domains of course... We have all to learn all !!

You take your case for a generality... Big mistake !


The 68k is certainly the only CPU who large programms are fully possible in asm only...

For exemple, the W3D_Permedia2.library is 276 615 lines long and I make any changes very easly...
Title: Re: Layers.library V45 on the aminet
Post by: Thorham on September 16, 2014, 09:44:00 AM
Quote from: Thomas Richter;773131
To give you some ideas: The largest scale Amiga program I have written in assembler is ViNCed, which is about 63000 lines assembler. It is *barely* managable in that size. It's hard to change, and its hard to maintain.
Would you let me take a look at the source code? Might help you get your point across if you're right ;)
Title: Re: Layers.library V45 on the aminet
Post by: vxm on September 16, 2014, 10:39:28 AM
I think I'll restart to program in machine language on punched cards.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 16, 2014, 10:52:11 AM
Quote from: Cosmos;773136
Because you are still a beginner in asm : you have a lot of thing to learn, and me too in other domains of course... We have all to learn all !!

You must be kidding, right? I started with assembler, and moved for a reason. Actually, ViNCed is probably one of the older programs. Now that I read the copyright notes, it gives me the creeps. "© 1990-2001 THOR". Nine years of writing, rewriting, improvements, changes. This is version 3... I believe this makes >25 years of assembly experience, not counting the 6502-years.

Anyhow, you life, you learn... Why don't you start a larger project, for example?
Title: Re: Layers.library V45 on the aminet
Post by: psxphill on September 16, 2014, 10:53:39 AM
Quote from: Thomas Richter;773082
Anyhow, byte counting stopped making sense, already when 512K were the norm, and priorities changed.

It still made sense, if you needed the space. If you could shave a couple of K off and make something fit in ram or on disk then the cost saving was worthwhile.
 
 exec/dos/workbench etc that were in memory a lot of the time would make sense to be as efficient as possible. Not many people would complain if Prefs wasted 100k of ram.
 
 gnu 68k compilers are shockingly bad, it's one of the things that needs the most development.
Title: Re: Layers.library V45 on the aminet
Post by: psxphill on September 16, 2014, 11:02:40 AM
Quote from: Thorham;773096
That implies that it's not possible to always implement optimal algorithms in an optimal way in assembly language.

Sure it's possible, it's possible that you'll get it finished before you give up, it's possible there won't be any bugs, it's possible that when you realise there is a better algorithm that requires you to start again that you will actually do it.
 
 For most people it's very unlikely they'll bother.
 
 You are arguing over usage and interpretation of English, not of the actual issues at hand.
 
 It's impossible for me to write in assembler these days, not because I can't but because I won't let myself. Life is too short. If you can afford to waste the time then go ahead, but it doesn't prove what you think it does.
Title: Re: Layers.library V45 on the aminet
Post by: Karlos on September 16, 2014, 11:29:27 AM
Quote from: Cosmos;773136
For exemple, the W3D_Permedia2.library is 276 615 lines long and I make any changes very easly...


There's an unreleased version of this library for OS3.x (the OS4 version is based on it). It's about 1/8th the size of the Warp3D 4.2 release version, fully supports every v4 array/element/index size primitive and is up to 2x faster at rendering triangle/strip/fan lists.

Those gains were from refactoring the C and then rewriting some vertex fetch routines in assembler. The latter did not give much gain since in the end the bus is the bottleneck.
Title: Re: Layers.library V45 on the aminet
Post by: Thorham on September 16, 2014, 12:01:51 PM
Quote from: psxphill;773143
If you can afford to waste the time then go ahead
I've said this before: My hobby is NOT a waste of time to me. What's really a waste of time is having been an alcoholic for 14 years doing nothing useful at all. If I had spent all that time writing 68k software in assembly language, then I'd have quite a few nice pieces of software.

Doing what you like doing isn't a waste of time. You don't like assembly language? Great, don't use it, but don't say it's a waste of time just because it's a waste time to you. Some people like peanut butter and some don't. No sense in arguing about that.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 16, 2014, 12:03:53 PM
Quote from: psxphill;773143
Sure it's possible, it's possible that you'll get it finished before you give up, it's possible there won't be any bugs, it's possible that when you realise there is a better algorithm that requires you to start again that you will actually do it.

The problem goes deeper. The problem is that it's very likely that you do not even realize that you have an architecture problem somewhere in the code if you write everything in assembler. If you take enough time, you'll probably get working code if you work hard. But you're still lost irrelevant details. It's likely that you picked an algorithm because it looked on the microlevel pretty ideal. But whether that's relevant for the big picture is another question, and you'll easily loose the big picture in assembler - you're not forced to organize your code, and you don't have a compiler that helps you at the detail level.
Title: Re: Layers.library V45 on the aminet
Post by: Thorham on September 16, 2014, 12:08:36 PM
Quote from: Thomas Richter;773148
you're not forced to organize your code
In assembly language, organizing your code properly is even more important than in other languages.
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 16, 2014, 12:39:09 PM
Quote from: Thomas Richter;773148
The problem goes deeper. The problem is that it's very likely that you do not even realize that you have an architecture problem somewhere in the code if you write everything in assembler. If you take enough time, you'll probably get working code if you work hard. But you're still lost irrelevant details. It's likely that you picked an algorithm because it looked on the microlevel pretty ideal. But whether that's relevant for the big picture is another question, and you'll easily loose the big picture in assembler - you're not forced to organize your code, and you don't have a compiler that helps you at the detail level.


If somebody is deeply committed to using the language of his choice (say, assembly language, Perl, Visual Basic, Delphi, you name it), and has a clear idea of the limitations of the language, then there is literally no problem he cannot solve using that language, even if that means having to put in extra work to solve it.

You can mention how much more leverage a different language provides, tell war stories to illustrate the time and effort you saved by switching tools, but it won't leave any impression whatsoever. If somebody grew up learning one programming language, and found that it is fit to solve all the problems he ever encountered, never saw the need to look beyond it, you won't be able to talk him out of it.

Which is fine, until you have to collaborate with such a savant and find common ground to work with him. I trust you've been in this kind of situation, and so have I.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 16, 2014, 12:42:40 PM
Quote from: Thorham;773149
In assembly language, organizing your code properly is even more important than in other languages.

You are not *forced to* by the language to do that. C and even more so C++ or Java requires(!) you to use language constructs to organize your code that are quite expressive and rich, and allows the compiler to check for the correctness of these constructs. In Assembler, you have nothing. Pretty much every Java code looks the same - same style. In C++, you have more freedoms and several programming styles are possible, but one way or another, the language offers you constructs how to address specific problems, and the compiler is there to check for the correctness of such constructs.

Anyhow, we're arguing in circles. Given that you never worked on a major project in assembler, I see that you can hardly judge why all that is beneficial for a project, and why it helps so much. Don't you think that it's rather ignorant to make such arguments without ever having gone through all this at least once?

Try it, then we do the talking. Probably in five years if you start now.
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 16, 2014, 12:53:37 PM
Quote from: Thomas Richter;773152
You are not *forced to* by the language to do that. C and even more so C++ or Java requires(!) you to use language constructs to organize your code that are quite expressive and rich, and allows the compiler to check for the correctness of these constructs. In Assembler, you have nothing. Pretty much every Java code looks the same - same style. In C++, you have more freedoms and several programming styles are possible, but one way or another, the language offers you constructs how to address specific problems, and the compiler is there to check for the correctness of such constructs.

Anyhow, we're arguing in circles. Given that you never worked on a major project in assembler, I see that you can hardly judge why all that is beneficial for a project, and why it helps so much. Don't you think that it's rather ignorant to make such arguments without ever having gone through all this at least once?

Try it, then we do the talking. Probably in five years if you start now.

I think you and Thorham (and Cosmos) are looking at it from a completely different perspective. You look at it as a professional developer, they look at it as hobbyists doing it just for fun and are happy if they squeeze out some bytes or make it a little faster on their own system and environment. This discussion about sense or nonsense of using assembler or if it makes sense that everyone does his own patches can last for another 1000 postings and will not come to a end. It is the same as discussing if it makes sense to use a exotic OS instead of mainstream. As long as they offer only patches (and do not spread the changed original) nobody can do anything about it. There are countless patches on aminet and everybody knows that using it is risky so people are responsible themselves if they use it or not.

Better would be AmigaOS 68k would still be in development but we cannot bake reality..
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 16, 2014, 01:17:30 PM
Quote from: Heiroglyph;773110
I think Thomas is right on the money about startup and C library code.

My guess is that there's about 2k of startup/clib code duplicated on each command, but it may also be gcc contributing.

Most of my changes involved using native methods that would be in ROM, doing my own startup (2-3 lines of C code, wouldn't work in x86 AROS) and using C that I knew would compile to better assembly.

IMHO it's more readable now and I fixed several bugs along the way. AROS AddBuffers for example won't work correctly on a real ROM, but this works on both back to v37 KS.

I had more of it done with SAS/C but switched to vbcc this weekend for c99 support and a better compiler.

its not like they dont want to support vbcc, there has been even some work put towards it, though first of all there is not enough human resources, so they must concentrate on compilers that are offering most up to date features, best multi-platform backend support, best posix compatibility, and active maintenance, backed up by huge team. i think in this respect relying on 4.x.x gcc is a right and reasonable trade off.

i would definitely love if you could help to improve aros68k, but its up to you of course and aros maintainers. if need be you could talk directly to toni wilen or via eab. i think even discussing things with him could be valuable given experience you have gathered. im aware though, that toni being winuae man, is less interested in performance optimizations for real hardware as long as he considers them premature, that means as long as implementation is incomplete and not very well tested.
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 16, 2014, 01:25:02 PM
Quote from: Karlos;773146
There's an unreleased version of this library for OS3.x (the OS4 version is based on it). It's about 1/8th the size of the Warp3D 4.2 release version, fully supports every v4 array/element/index size primitive and is up to 2x faster at rendering triangle/strip/fan lists.

Those gains were from refactoring the C and then rewriting some vertex fetch routines in assembler. The latter did not give much gain since in the end the bus is the bottleneck.


and here we go again. things that could improve the experience on 68k are held back to remain os4 exclusive. of course you and the genuine source owners have every right to do what they please, but imagine what might have happened if you published your work as open source backend to wazp3d. perhaps it could even have become a template for volunteers king for opportunity to write other w3d drivers, and literally everyone could gain from it including os4 community.
Title: Re: Layers.library V45 on the aminet
Post by: Thorham on September 16, 2014, 01:38:31 PM
Quote from: Thomas Richter;773152
You are not *forced to* by the language to do that. C and even more so C++ or Java requires(!) you to use language constructs to organize your code that are quite expressive and rich, and allows the compiler to check for the correctness of these constructs.
Oh, come on, you can make a mess out of things in every language, and yes, assembly language makes that easier.

Quote from: Thomas Richter;773152
In Assembler, you have nothing.
Except the most important tool: Your brain. Nothing keeps you from structuring your assembly language code properly. If someone doesn't do that, then that's their mistake.

Quote from: Thomas Richter;773152
Anyhow, we're arguing in circles. Given that you never worked on a major project in assembler, I see that you can hardly judge why all that is beneficial for a project
I can see perfectly fine how higher level programming languages are beneficial to a larger project (use them myself on the peecee, where I don't use assembly language). I simply don't agree with you that you can't do it properly in assembly language.

Quote from: Thomas Richter;773152
and why it helps so much. Don't you think that it's rather ignorant to make such arguments without ever having gone through all this at least once?
No, it's not ignorant. What's ignorant is assuming that your personal experience with this applies to everyone. You say it's too hard, because you've had problems with it, and that's not right.

Also, I'd like to see what's so hard about a shell replacement in assembly language. Would be great if I could take a look at that (because you claim it was hard to do).
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 16, 2014, 01:45:37 PM
Quote from: Thorham;773157
I simply don't agree with you that you can't do it properly in assembly language.


Once again, and even simpler: "Then shut up and do it, then see what happens." Got it?
Title: Re: Layers.library V45 on the aminet
Post by: Thorham on September 16, 2014, 02:11:55 PM
To Thomas Richter:

All you're saying is that because you can't do it, no one can. Because you find it too hard, it's too hard for everyone. That's some major arrogance right there.
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 16, 2014, 02:22:22 PM
sighhhh......
Title: Re: Layers.library V45 on the aminet
Post by: vxm on September 16, 2014, 02:22:42 PM
Fortunately, the first C compiler was written in assembler.
(with that, it seems clear to me that I will not have new friends.)
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 16, 2014, 02:25:53 PM
Quote from: Thorham;773161
To Thomas Richter:

All you're saying is that because you can't do it, no one can. Because you find it too hard, it's too hard for everyone. That's some major arrogance right there.

Once again: "Shut up, try it yourself, we'll then talk". Which part of that did you not understand?
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 16, 2014, 02:31:07 PM
Quote from: vxm;773163
Fortunately, the first C compiler was written in assembler.

 Where did you get that idea from? http://cm.bell-labs.com/who/dmr/chist.html
Title: Re: Layers.library V45 on the aminet
Post by: Heiroglyph on September 16, 2014, 02:33:26 PM
Quote from: wawrzon;773154
its not like they dont want to support vbcc, there has been even some work put towards it, though first of all there is not enough human resources, so they must concentrate on compilers that are offering most up to date features, best multi-platform backend support, best posix compatibility, and active maintenance, backed up by huge team. i think in this respect relying on 4.x.x gcc is a right and reasonable trade off.


Apparently they have technical issues with vbcc and a very gcc specific codebase.

http://en.wikibooks.org/wiki/Aros/Platforms/68k_support/Developer/Compiler#VBCC

I still think this is the right path for native 68k though, which is the one platform I want and that I think is underdeveloped.

Quote

i would definitely love if you could help to improve aros68k, but its up to you of course and aros maintainers. if need be you could talk directly to toni wilen or via eab. i think even discussing things with him could be valuable given experience you have gathered. im aware though, that toni being winuae man, is less interested in performance optimizations for real hardware as long as he considers them premature, that means as long as implementation is incomplete and not very well tested.


I haven't discussed it with them because I'm still not sure I'm on the right track. I may realize exactly why they haven't done it themselves and I don't see a point in distracting them or making it look like a fork. It's just my little playground ATM.

The discussions lately (especially from you and OlafS3) convinced me to do something  instead of just complaining about how they handled it, lol.
Title: Re: Layers.library V45 on the aminet
Post by: Heiroglyph on September 16, 2014, 02:45:52 PM
Thomas and anyone else who contributed, I understand that you have NDAs so you can't work on open versions of system components.

Excuse me if I missed this along the way, it's a long thread, but how are you able to distribute binaries like this?

Also, are there more libraries that you have the ability improve and if so, which ones have potential?

I doubt most could give this same level of improvement, but any at all would be welcome in lieu of an official update.

Thanks
Title: Re: Layers.library V45 on the aminet
Post by: Rotzloeffel on September 16, 2014, 02:49:52 PM
Quote from: Heiroglyph;773169
Excuse me if I missed this along the way, it's a long thread, but how are you able to distribute binaries like this?
Thanks

Because Thomas asked the owner of the rights (IMHO Hyperion) and they allowed Thomas to improve layers.library

That´s the way it should allways work:-) But we know better....
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 16, 2014, 03:17:06 PM
Quote from: Heiroglyph;773167
Apparently they have technical issues with vbcc and a very gcc specific codebase.

http://en.wikibooks.org/wiki/Aros/Platforms/68k_support/Developer/Compiler#VBCC

I still think this is the right path for native 68k though, which is the one platform I want and that I think is underdeveloped.



I haven't discussed it with them because I'm still not sure I'm on the right track. I may realize exactly why they haven't done it themselves and I don't see a point in distracting them or making it look like a fork. It's just my little playground ATM.

The discussions lately (especially from you and OlafS3) convinced me to do something  instead of just complaining about how they handled it, lol.

yes i remember it was technical issues of course. im not sure if this article is fully up to date, it must have been written by jason.

one issue not privilidgeing vbcc is of course that it is a native 68k compiler (afaik) and aros heavily depends on automatized cross compiling on servers to have actual nightlies ready at hand for testing by everybody. though since people are adding their preffered platforms to compile on i imagine vbcc could also be accepted if it was doable. what concerns missing features like different asm inline syntax (if i understand it right), we have here matthey who is helping with vbcc and vasm for input on that matter.
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 16, 2014, 04:01:58 PM
Quote from: Heiroglyph;773167
Apparently they have technical issues with vbcc and a very gcc specific codebase.

http://en.wikibooks.org/wiki/Aros/Platforms/68k_support/Developer/Compiler#VBCC

I still think this is the right path for native 68k though, which is the one platform I want and that I think is underdeveloped.



I haven't discussed it with them because I'm still not sure I'm on the right track. I may realize exactly why they haven't done it themselves and I don't see a point in distracting them or making it look like a fork. It's just my little playground ATM.

The discussions lately (especially from you and OlafS3) convinced me to do something  instead of just complaining about how they handled it, lol.


That is great :-)

I have reached the end of line regarding Aros 68k now. When you look at functionality I think the difference is not far but it still misses needed optimizations to reduce size and adapt it to the classic hardware. AmigaOS is still unbeatable there (its biggest strength and weakness at the same time). If some skilled developers would help there and help to remove incompatiblility issues everyone would benefit. And for the Aros developers compatibility to 3.1. is the main goal. Thomas has said he will answer questions so perhaps if we all work together something good can come out.

@Wawa

On aros-exec there is someone wanting to help testing on real hardware:
http://aros-exec.org/modules/newbb/viewtopic.php?topic_id=8851&forum=4&post_id=90173#forumpost90173

perhaps you can get in contact. We need more people being active then the progress will be much faster.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 16, 2014, 04:08:11 PM
Quote from: Rotzloeffel;773170
Because Thomas asked the owner of the rights (IMHO Hyperion) and they allowed Thomas to improve layers.library.

Almost. Layers V45 was collecting dust on my hard disk for over 12 years. The project was done as a contribution to Os 4.0 a long time ago, and the code actually made it into Os 4. I just found that it would be too bad not to offer it to the classic system, even more so as some of the folks I know (Gunnar, for example) were planning new graphics cards, and the code we have here is a welcome extension. Actually, the story of all this is even older, years ago when I helped Tobias and Alex a little bit with P96, they already asked me whether it would make sense to clean up layers. Back then, I haven't had the time to do it, this then finally happened after 3.9. Probably a bit too late for the V2 of P96, but still in time to have it today.

One way or another, yes, I got permission, thus I'm not so pessimistic that there is probably some chance for further improvements to be made.
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 16, 2014, 04:35:55 PM
Quote from: OlafS3;773175
That is great :-)


@Wawa

On aros-exec there is someone wanting to help testing on real hardware:
http://aros-exec.org/modules/newbb/viewtopic.php?topic_id=8851&forum=4&post_id=90173#forumpost90173

perhaps you can get in contact. We need more people being active then the progress will be much faster.


who? magorium? i doubt he needs my help, anyway he didnt asked for any so..
Title: Re: Layers.library V45 on the aminet
Post by: OlafS3 on September 16, 2014, 04:41:46 PM
Quote from: wawrzon;773177
who? magorium? i doubt he needs my help, anyway he didnt asked for any so..


no

ntromans
Title: Re: Layers.library V45 on the aminet
Post by: Thorham on September 16, 2014, 04:57:54 PM
Quote from: Thomas Richter;773164
Once again: "Shut up, try it yourself, we'll then talk".
Yeah, I think I will shut up :)
Title: Re: Layers.library V45 on the aminet
Post by: vxm on September 16, 2014, 05:00:18 PM
Quote from: Thomas Richter;773165
Where did you get that idea from? http://cm.bell-labs.com/who/dmr/chist.html
As far as I can remember, probably during training in microelectronics in the 80s:
"in 1972 the first version of C is written in assembler by Brian W. Kernighan and Dennis M. Ritchie."
Title: Re: Layers.library V45 on the aminet
Post by: kolla on September 17, 2014, 01:56:49 AM
Quote from: psxphill;773142
gnu 68k compilers are shockingly bad, it's one of the things that needs the most development.


GCC (and glibc) for m68k has gotten quite a bit of attention the last few years and is far from "shockingly bad". Upgrade already.
Title: Re: Layers.library V45 on the aminet
Post by: kolla on September 17, 2014, 02:03:32 AM
Thoram: code an IPv6 capable TCP stack for AmigaOS in asm, it is very much needed, is perfectly doable and worth while on 68k, and complex enough to drive you insane.
Title: Re: Layers.library V45 on the aminet
Post by: matthey on September 17, 2014, 06:03:09 AM
Quote from: wawrzon;773172

one issue not privilidgeing vbcc is of course that it is a native 68k compiler (afaik) and aros heavily depends on automatized cross compiling on servers to have actual nightlies ready at hand for testing by everybody. though since people are adding their preffered platforms to compile on i imagine vbcc could also be accepted if it was doable. what concerns missing features like different asm inline syntax (if i understand it right), we have here matthey who is helping with vbcc and vasm for input on that matter.


Vbcc can cross compile from x86 or PPC which is generally all that is needed for fast cross compiling to 68k. AROS is using GCC specific functionality which is a problem. Vbcc has good C99 compatibility now (new unreleased version) and Frank Wille's vlink supports the AROS 68k ELF format. Frank Wille and the AROS developers need to hammer out the necessary changes to get it to work. There isn't a lot of motivation with GCC 68k code generation quality improving lately though.
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 17, 2014, 08:10:40 AM
Quote from: kolla;773207
Thoram: code an IPv6 capable TCP stack for AmigaOS in asm, it is very much needed, is perfectly doable and worth while on 68k, and complex enough to drive you insane.
Don't tempt me ;)

But seriously, implementing an IPv6 TCP/IP stack in plain 68k assembly language should be doable. You'd have to start off small with the 1983 TCP/IP implementation, as documented and used in 4.2BSD, upgrade it to the 1988 implementation (with congestion control support) and then you're basically in business: this can be upgraded for IPv6 support.

The hard part is in fitting this into the bsdsocket.library framework which already exists, so that it can be used for existing client software on AmigaOS (and not just exist as a proof that anything is possible in 68k assembly language, even if you have to forgo shaving, bathing and seeing your family for an extended period of time). There is a blueprint in AmiTCP, but it will only get you so far. The only IPv6 API support which I am aware of exists in Miami Deluxe, and it has never been replicated; the number of IPv6 clients on the Amiga always was very small, too, which would make testing difficult.

Anyway, before somebody even thinks about it: don't write IPsec code in plain 68k assembly language, because this is going to end in tears. As soon as you're having to do serious heavy lifting in cryptography you're best advised not to write the code in a language which is difficult to audit and review for errors.
Title: Re: Layers.library V45 on the aminet
Post by: Karlos on September 17, 2014, 08:38:49 AM
Quote from: wawrzon;773155
and here we go again. things that could improve the experience on 68k are held back to remain os4 exclusive.


Not exactly. This work pre dated OS4. I never released it at the time because in fixing a few bugs (and doubtless introducing new ones) I broke compatibility with a few applications. Most notably some of the better demos. I wrote entire suites of tests and can honestly say the driver honoured the API but there exists a corpus of software that relied on some obscure undocumented and likely accidental side effects of the original code. And while the improved performance in synthetic tests was nice, the gains were marginal in most games because the bottlenecks where elsewhere (esp. on ppc).

And that's the moral of this story. Optimising the %&$#?@!%&$#?@!%&$#?@!%&$#?@! out of a single small area often leaves you with little to show for it other than more bugs than you started with. None of the fixes to the v4 drawing calls mattered for existing software except to my projects, and they were still broken / unimplemented in the other drivers, so my software was left running on P2 when voodoo was fast becoming the norm. MiniGL went from v3 api calls to v5 (OS4 only) rendering those fixes irrelevant for most applications.

I had marginally faster minigl 1.5 / heretic 2 / glquake and a lot of wrecked elude demos.


Quote
of course you and the genuine source owners have every right to do what they please, but imagine what might have happened if you published your work as open source backend to wazp3d. perhaps it could even have become a template for volunteers king for opportunity to write other w3d drivers, and literally everyone could gain from it including os4 community.


I'd be happy to release it, but it isn't up to me. Warp3D belongs to Hyperion and is now part of OS4. It's also deprecated so they may be ok with it. Either way, I'd have to ask.
Title: Re: Layers.library V45 on the aminet
Post by: psxphill on September 17, 2014, 08:59:34 AM
Quote from: kolla;773206
GCC (and glibc) for m68k has gotten quite a bit of attention the last few years and is far from "shockingly bad". Upgrade already.

Can you back that up, I can't find any proof of that online.

Quote from: vxm;773181
As far as I can remember, probably during training in microelectronics in the 80s:
"in 1972 the first version of C is written in assembler by Brian W. Kernighan and Dennis M. Ritchie."

The C compiler was based on the B compiler, which had already been re-written in B by this point. B was originally written in TMG, but TMG was written in assembler by Doug McIlroy.

Never believe anything they teach you in school.

http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
Title: Re: Layers.library V45 on the aminet
Post by: vxm on September 17, 2014, 10:04:11 AM
Quote from: psxphill;773221
Never believe anything they teach you in school.

I agree, and that's one reason why I never learned C. Another is that it is always better to avoid the use of an interpreter.
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 17, 2014, 10:06:42 AM
Quote from: matthey;773214
Vbcc can cross compile from x86 or PPC which is generally all that is needed for fast cross compiling to 68k. AROS is using GCC specific functionality which is a problem. Vbcc has good C99 compatibility now (new unreleased version) and Frank Wille's vlink supports the AROS 68k ELF format. Frank Wille and the AROS developers need to hammer out the necessary changes to get it to work. There isn't a lot of motivation with GCC 68k code generation quality improving lately though.


okay, another informed opinion that gcc 68k backend improved. im sure matt bases it on own experience. of course if someone found solution to modify aros source to compile with vbcc or to extend vbcc with the necessary gcc functionality it would be also fine, but yet again this must be out of own motivation. hard to believe there will be significant amount of interest let alone money to rely on.
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on September 17, 2014, 10:25:39 AM
Quote from: Karlos;773220
Not exactly. This work pre dated OS4. I never released it at the time because in fixing a few bugs (and doubtless introducing new ones) I broke compatibility with a few applications. Most notably some of the better demos. I wrote entire suites of tests and can honestly say the driver honoured the API but there exists a corpus of software that relied on some obscure undocumented and likely accidental side effects of the original code. And while the improved performance in synthetic tests was nice, the gains were marginal in most games because the bottlenecks where elsewhere (esp. on ppc).

And that's the moral of this story. Optimising the %&$#?@!%&$#?@!%&$#?@!%&$#?@! out of a single small area often leaves you with little to show for it other than more bugs than you started with. None of the fixes to the v4 drawing calls mattered for existing software except to my projects, and they were still broken / unimplemented in the other drivers, so my software was left running on P2 when voodoo was fast becoming the norm. MiniGL went from v3 api calls to v5 (OS4 only) rendering those fixes irrelevant for most applications.

I had marginally faster minigl 1.5 / heretic 2 / glquake and a lot of wrecked elude demos.




I'd be happy to release it, but it isn't up to me. Warp3D belongs to Hyperion and is now part of OS4. It's also deprecated so they may be ok with it. Either way, I'd have to ask.


you have had access to the sources and been working on a w3d driver predating os4? wow!
now: dont understand me wrong, ï dont expect wonders and also im not making demands. i was actually rather commenting on a general attitude to keep features for os4 even though they could be ported to 68k, or even opening them altogether, even if it was just for educational reasons or for code preservation. this might been legitimate as long as there have been slightest chance for securing an own commercial niche. but it seems for os4 such a chance if ever must have exist only at the very beginning.

now, this attitude seems to change now a little. at least when it comes to contributors, such as in case of the topic here, olsens roadshow or os4 mui maintainers. probably it is plain impossible to prevent such a notion, whoever would like to do it, as soon as it gains own dynamic. i wonder if some day at least the sources of improvements will be published, even if the original ones will remain locked off.
Title: Re: Layers.library V45 on the aminet
Post by: kamelito on September 17, 2014, 06:16:47 PM
@Olsen @Thor,

Since it's too late to go back to school, could you please give a list of good books to go from a "coder" to a "software engineer". Being about C, C++, Algorithms, Design patterns whatever else suit you.

Thanks
Kamelito
Title: Re: Layers.library V45 on the aminet
Post by: kolla on September 17, 2014, 07:21:39 PM
Quote from: psxphill;773221
Can you back that up, I can't find any proof of that online.


From the top of my head, thread local storage (TLS) support for m68k and coldfire was added in gcc 4.5, by people from codesourcerer, an embedded company. A lot of improvements in gcc are general and also affect m68k. Improvements to coldfire support are also reflected on the m68k since they are so similar. Check the gcc changelogs.

https://gcc.gnu.org/gcc-4.5/changes.html for example.

Personally I have spent lots of time on Gentoo for Linux/m68k, and can from experience just say that it works pretty well.
Title: Re: Layers.library V45 on the aminet
Post by: Cass on September 17, 2014, 08:33:01 PM
@Thomas Richter
Congratulations for your hard work and this update! I didn`t read the whole 16 pages thread but I tried to install it on my A4000. My config is the following:
H/W : CSPPC, CV3D, ALGOR, X-SURF
S/W : WB3.9 & BB ( i think the latest official, that would be #2), AfaOS, P96

The results:
When loaded as a module on ALGOR it failed to boot, When I tried with the c:loadmodule and all the intructions on readme, I managed to get to WB but with trashed backdrop, and the system froze after a few click or mouse movement.

I suspect it has to do with AfaOS, but any other suggestion would be nice...
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 18, 2014, 08:35:32 AM
Quote from: kamelito;773249
@Olsen @Thor,

Since it's too late to go back to school, could you please give a list of good books to go from a "coder" to a "software engineer". Being about C, C++, Algorithms, Design patterns whatever else suit you.

Thanks
Kamelito
Well, you asked for it ;)

The difference between coder and software engineer, as I'd like to frame it for the purpose of pointing you to the books which completely changed how I work, is that as a software engineer you are going to find yourself doing more challenging and complex work, and if you persist in practicing what you learned as a coder, you will start hating your work. Something has to change between "coder" and "software engineer", and it's *you*.

If you are writing software, you will make mistakes and will need to correct them. This inevitably means returning to old code, rereading, understanding and reworking it. You will be surprised by how long-lived even tiny throw-away snippets will be. For this reason you need to write code in such a way that returning to modify it will not be painful. In so many words, the way you "construct" your programs matters.

There are three books which profoundly changed how I work. These are "Debugging the development process", "Writing solid code" and "Code complete". The first two were written by Steve Maguire and are probably out of print (but can be bought used rather cheaply). The last was written by Steve McConnell and is still in print. If you are going to read just one of these books, make it "Code complete". The drawback of "Code complete" is that it's rather long, though, while the other two books are shorter. However, I found that reading "Code complete" is exceptionally rewarding. Every chapter you read will change how you work and build software, if you are willing to question the way how you work today.

As for books on algorithms, I wish I could point to a set that was helpful to me, but the fact is that most algorithm collections are either very mathematically inclined, or used as teaching tools in computer science education. This means that if you need a solution for a practical problem you'll either have to wade through pages and pages with greek lettering and proofs that, yes, the algorithm actually does work (never mind how it works), or you'll get useful information on implementing algorithms from which one crucial piece is missing because the book uses that missing piece in a course exercise (you now know how to correctly construct a B-tree, but you don't know how to remove nodes from it, and you'll probably make big honking mistakes building an implementation of that, and it's three in the morning and your project is due by noon tomorrow, and you just ran out of coffee, and you are wearing sunglasses because your eyes hurt, and what could possibly go wrong now).

So... the next best thing I can recommend is a book that explains the basic algorithms which you are going to find are used pretty much everywhere. There are highly specialized algorithms, such as for cryptography, graphs or numerics, but you'll probably meet sorting and searching in most of the work you do. These basics are decently explained in books such as "Algorithms" by Robert Sedgewick. This book is still affordably priced, and the older used versions aren't so bad either, and cheaper.

The big problem with algorithms in general is that you need to know where to look when you are working on a problem which requires a better optimized solution than the basic stuff you knocked together. Not everything can be tackled as an application of sorting or searching algorithms, or whatever tricks you learned so far. But before you can look for a solution, you need to know where to look, except you don't even know where to start looking. Sound familiar? I found help in a book called "The algorithm design manual" by Steven Skiena. It contains a big catalog of algorithmic problem categories. Flip through the pages, read the introductions, consider if they generally match your problem, and if they do, look up the material listed on the page. There is an online version to complement the printed book at http://www3.cs.stonybrook.edu/~algorith/, don't miss it.
Title: Re: Layers.library V45 on the aminet
Post by: Thorham on September 18, 2014, 03:34:01 PM
Wikipedia seems to have some good articles about software engineering.

Software engineer: http://en.wikipedia.org/wiki/Software_engineer
Software engineering: http://en.wikipedia.org/wiki/Software_engineering
Title: Re: Layers.library V45 on the aminet
Post by: Cosmos on September 18, 2014, 04:53:52 PM
Quote from: olsen;773283
There are three books which profoundly changed how I work. These are "Debugging the development process", "Writing solid code" and "Code complete". The first two were written by Steve Maguire and are probably out of print (but can be bought used rather cheaply). The last was written by Steve McConnell and is still in print. If you are going to read just one of these books, make it "Code complete". The drawback of "Code complete" is that it's rather long, though, while the other two books are shorter. However, I found that reading "Code complete" is exceptionally rewarding. Every chapter you read will change how you work and build software, if you are willing to question the way how you work today.http://www3.cs.stonybrook.edu/~algorith/, don't miss it.


For me, learning from books is a mistake : the better and best way is to learn by yourself.

Start learning with tiny programms, understand how they works, modify them...

Little by little, your skill will grow up. When you don't understand something, email a confirmed coder (by not Thomas Richter, please !) for explanations... And so on...

I do that for me and I reached an high level...


Good luck !!


:)
Title: Re: Layers.library V45 on the aminet
Post by: itix on September 18, 2014, 05:24:22 PM
Quote from: Cosmos;773305
For me, learning from books is a mistake : the better and best way is to learn by yourself.

Start learning with tiny programms, understand how they works, modify them...


Your coding skills get better when you see fancy constructs but theory is still important. From books you can learn new algorithms, coding practises, development models, optimization (famous big O) and anything that helps to write better code in any language.

I used to be asm coder like you but when I had my first optimization class at uni I realized I had done it wrong. I was looking at details when I should have looked at the bigger picture.
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 18, 2014, 05:30:15 PM
Quote from: Cosmos;773305
For me, learning from books is a mistake : the better and best way is to learn by yourself.


I have to disagree with you on that.

The best way to learn is to experiment/explore, make mistakes and find out why you made them, then avoid making them again if possible. The problem with making mistakes is knowing when you are making them.

If you are lucky, you will, after a while, realize by yourself that you made a mistake or left an alternative option to solve a problem unexplored.

You don't always get lucky. It's by far more effective to know somebody who understands your work, can give you his opinion on it and offer insights.

A third person may be able to tell you when you are on the wrong track, drawing the wrong conclusions or have falsely convinced yourself of having explored a problem to the fullest. All by yourself you are far less likely to arrive at the same conclusion.

There's a term for that: confirmation bias. Don't believe that you are immune, you're human like the rest of us.
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 18, 2014, 05:49:14 PM
Quote from: Thorham;773304
Wikipedia seems to have some good articles about software engineering.

Software engineer: http://en.wikipedia.org/wiki/Software_engineer
Software engineering: http://en.wikipedia.org/wiki/Software_engineering

These articles are, frankly, a bit scary. Back when I started out programming computers in my spare time, as a hobby, I didn't realize how long the road ahead would be before I became a halfway decent programmer.

Part of the journey took me through practicing the craft (which everybody can do in his own home, without any heavy lifting involved, except for flipping through those heavy 'C' compiler reference manuals and operating system documentation), part of it took me through a professional education.

If you didn't know with all your heart that programming was fun, interesting and worth the slog, you probably wouldn't want to follow through the professional education, as it is too often tedious, impractical and unfairly challenging. This can be pretty dry and boring (I hope that I'll never have to sit through another lecture on stochastics or information theory; luckily, I got my degree and probably never will have to sit through any of these again!), and these two Wikipedia articles are far from making this profession appear to be something you might want to spend the rest of your life practicing.

As for the books I mentioned, I think they are helpful for practicing the craft even if you don't consider going the route of getting a professional education in the field. What you will find in them metaphorically makes the difference between chopping down a tree using nail clippers or, well, an actual axe, when it comes to programming.
Title: Re: Layers.library V45 on the aminet
Post by: Cosmos on September 18, 2014, 05:51:01 PM
Quote from: olsen;773310
I have to disagree with you on that.

The best way to learn is to experiment/explore, make mistakes and find out why you made them, then avoid making them again if possible. The problem with making mistakes is knowing when you are making them.

If you are lucky, you will, after a while, realize by yourself that you made a mistake or left an alternative option to solve a problem unexplored.

You don't always get lucky. It's by far more effective to know somebody who understands your work, can give you his opinion on it and offer insights.

A third person may be able to tell you when you are on the wrong track, drawing the wrong conclusions or have falsely convinced yourself of having explored a problem to the fullest. All by yourself you are far less likely to arrive at the same conclusion.

There's a term for that: confirmation bias. Don't believe that you are immune, you're human like the rest of us.

No, no, sorry : the authors of your books will "programm" the readers beginner to follow a way...

I started asm using 2 books and the result was a give up : I understood few things only...

After some years, I started again with my method described above, and this time it works good for me...

I wrote my story here (in french, but you can translate using "Traduction" on the left) : http://assembly68k.blogspot.fr/p/blog-page_24.html

For me, the best is to learn by yourself, to "build" YOUR own way with using (and developping) your imagination and understanding...


Anyway, do what you feel better for you, I just give here my opinion and my experience...



:)
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 18, 2014, 06:02:19 PM
Quote from: Cosmos;773316
No, no, sorry : the authors of your books will "programm" the readers beginner to follow a way...
This is what an education does, doesn't it? Same thing about religion...

Programming and the different practices of programming have been invented and reinvented multiple times, starting with the 19th century, and have finally been reduced to theory in the 20th century.

You are likely following the invisible footsteps of somebody who came before you. Your journey and the discoveries you made will be your own, but there is a wide world out there which already shares these ideas and has been expanding upon them for more than 70 years.

The guys outside your room who practice the same craft know a thing or two which you are missing out on.

Quote from: Cosmos;773316
For me, the best is to learn by yourself, to "build" YOUR own way with using (and developping) your imagination and understanding...

Anyway, do what you feel better for you, I just give here my opinion...
:)
Best of luck to you! If this is what works for you, who am I to criticize you?
Title: Re: Layers.library V45 on the aminet
Post by: Minuous on September 18, 2014, 06:35:31 PM
Quote from: olsen;773283
There are three books which profoundly changed how I work. These are "Debugging the development process", "Writing solid code" and "Code complete".

I've read the 2nd and 3rd of these, and can confirm they are very good for high-level language programmers (maybe less relevant for assembly language coders such Cosmos). They are available at http://amigan.1emu.net/aw/
Title: Re: Layers.library V45 on the aminet
Post by: kamelito on September 18, 2014, 07:19:49 PM
@Olsen
>Well, you asked for it ;)

Thanks. About Code complete AFAIR the first edition is about C and the other about OO languages. Is the first edition enough?
I read good comments about Programming Pearls any thoughts about this book?

Regards
Kamelito
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 18, 2014, 08:01:57 PM
Quote from: kamelito;773329
@Olsen
>Well, you asked for it ;)

Thanks. About Code complete AFAIR the first edition is about C and the other about OO languages. Is the first edition enough?

I only read the first edition, always was planning to give the second a look, though.

Quote from: kamelito;773329

I read good comments about Programming Pearls any thoughts about this book?
Regards
Kamelito

I wouldn't have recommended it, because it covers so much ground. There is programming practice, the matter of verifying that you got your implementation right, understanding how algorithms work, how optimizations can be made, and when they are useful (estimation methods, why optimization matters). As a book on getting to know your craft, and when to try picking a better algorithm than you already have, and why it may not be a good idea, it's as good as it gets.

The chapter on algorithm design techniques which has an example of how an algorithm in interpreted BASIC on a TRS-80 using a 1.7 MHz Z-80 CPU can beat a different implementation of that algorithm, written in 'C' and running on a DEC workstation using a 300 MHz Alpha CPU is worth the price of admission alone!

Enjoy :)
Title: Re: Layers.library V45 on the aminet
Post by: Bif on September 19, 2014, 09:21:00 AM
That's an interesting question - what defines a coder vs. a software engineer. Hadn't thought of it in those terms until now.

My personal revelation from my own growth experience is I feel software engineering is more about code development process than knowledge of design patterns/languages, etc. Of course those are important too but I think without good process you are going to have far more problems than you should with your resulting code.

A might think a coder writes code without really caring too much how they get something done as long as they get their immediate problem/feature working. They have their own way of working that they feel works for them.

A software engineer employs a large number of long standing good practices that help in creating large and complex programs that contain few bugs.

I would say for the first 15 years of my career I was more of a coder. In the last 10 years I feel I'm more of a software engineer. I evolved because people that were smarter/more experienced than me were brought in to make a concerted effort to increase code quality in our large development studio.

While there are many processes I have learned and employed to write better code, the main differences that saw me evolve were moving to test driven development and automated testing. Hackers always avoid this as they feel it is too much work and will slow down development (they are usually too busy fighting fires due to their undiscovered bugs to have "time" to make the switch).

I'm tempted to write all sorts of stuff describing this but I don't want to waste time, Google it if interested. All I can say is since adopting these practices, only maybe one or two minor bugs a year are found by my customers in the code that I write. It's not that I am super smart or write perfect code, it's just that I find all my bugs before I release my code by writing thorough tests (using code coverage tools, etc.) - and I only have to press one key to run thousands of tests across all sorts of platforms and configurations - something that is always done before code is checked into source control. It gets to the point where this becomes a safety net you cannot live without. If I need to change some existing code I don't even need to think the ramifications through much - my main question will be, does it pass my existing tests? Oh it does? Code is probably good then. To think of trying that without test scares the crap out of me now.

Now when I see other people just coding something up, running some quick manual test that covers maybe 20% of the code paths, and just "figuring the rest will work because it should because I am smart" I have to shake my head. Sadly I work on a team where the other coders still do this. They are constantly chasing bugs, and frustratingly my tests in my code area run into all sorts of their bugs in their areas (these are large complex projects), and it is unbelievably expensive to have to continually communicate the problems and schedule fixing when they could have just found the bug while writing their code so that I didn't have to waste hours dealing with something they have to fix anyway.

I think it is to the point where if I am ever interviewing for a job again, I will interview them about their coding department's software engineering processes before I accept an offer. I will refuse to work with "coders" again.

Anyway, that's just my personal view on it, maybe not some well defined definition, but that's how I feel.
Title: Re: Layers.library V45 on the aminet
Post by: modrobert on September 19, 2014, 11:33:41 AM
My advice is to adopt a shameless attitude towards learning in general, all the information is out there on internet these days if you dig deep enough.

Want to learn a new physics theory? Watch a lecture when the professor who won the recent Nobel price for it explains the theory in detail, made freely available as a video by some University or foundation. If there is something he/she is talking about you don't understand, then search and learn about that as well. Just keep trying, give it time, eventually you will learn. After doing this you will start to get your own ideas and think about solutions to problems not yet solved.

Want to learn hardware design? Learn electronics. Read primers and books (PDF) about VHDL/Verilog on internet until your eyes bleed. After a couple of years, when you design your first state machine (simple CPU) and code a little program running on it, all the effort will be worthwhile.

Want to learn software engineering? Learn the basics of a computer language, anything will do, and then, for example, look at the fastest known sorting method. Tweak something in the code, experiment, watch what happens, even if it gets slower, why did it get slower? One morning you might wake up with a tweak idea which makes it slightly faster. The thrill of that might inspire you to write your own sorting method one day.

Want to learn philosophy? Good, it will help you to think out of the box, and come up with new ideas because suddenly abstraction takes you beyond previous borders of comprehension.

Why not learn all of the above? You can do it, don't let anyone make you think otherwise.

Don't worry about a career, don't worry about academia and titles. Instead, use internet and learn for the sake of knowledge which is its own reward. One day, you will have the potential to be more than anyone blindly following the wisdom of others, make your own path, and eventually others will follow you instead.
Title: Re: Layers.library V45 on the aminet
Post by: kamelito on September 19, 2014, 12:59:18 PM
I'm wondering if OS 4.x is tested against tools like purify, valgrind or PVS Studio or any others tools like that to improve code quality and if automated tests cases are run before production.

Kamelito
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 19, 2014, 01:35:42 PM
Quote from: kamelito;773373
I'm wondering if OS 4.x is tested against tools like purify, valgrind or PVS Studio or any others tools like that to improve code quality and if automated tests cases are run before production.

Kamelito
As far as I know none of these tools exist for the OS4 target platform. For Purify and Valgrind that's a real dealbreaker (Valgrind needs an x86 platform, Purify is available for IBM Power architecture, but still seems to need a POSIX operating system to work its magic). As for PVS Studio, it seems that it could be used for static analysis even if the code produced was never intended to run on the PowerPC. I have no idea how good the static analysis capabilities of PVS Studio are compared to, say, LLVM-based Xcode, but I've used Xcode extensively for a small Amiga project of mine, and it certainly did help to shake a large number of bugs out of the code.

As for OS4 development work, if such code quality tests were available for the development environment, and properly integrated, it certainly would be very useful. Back in the day when Commodore switched from using a cross compiler to native development, employing the more modern Lattice and Aztec 'C' compilers, code quality did improve.
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 19, 2014, 02:24:00 PM
Quote from: Bif;773363
That's an interesting question - what defines a coder vs. a software engineer. Hadn't thought of it in those terms until now.

My personal revelation from my own growth experience is I feel software engineering is more about code development process than knowledge of design patterns/languages, etc. Of course those are important too but I think without good process you are going to have far more problems than you should with your resulting code.

My personal take on the difference between what these terms stand for is that the software engineer has a significantly bigger toolbox to draw upon than the coder. For the software engineer, the toolbox contains such things as process, a common language (terminology), and a big collection of methods which have been tried and tested.

None of this is the exclusive domain of the software engineer, the coder can use these tools, too. The thing is, if you practice software development professionally and enjoyed a professional education, you acquire this toolbox and it becomes part of your daily work. The coder has to work harder on acquiring it, and chances are that he won't be exposed to tools which a software engineer winds up finding in his toolbox as part of his education that at the time when they show don't seem to matter much. Only lateron some of their value may become apparent, and then it's often of crucial importance. A coder may not see the immediate value and discard that tool.

This sounds pretty abstract, so I'd like to give an example of such a tool that might show up one day and prove its value lateron: software configuration management (SCM), using tools such as SCCS, RCS, CVS, SVN, git, you name it. One can make backups of the source code as one maintains and modifies it, and that may be sufficient if the code base is small and the changes are sufficiently small as to be manageable. But one might cross the threshold when this is no longer the case, and if one hasn't picked up the habit of using an SCM, one may not realize how much work and effort it saves in the long run.

Quote from: Bif;773363

A might think a coder writes code without really caring too much how they get something done as long as they get their immediate problem/feature working. They have their own way of working that they feel works for them.

A software engineer employs a large number of long standing good practices that help in creating large and complex programs that contain few bugs.

Somebody might argue that a coder can accomplish the same thing through grit and determination alone ;)

The big difference here may be in that you learn to use tools to do the work for you which the coder still has to do all by himself, using his brains alone. If a task can be performed through automation, it is reasonable to assume that it can be done more quickly in this form than a human could, and it's probably quite boring to begin with. It will save you time and effort which you can spend elsewhere. Instead of combing your code for problems, testing it one problem fix at a time, you can focus on different and more complex aspects of the software.

Quote from: Bif;773363

I would say for the first 15 years of my career I was more of a coder. In the last 10 years I feel I'm more of a software engineer. I evolved because people that were smarter/more experienced than me were brought in to make a concerted effort to increase code quality in our large development studio.

While there are many processes I have learned and employed to write better code, the main differences that saw me evolve were moving to test driven development and automated testing. Hackers always avoid this as they feel it is too much work and will slow down development (they are usually too busy fighting fires due to their undiscovered bugs to have "time" to make the switch).

I know all too well to what you refer to :(  What always gets me is how programmers can be so confident and effective in making their lives not just harder, but really miserable by working without the assistance of simple tools which others use regularly.

You certainly can create code with a simple text editor, without using an SCM, test the code manually without even using a debugger, crank out code which makes testing hard, makes the code hard to read, etc. but it's not going to make you happier or make it easier to collaborate with your collleagues. You'll probably just end up spreading the misery.

Yet this is par for the course for many programmers you are going to meet. It's not just that they work like they do, by rejecting just about every tool you have been using to great effect in the past 20 years, they tend to insist that you have to work like them because they find it difficult to understand why anybody would even bother using different tools and methods than they do. Things tend to get difficult at this point :(

Quote from: Bif;773363

I'm tempted to write all sorts of stuff describing this but I don't want to waste time, Google it if interested. All I can say is since adopting these practices, only maybe one or two minor bugs a year are found by my customers in the code that I write. It's not that I am super smart or write perfect code, it's just that I find all my bugs before I release my code by writing thorough tests (using code coverage tools, etc.) - and I only have to press one key to run thousands of tests across all sorts of platforms and configurations - something that is always done before code is checked into source control. It gets to the point where this becomes a safety net you cannot live without. If I need to change some existing code I don't even need to think the ramifications through much - my main question will be, does it pass my existing tests? Oh it does? Code is probably good then. To think of trying that without test scares the crap out of me now.

Now when I see other people just coding something up, running some quick manual test that covers maybe 20% of the code paths, and just "figuring the rest will work because it should because I am smart" I have to shake my head. Sadly I work on a team where the other coders still do this. They are constantly chasing bugs, and frustratingly my tests in my code area run into all sorts of their bugs in their areas (these are large complex projects), and it is unbelievably expensive to have to continually communicate the problems and schedule fixing when they could have just found the bug while writing their code so that I didn't have to waste hours dealing with something they have to fix anyway.

This sounds painfully familiar :(

My personal impression is that if you are going to have a life and a job writing code, then you'd better make writing the code a task which does not impinge on your life. That means having a plan for dealing with the task at hand (a process) and a big enough tool box to draw upon when facing the unexpected. If you are going to slip and fall, you ought to be able to stand up and try again.
Title: Re: Layers.library V45 on the aminet
Post by: psxphill on September 19, 2014, 03:12:19 PM
Quote from: olsen;773379
My personal take on the difference between what these terms stand for is that the software engineer has a significantly bigger toolbox to draw upon than the coder.

It's pointless to use terms when you are applying your own definition of what they mean, as words are only useful to communicate your ideas.

http://en.wikipedia.org/wiki/Programmer (http://en.wikipedia.org/wiki/Programmer)

"A programmer, computer programmer, developer, coder, or software engineer is a person who writes computer software (http://en.wikipedia.org/wiki/Computer_software)"

http://en.wikipedia.org/wiki/Software_engineer

"Software engineers apply the principles of engineering to the design, development, maintenance, testing, and evaluation of the software and systems that make computers or anything containing software work."

Most people who call themselves software engineers are doing it through arrogance as they are piss poor programmers who can't design for toffee. If you call yourself a software engineer because you think it sounds good, then be careful where you work.

"Some of the states regulate the use of terms such as "computer engineer" and even "software engineer". These states include at least Texas[30] (http://en.wikipedia.org/wiki/Software_engineer#cite_note-30) and Florida.[31] (http://en.wikipedia.org/wiki/Software_engineer#cite_note-leg.state.fl.us-31) Texas even goes so far as to ban anyone from writing any real-time code (http://en.wikipedia.org/wiki/Real-time_operating_system) without an engineering license"

I've never called myself a software engineer because I'm not that pretentious, I preferred the term software developer. If I was arrogant I'd call myself a software architect, which trumps your made up software engineer status.
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 19, 2014, 05:33:58 PM
Quote from: psxphill;773383
I've never called myself a software engineer because I'm not that pretentious, I preferred the term software developer. If I was arrogant I'd call myself a software architect, which trumps your made up software engineer status.
As far as I know the term "software engineer" is not a "standardized" professional term.

It has been used as shorthand for applying the professional standards which engineers are held to in the field of software development. Not a bad idea, considering what a mixed bag the professional standards in software development tend to be. If I remember correctly, the term "software engineering" goes back at least thirty years, and look how far we've come since then :-/

The term has also been used to denote differences in status between the lowly programmer, the programmer who has leveled up twice, and so forth, up to the apex of the imaginary pyramid, where presumably the "principal architect" sits (what do you give a programmer if you can't pay him a higher salary? a fancy job title) and looks downward, smiling benevolently and drawing the kind of salary which allows him to smile, if not smirk, and hardly lift a finger actually doing any programming work ;)

The term "software engineer" can be anything to anybody. Which is why I mentioned the context in which I used it. Because Thomas used this term to make his point, it does seem prudent to me to keep using it.

As for attaching status to titles, I'd personally be content to be known as a reliable programmer who tries to solve interesting problems and most of the time gets results ;)
Title: Re: Layers.library V45 on the aminet
Post by: psxphill on September 19, 2014, 07:30:06 PM
Quote from: olsen;773392
The term "software engineer" can be anything to anybody. Which is why I mentioned the context in which I used it. Because Thomas used this term to make his point, it does seem prudent to me to keep using it.

If you know that everybody has a different meaning to it, then why would you waste time assigning your own meaning and using the term?

All you'll do is have endless arguments over what the term means, which can't be solved as you are only one person and statistically nobody cares about your point of view.

Life is too short, which is why I'm not going to push you to understand my point of view.
Title: Re: Layers.library V45 on the aminet
Post by: Karlos on September 19, 2014, 08:13:26 PM
Quote from: wawrzon;773225
you have had access to the sources and been working on a w3d driver predating os4? wow!


It was a long time ago. I was trying to write some code around the V4 API and it kept having issues on my BVision. Somehow I ended up volunteering to find the source of the bugs and I got access.

Although the driver was never publicly released for the issues stated earlier,  the specific architectural changes that made the updated driver much smaller were adopted in the later drivers for other chips.

I later got involved in Warp3D on OS4 because I was one of few people with the necessary experience and will. I (re)wrote the Permedia driver for OS4 based on my updated 3.x code.

I like Warp3D, but it has far outlived it's usefulness. It's closed, deprecated and for many reasons it'll never deliver the full performance of the hardware it can support.

IMHO, for better 3D in OS3.x (and indeed OS4 on lower end machines), we need a replacement, open-source driver system, designed from the ground up on and for our machines. Such a driver could then have wrappers implemented for both Warp3D and OpenGL.

I have a lot of ideas for this, but no time.
Title: Re: Layers.library V45 on the aminet
Post by: itix on September 19, 2014, 08:21:00 PM
Quote from: psxphill;773383

"Some of the states regulate the use of terms such as "computer engineer" and even "software engineer". These states include at least Texas[30] (http://en.wikipedia.org/wiki/Software_engineer#cite_note-30) and Florida.[31] (http://en.wikipedia.org/wiki/Software_engineer#cite_note-leg.state.fl.us-31) Texas even goes so far as to ban anyone from writing any real-time code (http://en.wikipedia.org/wiki/Real-time_operating_system) without an engineering license"


That is quite funny to is Finns. Here in Finland title is (usually) used to describe your job than competence. It has gone ven so far that I can craft my job title if I want to. And sometimes i do. So far I have been Software engineer, embedded engineer, project engineer, research engineer, training engineer, development engineer and it could be anything relating to my work. :)
Title: Re: Layers.library V45 on the aminet
Post by: psxphill on September 19, 2014, 08:23:17 PM
Quote from: itix;773414
That is quite funny to is Finns. Here in Finland title is (usually) used to describe your job than competence. It has gone ven so far that I can craft my job title if I want to. And sometimes i do. So far I have been Software engineer, embedded engineer, project engineer, research engineer, training engineer, development engineer and it could be anything relating to my work. :)

Yes, it's why we have sandwich artists and kitchen technicians.
 
 The job title you have is largely irrelevant, I'd rather have more money than a flashier title (some companies stroke your ego with a flashy title just so they can pay you less)
Title: Re: Layers.library V45 on the aminet
Post by: itix on September 19, 2014, 08:29:10 PM
Quote from: psxphill;773416
Yes, it's why we have sandwich artists and kitchen technicians.
 
 The job title you have is largely irrelevant, I'd rather have more money than a flashier title (some companies stroke your ego with a flashy title just so they can pay you less)


I have been told that in India if you don't get promoted regularly employees quit. So companies have invented different levels of engineers, like level 1, 2, 3 etc software engineers to keep workers happy.
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 21, 2014, 09:13:58 AM
Quote from: kamelito;773249
@Olsen @Thor,

Since it's too late to go back to school, could you please give a list of good books to go from a "coder" to a "software engineer". Being about C, C++, Algorithms, Design patterns whatever else suit you.

Thanks
Kamelito
I missed one book which might be helpful, and which is also very readable: "The practice of programming", by Brian Kernighan and Robert Pike. It covers some of the same ground as the "Programming pearls" collection, but complements it well with material absent from it, such as testing and debugging. I'd say that had this book been available to me some 25 years ago, it would have opened doors which at the time I did not even know to exist.
Title: Re: Layers.library V45 on the aminet
Post by: kolla on September 21, 2014, 02:33:59 PM
Quote from: olsen;773379

This sounds pretty abstract, so I'd like to give an example of such a tool that might show up one day and prove its value lateron: software configuration management (SCM), using tools such as SCCS, RCS, CVS, SVN, git, you name it.


Hm, my mind boggles - in my book, SCM is a tad more than just a revision system, Software Configuration Management is more a tool for system administration, rather than software development. SCM also include automated building and testing of software (hudson, jenkins, codeship, cruisecontrol...), change control with peer reviewing before deployment (puppet, chef, cfengine ...) Of course, using such tools can also be usefull for developers too, and these days I dont know any coders who don't at least use a revision control system.
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 21, 2014, 03:36:58 PM
Quote from: kolla;773583
Hm, my mind boggles - in my book, SCM is a tad more than just a revision system, Software Configuration Management is more a tool for system administration, rather than software development. SCM also include automated building and testing of software (hudson, jenkins, codeship, cruisecontrol...), change control with peer reviewing before deployment (puppet, chef, cfengine ...) Of course, using such tools can also be usefull for developers too, and these days I dont know any coders who don't at least use a revision control system.

Modern times indeed. You'd be surprised how many people don't even know or care about SCM, even in its most simplistic form. Even talking them about it you're met with the kind of gaze I supposed is reserved for looking at cranky children, axe murderers and the remains of a dead rat which turned out to be hidden in a piece of sponge cake.

You are correct that the purpose of SCM goes beyond the simple stuff, yet it's the simple stuff which is underestimated, and the more complex stuff is ignored because you can do even the simple stuff manually, so why care?

Part of the job of developing software, performing system administration, etc. is not to become complacent and at least have an eye on where the field is moving. You can adopt what you find useful, after you have evaluated it. But in some cases that bit never happens, because things work well as they do. Until they don't, and when they suddenly don't work any more, you're in bound to be in a profoundly unhappy place :(
Title: Re: Layers.library V45 on the aminet
Post by: kamelito on September 21, 2014, 07:46:28 PM
Quote from: olsen;773565
I missed one book which might be helpful, and which is also very readable: "The practice of programming", by Brian Kernighan and Robert Pike. It covers some of the same ground as the "Programming pearls" collection, but complements it well with material absent from it, such as testing and debugging. I'd say that had this book been available to me some 25 years ago, it would have opened doors which at the time I did not even know to exist.


Thanks
Kamelito
Title: Re: Layers.library V45 on the aminet
Post by: Minuous on September 22, 2014, 07:04:12 AM
Quote from: kolla;773583
I dont know any coders who don't at least use a revision control system.


I don't use one, it doesn't make much sense for solo projects...
Title: Re: Layers.library V45 on the aminet
Post by: biggun on September 22, 2014, 07:26:52 AM
Quote from: Minuous;773639
I don't use one, it doesn't make much sense for solo projects...


Its crucial for team projects
and it can be very helpful also for solo projects.

Imagine a big project with many files on which you work for several years.
Every code change you did is with a revision system "marked" with a comment explaining its intention.
E.g.
"chip-bus rewrite to lower latency"
"decoder PC-calc change to improve clockrate"
"Ea rewrite to reduce LE count"
...
With a revisioning system you could "rollback" certain code changes even much later - if you expect them to cause problems.

You can also flag certain know good/stable version easily.
And you can easily mark releases.

If you give our releases to customer you can later apply importatn fixes to these releases as updates - without adding new features whih the main developmen stream might have,

For a sensible software development with release which get supported etc - something like a revision system is required to be able to do this.
Title: Re: Layers.library V45 on the aminet
Post by: psxphill on September 22, 2014, 08:17:39 AM
Quote from: biggun;773643
and it can be very helpful also for solo projects.

Imagine a big project with many files on which you work for several years.

Yeah, I rarely bother for solo projects that I am not going to share. But these usually turn out to be one off throw away programs anyway. While it makes some sense to source control those too, it is one of those jobs you put off. Like deleting old emails you no longer need.
 
 The biggest problem is when you write crappy programs that have hard coded paths etc, then these show up as changes in source control. You should split those out into configuration, but when it takes 30 seconds to write the code in the first place then making it tidy and putting it into source control is hardly worth it.
 
 You also have to maintain a server yourself, but if you're part of a team then you can offload that to someone else.
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 22, 2014, 08:48:26 AM
Quote from: Minuous;773639
I don't use one, it doesn't make much sense for solo projects...

It can make good sense for solo projects, though modern SCMs make it look as if the technology is primarily enabling collaboration.

I started using RCS some twenty years ago in my small projects for two reasons.

The first reason is that the more you change your code, the harder it becomes to keep track of the changes. Instead of a single .bak file for each file you edited, or a collection of backup files which are tagged with a date in their names, you can keep all the changes in a single SCM file. There's also one common interface for storing the changes and retrieving them. Compare making individual backup files with just committing a change with a comment, and then later using the diff command integrated into your SCM tool to look at them, to comparing individual backup files manually.

The second reason is that a project can change scale and scope, and you may not notice how the daily changes gradually push it into a direction which make it harder to manage. The SCM acts as a safety-net, so that if your project crosses a certainly complexity threshold, you can still roll back changes, or review older revisions. Using the SCM regularly isn't that much of an effort. Getting back at the change history you cannot easily recover (because you don't have one, or because it only goes back 1-2 edits) puts a bigger burden on your work.

You don't have much to lose if you use an SCM in solo projects :)
Title: Re: Layers.library V45 on the aminet
Post by: Minuous on September 22, 2014, 11:28:46 AM
I keep copies of each older release, and also a changelog of what was done for each new release. Plus, anything which is non-obvious as to its purpose (eg. a change to my emulator which is needed for compatibility with some obscure guest program) has a comment to that effect in the source. Those three measures have proven adequate for me. Plus, last time I checked, these revision control systems seem to require use of a makefile. YMMV; I'm not saying that revision control is useless for everyone, but if your coding is done in a disciplined way it's not necessary.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 22, 2014, 12:28:59 PM
Quote from: Minuous;773653
I keep copies of each older release, and also a changelog of what was done for each new release. Plus, anything which is non-obvious as to its purpose (eg. a change to my emulator which is needed for compatibility with some obscure guest program) has a comment to that effect in the source. Those three measures have proven adequate for me. Plus, last time I checked, these revision control systems seem to require use of a makefile. YMMV; I'm not saying that revision control is useless for everyone, but if your coding is done in a disciplined way it's not necessary.

Look, I worked the same way like 20 years ago when all at a sudden I was forced to use a revision control system (not even a full-fledged SCM) when I started in industry. At first, it sounded like an unnecessary overhead and a needless burden, but it was not. The learning curve for a simple tool like CVS or SVN is not very heavy. It really proved to be a very useful tool, even more so as you could go back any time you wanted, you could run a "bisection" to see in which release you introduced a bug, and you could follow the revisions and history easily.  

What you want to have in professional development is some kind of "development release" where you test your ideas, and a "stable" release you ship to your customers. If you make fixes in one release, you want to merge them to the other, but new ideas stay "local" until they have been tested, and have been exposed to the customer. Typically, "your customer" also has "customers", and thus, you would need to keep several revisions around in case your customer comes back to you with problems their customer had.

I was then rather shocked to find  when our company took over another company on the "professionalism" of our ex-competitors for using "manual revision control", i.e. manually copying source files around. This is very error prone, and you often forget to merge something, or check for conflicts. As soon as your project grows larger and becomes complex or you get new team members, you're lost. Instead of depending on an in-house protocol, rather depend on a protocol every professional engineer should know.  

Nowadays, I really regret that I did *not* use a simple revision control system (even RCS or CVS would have worked) for many of my Amiga sources. Lots of old code is lost in limbo, or somewhere in some strange places (manual backups) without enough information how the pieces fit together. It really pays off, and I would strongly suggest to try before banning a simple tool. Note well, I'm not talking about a full-fledged SCM like perforce (I kinna hate tools that "get in your way", and p4 is a prime candidate for it because you cannot use it without a longer lecture on its principles - but if you're working in a larger group, it's arguably unavoidable.) but really about simple minded elementary tools that can save your day.

Hence, yes I regred that I do not have a formal education in such tools, and I had to learn the hard way that they are very necessary. Don't be the same fool I was years ago. I simply didn't know better... but at least you should now know better when people that did get a formal education (unlike me) tell you.
Title: Re: Layers.library V45 on the aminet
Post by: olsen on September 22, 2014, 01:05:57 PM
Quote from: Minuous;773653
I keep copies of each older release, and also a changelog of what was done for each new release. Plus, anything which is non-obvious as to its purpose (eg. a change to my emulator which is needed for compatibility with some obscure guest program) has a comment to that effect in the source. Those three measures have proven adequate for me. Plus, last time I checked, these revision control systems seem to require use of a makefile. YMMV; I'm not saying that revision control is useless for everyone, but if your coding is done in a disciplined way it's not necessary.
That certainly can work, but it may not always work. Some 25 years go I could literally remember everything that went on in a program, its configuration files, it data files, what all the constants meant and how they were used.

Nowadays there's not so much of the old zing around (maybe the programs became bigger, maybe the tools got better), and I have become too lazy to do manually what a script, a program, a tool could do automatically for me.

Maintaining a change log is necessary, and it is very convenient to maintain it through subversion (SVN) commit messages, which lateron get folded into a release log file. The subversion repository keeps track of my file changes, the change log data that describes the changes, and it contains the release log file, too.

If need be, I can use the subversion repository to roll back changes I made (undo), and I can go back to old releases for review. All of that can be done by reviewing archived changes, stored in individual files (which clutter up the directory), but with a revision control system you just tell it to retrieve the file change history and you're able to review each small change you made and committed.

If you change one character in a file you can commit the change and it won't eat up a lot of disk space (revision control systems store differences between subsequent revisions), but you probably wouldn't store a full backup copy of that file for later reference.

The subversion command does work which I need to do anyway, and it allows me to spend far less time on it than doing it manually would. There are positive side-effects as well.

Revision control systems such as the old RCS, CVS and SVN do not need a makefile. It's possible that the makefile contains rules for invoking these programs, but these are just icing on the cake. You could invoke these commands manually and it would not change a thing.

What is needed is a place to store the revision information, etc. Both the old RCS, CVS and even subversion allow you to keep the data in a local directory on your computer. Storing that data on a separate system, where it can be safe from data corruption or loss may be a more appropriate solution though.

Once you commit to using a revision control system and clear the first hurdle in setting up a repository, it can become second nature to use it for every project you work on, no matter how small. If you consider each small project in isolation, then setting up the repository may look like unnecessary, unwarranted effort. But if you do start using it, then every project, no matter how small, can benefit from having it around.
Title: Re: Layers.library V45 on the aminet
Post by: kolla on September 22, 2014, 01:39:35 PM
No revision system ever had anything to do with Makefiles, what an obscure idea.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 22, 2014, 03:47:48 PM
Quote from: kolla;773660
No revision system ever had anything to do with Makefiles, what an obscure idea.

No, makefiles and revision control are indeed independent, though both are a good idea. Make is just another one of the tools you want to know how to use, plus autoconf if you're working in a POSIX environment.

Anyhow, one thing a revision control system can do for you is to dump the version number upon check-in, in the makefile if you like.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on October 02, 2014, 12:45:26 PM
To facilitate further testing,  I prepared a new version with cliprect pooling partially disabled. It does not seem to make any difference here, though it might be *slightly* slower (due to the lack of the pools), though this is probably unnoticable.

Anyhow, I would be interested how this performs and whether it avoids the known problems of the previous release.

up.z01.zip (http://www.amiga.org/forums/attachment.php?attachmentid=3758&stc=1&d=1412250149)
up.zip (http://www.amiga.org/forums/attachment.php?attachmentid=3757&stc=1&d=1412250149)

Note that this is a beta release, i.e. your milage may vary. This is a multi-part zip archive, you first have to rename the first back to up.z01 or merge the files in the order up.z01.zip and up.zip to get one single archive which can then be extracted.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on October 03, 2014, 11:47:17 AM
Nobody interested in looking at this? Sorry, but I don't think I want to upload anything to Aminet before at least a couple of people had looked at a revised edition.  This version should likely fix the issue with Birdie (at least it seems to work fine here), and those of you who reported a problem with P96 should be ready for a small surprise.  Thanks, Thomsa
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on October 03, 2014, 11:59:06 AM
i cant test as i dont know the issue, have never used birdie and above all have only a touch device with me that doesnt cope well with winuae. sorry.
Title: Re: Layers.library V45 on the aminet
Post by: Ancalimon on October 03, 2014, 02:30:51 PM
I will test once I receive my CStormPPC back from Stachu.
Title: Re: Layers.library V45 on the aminet
Post by: Gulliver on October 03, 2014, 08:16:21 PM
@Thomas Richter

This new version of layers.library is so far working fine with Birdie.
See attached screenshot, where I show nice OS4 like window borders with Birdie and then on the CLI I show that your new layers.library is doing its thing.

BTW, I couldnt extract your new rtg.library from the archive, due to bad crc. I downloaded several times both archives, but I still get the same result, layers.library gets extracted fine but rtg.library doesnt. :(

Thank you!
Title: Re: Layers.library V45 on the aminet
Post by: vxm on October 03, 2014, 09:53:10 PM
I just basically try them inside UAE + OS 3.1 + Visualprefs. This seems OK.
Thanks for your work.

NB: No error during extraction.
Title: Re: Layers.library V45 on the aminet
Post by: Oldsmobile_Mike on October 03, 2014, 10:23:56 PM
Layers.library 45.21 working great here so far, it was nice to be able to turn Birdie back on, I'd disabled it when it didn't work with the previous new layers.library.

I also was unsuccessful in extracting rtg.library from your split zip archive thingy. WinRAR couldn't put the two pieces back together again, and I'm not downloading and trying to figure out WinZip just for that. ;)

Now that I'm messing around with turning things on & off, turns out that my 4.x-like VisualPrefs gadgets really down my system. I'd always thought that was Birdie, doing that. Huh, might have to re-think my patches! ;)
Title: Re: Layers.library V45 on the aminet
Post by: crasbe on October 03, 2014, 11:42:01 PM
Works fine here:

Linux: cat up.z01.zip up.zip > layers.zip

Windows: copy /b up.z01.zip + up.zip layers.zip
(not tested yet)

unzip complains a little bit about wrong offsets, but the extraction is successful.
Title: Re: Layers.library V45 on the aminet
Post by: Oldsmobile_Mike on October 04, 2014, 12:47:55 AM
Nope, still didn't work.  Good tip though, and for your first post, thanks!

Get a seek error trying to extract from the combined zip archive.  :(
Title: Re: Layers.library V45 on the aminet
Post by: Oldsmobile_Mike on October 04, 2014, 01:08:00 AM
Disregard my last, got it finally, just had to finagle WinRAR a bit. Thanks @crasbe!

Pumped it into my system via LoadResident, C:Version rtg.library went from 40.3992 to 40.4024. I guess the obvious questions now are:

- I didn't originally have an rtg.library in Libs: even though it was showing a version number. I guess it's in ROM?

- What are the changes/benefits of this new version? Sorry if I missed something obvious in this long thread. ;)

Thanks THoR! :)
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on October 04, 2014, 09:19:07 AM
Quote from: Oldsmobile_Mike;774448
- I didn't originally have an rtg.library in Libs: even though it was showing a version number. I guess it's in ROM?

No, it goes into LIBS:Picasso96. If you don't have P96 then you don't need the library in first place.

The suprise is a recompiled version from the sources, with all fixes applied. It is not exactly a recent version either. Just collecting dust...
Title: Re: Layers.library V45 on the aminet
Post by: Minuous on October 04, 2014, 11:18:07 AM
>I also was unsuccessful in extracting rtg.library from your split zip archive thingy. WinRAR couldn't put the two pieces back together again

It works (WinRAR 3.62), just rename up.z01.zip as up.z01 and then unzip up.zip.

layers.library is working fine now with Birdie on OS3.9+BB4 under WinUAE. Thanks ThoR for this fix.
Title: Re: Layers.library V45 on the aminet
Post by: pawelek on October 04, 2014, 12:36:53 PM
1. Video overlays now works OK with layers.library 45.19 or 45.21 and rtg.library 40.4024 :)

2. Birdie with layers 45.21 works ok :)

3. Minimize the window AmiTradeCenter still suspend with layers 45.21. Program failed error #80000008
Title: Re: Layers.library V45 on the aminet
Post by: Oldsmobile_Mike on October 04, 2014, 12:39:44 PM
Quote from: Thomas Richter;774452
No, it goes into LIBS:Picasso96. If you don't have P96 then you don't need the library in first place.

The suprise is a recompiled version from the sources, with all fixes applied. It is not exactly a recent version either. Just collecting dust...


Ah, I didn't think to look there. Still kinda new to Amiga RTG. ;-)  Thx!
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on October 04, 2014, 01:03:29 PM
Quote from: pawelek;774460
3. Minimize the window AmiTradeCenter still suspend with layers 45.21. Program failed error #80000008

I didn't even get the program working in first place. It seems to require some MUI classes, but those are installed here. It just crashes on start, probably failing a dependency check of some obscure library. I guess if the author wasn't keeping care enough to write proper tests for dependencies and returning an error instead of crashing, I wonder why I should care so much to make it working... (-;

Ok. Half a dozend missing libraries later... The program runs right into a hit when I try to load it from the workbench, calling through a6 = NULL for still some missing code - I don't know what is wrong there.

It does work from the Shell, though, and then I don't actually notice a problem with it. I can minimize the window just fine, close it, open it, and I don't get a hit or a problem. Thus, hard to say what goes wrong, but given the overall stability of the program as I experienced it I wouldn't be surprised if something is wrong here....
Title: Re: Layers.library V45 on the aminet
Post by: pawelek on October 04, 2014, 01:25:04 PM
The same error when closing AmiTradeCenter and save its settings MUI.
Title: Re: Layers.library V45 on the aminet
Post by: wawrzon on October 04, 2014, 04:01:23 PM
Quote from: Thomas Richter;774462
I didn't even get the program working in first place. It seems to require some MUI classes, but those are installed here. It just crashes on start, probably failing a dependency check of some obscure library. I guess if the author wasn't keeping care enough to write proper tests for dependencies and returning an error instead of crashing, I wonder why I should care so much to make it working... (-;

Ok. Half a dozend missing libraries later... The program runs right into a hit when I try to load it from the workbench, calling through a6 = NULL for still some missing code - I don't know what is wrong there.

It does work from the Shell, though, and then I don't actually notice a problem with it. I can minimize the window just fine, close it, open it, and I don't get a hit or a problem. Thus, hard to say what goes wrong, but given the overall stability of the program as I experienced it I wouldn't be surprised if something is wrong here....


amitradecenter? years ago as i tried it it caused read hits.
Title: Re: Layers.library V45 on the aminet
Post by: itix on October 04, 2014, 04:32:32 PM
You probably have broken NList.mcc class. It is notoriously buggy class but at that time it was the best available :p

As for crashing when deeps are missing... I know, it has never been tested with missing deps and it crashes when trying to close non-existing stuff. Broken resource tracking I would say...
Title: Re: Layers.library V45 on the aminet
Post by: lionstorm on October 06, 2014, 06:07:29 PM
can the included rtg.library be used without the layers.library ?

thanks Thor for updating your numerous gems !
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on October 06, 2014, 06:32:50 PM
Quote from: lionstorm;774570
can the included rtg.library be used without the layers.library ?
Yes, but why would you?  
Quote from: lionstorm;774570
thanks Thor for updating your numerous gems !
No problem,though the gems aren't mine. These are updates of CBM codes, and Tobias' and Alex' codes.
Title: Re: Layers.library V45 on the aminet
Post by: lionstorm on October 07, 2014, 10:09:30 PM
The reason is I am trying to get Napalm to work under AOS4.1 on my A1200PPC+BVPPC. Apparently it requires rtg.library but so far the only thing I get is a guru with the provided library, and I hope your update will make to work !
Title: Re: Layers.library V45 on the aminet
Post by: Ancalimon on November 19, 2014, 02:44:46 PM
I have received my CyberStormPPC back from Stachu.

Now I'm starting to configure things. I'm having problems with numerous 0100 000c recoverable alerts while loading workbench and while copying stuff to ram. I'll try sorting it out later.

The problem here is that adding layers.library in my Blizckick * module ....  command does not seem to replace the layers.library.

Should I use loadmodule + loadresident together with blizkick to make it work?

EDIT: I fixed to alerts. It was because that I forgot to set two jumpers on A4000T to ext after replacing 3630 with CStormPPC.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on November 19, 2014, 07:52:09 PM
Quote from: Ancalimon;777806
I have received my CyberStormPPC back from Stachu.

Now I'm starting to configure things. I'm having problems with numerous 0100 000c recoverable alerts while loading workbench and while copying stuff to ram. I'll try sorting it out later.
Which version of layers are we talking about? Are you using P96 or Cgfx? Have you installed the LayersAntiHack or did you set the environment variable to avoid CGfx patching over layers?  As for Blitzkick, I'm sorry, I but I don't know how this program works, I can't help you there.[/QUOTE]
Title: Re: Layers.library V45 on the aminet
Post by: Ancalimon on December 07, 2014, 06:06:44 AM
Quote from: Thomas Richter;777824
Which version of layers are we talking about? Are you using P96 or Cgfx? Have you installed the LayersAntiHack or did you set the environment variable to avoid CGfx patching over layers?  As for Blitzkick, I'm sorry, I but I don't know how this program works, I can't help you there.

Sorry for missing your reply. I have already sorted it out. Now I'm trying to figure out how to benchmark layers.library. It was because I forgot to set motherboard clock jumpers to external. I use CGX4 with CVisionPPC.

By the way, what is the best way to have smart refresh Workbench windows and also Workbench backdrop?

I tried http://aminet.net/package/util/cdity/smartwin31_usr from aminet which does the job and makes solid window moving really smooth. But from time to time things get very sluggish.
(for example the tasks window of Scout moves extremely slowly if I enlarge the window large enough...)
( Or sometimes moving window slow down too much when it is passing through another windows gadgets or left&right borders. Weird. The window is suddenly moving smooth again once it passes the the borders of another window and is moving on top of that window)

Should I start smartwin after or before layers antihack?
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on December 07, 2014, 10:37:48 AM
Quote from: Ancalimon;779177
By the way, what is the best way to have smart refresh Workbench windows and also Workbench backdrop?
The best way is not to install any patch and leave the refresh mode like the program authors intended them to be. Just to give you an idea: To refresh the shell window, the console (ViNCEd or console.device) have to redraw all the text within. If that is a smart refresh window, the graphics content had to be blitted from an off-screen buffer into the screen. Usually, the former is faster than the latter, at least on a graphics board, and it uses less memory (information for the missing text is stored in the console anyhow), so it is just best to leave things as they are, and not to "improve" them. "Smart Refresh" is for programs were redrawing would be a relatively costy operation, and this does not hold for the workbench or the console, all of which are trivial to refresh.

Solid window moves should be already pretty fast the way how layers works right now, i.e. when moving a layer around, it tries to preserve as many bits as possible on the move. The algorithm there improved from V40 as well and should be much better. No need to install any patch here.

Window enlargement works likewise. Layers tries to preserve as many bits as possible, but of course it needs to trigger refresh requests for the missing bits. If the program has lots of stuff to redraw, it will take a while. "Smart refresh" won't help here (Superbitmap would, but that requires native support from the program) since the "missing pieces" that become visible are not hidden anywhere, but were simply not present before.  
Quote from: Ancalimon;779177
Should I start smartwin after or before layers antihack?

You shouldn't start this at all.
Title: Re: Layers.library V45 on the aminet
Post by: TuKo on September 17, 2017, 01:29:52 PM
Hi Thomas,

I noticed some graphic glitches with the v45 library. The most visible is when using LimpidClock as it is easily reproducible.

I recorded that in a video :
https://youtu.be/rL4pSJo2mQw

Any chance to have a look at this ?
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 17, 2017, 10:30:01 PM
Quote from: TuKo;830730
Any chance to have a look at this ?

Sure, as soon as I have a chance to check with my Amiga. Can you provide details as how to reproduce it? Is it sufficient to install the mentioned program? I supose I can find it on Aminet?

V45 layers (has to) use some of the internal layers structures in a somewhat different way because the layer-arrangement algorithm is quite different. It's all "internal use only", but some programs may use this information anyhow.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 18, 2017, 05:32:19 PM
Quote from: TuKo;830730
Hi Thomas,

I noticed some graphic glitches with the v45 library. The most visible is when using LimpidClock as it is easily reproducible.

Sorry, not reproducable here. You seem to have another hack installed that performs transparent window movement. I don't know how this works, but it does not seem too unlikely that this is the culprit. What exactly are you using there?
Title: Re: Layers.library V45 on the aminet
Post by: Oldsmobile_Mike on September 18, 2017, 08:22:05 PM
Quote from: TuKo;830730
I recorded that in a video :
https://youtu.be/rL4pSJo2mQw

I couldn't for the life of me figure out what is going on here.  Could you at least point the camera directly at the screen when trying to document an issue? :laughing:
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 18, 2017, 09:57:27 PM
Quote from: Oldsmobile_Mike;830777
I couldn't for the life of me figure out what is going on here.
That is easy to spot. Apparently, the workbench misses a refresh of the backdrop layer after the front window moves away from the clock.

Now, there are two issues here: First, the system does not natively support semi-transparent or partially-transparent layers, so the clock has to fetch the background somehow. This "somehow" might be important since grabbing the contents of a window underneath requires working with layers internal structures, and in particular locking some of its structures such as nothing happens *while* the clock fetches the background. That is a potential source for the problem.

Problem number 2 is that intuition does not support full-size window movements. IOWs, whatever enables it has to interact with intution in a way that intuition did not natively support. This typically requires working on some internal structures of intuition which may fire back. In particular, the traditional window movement happens in the intuition input handler, and dependencies between this and the intuition and layers semaphores are somewhat fragile. So this is unfortunately also calling for problems.
Title: Re: Layers.library V45 on the aminet
Post by: Georg on September 19, 2017, 07:42:07 AM
Quote from: Thomas Richter;830778
Apparently, the workbench misses a refresh of the backdrop layer after the front window moves away from the clock.


No, in that area with the "trash" there is the ~non-user-visible fake-transparency LimpidClock window, not wb backdrop window. It maybe tries to auto-refresh (close/reopen
window?) the whats-behind-snapshot (initially done by opening window with LAYERS_NO_BACKFILL) at the wrong time.

Quote

Problem number 2 is that intuition does not support full-size window movements. IOWs, whatever enables it has to interact with intution in a way that intuition did not natively support. This typically requires working on some internal structures of intuition which may fire back. In particular, the traditional window movement happens in the intuition input handler, and dependencies between this and the intuition and layers semaphores are somewhat fragile. So this is unfortunately also calling for problems.


Since decades the way this was done is to detect click into titlebar in input handler or commodity and then simply move window with a normal Intuition function like MoveWindow() (best in a helper task, not in input.device task context directly to give app tasks time to refresh their simple refresh windows in between while window is dragged). No internals of Intuition touched.
Title: Re: Layers.library V45 on the aminet
Post by: TuKo on September 19, 2017, 08:06:04 AM
Hi Thomas,

I could set up a small CompactFlash image with a bare 3.9bb2 setup and MCP 1.49 (program I use to enable Solid Windows) to try to replicate the bug.

Thanks in advance for your time spent on that bug.

Would that fit ?
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 21, 2017, 09:19:27 PM
Quote from: TuKo;830796
Would that fit ?

I wouldn't know where to fit the card in. (-:

Frankly, I'm trying a bit harder now to reproduce this on a clean system. In an attempt to make this simple, I wrote a small arexx program that moves a window over the clock:
Code: [Select]
/* move window test */
call addlib("rexxsupport.library",0,-30)
address WORKBENCH
do i=1 to 50
 do j=1 to 5
  movewindow window "SCSI:" leftedge 500-i*5+j*2 topedge 10+i-j
  call delay(1)
 end
end
which mimics a bit the erratic pattern in which a window overlays the clock. But without much success.  You may try to play with this as well, adjusing coordinate names and window names, of course.

I need something that is a little bit more reproducable than just moving the mouse by hand, and something that is a little bit more reliable than MCP.

The problem here is that one cannot reliably call MoveWindow() from within the intuition input handler (which is responsible for the dragging the window, receiving the move movements and performing the actual layer movement as well, actually). My best guess is that MCP plays with the rather delicate semaphore hierarchy of intuition to avoid a deadlock, but then fails to cover the interactions between all the semaphores correctly, leaving some structures unlocked that should rather be locked, hence causing a conflict somewhere.

If there would be some other form of moving the window *but* MCP, then I would have second look, but this particular program is so much known for its bug riddance and ignorance of system guidelines that I don't really want to make any speculations as where to look.
Title: Re: Layers.library V45 on the aminet
Post by: Georg on September 22, 2017, 08:47:15 AM
Quote from: Thomas Richter;830890

The problem here is that one cannot reliably call MoveWindow() from within the intuition input handler (which is responsible for the dragging the window, receiving the move movements and performing the actual layer movement as well, actually). My best guess is that MCP plays with the rather delicate semaphore hierarchy of intuition to avoid a deadlock, but then fails to cover the interactions between all the semaphores correctly, leaving some structures unlocked that should rather be locked, hence causing a conflict somewhere.


Intuition executes MoveWindow() asynchronously, so there are not many semaphores involved. But as said solid window moving commodities/tools (there are others like MultiCX) would typically call MoveWindow() from a helper task (or the main task), as otherwise while quickly dragging windows around there is no time for low pri app tasks to refresh simple refresh windows (until user stops dragging window for a moment) and you get a DPaint like brush-paint effect. Unless other hacks are used to for example force all windows to be smart refresh.
Title: Re: Layers.library V45 on the aminet
Post by: Georg on September 22, 2017, 08:50:53 AM
As for the ARexx script: if possible (and if you don't trust other tools) make it loop forever and move window to screen mouse coords and remove delay.
Title: Re: Layers.library V45 on the aminet
Post by: guest11527 on September 22, 2017, 10:58:27 AM
Quote from: Georg;830900
As for the ARexx script: if possible (and if you don't trust other tools) make it loop forever and move window to screen mouse coords and remove delay.
This doesn't make any difference. As you say, MoveWindow is asynchron. It essentially builds up a message, and pools it up in the input queue of the intuition input handler. The input handler runs once per VBI, thus any attempt to run the window movement more often just pools up more messages, but does not create more work.

The problem here is, however, the interaction of the calling task through messages with the input handler. Thus, if you call MoveWindow from *within* the input handler, this might have undesireable side effects.
Title: Re: Layers.library V45 on the aminet
Post by: TuKo on October 05, 2017, 04:18:59 PM
Thomas, I tried the ARexx script and unfortunately it didn't trigger the bug. It seems to me bug is triggered when switching focus from one window to another.