@ferrels

Quote:

ferrels wrote: @Hans Well, I do know that when the only people programming for a platform are weekend amateurs, then all you can expect, at best, are amateur quality apps. You get what you pay for. And existing developers like you get paid for their work, amateur hobbyists don't, so you only serve to prove my point.

I was thinking more about professional developers working on side projects. The RadeonHD driver started as a side-project while at university, and continued as one while I did my "serious coding" on Windows. Likewise, Entwicker-X pay the bills by developing games for multiple platforms, one of which is AmigaOS. We're not the only ones...

Hans

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

@Hans

My side projects rely on tech that is like 20 years ahead of what OS4 can offer, there aren't many "fields of programming" where what you do at work can be relevant for anything Amiga.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@bison

Quote:

And I find that tools such as Valgrind, LSan, MSan, etc. mitigate the safety problems.

Valgrind has been a godsend, but even it didn't find that one bug I mentioned where the programmer forgot to use a return statement. I really lucked out when I discovered that bug.

_________________
I've decided to follow an awful lot of people I respect and leave AmigaWorld. If for some reason you want to talk to me, it shouldn't take much effort to find me.

@Hans

> What's in the way of you writing/porting software?

It was A-eon's lack of interest in their own hardware, when it came to users, but not anymore.

_________________
Tinkering with computers.

@Hans

Another thing which I forgot to mention before, which is kindof related to time, but still somewhat different.

There could be more times to have opportunity to hack around in some code, except that I am not in a place that I can have an Amiga.

That is sortof answered by WinUAE, and might become better answered by Qemu sam460 mode, and perhaps best answered by your laptop shell project or the OpenPPC Notebook project.

If I could have my Amiga with me more, rather than being chained to a particular desk by a tower setup, then time might be somewhat less of an obstacle.

I look forward to seeing how your laptop project turns out!

_________________
All glory to the Hypnotoad!

@simplex

Nim, to the extent I have just read about it, interests me as Rust does. They both sound usable for embedded programming. I assume that being able to do embedded programming means we can also make driver level code with it, point to and control hardware registers etc.

But, you also mention wrapping lots of C (or C++) libraries for use in Nim. So while an application may become somewhat safer, there will still be some security weaknesses in those underlying C libraries. And with our favorite OS being designed sortof the opposite as for security (ie. replace whatever function calls with whatever we want to patch in), and being single-user (no multiuser, no admin vs typical user vs guest user types etc) there is a serious paradigm change that needs to happen for AmigaOS to actually become security minded. I'm kindof surprised that MUFS, or somethng like it, hasn't become somewhat more mainstream in AmigaLand by now.

_________________
All glory to the Hypnotoad!

@billt

Quote:

I'm kindof surprised that MUFS, or somethng like it, hasn't become somewhat more mainstream in AmigaLand by now.

Why? All people who ever were involved with such features knew the limitations of AmigaOS, were rather loud about it and left for Linux and BSD.

Last edited by kolla on 30-Jun-2018 at 12:30 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@jPV

I agree to everything you said. Just spent the last two-three hours on Hollywood coding and made way more progress within that time than I would have done if I was trying the same on C++.
For occasional coders Hollywood is just great. I think most of us have some serious lack of time, but it was easy to just pick up my last project (a contact manager) tonight where I had stopped last time (was in April). Sure, development pace is slow when coding only very occasional, but still progress can get achieved.

_________________
My programs: via.bckrs.de
MorphOS user since V0.4 (2001)

@billt

Quote:

But, you also mention wrapping lots of C (or C++) libraries for use in Nim. So while an application may become somewhat safer, there will still be some security weaknesses in those underlying C libraries.

Correct. The point is that you can get work done in a language that makes it easier to write safe new code and still interact with what's written in C (hopefully refined by years or decades of use).

