B-Em

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Mon Feb 13, 2017 1:38 pm

hoglet wrote: dmb@quadhog:~/atom/stardot/b-em$ git merge hoglet67/master
So the problem is that in doing a merge you're now trying to merge all the changes in from a repository (hoglet67) which has no common ancestory with stardot/b-em -- which, as you say, is because it wasn't forked from anything.

That said, this is easy to rectify in your case:

Code: Select all

# In stardot/b-em git checkout....
cd b-em
git pull
git remote add test http://github.com/fesh0r/b-em.git
git fetch test
git checkout -t test/master -b test/master
git rebase -i master
At this point, an editor (vim in my case) will allow you to pick which commit(s) you want to rebase. I delete all lines except "Several fixes, mostly based on patches from jimmy." which is the commit I want. When I save the file and exit vim, I then let git do its work.

There will be a few minor conflicts to fix up, but they're minor. When that's happened, you then just need to:

Code: Select all

git rebase --continue
And rinse and repeat for any other compilation failures which might occur (there weren't any). In doing that, I checked it compiled, and I've temporarily pushed the result out here for you to see: https://github.com/stardot/b-em/tree/test/master

The point here is that I am likely going to need to hand-hold people through this, but it's OK. Note that the rebase action implies honouring .gitattributes at this point. Win, win. :)

Kindly,
Thomas

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Mon Feb 13, 2017 1:40 pm

That said, some of those fixes in the patch I mentioned I have already done (differently, but I've also reduced the code as I've gone) -- so I am not likely to just take that patch wholesale anyway.

User avatar
BigEd
Posts: 2615
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: B-Em

Post by BigEd » Mon Feb 13, 2017 2:30 pm

Is there some git magic which could retrospectively inherit in the upstream fork?

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Mon Feb 13, 2017 2:45 pm

BigEd wrote:Is there some git magic which could retrospectively inherit in the upstream fork?
Depending on how the two code-bases have been developed, you could make use of "git grafts" (what has now been called "git replace"). I've done this a few times in projects where there's a lot of divergent histories. I suspect though it's not as relevant here, and my earlier statement about interactive rebasing is probably a lot easier.

For the curious, see: https://git.wiki.kernel.org/index.php/GraftPoint

This is something I would most definitely have to handhold people through if they wanted to go down this path.

-- Thomas Adam

User avatar
BigEd
Posts: 2615
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: B-Em

Post by BigEd » Mon Feb 13, 2017 2:47 pm

Sounds good - wouldn't the result be
- the stardot repo can be definitive as it has all the history
- no more need for that rebase dance

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Mon Feb 13, 2017 2:52 pm

BigEd wrote:Sounds good - wouldn't the result be
- the stardot repo can be definitive as it has all the history
- no more need for that rebase dance
Yes to the first.

The second point has wider implications about development practises which is a completely separate topic. I don't want people reading this to go away thinking that rebase only has this one (limited) application. It does not.

The point of rebase here is to get a given branch uptodate with known changes -- that's not the same thing as tying the two repositories together -- although once the code is in, you can just reclone the stardot/b-em repo and/or fork it on Github and then all of your worries go away. So I suppose you could treat this as a one-off in that regard.

HTH,
Thomas

dp11
Posts: 956
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

Re: B-Em

Post by dp11 » Mon Feb 13, 2017 2:59 pm

cppcheck has a few suggestions for possible bugs. Might be worth tidying some of them up.

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Mon Feb 13, 2017 4:31 pm

dp11 wrote:cppcheck has a few suggestions for possible bugs. Might be worth tidying some of them up.
There's a slew of compiler warnings I'm slowly picking over, so yes please. :)

Thomas

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Mon Feb 13, 2017 9:52 pm

So I noticed that BeebBm ships with a copy of the Acorn ROMs in its source.

I happen to work with Rebecca Gellman (whom some of you may have known as Richard Gellman) who told me that it's generally a bit of a minefield as to the copyright, but she's told me that as long as we don't charge for the ROMs, the distribution of the ROMs is considered "fine".

So would anyone object to my adding the ROMs to the git repository? Assuming I'm not about to open up a can of legal worms, that is! It would make releases a tonne easier on my part (when I change autotools to do that for us...)

Kindly,
Thomas

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Wed Feb 15, 2017 11:36 pm

Changes on the 'master' branch:
  • Some cleanups to autotools: git-version string for version (or released version otherwise), look for allegro.m4 locally, use AM_SILENT_RULES by default;
  • UNIX: Close the menu on selection (stops needing the user to close the menu after selection);
  • Distribute the ROMs/Tapes/Discs as part of the repository (as well as the release tarballs);
  • Gracefully handle missing ROMs (and other files) by providing as wrapper around fopen()
  • Add include guards around header files so as to avoid recursion.
Testing welcomed and encouraged, please.

Kindly,
Thomas

