Probably in the APL code with some support code in the library. The reason
for this is that a native library can only have a single entry point, and
that entry point has to be *either* an operator *or* a normal function.
It's a normal function now, and I have no intention of changing that.
Regards
On Mon, 2014-04-21 at 12:21 +0800, Elias Mårtenson wrote:
> I think that I should probably implement SQL∆with_transaction. It
> belongs in the SQL layer. It's also the only way to ensure that
> transaction rollback on error is handled correctly.
I agree that that's probably the right place to do i
Another change: Positional parameters are now always specified as ?
(question mark), regardless of underlying database. This should make
portable code easier.
Regards,
Elias
On 20 April 2014 23:53, Elias Mårtenson wrote:
> Another update. There is now a new command: SQL[8] which returns a list
I think that I should probably implement SQL∆with_transaction. It belongs
in the SQL layer. It's also the only way to ensure that transaction
rollback on error is handled correctly.
Regards,
Elias
On 21 April 2014 12:18, David B. Lamkins wrote:
> One more code drop...
>
> I've factored out the
One more code drop...
I've factored out the encode and decode routines to make it easier to
experiment with the storage format.
I've added a cf∆with_transaction operator to simplify transaction
support for applications that actually need it. This, I believe, is
useful since it lets the applicatio
Sigh: Or maybe not... The crash happens less often from the command
line, but it can still happen.
Uninitialized pointer...?
OK... I'm gonna stop reporting these crashes. Let me know if there's
anything I can do to help isolate the cause.
On Sun, 2014-04-20 at 14:20 -0700, David B. Lamkins wrote
Apologies: This problem only appears within an Emacs session using
gnu-apl-mode. It's not an APL bug; the problem does not manifest when
apl is run from the command-line.
Let me try to resynchronize gnu-apl and gnu-apl-mode; if there's still a
problem I'll report back.
On Sun, 2014-04-20 at 14:09
Here's another )load crash, this time with dump files. I'm running svn
218, clean build with a default ./configure.
This crash is trivial to reproduce. Create a dump file with only the
header line, i.e.:
-- begin test.apl --
#!/usr/local/bin/apl --script --
-- end test.apl --
... then:
)
On Sun, 2014-04-20 at 14:18 +0800, Elias Mårtenson wrote:
>
> Oh, and I'll be committing a fix within the next half hour that
> actually implements transaction support for SQLite. Please use these
> commands instead of directly calling begin/commit as SQL calls, since
> the library will keep trac
Here's one more update (see attached). Unless someone discovers an
egregious bug or I find an order-of-magnitude breakthrough on the
performance front (see below), this should be the last code drop for a
while.
+ I've made most functions return some value so they can be used in a
lambda.
+ I've
Thanks a lot!
On Sun, Apr 20, 2014 at 9:22 AM, Juergen Sauermann <
juergen.sauerm...@t-online.de> wrote:
> Hi Blake,
>
> I have added a few more ⎕CR variants, see SVN 218.
> I added a chapter to apl.info describing them.
>
> You may like 14 ⎕CR and its inverse ¯14 ⎕CR:
>
>
>
>
>
>
>
>
> *
Another update. There is now a new command: SQL[8] which returns a list of
all tables in the database.
Eventually SQL[9] will return a list of columns for a given table, but
that's less important for now.
Regards,
Elias
On 17 April 2014 23:52, Elias Mårtenson wrote:
> Latest update:
>
> The 2
Hi Elias,
I believe you can set CXXFLAGS before AC_CHECK_HEADER([term.h], [], [],
[]) like:
*CXXFLAGS=-I. -I**/usr/include/postgres
**AC_CHECK_HEADER([**libpq-fe**.h], [], [], []) *
If it fails then config.log tells you why. Alternatively you could call
AC_CHECK_HEADER again
if the first on
Hi David,
thanks. Hopefully fixed in SVN 218.
/// Jürgen
On 04/20/2014 05:03 AM, David B. Lamkins wrote:
When using 2⎕tf to encode a nested array in which the last element is a
character array of rank greater than one, the parentheses around the
denotation of that element are incorrectly omit
Hi Blake,
I have added a few more ⎕CR variants, see SVN 218.
I added a chapter to apl.info describing them.
You may like 14 ⎕CR and its inverse ¯14 ⎕CR:
* 14 ⎕CR 'Hello' 1 (2 3)
202000830701000320004000600020200020
00050401000548656c6
I've struggling with integrating the SQL stuff with Autoconf. My intent was
(and still, to some degree, is) to provide a simple patch for Jürgen.
But alas! My plan has been foiled! Bu that creature of the shadows that go
by the name Autoconf.
My question to anyone here (especially Jürgen) how can
Hi Vladimir,
I see. My point was just that the text of the warning, i.e. "comparison
is always true"
is wrong because it is, IMHO, not. And I hope that the optimizer in the
compiler does
not make the same assumption because that would lead to incorrect code.
/// Jürgen
On 04/20/2014 10:47 A
Juergen, I think whis warning is neither about compiler nor c standard.
It is about programmers' convention to use enum type to hold limited set
of values. Using enum for integer is not tricking the compiler, but
tricking other programmers who follow this convention (or even the self).
Most compile
18 matches
Mail list logo
