forum.defence-force.org

Questions, bug reports, features requests, ... about the Oric Software Development Kit. Please indicate clearly in the title the related element (OSDK for generic questions, PictConv, FilePack, XA, Euphoric, etc...) to make it easy to locate messages.

The version 1.11 of the OSDK is now available, with the following changes:
- Upgraded FloppyBuilder to version 1.2 (fixed issues with gap2 and crc values)
- Upgraded Bas2Tap to version 1.0, now correctly handles corrupted programs using out of range tokens as well as saving to a file instead of stdout
- Upgraded PictConv to version 1.0 (Fixed some error handling as well as a minor issue in the Atari multipalette conversion)

(The reason for these 1.0 upgrades is that it felt silly to keep using 0.x notation for things that have been in use for longer than Google has existed)

I will be importing this version of the OSDK to GitHub this afternoon, so before I begin here are a few questions.

They are mostly about the organization that you use for the SVN repository:

Do you use branches?

If so, is the branching model by author or by feature, or something else?

Which folders should be imported from the SVN repo (http://miniserve.defence-force.org/svn/ ... osdk/main/)?
I assume it is "Osdk but under the "main" folder there seems to be a few folders for utilities such as:
"FloppyBuilder", "(Dsk|Tap)Tools", etc.
Are these also necessary (I seem to recall that the OSDK includes a few utilities itself)?

Do you already have a preferred way to bring back changes made in GitHub back to SVN or is this something that we will have to figure out when the time comes?

That is all I can think of for now but surely more will come.

Hopefully their SVN importer will behave properly, it does respect author commit attribution and history so at least every participant will still be properly credited!

[*] Which folders should be imported from the SVN repo (http://miniserve.defence-force.org/svn/ ... osdk/main/)?
I assume it is "Osdk but under the "main" folder there seems to be a few folders for utilities such as:
"FloppyBuilder", "(Dsk|Tap)Tools", etc.
Are these also necessary (I seem to recall that the OSDK includes a few utilities itself)?
[/list]

- No branches, what is committed is supposed to be in a releasable state, which means eventual experimental features have to be committed with special switches, or #ifdef'ed out.
- The main code is in http://miniserve.defence-force.org/view ... osdk/main/ with some extra libraries one level above
- The Osdk/_final_/ subfolder contains the actual built version of the OSDK, when I work on my demos and stuff, I have my OSDK environment variable pointing on this live version, so I eat my own dog food (that's how I test that I don't break stuff)
- FloppyBuilder, Bas2Tap, PictConv, etc... are part of the osdk, as well as the common folder and the documentation.

Okies, thanks!
(Of course I did not have the time to do it this afternoon so that will be tomorrow. )

I will likely put my changes in a branch on Git since that is how I am used to work with Git but when I bring them back to SVN I will take care to do that in the main branch.
But anyway I will discuss that with you before doing anything, not taking any risks.

In the meantime, more questions:

Is the peephole optimizer (popt) automatically applied to the output of the C compiler or this is a manual step?

Is this popt really useful? I briefly looked at its sources and the optimizations it seems to apply look very basic.

Are there any particular areas of the OSDK which you think would deserve a bit of love and attention but you never had the time to tackle?

Regarding the questions:
- popt65 is not in use, mostly because it has some bugs that generated invalid code in a few situations, but if it was working, that would be a nice tool to provide a second pass optimization, not only for C but also for assemblers (a bit like the "opt o+" parameter in Devpac on the Atari ST)
- Places that need tender love and care: There are some open issues there http://osdk.org/index.php?page=issues

Recently there's been some discussions with Fabrice, Jede and a few others regarding upgrading both the C compiler and XA:
- The version of LCC65 we have in the OSDK does not have the latest upgraded from Fabrice
- The version of XA we use does not have some of the 65816 bug fixes of the official XA development branch, and is also missing some things added later like the option to directly include binary files

An option could be to use the official XA, unfortunately it has came and gone twice during the time ours was maintained, and ours has some changes in various places that makes it more reliable, natively support the Oric symbols emulator format, etc... so the sane thing would be to back port the interesting changes.

In any case: I'm not against bringing in changes, but that should be done step by step, one tool at a time, with an official release of the OSDK matching that, so we can check that nothing gets broken (it's not like we have a live QA team doing regression testing and stuff like that )

No branches, what is committed is supposed to be in a releasable state, which means eventual experimental features have to be committed with special switches, or #ifdef'ed out.

.. and this statement:

In any case: I'm not against bringing in changes, but that should be done step by step, one tool at a time, with an official release of the OSDK matching that, so we can check that nothing gets broken (it's not like we have a live QA team doing regression testing and stuff like that )

