Re: [polyml] 5.7 Release

On 11/11/2017 10:41, Ramana Kumar wrote: OK, thanks. My impression of Git master is that there is often work-in-progress that should not be expected to work. Is it useful to report bugs while development is still in progress? For example, trying it now I saw this: Fail "Exception-

Re: [polyml] 5.7 Release

Hi Ramana, The fixes branches are useful in the early phase of the development cycle if bugs are found soon after a release. At some point it is no longer viable to keep back-porting especially if there is a risk that the fix itself may introduce bugs. This particular change was one of a

Re: [polyml] 5.7 Release

On 16/05/2017 04:47, Jerry James wrote: I attempted to build this version for Fedora. It succeeded on all architectures except aarch64: https://koji.fedoraproject.org/koji/taskinfo?taskID=19526061 I don't understand the failure, though. We run "make check" after the build to gain some

Re: [polyml] 5.7 Release

Hi Ramana, I was going to do that at some stage, perhaps when there was something to include, but I've done it now. Regards, David On 16/05/2017 04:33, Ramana Kumar wrote: Hi David, Is there going to be a fixes-5.7 branch as with previous releases? Cheers, Ramana On 13 May 2017 at 00:50,

Re: [polyml] 5.7 Release

Hi David, Is there going to be a fixes-5.7 branch as with previous releases? Cheers, Ramana On 13 May 2017 at 00:50, David Matthews wrote: > I've finally got round to releasing version 5.7. The source code was > actually tagged as 5.7 on Github a while ago and

[polyml] 5.7 Release

I've finally got round to releasing version 5.7. The source code was actually tagged as 5.7 on Github a while ago and Github considered that a release. There are Windows installers for 32-bit and 64-bit as well as the normal source code for everything else. I'm aware that there are still

Re: [polyml] 5.7 Release

Hi David, I can reproduce this (or at least a very similar issue) seemingly every time on 32-bit PowerPC. All three of my uploads to Debian failed to build on it (across different machines) and I can reproduce it on another box. It happens with both jessie and unstable; below is the state of

Re: [polyml] 5.7 Release

On 01/03/2017 13:31, Makarius wrote: On 01/03/17 13:55, David Matthews wrote: On 24/02/17 13:26, Makarius wrote: My current guess is that it is a problem of compiled ML code that is no longer garbage-collected. The current version does garbage collect code; it's just that it only happens at a

Re: [polyml] 5.7 Release

This is on Debian unstable (the soon-to-be-released Stretch should be close enough), but also amd64 in VirtualBox. Perhaps there have been some glibc changes? I couldn't reproduce it under my macOS host, which would be consistent with that. James > On 1 Mar 2017, at 15:48, David Matthews

Re: [polyml] 5.7 Release

On 01/03/17 13:55, David Matthews wrote: >> On 24/02/17 13:26, Makarius wrote: >> My current guess is that it is a problem of compiled ML code that is no >> longer garbage-collected. > > The current version does garbage collect code; it's just that it only > happens at a major GC. Previously

Re: [polyml] 5.7 Release

On 27/02/2017 22:55, Makarius wrote: On 24/02/17 13:26, Makarius wrote: We have strange memory management problems with Isabelle. (1) Poly/ML pre-5.7 requires a bit more heap space (tested for HOL, HOL-Library, HOL-Analysis), especially when running in parallel. This might explain the failure

Re: [polyml] 5.7 Release

On 24/02/17 13:26, Makarius wrote: > We have strange memory management problems with Isabelle. > > I've been using repository versions of Poly/ML privately during the past > few months, without seeing such problems. Only the official switch in >

Re: [polyml] 5.7 Release

On 21/02/17 13:48, David Matthews wrote: > The latest version, provisionally called 5.6.1, has had very little > change for several months. I'm not aware of any show-stoppers so I > think it would be a good time to make a release. Because there have > been some major changes I was planning to

Re: [polyml] 5.7 Release

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

Re: [polyml] 5.7 Release

Thanks. I've added BICArbitrary to the case and it seems to be fine now. David On 21/02/2017 19:19, James Clarke wrote: 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

Re: [polyml] 5.7 Release

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 running

Re: [polyml] 5.7 Release

I've not seen anything like that. I did a search to see if anyone else had had a crash in similar circumstances in other programs and interestingly the closest match was also in FreeBSD. It's difficult to know where the problem is. David On 21/02/2017 15:32, Kostirya wrote: it's also when

Re: [polyml] 5.7 Release

I sometimes get Segmentation fault on pure SML code (without FFI). Feels it's after main function finished. > gdb -c a.out.core a.out GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to

Re: [polyml] 5.7 Release

Thanks. That's now been done. David On 21/02/2017 14:30, James Clarke wrote: 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":

[polyml] 5.7 Release

The latest version, provisionally called 5.6.1, has had very little change for several months. I'm not aware of any show-stoppers so I think it would be a good time to make a release. Because there have been some major changes I was planning to call it 5.7. This is the last chance to do any