In my implementation of eval_AXB I am getting the function number using the
following code:
const int function_number = X->get_ravel(0).get_near_int(qct);
When X is either 0 or 1, this works correctly. But when X is any other
value (for example, 2) the call to .get_near_int(qct) throws a
*DOMAIN_
Greetings,
I have a Unicomp (USB) APL keyboard. I am running the latest LinuxMint.
Using:
xmodmap apl.xmodmap
does work but has two significant problems as follows:
1. Many keys don't match the Unicomp layout of APL characters. For
example, on the Unicomp keyboard, ← and → are on the sa
> Personally, my eyes can't handle black background at all, so I'd definitely
> all for a white background (also, it's generally better for people's eyes).
Done. Now it is white. Also cleaned the URL:
interpreter: http://baruchel.hd.free.fr/apps/apl
script evaluator (old): http://baruchel.hd.
Blobs is not a problem for 2⎕TF, since it will only ever output text,
correct? Then just using a plain text column will be good enough, and will
actually work right now.
As for blobs, I'm not sure we should care about that. After all, APL
doesn't support binary data anyway.
Regards,
Elias
On 13
Hi,
I see. I also worked with several VCS and my favorite is still RCS.
I just think that changing a VCS in the middle of something is just
extra work.
And I am admittedly not as familiar with git or mercurial as with SVN.
/// Jürgen
On 04/13/2014 05:51 PM, Elias Mårtenson wrote:
Sure, that
Personally, my eyes can't handle black background at all, so I'd definitely
all for a white background (also, it's generally better for people's eyes).
Regards,
Elias
On 13 April 2014 23:56, Thomas Baruchel wrote:
> > Time to post this on reddit then? :-)
>
> I will clean the URL and make some
> Time to post this on reddit then? :-)
I will clean the URL and make some cosmetic changes; btw:
* wouldn't a white background be more "modern"?
* wouldn't a colored background (like in the code sample from
https://blogs.adobe.com/typblography/2012/09/source-code-pro.html
be more "mo
Sure, that works fine. The reason I was suggesting a shift to a distributed
system (Savannah supports at least Bazaar, Mercurial and Git, as far as I
know) was that the local-vs-official repository can be handled more
smoothly that way.
However, I do not want to be "that guy". You know, the guy wh
Hi,
my concern is not the ultimate responsibility because if we get more and
more sub-projects then
I would NOT like to be responsible for the merges. I would prefer if the
responsibilities are agreed
beforehand and then every contributor would have, say, her subdirectory
and with it also the
Hi Elias,
yes, you have a point there. My first guess would be GNU savannah where
GNU APL lives. We would have to figure a few things like how to change
SVN permissions,
paperwork for contributors (as per
http://www.gnu.org/prep/maintain/maintain.html) and so
on, but that is doable.
Another p
Elias Mårtenson wrote:
> With the exception of the lack of popup keyboard, it's already so much
Just added it ;-) Same URL
Not really. Tablets usually use a popup on-screen keyboard.
I'd say that APL is probably more appropriate for Tablet use than any other
language that I can think of, thanks to the fact that you have to type so
much less, and typing is the worst part of tablet use.
Thus, a good Android UI should s
There are now a few separate side-projects that all depend on and integrate
with GNU APL:
- Emacs mode
- Thomas' javascript port
- SQL API
- Possible Android port?
These ports are spread over different source repositories (I'm not even
sure where I can find the javascript port) it's g
I haven't looked. I believe there is a J port, and I heard about an APL as
well.
HTML views can certainly be embedded, but I'd argue that it would not be
ideal to base an Android version on the Javascript port, but rather compile
the C++ code directly to native ARM code and put a Java-based user
i
Elias Mårtenson wrote:
> In related news, I've been thinking about how to best handle APL input on
> Android. I think this project screams for an Android port just about now.
>
> The rest of the work in getting the Android version running (porting the
> APL interpreter itself) should be fairly tri
Hi,
wouldn't the tablet approach be to draw the APL symbol with your finger
on the screen :-?
/// Jürgen [still keyboard user]
On 04/13/2014 03:38 PM, Elias Mårtenson wrote:
With the exception of the lack of popup keyboard, it's already so much
better than tryapl it's not even funny. :-)
Nice, and thanks! I was about to ask for this very thing. :-)
Regards,
Elias
On 13 April 2014 21:39, Juergen Sauermann wrote:
> Hi,
>
> I have changed the NativeFunction class so that so that the
> called function (eval_AB(), eval_B(), ...) in the shared library
> can access the calling object
Hi,
I have changed the NativeFunction class so that so that the
called function (eval_AB(), eval_B(), ...) in the shared library
can access the calling object (of class NativeFunction).
This can be used if the called function wants to know, for example,
the name under which is was ⎕FX'ed in APL.
With the exception of the lack of popup keyboard, it's already so much
better than tryapl it's not even funny. :-)
Great work!
In related news, I've been thinking about how to best handle APL input on
Android. I think this project screams for an Android port just about now.
The rest of the work
Hi Thomas,
cool, even colors are working!
Some commands don't, for example ]KEYBOARD which could be useful
for users without proper APL keyboard setup.
Thank you for this.
/// Jürgen
On 04/13/2014 02:49 PM, Thomas Baruchel wrote:
Also, using the arrow keys to select from the command history
> Also, using the arrow keys to select from the command history would be neat.
Work in progress...
http://baruchel.hd.free.fr/apps/apl/i2/
I integrated the javascript code to http://terminal.jcubic.pl/
Full terminal emulation with readline-like arrow up/down history
I added the exciting free S
Hi Blake,
we have 2⎕TF to convert APL functions and APL variables to text vectors
("bytes") and back.
So all that is needed for a native APL SQL database given a generic SQL
database is to declare
the objects properly (BLOB) and to call 2⎕TF before writing to, or after
reading from, the databa
Hello Blake,
yes, thanks. Fixed in SVN 202.
/// Jürgen
On 04/12/2014 08:00 PM, Blake McBride wrote:
∇gg
[1] 4
[2] ∇
gg
4
x←gg
4
SYNTAX ERROR
x←gg
^ ^
I understand what is wrong with gg. The problem is the error message.
I think it is wrong. Shouldn't it be V
23 matches
Mail list logo