.. are not congruous. The #ifdef model of configuration is a heinous code smell, and seems only necessary because the chops to be using git properly have not been properly refined...

If we could have a proper branch model, and basically get over our fears of git, then we'd have the ability to isolate development, qualification and release. The core devs could push to "-development" knowing that there isn't going to be any impact on those of use using "-release" branches, and so on - and even those of us willing to help with the QA side of things could have a branch "-qualification", which would allow us to stage and test releases properly.

At the moment I've been working through getting OSDK Building on MacOS, and its been very disappointing. I wish we were on git, so I could push my branch to others who would be interested in assisting, knowing we could eventually merge with the master release once all the glitches have been ironed out. To me, it makes no sense not to embrace git and hold on feverishly to SVN and #ifdef based development processes ..

The reason we are on SVN is because historically there's been many persons not even knowing what source control was, who never really did any programming, just wanted to get a small game done, and SVN + tortoise was an easy way to get their code present in the system very simply.

I personally dislike GIT very much, mostly because of it's complexity, ease of making mistakes, confusing choice of names for things.

I agree it is ultra powerful, but until recently there was nobody else than basically me and mmu_man doing code changes, so there was no reason for putting on myself the charge of using something I really dislike.

Recently there's been some semi usable graphical interface that hides all the horribleness of GIT so I don't hate to see it.
Something may happens at some point, but that will not be now, and heck, that may even be Mercurial, who knows what the future may hold.

Roger that, I do respect and understand that its your project, you get to choose what you want to do with it .. just that if you'd get over the Git hurdle, you'd probably get a few more contributors (myself included).

Anyway if you ever decide to learn Git, I'd be happy to help you out. I think we could definitely be productive with it, using only 3 or 4 of the basics ..

I do use git (at work) and I absolutely despise the interface (textual commands) as well as the lack of shortcuts for the most commonly used operations.

Basically it's a geek tool designed by somebody for his own purpose, it does that brilliantly, and it has become a de-facto standard not because it was adapted to what people actually needed/wanted but because it's what Linux kernel maintainer are using.

What annoys me is that now people are saying "git" to mean "distributed revision system" as they used to say "nintendo" or "atari" to mean "game console that plugs on the tv".

Questions for you:
- What is the simplest way to push a local change to master directly without going through the staging phase (or having that done automatically)?
- What would be the best GIT GUI, ideally cross platform Windows+Linux (mac as a bonus)

Regarding the questions:
- popt65 is not in use, mostly because it has some bugs that generated invalid code in a few situations, but if it was working, that would be a nice tool to provide a second pass optimization, not only for C but also for assemblers (a bit like the "opt o+" parameter in Devpac on the Atari ST)
- Places that need tender love and care: There are some open issues there http://osdk.org/index.php?page=issues

Okies, I will look into these.
My priority will be making it macOS compatible though.
(but it looks like ibisum is already on it => ARRRRGH )

Recently there's been some discussions with Fabrice, Jede and a few others regarding upgrading both the C compiler and XA:
- The version of LCC65 we have in the OSDK does not have the latest upgraded from Fabrice
- The version of XA we use does not have some of the 65816 bug fixes of the official XA development branch, and is also missing some things added later like the option to directly include binary files

An option could be to use the official XA, unfortunately it has came and gone twice during the time ours was maintained, and ours has some changes in various places that makes it more reliable, natively support the Oric symbols emulator format, etc... so the sane thing would be to back port the interesting changes.

In any case: I'm not against bringing in changes, but that should be done step by step, one tool at a time, with an official release of the OSDK matching that, so we can check that nothing gets broken (it's not like we have a live QA team doing regression testing and stuff like that )

Yup, I agree with incremental steps. This should be the norm for every update.
Massive changes are bound to introduce lots of regressions anyway.

This said, to avoid regressions, maybe we could work on a test suite for the OSDK.
Being able to automatically validate basic functionality of the OSDK before each release would definitely be useful.

This could go even up to running full demos and comparing video output in emulators to verify that they match an expected result.
Of course we would not get there overnight but we could get there step by step.

