Thanks. I will.
Blake
On Wed, May 7, 2014 at 10:59 PM, Elias Mårtenson wrote:
> OK, I've fixed it now, I think. Please test it.
>
> Regards,
> Elias
>
>
> On 8 May 2014 11:49, Blake McBride wrote:
>
>> Thanks a lot! That is what I was waiting for.
>>
>> Thanks!
>>
>> Blake
>>
>>
>>
>> On We
That's helpful. Thank you.
On Thu, 2014-05-08 at 10:25 +0800, Elias Mårtenson wrote:
> For my own workflow, I have set the Emacs variable
> "gnu-apl-libemacs-location" to point to the location of the .so file.
> This variable can be used to decouple the location of the library with
> the GNU APL
OK, I've fixed it now, I think. Please test it.
Regards,
Elias
On 8 May 2014 11:49, Blake McBride wrote:
> Thanks a lot! That is what I was waiting for.
>
> Thanks!
>
> Blake
>
>
>
> On Wed, May 7, 2014 at 10:48 PM, Elias Mårtenson wrote:
>
>> Oh yes. You're right about that. I should do that
Thanks a lot! That is what I was waiting for.
Thanks!
Blake
On Wed, May 7, 2014 at 10:48 PM, Elias Mårtenson wrote:
> Oh yes. You're right about that. I should do that. :-)
>
> Regards,
> Elias
>
>
> On 8 May 2014 11:47, Blake McBride wrote:
>
>> I thought: "The SQL library needs to be ch
Oh yes. You're right about that. I should do that. :-)
Regards,
Elias
On 8 May 2014 11:47, Blake McBride wrote:
> I thought: "The SQL library needs to be changed to support the new API."
>
>
> On Wed, May 7, 2014 at 10:21 PM, Elias Mårtenson wrote:
>
>> All right then. Just go ahead and use t
I thought: "The SQL library needs to be changed to support the new API."
On Wed, May 7, 2014 at 10:21 PM, Elias Mårtenson wrote:
> All right then. Just go ahead and use the library as-is.
>
> If we change something later, a simply search&replace should be easily
> applicable to your code. :-)
All right then. Just go ahead and use the library as-is.
If we change something later, a simply search&replace should be easily
applicable to your code. :-)
Regards,
Elias
On 8 May 2014 11:20, Blake McBride wrote:
> I usually use function names (at least starting) in uppercase, and
> applicat
I usually use function names (at least starting) in uppercase, and
application specific functions in lowercase. This way I avoid name hits
between my generic utilities and the application code. At least it splits
those two namespaces.
Just an opinion.
Thanks!
Blake
On Wed, May 7, 2014 at 10
I haven't decided what to do yet. I'd like to have some input from others
as to what's the best naming style is. All-lowercase? Upper and lower like
the SQL mode now? camelCase?
Regards,
Elias
On 8 May 2014 11:16, Blake McBride wrote:
> Any luck on getting the SQL library up-to-date? (I'd lik
Any luck on getting the SQL library up-to-date? (I'd like to start work on
the keyed file system, but I am waiting on this fix.)
Thanks!
Blake
On Sun, May 4, 2014 at 2:12 AM, Elias Mårtenson wrote:
> The SQL library needs to be changed to support the new API. I will fix
> this soon (within a
This was reported in this thread:
https://github.com/lokedhs/gnu-apl-mode/issues/7
This problem seems to be caused by a bug in GNU APL. When the user calls
)LOAD to load a workspace, the start_input callback function is not called
before control is returned back to the user.
(because of this, the
There is such a warning, but it only tells you if the opposite is true; if
your native library is newer than the Lisp code. I can't warn the other
way, because the lisp code can update from MELPA without the user upgrading
GNU APL itself.
For my own workflow, I have set the Emacs variable "
gnu-ap
Previously I said "OK I spent some time digging around and maybe I understand a
bit more."
and also "Not totally confident that I have analyzed this correctly. What do
you think?"
Well here is a better analysis which I do feel more confident about.
The version of gettext I had previously instal
'lib_file_io' ⎕fx 'pkg⍙fileio'
pkg⍙fileio
)erase pkg⍙fileio
'lib_file_io' ⎕fx 'pkg⍙fileio'
pkg⍙fileio
pkg⍙fileio⍬
VALUE ERROR
pkg⍙fileio⍬
^
As one of the folks who likes to use gnu-emacs-mode updates (as opposed
to the older version that's bundled with gnu-apl), I have separate
working directories for gnu-apl and gnu-emacs-mode.
Maybe there's an easier way, but here's what I've been doing to
reinstall the latest gnu-apl-mode native co
Speaking of the Emacs mode. The latest version supports tab-expansion of
user-defined commands. Thank Jürgen for providing me with the necessary
information to make this possible.
Regards,
Elias
On 8 May 2014 00:19, David B. Lamkins wrote:
> I had to ponder this for a few moments, since I've b
I had to ponder this for a few moments, since I've become so accustomed
to working with APL scripts rather than workspaces. (Kudos to Elias for
gnu-apl-mode!)
Of course it makes perfect sense that you wouldn't want to wipe out your
]USERCMD definitions when (re) )LOADing a workspace from an xml fi
The way configure is supposed to work is that it tests if it's possible to
build with a library, and it will deselect it if it doesn't work.
Also, as far as I can tell, this issue only occurs if one has built gettext
prior to upgrade to 10.9. In this particular case, it seems reasonable for
config
We probably want to do that at some time anyway but IMHO a simpler solution is
to make
the default in configure be --without-nls. Particularly in view of Jürgen's
comments.
So if somebody wants NLS they have to be intentional. Either way it's no big
deal
to just add it or remove it at ./configur
How about we build an binary package for OSX? Another alternative is a
Hombrew recipe.
Regards,
Elias
On 7 May 2014 19:22, "Juergen Sauermann"
wrote:
> Hi Peter,
>
> when I first looked at internationalization my impression was that it
> could be a good idea,
> in particular for ⎕NLT.
>
> After
Hi Peter,
when I first looked at internationalization my impression was that it
could be a good idea,
in particular for ?NLT.
After that saw a number of problems with translation and locales, and I
was several times
close to removing it again (and I may actually do that at some point in
time
Hi Peter,
thanks, should be fixed in SVN 250.
/// Jürgen
On 05/03/2014 07:41 PM, Peter Teeson wrote:
Hi Jürgen:
..GNUAPL/apl-svn/src/Logging.cc:32:11: Enumeration values 'LID_NONE' and
'LID_MAX' not handled in switch
..GNUAPL/apl-svn/src/Logging.cc:42:11: Enumeration values 'LID_NONE' and
'
Hi David,
I think they should because commands work outside of workspaces.
Think of one workspace installing commands and another using them.
You can ]USERCMD REMOVE-ALL to remove all commands.
/// Jürgen
On 05/06/2014 09:41 PM, David Lamkins wrote:
Thank you.
One more thing: ]usercmd defi
23 matches
Mail list logo
