Poly/ML June 2013

polyml@lists.polyml.org

6 participants
7 discussions

Inspecting structures
by ramana.kumar＠gmail.com 27 Jan '16

27 Jan '16

Is there a way to look at the contents (i.e. signature) of a structure without opening it? (I suppose you could just open it then call a lot of PolyML.Compiler.forgetXXX, but that's quite tedious) Also, is it possible to retrieve the long path of an identifier in scope? Something that will, for example, take the rev in scope and say that it came from List. Finally, what about searching for an identifier that would come into scope if you opened some structures?

3 5

[Fwd: Re: [polyml] Building Poly/ML on MacOS X 10.6]
by rda＠lemma-one.com 29 Dec '14

29 Dec '14

I wrote: > I am completely baffled. I thought I hada solved all my problems on > MacOS X > 10.6 and was just tidying up, when I had to recompile a 32 bit > version of > Poly/ML to test a tidied up make file. This failed because > PolyML.Compiler.printTypesWithStructureName no longer exists. The same > problem happened when i rebuild a 64 bit version. What has happened? but it was a false alarm: my make file was wrong for other reasons and the absence of PolyML.Compiler.printTypesWithStructureName was not relevant. No doubt there are good reasons why this variable has been withdrawn. Regards, Rob.

3 6

Sourceforge and SVN
by David.Matthews＠prolingua.co.uk 24 Jun '13

24 Jun '13

I have "upgraded" the Poly/ML site on SourceForge (there didn't seem to be any choice) and as a consequence the subversion site has changed. Anyone who is following Poly/ML SVN will need to change to the new site. For trunk this is svn checkout svn://svn.code.sf.net/p/polyml/code/trunk polyml and for the 5.5 fixes branch svn co svn://svn.code.sf.net/p/polyml/code/fixes-5.5 polyml I am currently working on the stages of the compiler that process and optimise the intermediate code. These are parts of the compiler that haven't been looked at for a very long time and some of it was obviously translated automatically from my original Poly code back in the 1980s. I tend to commit changes fairly regularly rather than accumulate a long set of changes and commit all at once. This does mean that things could be broken and only fixed by a later commit but it makes it much easier to find a bug if it shows up much later. Season's greetings and best wishes for the New Year, David

3 5

ArraySlice.copy is inefficient
by peter.lammich＠uni-muenster.de 20 Jun '13

20 Jun '13

Hi all, (Referring to "PolyML 5.5.0 release") I am trying to copy the initial part of an array into another array, something like OCamls: "Array.blit src 0 dst 0 len" In PolyML, I have Array.copy, that copies the whole array, i.e., fixes len=length src, which is to restrictive for my purpose. I can solve my problem with "ArraySlice.copy {src=ArraySlice.slice(src,0,SOME len),di=0,dst=dst}" However, this solution has very poor performance. Looking at the code, it becomes clear why: Array.copy is implemented natively by "move_words", however, ArraySlice.copy is implemented as a recursive function inside ML. This is a performance difference of roughly two orders of magnitude! There is a comment on ArraySlice.copy that "We can't use System_move_words because of the potential overlap problem." However, looking at the implementations of move_words, I find: x86asm.asm: ;# Must deal with the case of overlapping segments correctly. (which the implementation there does) run_time.cpp: memmove(dest, source, words*sizeof(PolyWord)); /* must work for overlapping segments. */ (which it does according to C++ specification) Nevertheless, a quick test reveals that System_move_words does not work for overlapping memory! What am I missing? So, this results in a few questions: 1) Is there a fast solution two my problem within the SML-standard, where I can even assume that src and dst are different arrays? 2) Can ArraySlice.copy be patched to use System_move_words after a check that the arrays are actually not the same? 3) Where is the code executed by System_move_words, and can this be fixed to correctly handle overlapping segments? Best, Peter

2 4

Large file support
by loganjerry＠gmail.com 13 Jun '13

13 Jun '13

Greetings, Fedora is planning to switch to btrfs as the default filesystem at some future point. This may cause problems for some 32-bit applications, because btrfs uses 64-bit inode numbers (see [1], for example). This can cause stat() calls to fail with EOVERFLOW, just because the inode number doesn't fit into the 32-bit stat structure, even if the caller doesn't care about the inode number. I'm attaching a candidate patch for polyml to avoid this issue. It enables large file support on systems where that makes sense, which builds with a 64-bit stat structure on 32-bit systems, and makes some types (such as off_t) larger. I seem to have a different version of automake than you, so I am not including the generated files in this patch. While you're changing stuff, though, may I suggest dropping AC_FUNC_SETVBUF_REVERSED from configure.ac? Autoconf complains that it is obsolete, and the one use of setvbuf() in the code ignores the results of this test anyway. References: [1] http://permalink.gmane.org/gmane.comp.file-systems.btrfs/10374 Regards, -- Jerry James http://www.jamezone.org/

2 1

Suspicious memset in 5.5
by loganjerry＠gmail.com 11 Jun '13

11 Jun '13

Greetings, I maintain the polyml package for the Fedora Linux distrubtion. I was just doing a build with the latest addition to polyml-5.5-fixes when I spotted this compiler output: elfexport.cpp: In member function 'virtual void ELFExport::exportStore()': elfexport.cpp:612:31: warning: argument to 'sizeof' in 'void* memset(void*, int, size_t)' call is the same pointer type '_memTableEntry*' as the destination; expected '_memTableEntry' or an explicit length [-Wsizeof-pointer-memaccess] memset(memTable, 0, sizeof(memTable)); So only the first pointer-length bytes of memTable are being cleared. Shouldn't that be: memset(memTable, 0, sizeof(*memTable) * memTableEntries); ? Regards, -- Jerry James http://www.jamezone.org/

2 1

crashes
by michael.norrish＠nicta.com.au 07 Jun '13

07 Jun '13

Using PolyML 5.5.0 as downloaded from Sourceforge, we can reliably produce: Exception- InternalError: indirect - invalid constant address raised while compiling Exception- InternalError: indirect - invalid constant address raised while compiling We can also regularly, but somewhat less reliably, produce hol.builder: gc_mark_phase.cpp:199: bool MTGCProcessMarkPointers::ForkNew(PolyObject*): Assertion `marker != 0' failed. Aborted (core dumped) where hol.builder is the name of our dumped heap. Are there any obvious things we can try to get around these problems? Thanks, Michael

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Poly/ML June 2013