If we could have a proper branch model, and basically get over our fears of git, then we'd have the ability to isolate development, qualification and release. The core devs could push to "-development" knowing that there isn't going to be any impact on those of use using "-release" branches, and so on - and even those of us willing to help with the QA side of things could have a branch "-qualification", which would allow us to stage and test releases properly.

At the moment I've been working through getting OSDK Building on MacOS, and its been very disappointing. I wish we were on git, so I could push my branch to others who would be interested in assisting, knowing we could eventually merge with the master release once all the glitches have been ironed out. To me, it makes no sense not to embrace git and hold on feverishly to SVN and #ifdef based development processes ..

I also prefer Git to SVN and I will definitely be using branches when the OSDK in on GitHub (*) but I plan to repatriate things to SVN in one step to avoid possible conflicts (SVN branching is pretty crappy anyway).

Nothing prevents you from sharing your Git changes with others as long as there a single point to push things back to the SVN repository.

(*) unfortunately I had no time available today contrary to my plans... but I will try during the week as my evenings so far are free.

Basically it's a geek tool designed by somebody for his own purpose, it does that brilliantly, and it has become a de-facto standard not because it was adapted to what people actually needed/wanted but because it's what Linux kernel maintainer are using.

I agree and I would not say it does it brilliantly, the syntax of the command line is confusing, the commands are overcomplicated and mix concerns which are not always related and as I said the naming is not always consistent. Feature wise it is very good, but interface wise (by which I mean command line) it feels like it was designed by a rookie working alone on its pet project and who did not care about consistency because he made all the commands as he needed without a care for mass usage.

It is objectively very badly designed for human usage even though as you say, technically, it does a fantastic job. In some ways (not all) I prefer it to Perforce but no way I am using that command line (even though I LOVE command line interfaces when they are well designed).
With a proper GUI (cf below, I keep the suspense alive ), it is reasonably practical.

Questions for you:
- What is the simplest way to push a local change to master directly without going through the staging phase (or having that done automatically)?
- What would be the best GIT GUI, ideally cross platform Windows+Linux (mac as a bonus)

- Pushing without staging: you cannot.
Staging is the equivalent of your Perforce changelist, except in Git you get only one staging area (which I agree is a pain, this is an artificial unnecessary limitation). In Perforce you also need to create a changelist before submitting after all.

- SourceTree from Atlassian (https://www.sourcetreeapp.com/) is IMO the best on Windows, on Mac, I am using Git Tower which is not too bad in some respects but a bit annoying on some others, I keep using it though to see if I can get used to it (there is a Windows version if you want to try but it is not free: https://www.git-tower.com/windows/ , I use it from time to time at work to see if I prefer it to SourceTree (ST) but so far ST wins).

SourceTree is relatively bare bones but offers the most usable Git user interface I was able to find on Windows (I have tried many others, most suck kangaroos in hell but SourceTree is usable even if far from perfect). It also has the advantage of being multi-platform (Windows & macOS but not Linux).

On Linux I have no idea, but knowing Linux and its developers, I would suspect that the available GUIs murder kittens by the millions.

NekoNoNiaow has given some good advice here - only thing I would add is that the whole 'staging' philosophy, which you probably adopted from years of SVN use, is not really a thing in git... rather you'd use a local branch, something like "development-staging" (or whatever, actually doesn't need to be prefixed...) and push your changes to it. Then, say you're going to start merging from others (preparing a release for testing, for example), you'd pull the other branches you're interested in locally from whatever remotes are being used, do the merge, and then .. when you've got things 'settled' on your branch, you would push to the remote master for everyone else to catch up with.

I know this is probably futile, but here is a set of aliases I use for my personal git toolkit, maybe you'll find some of them inspiring - although, given your disgust for the command line, perhaps not (I'm a bash junkie, for me the only IDE I need is my $ prompt...)

EDIT: just wanted to add - these aliases are all I need for productive git use... there are others, better, out there - but the above set is all I've ever needed to use, along with the obvious "g merge"/"g diff"/"g fetch" and so on .. I guess the point is that the abstraction of remote and local branches has served me well over the years..

The 'interesting' alias is 'gss', which - when run - shows the current state of every branch in the repo, sorted by changes - so the most recently updated branch is at the top. I've found that giving Git newbies this command really helps them along with working out what the status of things - it *can* be confusing if you're not paying attention to hash values, for example, for each commit. But 'gss' will help you stay on top of things, I find.

