I've implemented this bow and it works exactly the way you said it would. Very nice.
The only issue is the evaluation. As of now, I have to type any command into the interpreter in order to have the input take effect. How should I deal with this? One way would be to send left tack, zilde to the normal input. I find that to be a bit ugly though. Is there a better solution? Regards, Elias On 6 Aug 2014 18:30, "Elias Mårtenson" <loke...@gmail.com> wrote: > Thank you. I had actually looked at that method too, but I thought that > the line number stuff was handled by the Archive stuff. > > I'm testing it out now. > > By the way, it seems as though the set_line_no change hasn't been pushed > yet. > > Regards, > Elias > > > On 6 August 2014 18:26, Juergen Sauermann <juergen.sauerm...@t-online.de> > wrote: > >> Hi Elias, >> >> when I said "have a look at" I meant to see how it works, not to call it. >> There relevant lines are *Workspace.cc:789* : >> >> I*nputFile fam(filename, file, false, false, true, with_LX);* >> * InputFile::files_todo.insert(InputFile::files_todo.begin(), fam);* >> >> That pushes filename onto the input file stack and its content will be >> read next. >> No need for #! etc. >> >> I have added a *set_line_no()* function so that you can do: >> >> *fam.set_line_no(your number);* before i*nsert()*ing it. Next SVN. >> >> I should mention that you need to return to immediate execution mode >> for the input to be read. >> >> /// Jürgen >> >> >> >> On 08/06/2014 10:43 AM, Elias Mårtenson wrote: >> >> OK, I now have a better understanding of how loading works. >> >> I have a request though: >> >> I would like to be able to specify to Workspace::copy_WS that my input >> file contains APL code, and nothing else. This is because the Emacs mode >> has the ability to send parts of a file to the interpreter, and in such >> cases there is no #! tag in the beginning of the block. >> >> I can of course work around this by prepending the data with #!, but >> then the lines numbers are no longer correct (if I send a block that >> contains the first line of a file, the lined numbers in the function >> metadata will be off by one). >> >> How about another optional(?) argument to copy_WS that specifies the >> input type? >> >> Regards, >> Elias >> >> >> On 6 August 2014 13:51, Elias Mårtenson <loke...@gmail.com> wrote: >> >>> Thanks, I've tried this and I'm having some problems. I'm probably not >>> doing things right. >>> >>> I'm doing something similar to: >>> >>> string filename = "/tmp/xyz"; >>> int fd = open( filename.c_str(), O_RDONLY ); >>> Workspace::load_DUMP( COUT, UTF8_string( filename ), handle, false ); >>> >>> The load seems to succeed, but none of the code in the file seems to >>> be executed. >>> >>> What am I doing wrong here? >>> >>> Or, should I be using InputFile directly? >>> >>> Regards, >>> Elias >>> >>> >>> On 5 August 2014 23:57, Juergen Sauermann <juergen.sauerm...@t-online.de >>> > wrote: >>> >>>> Hi Elias, >>>> >>>> I guess something like that exists already. Have look at >>>> how *)LOAD* works for .*apl *files. There is a stack of file >>>> descriptors >>>> for the files read by *Input* and you can push an open file descriptor >>>> onto it. The >>>> only thing that doesn't work is to stop in the middle of a file (unless >>>> you insert >>>> a *]NEXTFILE* command at that point. >>>> >>>> /// Jürgen >>>> >>>> >>>> >>>> On 08/05/2014 05:39 PM, Elias Mårtenson wrote: >>>> >>>> Hello Jürgen, >>>> >>>> What I mean by the somewhat mysterious subject is that I have had a >>>> request to implement (or rather, improve) a feature in the Emacs Mode that >>>> allows a user to evaluate all or part of a file. >>>> >>>> Specifically, what is needed is a way for me to take a set of source >>>> lines (usually a portion of a source .apl file) and pass it to some >>>> function that will load execute those lines in exactly the same manner as >>>> if the content had been saved to a file and then loaded using )COPY. >>>> >>>> Ideally, I would also need the ability to specify the name of the >>>> file and starting line number. This is so that the symbol metadata >>>> (filename and line number) are correct in functions that are defined in >>>> this manner. >>>> >>>> Would it be possible for you to implement a function that provides >>>> such interface? >>>> >>>> Regards, >>>> Elias >>>> >>>> >>>> >>> >> >> >
