In article , JF Mezei writes:
> Anyone know about the odds of getting TPU/EVE ported to MAC OS-X ?
>
> Isn't it time for the source code of this dead product to be released ?
>
> Since they haven't improved TPU in decades, wouldn't it be fair to state
> that the product is dead ?

Check with a/Soft to see if nu/TPU is available for that platform.
They wrote their own "TPU" and ported it to many platforms. It would
ingest the same TPU source as DEC's TPU (TPU is also a programming
language designed for editor writing), and they included EVE
recompiled from DEC's EVE (written in TPU).

As for DEC's TPU engine and compiler, it's probably written in BLISS
so not yet highly portable.

As many products in many industries have proven, being stable is not
the same as being dead.

Bob Koehler wrote:

> As many products in many industries have proven, being stable is not
> the same as being dead.

Depends on your definition on dead and stable. Mine is defined around the
German proverb "Stillstand ist Rückschritt" - which translates to "To stand
still is to go back" (because everybody else around you move foreward).

Which in turn means that to keep stable you have to move foreward at a
moderate rate and if you don't move foreward at all you are - or soon will
be - dead.

Martin
--
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

In article <1615375.22NOzJ5N3m@linux1.krischik.com>, Martin Krischik writes:
> Bob Koehler wrote:
>
>> As many products in many industries have proven, being stable is not
>> the same as being dead.
>
> Depends on your definition on dead and stable. Mine is defined around the
> German proverb "Stillstand ist Rückschritt" - which translates to "To stand
> still is to go back" (because everybody else around you move foreward).

Since my EVE based editor is still the best I've had, the others are
still catching up.

I only know of one feature, which I use on rare ocasion, that my
EVE based editor doesn't have that would be nice to have. If I
really wanted it that much, I'd probably write some TPU so I could
have it, just like some of my coworkers write some elisp to have the
features they want in thier emacs based editors.

Of course, we could go around and around on the religions of which
editor is best, but you can't convince me that we aren't in an
it-ain't-broke-don't-fix-it situation with TPU.

If you don't have the TPU code to do your favorite editor trick,
that's not TPU's fault.

Bob Koehler wrote:
> but you can't convince me that we aren't in an
> it-ain't-broke-don't-fix-it situation with TPU.

Before people gave up on TPU, there were often requests to add features
to it. One that was often made but never implemented was the ability for
TPU code to translate logical names (or perhaps even set them) as well
as symbols. It was never implemented.

Since people have given up on TPU, they no longer send in requests for
improvements, so VMS management applaud themselves for having made the
right decision to offshore TPU maintenance since nobody wants any
changes to it.


The best thing that could happen to Microsoft is if it inherited VMS
management. They would be great at finding excuses/reasons to NOT
implement something in Windows. And Windows would become letharigic like
VMS.

JF Mezei wrote:
> Bob Koehler wrote:
>> but you can't convince me that we aren't in an
>> it-ain't-broke-don't-fix-it situation with TPU.
>
> Before people gave up on TPU, there were often requests to add features
> to it. One that was often made but never implemented was the ability for
> TPU code to translate logical names (or perhaps even set them) as well
> as symbols. It was never implemented.
>
>[snip]

erm, see TPU procedure CALL_USER? It's trivial to implement logical
name and symbol functions using a user written program.



Jim.
--
www.eight-cubed.com

Jim Duff wrote:
> erm, see TPU procedure CALL_USER? It's trivial to implement logical
> name and symbol functions using a user written program.

Yeah, standard answer for an operating system that won't see user level
improvements: WRITE YOUR OWN.


If TPU had built in access to logicals and symbols as had been requested
many times back where there was still some hope of seeing improvements
made, it would make the TPU language much more versatile and it might
have made the language far more popular to build apps other than just
customizing your editor.

Lets face it, the only "priorities" left at VMS management is ensuring
VMS runs and supports the hardware that HP tells it to support. Any
other improvements are just icing on the cake if they have time for it.
And you don't see much improvements to any X applications on VMS, mostly
because they were declared "mature" long ago and maintenance shifted to
another continent where their only role is to compile and test it for
each new version.