I also prefer Git to SVN and I will definitely be using branches when the OSDK in on GitHub (*) but I plan to repatriate things to SVN in one step to avoid possible conflicts (SVN branching is pretty crappy anyway).
Nothing prevents you from sharing your Git changes with others as long as there a single point to push things back to the SVN repository

I feel the same way about SVN that DBug does about Git - I despise it! But thats only because I've developed years of competence with git, I suppose .. anyway, everyone has their tooling preferences.

Staging is the equivalent of your Perforce changelist, except in Git you get only one staging area (which I agree is a pain, this is an artificial unnecessary limitation).

I would state it otherwise: Perforce/SVN's staging concept is a load of bollocks. Just use a well-named branch for your staging area - thats what branches (well named) are for.

Re: building on MacOS - I'd be very happy to have a place I could push my changes, but the current SVN setup is not conducive to me doing that, alas. Its comical, because all the reasons for not using Git are the same reasons I can't get my changes pushed up to the SVN repo ..

As for the GUI discussion, I can't honestly believe I'm hearing this from a bunch of Oric heads, but I guess I shouldn't be surprised given that the most powerful tools for doing interesting Oric work are all on Windows, and require GUI sensibilities (which I admit, I do not have, as a Unix guy...). However, I have heard good things about SourceTree, and have worked with other developers who insist on using it, so .. I could recommend that as a solution to the Git usability dilemma.

Anyway .. I will try to prepare my OSDK changes for MacOS in a fashion that would make sense for sharing - but I am resisting the idea of just setting up a Git repo like normal and pushing all the changes, since this would give SVN users conniptions .. so I suppose I should work through the hassles of SVN to prepare a patch...

- Regarding Staging, I see what the point is for normal development, but GIT is restricting users that do not need the workflow. In a particular case we have files (configuration files) to share with a third party, and for their workflow it's practical to use git. So we modify the files on our machine and we need to push them to the git server so they can get them. The staging part is totally unnecessary and just adds a useless step between the modification and the commit.

- Regarding command line vs GUI: I use a revision control to feel safe, which include not breaking stuff if I'm half awoken or tired. I script source control operations that can be automated, I use a GUI for things I do manually. It's a choice I've done a long time ago which has saved me a lot of hurdle. Your solution of using aliases works nicely for you, but it makes it very impractical to move between people's machines if everybody has different aliases because the default command set was not designed to be user friendly.

- Regarding Oricians and GUIs, when I was using my Oric I was drooling of screenshots of the Mac Paint, then I had my Atari ST with a mouse, GFA Basic and Devpac which were basically mouse driven IDE. I love mouse, I love UIs, when I had to use DOS I was sad, when I met Unix I got devastated by things like case sensitive filesystem. So yeah, not everybody is the same, the less commands I type the happier I am. The myth of the "word per minutes" hacker is not something that attracts me, that's probably because I spend most of my type thinking about things than typing code or commands.

- Regarding GUI clients: I'm using SourceTree as well, I was hopping for something that would work on Linux as well. I like to use the same tools on all the OS I'm using, which is why I'm also using things like "Sublime Text" or "Beyond Compare".

- For the git users, there's already a OSDK github depot, I think it was Godzil maintaining it, you can totally synchronize all of you together

- Regarding TestSuite, there are some regression tests for PictConv, and I do run many of the samples to make sure things are not broken, and there's Coverity for the code regression, but yeah, there's no bit "all in one" system, mostly because it's my hobby, and I also like to do funny things, not only core system stuff.

I am not contributing to this debate because one main reason: I cannot manage to work with software control tools. It is sad, I know, because I am aware of all the benefits (which are many), but it's been a long time since I last work in a mid-size programming project, and back in the day we managed without those tools.

Yeah I am always confused about what I have to do: commit, update, merge, checkout, import... I always chose the wrong option, upload the wrong folder, or at the wrong place. I ended up getting more or less used to Tortoise because it is easy to use from my windows box (context menu, a repo browser where I can drag&drop, icons with overlay...) but I also used git which is integrated in Visual Studio, and I needed many arghs and urghs and @#@@##! to find out how to do the simple thing of uploading my last changes. It took time to figure out how to avoid including versioning in the obj and auxiliar files (finding a working .gitignore), remembering to enter the reason, then choosing the right action, then checking it is okay. Every time I got it wrong, a branch appeared and I had to merge them (blame me but I find the merging process awful and terrible)... And that with the GUI from Visual Studio... I cannot imagine how it would've been with the command line.