I don't know if you're familiar with Kotlin, but it has a similar relationship with Java. Last year, I wrote an Android app in Kotlin just to see how things would work. One thing I remember that was really hard to observe is that you can never use an uninitialized objects unless you tag it as @Nullable. The compiler checks this carefully, and it was a pain to write code where each object really was initialized: when JetBrains converted the Android & Java libraries, they added almost no @Nullable tags, so you really can't send garbage to the system. But by the time I was done, the problems I had were really with my algorithms and design, rather than stupid oversights caused by leaving off, for example, an ampersand, and missing the compiler's warning (which wouldn't have appeared back in the 90s because, hey, C compilers were perfectly OK with that back then).

All this pain may sound bad, but these newer languages allow for type inference (which C++11 also does), functional programming constructs, generics (very, very well thought-out in Kotlin's case), and with Nim you even get concepts, which the C++ committee still hasn't worked into their language.

For those unfamiliar with it, here's an example of how type inference is useful. First, you don't have to remember the return value of a function, you just use a keyword telling the compiler that it should figure out a variable's type depending on the type of the function whose value is being assigned to it. Already you're saving yourself a bunch of time from looking up functions, which even with hyperlinked doc pages can take a while when you're dealing with layers and layers of libraries and polymorphic functions that sometimes have as many as ten different forms (and potential return values) depending on the parameters you send.

Now, in languages like Python, the weak typing means the compiler/interpreter has no idea what the return type was. So if you then try to do something naughty with the returned value, you get a BOOM. In languages like Nim and Kotlin and C++11, the compiler has figured out the return type, so it warns you at compile time.

Likewise my bugaboo with not returning a value from a function that declares a return type: Nim and Kotlin catch that sort of stuff. C++11? eh, that's a feature, not a bug (but at least we'll warn you about it, if you catch the warning).

Quote:

And with our favorite OS being designed sortof the opposite as for security (ie. replace whatever function calls with whatever we want to patch in), and being single-user (no multiuser, no admin vs typical user vs guest user types etc) there is a serious paradigm change that needs to happen for AmigaOS to actually become security minded.

This is a different notion of security, one where they made a deliberate choice to trade off a lot of security for what was, at the time, a lot of efficiency, as well as a deadline to market. No useful language will protect you against design decisions. Sun tried with Java's JVM, and even there they failed badly enough that I read recommendations against Java for security reasons (though it seems these same people had no trouble with Windows 15-20 years ago, so I take that with a grain of salt).

Last edited by simplex on 30-Jun-2018 at 07:55 AM.

_________________
I've decided to follow an awful lot of people I respect and leave AmigaWorld. If for some reason you want to talk to me, it shouldn't take much effort to find me.

@Hans

"Entwicker-X pay the bills by developing games for multiple platforms, one of which is AmigaOS. We're not the only ones..."

It is easier with games because cross platform libraries exist, it is not the same for applications or you've to target QT.

@Hans

"Entwicker-X pay the bills by developing games for multiple platforms, one of which is AmigaOS. We're not the only ones..."

It is easier with games because cross platform libraries exist, it is not the same for applications or you've to target QT.

@Hans

Try to compile Firefox or OWB on AmigaOS4 and you have your answers.

The configure scripts crash, the autogen, auto this and that magic configure tools suck.

http://www.amigans.net/modules/xforum/viewtopic.php?topic_id=7623&start=140

We have now 143 comments about setting up cross compiler that should tell you that it not easy. How about distributing a small Virtual Box image with everything configures and setup.

Last edited by NutsAboutAmiga on 30-Jun-2018 at 11:03 AM.
Last edited by NutsAboutAmiga on 30-Jun-2018 at 11:02 AM.
Last edited by NutsAboutAmiga on 30-Jun-2018 at 11:00 AM.
Last edited by NutsAboutAmiga on 30-Jun-2018 at 10:59 AM.

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

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Hans Try to compile Firefox or OWB and on AmigaOS4 and you have your answers. The configure scripts crash, the autogen, auto this and that magic configure tools suck.

Yes I know. I avoid any projects with autogen/automake/CMake because I know they don't build on AmigaOS (and configuring them for cross-compiling is something I've never figured out). My own projects generally build with a simple make... after you've installed any dependencies.

I did suggest that someone writes a script and/or docs on how to build Odyssey (which definitely needs a cross-compiler), but that idea got shot down. That's a pity, because I'm sure there are devs who might look at fixing bits of it, if they didn't have to figure out how to build the darn thing first.

Quote:

We have now 143 comments about setting up cross compiler that should tell you that it not easy. How about distributing a small Virtual Box image with everything configures and setup.