Not happy that I say these things ? Tough luck. It is reality. Wake up
and smell the coffee.

In article <1615375.22NOzJ5N3m@linux1.krischik.com>,
Martin Krischik wrote:

> Bob Koehler wrote:
>
> > As many products in many industries have proven, being stable is not
> > the same as being dead.
>
> Depends on your definition on dead and stable. Mine is defined around the
> German proverb "Stillstand ist Rückschritt" - which translates to "To stand
> still is to go back" (because everybody else around you move foreward).
>
> Which in turn means that to keep stable you have to move foreward at a
> moderate rate and if you don't move foreward at all you are - or soon will
> be - dead.
>

Software is usually a compromise. Getting it right can be knowing when
to stop.

--
Paul Sture

Sue's OpenVMS bookmarks:
http://eisner.encompasserve.org/~stu...bookmarks.html

> >[snip]
>
> erm, see TPU procedure CALL_USER? It's trivial to implement logical
> name and symbol functions using a user written program.
>
> <http://h71000.www7.hp.com/doc/73fina...tml#6020built1
> _12>
>
> Jim.

LOL! Whatever else TPU may be- "trivial" is definitely the wrong word.
"Easy" would not work there either --- "arcane" comes to mind.

Rexx and Perl and so forth can be just as arcane though.

-Paul

P. Sture schrieb:
> In article <1615375.22NOzJ5N3m@linux1.krischik.com>,
> Martin Krischik wrote:
>
>> Bob Koehler wrote:
>>
>>> As many products in many industries have proven, being stable is not
>>> the same as being dead.
>> Depends on your definition on dead and stable. Mine is defined around the
>> German proverb "Stillstand ist Rückschritt" - which translates to "To stand
>> still is to go back" (because everybody else around you move forward).
>>
>> Which in turn means that to keep stable you have to move forward at a
>> moderate rate and if you don't move forward at all you are - or soon will
>> be - dead.
>>
>
> Software is usually a compromise. Getting it right can be knowing when
> to stop.

I think you missed the point of "Stillstand ist Rückschritt". You can't
stop because everybody else moves.

Or to put it different: There are two ways of stopping:

1) Absolute - then the majority of the industry moves passed you and you
soon are left behind.
2) Relative - You move forward at the average rate of the rest of the
industry.

And you can look at it any way you like: If you choose option 1 then you
will become obsolete - depending on which part of the industry it will
happen in 5, 10 or 20 years. But it will happen.

As for the topic: Our two newest team members have chosen Vim over Eve
or LSEdit.

Martin
--
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Bob Koehler schrieb:

> If you don't have the TPU code to do your favorite editor trick,
> that's not TPU's fault.

Then do tell me how to implement syntax highlight in an editor language
without colour support.

Even syntax folding which is supported by lsedit is not at all that
useful without a 2nd colour to highlight the folded lines.

Martin
--
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

In article <46bada06@news.post.ch>, Martin Krischik writes:
> Bob Koehler schrieb:
>
>> If you don't have the TPU code to do your favorite editor trick,
>> that's not TPU's fault.
>
> Then do tell me how to implement syntax highlight in an editor language
> without colour support.

DON'T! I hate it when editors change the colors to illegible.

In article <46bad8c2$1@news.post.ch>,
Martin Krischik wrote:

> P. Sture schrieb:
> > In article <1615375.22NOzJ5N3m@linux1.krischik.com>,
> > Martin Krischik wrote:
> >
> >> Bob Koehler wrote:
> >>
> >>> As many products in many industries have proven, being stable is not
> >>> the same as being dead.
> >> Depends on your definition on dead and stable. Mine is defined around the
> >> German proverb "Stillstand ist Rückschritt" - which translates to "To stand
> >> still is to go back" (because everybody else around you move forward).
> >>
> >> Which in turn means that to keep stable you have to move forward at a
> >> moderate rate and if you don't move forward at all you are - or soon will
> >> be - dead.
> >>
> >
> > Software is usually a compromise. Getting it right can be knowing when
> > to stop.
>
> I think you missed the point of "Stillstand ist Rückschritt". You can't
> stop because everybody else moves.
>

