On 4 Dec 2018, at 15:59,
wrote:
> On Tue, Dec 4, 2018 at 2:21 PM +0100, "David Matthews"
> wrote:
>> On 04/12/2018 13:00, Gergely Buday wrote:
>> > Hi,
>> >
>> > https://polyml.inf.ed.ac.narkive.com/c53BJE4q/run-out-of-store-interrupting-
>> > threads
>> >
>> > says that setting --maxheap wi
On 4 Dec 2018, at 13:00, Gergely Buday wrote:
>
> Hi,
>
> https://polyml.inf.ed.ac.narkive.com/c53BJE4q/run-out-of-store-interrupting-
> threads
>
> says that setting --maxheap with polyml can fix this problem.
>
> Does this memory allocation necessarily mean _physical_ memory allocation or
>
On 13 Nov 2018, at 15:24, Gergely Buday wrote:
>
> Hi there,
>
> running a CakeML bootstrapping process I got an error
>
> no space left on device
>
> Actually, the disk was not full but consumed all possible inodes:
>
> $ sudo df -i /
> [sudo] password for gbuday:
> Filesystem I
I've uploaded the current master to Debian's experimental suite, and so far
everything looks good[0] from my perspective.
James
[0] https://buildd.debian.org/status/package.php?p=polyml&suite=experimental
> On 20 Nov 2017, at 13:23, David Matthews
> wrote:
>
> Thanks to everyone who sent in
Without having looked at the code in question, that assertion seems somewhat
unusual; a typical in-range check has >= and <. Perhaps it's a bit naive, but
have you tried that?
James
> On 13 Nov 2017, at 16:32, Rob Arthan wrote:
>
> David,
>
> Thanks again, but I've got two ProofPower source
Or just 'apt-get install polyml'.
James
> On 1 May 2017, at 19:12,
> wrote:
>
> Building under Cygwin or with the official Linux subsystem gives you this.
>
> Michael
>
> On 1/5/17, 19:49, "polyml-boun...@inf.ed.ac.uk on behalf of Chris Cannam"
> wrote:
>
>Hello -- I'm wondering whet
se that only works for X86. If you
> can get me access to a real machine that would certainly help.
>
> I've already prepared a release of 5.7 and I'm inclined to go ahead with that
> anyway. There will almost certainly be other bug fixes to include so it's
> likely
sighandler.cpp:524
> #4 0x1fde7500 in start_thread () from /lib/powerpc-linux-gnu/libpthread.so.0
> #5 0x1ff339ac in clone () from /lib/powerpc-linux-gnu/libc.so.6
>
> Thread 1 (Thread 0xf7d25290 (LWP 1733)):
> #0 0x1fdf0138 in pthread_cond_timedwait@@GLIBC_2.3.2 () from
> /lib/
ck
> this down.
>
> David
>
> On 23/02/2017 20:44, James Clarke wrote:
>> Hi David,
>> It seems Test166 (the new condition variable one) sometimes deadlocks. I'm
>> able to reliably reproduce with the following:
>>
>>> ./configure
>>>
Hi David,
It seems Test166 (the new condition variable one) sometimes deadlocks. I'm able
to reliably reproduce with the following:
> ./configure
> make -j2 compiler
> make -j2 compiler
> while true; do make -j2 check; done
(The -j2's are probably irrelevant, but I'm including them for completen
Seems I forgot to include the mailing list; adding it back in.
James
> On 21 Feb 2017, at 19:14, James Clarke wrote:
>
> Hi David,
> I just uploaded the latest version to Debian's experimental suite[1], and it
> seems all the interpreted versions are failing when ru
The configure script needs to be regenerated from configure.ac.
James
> On 21 Feb 2017, at 14:17, Kostirya wrote:
>
> I think polyc is little broken.
> "polyc_CFLAGS" macro do not replaced on "-O3":
>
>> git pull && ./configure && make && make compiler && make install
> ...
>> grep polyc_CFLAG
> On 20 Sep 2016, at 16:42, Makarius wrote:
>
> On 20/09/16 16:50, Rob Arthan wrote:
>>
>> I think this patch fixes it:
>>
>> diff --git a/libpolyml/pexport.cpp b/libpolyml/pexport.cpp
>> index b03b1da..a9ebd2e 100644
>> --- a/libpolyml/pexport.cpp
>> +++ b/libpolyml/pexport.cpp
>> @@ -158,7 +1
You're not going mad; there used to be a release notes link:
http://web.archive.org/web/20150826013635/http://www.polyml.org/documentation/ReleaseNotes.html
That page says polyc was added in 5.5.1.
Regards,
James
> On 13 May 2016, at 15:33, Rob Arthan wrote:
>
> I have a recollection of a list
Linux (since 2.6.10) does have a WIFCONTINUED(status), which checks if status
== 0x; could this be the source of it?
James
> On 25 Apr 2016, at 14:07, David Matthews
> wrote:
>
> I've found something to suggest that the 255 value can come from an invalid
> value being passed to "exit".
on. I think the reason it doesn't at the moment is
> that there are three different "exporters", ELF, MachO and PECOFF and they
> all do it differently.
>
> David
>
>> On 09/03/2016 16:56, James Clarke wrote:
>> Hi,
>> I’ve been working on making P
Hi,
I’ve been working on making Poly/ML build reproducibly
(https://reproducible-builds.org), specifically the Debian package, although it
should be distro-agnostic. The first step was getting timestamps to be
deterministic using SOURCE_DATE_EPOCH (see
https://reproducible-builds.org/docs/times
he rounding mode for the
> SSE2 floating point unit. Currently Poly/ML uses the legacy x87 floating
> point unit even in 64-bit mode. That's on my TODO list.
>
> If you can check that it all works on the machines you were testing that
> would be helpful.
>
> Regards
Hi David (cc’d mailing list back in),
Of course "bytes 00 00 00 00 00 followed by 00 00 00/01/02" is meant to be
"bytes 00 00 00 00 followed by 00 00 00 00/01/02".
Regards,
James
> On 26 Jan 2016, at 14:13, James Clarke wrote:
>
> Hi David,
> I initially tried
Hi,
I notice you committed
https://github.com/polyml/polyml/commit/891e8122dcca36f9c2e9eea5a3eca7cf5de9f191.
However, as it stands, on armel the calls do not raise an exception like
https://github.com/polyml/polyml/pull/16, which could be misleading for the
user, as as far as they are aware set
includes a bit
of a cleanup which is potentially subjective, so if you disagree with any of
the changes I will happily change the pull request.
Regards,
James
> On 19 Jan 2016, at 22:57, James Clarke wrote:
>
> Hi David,
> I added the patch (locally) to the Debian 5.5.2 package; i
rule, which does nothing for Poly/ML. While I can override
this default behaviour in the package build script, I thought it would be a
good idea if Poly/ML followed the convention.
Thanks,
James
> On 19 Jan 2016, at 19:31, James Clarke wrote:
>
> Hi David,
> I had thought it might
Hi David,
I had thought it might be something like that, but a quick glance through
pexport didn’t enlighten me that much as I’m not familiar enough with the same
codebase.
Those were the same elfexport properties I had. I will try building on Sid and
see if it still crashes.
Thanks,
James
>
successfully. It does crash with some larger examples, such as
> Tests/Succeed/Test133.ML, and I've seen some other crashes in the
> garbage-collector. I suspect that there is a problem with endian-ness
> somewhere but it may be possible to narrow this down with gdb.
>
> Reg
very old version works on
big-endian mips; if so, I will try and do a git bisect, otherwise it might have
to be some painful debugging.
Regards,
James
> On 15 Jan 2016, at 11:59, James Clarke wrote:
>
> They are all big-endian. I haven't tried mipsel; that could help narrow i
Are
> these little-endian or big-endian? In theory the interpreter should work on
> both big-endian and little-endian but I've only tested the most recent
> version on X86. Have a look at an earlier version of Poly/ML and see if you
> have any more success with that.
>
et understand compressed debug
info; I removed a whole load of warnings to that effect)
Have you ever come across anything like this? Do you have any thoughts for
where to start with hunting this down?
Regards,
James Clarke
___
polyml mailing
> On 6 Jan 2016, at 13:41, David Matthews
> wrote:
>
> On 05/01/2016 05:51, Lucas Dixon wrote:
>> I recommend using github markdown in the repository for documentation. Make
>> a top level readme.md file and/or docs directory with documentation. This
>> makes it easy for others to submit pull re
Hi Rob,
install_pp has been deprecated for a while[1], with addPrettyPrinter[2] being
its replacement. Is there a reason you can't use that?
Regards,
James
[1]
http://www.polyml.org/documentation/Reference/PolyMLStructure.html#install_pp
[2]
http://www.polyml.org/documentation/Reference/PolyML
29 matches
Mail list logo
