"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c5gm7u$iac$1@digitaldaemon.com...
> Ben Hinkle wrote:
>
> >hmm. what's a rar file and can you post the files in something
> >more conventional? something that WinZip can read, for instance.
> >Do I need to upgrade my WinZip?
> >thanks,
> >-Ben
> >
> >
> >
> Rar is a *slightly* better compression scheme then zip.  Get winrar or
> winase (winase does many formats).  Everyone uses zip and it doesn't
> seem people are willing to upgrade to/pick a (slightly) better format
> (of which there are many competing factions).
>

Am I right in thinking that if you have Apache or
Tomcat, you can just place the .rar file in one of
your servers folders, and when you retstart the
server the file unpacks itself? Or am I confused
with something else?

Phill.




---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.656 / Virus Database: 421 - Release Date: 4/9/2004

Phill wrote:
> 
> Am I right in thinking that if you have Apache or
> Tomcat, you can just place the .rar file in one of
> your servers folders, and when you retstart the
> server the file unpacks itself? Or am I confused
> with something else?

.war is the file type you're thinking of.

.jar is a Java Archive
.war is a Web Archive

"Brad Anderson" <brad@dsource.dot.org> wrote in message news:c5nrt5$2210$1@digitaldaemon.com...
>
>
> Phill wrote:
> >
> > Am I right in thinking that if you have Apache or
> > Tomcat, you can just place the .rar file in one of
> > your servers folders, and when you retstart the
> > server the file unpacks itself? Or am I confused
> > with something else?
>
> .war is the file type you're thinking of.
>
> .jar is a Java Archive
> .war is a Web Archive

Ah thats right, thanks, its been a while since I mucked around with Tomcat.

Phill.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.659 / Virus Database: 423 - Release Date: 4/15/2004

Walter wrote:
> "Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message
> news:c5c2fd$20p7$1@digitaldaemon.com...
> 
>>Do you mean serialization of classes, or serialization of threads? If the
>>former, then I may be able to help you out. If you meant the latter, then
>>read on:
>>
>>It appears as though Java 1.5 is adopting the full embrace of Doug Lea's
>>asynchronous package. Well, at least it looks like Doug's stuff. His home
>>page is over here:  http://gee.cs.oswego.edu/dl/
>>
>>It would be uber-cool if someone were to port even part of Doug's
> 
> impressive
> 
>>synchronization and serialization library over to D ...
>>
>>- Kris
> 
> 
> It does look like a nice package, and best of all, it's explicitly public
> domain. This means it can be transferred to D without worries (except for
> the two classes that carry a Sun copyright).
> 
> Anyone want to take the lead on this?

Hmm. I'm surprised no-one seems interested. Are there any HOWTOs or scripts that can help with Java -> D conversions? Not in terms of library calls - I just mean syntax. It shouldn't be too hard to convert this code.

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:c5v9nt$rjv$1@digitaldaemon.com...
> Hmm. I'm surprised no-one seems interested. Are there any HOWTOs or scripts that can help with Java -> D conversions? Not in terms of library calls - I just mean syntax. It shouldn't be too hard to convert this code.

As far as porting Java goes, my meager experience identifies these candidates:

1) replace boolean with bool
2) replace implements with  ':' or ','
3) remove "throws X" syntax
4) replace String with char[]
5) replace package with module
6) replace "(x== null)" with "(x is null)" or "(x === null)" where x is an
Object
7) replace "(x != null)" with "(x)" or "(x !== null)" where x is an Object
8) add cast keyword to C-style casts
9) remove Serializable interface, and transient keyword

FWIW, I felt that the tricky part would be reworking some of the "dependencies" on how the Java notify and interrupt stuff operates. For example, here's one of Doug's quotes:

"Why do so many methods perform notify within InterruptedException catches? Because when notify's and interrupt's happen at about the same time, JVMs are currently free to treat them independently, so a notified thread could return out as interrupted. In classes using notify rather than notifyAll, the extra notify in the catch clause is a safeguard to ensure that a non-interrupted thread, if one exists, will be notified. See my CPJ book for more details. "

Then there's the D Thread class to consider: it currently does a linear array search when asked for the current Thread object. I figured that would need to be reworked for speed (Thread.currentThread() is employed in Doug's code). Not a big deal, except for getting it back into Phobos. While at it, I would have tried to remove Thread.pause and Thread.resume since there are reasonable arguments as to why they're prone to deadlock.

Perhaps the biggest job in porting this stuff would be thorough testing.

I really, really, hope you'll take this on <g>

On Sun, 18 Apr 2004 19:34:31 -0700, Kris wrote:

> "Ben Hinkle" <bhinkle4@juno.com> wrote in message news:c5v9nt$rjv$1@digitaldaemon.com...
>> Hmm. I'm surprised no-one seems interested. Are there any HOWTOs or scripts that can help with Java -> D conversions? Not in terms of library calls - I just mean syntax. It shouldn't be too hard to convert this code.
> 
> As far as porting Java goes, my meager experience identifies these candidates:
> 
> 1) replace boolean with bool
> 2) replace implements with  ':' or ','
> 3) remove "throws X" syntax
> 
> <snip>
> Perhaps the biggest job in porting this stuff would be thorough testing.
> 
> I really, really, hope you'll take this on <g>

I would be interested in working on it. However, I highly recomend against any sort of mechanical (whether by human or machine) porting of his code: there are too many subtleties involved. The first issue that comes to mind is that D's (*nux) threading code is built on pthreads, the behavior of which is not fully consistent across platforms (it's *damn* close, but not 100%). This bit us in the ass over here a few months back.

I'm hesitant to take on this alone, as it's a big can of worms that's not really my domain. Anyone interested in jumping in with me?

Mike Swieton
__
It's kind of fun to do the impossible.
	- Walt Disney

> I would be interested in working on it. However, I highly recomend against
any
> sort of mechanical (whether by human or machine) porting of his code:
there
> are too many subtleties involved. The first issue that comes to mind is
that
> D's (*nux) threading code is built on pthreads, the behavior of which is
not
> fully consistent across platforms (it's *damn* close, but not 100%). This
bit
> us in the ass over here a few months back.

I wouldn't worry about making the threading cross-platform (yet). Any platform specific stuff that really needs to be there can be version'ed. I bet Walter would be very open to tweaks to std.thread to support this project, too.

> I'm hesitant to take on this alone, as it's a big can of worms that's not really my domain. Anyone interested in jumping in with me?

Do as much as you like/want/can, is my attitude. I've downloaded it and started looking at it. If we stick it up on www.dsource.org it should generate some more interest.

Mike Swieton wrote:
> On Sun, 18 Apr 2004 19:34:31 -0700, Kris wrote:
> 
> I would be interested in working on it. However, I highly recomend against any
> sort of mechanical (whether by human or machine) porting of his code: there
> are too many subtleties involved. The first issue that comes to mind is that
> D's (*nux) threading code is built on pthreads, the behavior of which is not
> fully consistent across platforms (it's *damn* close, but not 100%). This bit
> us in the ass over here a few months back.

Even worse, winthreads are quite different from pthreads in some cases., and lack features present in pthreads in other cases.  I'd suggest using the Boost threading library as a template for writing reliable cross-platform thread code.  I've also got one or two sources for public domain condvar and other algorithms not implemented in Windows around here somewhere if licensing or copyright concerns are an issue.
> 
> I'm hesitant to take on this alone, as it's a big can of worms that's not
> really my domain. Anyone interested in jumping in with me?

This is something I've been meaning to do but I've just been to darn busy.  But I'd love to see "real" threading support in D.


Sean