No I don't think I missed the point. I'm saying that I'd rather that
OpenVMS Engineering put their efforts into other areas.

> Or to put it different: There are two ways of stopping:
>
> 1) Absolute - then the majority of the industry moves passed you and you
> soon are left behind.
> 2) Relative - You move forward at the average rate of the rest of the
> industry.
>
> And you can look at it any way you like: If you choose option 1 then you
> will become obsolete - depending on which part of the industry it will
> happen in 5, 10 or 20 years. But it will happen.

But what constitutes real progress? Given the choice between putting
colours in an editor or improving the BACKUP utility, I'd pick the
latter every time.

> As for the topic: Our two newest team members have chosen Vim over Eve
> or LSEdit.

The choice of an editor is always personal, so if that's what they
prefer, it's fine by me.

--
Paul Sture

Sue's OpenVMS bookmarks:
http://eisner.encompasserve.org/~stu...bookmarks.html

Bob Koehler schrieb:
> In article <46bada06@news.post.ch>, Martin Krischik writes:
>> Bob Koehler schrieb:
>>
>>> If you don't have the TPU code to do your favourite editor trick,
>>> that's not TPU's fault.

>> Then do tell me how to implement syntax highlight in an editor language
>> without colour support.

> DON'T! I hate it when editors change the colors to illegible.

The editor does not decide on any colour at all. I decide:

http://www.vim.org/scripts/script.php?script_id=1538

What I find really disturbing, and what shows the sorrow state of VMS,
is that you thought differently. No user of any other OS would have
thought that way - users of other OS's would have just expected to be
able to change the colours they way they like them. At least for an
editor advanced enough to support syntax highlight.

Martin

--
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

In article <46bc198e$1@news.post.ch>, Martin Krischik writes:
>
>
>Bob Koehler schrieb:
>> In article <46bada06@news.post.ch>, Martin Krischik writes:
>>> Bob Koehler schrieb:
>>>
>>>> If you don't have the TPU code to do your favourite editor trick,
>>>> that's not TPU's fault.
>
>>> Then do tell me how to implement syntax highlight in an editor language
>>> without colour support.
>
>> DON'T! I hate it when editors change the colors to illegible.
>
>The editor does not decide on any colour at all. I decide:
>
>http://www.vim.org/scripts/script.php?script_id=1538
>
>What I find really disturbing, and what shows the sorrow state of VMS,
>is that you thought differently. No user of any other OS would have

You are reading into Bob's statement. He said he doesn't like the
editor changing colors to illegible; he didn't say anything that I
read as implying that the color scheme could not be varied. I have
used editor that change colors of text and I do not like it. It's
turned off if I have a choice.

This is the same thing I find with web sites. People go and look
at a web site and are impressed by the color but where is the con-
tent? The most annoying thing lately is the "flash" animations I
must witness before I enter a site for information. Is there ANY
value in these 'flash' welcomes? In general, I would conclude no!



>thought that way - users of other OS's would have just expected to be
>able to change the colours they way they like them. At least for an
>editor advanced enough to support syntax highlight.

You're complaining about an editor in a discussion of an OS. If
you want to complain about editors, complain about all of the 'vi'
variants in linux to edit various files... like crontab.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

"Well my son, life is like a beanstalk, isn't it?"

http://tmesis.com/drat.html

In article <46bc198e$1@news.post.ch>, Martin Krischik writes:
>
> What I find really disturbing, and what shows the sorrow state of VMS,
> is that you thought differently. No user of any other OS would have
> thought that way - users of other OS's would have just expected to be
> able to change the colours they way they like them. At least for an
> editor advanced enough to support syntax highlight.

I didn't think differently. I don't want my editor to colorize my
code. The first thing I do with Linux is turn off the damn
colorization in ls. I know I can configure both of them, but I want
them off.

