[B2-devel] Re: basilisk-devel digest, Vol 1 #114 - 1 msg

[<ni...@in...>]

> OK, got the source for the OS X version, thanks.

	Thanks for looking through all my hacky source code, Max!


> I am already using 10.1 + 10.1 dev tools, which meant I first had a 
> hard time using the ObjC parts - the problem is that several files 
> (e.g. main.h) use C++ constructs,


	Hmmm. The only C++ism I could see in main.h was 'bool',
which is defined by main_MacOSX.h. As soon as I can get a copy
of 10.1, I will re-check compilation.


...
> The simple fix was to change the suffices to .mm which turns 
> on the ObjectiveC++ compiler on OS X 10.1

	If it is going to be built with the Obj-C++ compiler,
then all the glue functions in cpp_glue_MacOSX.{cpp,h} can go.


> Maybe some of my problems are also because I am trying to mix this 
> with the CVS version of Basilisk?

	Yes. The tarball I sent you is only for Basilisk 0.9 & OS10.0.
I think it compiled against this tarball:

http://iphcip1.physik.uni-mainz.de/~cbauer/BasiliskII_src_31052001.tar.gz

though it may be this one:

http://iphcip1.physik.uni-mainz.de/~cbauer/BasiliskII_src_17022001.tar.gz


...
> As for various of the problems mentioned in the README (regarding 
> double clicks, intercepting Cmd-key shortcuts etc.), that is because 
> the approach you used to hook into the system is not so good for this 
> kind of application. A view just doesn't get it all.
> 
> The solution usually is to subcalls NSApplication, and provie an own 
> sendEvent method. There you can intercept any events you want, and 
> pass the ones you are not interested to the original implementation.

	Excellent. I hadn't thought of that. I eagerly await your code!


> Oh, and I am not so convinced that this is good style:
> 
> void	errorPanel   (const char *text),
> 	warningPanel (const char *text);

	What is bad style? The function names? The multi-line decl?
The actual purpose of the functions?


...
> #ifdef __cplusplus
> }
> #else
> 
> // These are called from Objective-C methods only
> extern void errorSheet   (NSString *msg1, NSString *msg2, NSString 
> *button, NSWindow *win),
> 			warningSheet (NSString *msg1, NSString *msg2, 
> NSString *button, NSWindow *win);
> 
> #endif
> 
> This ain't no good, either, it causes a catch 22 - if I turn on C++ 
> extensions, I can't compile because those definitions are gone.

	Well, yes, but Obj-C++ didn't exist when I hacked this together.
The compiler supported either C++ or Obj-C.

...
> The proper way of doing this is to check the __OBJC__ macro

	Thanks. Done.

...
> #import <Foundation/NSArray.h>;
> 
> Please remove the ; it causes a compiler error in the new dev tools 
> (rightfully). In fact the line is not needed at all since it is 
> already covered by Cocoa.h

	Deleted.

> Same in PrefsEditor.h, there is a line
> #include "Emulator.h";

	Corrected.


> #####################################
> In Emulator.m/.h, you use a variable called "clock" which somehow 
> clashes with the unix function of the same name somehow.

	Hmm. It doesn't clash under 10.0. Anyway, I have called it
'RTC', and renamed clockInterrupt() as RTCinterrupt().

...
> 	[emul	terminate];  emul	= nil; [emul	release];
> 
> This is nonsense!

	Oops. Those lines should have been:

    [emul terminate]; [emul release]; emul = nil;

	Have corrected.


...
> #####################################
> In Emulator.m. method SpeedChange, you call
> 
> [redraw changeIntervalTo:redrawDelay * 1e6
> 	units:NNmicroSeconds ];
> 
> However, this doesn't make sense to me looking at how 
> changeIntervalTo:units: is implemented - why don't you simply change 
> the first parameter of that function to accept a double? then change 
> the above mentioned call to
> 
> [redraw changeIntervalTo:redrawDelay
> 	units:NNSeconds ];

	The NNTimer class uses nanosleep, which uses integers to set
its delay period. I decided to stick with passing integers into its
methods, hence the need to send the delay as a multiple of a small
time delta.


...
> Could you give me a quick hint what NNThread and NNTimer are needed 
> for - what advantage do they have over NSThread and NSTimer?

	They are not, strictly speaking, _needed_. They are mainly
an elegance thing. I created them to simplify all the pthread stuff
in main_unix.cpp. Their history:


	Right from the start, I wanted the ability to suspend the
Basilisk emulator. Later on, I had the idea of multiple emulators
(e.g. test a program under both OS 6 and 7, in separate windows).
So, I wanted a thread class that gave me:

* An easy way to suspend and resume the threads

* Threads that I could start off in an inactive state
  (like pthread_create_suspended_np() )


	I started off with wrappers to pthread calls with Mach style
thread manipulation, and then added:

* The option to allocate an ObjC autorelease pool

* A large variety of method syntaxes

* Timers which:
  - used NNThreads for totally independant operation
    (e.g. if I had 5 timers, one of their methods could
          never return, but the others would keep firing)

  - had similar method syntax to the Threads
    (e.g. I can start, suspend or resume both NNThreads and NNTimers)

Note that NNThread currently uses NSThread (for GUI safety),
but could easily use pthread, cthread or Mach Kernel threads.




	Now, instead of all this, I could have used one NSThread,
which called a modified main() from main_unix.cpp, and have the GUI
thread locate the Mach kernel thread of that main() and manipulate
its state, but that just felt really ugly. Much tidier to individually
create the threads and timers from Obj-C, and then toggle their state
all at once.


	Sorry, that wasn't very quick.

-- 
| Nigel Pearson, ni...@in...    | "Reality is that which,   |
| Telstra iDevelopments, Sydney, Australia |  when you stop believing  |
|   Office: 9206 3468    Fax:  9212 6329   |  in it, doesn't go away." |
|   Mobile: 0408 664435  Home: 9792 6998   |  Philip K. Dick - 'Valis' |