I followed those instructions, and got a working cross-compiler, so it's not that complicated. However, an virtual box image with a working cross-compiler would be great.

Hans

Last edited by Hans on 30-Jun-2018 at 11:07 AM.

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

@Hans

Quote:

I avoid any projects with autogen/automake/CMake because I know they don't build on AmigaOS (and configuring them for cross-compiling is something I've never figured out).

Well, there's your answer. Loads and loads of free, high-quality software exists that runs with the autotools suite. Others work with CMake. Just getting those going would make a huge difference.

Amiga had something like that once in Geek Gadgets. I don't know enough about that to understand what became of it, though I know it made it much easier to port just about anything that didn't use fork().

_________________
I've decided to follow an awful lot of people I respect and leave AmigaWorld. If for some reason you want to talk to me, it shouldn't take much effort to find me.

One of my struggles have always been that "modern" software use getaddrinfo() and (other IPv6 capable) friends instead of gethostbyname() and (other legacy IPv4-only) friends, and Amiga typically have not had support for getaddrinfo. I believe Roadshow fixes this, but I haven't really tried building any software for Roadshow yet.

Last edited by kolla on 30-Jun-2018 at 03:16 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Roadshow is hostile agents pthread.

When using normal clib socket api and pthread, it wrappers onto roadshow, not know socket sharing has to be enabled.

Last edited by NutsAboutAmiga on 30-Jun-2018 at 04:09 PM.
Last edited by NutsAboutAmiga on 30-Jun-2018 at 04:08 PM.
Last edited by NutsAboutAmiga on 30-Jun-2018 at 03:59 PM.

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

@Hans

We need Good Documentation, someting the Amiga world has never had...

The RKM's were really messy and not much good for the novice, most how to
books assumed prior knowledge and there was no step by step introduction.

Need fully annotated examples explaining why things are done the way they are,
explaining al the daft casting half way through open library/ open window etc.


Need :

INCLUDE and Why ?
Open Library............why? and why test?, how to bail out. With example.
Open Window........ old way and new, how to test and bail out. With example.
Open Devices and Recourses.........how to and why and how to close With example.

How to:
Write a Library ( Working Temlate )
Write a Device ( Working Template )

How to:
Find Libraries and Devices already in memory, a good overview what the OS is doing and why?

Would be nice if it was in the style of a 'Basic Manual' eg:

INSTRUCTION, TEMPLATE, OPTIONS, EXAMPLES (All Annotated Fully)

And of course a nice IDE.

Wol.

_________________
It is my conviction that killing under the cloak of war is nothing but an act of murder.~Albert Einstein

@billt

Quote:

Nim, to the extent I have just read about it, interests me as Rust does.

My enthusiasm for Rust diminished greatly as I worked my way through the tutorial. It looks like The One Language To Rule Them All on paper, but the actual experience was far less exhilerating.

I can say the same thing about Google Go; I was highly enthusiastic about it until I completed the tutorial and thought "I hope I never have to do that again."

Of all the newer languages, I probably like Dart and Swift the best. And D, which though a complex language like C++ has some really nice ideas and features.

_________________
"Unix is supposed to fix that." -- Jay Miner

@simplex

Quote:

In the Nim community, for instance, they've repackaged more C libraries than you can shake a stick at. The result is equivalent execution time and much, much faster compilation time (because Nim uses true modules, rather than including & compiling header files every blasted time they're needed).

I've never tried Nim, having never even heard about it until today, so I'm glad you mentioned it. I see that there's a nim compiler in the Debian repository, and an official tutorial on the Nim homepage, so I have what I need.

_________________
"Unix is supposed to fix that." -- Jay Miner

@Hans

Quote:

So, if you're a developer or someone who would be interested in learning: what's in the way of you writing/porting software for AmigaOS 4.x?**

Oh I know. The way you can spend half an hour coding something. Or longer as coding can be a laborious and repetitive process. Then spend an hour fixing up the errors and warnings from the new section of code. Or longer. As happens a lot in C.

Only to find when you tested the code it wastes more of your time by crashing. Then you need to locate and fix other errors!

The whole process is a pain in the colon!!