Looking for an alien solider

Martin -
I am trying to respond to your last email but it comes back as an 
invalid address. Please send me something so that I can get back to you.

Everyone else, please excuse the interruption. :-/

Michael

Everyone please pray for the french people

http://eucd.info/333.shtml

French Parliament approves the worst copyright law in Europe

Re: Everyone please pray for the french people

Liblayout

Bonefish,
I have seen quite a lot of progress on liblayout. I know the R5 binary
compatability requirements and the limits that imposes. I was wondering if you
intend to make it available (w/ assistance) to an BeOS derivative? Namely when
it is doen could I use it in my apps and know they will work on Zeta as well?

http://haiku-os.org/

http://matgeekau.blogspot.com/
http://matgeekaupolitcial.blogspot.com/

		
____________________________________________________ 
On Yahoo!7 
24: Watch it from 9.30pm on Thursdays on Seven 
http://www.seven.com.au/seven/24

Help with Sourceforge admin

I am trying to import Clue's code into Sourceforge. Preferablely as Subversion
but CVS is better than nothing.

When I triy to import into subversion on zeta it complains that
"https://svn.sourceforge.net/svnroot/clue" is a malformed URL.

When I try to import into CVS on zeta it complains it can't exec rsh.

Has anyone achieved it or should I just use <shudder> Linux?

http://haiku-os.org/

http://matgeekau.blogspot.com/
http://matgeekaupolitcial.blogspot.com/

		
____________________________________________________ 
On Yahoo!7 
Dating: It's free to join and check out our great singles! 
http://www.yahoo7.com.au/personals

Re: Help with Sourceforge admin

Hi

Mat Hounsell wrote:
> I am trying to import Clue's code into Sourceforge. Preferablely as Subversion
> but CVS is better than nothing.
>
> When I triy to import into subversion on zeta it complains that
> "https://svn.sourceforge.net/svnroot/clue" is a malformed URL.
>   
Don't know much about svn at SF but the BerliOS one uses "svn+ssh://..." 
URLs for secured developer access instead anonymous "http://..." -based 
ones. May be you just use wrong URL?
> When I try to import into CVS on zeta it complains it can't exec rsh.
>   
export CVS_RSH=ssh

should help you.

Regards,
   S.Zharski

Re: Liblayout

On 2006-07-03 at 03:15:04 [+0200], Mat Hounsell
<mat_geek@...> 
wrote:
> Bonefish,
> I have seen quite a lot of progress on liblayout. I know the R5 binary
> compatability requirements and the limits that imposes. I was wondering if 
> you
> intend to make it available (w/ assistance) to an BeOS derivative? Namely 
> when
> it is doen could I use it in my apps and know they will work on Zeta as 
> well?

Probably not. The main problem is that the layout stuff needs to be built 
into BView (and BWindow) and its the derived classes to work nicely. 
Otherwise one had to do something like Marco Nelissen did with liblayout and 
subclass all those classes, which I don't intend to do.

Also note that while layout management will probably be part of Haiku R1, it 
will be private API for that release, only used by applications in our 
repository. Everyone can use it, of course, but applications will likely 
need to be recompiled for the following release.

CU, Ingo

Re: Liblayout

Hi Mat,

> > I have seen quite a lot of progress on liblayout. I know the R5 binary
> > compatability requirements and the limits that imposes. I was wondering if
> > you
> > intend to make it available (w/ assistance) to an BeOS derivative? Namely
> > when
> > it is doen could I use it in my apps and know they will work on Zeta as
> > well?
> 
> Probably not. The main problem is that the layout stuff needs to be built
> into BView (and BWindow) and its the derived classes to work nicely.
> Otherwise one had to do something like Marco Nelissen did with liblayout and
> subclass all those classes, which I don't intend to do.
> 
> Also note that while layout management will probably be part of Haiku R1, it
> will be private API for that release, only used by applications in our
> repository. Everyone can use it, of course, but applications will likely
> need to be recompiled for the following release.

I'd like to add that liblayout by Marco Nelissen works fine on Haiku (with a 
few minor exceptions like button rendering). So if your app uses liblayout, 
it will work fine on either Haiku, R5 or ZETA, provided the library is 
present.

Don't confuse liblayout with what Ingo is doing though - except for the 
common goal, Ingo's layout management doesn't have anything to do with 
liblayout.

Best regards,
-Stephan

SCSI support

Hello,

I recently added the buslogic and symbios SCSI drivers to the
repository. They use the R5 SCSI bus manager interface. Now, since Haiku
uses a disk storage API layer based on Thomas' new IDE replacement
driver (+replacement driver model), the SCSI bus manager interface is
_completely_ different (for example, the CCB structure used is named
different, has different fields, etc).

To get any of the for R5 coded SCSI modules to work under current Haiku
we need to either:

1) Build an R5 SCSI wrapper (like ZETA has)
2) Depreciate the R5 SCSI bus manager interface.

Now I know Haiku was going for maximum binary compatibility but in this
case I would vote against option 1. From experience I can say that it is
quite a hack, and we've got source for 3 out of 4 of the SCSI modules in
SVN now (one of those is the usb_scsi module, which is the only 3rd
party SCSI module that I'm aware of) so we would loose little.

The only thing is, either we make the driver _really_ messy with all
kinds of _BEOS_R5_COMPATIBILITY_ #ifdef's, or the code in SVN would
become Haiku specific (no longer able of providing R5-compatible builds
of those modules).

Am I overlooking another possible option? And if not, are willing to
sacrifice our R5 packages built from svn (for the SCSI modules only)?

Opinions please :)

Regards,

Ithamar.

Re: SCSI support

First, welcome back! 

I personally don't see a whole lot of point in maintaining backward 
compatibility here. The whole point of BC was
a) keeping access to software
b) allowing people using R5 to keep their BFS partition and ability to 
easily switch between R5 and Haiku
c) Forcing us to somewhat limit our changes (i.e. keep us from getting 
too feature happy).

I think that in this particular case, losing the ability to build R5 
based SCSI packages is not that big of a hit. As time passes (and has 
passed), R5 is less and less viable. I still can't get Zeta, a much more 
compatible Kernel, to boot on my new hardware; I think that R5 is no 
longer an option for most people unless they own old hardware already.

Ithamar R. Adema wrote:
> Hello,
> 
> I recently added the buslogic and symbios SCSI drivers to the
> repository. They use the R5 SCSI bus manager interface. Now, since Haiku
> uses a disk storage API layer based on Thomas' new IDE replacement
> driver (+replacement driver model), the SCSI bus manager interface is
> _completely_ different (for example, the CCB structure used is named
> different, has different fields, etc).
> 
> To get any of the for R5 coded SCSI modules to work under current Haiku
> we need to either:
> 
> 1) Build an R5 SCSI wrapper (like ZETA has)
> 2) Depreciate the R5 SCSI bus manager interface.
> 
> Now I know Haiku was going for maximum binary compatibility but in this
> case I would vote against option 1. From experience I can say that it is
> quite a hack, and we've got source for 3 out of 4 of the SCSI modules in
> SVN now (one of those is the usb_scsi module, which is the only 3rd
> party SCSI module that I'm aware of) so we would loose little.
> 
> The only thing is, either we make the driver _really_ messy with all
> kinds of _BEOS_R5_COMPATIBILITY_ #ifdef's, or the code in SVN would
> become Haiku specific (no longer able of providing R5-compatible builds
> of those modules).
> 
> Am I overlooking another possible option? And if not, are willing to
> sacrifice our R5 packages built from svn (for the SCSI modules only)?
> 
> Opinions please :)
> 
> Regards,
> 
> Ithamar.
> 
> 
>