Hi David,
thanks, fixed in SVN 446.
/// Jürgen
On 08/23/2014 07:27 PM, David Lamkins
wrote:
I ran into this after updating to 445.
This is in a pendent function.
Hi David,
this could be caused by how the input echo is implemented.
If you look at CinOut::overflow(int c) then you will see
that the echo of GNU APL input
is sent to cerr rather than to cout. The reason
was, as far as i remember, that when yo
Thanks for the explanation. With this in mind, I'm wondering about two
specific cases and how you intend to solve them (these are are ones that
gave me the biggest headache):
First of all, how will you avoid doing a clone() on every update using
indexed assignment? You need some way to know whethe
Hi Elias,
I don't know. Actually I just found a nasty example which renders
my statement below
("I believe the clone()
call in Symbol::resolve() can be skipped completely")
wrong:
A←10⍴10
A+ (A[3]←3) ⊢ A
Cur
Of course, there are definitely times where cloning is necessary. The
typical example would of course be when a value is assigned to another and
that value is subsequently changed (by using indexed assignment).
And you mentioning the issue of not know *who* are the owners of an object
reminds me o
Hi Elias,
there are actually more cases. For example:
(5 5↑A)←B
This is like left values in C/C++.
I would agree that unnecessary cloning should be avoided. But that
needs to be done in a way
that can be proven to be c
Thanks for the pointer to CinOut::overflow(). That's the part I was
missing.
The attached patch ensures that no_readline() changes pad characters to
spaces before pushing the prompt onto stdin. I've also reverted your
patch to CInOut::overflow().
Here's the explanation:
aplwrap watches both stou
What about keeping a linked list of owners, figure who is getting written to, and clone that one only? Typically there would only be one owner, and you can do the linked check with inline code.. I think avoiding a lot of cloning is important.Blake-- Sent from my HP TouchPadOn Aug 24, 2014 10:01 AM
