| 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 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" < address@hidden> 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 <address@hidden> 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>
|