| |
Count Zero
Registered: Jan 2003
Posts: 1820 |
VICE - call for maintainers
Hey there all you (ab)users!
One of your favourite emulators next to HOXS, CCS, Frodo and alike really could use some help.
VICE has an awesome page at https://sourceforge.net/projects/vice-emu/ limited only by SF possibilities.
Many people around here use VICE and heavily avoid using the supplied bug tracker, mailing list or even the repositories. So be it.
Blacky Stardust does some awesome magic to supply Makefiles and project files for an incredible amount of platforms - and he keeps them up-to-date even when the original maintainer abandoned the project a long time ago.
He also recently announced a more rapid release cycle so we can hopefully narrow down problems in the future without asking "please try with a recent build. v2.2 is unsupported for a long time now."
However, if you are an experienced user on a deserted platform,
SUCH AS MAC OS X (!!!)
please check recent mailing list posts at https://sourceforge.net/p/vice-emu/mailman/vice-emu-mail/ and SAVE YOUR OS! :)
If you are using VICE on ANY other "rare" supported platform check the same link and offer your support for testing please!
While we provide WinVICE nightlies there are options to offer support for more platforms of course but I have chosen to not cross-build them as I feel quick testing in a VM is way too short for "maintenance". One should at least be able to test the build on two or more versions of the targetted OS is my personal opinion. Be it _only_ Win XP and Win 7 :).
So, if you feel you can support us by maintaining a port, supply regular builds for "common" platforms or just provide more bug reports to the tracker - DO SO! Don't be the lazy ass I see in the mirror every morning! |
|
... 14 posts hidden. Click here to view all posts....
|
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
Has any thought been given to separating VICE into an emulation core library and emulators shell apps? E.g. libvice with just the virtual machine and an abstract UI API, which WinVICE/MacVICE/SDLVICE/etc links to? It's frustrating to see you get held up by 15 platform ports every time a new release needs to be made, as it's always one or two ports that lost a maintainer since the last release. With semantic versioning and a good library API it should be possible for users to update to new core releases even if the native app maintainers fall behind, barring any breaking API changes.
I'm just an armchair developer here of course, and to me it seems like an easy solution, but I realize that it'd be a fair bit of work and maybe not the direction you want to go in. I don't see any way out of your situation with the current organization though.
As for MacVICE, as much as I depend on it I already maintain more open source projects than I have time for. |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
Oh, and even though I'm a GitHub fanboy myself, the project should obviously stay with svn on sf.net. Moving is a lot of work, it disrupts workflows, you risk alienating current developers, and the gain is minimal. If you want to work with git nothing's stopping you, it's easy enough to mirror svn repos and produce patches back from your git branch. |
| |
Mr. SID
Registered: Jan 2003
Posts: 421 |
Quoting MagerValpHas any thought been given to separating VICE into an emulation core library and emulators shell apps? E.g. libvice with just the virtual machine and an abstract UI API, which WinVICE/MacVICE/SDLVICE/etc links to? It's frustrating to see you get held up by 15 platform ports every time a new release needs to be made, as it's always one or two ports that lost a maintainer since the last release. With semantic versioning and a good library API it should be possible for users to update to new core releases even if the native app maintainers fall behind, barring any breaking API changes.
Since I already forked VICE (just x64) once for iOS, I know how hard it would be get that working, given the state of the codebase. I had to modify it so I can restart the emulation within my application. VICE has a lot of globals that are only implicitly initialized, so normally you have to restart the whole process to get it back into the initial state again.
It's all solvable, but retro-fitting a flexible abstracted library into the current code seems like a gigantic task that nobody wants to do. It's a lot of old C cruft. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Quoting Mr. SID VICE has a lot of globals that are only implicitly initialized, so normally you have to restart the whole process to get it back into the initial state again.
It's all solvable, but retro-fitting a flexible abstracted library into the current code seems like a gigantic task that nobody wants to do. It's a lot of old C cruft.
Ouch :(
Yes I was having similar thoughts about abstraction. I did manage to build 2.4 under OS X a few years ago and will have another attempt, but TBH I'm a developer who happens to use a Mac, rather than a Mac Developer per se. I was going to have another run at my SID envelope patch, but this is sounding more urgent at the moment. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Minor aside, I use git for my own projects and for some collaborations with another dev, but I've not used github for a very long time. Conflating the two's not as ridiculous as conflating java and javascript, but you can certainly like one and stay well away from the other. |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Have you considered creating your own mini-crossplatform framework (e.g. window, native UI elements needed by VICE) which would admittedly be a lot of upfront effort, even when extracting from the existing per-platform code, but could reduce the future maintenance work?
Or the nuclear option: integrate something like Qt :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
none of that solves the core problem: someone has to do it. yes there are some good ideas and perhaps some not so good ones. but talk is cheap :=) |
| |
Perplex
Registered: Feb 2009
Posts: 254 |
Scrap all user interfaces except SDL, then concentrate all efforts into improving that one. ;-) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
thats one of the options being discussed indeed. more likely we will use the GTK3 UI for all "major" ports instead (with SDL as provider for opengl and sound)
however, none of that will happen before the next major release, its pointless to discuss right now. |
| |
Count Zero
Registered: Jan 2003
Posts: 1820 |
Thank you, groepaz, for trying to keep people at bay while they just bash the repo choice apparently.
Would all of you bashers keep your critics on such "grown" workflows for yourself and just use what is supplied please? REALLY - having all the crap for CVS, SVN, git and more installed on $system is not the problem (my dear! Windows Icon cache does not supply enough overlay icon space! THAT may become a problem!!!).
Currently many of the involved developers WOULD like to improve actual emulation (e.g. drive emulation has a long way to go) and while discoveries on e.g. VSP crashing quickly find their way into proper emulation often enough $ports completely miss menu options to reflect such improvements.
We are still waiting for recent signups on the mailing list and someone stepping up for at least some testing - on any platform ...
However - you were given the links and the call - deletions of Win and OSX ports IS not just up for discussion but a very apparent thread to users of those platforms - no more to discuss and info passed - sign up now to the list and see/ask what you can do.
Alternatively a low traffic IRC channel #vice-dev on freenode network exists. Join for hardcore idling.
Case closed. |
| Previous - 1 | 2 | 3 - Next |
