Hi Elias: Sorry but I am totally ignorant about Android so don't know how the following comments apply, if at all.
As a first step in OS X I am going to experiment with setting up file handles for pipes, setting up NSNotifications, and launching a sub-task. See NSTask documentation and sample code such as Moriarty and QCComposer. Both are Cocoa event driven wrappers of command line programs. The sub task gets the environment of the launcher but is a separate process. My eventual goal would be to try to build the interpreter as a dynlib and possible later also a framework. respect…. Peter On 2014-06-16, at 12:56 PM, Elias Mårtenson <[email protected]> wrote: > Note that the Android port doesn't really do input. It's all event-driven > from the user interface. That said, I'll need to deal with quad-assignment. > Trying that right now would cause it to hang since there is no way to send > input to stdin. > > So yeah, I'd need some mechanism by which I can be informed that the running > APL program is requesting input (quad-assignment). I haven't looked at that > yet though. > > Regards, > Elias > > On 16 Jun 2014 18:30, "Juergen Sauermann" <[email protected]> > wrote: > Hi Peter, > > I see a few problems with your proposal. > > Currently class Input has only static functions, so virtual methods can not > be used to distinguish > between different implementations of the same function. > > Suppose we would fix that by using Input instances. Instead of eg. > > #ifdef HAVE_ANDROID > > line = Android_Input::get_line(); > > #else > > line = Input::get_android_line(); > > #endif > > We would then have eg. > > class Input { ... } > class Android_Input: public Input { ... } > class Normal_Input: public Input { ... } > > #ifdef HAVE_ANDROID > > Android_Input a_input; > Input * input = a_input; > > #else > > Normal_Input n_input; > Input * input = a_input; > > #endif > > ... > line = input->get_line(); > > IMHO this is only adding complexity without really making things more elegant. > > And it does not solve the real problem, which I believe is the following. I > assume > that Elias' Java environment has a number of nasty (read: totally > incompatible) things that > I cant support in a reasonable (read: portable) way. The two derived classes > would still need > to be compiled, but one of them is not portable, which will create a lot of > headache for all > non-Android users. > > A much cleaner (or at least simpler) proposal, in my eyes, is this: > > 1. We use two files Input.cc and AndroidInput.cc. > 2. Both use the same Input.hh so that all other source files are no affected. > Not all functions > declared in Input.hh need to be implemented, so AndroidInput.cc. can be > rather simple. > 3. The src/Makefile decides which of the two files shall be compiled in a > given environment. > > /// Jürgen > > > On 06/16/2014 04:43 AM, Peter Teeson wrote: >> I suggest once again two abstract classes for I/O with virtual methods which >> can then be inherited from and implemented by the user. >> This special case patching of fixes is not elegant - to me it is smelly >> coding. >> Sorry if I offend but that's my 2¢. >> >> Peter >> >> On 2014-06-15, at 4:06 PM, Elias Mårtenson <[email protected]> wrote: >> >>> Do you think it would be possible to apply this patch that avoids setting >>> up the output streams when compiling for Android? The Android version >>> installs its own that redirects the output to Java streams. >>> >>> Regards, >>> Elias >>> <streams.diff> >> >> >
