Commits on Sep 10, 2014
  1. Emerald is launched!

    Jaxo committed Sep 10, 2014
  2. About to launch Emerald (1.4)

    Jaxo committed Sep 10, 2014
Commits on Sep 5, 2014
  1. Solved a naive conflict

    Jaxo committed Sep 5, 2014
Commits on Aug 29, 2014
  1. Handle linux shebang

    Jaxo committed Aug 29, 2014
  2. Added launcher/launchee scripts

    Jaxo committed Aug 29, 2014
  3. Android versionCode 7

    Jaxo committed Aug 29, 2014
  4. Script samples added + more doc

    Jaxo committed Aug 29, 2014
Commits on Aug 26, 2014
  1. Do not strip the '>LIFO' from the original command, but strip a copy!

    Jaxo committed Aug 26, 2014
    In case the command is within a procedure, the redirection will not
    be executed at the second time.
Commits on Aug 25, 2014
Commits on Aug 24, 2014
  1. catch unhandled exceptions

    Jaxo committed Aug 24, 2014
  2. Branch b3 - SIGSEGV fix

    Jaxo committed Aug 24, 2014
    Branch b3 fixes the bug that was teasing me since more than a month.
    There probably were more than one bug.
    Most important is that I was incorrectly using the name 'finalize' to cleanup
    the static data in the JNI library when Rexx came to onStop. I should have
    remembered that 'finalize' is a reserved verb used by the JVM when the Object
    to which this method pertains get garbage collected. This mistake resulted
    in 'finalize' being called twice, one by me preceeding the one issued by
    the JVM, leading to a segfault. I renamed 'finalize' to 'terminate', and,
    to avoid any confusion, 'initialize' was renamed 'commence'.
    While chasing this bug, I did a few other changes.
    - in the overloaded 'onStop' of the Rexx activity, the call to 'super.onStop'
      has been moved at the end. How sure can I be that Android doesn't pollute
      my fields?
    - in the SystemContext destructor, 'invalidateConsoles' may need to be called
      before 'unregisterUri'.  At least, for the logic of the call order.
  3. changed text size units

    Jaxo committed Aug 24, 2014
Commits on Aug 23, 2014
  1. Bug fix: onCreate called again by onActivityResult

    Jaxo committed Aug 23, 2014
    See comments in the code change with this fix.
  2. Rexx error messages described on the Java side (toast)

    Jaxo committed Aug 23, 2014
    The challenge was to percolate messages from the C++ core up to Java.
    This was just not implemented.
Commits on Aug 13, 2014
  1. And the culprit was...

    Jaxo committed Aug 13, 2014
    Proguard! It's a bit my fault: I forgot to tell that "context", a long
    value in, should not be obfuscated.  But, even after
    this change + new proguard CFG structure, the problem reappeared.
    No proguard, no problemo.  Proguard is less than 1% of footprint improvement.
    Why would I to bother for this ridiculous amount? I'm not even trying to
    spend one second at fixing my Proguard config.  That was enough a pain
    in the neck, and I just don't care.
    This is branch b2, soon to be merged back to Emerald.
  2. Branch b2

    Jaxo committed Aug 13, 2014
    Getting rid of Launcher + ScriptsList activities.
    The Launcher was there only for switching views (splash -> list).
    Use a single activity (Landing) instead, with a ViewAnimator.
    Then..  A severe problem was discovered.  It stops the Rexx Interpreter
    (Tokenizer?) at the very start. Current change doesn't appear to be the
    culprit, and I ever rolled back to July 22nd and the problem is still there.
    This means that it should be something in the configuration (compiler, build
    tools.)  In any case, I cannot pursue on 'emerald' anymore, and created the
    branch 'b2'.
Commits on Aug 12, 2014
  1. Fix README typos

    Jaxo committed Aug 12, 2014
  2. Cosmetics

    Jaxo committed Aug 12, 2014
  3. 'Emerald Peak' is officially born.

    Jaxo committed Aug 12, 2014
  4. Pragma to hide GCC warning on mkstemp return value not used.

    Jaxo committed Aug 12, 2014
    I did it because I thing it is irrelevant, although I'm not 100% sure.
    Beside creating a tersed filename, "mkstemp" also opens the temporary file,
    returns its FD, but we don't care.  Later, Interpreter re-opens this file
    while it hasn't been closed -- because we don't care about the FD returned
    by mkstemp, what the warning warns me of.
    I don't think it is dangerous, but I should investigate more.
    For nowtimes, I'm close to a Customer Shipment and I want to make the less
    changes as I can.
  5. Updated README

    Jaxo committed Aug 12, 2014
  6. Made the edited tezt zoomable

    Jaxo committed Aug 12, 2014
Commits on Aug 11, 2014
  1. string.h missing, wrong comment

    Jaxo committed Aug 11, 2014
Commits on Aug 10, 2014
  1. Android snapshots added

    Jaxo committed Aug 10, 2014
Commits on Aug 8, 2014
  1. Final on branch b1

    Jaxo committed Aug 8, 2014
  2. Added Rexxoid's crown for logo

    Jaxo committed Aug 8, 2014
  3. Speaker language optimized

    Jaxo committed Aug 8, 2014
    At profiling REXX, I found that the 3sec lag observed at the start of an
    interpretation (associated file or attachment) was only due to the system
    setting the language.
    "Speech" has been modified so that a language change only occurs when it
    is required.
Commits on Aug 7, 2014
  1. Fix for problems in REXX Activity lifecycle.

    Jaxo committed Aug 7, 2014
    Finally!  This code seems to have robust manners to keep a sane SystemContext
    among the several ways Rexx can be called. The solution was to use the
    couple onStart/onStop rather than onCreate/onDestroy.
    It might look obvious, but it wasn't. I spent 2 days before to arrive to
    this solution.  I tried a Ref'ed SystemContext, and to make Rexx single task
    (but this doesn't work, because Google decided to secure access to GMail
    attachments, for onNewIntend.)  I even wrote a LocalBroadcaster! Nothing
    worked, a pain in the neck at fighting SIGSEGV's all over the place.
    Rereading carefully the Activities'lifecycle -- despite Google efforts for
    documenting, this part is still unclear for many -- I found out that the
    onStart/onStop had to recreate the SystemContext, b/c I could not keep
    the same context for Rexx started from the App, and Rexx started as an intent
    for executing mail attachment, or file association.
    REXX'SystemContext is really what it says it is: independent of REXX'guts
    (that is: clauses, the stack, etc..), it's just a kind of Helper to redirect
    the output/input (serambuffers) resources to what's appropriate in a given
    (new) context.
Commits on Aug 6, 2014
  1. Defense against a null speaker

    Jaxo committed Aug 6, 2014