Re: [Bug-apl] Problems with shared variables

[Juergen Sauermann]

Hi,

I believe )MORE should somehow be aligned with the display of other errors.
The theory seems to be that when an error occurs then a rather rigidly formatted,
3-line error output is produced:

VALUE ERROR
      a+5
      ^

Line 1 is the name of the error, line 2 the offending input and line 3 showing
one or two carets marking the token in line 2 that have caused the error.

Unfortunately line 1 is not very verbose about further details.
In this situation, )MORE may show more details about the error.
In theory, line 1 should show a + at the end when )MORE has more information.
like in:

VALUE ERROR+

I haven't done that yet, because I was not using )MORE in the beginning. I'll add that.

/// Jürgen



On 02/21/2014 03:47 AM, Elias Mårtenson wrote:

Jürgen,

I will put a check for )MORE availability in the end_input function and display a notification in Emacs when it contains something. Would this be the right approach?

Regards,

Elias

On 20 February 2014 23:44, Juergen Sauermann <address@hidden> wrote:

Hi,

the normal 3-line error printout is documented by IBM and shall remain as is for compatibility.

I will, however, put more information about errors in )MORE such as file names, strerror() stings and the like.

Pleas feel free to indicate where the information related to errors is not sufficient.

/// Jürgen

On 02/20/2014 12:16 PM, Elias Mårtenson wrote:

On 20 Feb 2014 18:57, "Kacper Gutowski" <address@hidden> wrote:
>
> On 2014-02-16 18:09:06, Juergen Sauermann wrote:
> > Ad 1) I changed the assertions Symbol.cc to short warnings visible in )MORE.
>
> I wouldn't guess to check )MORE upon getting VALUE ERROR on shared
> variable, but I guess it's better than failed assertion.

Hmm, this makes me think about a new feature for the Emacs mode: some kind of warning in the modeline when there is an unread )MORE message.

Would this be useful? Do you get these kinds of messages often? I rarely look for it.

> It appears to work correctly for cooperating users now.  Malicious user,
> however, can still easily destroy other users' coupling of shared variables.
> I'm not going to push for changing it right now because I don't see any way
> to exploit it beyond denial of service and I'm not using shared variables
> for anything serious, but I think that it should be done eventually.

I suppose some proper authentication and authorisation mechanism is needed too. Then comes the question of encryption. Things like Kerberos is easy to add and is powerful. However, it does require infrastructure a lot of people don't have.

Regards,
Elias