Re: A83: Menus & ZMENULIB
[Prev][Next][Index][Thread]
Re: A83: Menus & ZMENULIB
I could, but that would make the format more complicated for my taste (both
in coding and usage).
I would also have to make a new shell, I bet you'd all love that wouldn't
you :P
Joe Wingbermuehle
http://www.usmo.com/~joewing/
-----Original Message-----
From: Alan C Johnson <benjamin99@juno.com>
To: assembly-83@lists.ticalc.org <assembly-83@lists.ticalc.org>
Date: Monday, October 05, 1998 5:17 PM
Subject: Re: A83: Menus & ZMENULIB
>
>Of course you could just look it up once, store the pointer, and use
>offsets to get to a specific routine
>
>>For using ZLib having to look up "ZLIB" five times in the vat is kind
>>of
>>silly, but for ZGFXL it isn't so bad since there are only 2 routines.
>>That's one of the reasons why ZLib isn't written so well, most of the
>>routines aren't big enough to deserve a library.
>>
>>Joe Wingbermuehle
>>http://www.usmo.com/~joewing/
>>
>>-----Original Message-----
>>From: Linus Akesson <lairfight@softhome.net>
>>To: Joe Wingbermuehle <assembly-83@lists.ticalc.org>
>>Date: Monday, October 05, 1998 1:05 PM
>>Subject: Re: A83: Menus & ZMENULIB
>>
>>
>>>
>>>On 05-Oct-98, Joe Wingbermuehle wrote:
>>>
>>>>I agree with Linus on libraries for shell-independent programs,
>>especially
>>>>since I stole the idea from my vast array of ancient programming
>>books.
>>The
>>>>term library was founded not too very long ago, however, because the
>>old
>>>>name is "shared files."
>>>
>>>sorry, my fault. =)
>>>
>>>> Well, my guess is that the change came about
>>>>between 1974 and 1975 since I have a book from 1974 that refers to
>>them as
>>>>"shared files" and a book from 1975 that refers to them as
>>"libraries."
>>hehe
>>>>They all agree that libraries are meant to conserve space while
>>allowing
>>>>programs to use code that is optimized for speed though.
>>>
>>>>Anyway, here's why there will always be compatibility problems: as
>>long as
>>>>computers exist, I will write for a particular system/os/shell that
>>I like
>>>>and others will do likewise. So what? Deal with it.
>>>
>>>>And lastly, when I say I would have changed the library format, I
>>meant
>>>>from:
>>>>.db "ZLIB",0,0,0,0,lib1,vec1
>>>>to:
>>>>.db "ZLIB",0,lib1,vec1
>>>>That and the way I wrote ZLib (which isn't terribly excessive
>>anyway...).
>>>>So you waste 3 bytes every time you use ZLib; I bet you waste more
>>looking
>>>>up that long name ZMENULIB in the vat.
>>>
>>>>Joe Wingbermuehle
>>>>http://www.usmo.com/~joewing/
>>>
>>>Yep, that's true. But the thing I don't like about your system is
>>that when
>>>you want 5 functions from one library you have to specify the name of
>>that
>>>library five (!) times. WHY?
>>>
>>>Linus
>>>
>>>>-----Original Message-----
>>>>From: Linus Akesson <lairfight@softhome.net>
>>>>To: assembly-83@lists.ticalc.org <assembly-83@lists.ticalc.org>
>>>>Date: Sunday, October 04, 1998 6:03 AM
>>>>Subject: Re: A83: Menus & ZMENULIB
>>>
>>>
>>>>>
>>>>>Library, n.: A separate file containing program code meant to be
>>shared
>>>>among
>>>>>several applications.
>>>>>I know that the word library is often used to refer to a sos
>>library, but
>>>>>would you believe me if a said that the computer term "library"
>>was
>>founded
>>>>>somewhat before sos was written? =)
>>>>>
>>>>>You say that using only sos will cut back on compatibility
>>problems. My
>>>>reply
>>>>>is that not using any shell at all would extinguish compatibility
>>problems.
>>>>>
>>>>>And I don't like the way libraries are handled in sos, I mean, even
>>Joe
>>has
>>>>>admitted that he wouldn't have used that method if he'd written sos
>>now.
>>>>>
>>>>>Linus
>>>>>
>>>>>On 04-Oct-98, Jkhum98@aol.com wrote:
>>>>>
>>>>>>In a message dated 10/03/98 6:04:03 PM, lairfight@softhome.net
>>writes:
>>>>>
>>>>>>>ZMENULIB is a 395 bytes big file, containing ready-to-use menu
>>code.
>>>>>>>It is NOT a sos library. Instead, you have to look the program
>>up, and
>>>>>>>jump to the beginning of it. This way, it can be used by
>>>>shell-independent
>>>>>>>programs (AND sos programs of course).
>>>>>
>>>>>>Hey Linus, nice job on this, but I think its kind of contradictory
>>to
>>make
>>>>>>this shell-independent, and call it a _Library_ at the same
>>time... =P
>>I
>>>>>>personally think that SOS should progress as the main shell (I
>>think
>>other
>>>>>>people besides Me and Joe use this shell), and this shell is more
>>useful
>>>>than
>>>>>>Ashell or running programs from the OS, because of the obvious
>>reason of
>>>>>>Library Usage... Although, you have a point that any of these
>>methods of
>>>>>>running programs should be able to use your routine, but why not
>>create
>>a
>>>>SOS
>>>>>>library for it, and then people just start coding for SOS... =P I
>>know
>>I
>>>>>>shouldn't be bias to anything but SOS, and that it shouldn't
>>monopolize
>>>>the
>>>>>>shell usage, but having One shell would cut back on compatibility
>>problems
>>>>>and
>>>>>>competition, for example, look at the shell wars or the 85 and 86
>>(the
>>82
>>>>>>also, but Ash 3.1 will soon resolve that) and think of how
>>Plusshell and
>>>>>>DoorsOS Compatibility for the 89 at this time are causing
>>conflicts...
>>Is
>>>>it
>>>>>>really Morally wrong to have a Specific shell for a calculator
>>and
>>>>eliminate
>>>>>>competition? Its not competition for money but more like
>>programmer and
>>>>shell
>>>>>>popularity (y'all know it is), but it would make the Users of all
>>the
>>>>calcs
>>>>>>(Including the Calculator-Adept Programmers, and the "Calculator
>>Impaired"
>>>>>>people at school who depend on us for games) it would make
>>everything a
>>>>>little
>>>>>>bit easier to focus on one Shell... Whew, a lot of Preaching in
>>there,
>>did
>>>>>>that have "ticalc.org News Article" potential, since it was a
>>whole lot
>>of
>>>>>>crap...? Well anyways, I'm sure Ill get a lot of negative
>>opposition on
>>>>this,
>>>>>>Bring It On! =P
>>>>>>--Jason K.
>>>>>
>>>>>
>>>
>>>
>>>
>>
>>
>
>___________________________________________________________________
>You don't need to buy Internet access to use free Internet e-mail.
>Get completely free e-mail from Juno at http://www.juno.com
>or call Juno at (800) 654-JUNO [654-5866]
>