Dbug wrote: ↑Sun May 13, 2018 8:02 am
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
)
Dbug wrote: ↑Sun May 13, 2018 8:02 am
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.
Gotcha.
Dbug wrote: ↑Sun May 13, 2018 8:02 am
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.
ibisum wrote: ↑Sun May 13, 2018 9:43 am
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.
Dbug wrote: ↑Sun May 13, 2018 1:35 pm
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.
I agree that the Git command line is a pain especially because it has grown organically, the naming of commands and terms is confusing and not consistent across commands.
(Cf below for a UI recommendation.)
Dbug wrote: ↑Sun May 13, 2018 1:35 pm
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.
Dbug wrote: ↑Sun May 13, 2018 1:35 pm
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.