Error in process filter

[mjrodgers]

Occasional when I use the "evaluate until" command "C-C, C-U", I get the following messages: error in process filter: kill-append: Args out of range: 0, 0 error in process filter: Args out of range: 0, 0

It gives the error partway through sending the code (so it sends a number of lines then stops); if I hit enter in the terminal shell, it will resume sending lines of code but often will have skipped a few.

I appreciate the work by the way, I was using the old version for quite a while and was happy to see the updates :)

[ThibautVerron]

Hi, thanks for the heads up!

When you say "occasionally", do you see any pattern, or is it apparently completely random? For example, is there some magma code that triggers this all the time when the command is called from a specific position?

If it's really random, you could try activating the backtrace on error (M-x toggle-debug-on-error) and copy/pasting the backtrace when the problem occurs. If you have other packages that throw a lot of errors and spam you with backtraces, I won't blame you. ;)

Could you please also give me the values of the following variables in a magma interactive buffer (both local value and global value)? (If you don't know how to check these values, use C-h v)

• comint-output-filter-functions
• comint-preoutput-filter-functions
• comint-redirect-filter-functions

And the values of the following variables in a magma buffer:

• magma-interactive-method
• magma-interactive-wait-between-inputs

And last question, do you sometimes use other evaluation methods than eval-until? And does the bug never appear with these?

Sorry, that's a lot of questions... meanwhile I'll try using eval-until more often to see if I can reproduce it myself.

[ThibautVerron]

This is really puzzling... kill-append is not used by the magma-mode at all, and is used in only 2 lisp files of my emacs install (dired and eshell/esh-io), none of which should impact the behavior of the magma-mode.

Do you still see the bug with a vanilla emacs (started with emacs -Q)?

[mjrodgers]

Hmm, I'm using Aquamacs actually, so maybe that is the source of the error. I was having it occur pretty regularly, I'll do some more error testing tonight. Sorry I got caught up with some other things yesterday, but I'm happy to help!

[mjrodgers]

Okay, for now I am having the issue occur pretty regularly, and sometimes also in “evaluate paragraph". Always occurring in the same places.

evaluate until always triggers in this block, right before the last line: nu := rep{x : x in E | (x ne 0) and ((Log(-x) mod 2) eq 1) and ((Log(-x-1) mod 2) eq 0)}; //-nu is a nonsquare.

Using evaluate paragraph, it executes the paragraph with the preceding block fine but hangs on the following paragraph, right before the second comment:

//Both quadratic forms identical in characteristic 3. Interior points: -Q(v) in nsq. Q2 := ((E!2)^-1)_UpperTriangularMatrix(E, [0,4,0,0,0,-1]); V2 := QuadraticSpace(Q2); //Qpi := ((E!2)^-1)_UpperTriangularMatrix(E, [0,1,0,0,0,-1]);

So maybe using // to start comments is a problem? I have some regions commented out with /* */ and they don’t seem to trigger the error.

"Could you also give me the values of the following variables in a magma interactive buffer (both local value and global value)?

comint-output-filter-functions comint-preoutput-filter-functions comint-redirect-filter-functions” How do I display these? I am afraid I’m not an emacs power-user, I kind of just kludge together what I need for my specific uses :)

On Jun 22, 2015, at 2:10 PM, ThibautVerron notifications@github.com wrote:

This is really puzzling... kill-append is not used by the magma-mode at all, and is used in only 2 lisp files of my emacs install (dired and eshell/esh-io), none of which should impact the behavior of the magma-mode.

Do you still see the bug with a vanilla emacs (started with emacs -Q)?

— Reply to this email directly or view it on GitHub https://github.com/ThibautVerron/magma-mode/issues/11#issuecomment-114081134.

[mjrodgers]

Okay, actually I see it is occurring for other types of comments. This is what happens: it throws the error at the first comment in the evaluate region, and it will hang (stop sending lines of code). Hitting enter in the magma buffer will start sending lines of code again, but that line that triggered the error will be lost. If the line was ONLY a comment, no big deal. But if it had some code along with comment, or if it was a line consisting of /* without */, it creates some problems for the rest of the

The only thing that seems to be okay is for comments at the beginning of the evaluate region. (By "region", I usually just mean whatever is being sent by "evaluate until" or "evaluate paragraph", those are my most used). I hope this helps, and please let me know any other info I can get for you!

[ThibautVerron]

Thank you, it really should help!

