On 08/03/21 19:37, David Matthews wrote:
On 08/03/2021 17:29, Phil Clayton wrote:
I note that the binaries using the compiled FFI still have a
dependency on libffi. Presumably configure.ac is yet to be updated to
make the checks on libffi conditional. (I rebuilt with libffi
configuration rem
On 08/03/2021 17:29, Phil Clayton wrote:
I note that the binaries using the compiled FFI still have a dependency
on libffi. Presumably configure.ac is yet to be updated to make the
checks on libffi conditional. (I rebuilt with libffi configuration
removed from 'configure' as per the attached
On 05/03/21 13:41, David Matthews wrote:
On 23/02/2021 13:00, Phil Clayton wrote:
Thanks for the updates. I have been testing the Poly/ML variants (see
below) and that fixes callbacks within callbacks on x86_64 provided
compact32bit is disabled. When compact32bit is enabled, I find that
any
On 23/02/2021 13:00, Phil Clayton wrote:
Thanks for the updates. I have been testing the Poly/ML variants (see
below) and that fixes callbacks within callbacks on x86_64 provided
compact32bit is disabled. When compact32bit is enabled, I find that any
use of a callback seg. faults, not just ne
On 22/02/21 15:34, David Matthews wrote:
I've pushed some changes which should have fixed most of these issues.
Thanks for reporting them.
Thanks for the updates. I have been testing the Poly/ML variants (see
below) and that fixes callbacks within callbacks on x86_64 provided
compact32bit is
I've pushed some changes which should have fixed most of these issues.
Thanks for reporting them.
On 22/02/2021 09:40, Phil Clayton wrote:
I hacked PolyFFICallbackException to print the exception (see attached)
and found that it was
Foreign "Cannot return a closure"
It's now obvious what's
I hacked PolyFFICallbackException to print the exception (see attached)
and found that it was
Foreign "Cannot return a closure"
It's now obvious what's going wrong now in call_c_test_15. The load
function for a closure conversion raises the exception to prevent a
call to C returning a closure
In testing callbacks during callbacks, I have also tried a rather
contrived example (attached) where the SML function closures to call
back are passed down as arguments. It's not something that I have
needed to do. I simply cannot get this to work with either 5.8.1 or the
latest version in ma
I have finally tried out the new FFI with Giraffe Library with partial
success. For some examples, calls to C and callbacks from C are working
but other examples result a seg. fault. From the debug output, I
noticed that the seg. faults occur when a callback occurs during a
callback. I've at
On 14/11/2020 12:10, David Matthews wrote:
> On 09/11/2020 17:01, David Matthews wrote:
>> What is needed is a hook so that when Foreign.library actually calls
>> Foreign.System.loadLibrary it first calls your function to get the path.
>> It would do this once immediately before calling "sha1_buf
On 09/11/2020 17:01, David Matthews wrote:
What is needed is a hook so that when Foreign.library actually calls
Foreign.System.loadLibrary it first calls your function to get the path.
It would do this once immediately before calling "sha1_buffer" for the
first time during any run.
I've a
On 07/11/2020 11:56, Makarius wrote:
The above problem is rather profane: I am using Foreign.loadLibrary with the
symbolic path "$ML_HOME/sha1.dll" (or .so), but that gets normalized at
compile-time. Later at run-time, the Isabelle directory hierarchy might have
been moved elsewhere (e.g. a user
On 04/11/2020 18:10, David Matthews wrote:
>
>> * Native x86_64_32-windows: building an image on one Windows server
>> installation and running it on another one (Windows 10) caused an error in
>> accessing the sha1.dll (different file location, potentially different load
>> addresses).
>
> Th
On 02/11/2020 17:05, Makarius wrote:
On 19/10/2020 13:12, David Matthews wrote:
Some problems encountered so far:
* Interpreted arm64-linux does not quite work. A statically compiled
Foreign.buildCall within the heap image causes the dynamic invocation to
"hang"; e.g. see https://isabelle-dev
On 19/10/2020 13:12, David Matthews wrote:
>
> Instead the foreign function interface is handled essentially as part of the
> compiler. The high-level interface in the Foreign structure remains unchanged
> but the buildCallN functions now actually compile interface functions. This
> results in f
чт, 22 окт. 2020 г. в 13:33, David Matthews :
> ./configure --disable-shared && make && make compiler
> now works on FreeBSD 32 without needing any other options.
Thanks.
But if I want to use gmp, then I still have to specify
env CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib
Without them
This appears to be a problem with allocating memory for the stack. The
call to mmap is failing with EINVAL but I can't see why. It's line 407
in libpolyml/osmemunix.cpp which adds MAP_STACK to the arguments. This
is necessary for OpenBSD which segfaults if the stack is not allocated
with MAP_ST
ср, 21 окт. 2020 г. в 15:23, David Matthews :
>
> On 21/10/2020 07:20, Kostirya wrote:
> > But now the 3G memory is not enough to build the git version of polyml:
> >
> > cp ./imports/polymli386.txt polytemp.txt
> > ./polyimport polytemp.txt -I . < ./exportPoly.sml
> >
> > Unable to create the ini
On 21/10/2020 07:20, Kostirya wrote:
But now the 3G memory is not enough to build the git version of polyml:
cp ./imports/polymli386.txt polytemp.txt
./polyimport polytemp.txt -I . < ./exportPoly.sml
Unable to create the initial thread - insufficient memory
This appears to be a problem with
Hello.
LDFLAGS="-Wl,-z -Wl,notext" is helped.
Thanks.
ld automatically links stdc++ on FreeBSD.
So I am doing:
sed -i.bak -e 's|-lstdc++ ||' configure
sed -i.bak -e 's| modules||' Makefile.in
And I build so:
env CFLAGS=-I/usr/local/include LDFLAGS="-L/usr/local/lib -Wl,-z
-Wl,notext" ./configu
On 20/10/2020 13:33, Kostirya wrote:
Hello.
I cannot build last git version on FreeBSD 32bit:
libtool: link: c++ -fPIC -DPIC -shared -nostdlib /usr/lib/crti.o
/usr/lib/crtbeginS.o .libs/arb.o .libs/bitmap.o .libs/check_objects.o
.libs/diagnostics.o .libs/errors.o .libs/exporter.o .libs/gc.o
.l
Hello.
I cannot build last git version on FreeBSD 32bit:
libtool: link: c++ -fPIC -DPIC -shared -nostdlib /usr/lib/crti.o
/usr/lib/crtbeginS.o .libs/arb.o .libs/bitmap.o .libs/check_objects.o
.libs/diagnostics.o .libs/errors.o .libs/exporter.o .libs/gc.o
.libs/gc_check_weak_ref.o .libs/gc_copy_p
Hi,
I've just pushed a collection of changes to master that have been in the
pipeline for quite a long time. Some of these are internal changes to
the run-time system and some are extensions, such as the addition of
IPv6 networking with INet6Sock and Net6HostDB structures.
The major change,
23 matches
Mail list logo
