Hi Hugh,
Thanks for your answer. I'm not convinced. You are telling that we
must define macros to make sql.h get the right type for SQLBIGINT.
Getting the right type (some alias for int64_t or a struct) is IMO
something that should be done by unixodb such that the application
gets a working
On 5/4/20 11:07 AM, Jonas Smedegaard wrote:
> If perhaps your reason for fusing ABIs is that you are not a fan of
> perl, then I would be happy to help write the perl code for a dh_* tool
> which handles all 4 ABIs.
It was a theoretical exercise. I'm not a fan of four virtual packages.
One is
Hi Lev,
On 5/3/20 6:32 PM, Lev Lamberov wrote:
Hi Jan and Jonas,
Чт 30 апр 2020 @ 20:36 Lev Lamberov :
So, my proposal is to have to following packages:
1. swi-prolog-core (with Core_system)
2. swi-prolog-core-packages (with Core_packages), depends on
swi-prolog-core
3. swi-prolog-nox
Hi Lev, Jonas,
I've uploaded 8.1.30. We should be getting really close to 8.2
now. There are a couple of outstanding issues, notably for the
development tools.
Cheers --- Jan
On 4/30/20 3:13 PM, Lev Lamberov wrote:
Sure, that's what we need. Thanks, Jan!
Hi Lev,
On 4/30/20 3:10 PM, Lev Lamberov wrote:
> Recently I was (again!) approached by some embedded developers who asked
> to provide Core_system as a separate package and try to break
> swi-prolog-nox into several smaller packages.
>
> Currently, I'm thinking about breaking it into
On 4/30/20 2:50 PM, Jonas Smedegaard wrote:
Quoting Lev Lamberov (2020-04-30 14:40:53)
Чт 30 апр 2020 @ 14:06 Jan Wielemaker :
On 4/30/20 1:41 PM, Jonas Smedegaard wrote:
I think we can use the format almost as-is - just replacing the
leading "swipl-" with "swi-prolog-abi-&quo
Hi Jonas,
In theory we could have a package that merely contains /usr/bin/swipl
and /usr/lib/libswipl.so.8.2.0. That is enough to run saved states
(provided they have been built such that no dependencies need to be
loaded at runtime) and is indeed a lot smaller than swi-prolog-nox.
Possibly
On 4/30/20 1:41 PM, Jonas Smedegaard wrote:
I think we can use the format almost as-is - just replacing the leading
"swipl-" with "swi-prolog-abi-".
I think adding "abi" makes sense. I can replace "swipl" with the
package name, which is "swi-prolog" for Debian.
--- Jan
Hi Jonas,
On 4/28/20 5:26 PM, Jonas Smedegaard wrote:
Quoting Jan Wielemaker (2020-04-28 16:56:30)
That is worth a try. I guess that implies that generating SWI-Prolog
(as package) also generates this hash. What kind of support would be
needed from SWI-Prolog to make this work? Some
Hi Jonas,
On 4/28/20 4:42 PM, Jonas Smedegaard wrote:
Hi Jan,
Quoting Jan Wielemaker (2020-04-28 16:12:32)
A saved state makes sense for this scenario. Now I do not really
understand what the problem is. The eye package depends on some exact
version of SWI-Prolog, but it is not uncommon
the query and then closing the process as the internal state
(e.g. the
> deductive closure of the forward reasoning run) is of no use to the next
> run.
>
> Kind regards,
> Jos
>
> -- https://josd.github.io/ <http://josd.github.io/>
>
>
> On Tue, Apr 28, 2020
On 4/28/20 5:06 PM, Lev Lamberov wrote:
Hi Jan,
Вт 28 апр 2020 @ 16:56 Jan Wielemaker :
Debian packaging of Asterisk and uWSGI uses such ABI hash towards third
party plugins, to alow them to be rebuilt as infrequently as possible.
See e.g. https://packages.debian.org/buster/uwsgi-plugin-php
Hi Lev,
I most wanted to get Jos in the loop as the developer of eye. Packagers
working together with developers/maintainers saves a lot of work :)
Cheers --- Jan
On 4/28/20 12:49 PM, Lev Lamberov wrote:
Hi Jan,
Вт 28 апр 2020 @ 11:22 Jan Wielemaker :
Hi Lev, Jos,
For Jos
Hi Eugeniy,
On 08/14/2015 10:15 AM, Eugeniy Meshcheryakov wrote:
Hi Jan,
The test suite was disabled in ppl so swi-prolog did migrate to testing.
I see Ubuntu also got this version. So it is not so bad anymore.
Great!
It would be good to fix this some time anyway. I may look at it this
Dear all,
I've returned from holidays. This issue seems a show stopper getting
SWI-Prolog 7.2 into Debian and its offspring. What is the status?
Can I help? Concerning the build fails on amd64, I guess I
can reproduce this.
Cheers -- Jan
On 07/23/2015 09:18 PM, Eugeniy
Hi Eugeniy,
No real clue. The stacktrace is definitely completely broken, I guess
because too much symbol data is missing. I guess the simplest step is
to make sure the compile flags include -g and possibly drop -O2 and
symbols are not stripped. Then we might get a stacktrace that indicates
Dear Ben,
Thanks for looking into this.
On Wed, 2010-12-08 at 01:30 +, Ben Hutchings wrote:
On Wed, 2010-12-08 at 00:11 +, Ben Hutchings wrote:
On Tue, 2010-12-07 at 21:13 +0100, Jan Wielemaker wrote:
[...]
Looks like a trivial bug, but I cannot find a report that indicates
Package: linux-image
Version: 2.6.32-5-amd64
Hi, Trying to debug ocfs2 issues, I noticed that the system.map file
doesn't match the kernel in the latest Squeeze version. Here are my
findings:
# dpkg -S /boot/System.map-2.6.32-5-amd64
linux-image-2.6.32-5-amd64: /boot/System.map-2.6.32-5-amd64
18 matches
Mail list logo