It sounds like it could be related to a bug I fixed a long time ago, where comments in the sent code were added to the kill-ring (and they shouldn't). I doubt that the fix could create what you describe now, but sneaky bugs are sneaky.

I can not reproduce the bug with eval-until yet, but I do get a suspicious behavior for eval-paragraph with the second snippet: it sends the lines of code, but the magma interactive buffer does not realize that it is ready for more input, and will not recieve more lines until you press enter in the interactive buffer or you press C-c C-i in the code buffer.

Do you usually have to wait a moment before the error in process filter kicks in, or does it happen instantly (when it does)?

About the variables, I don't think they are relevant anymore, but I'd be interested in the value of magma-interactive-skip-comments now. You can check it with C-h v.

Also, I should have asked that before, but what version of emacs (aquamacs) and magma-mode are you using?

Thanks again!

[mjrodgers]

It feeds the code to the buffer line-by-line, and kicks in the instant it hits that line of code. It sounds like your behavior is similar to mine, that is exactly what happens when the error kicks.

I’m using the version of magma-mode from melpa, 20150604.505, and the latest release of Aquamacs, Aquamacs 3.2 GNU Emacs 24.4.51.2. Also, magma-interactive-skip-comments is nil

On Jun 23, 2015, at 8:52 PM, ThibautVerron notifications@github.com wrote:

Thank you, it really should help!

It sounds like it could be related to a bug I fixed a long time ago, where comments in the sent code were added to the kill-ring (and they shouldn't). I doubt that the fix could create what you describe now, but sneaky bugs are sneaky.

I can not reproduce the bug with eval-until yet, but I do get a suspicious behavior for eval-paragraph with the second snippet: it sends the lines of code, but the magma interactive buffer does not realize that it is ready for more input, and will not recieve more lines until you press enter in the interactive buffer or you press C-c C-i in the code buffer.

Do you usually have to wait a moment before the error in process filter kicks in, or does it happen instantly (when it does)?

About the variables, I don't think they are relevant anymore, but I'd be interested in the value of magma-interactive-skip-comments now. You can check it with C-h v.

Also, I should have asked that before, but what version of emacs (aquamacs) and magma-mode are you using?

Thanks again!

— Reply to this email directly or view it on GitHub https://github.com/ThibautVerron/magma-mode/issues/11#issuecomment-114606685.

[ThibautVerron]

Thanks for the information.

There are differences between what you describe and what I see: most notably there is no error message in my case. And my magma-interactive-skip-comments is t, if I set it to nil I can no longer see the problem. But it is better a lead than none, and if it was an entirely different bug, it would be very weird that it pops up now, with your code snippet.

Just to check if I can reproduce with the exact same procedure: could you please tell me, for each of your code snippets, where exactly do you place the point (cursor), and what command you enter at this point, or what keys you press?

Thanks,

[mjrodgers]

OK, I have put the code for the whole first part of my file, so it should all run in Magma without throwing any errors for undefined variables.

/Here we want to obtain information about secant sublines of different types; the type is based on the quadratic form for which the subline is canonical. i.e, we map the subline to the set of F_q points, and we look at the quadratic form induced on the line with respect to this basis. Type 1: f(t) := (t-alpha)(t-alpha^omega) for some omega in Aut(F_q^n/F_q) Type 2: f(t) := (t-alpha)(t-beta) for some alpha, beta in the subfield F_q^(n/2) (when n is even) Type 3: Others. /

q := 3; n := 7;

F := FiniteField(q); E := ext<F|n>; Ev, Evmap := VectorSpace(E,F); _, EmF := PGL(Ev); EmF := {@ (Evmap^-1)(v) : v in EmF | not ((Evmap^-1)(v) in F) @}; nu := rep{x : x in E | (x ne 0) and ((Log(-x) mod 2) eq 1) and ((Log(-x-1) mod 2) eq 0)}; //-nu is a nonsquare. |<————————Cursor location, command: C-c, C-u (throws the same error if cursor is at any position past here) sq := {x : x in E | x ne 0 and (Log(x) mod 2) eq 0}; nsq := {x : x in E | x ne 0 and (Log(x) mod 2) eq 1}; |<————————Cursor location, command: C-c, C-p //Both quadratic forms identical in characteristic 3. Interior points: -Q(v) in nsq. Q2 := ((E!2)^-1)_UpperTriangularMatrix(E, [0,4,0,0,0,-1]); V2 := QuadraticSpace(Q2); //Qpi := ((E!2)^-1)_UpperTriangularMatrix(E, [0,1,0,0,0,-1]);

//Vpi := QuadraticSpace(Qpi); …code continues

On Jun 24, 2015, at 7:13 AM, ThibautVerron notifications@github.com wrote:

Thanks for the information.

There are differences between what you describe and what I see: most notably there is no error message in my case. And my magma-interactive-skip-comments is t, if I set it to nil I can no longer see the problem. But it is better a lead than none, and if it was an entirely different bug, it would be very weird that it pops up now, with your code snippet.

Just to check if I can reproduce with the exact same procedure: could you please tell me, for each of your code snippets, where exactly do you place the point (cursor), and what command you enter at this point, or what keys you press?

Thanks,

— Reply to this email directly or view it on GitHub https://github.com/ThibautVerron/magma-mode/issues/11#issuecomment-114729402.

[ThibautVerron]

Ok, so I can definitely not reproduce your error with this procedure. This does not necessarily mean that the problem is out of my hands, just that we may have to investigate possible incompatibilities with your configuration in the future.

I'd like to narrow down what exactly triggers the issue, too. I suspect that the following code snippets will trigger the bug too:

x := 2+2; // Comment
// // C-c C-u at the beginning of this line

and

// // C-c C-p at the beginning of this line
// Comment 1
x := 2+2;
// Comment 2

Can you confirm that?

On the other front, I have fixed the (different but similar) bug that I could see with the snippet you gave me. I cannot offer any guaranty, but there is a nonzero chance that it also affected the behavior of your bug.

If you want to test it, please follow the "installation with git" section of the readme, and add

git checkout "bug#11" 

after the procedure, and before starting emacs. Please make sure, in your init file, to comment out the line where you load the magma-mode from melpa as well.

I am clumsy with git, so this branch might contain some partially implemented features that could result in more bugs (but nothing unusable, this is the version I use on a daily basis).

Last thing I can think of, the closest I can get to your setup is a friend's macbook using Emacs for Mac OSX. Would it be easy for you to test whether the bug also appears on this version?

Thanks again,

[mjrodgers]

I'll set this up and test. I have a busy weekend, but I'll let you know as soon as I can try it out.

[mjrodgers]

Hey, finally had a chance to try to set this up. I get an error message when I try git checkout “bug#11” When do I do this? I am typing this in terminal immediately after cloning the repository. I get the error fatal: Not a git repository (or any of the parent directories): .git

As for these two blocks: x := 2+2; // Comment // // C-u C-u at the beginning of this line (C-u does not trigger a problem from the beginning of this line, but it does from the end; also C-p triggers an error.)

x := 2+2; // Comment <—————error occurs here

Interesting note here: x := 2+2; // Comment y:= 2;

<---(C-u from THIS line triggers the problem but not from the previous (and only when the comment is there). C-p does not have a problem with the block)

// // C-p C-p at the beginning of this line // Comment 1 x := 2+2; // Comment 2

// // C-p C-p at the beginning of this line <—————error occurs here

I’m trying to get Emacs for Macs up and running to test, I’m not really sure how it sets up all the preferences (don’t know where it wants my init files… so I can’t set it up to download from Melpa, or set up using git method).

Best, Morgan

On Jun 24, 2015, at 10:52 AM, ThibautVerron notifications@github.com wrote:

Ok, so I can definitely not reproduce your error with this procedure. This does not necessarily mean that the problem is out of my hands, just that we may have to investigate possible incompatibilities with your configuration in the future.

I'd like to narrow down what exactly triggers the issue, too. I suspect that the following code snippets will trigger the bug too:

x := 2+2; // Comment // // C-u C-u at the beginning of this line

and

// // C-p C-p at the beginning of this line // Comment 1 x := 2+2; // Comment 2

Can you confirm that?

On the other front, I have fixed the (different but similar) bug that I could see with the snippet you gave me. I cannot offer any guaranty, but there is a nonzero chance that it also affected the behavior of your bug.

If you want to test it, please follow the "installation with git" section of the readme, and add

git checkout "bug#11"

after the procedure, and before starting emacs. Please make sure, in your init file, to comment out the line where you load the magma-mode from melpa as well.

I am clumsy with git, so this branch might contain some partially implemented features that could result in more bugs (but nothing unusable, this is the version I use on a daily basis).

Last thing I can think of, the closest I can get to your setup is a friend's macbook using Emacs for Mac OSX. Would it be easy for you to test whether the bug also appears on this version?

Thanks again,

— Reply to this email directly or view it on GitHub.

[ThibautVerron]

Hello,

About the error with git, I don't know what to say... I tested it with a new copy of the repository, it worked without any problem. Maybe you forgot to move to the cloned directory before the checkout?

Thanks for the information about the blocks. Maybe you'll want to remove your previous code blocks from this issue, if they contain some work in progress that you'd prefer to keep secret for the moment. I don't know the material well enough to judge. ;)

For emacs for mac OS, from what I can find on the matter, the init file should be in the standard location, in your home directory (I mean ~/... maybe that's not how it's called in the mac world). So your settings should be in ~/.emacs or ~/.emacs.d/init.el. See http://stackoverflow.com/q/22219131/1083706

Thanks and good luck!

[ThibautVerron]

I have just released a new version. I included the change I suggested you to test, since they are a confirmed fix for another bug. Give a few hours for melpa to synchronise, and you should be able to test it without git!

And as a bonus, if it works, you won't have to wait any longer before you can use it in production. Yes I'm an optimistic person.

[mjrodgers]

Unfortunately, I still have the bug... I will do some testing with emacs for osx when I get a chance (though I am at conferences for the next week or so). Thanks for the help finding where the config files go, in Aquamacs they get sent to the ~/Library/Preferences/ to be a little more OS X consistent so I was looking there for emacs as well.

[ThibautVerron]

Hello,

I have pushed a new version, could you check if it changes anything to the issue?

Thanks!

[mjrodgers]

I'm still getting the issue with my comments, unfortunately.