Again, an awesome month for us all and a great post rounding up all the updates. Thank you.

@MigthyMax
Quote:
I am not sure if things like that should end up in the SDK. What I would like to see is a tool that could be used to discover, download and install those libraries as soon as they are available. Maybe even update them if they are already installed.

In my opinion, the SDK is not the best place to have libraries, because of the frequency of the installation.

Quote:
The way the libraries should be created is documented in the introduction PDF that is included in the SDK. There you can find info on how to create static and dynamic libraries, as well as the release folder structure that should be followed. And those parts are there for years.

I believe that if we want to make a development environment as easy as possible for everyone it has to have standardisation in the libraries port, and by that I mean:
1. Follow all the rules that are documented in the SDK PDF and at the wiki
2. Provide the library for both newlib and clib2
3. Create it with all the necessary flags, like the -fPIC
4. Provide the source in a place where everyone is going to be able to have access to
5. Make sure that your port will pass all the tests that are possible.

Currently, we don't have that standardisation and everyone can distribute a library, even if it doesn't work properly. And the worst of all, some people do not even provide the changes that they did, although in some situations this is mandatory based on the library license.

@flash
The OS4-specific options I believe are included in the SDK. If they are not easy to find, then this can be fixed in future releases, but they are there.

These days everyone is able to access the wiki and that should be the place where the latest and most updated documentation should be. The SDK has a snapshot of the documentation for the tools and an introduction to the SDK.

I don't know if you have seen it, but in the latest SDK, I added as much documentation as possible for most of the tools that are included. The wiki though is a continuous WIP which is able to get better and better with our contribution.

Now, maybe the perfect thing would be for someone to take parts of the wiki, write his own parts, and create a PDF file that has all the needed information, as you mentioned. This in my opinion would be great but it is also a huge project. It requires a deep knowledge of the operating system and how things are working under the hood. There are not so many people who could do such a thing and I haven't seen anyone interested in doing something like that.

I personally feel grateful that the wiki exists and that some people update it. And best of all, if something is missing we can add it.

I don't know if you guys have seen the video from the Devcon days at amiwest this year. We had a discussion about the new SDK and the documentation. At that discussion, I proposed that we can arrange a weekend to gather online together and work on updating parts of the documentation. We need to prepare of course and have coordination, but this is doable. Other communities do similar things and a lot of work is finished these days.

We can do something like that because, at the end of the day, the tools and the documentation we have is a matter of the community to make it better.

Quote:
I'd love that too but this means that a person would have to work on the SDK and the tools that need to be fixed and update all the time, like gcc, make, cmake, coreutils, libc etc. If there is someone to volunteer to do it that would be great.

Quote:
I actually have one for personal use. The thing is that if something is going to be released by someone has to have some minimum standards, i.e. that the libs are created for both clib2 and newlib, they pass all the tests that are possible to pass etc. To do that you have either to do it yourself for all these libraries, or the people who port them have to follow those standards. Again a big task to do, but if anyone would like to step up for it would be awesome.

@kas1e
I agree with you and I apologise. The second and third paragraphs were not specifically for you but for everyone. I forgot to add "@all" before it, which I did now.

Quote:
In the best of situations, we might have a new SDK once per year. So, I wouldn't rely on the SDK PDF to find crucial information. In my opinion is more necessary for us to have the info at wiki.amigaos.net, because it can be updated by multiple people at any time.

@kas1e
There is no plan for a quick bug fix right now. Please correct me if I am wrong, but I haven't seen yet a major bug in the latest SDK that needs a fast fix.

@all
Everything we discussed so far are there for years. If something needs to change, like the -athread to be set as default, then I would suggest a pull request to adtools repo and if the maintainer accepts it, then it will be in the next SDK release. If you don't know how to do it, then open an issue at the repo asking for it. Maybe someone else would like to work on it.

