DTM: Can anyone remember?
M.R. Hoare
I had managed to lose the documentation for the following view
commands. Has anyone any idea what they were meant to do?
v 0:$v(9,6,-3):string ;I think this may remap a colour or attribute
array
s x=$v(0,$v(9,6,-3),16) ; this might save a default array
v 0:$v(1024,94,-3)+8:$c(0) ;these may be something to do with either
v 0:$v(1024,94,-3)+8:$c(2) ;keyboard or printing (2 is the default)
Thanks very much for any help!
MaryRose Hoare
Charlie-Boo
According to the DTM-PC Reference Manual and Operations Guide 9.1.20
VIEW Command: "The VIEW command modifies the content of memory. Its
use is currently restricted to DataTree system programmers."
Does that help? I guess I should ask if you're a DataTree systems
programmer. Or if you know if DataTree ever did document it.
Charlie Volkstorf
PS I recently had the last known copy of my "Handbook of Efficiency
Techniques" scanned into a PDF file (after repeated urgings from
cyberfriends.) If you'd like a copy ...
Rob Tweed
>
>PS I recently had the last known copy of my "Handbook of Efficiency
>Techniques" scanned into a PDF file (after repeated urgings from
>cyberfriends.) If you'd like a copy ...
Why not make it available to even more cyberfriends, Charlie, by
uploading it to our Utility Library - see www.mgateway.com
---
Rob Tweed
M/Gateway Developments Ltd
Global DOMination with eXtc : http://www.mgateway.tzo.com
---
Rob Tweed
I'd guess that some of the people at Partners must know - they're
still big DTM users. Alternatively I'd see if one of the DTM guys at
InterSystems could find out for you.
On Tue, 01 Apr 2003 17:23:12 +0200, M.R. Hoare <ombr...@planet.nl>
wrote:
---
John K Mitchell
Regards
John
In message <ta2l8v0bc35ao73jg...@4ax.com>, Rob Tweed
<rtw...@imtcons.demon.co.uk> writes
--
John K Mitchell
Forest Software Ltd
Web sites for the smaller business and charity.
Tel : 0870 747 4943
Fax : 0870 747 4942
M.R. Hoare
Thanks for the info. No I'm not a Datatree system programmer
(sometimes wish I were). What I lost in the second example was
Datatree's message advising this patch (I've found the source of the
first one and someone emailed me to confirm as he had the same code
for that purpose). Since I do a lot of raw printing it may relate to
that.
A handbook of efficiency techniques certainly sounds interesting. How
would I get a copy? Do you cover much on internationalisation
(European languages only), extended (>256) character sets, techniques
for dealing with large external files and processing binary and
unicode data? And yes, I do know there are better languages for this
but they dont have embedded databases and the cost of a rewrite would
anyhow be prohibitive.
MaryRose Hoare
Ben Bishop
M.R. Hoare <ombr...@planet.nl> wrote:
>On 1 Apr 2003 14:07:46 -0800, ch...@aol.com (Charlie-Boo) wrote:
>
>>PS I recently had the last known copy of my "Handbook of Efficiency
>>Techniques" scanned into a PDF file (after repeated urgings from
>>cyberfriends.) If you'd like a copy ...
>
>would I get a copy? Do you cover much on internationalisation
>(European languages only), extended (>256) character sets, techniques
>for dealing with large external files and processing binary and
>unicode data? And yes, I do know there are better languages for this
>but they dont have embedded databases and the cost of a rewrite would
>anyhow be prohibitive.
Beyond there being a _reason_ for it being the "last known copy", note
that _tHoMET_ is from the early-early 1980s (late 1970s?) and was out of
date/inaccurate within months of it being published. Such efficiency
techniques of 'use one letter variable names because they are
special-cased for faster lookups' may have been true for some early
versions of MUMPS, but by 1982 I know _explicitly_ that neither of
the then-modern versions of MUMPS that "technique" was directed act did
that any more.
However, having a PDF version might be fun for a laugh now and then.
Ben Bishop
25 years of $PIECE (so far)
Charlie-Boo
> >On 1 Apr 2003 14:07:46 -0800, ch...@aol.com (Charlie-Boo) wrote:
> >
> >>PS I recently had the last known copy of my "Handbook of Efficiency
> >>Techniques" scanned into a PDF file (after repeated urgings from
> >>cyberfriends.) If you'd like a copy ...
> >
> >A handbook of efficiency techniques certainly sounds interesting. How
> >would I get a copy?
Just drop me a line - C H V O L at A O L dot C O M and tell me why you
need it!
> Beyond there being a _reason_ for it being the "last known copy",
I gave away all my other ones.
> note that _tHoMET_ is from the early-early 1980s (late 1970s?) and was out of
> date/inaccurate within months of it being published.
Not so. Examples? Also note that only 5% of the techniques are
implementation-specific, and those few are segregated into the
appendix.
(A few years after it came out, MUG had me bring it up to date, and
there was virtually nothing to change!)
> Such efficiency
> techniques of 'use one letter variable names because they are
> special-cased for faster lookups' may have been true for some early
> versions of MUMPS,
Where do I say that? You must have me confused with someone else!
> but by 1982 I know _explicitly_ that neither of
> the then-modern versions of MUMPS that "technique" was directed act did
> that any more.
The other person who tried to bad-mouth my classic text (the German
guy who wrote the neat puzzle columns) said the same thing - they're
implmentation-specific, out of date, blah-blah-blah. All of that
either applies to no more than 2 or 3 of the 125 techniques (and is
segregated) or is just plain wrong. (He also had no true examples.)
Look at the book - what do I talk about? How to design globals, the
most efficient ways to update these globals, arranging logic to avoid
time-consuming processes - all generic techniques for minimizing the
number of machine cycles your MUMPS applications are consuming.
Now when does that become obsolete?
> However, having a PDF version might be fun for a laugh now and then.
>
> Ben Bishop
> 25 years of $PIECE (so far)
"Charlie's book is still the best source for efficiency techniques in
MUMPS."
- Fred Hiltz
"It's well-known that (Charlie's book) is a standard resource for
MUMPS programmers."
- Karl at Lovelace
Charlie Volkstorf
Denver Braughler
> The other person who tried to bad-mouth my classic text ...
> said the same thing - they're
> implmentation-specific, out of date, blah-blah-blah. All of that
> either applies to no more than 2 or 3 of the 125 techniques (and is
> segregated) or is just plain wrong. (He also had no true examples.)
Right there is a good reason to post your text.
> Look at the book - what do I talk about?
I don't have a copy.
> How to design globals, the
> most efficient ways to update these globals, arranging logic to avoid
> time-consuming processes - all generic techniques for minimizing the
> number of machine cycles your MUMPS applications are consuming.
> Now when does that become obsolete?
When computers become so fast that no one cares.
Rob Tweed
<nos...@localnet.com> wrote:
>Charlie V wrote:
>> The other person who tried to bad-mouth my classic text ...
>> said the same thing - they're
>> implmentation-specific, out of date, blah-blah-blah. All of that
>> either applies to no more than 2 or 3 of the 125 techniques (and is
>> segregated) or is just plain wrong. (He also had no true examples.)
>
>Right there is a good reason to post your text.
>
>> Look at the book - what do I talk about?
>
>I don't have a copy.
As I've said, our Utility Library awaits you Charlie - your
opportunity to spread your gospel ....and fame :)
Rob
M.R. Hoare
You keep on saying about the speed of modern computers being 'so fast
no one cares'. Well that is probably true in a lot of areas but not
everywhere. And it isnt only M applications like mine that can have
timing problems, we had to scrap using pdf for part of our stuff
because the conversion from html on a fast Linux server was far too
slow to be usable. When I said my application ran too slowly, one of
my colleagues asked if I'd ever tried loading my kind of document into
Word...
If even one of Charlie's techniques turned out to be useful or just
gave me a new idea it could save a lot. Mind you, I'd gain more by
using C in the worst bits but I'm no C programmer. What I need is not
so much a blindingly fast database, it's a blindingly fast interpreter
with acceptable database speed.
MaryRose Hoare
On Thu, 03 Apr 2003 16:35:13 -0500, Denver Braughler
<nos...@localnet.com> wrote:
Denver Braughler
> You keep on saying about the speed of modern computers being 'so fast
> no one cares'.
I did not say that.
In American English, the construction "when does ... become" ordinarily refers to a hypothetical (or future).
Charlie did not ask, "When dID that become obsolete?"
I did not reply, "When computers becAme so fast that no one cared."
So in your words, that would be 'modern computers beCOMing so fast that no one cares about efficiency'.
> Well that is probably true in a lot of areas but not everywhere.
I agree.
> And it isn't only M applications like mine that can have
> timing problems, we had to scrap using pdf for part of our stuff
> because the conversion from html on a fast Linux server was far too
> slow to be usable.
I agree.
> When I said my application ran too slowly, one of
> my colleagues asked if I'd ever tried loading my
> kind of document into Word...
Are you talking about *Microsoft* Word?
(Please pardon my sarcasm.)
> If even one of Charlie's techniques turned out
> to be useful or just gave me a new idea it could
> save a lot.
I'm sorry that you got the idea to that I was belittling Charlie's work.
I was not.
I have always been one to lay out expressions to use the least number of parentheses in an interpreted environment.
I use commas instead of ampersands for IF arguments whenever possible.
I move loop-invariant expressions/calculations outside the loop.
I store the result of recurring intermediate expressions into a temp variable.
And so on...
So I do pay attention to many points of efficiency of which this barely scratches the surface.
> Mind you, I'd gain more by using C in the worst bits
> but I'm no C programmer. What I need is not so much
> a blindingly fast database, it's a blindingly fast interpreter
> with acceptable database speed.
Yours is not a typical user-interactive application.
I don't know that you need to be a C programmer.
However, I think your analysis is correct.
You might be able to get a C library that you can invoke for the functionality you need without your having to write the code yourself.
If it takes 100 seconds with M, but one second with C, then the interpreter is your bottleneck and probably nothing that Charlie or I say can change that.