The Emacs mode should not be hiding the output on standard error. If anyone happens to see it do that, please let me know because that would mean you've come across a bug.
Regards, Elias On 30 Apr 2014 20:04, "Juergen Sauermann" <juergen.sauerm...@t-online.de> wrote: > Hi Blake, > > if the problem is that stderr gets lost, then it might help if you change > Archive.cc line 1348: > > CERR << "vid=" << vid << endl; > FIXME; > > from CERR to COUT. That should at least show the vid that tells me where > in the > .apl file this happens. Just a guess because i am not that familiar with > emacs mode. > > /// Jürgen > > > On 04/29/2014 10:19 PM, Blake McBride wrote: > > I don't know how to get the vid printed on stderr since I only get the > error running through Emacs. If someone can give me a way of simulating > this error without emacs, I'd be glad to do that. > > Thanks. > > Blake > > > > On Tue, Apr 29, 2014 at 8:45 AM, Juergen Sauermann < > juergen.sauerm...@t-online.de> wrote: > >> Hi, >> >> I managed to reproduce this once with )LOAD Devices (and without emacs), >> but after turning Archive related >> logging on and off again I did not happen again. I have added some more >> printout so that I >> can see which value ID is causing this (SVN 237). If it happens again, >> please send me the >> .xml (if it is a different one) and the vid printed on stderr. >> >> /// Jürgen >> >> >> >> On 04/28/2014 05:11 PM, Blake McBride wrote: >> >> Here is the workspace. >> >> >> On Mon, Apr 28, 2014 at 10:06 AM, Juergen Sauermann < >> juergen.sauerm...@t-online.de> wrote: >> >>> Hi, >>> >>> I have initialized current_char in SVN 234, but can't see either how >>> this would >>> make a difference. I would be interested in the workspace file as well >>> if the error persists. >>> >>> /// Jürgen >>> >> >> >> > >