If you want TPU to colorize your text, you can write the TPU code to
do it. Yes, it can be done on color capable displays. The fact that
no one has bothered has to do with the value of using a superior
editor and superior programming languages that don't need such crutches.

Paul Raulerson wrote:
>
>>> [snip]
>> erm, see TPU procedure CALL_USER? It's trivial to implement logical
>> name and symbol functions using a user written program.
>>
>> <http://h71000.www7.hp.com/doc/73fina...tml#6020built1
>> _12>
>>
>> Jim.
>
> LOL! Whatever else TPU may be- "trivial" is definitely the wrong word.
> "Easy" would not work there either --- "arcane" comes to mind.
>
> Rexx and Perl and so forth can be just as arcane though.
>
> -Paul
>
>

Arcane as opposed to say, lisp? That's what people are forced to
program in to extend emacs.

And perhaps I should have said "trivial for a programmer that can spend
20 minutes reading the manual". Having never programmed in TPU before
today, that's about how long it took me to figure out how to do this.
(Although my original statement re: trivial was referring to writing the
user routine to perform the logical name translation, the TPU code was
even simpler).

All up, 130 lines of C code (not including comments) and 27 lines of TPU
would be considered trivial for any accomplished programmer.

Conversion of the C code to your preferred language is left as an
exercise for the student.

$create log.c
$deck
#include
#include
#include
#include
#include
#include
#include

#pragma environment save
#pragma extern_model globalvalue
extern unsigned long int tpu$_success;
#pragma environment restore

extern int decc$crtl_init (void);
static int rtl_init = 0;