Basically I kept my Blake's 7 sources in Onedrive, so they are sync'ed between my computers. And I made backups by creating zip files. When everything was ready, I uploaded it to the repo.

So I would really like to learn how to use these tools. I googled for a tutorial, but even those are confusing! Probably it is just because I am getting old or maybe because this is a hobby and I don't have the energy or necessity to seriously learn.

Basically do what you want to do, then write a list of how the rest of us who suck at this can download/upload a project.

NekoNoNiaow has given some good advice here - only thing I would add is that the whole 'staging' philosophy, which you probably adopted from years of SVN use, is not really a thing in git... rather you'd use a local branch, something like "development-staging" (or whatever, actually doesn't need to be prefixed...) and push your changes to it.

[...]
I would state it otherwise: Perforce/SVN's staging concept is a load of bollocks. Just use a well-named branch for your staging area - thats what branches (well named) are for.

I think we are not using "staging" with the same meaning here.
The term I am referring to is the staging area which ones uses to determine which modified files on the machine are going to be used for the next commit.
Staging is necessary in Git regardless of the branching strategy used to propagate commits to the central repository.

Re: building on MacOS - I'd be very happy to have a place I could push my changes, but the current SVN setup is not conducive to me doing that, alas. Its comical, because all the reasons for not using Git are the same reasons I can't get my changes pushed up to the SVN repo ..

I fail to understand why working on Git prevents you from sharing your changes with others.
If you already have a repository, then I would advise you to just do what I wanted to do:

Create a GitHub repository (easy).

Import the OSDK SVN repository using GitHub tools (from what I read this is as simple as specifying the URL and checking a few checkboxes).

Create a "macOS" branch on that repository.

Use the GitHub repository as your remote.

Pull the macOS branch from GitHub and rebase all your changes on top of it (so that you conserve the history of all your changes).

Push that branch to GitHub.

After that, every macOS kitten can simply use that branch to benefit from your changes, while we discuss with DBug which changes to repatriate from "macOS" to the master (which maps SVN at that point) one by one. After each one, we push it back to SVN (I can do that if you want).

After some time, we will have repatriated all the macOS-specific changes to master, and concurrently to SVN and we can all start using master and branch from it for our own individual small changes.

If your commits are just too huge, then that is fine as well, we can spend a bit of time in the macOS branch to split them and bring them back in master.

As for the GUI discussion, I can't honestly believe I'm hearing this from a bunch of Oric heads, but I guess I shouldn't be surprised given that the most powerful tools for doing interesting Oric work are all on Windows, and require GUI sensibilities (which I admit, I do not have, as a Unix guy...). However, I have heard good things about SourceTree, and have worked with other developers who insist on using it, so .. I could recommend that as a solution to the Git usability dilemma.

Note that I am not technically an Oric head (more of an Amiga head ) and am also a full fledged unix kitten who loves the command line.

Anyway .. I will try to prepare my OSDK changes for MacOS in a fashion that would make sense for sharing - but I am resisting the idea of just setting up a Git repo like normal and pushing all the changes, since this would give SVN users conniptions .. so I suppose I should work through the hassles of SVN to prepare a patch...

What do you think of my above proposal? It does not really matter how work is organized on Git as long as we bring it back to SVN in an orderly fashion.

If DBug eventually decides to switch to Git, then we will still have a neat history of the OSDK on the master branch so I see no problem with having your non organized stuff in the wild either.

As long as we clearly state on GitHub that the only source of truth is the SVN repo, then all is good. After all we are not going to fork it.

Update:
I already created the GitHub repository.

It is now available at https://github.com/nekoniaow/OSDK.
I added a README.md which affirms the status of that repository and refers to the original OSDK site and SVN depot.

A handful of users from the SVN depot already had GitHub accounts so after a bit of search to make sure they were the correct persons I linked them to these accounts. I will publish a list here of people who contributed but for which I was not able to find a GitHub account in case anyone wants their account to be properly identified in GitHub history.

@ibisum : I will probably give you direct access to the repository so you can clone it and push directly to it rather than having to create pull requests which would be pretty annoying for the procedure I described above.
If you are familiar with how GitHub works in this regard, do not hesitate to suggest me how you would prefer to proceed. I will spend some time reading a bit about things works in that regard for GitHub tomorrow but for now I am heading to bed.