If someone needs changes in documentation, provide it and I can upload it to the wiki (if you don't have access there). If needed to include it in the next SDK I can do it.

@msteed
Thank you for mentioning this. Below is that part that has to do with -athread

Quote:

@flush
You will understand if this is needed by your app when you try to link the binaries and it complains like



Quote:
The same share/info folder exists in every SDK that has the above information, like msteed mentioned above.

Now, does that need a dedicated section in the introductory PDF file? Maybe yes. Maybe all the information should be in the wiki and some of that in this pdf file, but please let me know your opinion.

@nbache
Oh, then yeah, it crashes on mine as well.

@ChrisH
The only reason the GCC6 is included in the latest SDK is that it is the last one that supports SPE CPUs and is able to optimise code for it. By including it we set a base for anyone to have a compiler for this purpose. This was not available before in any package with an easy way to install it in any system.

About the -athread as much as I know it is like that for a lot of years and I thought that was some kind of standard. On the other hand, if I recall correctly, there was a discussion somewhere that this should be added at the default compilation flags, but some people objected because that would add an overhead even on applications that do not use it.

Now, you mentioned that it is not documented anywhere, and you are right about it. It only remains for this to be fixed. The best place would be wiki.amigaos.net. If you have access there you can add some information. If not, we can all create a page somewhere in an online shared doc and then I can upload it. Just let me know.

@Raziel
I wish I could make all of these work, but it is not possible. I will have a deeper look at that, but it seems that this list is loaded with JS.

For you to be sure, disable the JS on your browser and load that page. You will that it fails on every browser. So, if it fails on Odyssey with the JS enabled then it means that unfortunately it is not supported by our current browser.

I am not 100% sure but the version command doesn't work with .so files, since they do not have version tags. Of course, it shouldn't crash like that, but I don't know what you expect to get from it.

I wanted to let you know that I updated my github.js script.

Now, with this version, you will find a url under the assets of a release where nothing was visible. If you are in a page where multiple releases are shown, only the first has that url, but you can still click on the title of an older release and in the new page you will see the assets link.

Now you can download releases from github again using Odyssey.

You can find it at https://git.walkero.gr/walkero/odyssey-scripts as always.

Awesome. Glad they are working for you.

The ultimate solution will be a new browser though, but we are working on it. :D

When I released MediaVault I got some feedback that the app doesn't work on some people's systems, which proved that they didn't use the latest version of AmigaOS 4.1 FE for their own reasons.

Those discussions, although they can be bypassed with a simple reply "Sorry, it supports only the latest version...", still trouble me.

Most of the developers would like to use the latest implementations, with the latest versions of available tools, with the latest updates. And that is happening for many reasons, like it is really exciting to use new stuff.

There are a few questions in my mind that I'd like to discuss with you.

How many are using older versions of AmigaOS 4 on their main computer?

Should the developers have backward compatibility for those versions, so as to not exclude these people, even if that increases the complexity of the application? Does it justify the effort?

Should the developers use only the latest features so to push more people to update their computers?

What's your opinion?

@Raziel
I prepared something. Please have a look at
https://git.walkero.gr/walkero/odyssey ... c/branch/master/itchio.js

I don't think you can do it on Screens Prefs, but that would be a nice addition to have.

I am pretty sure you can do it to MUI Screens though from its screen manager.

@Raziel
I will check it as soon as possible.

Probably, the reason amigaworld.net has all these problems is that they have much more traffic, with people with generic interests in the Amiga ecosystem. We do not have that, as we are more focused on the AmigaOS 4.

A not-so-accurate comparison, but gives an idea:
https://www.similarweb.com/website/ami ... s/amigaworld.net/#traffic

You can check that theory by comparing the post hours and the hours New Zealand sleeps :D

But in any way, our concern should be how to keep this forum as great as possible. Please use the feedback forum to send ideas and problems and we will try to implement them. And also, think about how we could share more of what we do here with others.

@Raziel
Quote:
Please have a look at my aiostreams code, because I am using something like that and maybe it is useful for you too.

https://github.com/walkero-gr/aiostreams/blob/master/argparse.py

I guess you cloned first your code from the repo, right? Something like
sgit clone https://github.com/reponame.git reponame

If you have done that and then made changes to your code you need to stage the changes. You can see what files were changed by

sgit status

To stage all of them you have to do

sgit add .

If you want to stage one file, i.e.

sgit add src/filename.c

Then you have to create a commit for the staged files with a description, like

sgit commit -m "These are my changes"

Then you can push that commit to your repo like

sgit push origin branchname

That's all you should do for pushing changes. Have in mind that you might get connection issues with GitHub if your try to use your login credentials. The only way to make it work is with a self-access token.