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" <juergen.sauerm...@t-online.de>
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 <loke...@gmail.com>
> <loke...@gmail.com> 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>
>
>
>
>
>
