853 lines
39 KiB
Plaintext
853 lines
39 KiB
Plaintext
AppleLink
|
|
APPLE II DEVELOPMENT FORUM CONFERENCE LOG
|
|
August 29, 1989 10:00 p.m. eastern time
|
|
Topic: ByteWorks Products - Special Guest Mike Westerfield
|
|
Forum Leader: Dave Sugar (AFL Dyfet)
|
|
|
|
AFL Dyfet Well, it's about that time (10:00EST), so I guess we better get
|
|
started :)
|
|
AFL Dyfet Good evening and welcome to the Apple II development. As you can
|
|
see by that
|
|
AFL Dyfet worm up there, tonight's topic was originally scheduled open, and
|
|
appearently
|
|
AFL Dyfet it never got changed :(...In any case, tonight's topic is
|
|
BYTEWORKS and related
|
|
AFL Dyfet tools, and our special guest tonight is Mike Westerfield. We
|
|
will be using
|
|
AFL Dyfet PROTOCOL tonight, which means, if you wish to ask a question, you
|
|
should enter
|
|
AFL Dyfet a '?' on a line by itself, like Parik just did, and if you wish to
|
|
comment on
|
|
AFL Dyfet the current discussion, you must enter a '!' on a line by itself.
|
|
You will
|
|
AFL Dyfet be called upon in turn to speak. But first, before we get
|
|
started, I would
|
|
AFL Dyfet like to give our guest a chance to introduce himself :). Mike,
|
|
you have the
|
|
AFL Dyfet floor now :).
|
|
MikeW50 Gee... (blush). For the two of you who don't know :) I'm Mike
|
|
Westerfield,
|
|
MikeW50 President of the Byte Works, Inc. We write development systems
|
|
for
|
|
MikeW50 Apple II computers, most recently for the Apple IIGS, where we now
|
|
offer
|
|
MikeW50 assembly language, Pascal, and C, all working from either a text
|
|
or
|
|
MikeW50 desktop environment, and all sharing the same development
|
|
environment.
|
|
MikeW50 ga
|
|
AFL Dyfet I see your modest too, Mike :)...
|
|
AFL Dyfet GA Phil, if you have a comment, and aren't sneaking in a question
|
|
:)
|
|
AE PhilM Hi Mike, that all!
|
|
AE PhilM ga
|
|
MikeW50 Hola.
|
|
MikeW50 ga
|
|
AFL Dyfet :) Okay, I believe our first question is from AFA Parik. You
|
|
have the floor
|
|
AFL Dyfet now.
|
|
AFA Parik couple Q's. What ever happened to Orca/Basic? Have you seen John
|
|
Brooks
|
|
AFA Parik TurboLink and/or Randy's Rose editor? if so, have you talked with
|
|
them about
|
|
AFA Parik maybe including them? they are really hot! Also - can you give a
|
|
status
|
|
AFA Parik report on Orca/M v2.0? ga
|
|
MikeW50 First, ORCA/BASIC is still an active project, but an incredibly
|
|
hectic and
|
|
MikeW50 busy schedule keeps pushing it back. That's why we have been
|
|
silent about
|
|
MikeW50 release dates. I don't want to continue to get people's hopes up,
|
|
only to
|
|
MikeW50 dash them when a slip comes up. Frankly, although it is still an
|
|
active
|
|
MikeW50 project, I'm sorry we ever anounced that we were working on it. I
|
|
don't like
|
|
MikeW50 doing that sort of think to you.
|
|
MikeW50 I have seen both the editor and linker you asked about. Neither
|
|
is likely
|
|
MikeW50 to make it into our commercial product, simply because we could
|
|
not
|
|
MikeW50 1. pay for it
|
|
MikeW50 2. support it
|
|
MikeW50 I also like to see a _choice_ of editors. If there is one truism
|
|
about
|
|
MikeW50 editors, it's that no one editor satisfies everyone. There are
|
|
many
|
|
MikeW50 people who are very happy with the one we ship, or who want to see
|
|
it
|
|
MikeW50 extended rather than replaced. I want Randy to publish his as a
|
|
_alternative_,
|
|
MikeW50 not a replacement. That gives you a choice.
|
|
MikeW50 While the linker you mentioned is fast, it is also very
|
|
non-standard in the way
|
|
MikeW50 it works and the features it supports. Look for a new linker from
|
|
us that is
|
|
MikeW50 about as fast, but supports all features and works in a more
|
|
normal way.
|
|
MikeW50 ORCA/M 2.0 is under development. It will be the basis for 2.0
|
|
versions of
|
|
MikeW50 C amd Pascal, as well. I can't give you firm release dates, yet.
|
|
The major
|
|
MikeW50 features are full support of system 5.0, including resources, and
|
|
lifting of
|
|
MikeW50 many limitations, such as longer expanded command lines (64K) to
|
|
allow
|
|
MikeW50 for more link names, 64K shell variables, and 8K path names. I
|
|
will be
|
|
MikeW50 happy to answer ?s about it.
|
|
MikeW50 ga
|
|
AFA Parik multiple commands on a single line? ;) thanks! <done>
|
|
MikeW50 You have mutiple commands on a line now... ga
|
|
AFL Dyfet Okay, I'm sure some questions will be asked about that before the
|
|
end of
|
|
AFL Dyfet tonight :)...I believe the next question is from WindRider...GA.
|
|
Windrider5 I have been reading recently about object-oriented programming and
|
|
C++ do you
|
|
Windrider5 think Apple of Byteworks will ever support OOP/C++ for the IIgs
|
|
Windrider5 ga
|
|
MikeW50 I can't speak for Apple. As for us, we are seriously considering
|
|
C++ as
|
|
MikeW50 an extension to a future version of ORCA/C. On the other hand, I
|
|
am not
|
|
MikeW50 willing to publicly commit to anything even vaguely resimbling a
|
|
release
|
|
MikeW50 date. ga
|
|
AFL Dyfet Okay, I believe Coach has the floor next. GA Coach...
|
|
Coach101 First, do you have a feel for the general time frame of the
|
|
release
|
|
Coach101 that fully supports 5.0 and is that the "free" upgrade I have read
|
|
about?
|
|
Coach101 ga
|
|
MikeW50 I assume you are speaking of C. The free update will include a
|
|
new compiler,
|
|
MikeW50 new libraries, and new interface (.h) files. We are currently
|
|
working on the
|
|
MikeW50 bug fixes, and waiting on the .h files, which are supplied by
|
|
Apple.
|
|
MikeW50 Unfortunately, the fact that we decided to include 5.0 with C 1.1
|
|
has slowed
|
|
MikeW50 it down considerably -- we have to wait for Apple supplied
|
|
files.
|
|
MikeW50 As for the "full" support of 5.0, the current system works with it
|
|
fine, with
|
|
MikeW50 the exception of the ORCA COPY command, which does not copy
|
|
resource forks.
|
|
MikeW50 The 5.0 free C upgrade will ship considerably before we have
|
|
finished the
|
|
MikeW50 new shell, which will take advantage of the new features offered
|
|
by 5.0.
|
|
MikeW50 That will be later this year. The free upgrade to C may ship as
|
|
soon as
|
|
MikeW50 next week. If we don't have files from Apple vefore AppleFest
|
|
(late Sept),
|
|
MikeW50 we will just modify the files ourselves, and ship anyway. That
|
|
would,
|
|
MikeW50 unfortunately, mean that we would have to do another update when
|
|
we get
|
|
MikeW50 Apple's .h files. I hope we don't have to do that.
|
|
ikeW50 ga
|
|
Coach101 "C" was what I was referring to. Thanks for the infor.....
|
|
Done...
|
|
AFL Dyfet I have a question...why does Apple have to supply the headers?
|
|
MikeW50 We use Apple's tool interface headers to maintain as much
|
|
compatibility as
|
|
MikeW50 possible between ORCA/C and APW C. It is also supposed to make
|
|
our interfaces
|
|
MikeW50 more accurate, since they are generated mechanically from original
|
|
data, and
|
|
MikeW50 make them match the Apple-supplied toolbox documentation.
|
|
ikeW50 ga
|
|
AFL Dyfet That seems like a wise choice then :)...I believe Phil has the
|
|
floor next..GA
|
|
AFL Dyfet Phil.
|
|
AE PhilM In 2.0 can will we see a recursive delete command, and text output
|
|
thru the
|
|
AE PhilM console driver (for speed). Will switch and compress work with
|
|
directories
|
|
AE PhilM that have extended files. Finally, please don't change the way
|
|
the editor
|
|
AE PhilM handles key substitutio (ie. SYSECMD) I really like the editor I
|
|
am using now
|
|
AE PhilM done
|
|
MikeW50 The ORCA/M 2.0 shell will support recursive deletes. Keep in mind
|
|
that while
|
|
MikeW50 I cannot talk about APW, there will be some differences between
|
|
the ORCA/M and
|
|
MikeW50 APW shell. (ORCA will have more.) (Hint, hint...)
|
|
AE PhilM :)
|
|
MikeW50 The new shell supports output using the console driver. For
|
|
speed? Well, no.
|
|
MikeW50 The text tools are _still_ faster that the console driver, but the
|
|
OS team
|
|
MikeW50 keeps promising that that will change someday. Old programs that
|
|
use the text
|
|
MikeW50 toolkit will still work -- the very flexable text tools will be
|
|
routed by the
|
|
MikeW50 shell to the less flexible console driver, which would not be able
|
|
to handle th
|
|
MikeW50 reverse situation.
|
|
MikeW50 Compress and switch shoudl support extended files now. The
|
|
problem is that
|
|
MikeW50 there is a "feature" (DTS insists it is a feature, not a bug)
|
|
that
|
|
AFA Parik Will there be a rez compiler on 2.0? Is it going to be as large
|
|
as APWs? :)
|
|
MikeW50 prevents a program from using write-block to the boot disk.
|
|
COMPRESS and
|
|
AFA Parik (whoops, sorry)
|
|
MikeW50 SWITCH work fine if you use them on any disk except the boot
|
|
disk.
|
|
MikeW50 We will eventually stop supporting the key remapping feature of
|
|
the current
|
|
MikeW50 editpr, but it will not happen until it is replaced by a much more
|
|
flexable
|
|
MikeW50 mechanism for doing the same thing (and more). That may be in
|
|
2.0, but
|
|
MikeW50 frankly, it will probably have to wait until a little later.
|
|
MikeW50 ga
|
|
Dave Lyons With the Console Driver, there is the potential for being much
|
|
faster than the
|
|
AE PhilM Thats not a feature.....preventing a write block call?? Thanks
|
|
Mike!
|
|
Dave Lyons text tools--this depends largely on the calls being
|
|
multiple-character writes
|
|
Dave Lyons rather than single-character ones, so the advantage won't become
|
|
too apparent
|
|
MikeW50 Without getting into a debate, console drivers are not used as
|
|
block-output
|
|
Dave Lyons until EXE utilities and/or the shell itself start going directly
|
|
to the
|
|
MikeW50 devices. They are sed as single-character devices by shells.
|
|
Since the shell
|
|
Dave Lyons console driver.
|
|
MikeW50 is the only program that uses it (right now), it must be fast the
|
|
way the shell
|
|
MikeW50 uses it, not the way the tester tests it. ga
|
|
Dave Lyons GS/OS wasn't designed to allow direct block access to a disk with
|
|
open files
|
|
Dave Lyons on it--since Sys.Resources is generally open, that means you can't
|
|
do block
|
|
Dave Lyons access to your boot disk, at least not without a lot of trouble.
|
|
Dave Lyons EXE utilities typically use things like WriteLine today, right?
|
|
If you
|
|
Dave Lyons replace these with multiple-character writes (using Write or
|
|
DWrite--don't
|
|
Dave Lyons remember which way is faster), you get a lot of speed out of the
|
|
console
|
|
Dave Lyons driver.
|
|
Dave Lyons (ga)
|
|
MikeW50 Dave, the shell is written to handle output of a character stream.
|
|
While
|
|
MikeW50 proms _could_ be completely rewritten to collect characters into a
|
|
single line,
|
|
MikeW50 then send them in bursts, it is not reasonable to expect the
|
|
programmer to do
|
|
MikeW50 that just to suppprt the new console driver. The console driver
|
|
should be
|
|
MikeW50 rewritten to support the existing programs, which all worked fine
|
|
before.
|
|
Dave Lyons Old programs continue to work; but there is the opportunity for
|
|
large
|
|
MikeW50 As for write block, keep in mind that the "feature" breaks
|
|
existing programs.
|
|
MikeW50 It can also be avoided by changing GS/OS. Breaking existing
|
|
programs,
|
|
Dave Lyons speed increases by using the console driver in "spurts"--I think
|
|
it's
|
|
Dave Lyons reasonable in some cases to take advantage of the speed.
|
|
MikeW50 especially without providing an alternative, is something Apple
|
|
can choose
|
|
MikeW50 to do, but I hope you change your mind.
|
|
MikeW50 ga
|
|
Dave Lyons On WriteBlock--also note that block-level access to volumes
|
|
MikeW50 Sorry -- I missed your comments because I was still typing.
|
|
Dave Lyons is never recommended, and that you can always boot from another
|
|
disk to
|
|
Dave Lyons do block-level stuff to a particular disk.
|
|
MikeW50 Right - or reboot P8 to do the job, as the DTS letter recommended.
|
|
Put THAT
|
|
AE PhilM Dave, that is not reasonable...that is not the way people work.
|
|
Generally
|
|
MikeW50 in your script file!!!
|
|
AFA Parik (hd...:-)
|
|
AE PhilM they are booting from a harddisk and dont really want to boot up
|
|
from another
|
|
AE PhilM disk just to use switch an compress.
|
|
AFL Dyfet Or do a quick hack on a file :)
|
|
Dave Lyons It is reasonable to ask that GS/OS be enhanced in the future
|
|
AE PhilM It's really very inconvenient.
|
|
AE PhilM done
|
|
Coach101 ProSel-16 will do the SWITCH, SORT, etc. on the boot disk!!
|
|
Dave Lyons to allow block-level access even with open files--with caching
|
|
going on at
|
|
Dave Lyons the device and FST level, this is a tricky issue.
|
|
AE PhilM Then I will ask that it does. If the time penalty is not too
|
|
great to do so
|
|
AE PhilM now without a re-design...then it should be done ASAP.
|
|
MikeW50 PrSEL-16 will not do it's stuff using 5.0. ORCA works fine with
|
|
4.0. ga
|
|
Dave Lyons (done)
|
|
AE PhilM done
|
|
AFL Dyfet Any other takers?
|
|
Coach101 Yes
|
|
AFL Dyfet GA Coach...
|
|
Coach101 I think that there must be a way to do it currently (DRead/DWrite
|
|
maybe)
|
|
Coach101 but the whole concept is very scary.. The OS is doing caching
|
|
(FST.DEV)
|
|
MikeW50 I asked DTS about DRead, DWrite. It will work, but leaves you in
|
|
danger of
|
|
MikeW50 corrupting the disk. ga
|
|
Coach101 and ANY write activity to the disk is just FLAT DANGEROUS and
|
|
beyond
|
|
Coach101 the scope of understnding by the JTU (Jay Turkey User).
|
|
Coach101 With respect to the CONSOLE driver issue, I agree with both of
|
|
you. The SHEL
|
|
Coach101 has a need for character I/O but the programs , I think, tend to
|
|
things
|
|
Coach101 in line form. In line form the speed increase will be there and
|
|
Coach101 MORE importantly, a program can be used outside of the SHELL (i.e.
|
|
a sort
|
|
Coach101 program launched by a database program) and use the new prefixes
|
|
Coach101 to accomplish I/O redirection. Done....
|
|
AFL Dyfet Also, by using the new prefix based redirection, one no longer has
|
|
to worry
|
|
MikeW50 I agree. And I think that the console driver will eventually be
|
|
AFA Parik like I asked before, how will rez be handled? a text and desktop
|
|
compiler? Will
|
|
MikeW50 faster than the text tools are now. They just aren't yet.
|
|
MikeW50 ga
|
|
AFL Dyfet about stdin/stdout being implimented incompletely. You could do
|
|
fseek/etc on
|
|
AFL Dyfet stdio again :)...
|
|
Coach101 Perhaps....
|
|
AFA Parik it be a programmers thing, or something like Genesys/DesignMaster?
|
|
Also, how
|
|
Coach101 The resolution is to have a way to have GS/OS flush all cache for
|
|
a
|
|
AFA Parik do you do multiple commands on one line? (ie, prefix /xxx/xxx
|
|
cat)
|
|
Coach101 particular device... Then the test for Block I/O could be is
|
|
there any
|
|
Coach101 items for the volume in the cache... If so, no block I/O.. If
|
|
not, Block I/o
|
|
AE PhilM Coach, the cache is implemented at the block I/O level....it is a
|
|
write thru
|
|
AE PhilM cache so there is no reason to flush it.
|
|
AFL Dyfet PLEASE, ONE AT A TIME.!! GA Dave, YOU now have the floor :)
|
|
Dave Lyons But the FSTs are allowed to have copies of bitmap/etc blocks that
|
|
are *more*
|
|
Coach101 But you MUST invalidate it!]
|
|
Dave Lyons up to date than what has been written to disk. By the time a
|
|
WriteBlock
|
|
Dave Lyons request comes through, the application may have computed the
|
|
*wrong* data
|
|
Dave Lyons to write to disk, and flushing the FST info to disk right before
|
|
that data
|
|
Dave Lyons is written may just fry things by re-over-writing it. (Consider
|
|
using a
|
|
Dave Lyons block editor on a bitmap block while files are open, for example.)
|
|
Maybe
|
|
Dave Lyons the answer is to do the FST flushing at ReadBlock time, and allow
|
|
WriteBlock
|
|
Dave Lyons only if there was a ReadBlock with no intervening File-oriented
|
|
calls...or
|
|
Dave Lyons *something* like that. It's definitely complicated. GA
|
|
MikeW50 Dave, it's simple. The OS, as advertised, is only changing the
|
|
blocks without
|
|
AFL Dyfet GA Coach...
|
|
MikeW50 writing them during certain well-defined calls that could disable
|
|
write-block.
|
|
MikeW50 In any case, the OS does not prevent write-block froma happening
|
|
on a general
|
|
Dave Lyons Mmmm...that isn't clear at all to me from the documentation. When
|
|
files
|
|
MikeW50 disk, so if it is angerous, it is possible to do harm _now_.
|
|
Dave Lyons are open, FSTs "know" what's eventually going to be on disk.
|
|
MikeW50 In any case, this is a topic for another night. Can we move on?
|
|
MikeW50 ga
|
|
Dave Lyons (I'm *not* talking about Sessions here, by the way.)
|
|
Dave Lyons (OK, done)
|
|
MikeW50 (I was.)
|
|
Coach101 Maybe a folder for this discussion....
|
|
Coach101 ga
|
|
AFL Dyfet Perhaps this should be moved to a folder :)...Okay, I believe
|
|
Parik had the
|
|
AFL Dyfet next question. GA Parik...
|
|
AFA Parik sorry about jumping the gun before. :) one more time... how will
|
|
2.0 handle
|
|
AFA Parik rez? e-z to use? Or would genesys / designmaster be better?
|
|
MikeW50 We will be licensing the resource compiler/decompiler from Apple
|
|
and shipping
|
|
MikeW50 those with 2.0. We will also be offering alternative, visual
|
|
methods. I
|
|
MikeW50 will be ready to talk more about those at AppleFest, where we hope
|
|
to be
|
|
MikeW50 ready with some exciting anouncements.
|
|
AFA Parik Ok, lastly..you said we could have multiple commands on a command
|
|
line. HOW?
|
|
MikeW50 You also asked about multiple commands on one line back there in
|
|
the
|
|
AFA Parik I can't do a PREFIX /xxx CAT. done
|
|
MikeW50 forrey about write-block. Those are handled with a semi-colon in
|
|
the
|
|
MikeW50 current shell. For example,
|
|
MikeW50 cat;cat
|
|
MikeW50 will do two catalogs.
|
|
MikeW50 ga
|
|
AFA Parik whoah, just tried it. You're right! Thannnnks!!!!! <ga> (very
|
|
happy) :)
|
|
MikeW50 :) same thoughts...
|
|
AFL Dyfet Okay, I believe the next question is from Dave Lyons...GA
|
|
Dave...
|
|
Dave Lyons Just a quick set-the-record-straight: Mike mentioned earlier a
|
|
letter where
|
|
Dave Lyons Apple II DTS suggested rebooting into P8 to do block-level
|
|
editing. I don't
|
|
Dave Lyons have a copy of that in front of me (and I didn't write it), but I
|
|
assume that
|
|
Dave Lyons this was *one* of several alternatives given--another of which is
|
|
to boot
|
|
Dave Lyons from a different disk. If we gave an incomplete answer, I
|
|
apologize. (done)
|
|
MikeW50 Actually, Dave, that wasn't quite what the letter said. I was
|
|
told flat out
|
|
MikeW50 that GS/OS was not designed to handle block writes because it was
|
|
designed
|
|
MikeW50 to handle a variety of FSTs. I was also told flat out that disk
|
|
utilities that
|
|
MikeW50 needed to do block writes should use P8. Maybe I misinterpreted
|
|
the tone, but
|
|
MikeW50 it seemed clear that I would get no help on making our existing,
|
|
functional pro
|
|
MikeW50 program work inder the new OS. If I still have the letter, I will
|
|
be happy
|
|
MikeW50 to post it. ga
|
|
Dave Lyons It's hard to remember all the details of your previous
|
|
correspondence--but
|
|
Dave Lyons GS/OS *is* designed to allow block-level I/O: just not to volumes
|
|
that
|
|
Dave Lyons contain open files. I believe it was suggested that P8 would be a
|
|
good
|
|
Dave Lyons alternative for *ProDOS-specific* block-level stuff. If there are
|
|
issues
|
|
Dave Lyons that are not completely resolved, please bring them up again
|
|
through
|
|
Dave Lyons official channels before posting them here.
|
|
MikeW50 Dave, I would love to talk with you about it. I wanted to add
|
|
_more_ disk
|
|
MikeW50 utilities in our new OS. I tried working through official
|
|
chanels, though,
|
|
MikeW50 and was firmly rebuffed. If you would like to reopen them, let's
|
|
do so.
|
|
MikeW50 ga
|
|
Dave Lyons Please do--the correspondence died down, so I assumed
|
|
Dave Lyons that the issues were all resolved! ga
|
|
MikeW50 No, I simply gave up. ga
|
|
AFA Parik real quick: something I'd like in 2.0 is the ability to change the
|
|
cat output,
|
|
AFA Parik maybe even make cat a seperate utility w/ source? ga
|
|
MikeW50 The plan for the ORCA cat command is as follows:
|
|
MikeW50 1. By default, it will look like it does now.
|
|
MikeW50 2. You will have a single flag to print a list of file names,
|
|
with no
|
|
MikeW50 other info. There will probably be a way to put the list in a
|
|
shell variable
|
|
MikeW50 for use in scripts.
|
|
Coach101 Wow!
|
|
MikeW50 3. Every piece of information available from s GetFileInfo call
|
|
will be
|
|
MikeW50 available with flags. Since it will not (gernarally) fit on a
|
|
line, it
|
|
MikeW50 will be presented in a table format. You can choose the specific
|
|
info you
|
|
MikeW50 want with flags.
|
|
MikeW50 ga
|
|
AFA Parik can we change the type / subtype fields w/o using a block
|
|
editor?
|
|
AFL Dyfet Well, I believe we have plenty of room for more questions, folks
|
|
:)...
|
|
MikeW50 (Did you want something else? ;) )
|
|
Dave Lyons Mike, can the catalog be sorted different ways?
|
|
MikeW50 Yes -- the filetype command can now change both the file type and
|
|
aux type of
|
|
MikeW50 a file.
|
|
MikeW50 ga
|
|
MikeW50 Sorting... I hadn't planned that, but I will do so if I can figure
|
|
out a
|
|
AFL Dyfet GA Dave...
|
|
Dave Lyons -! :)
|
|
MikeW50 quick way to do it. (thinking...) Sure. Standard and
|
|
alphabetical OK? ga
|
|
Dave Lyons How 'bout sorting by mod date and filetype, and with multiple
|
|
keys?
|
|
Dave Lyons And Create date, too! I hate it when I download a file w/ an old
|
|
mod date
|
|
Dave Lyons and can't find it in the dir listing.
|
|
Dave Lyons And Size--basically, you ought to be able to sort by anything that
|
|
can be
|
|
Dave Lyons listed. (ga)
|
|
AFL Dyfet GA Doctor...
|
|
MikeW50 Uh... well, the sort isn't hard, but I'm a little woried about the
|
|
syntax
|
|
Doctor Why And while your at it allow for ascendng and descending.
|
|
MikeW50 to make all of that understandable. I will give it a try, though.
|
|
Perhaps
|
|
MikeW50 that should be an interactive utility, though. Any thoughts on
|
|
that? ga
|
|
Dave Lyons I have a fairly workable solution to most of that
|
|
Dave Lyons in Davex 8...the "-a" option takes a string, which is a sequential
|
|
list of
|
|
Dave Lyons keys to sort on, with Uppercase reversing the order. So cat -aFm
|
|
means to
|
|
Dave Lyons sort backwards by filetype, breaking ties by mod-date. ga
|
|
MikeW50 Seems a bit complicated, but heck, that's what help files are for.
|
|
I'll
|
|
MikeW50 give it a shot. ga
|
|
Dave Lyons (a="arrange", by the way)
|
|
MikeW50 (And thanks for the suggestion.) (ga)
|
|
AFL Dyfet And that's also what pipes and a good sort filter are for :)
|
|
MikeW50 :) yup.
|
|
AFL Dyfet And aliases to make it clean :)
|
|
MikeW50 Still, with alias, you can make your prefered format the
|
|
default...
|
|
MikeW50 ;) great minds think alike
|
|
Coach101 Dont break your arms guys :)
|
|
AFL Dyfet Well, do we have any other questions for tonight?
|
|
AE PhilM I would REALLY like to beta test the 2.0 linker.....how about it?
|
|
With TWGS,
|
|
AE PhilM System 5.0 life is great....but could be better (faster) (hint
|
|
hint)
|
|
AE PhilM (never satisfied)
|
|
AE PhilM done
|
|
AFL Dyfet GA Parik, you have the floor...
|
|
MikeW50 Phil, when we are ready for beta testers, I will post a message in
|
|
the Byte
|
|
MikeW50 Works inductry connection area. I would be happy to have you help
|
|
test, but
|
|
MikeW50 please remind me then. If I try to take names before we are
|
|
ready, I will
|
|
MikeW50 almost certainly loose some of them. ga
|
|
AFA Parik is there any way to have everything compile to memory? no .root
|
|
files, just
|
|
AFA Parik a final exe file. No fair Phil, you wrote a lot of orca products.
|
|
:-)
|
|
AFA Parik ga
|
|
MikeW50 Sure -- use the +m flag. For example,
|
|
MikeW50 run +m myfile.asm
|
|
MikeW50 will compile to memory.
|
|
AFA Parik It still keeps a .root file though.
|
|
MikeW50 alias run run +m
|
|
MikeW50 will make it the default for your system. ga
|
|
MikeW50 No, with run +m, you don't get a .root file with any of te ORCA
|
|
languages.
|
|
MikeW50 APW and APW C don't support compile to memory, so they ignore the
|
|
+m flag.
|
|
MikeW50 ga
|
|
AFA Parik ok, musta been a old .root file hanging around. thanks (again
|
|
:)
|
|
Coach101 Hi Jim
|
|
Coach101 Mike, does #pragma cda work
|
|
MikeW50 Yes. Keep in mind, though, that CDAs are limited to 256 bytes of
|
|
stack space.
|
|
MikeW50 You have to be real careful how you write them. ga
|
|
AFL Dyfet GA Dave...
|
|
Dave Lyons CDAs are free to *allocate* stack space, which they can typically
|
|
do if GS/OS
|
|
Dave Lyons is around (not under P8, though). There are a couple tricky
|
|
things--how many
|
|
Dave Lyons ppl would like to see some sample code illustrating this? (I have
|
|
some code
|
|
Dave Lyons working, but it could use some cleaning-up.) ga
|
|
Doctor Why (I'd like to see it)
|
|
AFA Parik me
|
|
MikeW50 Dave, I linked DTS about this one, too. I believe you answered my
|
|
link.
|
|
Dave Lyons Yes, that was me. I've worked with the issue some more since
|
|
then, but my
|
|
MikeW50 I was having trouble getting this to work, and you suggested I try
|
|
a way out.
|
|
Dave Lyons answer at the time was correct. My code may currently be doing
|
|
some more
|
|
MikeW50 Unfortunately, there was no garantee that the way would be
|
|
supported in the
|
|
Dave Lyons work than it *needs* to--I'm preserving and restoring the whole
|
|
page-1 stack,
|
|
Dave Lyons which may be redundant.
|
|
MikeW50 future. Does your sample code represent a portable way to do
|
|
CDAs? If not,
|
|
Coach101 me
|
|
MikeW50 I can;t put it into a commercial compiler.
|
|
MikeW50 ga
|
|
Dave Lyons I believe my current approach will always work; it may be being
|
|
*more* careful
|
|
Dave Lyons than it needs to be; feel free to re-link me on it & that'll force
|
|
me to get
|
|
Dave Lyons all my facts straight & be able to show a presentable, supported
|
|
method to
|
|
Dave Lyons the world. (ga)
|
|
MikeW50 But does it represent a way that is officially supported by Apple?
|
|
I don't
|
|
MikeW50 want to get burned by having every CDA written with ORCA/C fail in
|
|
some
|
|
MikeW50 future OS. People would rightly blame me for that. ga
|
|
AFL Dyfet GA Jim...
|
|
Dave Lyons (Let's let Jim M talk: )
|
|
JimMensch Well, We have always supported CDA's and NDA's making memory
|
|
manager calls
|
|
JimMensch this includes asking for extra memory for stack and direct page
|
|
space
|
|
JimMensch The only drawback is that at CDA time (this does not apply to NDA
|
|
time) no memory compaction
|
|
JimMensch can take place (or at least be relied on since some times CDA's
|
|
are called from interupt and sometimes
|
|
JimMensch not). So, if you want you could put a CDA header that always
|
|
*tries* to allocate some direct page
|
|
JimMensch and stack then calls back the C or pascal routines whith the stack
|
|
swapped in.
|
|
MikeW50 I understand, Jim. The problem isn't GETTING the memory; I was
|
|
able to do
|
|
Dave Lyons Mike, please re-open this issue w/ DTS, and I'll show the problem
|
|
we were
|
|
JimMensch We will always support this method. I promise.
|
|
MikeW50 that. The problem is that the page 1 stack, which contains the
|
|
original return
|
|
Dave Lyons having to Mensch. (The problem is having the page-1 stack get
|
|
TROMPED on
|
|
Dave Lyons while you're using non-page-1 stack, and this is probably
|
|
resolvable in a
|
|
MikeW50 address and presumably other info, is corrupted if I set S>$200.
|
|
ga
|
|
Dave Lyons better way than what I have so far.)
|
|
JimMensch Mike, simply copy off that return address if you want... (thats
|
|
what I do...)
|
|
Dave Lyons The "clean" solution probably involves the $01/0100 and $01/0101
|
|
stack ptr
|
|
MikeW50 Dave, Jim: I will link you tomorrow. Thanks for the invite.
|
|
:)
|
|
Dave Lyons preservation locations, but I'm not sure.
|
|
JimMensch groovy
|
|
JimMensch ga
|
|
AFA Parik are invisible files hidden? Is there a I flag in access?
|
|
MikeW50 Yes - invisible files are hidden in the 2.0 shell. There is a
|
|
flag to
|
|
MikeW50 see them, though. (I think it is -a, for a reason I can't go into
|
|
now.) ga
|
|
MikeW50 Oh - and the I bit is shown in the flags, i.e. DNBWRI. ga
|
|
AFA Parik ok. bye
|
|
AFL Dyfet Okay, do we have any more questions for tonight?
|
|
AFL Dyfet Well, I would like to thank Mike Westerfield for comming by
|
|
tonight then, and I
|
|
AFL Dyfet guess we are ready to wrap up tonight's conference :)....I hope
|
|
everyone had
|
|
AFL Dyfet fun...
|
|
AFA Gary J Yup! :)
|
|
AFA Gary J (Thanks for coming, Mike)
|
|
Coach101 Thanks for the information and lively discussion(s) Mike.
|
|
ShrinkIt Can I ask a question quick before y'all scatter? (addressed to Jim
|
|
M)
|
|
MikeW50 Thanks for having me. Next time, Dave and I will play catch with
|
|
rotten
|
|
MikeW50 eggs instead of tomatoes. Right , Dave? ;)
|
|
AFA Gary J :)
|
|
JimMensch sure
|
|
Dave Lyons :) Right.
|
|
Coach101 :)
|
|
ShrinkIt Is there any way to position something on the 640 mode screen so
|
|
that it will
|
|
ShrinkIt be scrolled quicker than usual?
|
|
ShrinkIt I'm using a list control that has a custom draw routine and it's
|
|
incredibly
|
|
ShrinkIt slow at scrolling... I remember (vaguely) that you could byte or
|
|
word align
|
|
JimMensch sure make sure the rectangle you are scrolling starts on a
|
|
multiple of 4 pixels and always scroll
|
|
MikeW50 (As always, if you think of more ?s for me, you can find me in the
|
|
Byte Works
|
|
JimMensch a multiple of 4 pixels...
|
|
ShrinkIt the edges of the box and the scroll routine would go faster?
|
|
MikeW50 industry connection area.)
|
|
MikeW50 See 'ya 'round.
|
|
JimMensch get that?
|
|
ShrinkIt Jim, is that noticably faster? (yeah, got it)
|
|
Dave Lyons If the scrolling is vertical, it doesn't matter if it's a multiple
|
|
of 4 or
|
|
Dave Lyons not, right?
|
|
A2GS Could use the fast move routine via shadowing and the stack.
|
|
ShrinkIt That's the scrolling I'm talking about... up 'n down...
|
|
ShrinkIt This is in QD II, albert... :-) (a2gs)
|
|
JimMensch if ya does it right then horizontal scrolling will be faster
|
|
Dave Lyons Mensch: does aligning by words (8 pixels in 640 mode) ever
|
|
increase
|
|
A2GS Using the tools? I thought you were using custom routines.
|
|
JimMensch If its vertical scrolling your doing then it will not be much
|
|
faster
|
|
Dave Lyons performance over aligning by bytes? (currently)
|
|
ShrinkIt (Ie, I have a box with stuff in it... a list) --- is there ANY
|
|
EASY way to
|
|
ShrinkIt get it to go quicker?
|
|
JimMensch But at that time you can also set bit 15 of the master SCB when
|
|
you start quickdraw and then
|
|
JimMensch you should scroll about 20% faster
|
|
JimMensch Dave, nope.
|
|
ShrinkIt Let me amend that to any QUICK way, programming wise. I don't
|
|
care if it's
|
|
Dave Lyons (thanks)
|
|
ShrinkIt hard.. I can handle it..
|
|
JimMensch sure, set bit 15 of the master SCB on QD startup...
|
|
SteveSand ShrinkIt.. I had the same problem... I solved it by (re)drawing
|
|
only what was
|
|
A2GS Oh, a tough guy :)
|
|
SteveSand on the screen.
|
|
ShrinkIt Jim, I'm already using bit 15 and the fastport bit. It's still
|
|
way slow.
|
|
JimMensch using the list manager???
|
|
Dave Lyons What are you drawing, Andy?
|
|
Dave Lyons (Text, etc/)
|
|
ShrinkIt yes, using the list manager or tweaking QD2 somehow...
|
|
JimMensch if using the list manager its always gonna be slow
|
|
ShrinkIt text, dave... just a line of text which shows the current entry in
|
|
an archive,
|
|
JimMensch the list manager is not known for its lightning speed
|
|
ShrinkIt how large it is (in bytes), it's % of original size, and it's
|
|
filetype.
|
|
Dave Lyons Mensch, I believe he's talking about Standard File, which uses the
|
|
List
|
|
Dave Lyons Manager.
|
|
ShrinkIt The list manager is driven by QDII, no, Jim?
|
|
JimMensch Also, if you are drawing text, then also make sure that your
|
|
member height is at least 1 pixel larger
|
|
JimMensch than it needs to be
|
|
ShrinkIt No, dave, I open a list on the screen with the contents of an
|
|
archive .. like
|
|
JimMensch The list manager uses quickdraw.
|
|
ShrinkIt what stuffit does...
|
|
ShrinkIt SOOOooooo... is there any way to get the List manager to go faster
|
|
by
|
|
JimMensch But, when it sets up its clipping area to redraw the new text that
|
|
scrolls in, it will sometimes be to
|
|
JimMensch too small to use fastfont for printing.
|
|
ShrinkIt (quickly) patching quickdraw to scorll UP and DOWN faster?
|
|
ShrinkIt (listening... scribbling...)
|
|
JimMensch Shrinkit, the scrollrect is not whats slowing you down, its the
|
|
member redraw...
|
|
Dave Lyons Andy, do you know whether most of the time is taken by scrolling,
|
|
by
|
|
Dave Lyons drawing your new line, or something else?
|
|
JimMensch and the member redraw routine calls drawstring, which is probably
|
|
clipped tight to the height of the
|
|
ShrinkIt Dave -- pretty even split. A ton of time is spent by scrolling,
|
|
it's horribly
|
|
Dave Lyons You might try keeping cached bitmap images of the lines around.
|
|
ShrinkIt slow, although the text draw isn't fast, either...
|
|
JimMensch line. which will cause fastfont to always think that it needs to
|
|
draw the slow way.
|
|
Dave Lyons Is the scrolling done with a ScrollRect call, or what? I don't
|
|
understand
|
|
Dave Lyons why it should be slow.
|
|
JimMensch yes, but the scrolling time would be fine if the redraw wasn't
|
|
happening....
|
|
ShrinkIt I don't know how the list manager does its scrolling... but I
|
|
could cache the
|
|
JimMensch scrolling is done with a scrollrect, its not slow, its the
|
|
redrawing of the members...
|
|
ShrinkIt bitmaps on the stuff... but the scrolling would still suck.
|
|
JimMensch the other way to do it is a custom drawing routine that reblits
|
|
the member text instead of calling
|
|
JimMensch drawstring
|
|
Dave Lyons (I wish I'd said that. :-)
|
|
JimMensch Shrinkit, scrollrect works fine everywhere else...
|
|
ShrinkIt I didn't say it didn't work fine (name's andy) -- it just works
|
|
slowly, that's
|
|
ShrinkIt all... :-)
|
|
SteveSand I think Coach101 gave me the idea of using GetContentOrigin to get
|
|
the
|
|
JimMensch :) Not for me... it works pretty fast, bout how wide is your
|
|
list?
|
|
ShrinkIt about 320 pixels in 640 mode....
|
|
SteveSand position of the scroll bar and then just redrawing what would show
|
|
on the scree
|
|
JimMensch hmmm and how tall is the list
|
|
AE PhilM Andy, you could also write a custom scroll rect....have the rect
|
|
byte aligned
|
|
SteveSand n... It speeded mine up by LOTS!
|
|
AE PhilM on both sides then it is a simple block move...you could optimize
|
|
that also
|
|
Dave Lyons (Steve, I believe Andy's already redrawing only the line that
|
|
needs to be
|
|
AE PhilM using lda sta combos..
|
|
Dave Lyons redrawn.)
|
|
ShrinkIt (folks, I'm using the list manager...)
|
|
AE PhilM You would only have to patch scroll rect for the time the list is
|
|
up.
|
|
A2GS Going back to my original suggestion of shadowing and the
|
|
stack....:-)
|
|
JimMensch how tall is the list???
|
|
Coach101 How slow is slow Andy?
|
|
ShrinkIt 12 members... 122 pixels..
|
|
A2GS But I guess Andy is certain he's using the List Manager.
|
|
ShrinkIt there's about a 1/2 to 3/4 second pause between stuff scrolled
|
|
into the view
|
|
JimMensch Well tell ya what andy, let me give a list that size a try and see
|
|
how it comes out, I will let ya
|
|
JimMensch know next week.
|
|
JimMensch 'bout 100 members an ok test?
|
|
ShrinkIt (make sure you print stuff all the way across and do something
|
|
significant
|
|
ShrinkIt printing wise to make it somewhat near what I'm doing...)
|
|
ShrinkIt :-)
|
|
Dave Lyons Andy, do you know how many times your list-draw routine is getting
|
|
called
|
|
JimMensch ok.
|
|
Dave Lyons for each scroll? Should be 1, but if it's more that might explain
|
|
some of
|
|
Dave Lyons the delay.
|
|
ShrinkIt (list draw is getting called once every time the thing does
|
|
something... ummm
|
|
ShrinkIt why would it be getting called twice?)
|
|
Dave Lyons I was just trying to eliminate the possibility that the List
|
|
Manager is
|
|
JimMensch well, I am off to try this out.. see ya all next week
|
|
Dave Lyons making superflous calls to ask you to draw things that are getting
|
|
clipped
|
|
A2GS Bye Jim
|
|
ShrinkIt Jim -- 100 members is fine... just do something significant time
|
|
wise in the
|
|
ShrinkIt itemDraw routine...
|
|
Dave Lyons completely out of view. I assume it's not, but I wondered if
|
|
you'd checked
|
|
Dave Lyons (like by making your list-draw routine SysBeep once).
|
|
ShrinkIt No, dave, hadn't checked... just thought I'd assume that It was
|
|
getting called
|
|
ShrinkIt once... I'll check that...
|
|
Dave Lyons ok
|
|
AE PhilM Shrinkit....we have a logic analyzer with performance analysis
|
|
software...we
|
|
Coach101 Andy, If I have to do something significant in the line draw, why
|
|
not
|
|
AE PhilM could look at it with that and see exactly where the time is being
|
|
spent.
|
|
Coach101 look at what I am doing to draw instead of looking at list
|
|
manager?
|
|
ShrinkIt phil -- I don't think it's THAT important. I'd only use a logic
|
|
analyzer on
|
|
ShrinkIt live or die type code... maybe the packing algorithms... :-)
|
|
AE PhilM Well it's pretty easy to use and setup...if you like just send a
|
|
disk to John
|
|
AE PhilM Stephens or myself and we'll be happy to look at it.
|
|
A2GS Phil, if you've got an extra analyzer w/software I'll be happy to
|
|
take it off
|
|
A2GS your hands :)
|
|
ShrinkIt (Phil, it looks pretty good using a TWGS, though.. :-)
|
|
AE PhilM :)
|
|
AE PhilM Really, I'd be interested in finding out myself where the time
|
|
split is..
|
|
AE PhilM between scroll-rect or the itemdraw routin.
|
|
Coach101 Thanks for an entertaining and provocative evening folks.....
|
|
AE PhilM (or elsewhere) ya never know....1/2 second seem like a long time
|
|
to me
|
|
ShrinkIt I'd be willing to think that it's about 3/4 itemdraw and 1/4
|
|
scroll...
|
|
Coach101 See you all next week....
|