User avatar
richardtoohey
Posts: 3717
Joined: Thu Dec 29, 2011 5:13 am
Location: Tauranga, New Zealand
Contact:

Re: B-Em

Post by richardtoohey » Thu Feb 16, 2017 2:20 am

Thanks for your efforts. :D

I can give it a go on OpenBSD and Raspbian ... but are there any instructions or should I look for a README?

The Autotools are dark magic I delve into every now and then and then I wander off a sad and non-the-wiser man.

So is it ./configure, make etc. or a bit more?

User avatar
fordp
Posts: 1033
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England
Contact:

Re: B-Em

Post by fordp » Thu Feb 16, 2017 7:57 am

Have you merged the changes from others yet. I will look to get it building once there is a version with the latest changes.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Thu Feb 16, 2017 8:44 am

fordp wrote:Have you merged the changes from others yet. I will look to get it building once there is a version with the latest changes.
If you're able to identify "others", then I will do. But right now, I've not gone looking. Can you suggest which changes?

Thomas

User avatar
fordp
Posts: 1033
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England
Contact:

Re: B-Em

Post by fordp » Thu Feb 16, 2017 11:01 am

HI,

I was particulaly thinking of the changes already on Github from SteveFosdick and hoglet67.

My interest is in using B-Em to assist in projects like PiDirect, Doomsday Project, Midi, Econet and so on.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

User avatar
kieranhj
Posts: 813
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: B-Em

Post by kieranhj » Thu Feb 16, 2017 1:00 pm

Good to see the B-Em repo getting some action on Stardot! I am building on Windows so will check the latest changes all work OK when I'm back at my PC (weekend.)
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Thu Feb 16, 2017 2:11 pm

fordp wrote:HI,

I was particulaly thinking of the changes already on Github from SteveFosdick and hoglet67.

My interest is in using B-Em to assist in projects like PiDirect, Doomsday Project, Midi, Econet and so on.
I will take a look at those repositories this evening and look at what work is on them, and then chat to both SteveFosdick and Dave to see what work they want ported across.

Kindly,
Thomas

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Thu Feb 16, 2017 2:14 pm

richardtoohey wrote:Thanks for your efforts. :D

I can give it a go on OpenBSD and Raspbian ... but are there any instructions or should I look for a README?

The Autotools are dark magic I delve into every now and then and then I wander off a sad and non-the-wiser man.

So is it ./configure, make etc. or a bit more?
So the README.md file covers compilation. For Unix/Linux, it is now a case of:

Code: Select all

./autogen.sh && ./configure && make
If you've previously copied

Code: Select all

allegro.m4
to somewhere like

Code: Select all

/usr/local/share/aclocal
-- I'd like you to remove it from there; I'm keen to check that my autotools foo is good enough for aclocal to check the local copy of allegro.m4 in the repository and not in its default search path. It works fine for me, but please do double-check.

Kindly,
Thomas

User avatar
fordp
Posts: 1033
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England
Contact:

Re: B-Em

Post by fordp » Fri Feb 17, 2017 9:41 pm

I got the b_em building on Ubuntu Linux.

I hope this line adds the dependencies:

Code: Select all

sudo apt-get install build-essential checkinstall liballegro4.2-dev libalut-dev libz-dev autotools-dev automake
I am trying to add instructions to the wiki but I am not good at the mark-up on it can somebody help out?
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Fri Feb 17, 2017 9:43 pm

fordp wrote:I got the b_em building on Ubuntu Linux.

I hope this line adds the dependencies:

Code: Select all

sudo apt-get install build-essential checkinstall liballegro4.2-dev libalut-dev libz-dev autotools-dev automake
I am trying to add instructions to the wiki but I am not good at the mark-up on it can somebody help out?
Sure. I'll do that now.

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Fri Feb 17, 2017 9:52 pm

ThomasAdam wrote:
fordp wrote:I got the b_em building on Ubuntu Linux.

I hope this line adds the dependencies:

Code: Select all

sudo apt-get install build-essential checkinstall liballegro4.2-dev libalut-dev libz-dev autotools-dev automake
I am trying to add instructions to the wiki but I am not good at the mark-up on it can somebody help out?
Sure. I'll do that now.
Done.

chrisn
Posts: 486
Joined: Sat Apr 19, 2014 11:31 am
Location: UK
Contact:

Re: B-Em

Post by chrisn » Tue Feb 21, 2017 7:06 am

It's great to see the renewed activity around the emulators, and I have some changes I'd like to contribute myself.

To solve the problem of integrating changes from the various existing forks, should we consider re-starting the stardot repo as a fork of https://github.com/fesh0r/b-em? It would be really nice if the stardot repo included the complete release history.

This would be a pain to do, but maybe better to do it now while the number of changes is fairly small.

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Tue Feb 21, 2017 7:53 am

chrisn wrote:It's great to see the renewed activity around the emulators, and I have some changes I'd like to contribute myself.

