On 01/12/11 17:31, David Matthews wrote:
On 01/12/2011 16:09, Phil Clayton wrote:
I've just tried r1380 on my Fedora 15 x86_64 machine and have a couple
of things to report:
1. I get a build error (see output below) for foreign.cpp. Perhaps my C
compiler is more pedantic than most but it is ju
On 01/12/2011 16:09, Phil Clayton wrote:
I've just tried r1380 on my Fedora 15 x86_64 machine and have a couple
of things to report:
1. I get a build error (see output below) for foreign.cpp. Perhaps my C
compiler is more pedantic than most but it is just using the default
options. I think the
On 29/11/11 18:09, David Matthews wrote:
On 24/11/2011 17:34, Ian Zimmerman wrote:
Yes, it is quite common to have an autoconf option like
--with-system-libffi to force linking to an existing shared library. I
don't think there would be any objection to that.
I've now added libffi to the Poly/
On Tue, 29 Nov 2011, David Matthews wrote:
On 24/11/2011 17:34, Ian Zimmerman wrote:
Yes, it is quite common to have an autoconf option like
--with-system-libffi to force linking to an existing shared library. I
don't think there would be any objection to that.
I've now added libffi to the P
On 24/11/2011 17:34, Ian Zimmerman wrote:
Yes, it is quite common to have an autoconf option like
--with-system-libffi to force linking to an existing shared library. I
don't think there would be any objection to that.
I've now added libffi to the Poly/ML source. I was trying to find a
good
David> If libffi were like the C/C++ libraries and available
David> consistently on all platforms there would be no need to consider
David> including it in the source. However, it's becoming clear that on
David> a significant range of platforms using it would require users to
David> install libff
On 23/11/2011 07:35, Ian Zimmerman wrote:
David> I'm glad it works for you. When I tested it with Debian and
David> Ubuntu I had to install the development packages but otherwise it
David> went smoothly. I'm considering adding libffi to the poly source
David> since it's licensed under the B
On 22/11/2011 16:35, Phil Clayton wrote:
On 21/11/11 16:46, David Matthews wrote:
I have tried libffi 3.10.0 and the latest 3.11.0-rc2 and the seg fault
still occurs. I've attached a simple example but it's nothing special.
I can explain what is happening, but not ultimately why.
The seg fault
David> I'm glad it works for you. When I tested it with Debian and
David> Ubuntu I had to install the development packages but otherwise it
David> went smoothly. I'm considering adding libffi to the poly source
David> since it's licensed under the BSD licence.
Ian> I understand the appeal of thi
On 21/11/11 16:46, David Matthews wrote:
On 21/11/2011 14:19, Phil Clayton wrote:
On 21/11/11 11:33, David Matthews wrote:
This now works on Fedora 15 x86_64 without the symbolic links. I also
tested Fedora 12 x86_64 with and without the libffi-devel package and
both scenarios worked 'out of the
On 21/11/2011 16:45, Ian Zimmerman wrote:
David> I'm glad it works for you. When I tested it with Debian and
David> Ubuntu I had to install the development packages but otherwise it
David> went smoothly. I'm considering adding libffi to the poly source
David> since it's licensed under the B
David> I'm glad it works for you. When I tested it with Debian and
David> Ubuntu I had to install the development packages but otherwise it
David> went smoothly. I'm considering adding libffi to the poly source
David> since it's licensed under the BSD licence.
I understand the appeal of this sol
On 21/11/2011 14:19, Phil Clayton wrote:
On 21/11/11 11:33, David Matthews wrote:
This now works on Fedora 15 x86_64 without the symbolic links. I also
tested Fedora 12 x86_64 with and without the libffi-devel package and
both scenarios worked 'out of the box' i.e. no sym links required.
I also
On 21/11/11 11:33, David Matthews wrote:
On 18/11/2011 13:49, Phil Clayton wrote:
With Fedora, there is a minor configuration issue: like many packages,
libffi headers are not installed on a standard path, so relies on
pkg-config to supply cflags/libs arguments. I was able to build by
simply add
On 18/11/2011 13:49, Phil Clayton wrote:
With Fedora, there is a minor configuration issue: like many packages,
libffi headers are not installed on a standard path, so relies on
pkg-config to supply cflags/libs arguments. I was able to build by
simply adding symbolic links in /usr/include. After
On 18/11/2011 13:49, Phil Clayton wrote:
On 17/11/11 19:40, David Matthews wrote:
Well, having decided that the existing code is horrible I bit the bullet
and investigated libffi more closely. It turns out that it does
everything we need including callbacks. I've now modified the
foreign-functi
On 17/11/11 19:40, David Matthews wrote:
On 16/11/2011 20:27, Phil Clayton wrote:
On 16/11/11 18:27, David Matthews wrote:
On 16/11/2011 18:07, Phil Clayton wrote:
Right. Those preprocessor symbols are wrong. I think I changed them
elsewhere in the code and somehow those got missed. I think the
On 16/11/2011 20:27, Phil Clayton wrote:
On 16/11/11 18:27, David Matthews wrote:
On 16/11/2011 18:07, Phil Clayton wrote:
Right. Those preprocessor symbols are wrong. I think I changed them
elsewhere in the code and somehow those got missed. I think the issue is
that on X86/32 all arguments are
On 16/11/11 18:27, David Matthews wrote:
On 16/11/2011 18:07, Phil Clayton wrote:
The calling conventions for x86_64 appear to pass via registers not only
the initial floating point arguments but also the initial int/pointer
arguments:
http://en.wikipedia.org/wiki/X86_calling_conventions
So I su
On 16/11/11 17:59, David Matthews wrote:
On 16/11/2011 17:15, Makarius wrote:
On Wed, 16 Nov 2011, Rob Arthan wrote:
On 16 Nov 2011, at 15:17, Phil Clayton wrote:
I suspect those involved with large scale theorem proving will start
moving to 64 bit OSes, if not already, so one application ca
On 16/11/2011 18:07, Phil Clayton wrote:
The calling conventions for x86_64 appear to pass via registers not only
the initial floating point arguments but also the initial int/pointer
arguments:
http://en.wikipedia.org/wiki/X86_calling_conventions
So I suspect all arguments, not just floating poi
On 16/11/11 15:38, David Matthews wrote:
On 16/11/2011 15:17, Phil Clayton wrote:
On 16/11/11 11:17, David Matthews wrote:
On 16/11/2011 04:15, Ian Zimmerman wrote:
Phil> David, My situation is slightly unusual so perhaps it's
Phil> useful/interesting to explain some background. I'm working o
On 16/11/2011 17:15, Makarius wrote:
On Wed, 16 Nov 2011, Rob Arthan wrote:
On 16 Nov 2011, at 15:17, Phil Clayton wrote:
I suspect those involved with large scale theorem proving will start
moving to 64 bit OSes, if not already, so one application can address
more than 4GB memory, as that am
On Wed, 16 Nov 2011, Rob Arthan wrote:
On 16 Nov 2011, at 15:17, Phil Clayton wrote:
I suspect those involved with large scale theorem proving will start
moving to 64 bit OSes, if not already, so one application can address
more than 4GB memory, as that amount of physical memory is becoming
On 16 Nov 2011, at 15:17, Phil Clayton wrote:
> I suspect those involved with large scale theorem proving will start moving
> to 64 bit OSes, if not already, so one application can address more than 4GB
> memory, as that amount of physical memory is becoming quite common these days.
Seconded:
On 16/11/2011 15:17, Phil Clayton wrote:
On 16/11/11 11:17, David Matthews wrote:
On 16/11/2011 04:15, Ian Zimmerman wrote:
Phil> David, My situation is slightly unusual so perhaps it's
Phil> useful/interesting to explain some background. I'm working on
Phil> support for GLib/GTK in SML which
On 16/11/11 11:17, David Matthews wrote:
On 16/11/2011 04:15, Ian Zimmerman wrote:
Phil> David, My situation is slightly unusual so perhaps it's
Phil> useful/interesting to explain some background. I'm working on
Phil> support for GLib/GTK in SML which involves a significant number of
Phil> cal
On 16/11/2011 04:15, Ian Zimmerman wrote:
Phil> David, My situation is slightly unusual so perhaps it's
Phil> useful/interesting to explain some background. I'm working on
Phil> support for GLib/GTK in SML which involves a significant number of
Phil> calls to C functions.
Last I knew, this
Phil> David, My situation is slightly unusual so perhaps it's
Phil> useful/interesting to explain some background. I'm working on
Phil> support for GLib/GTK in SML which involves a significant number of
Phil> calls to C functions.
Last I knew, this was impossible in Poly/ML due to no callbacks f
David,
My situation is slightly unusual so perhaps it's useful/interesting to
explain some background. I'm working on support for GLib/GTK in SML
which involves a significant number of calls to C functions. These C
functions need wrapping to provide a suitable ML interface for various
reaso
Phil,
I think it could be possible to provide CInterface.null as a persistent
vol pointing to a value containing (void*)0. I know that seems a
contradiction but it should be possible. I'm just not sure it's
necessary. Why do you need to have "null" and "isNull"? Have you
considered instead
On 11/11/11 20:18, Phil Clayton wrote:
I am currently implementing
type t
val null : t
val isNull : t -> bool
where type t = CInterface.vol. There is no problem doing this but I
wondered whether I could improve the CInterface structure to avoid
annoying little C library functions.
I have realiz
I am currently implementing
type t
val null : t
val isNull : t -> bool
where type t = CInterface.vol. There is no problem doing this but I
wondered whether I could improve the CInterface structure to avoid
annoying little C library functions.
Would it be at all controversial to include
33 matches
Mail list logo