/************************************************** ****************************/
extern int tpu$calluser (int *int_param,
struct dsc$descriptor *str_param,
struct dsc$descriptor *result_param) {

/*
** Translate, delete, or set a logical name via TPU's CALL_USER
** interface.
**
** If the int_param is zero, the logical name is deleted. If it's one,
** the logical name is set. If it's two, the logical name is translated
** and the equivalence name is returned in result_param.
**
** The str_param contains the logical name to delete or translate, or a
** logical name / equivalence name pair separated by a tilde (~).
**
** Example TPU code to call this routine would be:
**
** ! Get the physical terminal name
** result_string := CALL_USER (2, "TT");
**
** The result string can return three strings other than the equivalence
** name:
**
** SUCCESS indicates the routine deleted or set the logical correctly,
** PARAM_ERROR indicates a parameter error (you didn't set the integer
** parameter to 0, 1, or 2; you passed in a zero length
** string parameter; you passed in a string parameter that
** either did not contain a tilde when you specified "set
** logical"; or the logical or equivalence names exceeded
** 31 ot 255 characters respectively.
** ERROR indicates an unexpected error occurred.
*/

static char *success = "SUCCESS";
static char *error = "ERROR";
static char *param_error = "PARAM_ERROR";
static char *result_p;
static char *p;

static unsigned long int r0_status;
static unsigned long int flags = LNM$M_CASE_BLIND;
static int result_len;
static short int i;
static short int j;

static char log[31];
static char eqv[255];
static char seen_tilde;

static struct dsc$descriptor_s log_d = { sizeof (log),
DSC$K_DTYPE_T,
DSC$K_CLASS_S,
log };
static struct dsc$descriptor_d eqv_d = { sizeof (eqv),
DSC$K_DTYPE_T,
DSC$K_CLASS_S,
eqv };

/*
** Because we are not being called by a C main(), initialize the
** C RTL.
*/
(void)decc$crtl_init ();
rtl_init = 1;

/*
** Assume success status.
*/
result_len = strlen (success);
result_p = success;

if (str_param->dsc$w_length == 0) {
/*
** Zero length string. Parameter error.
*/
result_len = strlen (param_error);
result_p = param_error;
} else {

log_d.dsc$w_length = sizeof (log);
eqv_d.dsc$w_length = sizeof (eqv);

switch (*int_param) {
case 0:
/*
** Delete the logical name
*/
r0_status = lib$delete_logical (str_param);
if (r0_status != SS$_NORMAL) {
result_len = strlen (error);
result_p = error;
}
break;
case 1:
/*
** Set the logical name
*/

/*
** Break the string up into the logical and equiv names.
*/
seen_tilde = FALSE;
p = str_param->dsc$a_pointer;
for (i = j = 0; i < str_param->dsc$w_length; i++) {
if (p[i] == '~') {
seen_tilde = TRUE;
log_d.dsc$w_length = j;
j = 0;
continue;
} else {
if (seen_tilde) {
if (j > sizeof (eqv)) {
result_len = strlen (param_error);
result_p = param_error;
break;
} else {
eqv[j] = p[i];
}
} else {
if (j > sizeof (log)) {
result_len = strlen (param_error);
result_p = param_error;
break;
} else {
log[j] = p[i];
}
}
j++;
}
}
eqv_d.dsc$w_length = j;

if (i == str_param->dsc$w_length && seen_tilde) {
/*
** Actually set the logical.
*/
r0_status = lib$set_logical (&log_d, &eqv_d);
if (r0_status != SS$_NORMAL) {
result_len = strlen (error);
result_p = error;
}
}
if (!seen_tilde) {
result_len = strlen (param_error);
result_p = param_error;
}
break;
case 2:
/*
** Translate the logical name
*/
r0_status = lib$get_logical (str_param,
&eqv_d,
&eqv_d.dsc$w_length,
0,
0,
0,
0,
&flags);
if (r0_status != SS$_NORMAL) {
result_len = strlen (error);
result_p = error;
} else {
result_len = eqv_d.dsc$w_length;
result_p = eqv_d.dsc$a_pointer;
}
break;
default:
/*
** Parameter error
*/
result_len = strlen (param_error);
result_p = param_error;
break;
}
}

/*
** Set up the results string descriptor and copy the result to it.
*/
r0_status = lib$sget1_dd (&result_len, result_param);
if (r0_status != SS$_NORMAL) {
return r0_status;
}
(void)memcpy (result_param->dsc$a_pointer,
result_p,
result_len);
return tpu$_success;
}
$eod
$cc log
$link/share log,sys$input/opt
$deck
symbol_vector=(tpu$calluser=procedure)
$eod
$loc = f$environment ("default")
$define tpu$calluser 'loc'log.exe
$create x.x
$deck
PROCEDURE set_logical
LOCAL result,
log,
eqv;
log := READ_LINE ("Logical name to define> ", 31);
eqv := READ_LINE ("Value> ");
EDIT (log, TRIM);
EDIT (eqv, TRIM);
result := CALL_USER (1, log + "~" + eqv);
MESSAGE (result);
ENDPROCEDURE;
PROCEDURE del_logical
LOCAL result,
log;
log := READ_LINE ("logical name to delete> ", 31);
EDIT (log, TRIM);
result := CALL_USER (0, log);
MESSAGE (result);
ENDPROCEDURE;
PROCEDURE show_logical
LOCAL result,
log;
log := READ_LINE ("show logical> ", 31);
EDIT (log, TRIM);
result := CALL_USER (2, log);
MESSAGE (result);
ENDPROCEDURE;
$eod

To use, edit X.X and at the command prompt, type "extend all". To demo
the functionality, you can then type "tpu show_logical", "tpu
set_logical", or "tpu del_logical" at the command prompt.

Jim.
--
www.eight-cubed.com

Bob Koehler wrote:

> In article <46bc198e$1@news.post.ch>, Martin Krischik
> writes:
>>
>> What I find really disturbing, and what shows the sorrow state of VMS,
>> is that you thought differently. No user of any other OS would have
>> thought that way - users of other OS's would have just expected to be
>> able to change the colours they way they like them. At least for an
>> editor advanced enough to support syntax highlight.
>
> I didn't think differently. I don't want my editor to colorize my
> code. The first thing I do with Linux is turn off the damn
> colorization in ls. I know I can configure both of them, but I want
> them off.

But you could switch them off. I never got Eve or LsEdit to display Black on
Bright White - at least not with the DecWindows interface. Both use some
ugly green from the Motif colour scheme.