To solve the problem of integrating changes from the various existing forks, should we consider re-starting the stardot repo as a fork of https://github.com/fesh0r/b-em? It would be really nice if the stardot repo included the complete release history.

This would be a pain to do, but maybe better to do it now while the number of changes is fairly small.
That's not going to help since the problem is there's no common ancestor for any of the changes we're looking at as everyone has their own repository.

As for restarting things -- no thanks, I think we're beyond that, and I've spoken to various people about getting changes included in stardot/b-em, which people are happy to do as *their* changes are the ones which are thankfully small.

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Tue Feb 21, 2017 7:54 am

chrisn wrote:It's great to see the renewed activity around the emulators, and I have some changes I'd like to contribute myself.
Excellent -- which changes? :)

User avatar
fordp
Posts: 1033
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England
Contact:

Re: B-Em

Post by fordp » Tue Feb 21, 2017 8:09 am

ThomasAdam wrote:
chrisn wrote:It's great to see the renewed activity around the emulators, and I have some changes I'd like to contribute myself.

To solve the problem of integrating changes from the various existing forks, should we consider re-starting the stardot repo as a fork of https://github.com/fesh0r/b-em? It would be really nice if the stardot repo included the complete release history.

This would be a pain to do, but maybe better to do it now while the number of changes is fairly small.
That's not going to help since the problem is there's no common ancestor for any of the changes we're looking at as everyone has their own repository.

As for restarting things -- no thanks, I think we're beyond that, and I've spoken to various people about getting changes included in stardot/b-em, which people are happy to do as *their* changes are the ones which are thankfully small.
The common ancestor to all the the other repo's on git hub is https://github.com/fesh0r/b-em. The startdot repo was incorrectly made afresh, which has nothing but downsides. You are now asking people to submit push requests against the incorrectly made repo when the right thing to do is to delete it a recreate it the way it should have been done in the first place.

I am waiting for the working 32016 Copro code to be fed in to the Stardot repo so I can start to make improvements. I would prefer it if somebody put Windows build instructions up on the Wiki. I had ago at the Linux ones myself but my main dev machine is a windows 10 one.

I look forward to B-Em becoming a genuine community project.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Tue Feb 21, 2017 8:40 am

fordp wrote:I am waiting for the working 32016 Copro code to be fed in to the Stardot repo so I can start to make improvements. I would prefer it if somebody put Windows build instructions up on the Wiki. I had ago at the Linux ones myself but my main dev machine is a windows 10 one.

I look forward to B-Em becoming a genuine community project.
The 32016 changes ought to be coming soon. When I receive them, I'll merge them.

As for Windows build instructions, if your main machine is a Windows one, are you not able to submit such instructions? Certainly it's been discussed before on these forums. Alas, I can't help you on Windows.

User avatar
fordp
Posts: 1033
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England
Contact:

Re: B-Em

Post by fordp » Tue Feb 21, 2017 9:04 am

Getting B-Em building and working on Windows has been an issue and the last time I tried I did not manage to get it working.

I would prefer to work to the instructions of those that have got it building and working in Windows 10. My own preference is to have it building on the latest community edition of Visual Studio as I use that professionally and can therefore leverage over 15 years of experience in driving Visual Studio.

If nobody posts instructions I may well have a go at making it work and posting instructions myself. I got it building on Linux as I would want to test it at least on 'Nix and Windows if I were to add features.
Last edited by fordp on Tue Feb 21, 2017 9:08 am, edited 1 time in total.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

User avatar
hoglet
Posts: 8535
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: B-Em

Post by hoglet » Tue Feb 21, 2017 9:05 am

ThomasAdam wrote: That's not going to help since the problem is there's no common ancestor for any of the changes we're looking at as everyone has their own repository.
Actually, I think almost everyone has forked from https://github.com/fesh0r/b-em, including Steve, Kieran and myself. It would make merging the work on these forks much more straightforward.

Dave

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em

Post by ThomasAdam » Tue Feb 21, 2017 9:10 am

hoglet wrote:
ThomasAdam wrote: That's not going to help since the problem is there's no common ancestor for any of the changes we're looking at as everyone has their own repository.
Actually, I think almost everyone has forked from https://github.com/fesh0r/b-em, including Steve, Kieran and myself. It would make merging the work on these forks much more straightforward.

Dave
I can sort all this out -- but what I don't want to have, is a situation where that ends up being inconvenient for others. If you're telling me that this fork is the one most people want as stardot/b-em, then I can certainly use it, but I've not heard that thus far.

So what's it to be?

Thomas

User avatar
fordp
Posts: 1033
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England
Contact:

Re: B-Em

Post by fordp » Tue Feb 21, 2017 9:13 am

FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

User avatar
BigEd
Posts: 2615
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: B-Em

Post by BigEd » Tue Feb 21, 2017 9:15 am

Sounds right to me.

Post Reply