basilisk-devel — Basilisk II development-related discussion

Re: [B2-devel] Thoughts on SheepShaver and Basilisk II

[Robert M. <mr...@gm...>]

PPC_DECODE_CACHE enables a memory block decode_cache_p which holds up
to 32768 consecutive results of decode(opcode) for a block of
consecutive PPC instructions (32-bit words).

There is a profiling function enabled by PPC_PROFILE_COMPILE_TIME
which will record the amount of CPU time used by the decode cache
function, printing "compile" vs "predecode" time vs total emulation
time.

I'm also prone to wonder why PPC_DECODE_CACHE was disabled by default
-- it seems that if Gwenole went to all that effort implementing a
decode cache (it's about 150 lines of code), why would it be disabled
by default?

On 6/16/12, Alexei Svitkine <ale...@gm...> wrote:
> For example, let's take this commit by Tycho which kallisti5 pulled:
>
https://github.com/tycho/sheepshaver/commit/ceed8dca09fd5e5fe4e1bf9127d628382cb0f350
>
> Presumably this makes something faster. Maybe it does, it looks plausible -
> [...]

-- 
  Robert Munafo  --  mrob.com
  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com

[B2-devel] Thoughts on SheepShaver and Basilisk II

[howard s. <how...@ho...>]

Hi all,

The sudden increase in activity on this ML makes for interesting 
reading. It looks like the development community is looking for an 
agenda? We, the maintainers of the http://www.emaculation.com
 website have ample experience in why and how SheepShaver is used by 
various groups of users. And have ample experience in what its 
shortcomings are. So, we would like to chime in from the user 
perspective.

First of, something about importance: In the 
discussion these past days, someone suggested that SheepShaver is not 
all that important because much old software can be run in Mini vMac. 
This is certainly not true for those who use SheepShaver on an Intel 
Mac, by far the largest group of SheepShaver users. After the demise of 
the Classic environment and later Rosetta, SheepShaver is the only way 
left to run Mac OS applications on an emulated PowerPC processor. Many 
Mac users simply need SheepShaver to keep some old applications running 
or to have access to files in formats that are not supported by today's 
Mac software. SheepShaver became a necessary tool that, as we know from 
the forum discussions and support questions, in some cases is even used 
to run irreplaceable software that is vital to professionals, 
businesses, or scientists.

Someone called SheepShaver a niche 
product. While that in itself is true, we feel that some tender love and
 care (including some expansion in the feature set) could make it a bit 
less “nichy”. Looking around the Internet, one finds many failed attempts at getting SheepShaver running, or when it does run not providing the desired functionality.
A point we would like to make is that we, as volunteer supporters/build providers, are not in favour of a diverging 
code base for the supported platforms.

Towards a better feature set for all supported hosts: 
-Improved CD/DVD handling. 
-USB support. 
-Video acceleration on the host. 
-Memory management allowing running Mac OS above 9.0.4. 
-More opcodes supported, allowing more applications to work. (Office comes to mind). 
-Improve networking, including Appletalk. 
-Improve communication to serial/parallel ports.
-A
 possibility to launch a SheepShaver built-in preferences editor without
 the emulator starting (by holding a modifier key?). That would make a 
separate external preferences editor superfluous.
-Improve SCSI support.

Specific for OSX: 
-Clipboard exchange for text in 64-bit mode SheepShaver (it currently doesn’t work at all in 64-bit mode.) 
-Possibility to compile/build SheepShaver in MacOSX 10.7.x (Lion) and future versions. 
-Solution
 to the weird color problems on Intel Mac after SheepShaver window has 
been minimized or hidden and is brought back in view. (Possibly a SDL 
issue.)

Specific for Windows: 
-Replace the reliance on the cdenable.sys cd rom driver for CD support. It currently doesn’t work on 64-bit hosts. 
-Replace
 the reliance on the BasiliskII Ethernet driver with for example 
WinPcap, as it currently doesn’t run on 64-bit hosts (requiring driver 
signing).
-Replace reliance on Cygwin to build for Windows.

Best regards,
Ronald P. Regensburg and Howard Spoelstra
 		 	   		  

Re: [B2-devel] BasiliskII compilation issues

[Giulio P. <giu...@gm...>]

Il 15/06/2012 23:57, Alexei Svitkine ha scritto:
> I've now landed a change that does that and also includes <signal.h>.
> Let me know if it works for you now or if there are still issues.

It is still not working:
sshpty.c:187:20 error: `I_PUSH' undeclared (first use in this function)

I also have two warnings about "sig" and "strlcpy" implicit declaration.
The first one is due to a wrong definition of mysignal. I do not know
why I see the strlcpy warning (In config.h HAVE_STRLCPY has been defined
to 1).

Giulio.

> On Fri, Jun 15, 2012 at 5:46 PM, Alexei Svitkine
> <ale...@gm... <mailto:ale...@gm...>> wrote:
> 
>     Does it work if you replace "mysig_t" with "sig_t" and "mysignal"
>     with "signal"?
> 
> 
>     On Fri, Jun 15, 2012 at 12:54 PM, Giulio Paci <giu...@gm...
>     <mailto:giu...@gm...>> wrote:
> 
>         On 12/06/2012 02:01, Robert Munafo wrote:
>         > Hello Giulio,
>         >
>         > On 6/11/12, Giulio Paci <giu...@gm...
>         <mailto:giu...@gm...>> wrote:
>         >> On 10/06/2012 06:59, Robert Munafo wrote:
>         >>> You might have noticed that mysignal is part of a small C
>         program used
>         >>> as a test during the autoconf process.  [...]
>         >>
>         >> Actually I did not notice it. How is it related mysignal
>         being part of a
>         >> test in configure and the error I am seeing?
>         >
>         > They both use the same name. This means that they might have
>         both been
>         > put in by the same programmer. If there is a history of old
>         versions
>         > of BasiliskII source code, then we could find out when the
>         mysignal
>         > got added to autoconf, and perhaps that will give a clue as to who
>         > added it and maybe the other mysignal was added at the same time.
> 
>         In autoconf files they were there since the first CVS commit,
>         but I do
>         not know how this can help.
> 
>         >>> What happens if you disable the "#define HAVE_DEV_PTMX 1" as
>         Andreas
>         >>> Wiese suggested?
>         >>
>         >> I am in the same situation as Andreas: if I
>         >> 1) undefine HAVE_DEV_PTMX and
>         >> 2) include signal.h
>         >> I can complete the compilation. (Although I am not able to
>         test the
>         >> resulting binary at the moment, because on the virtual
>         machine I set up
>         >> for testing, the X server is not able to start).
>         >>
>         >> My goal is to have the compilation working without manual
>         intervention
>         >> on as many Debian supported architectures as possible, so: I
>         can accept
>         >> the point 2 above (as it is working in the general case), but
>         I cannot
>         >> accept the point 1 (because I do not understand what I am
>         tweaking and
>         >> why. Moreover the change is probably affecting other
>         architectures).
>         >
>         > I suggest that you add the change in the same way that one
>         normally
>         > makes such changes in Debian.
>         >
>         > This is probably done with the config files. Note that
>         "HAVE_DEV_PTMX"
>         > appears in:
>         >
>         >   Unix/config.h.in <http://config.h.in>
>         >   Unix/configure
>         >   Unix/configure.ac <http://configure.ac>
> 
>         Yes, the two usual fixes are either 1) temporary patch the building
>         system or 2) wait for an upstream patched release.
> 
>         > I do not know how these files work, but I do remember that one
>         or more
>         > of them is created based on one of the others, and I'm pretty sure
>         > this happens in the "autogen.sh" or "configure" step of the build
>         > process.
> 
>         config.h.in <http://config.h.in> is normally generated by
>         autoheader, configure.ac <http://configure.ac> is usually
>         the manually edited main source and configure is automatically
>         generated
>         by autoconf and is responsible to convert .in files into the
>         final file
>         (e.g., to create config.h from config.h.in <http://config.h.in>).
> 
>         > Whichever one is the "original" configure file, needs to be
>         edited so
>         > that it tests for Debian and disables the define of
>         HAVE_DEV_PTMX if
>         > the Debian test is true.
> 
>         The problem is that 1) I do not understand what to check for and
>         2) I do
>         not understand the implication of undefining HAVE_DEV_PTMX.
> 
>         It is not a matter to detect Debian, as the building procedure is
>         already working on many Debian architectures. It is a matter of
>         detecting freebsd kernel in a Debian OS, but why? What features is
>         missing? As the same problem appeared long time ago in NetBSD
>         and other
>         *BSD, is it related to FreeBSD?
> 
>         > Once you determine the best way to change the right config
>         file, then
>         > report the details back to this list. There are people on this
>         list
>         > who can update the source code server to reflect the bug fix, once
>         > they are told what needs to be changed.
> 
>         Once I will determine it I will do it for sure, but I do not think I
>         have the knowledge to determine it on my own.
> 
>         Bests,
>                Giulio.
> 
>         ------------------------------------------------------------------------------
>         Live Security Virtual Conference
>         Exclusive live event will cover all the ways today's security and
>         threat landscape has changed and how IT managers can respond.
>         Discussions
>         will include endpoint security, mobile security and the latest
>         in malware
>         threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>         _______________________________________________
>         basilisk-devel mailing list
>         bas...@li...
>         <mailto:bas...@li...>
>         https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> 
> 
> 
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] BasiliskII compilation issues

[Alexei S. <ale...@gm...>]

On Sat, Jun 16, 2012 at 2:34 PM, Giulio Paci <giu...@gm...> wrote:

> Il 16/06/2012 08:36, Robert Munafo ha scritto:
> > What we need is someone who has a computer with this problem, and who
> > is also able to figure out how to get it to build (and run!), who can
> > tell us how the configure.ac needs to change so that it will work
> > properly without any manual temporary patch.
>
> Yes, unfortunately this is my first time with a Debian with freebsd
> kernel, so I am still not able to run Xorg on my virtual machine.
> If anybody is interested I can share the VM anyway: I have no private
> data there, just the Basilisk requirements.


Can you let me know whether my changes fixed the compilation error?

-Alexei

Re: [B2-devel] BasiliskII compilation issues

[Giulio P. <giu...@gm...>]

Il 16/06/2012 08:36, Robert Munafo ha scritto:
> What we need is someone who has a computer with this problem, and who
> is also able to figure out how to get it to build (and run!), who can
> tell us how the configure.ac needs to change so that it will work
> properly without any manual temporary patch.

Yes, unfortunately this is my first time with a Debian with freebsd
kernel, so I am still not able to run Xorg on my virtual machine.
If anybody is interested I can share the VM anyway: I have no private
data there, just the Basilisk requirements.

> It's too bad -- it looks like Debian will need to remove BasII.

I hope we will be able to ship also a package for Debian kfreebsd, but
there is no reason to remove Basilisk II for the Debian architectures
that are working. :-)

Re: [B2-devel] git?

[Alexander v. G. <kal...@un...>]

On 16.06.2012 12:38, Alexei Svitkine wrote:
> On Sat, Jun 16, 2012 at 5:08 AM, Christian Bauer <cb...@ce... [1]> wrote:
>
>> Hi!
>>
>> At last some action here. :-)
>>
>> I agree that for a project with so few active developers CVS should
>> still be sufficient. But if it helps people working on the code I will
>> gladly convert the CVS repository to git and put it on GitHub (and shut
>> down the CVS). However, due to time constraints I won't always be able
>> to respond to pull requests or review patches myself, so I'd place the
>> main liability for keeping the repository up-to-date on Alexei if that's 
>> OK.
>
> Sounds like there's a lot of interest in moving to GitHub, so let's do it.

Yay! Glad to hear I was the motivation for this! :D

There are some examples of git usage and a flow chart I threw together a
while back if anyone wants a *quick* crash course on GIT:

https://www.haiku-os.org/guides/building/get-source-git

Tips:
   * Always git pull --rebase before you commit.
     This will mimic a central repo better and avoid a mass amount of merges

-- Alex

Re: [B2-devel] git?

[Alexei S. <ale...@gm...>]

On Sat, Jun 16, 2012 at 5:08 AM, Christian Bauer <cb...@ce...> wrote:

> Hi!
>
> At last some action here. :-)
>
> I agree that for a project with so few active developers CVS should
> still be sufficient. But if it helps people working on the code I will
> gladly convert the CVS repository to git and put it on GitHub (and shut
> down the CVS). However, due to time constraints I won't always be able
> to respond to pull requests or review patches myself, so I'd place the
> main liability for keeping the repository up-to-date on Alexei if that's
> OK.
>

Sounds like there's a lot of interest in moving to GitHub, so let's do it.

Can you create a new GitHub repo containing both SS and BasiliskII sources
from the CVS TOT and add me as a collaborator? (https://github.com/asvitkine
)

This will then become the new "upstream" repo for SS + BasiliskII and we'll
go from there.

-Alexei

Re: [B2-devel] git?

[Alexei S. <ale...@gm...>]

On Sat, Jun 16, 2012 at 1:16 PM, Alexei Svitkine
<ale...@gm...>wrote:

> We could even have the symlinks checked in, so the separate script to
> generate them won't be required.


Looks like that wouldn't work well with Windows. Sigh:

http://stackoverflow.com/questions/5917249/git-symlinks-in-windows

-Alexei

Re: [B2-devel] git?

[Alexei S. <ale...@gm...>]

I think it makes sense to stick both codebases in the same repo as two
side-by-side subtrees. We could even have the symlinks checked in, so the
separate script to generate them won't be required.

-Alexei

On Sat, Jun 16, 2012 at 1:05 PM, Robert Munafo <mr...@gm...> wrote:

> Regarding the symlinks, I think it's important to keep as much code
> shared as possible.
>
> I don't care as much about whether that's done with symlinks, or in
> the more standard way with a single directory tree with shared files
> and two build targets. Either way I still have to read a README to
> find out how to build it, and how to get the result running, and
> that's not going to change.
>
> On the prefs editor issue, I couldn't care less. I've used both GUI
> versions (there's a Mac-specific one, that some of you may have used)
> as well as editing the textfile directly. Once again, you have to RTFM
> to know how to set your prefs, and the task of actually setting them
> is insignificant by comparison.
>
> On 6/16/12, Christian Bauer <cb...@ce...> wrote:
> > [...]
> > My main concern is what to do with the files shared between B2 and SS. I
> > guess the best starting point would be to put both projects into a
> > single repository, including the symlinks, and eventually rework the
> > directory layout later?
> >
> > As far as the crappy GTK prefs editor is concerned: If I was starting
> > from scratch I'd implement it with Qt (in C++, not with Designer) and
> > make it work on all supported host platforms. The current code was
> > originally a quick'n'dirty port of the BeOS UI...
>
> --
>  Robert Munafo  --  mrob.com
>  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
> mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

Re: [B2-devel] git?

[Robert M. <mr...@gm...>]

Regarding the symlinks, I think it's important to keep as much code
shared as possible.

I don't care as much about whether that's done with symlinks, or in
the more standard way with a single directory tree with shared files
and two build targets. Either way I still have to read a README to
find out how to build it, and how to get the result running, and
that's not going to change.

On the prefs editor issue, I couldn't care less. I've used both GUI
versions (there's a Mac-specific one, that some of you may have used)
as well as editing the textfile directly. Once again, you have to RTFM
to know how to set your prefs, and the task of actually setting them
is insignificant by comparison.

On 6/16/12, Christian Bauer <cb...@ce...> wrote:
> [...]
> My main concern is what to do with the files shared between B2 and SS. I
> guess the best starting point would be to put both projects into a
> single repository, including the symlinks, and eventually rework the
> directory layout later?
>
> As far as the crappy GTK prefs editor is concerned: If I was starting
> from scratch I'd implement it with Qt (in C++, not with Designer) and
> make it work on all supported host platforms. The current code was
> originally a quick'n'dirty port of the BeOS UI...

-- 
  Robert Munafo  --  mrob.com
  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com

[B2-devel] First milestone... SheepShear now compiles on Haiku gcc4

[Alexander v. G. <kal...@un...>]

Doesn't work yet, however:

http://imagebin.org/216651
http://imagebin.org/216652

That should take some of the older B2 + SS folks back :)


Now, I can begin doing some of the fun reorganization. (Maybe make things 
more class based vs 1000 C functions per platform :)

-- Alex

Re: [B2-devel] Thoughts on SheepShaver and Basilisk II

[Giulio P. <giu...@gm...>]

Il 16/06/2012 17:52, Alexei Svitkine ha scritto:
> 
> 
> On Sat, Jun 16, 2012 at 2:47 AM, Robert Munafo <mr...@gm...
> <mailto:mr...@gm...>> wrote:
> 
>     On Fri, Jun 15, 2012 at 12:08 PM, Alexander von Gluck wrote:
>     >> Right now i'm pouring over the other existing forks on Github of
>     >> SheepShaver and cherrypicking patches not in the
>     >> SheepShaver codebase (giving the other authors credit)
> 
>     Wow, you're not kidding -- I found four other forks of SheepShaver
>     on GitHub!
> 
>     Regardless of the rest of the questions, like how to improve the UI or
>     make development easier, we should definitely check these out --
>     there's obviously a lot of creative energy out there. Some of them
>     could probably benefit from the work we've done. I noticed one version
>     has "enable JIT on 64-bit MacOS" as their latest change, and we've
>     done other improvements since then.
> 
>     Any Mac users using any of those forks would want my CD-ROM eject fix,
>     for example.
> 
> 
> I think regardless of any new SCM we switch to, we definitely need a
> better process to getting code to upstream. In the past, I've tried to
> encourage people to send patches to this list for this, so that we could
> discuss them if necessary and I would land them. This model works very
> well for some other projects, like ffmpeg.
> 
> But it hasn't really worked too well here. Often times people don't send
> patches - either they post them to emaculation.com
> <http://emaculation.com> forums and I need to periodically monitor these
> and look for these gems - or they don't share them and just post builds
> there - or they commit them to their own git works without telling anyone.

Github "Network" facilities will greatly help you with this: people
commits in their own repositories and you can see how those changes
relate to yours.

> You may argue that the last workflow should be fine - i.e. people
> committing stuff to their own forks and upstream (me) then looking over
> what's been done and pulling stuff I'm interested in. I disagree. A lot
> of such changes don't provide enough context as to what they're fixing
> or why that change is being made. And I don't feel comfortable merging
> in stuff randomly without understanding it. There needs to be a place
> for discussion.

In github (but also in bare git) there is also the "Pull request" method
that is: if someone wants to contribute a set of commits with you, just
selects the set of commits, writes a few notes about them and send the
request to you. You can ask for further details in a forum-like
discussion and when you are convinced can accept or reject the changes.
It works quite fine.

> For example, let's take this commit by Tycho which kallisti5 pulled:
> 
> https://github.com/tycho/sheepshaver/commit/ceed8dca09fd5e5fe4e1bf9127d628382cb0f350
> 
> Presumably this makes something faster. Maybe it does, it looks
> plausible - instead of checking the cache just at the beginning, check
> it at every iteration so that presumably if the next pc is in the cache,
> we could get it from there. Maybe. I'm not sure that my description is
> correct - the code is pretty complicated there. Does it really improve
> performance? Something like this could actually degrade performance. I
> don't see any reference to benchmarks or improvements in the commit
> description. When I try running some random benchmark programs I have
> lying around, I don't see any difference. I can't justify pulling that
> into upstream unless I know what improvement that provides - otherwise
> it's just unnecessary code churn.
> 
> -Alexei
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> 
> 
> 
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] git?

[Giulio P. <giu...@gm...>]

Il 16/06/2012 17:35, Alexei Svitkine ha scritto:
> I am okay with switching to git, since it seems developers prefer it
> these days to SVN. (I've not fully embraced git myself since most stuff
> I work on is still using SVN and it suits my needs, but by all means
> let's go with git if that's what people like - and would give me an
> excuse to actually use/learn it.)
> 
> Do any other open source projects use GitHub for their master copy? Does
> it make sense to also move our docs to their wikis and use their bug
> tracker? Anyone have any experience with that?

I know of this project:
https://github.com/marytts/marytts/
that is using github as its main development platform.

If one decides to use git, using all the features of github is a very
good option in my opinion, because all the provided features integrate
very well with git.

The drawback (missing feature) of github is that the whole interface is
very developer oriented and projects are missing a real main page. it is
one of the best option for developers, but non-developers users may be
confused (e.g., where should I download the software releases? hint:
there is a link called Downloads, but it is not very visible).

If it is possible to update this page: http://sheepshaver.cebix.net/
with references to github pages, I think there is no need for other
source farms.

> Alternatively, we can go with Google Code, which also supports git and
> provides a wiki and an issue tracker (with which I'm more familiar
> with). (And since it's git, people can still use GitHub for their own
> forks and pull requests, etc.)

One of the main features of github that you are going to miss is that it
allows to "centralize" development. That is you can track the work of
your contributors with the "Network graph" (e.g.,
https://github.com/marytts/marytts/network) and your developers
community with the "Network members" (e.g.,
https://github.com/marytts/marytts/network/members). This works outside
git, spanning several git repositories that has been cloned using what
github calls a "Fork".

Bests,
	Giulio.

> On Sat, Jun 16, 2012 at 10:42 AM, Alexander von Gluck
> <kal...@un... <mailto:kal...@un...>> wrote:
> 
>     On 16.06.2012 04:08, Christian Bauer wrote:
>     > Hi!
>     >
>     > At last some action here. :-)
>     >
>     > I agree that for a project with so few active developers CVS should
>     > still be sufficient. But if it helps people working on the code I will
>     > gladly convert the CVS repository to git and put it on GitHub (and
>     shut
>     > down the CVS).
> 
>     Don't even have to use git... Subversion, Mercurial, all good choices.
>     I simply am using git because it is a little more 'unixy' then
>     Mercurial.
> 
>     > My main concern is what to do with the files shared between B2 and
>     SS. I
>     > guess the best starting point would be to put both projects into a
>     > single repository, including the symlinks, and eventually rework the
>     > directory layout later?
> 
>     I think that would be a positive thing.  While I can easily see the
>     reasoning
>     behind using the symlink scripts, given the "mature" state of each
>     codebase
>     the current commits are minimal.
> 
>     I'd vote to do as you said for sheepshaver and keep B2 as-is. Maybe
>     someday
>     SS could do what B2 does and then you could drop B2 completely :)
> 
>     > As far as the crappy GTK prefs editor is concerned: If I was starting
>     > from scratch I'd implement it with Qt (in C++, not with Designer) and
>     > make it work on all supported host platforms. The current code was
>     > originally a quick'n'dirty port of the BeOS UI...
> 
>     Haha, yeah.  It's pretty easy to tell that not a lot has changed from a
>     necessity standpoint (SS is mature, and the current pref editor "works")
> 
>     I actually have SheepShear compiling now on Haiku as of last
>     night, however linking is another story :)
> 
>      -- Alex
> 
>     ------------------------------------------------------------------------------
>     Live Security Virtual Conference
>     Exclusive live event will cover all the ways today's security and
>     threat landscape has changed and how IT managers can respond.
>     Discussions
>     will include endpoint security, mobile security and the latest in
>     malware
>     threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>     _______________________________________________
>     basilisk-devel mailing list
>     bas...@li...
>     <mailto:bas...@li...>
>     https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> 
> 
> 
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] git?

[Frank T. <fra...@gm...>]

On Sat, Jun 16, 2012 at 11:27 AM, Charles Srstka <
bas...@ch...> wrote:

> On Jun 16, 2012, at 9:42 AM, Alexander von Gluck wrote:
>
> I'd vote to do as you said for sheepshaver and keep B2 as-is. Maybe someday
> SS could do what B2 does and then you could drop B2 completely :)
>
>
> I disagree with this one. Basilisk II is quite useful for running late 68k
> Mac stuff, and it would be a shame for it not to pick up any improvements
> that get made to the shared code.
>
> And Basilisk II seems to be a bit more flexible about the memory model .


> Charles
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

Re: [B2-devel] git?

[Charles S. <bas...@ch...>]

On Jun 16, 2012, at 9:42 AM, Alexander von Gluck wrote:

> I'd vote to do as you said for sheepshaver and keep B2 as-is. Maybe someday
> SS could do what B2 does and then you could drop B2 completely :)

I disagree with this one. Basilisk II is quite useful for running late 68k Mac stuff, and it would be a shame for it not to pick up any improvements that get made to the shared code.

Charles

Re: [B2-devel] Thoughts on SheepShaver and Basilisk II

[Alexei S. <ale...@gm...>]

On Sat, Jun 16, 2012 at 2:47 AM, Robert Munafo <mr...@gm...> wrote:

> On Fri, Jun 15, 2012 at 12:08 PM, Alexander von Gluck wrote:
> >> Right now i'm pouring over the other existing forks on Github of
> >> SheepShaver and cherrypicking patches not in the
> >> SheepShaver codebase (giving the other authors credit)
>
> Wow, you're not kidding -- I found four other forks of SheepShaver on
> GitHub!
>
> Regardless of the rest of the questions, like how to improve the UI or
> make development easier, we should definitely check these out --
> there's obviously a lot of creative energy out there. Some of them
> could probably benefit from the work we've done. I noticed one version
> has "enable JIT on 64-bit MacOS" as their latest change, and we've
> done other improvements since then.
>
> Any Mac users using any of those forks would want my CD-ROM eject fix,
> for example.
>

I think regardless of any new SCM we switch to, we definitely need a better
process to getting code to upstream. In the past, I've tried to encourage
people to send patches to this list for this, so that we could discuss them
if necessary and I would land them. This model works very well for some
other projects, like ffmpeg.

But it hasn't really worked too well here. Often times people don't send
patches - either they post them to emaculation.com forums and I need to
periodically monitor these and look for these gems - or they don't share
them and just post builds there - or they commit them to their own git
works without telling anyone.

You may argue that the last workflow should be fine - i.e. people
committing stuff to their own forks and upstream (me) then looking over
what's been done and pulling stuff I'm interested in. I disagree. A lot of
such changes don't provide enough context as to what they're fixing or why
that change is being made. And I don't feel comfortable merging in stuff
randomly without understanding it. There needs to be a place for discussion.

For example, let's take this commit by Tycho which kallisti5 pulled:

https://github.com/tycho/sheepshaver/commit/ceed8dca09fd5e5fe4e1bf9127d628382cb0f350

Presumably this makes something faster. Maybe it does, it looks plausible -
instead of checking the cache just at the beginning, check it at every
iteration so that presumably if the next pc is in the cache, we could get
it from there. Maybe. I'm not sure that my description is correct - the
code is pretty complicated there. Does it really improve performance?
Something like this could actually degrade performance. I don't see any
reference to benchmarks or improvements in the commit description. When I
try running some random benchmark programs I have lying around, I don't see
any difference. I can't justify pulling that into upstream unless I know
what improvement that provides - otherwise it's just unnecessary code churn.

-Alexei

Re: [B2-devel] git?

[Alexei S. <ale...@gm...>]

I am okay with switching to git, since it seems developers prefer it these
days to SVN. (I've not fully embraced git myself since most stuff I work on
is still using SVN and it suits my needs, but by all means let's go with
git if that's what people like - and would give me an excuse to actually
use/learn it.)

Do any other open source projects use GitHub for their master copy? Does it
make sense to also move our docs to their wikis and use their bug tracker?
Anyone have any experience with that?

Alternatively, we can go with Google Code, which also supports git and
provides a wiki and an issue tracker (with which I'm more familiar with).
(And since it's git, people can still use GitHub for their own forks and
pull requests, etc.)

Any opinions?

-Alexei


On Sat, Jun 16, 2012 at 10:42 AM, Alexander von Gluck <kal...@un...
> wrote:

> On 16.06.2012 04:08, Christian Bauer wrote:
> > Hi!
> >
> > At last some action here. :-)
> >
> > I agree that for a project with so few active developers CVS should
> > still be sufficient. But if it helps people working on the code I will
> > gladly convert the CVS repository to git and put it on GitHub (and shut
> > down the CVS).
>
> Don't even have to use git... Subversion, Mercurial, all good choices.
> I simply am using git because it is a little more 'unixy' then Mercurial.
>
> > My main concern is what to do with the files shared between B2 and SS. I
> > guess the best starting point would be to put both projects into a
> > single repository, including the symlinks, and eventually rework the
> > directory layout later?
>
> I think that would be a positive thing.  While I can easily see the
> reasoning
> behind using the symlink scripts, given the "mature" state of each codebase
> the current commits are minimal.
>
> I'd vote to do as you said for sheepshaver and keep B2 as-is. Maybe someday
> SS could do what B2 does and then you could drop B2 completely :)
>
> > As far as the crappy GTK prefs editor is concerned: If I was starting
> > from scratch I'd implement it with Qt (in C++, not with Designer) and
> > make it work on all supported host platforms. The current code was
> > originally a quick'n'dirty port of the BeOS UI...
>
> Haha, yeah.  It's pretty easy to tell that not a lot has changed from a
> necessity standpoint (SS is mature, and the current pref editor "works")
>
> I actually have SheepShear compiling now on Haiku as of last
> night, however linking is another story :)
>
>  -- Alex
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

Re: [B2-devel] git?

[Alexander v. G. <kal...@un...>]

On 16.06.2012 04:08, Christian Bauer wrote:
> Hi!
>
> At last some action here. :-)
>
> I agree that for a project with so few active developers CVS should
> still be sufficient. But if it helps people working on the code I will
> gladly convert the CVS repository to git and put it on GitHub (and shut
> down the CVS).

Don't even have to use git... Subversion, Mercurial, all good choices.
I simply am using git because it is a little more 'unixy' then Mercurial.

> My main concern is what to do with the files shared between B2 and SS. I
> guess the best starting point would be to put both projects into a
> single repository, including the symlinks, and eventually rework the
> directory layout later?

I think that would be a positive thing.  While I can easily see the 
reasoning
behind using the symlink scripts, given the "mature" state of each codebase
the current commits are minimal.

I'd vote to do as you said for sheepshaver and keep B2 as-is. Maybe someday
SS could do what B2 does and then you could drop B2 completely :)

> As far as the crappy GTK prefs editor is concerned: If I was starting
> from scratch I'd implement it with Qt (in C++, not with Designer) and
> make it work on all supported host platforms. The current code was
> originally a quick'n'dirty port of the BeOS UI...

Haha, yeah.  It's pretty easy to tell that not a lot has changed from a
necessity standpoint (SS is mature, and the current pref editor "works")

I actually have SheepShear compiling now on Haiku as of last
night, however linking is another story :)

  -- Alex

[B2-devel] git?

[Christian B. <cb...@ce...>]

Hi!

At last some action here. :-)

I agree that for a project with so few active developers CVS should 
still be sufficient. But if it helps people working on the code I will 
gladly convert the CVS repository to git and put it on GitHub (and shut 
down the CVS). However, due to time constraints I won't always be able 
to respond to pull requests or review patches myself, so I'd place the 
main liability for keeping the repository up-to-date on Alexei if that's OK.

My main concern is what to do with the files shared between B2 and SS. I 
guess the best starting point would be to put both projects into a 
single repository, including the symlinks, and eventually rework the 
directory layout later?

As far as the crappy GTK prefs editor is concerned: If I was starting 
from scratch I'd implement it with Qt (in C++, not with Designer) and 
make it work on all supported host platforms. The current code was 
originally a quick'n'dirty port of the BeOS UI...

Bye,
Christian

-- 
   / Physics is an algorithm
\/ www.cebix.net

Re: [B2-devel] Thoughts on SheepShaver and Basilisk II

[Robert M. <mr...@gm...>]

Oh yeah, the "mature" thing.

B2 and SS are "mature" in the sense that the features are complete:
you can run pretty nearly any MacOS software in the emulator. Back in
the 1980's, when these terms were being invented, that's about all
that "mature" ever really meant in a software project.

People also think "mature" should mean "finished", "up to date", or
even "stable", but it doesn't. Those are different words and you
should use them, along with qualifiers like "not" where appropriate.

It's okay that people don't agree on this. See the following
discussion, and you'll notice someone thinks "mature" means "not
bloated", while someone else says it means "does everything":

http://www.linkedin.com/answers/technology/software-development/TCH_SFT/823923-39777067

They can't all be right (-:

>> And SS is everything but mature. There is so much stuff that need fixed.
>> It crashed a lot, it needs updates to be more user friendly, more
>> compatible, more everything.
>
> These problems tend to result from large structural problems or design
> decisions (the memory management system and the choice to intercept
> specific Mac O.S. functionality rather than emulating the hardware) rather
> than from small bugs. The problems have never been sufficient, at least for
> me, to justify rewriting everything as would be necessary to correct those
> problems.
> [...]

-- 
  Robert Munafo  --  mrob.com
  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com

Re: [B2-devel] Thoughts on SheepShaver and Basilisk II

[Robert M. <mr...@gm...>]

On Fri, Jun 15, 2012 at 12:08 PM, Alexander von Gluck wrote:
>> Right now i'm pouring over the other existing forks on Github of
>> SheepShaver and cherrypicking patches not in the
>> SheepShaver codebase (giving the other authors credit)

Wow, you're not kidding -- I found four other forks of SheepShaver on GitHub!

Regardless of the rest of the questions, like how to improve the UI or
make development easier, we should definitely check these out --
there's obviously a lot of creative energy out there. Some of them
could probably benefit from the work we've done. I noticed one version
has "enable JIT on 64-bit MacOS" as their latest change, and we've
done other improvements since then.

Any Mac users using any of those forks would want my CD-ROM eject fix,
for example.

-- 
  Robert Munafo  --  mrob.com
  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com

Re: [B2-devel] BasiliskII compilation issues

[Robert M. <mr...@gm...>]

Dear Giulio,

Thanks for writing back, and thanks for the detailed responses. It's
good to have answers to at least some of the stuff that I did not
understand!

But I guess we're still stuck on the main problem. I was hoping you
might be able to figure out how to fix it.

What we need is someone who has a computer with this problem, and who
is also able to figure out how to get it to build (and run!), who can
tell us how the configure.ac needs to change so that it will work
properly without any manual temporary patch.

It's too bad -- it looks like Debian will need to remove BasII.

- Robert

On 6/15/12, Giulio Paci <giu...@gm...> wrote:
> Yes, the two usual fixes are either 1) temporary patch the building
> system or 2) wait for an upstream patched release.
> [...]
> config.h.in is normally generated by autoheader, configure.ac is usually
> the manually edited main source and configure is automatically generated
> by autoconf and is responsible to convert .in files into the final file
> (e.g., to create config.h from config.h.in).
> [...]
> The problem is that 1) I do not understand what to check for and 2) I do
> not understand the implication of undefining HAVE_DEV_PTMX.
>
> It is not a matter to detect Debian, as the building procedure is
> already working on many Debian architectures. It is a matter of
> detecting freebsd kernel in a Debian OS, but why? What features is
> missing? As the same problem appeared long time ago in NetBSD and other
> *BSD, is it related to FreeBSD?

-- 
  Robert Munafo  --  mrob.com
  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com

Re: [B2-devel] Thoughts on SheepShaver and Basilisk II

[Robert M. <mr...@gm...>]

Wow. I spent a day on the Civ 2 "Eternal War" and now I have 30
messages about SS!

I'll have to respond in more than one message, but I'll try not to
repeat too much.

On 6/15/12, Alexander von Gluck <kal...@un...> wrote:
>   * CVS
>     Most projects left cvs for other version control software years ago.
> Much  better source revision control software exist. [...]

On the CVS issue, I think it would be kind of nice to have something
like Git's "Fork and Pull model"...

but I ALSO think that anyone who would make useful changes to BasII or
SS should be able to type "cvs diff -uN | gzip > patch.txt.gx"

Perhaps more of the development process (like this issue of submitting
improvements back upstream) should be more well-documented.

-- 
  Robert Munafo  --  mrob.com
  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com

Re: [B2-devel] Thoughts on SheepShaver and Basilisk II

[Frank T. <fra...@gm...>]

On Fri, Jun 15, 2012 at 9:28 PM, Alexander von Gluck
<kal...@un...>wrote:

> On 15.06.2012 20:36, Frank Trampe wrote:
> > So as to avoid duplicative effort, can you share what areas you plan to
> > improve? If you do start working on
> > re-implementing the memory management layer, I would be willing to help.
>
> Right now I'm starting with an overhaul of the build system and cleanup
>
>  * fix automake errors
>  * reduce C warnings
>  * remove crusty unused sources
>  * simplify code layout
>  * apply performance patches already floating around on the internet
>
> You can see what's been done so far here:
>   https://github.com/kallisti5/sheepshear/commits/master
>
> One mundane change upstream may want is:
>
> https://github.com/kallisti5/sheepshear/commit/3f409600d7aba91f1e6bb230b29165394525c70c
>
> It is a bit more readable. Did you do that all manually?


> I reworked some of the BIOS patching functions to be a little more
> efficient
> and less error prone.
> (using pointers for return data vs relying on 0 vs >0 for error detection)
>
>
You might consider renaming the new functions in a predictable pattern or
something. If the names are the same but the number of arguments different,
sharing code between the two projects might be more difficult.

> On Fri, Jun 15, 2012 at 6:34 PM, Alexander von Gluck
> > <kal...@un... [4]> wrote:
> >
> >> On 15.06.2012 17:34, Lew Irwin/Studio Briefing wrote:
> >> > For us non-techies who are using SheepShaver with the old "fork," what
> >> > does this mean?
> >>
> >> Nothing really.  The GNU license means a fork can take place as long as
> >> some
> >> guidelines
> >> are followed:
> >>
> >>  * Copyrights can't be changed (eg, I can't go back and erase the names
> >> of
> >> all the people
> >>    who made SheepShaver possible)
> >>  * Trademark laws must be followed. (thus SheepShear vs SheepShaver)
> >
> > And the resulting derivative products are forever locked into the G.P.L..
> > There are some down-sides to this, but it
> > makes merging back changes from those derivative products much simpler.
>
> Indeed you are correct, sorry for missing that important bit :)
>
>  -- Alex
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

Re: [B2-devel] Thoughts on SheepShaver and Basilisk II

[Alexander v. G. <kal...@un...>]

On 15.06.2012 20:36, Frank Trampe wrote:
> So as to avoid duplicative effort, can you share what areas you plan to 
> improve? If you do start working on
> re-implementing the memory management layer, I would be willing to help.

Right now I'm starting with an overhaul of the build system and cleanup

  * fix automake errors
  * reduce C warnings
  * remove crusty unused sources
  * simplify code layout
  * apply performance patches already floating around on the internet

You can see what's been done so far here:
   https://github.com/kallisti5/sheepshear/commits/master

One mundane change upstream may want is:
https://github.com/kallisti5/sheepshear/commit/3f409600d7aba91f1e6bb230b29165394525c70c

I reworked some of the BIOS patching functions to be a little more efficient 
and less error prone.
(using pointers for return data vs relying on 0 vs >0 for error detection)

> On Fri, Jun 15, 2012 at 6:34 PM, Alexander von Gluck 
> <kal...@un... [4]> wrote:
>
>> On 15.06.2012 17:34, Lew Irwin/Studio Briefing wrote:
>> > For us non-techies who are using SheepShaver with the old "fork," what
>> > does this mean?
>>
>> Nothing really.  The GNU license means a fork can take place as long as 
>> some
>> guidelines
>> are followed:
>>
>>  * Copyrights can't be changed (eg, I can't go back and erase the names 
>> of
>> all the people
>>    who made SheepShaver possible)
>>  * Trademark laws must be followed. (thus SheepShear vs SheepShaver)
>
> And the resulting derivative products are forever locked into the G.P.L.. 
> There are some down-sides to this, but it
> makes merging back changes from those derivative products much simpler.

Indeed you are correct, sorry for missing that important bit :)

  -- Alex