> If you want TPU to colorize your text, you can write the TPU code to
> do it. Yes, it can be done on color capable displays.

And how may weeks will that take me - after I leared the basics of TPU
programming?

> The fact that
> no one has bothered has to do with the value of using a superior
> editor and superior programming languages that don't need such
> crutches.

As said that elsewhere: Any program or programing language not actively
developed will not stay superior for ever. Personlay I think that
TPU/EVE/LSEdit has allready been overtaken about 5 to 10 years ago.

Apart from that: those in our team who want the named features either use
Vim or Ms-Windows UltraEdit (copying the sources back and forth from VMS).



Martin
--
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

VAXman- @SendSpamHere.ORG wrote:

> In article <46bc198e$1@news.post.ch>, Martin Krischik
> writes:
>>
>>
>>Bob Koehler schrieb:
>>> In article <46bada06@news.post.ch>, Martin Krischik
>>> writes:
>>>> Bob Koehler schrieb:
>>>>
>>>>> If you don't have the TPU code to do your favourite editor trick,
>>>>> that's not TPU's fault.
>>
>>>> Then do tell me how to implement syntax highlight in an editor language
>>>> without colour support.
>>
>>> DON'T! I hate it when editors change the colors to illegible.
>>
>>The editor does not decide on any colour at all. I decide:
>>
>>http://www.vim.org/scripts/script.php?script_id=1538
>>
>>What I find really disturbing, and what shows the sorrow state of VMS,
>>is that you thought differently. No user of any other OS would have
>
> You are reading into Bob's statement. He said he doesn't like the
> editor changing colors to illegible; he didn't say anything that I
> read as implying that the color scheme could not be varied. I have
> used editor that change colors of text and I do not like it. It's
> turned off if I have a choice.

Ok I missunderstood him. But still: turning off a feature you don't like is
usually easier then turning on a feature which is not even implemented and
you will need to program it yourself in a programming language you have not
used before.

Well, learning a new language has never stopped me - but it helps if the I
can first use the tool comfortably and then learn the scripting language
behind.

> This is the same thing I find with web sites. People go and look
> at a web site and are impressed by the color but where is the con-
> tent? The most annoying thing lately is the "flash" animations I
> must witness before I enter a site for information. Is there ANY
> value in these 'flash' welcomes? In general, I would conclude no!

Strangely enough I hate flash animations as well. But just a much I hate an
editor which won't allow me to use an simple bright white as background.
See my answer to Bob.

>>thought that way - users of other OS's would have just expected to be
>>able to change the colours they way they like them. At least for an
>>editor advanced enough to support syntax highlight.
>
> You're complaining about an editor in a discussion of an OS. If
> you want to complain about editors, complain about all of the 'vi'
> variants in linux to edit various files... like crontab.

What I did not mentioned is that but - before posting - I checked both
LSEdit and Eve to see if - at least - the used foreground and background
colour can be easily changed. For the test I used the DecWindows
interface - and no: neither fonts nor the colours can be easily changed.
You will have to change the Motif colour scheme or do some advanced
DecW$XDefaults.Dat tweakting. "advanced" - because I already did all the
simple DecW$XDefaults.Dat tweakting, which changed the font but not the
colours used.

Martin
--
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Jim Duff wrote:
> And perhaps I should have said "trivial for a programmer that can spend
> 20 minutes reading the manual". Having never programmed in TPU before
> today, that's about how long it took me to figure out how to do this.


Thanks for your code.

1- If it is so trivial, how come they never included it in TPU ?

2- Because it is closed source, and because they have decided to no
longer do any improvements to TPU, such small programs cannot be made an
"official" part of TPU.


Compare this to healthy operating systems where much development happens
where the vendor wants to find reaons to justify adding new features to
their product (as opposed to VMS where management/engineers find reasons
to NOT add new features).

Compare this to even Linux where good tidbits get integrated into the
main distributions and become part of an EVOLVING product.

VMS is DEAD in the sense that it is no longer evolving its user facing
applications.