[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Re: [zzdev] Re: [zzdev] ZZDEV Problems
- To: zzdev@xxxxxxxxxx
- Subject: Re: [zzdev] Re: [zzdev] Re: [zzdev] ZZDEV Problems
- From: Joseph Osako <scholr@xxxxxxxx>
- Date: Sun, 18 Apr 1999 12:41:35 -0700
- In-reply-to: <370B62E1.370721F2@xxxxxxxxxxxxxxxx>
- References: <22.214.171.124.19990407211222.007d9a80@xxxxxxxxxxxxxxxxxxx>
- Reply-to: zzdev@xxxxxxxxxx
Sorry for the delay here, I've been unexpectedly busy.
At 02:51 PM 4/7/99 +0100, you wrote:
>> >>The second point I'd like to make is that it IMO we've gotten to the
>> >>where we need to break zigzag.pm into seperate pieces.
>I'm not sure zigzag.pm is too large. the script and the module were
>separated and I think some artifacts remain (the script still opens the
>I'd really like to see the front and back ends separated from each other
>by a network connection. The back end is the ZigZag server written in
>perl and the front end is something else somewhere else. Here we get a
>collabarative enviroment and a client cabable of using the hosts display
>cababilities to the full.
This is mostly what I had in mind; the size issue is more a reflection of
a) my personal programming esthetics and b) that I wasn't very familiar
with the current version. The seperation of front end and back is the real
key, esp if we're going to supportthe program on more than one platform.
The FE-BE seperation is a key part of the final Xanadu system, for the same
reason (among others).
>The problem with all of this is that Andrew is already maxed-out trying
>to implement the squillions of ideas that he and Ted have worked out
>already. Maybe ZZ version 2?
Perhaps. What I was looking for in the short term was just a physical
seperation of the interface code into a seperate package file, which is a
lot simpler than a full-fledged client-server design. What may make the
most sense is if I work out a simple prototype on a seperate RCS worldline
(is that the right term?), with no (or very few) changes in program
behavior, just separating the UI code out.
>> >Sorry for being gone for so long, but other matters have been getting in
>> >the way. After my talk with Marlene, I had promised to try and work on the
>> >prototype Windows 95/98 installation package, and I should be free to
>yey! another windows user! - this post get's windowsey from here on...
Not exactly by choice. I'm no fan of *any* of the existing OSes, but I've
mostly used Multics95 for work-related reasons.
>> >For now, I'm using ActivePerl 1.0 (build 509), which is supposed to be BC
>> >with Sarathy's port. Since its under the Community Liscense, it supposedly
>I had bad experiences a while back with ActivePerl. I found the
>Gurusamy build a lot easier to use and more compatible with the Unix
>version. The trouble is - Gurusamy now works for Activestate so I guess
>we'd better start using their build. I hope he's made it better.
It seems OK, but it doesn't appear to have a Curses module the way I
understand Sarathy's did. As a result, I haven't gotten it working yet.
Worse, I can't seem to find one for it. It looks as if it may be necessary
to use Win32:Console instead, which means we'd need two radically diferent
versions of the screen handling code. I could go back and install an older
version, but then we'd have support and updating problems. Are there any
>> >First off, when we're ready to do so, I assume we'll want a
>> >system a la InstallShield. In order to do this, I'll need to know what
>> >we'll be bundling together with the program. For example, will we want to
>> >have it autoinstall Perl (or offer the option to do so), or should we
>> >assume that the user has already installed it (or can install it
>tricky question. Most Unix users are familier with installing extra
>librarys in order to get something to work (or they know a guru that
>Most windows users will not have perl installed or know what CPAN is.
>Is it possible to take just bits of the ActiveState package and
>re-package them? If so then could you make an install that contains
>eveything that you need to make ZigZag run? This makes things easy for
>the user and gives you control of which version of perl / shared
>library's are installed - it might make for a bigger install but how big
>was your system directory last time you looked?
It looks like it. They distribute the Perl interpreter seperately, and it
should be possible to bundle just the interpreter and the libraries, but
I'm not sure. They also offer a Perl compiler, but its not free, and I
don't know if all of the current code would work compiled (it should, I
haven't seen any reflective interpreter calls or other problematic code,
but I haven't gone through the code exhaustively yet).
Programmer Analyst, Operating Systems Designer, Notational Engineer