Logiciel Gambit | 18 Jun 2013 18:42
Mikael | 18 Jun 2013 17:51
Picon
Gravatar

Any procedure/debug way to see what objects reference an object?

Dear Marc,


I'm having a memory leak issue that takes hours and hours to resolve.

Is there any way to traverse the heap as to find the object that references a particular object?

E.g.  (object-references object) => referencing-objects-list


It's completely OK if it requires scanning all the heap :}

If it's not in Gambit already, I guess one such routine could be created easily-enough based on the GC mark routines.

Thanks,
Mikael

_______________________________________________
Gambit-list mailing list
Gambit-list <at> iro.umontreal.ca
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
egarrulo | 17 Jun 2013 14:06
Picon

Conformance to the R5RS

Hello everyone,

I'm a newcomer to Scheme and I was playing Gambit.

While fiddling around, I have stumbled upon a Scheme file whose goal
is to test an implementation's conformance to the R5RS:

http://sisc-scheme.org/r5rs_pitfall.scm

The Gambit interpreter passed all tests but the 8.3 (which could be a
feature: read the file for explanations) and saving for a warning,
whilst the Gambit compiler failed two more tests. Here is the
session:

---- TEST SESSION STARTS HERE
$ cat ~/.gambcini
(load "~~/lib/syntax-case")
$ gsi r5rs_pitfall.scm
...
Failure: 8.3, expected '1', got '2'.
Map is call/cc safe, but probably not tail recursive or inefficient.
$ gsc -exe r5rs_pitfall.scm
$ ./r5rs_pitfall
Failure: 1.1, expected '0', got '1'.
...
Failure: 1.3, expected '#t', got '#f'.
...
Failure: 8.3, expected '1', got '2'.
Map is call/cc safe, but probably not tail recursive or inefficient.
$ gsc -v
v4.6.8 20130430024640 i686-pc-linux-gnu "./configure
'--enable-single-host' '--enable-c-opt' '--enable-multiple-versions'
'--prefix=/home/egarrulo/bin/gambit/gambit-4.6.8'"
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-targets=all --with-arch-32=i586
--with-tune=generic --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8)
$ cat /etc/debian_version
6.0.7
---- TEST SESSION ENDS HERE

Any comments? Thanks for your attention.
publicityifl | 16 Jun 2013 20:58
Picon

Call for Papers IFL 2013

Hello,

Please, find below the second call for papers for IFL 2013.
Please forward these to anyone you think may be interested.
Apologies for any duplicates you may receive.

best regards,
Jurriaan Hage
Publicity Chair of IFL

CALL FOR PAPERS

25th SYMPOSIUM ON IMPLEMENTATION AND APPLICATION OF FUNCTIONAL LANGUAGES - IFL 2013

RADBOUD UNIVERSITY NIJMEGEN, THE NETHERLANDS
ACM In-Cooperation / ACM SIGPLAN

AUGUST 28 - 30 2013

"Landgoed Holthurnsche Hof"

http://ifl2013.cs.ru.nl

We are proud to announce that the 25th edition of the IFL series returns to its roots at 
the Radboud University Nijmegen in the Netherlands. The symposium is held from 28th 
to 30th of August 2013.

Scope
-----
The goal of the IFL symposia is to bring together researchers actively engaged in the 
implementation and application of functional and function-based programming languages. 
IFL 2013 will be a venue for researchers to present and discuss new ideas and concepts, 
work in progress, and publication-ripe results related to the implementation and 
application of functional languages and function-based programming. 

Following the IFL tradition, IFL 2013 will use a post-symposium review process to 
produce the formal proceedings which will be published in the ACM Digital Library. All 
participants of IFL 2013 are invited to submit either a draft paper or an extended 
abstract describing work to be presented at the symposium. At no time may work submitted 
to IFL be simultaneously submitted to other venues; submissions must adhere to 
ACM SIGPLAN's republication policy:

    http://www.sigplan.org/Resources/Policies/Republication

The submissions will be screened by the program committee chair to make sure they are 
within the scope of IFL, and will appear in the draft proceedings distributed at the 
symposium. Submissions appearing in the draft proceedings are not peer-reviewed 
publications. Hence, publications that appear only in the draft proceedings do not 
count as publication for the ACM SIGPLAN republication policy. After the symposium, 
authors will be given the opportunity to incorporate the feedback from discussions at 
the symposium and will be invited to submit a revised full article for the formal 
review process. From the revised submissions, the program committee will select papers 
for the formal proceedings considering their correctness, novelty, originality, 
relevance, significance, and clarity. 

Invited Speaker
---------------
Lennart Augustsson, currently employed by the Standard Chartered Bank, well-known for 
his work on Haskell, parallel Haskell, Cayenne, and Bluespec, is the invited speaker of 
IFL 2013. He will be talking about practical applications of functional programming. 

Submission Details
------------------
Submission deadline draft papers:                          July 31 
Notification of acceptance for presentation:               August 2 
Early registration deadline:                               August 7
Late registration deadline:                                August 14 
Submission deadline for pre-symposium proceedings:         August 21
25th IFL Symposium:                                        August 28-30 
Submission deadline for post-symposium proceedings:        November 11
Notification of acceptance for post-symposium proceedings: December 18
Camera-ready version for post-symposium proceedings:       February 3 2014 

Prospective authors are encouraged to submit papers or extended abstracts to be 
published in the draft proceedings and to present them at the symposium. All 
contributions must be written in English. Papers must adhere to the standard ACM two 
columns conference format. For the pre-symposium proceedings we adopt a 'weak' page limit
of 12 pages. For the post-symposium proceedings the page limit of 12 pages is firm. A 
suitable document template for LaTeX can be found at: 

    http://www.acm.org/sigs/sigplan/authorInformation.htm

Papers are to be submitted via the conference's EasyChair submission page: 

    https://www.easychair.org/conferences/?conf=ifl2013

Topics
------
IFL welcomes submissions describing practical and theoretical work as well as submissions
describing applications and tools in the context of functional programming. If you are 
not sure whether your work is appropriate for IFL 2013, please contact the PC chair at 
rinus <at> cs.ru.nl. Topics of interest include, but are not limited to:  

•  language concepts
•  type systems, type checking, type inferencing
•  compilation techniques
•  staged compilation
•  run-time function specialization
•  run-time code generation
•  partial evaluation
•  (abstract) interpretation
•  metaprogramming
•  generic programming
•  automatic program generation
•  array processing
•  concurrent/parallel programming
•  concurrent/parallel program execution
•  embedded systems
•  web applications
•  (embedded) domain specific languages
•  security
•  novel memory management techniques
•  run-time profiling performance measurements
•  debugging and tracing
•  virtual/abstract machine architectures
•  validation, verification of functional programs
•  tools and programming techniques
•  (industrial) applications

Peter Landin Prize
------------------
The Peter Landin Prize is awarded to the best paper presented at the symposium every 
year. The honoured article is selected by the program committee based on the submissions 
received for the formal review process. The prize carries a cash award equivalent to 
150 Euros. 

Programme committee
-------------------

•  Thomas Arts, Quviq, Gothenburg, Sweden
•  Andrew Butterfield, Trinity College, Dublin, Ireland
•  Edwin Brady, University of St. Andrews, UK
•  Clemens Grelck, University of Amsterdam, Netherlands
•  Adam Granicz, IntelliFactory, Budapest, Hungary
•  Jeremy Gibbons, University of Oxford, UK
•  Fritz Henglein, University of Copenhagen, Denmark
•  Stephan Herhut, Intel Labs, Santa Clara, US
•  Ralf Hinze (co-chair), University of Oxford, UK
•  Zoltán Horváth, Eötvös Loránd University, Budapest, Hungary
•  Zhenjiang Hu, University of Tokyo, Japan
•  Mauro Jaskelioff, Universidad Nacional de Rosario, Argentina
•  Johan Jeuring, University of Utrecht, Netherlands
•  Rita Loogen, University of Marburg, Germany
•  Marco T. Morazán, Seton Hall University, New Jersey, US
•  Dominic Orchard, University of Cambridge, UK
•  Rinus Plasmeijer (chair), Radboud University Nijmegen, Netherlands
•  Tim Sheard, Portland State University, US
•  Sam Tobin-Hochstadt, Northeastern University / Indiana University, US
•  Peter Thiemann, University of Freiburg, Germany
•  Simon Thompson, University of Kent, UK

Venue
-----
The 25th IFL is organized by the Radboud University Nijmegen, Model Based Software 
Development Department at the Nijmegen Institute for Computing and Information Sciences. 
The event is held in the Landgoed “Holthurnsche Hof”, a rural estate in the woodlands 
surrounding Nijmegen. It can be reached quickly and easily by public transport.
_______________________________________________
Gambit-list mailing list
Gambit-list <at> iro.umontreal.ca
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Hendrik Boom | 16 Jun 2013 17:19

An ancient legacy dialect

I have some thirty-year-old legacy code in what's best described as a
legacy dialect of Scheme.  The  important differences are:

* A different syntax for lists -- a slash can be used to introduce a 
final sublist of a list.  This reduces the piling up of lots of close 
brackets when a list's last element is a list whose last element is a 
list whose ... .

* A different syntax for 'let' that is to the regular 'let' as 'if' is 
to 'cond'.  This works well with the slash notation.

* Its own nonhygienic macro processor.

* No first-class continuations, though I wished I had them available 
thirty years ago.

The existing implementation is bootstrapped from a subset of itself, 
and involves an interpreter and translators to VAX assembly language.

I'd like to revive the legacy code that's written in that Scheme, and 
it seems that a good approach would be to it translate to Gambit, and 
thence to C.  Perhaps starting with the bootstrap code and being 
opportunistic after that.

Any suggestions as to a programmer-time efficient way to use or 
modify existing tools to accomplish that?

-- hendrik
Mikael | 16 Jun 2013 13:06
Picon
Gravatar

How allocate u8vectors from C safely&without memory leaks? (Noted ___EXT(___alloc_scmobj)(___sU8VECTOR, len, ___MOVABLE0) leaks 100%, that's used by the sqlite ffi etc.)

Dear Marc,

Just realized there's a memory leak in many Gambit libraries, such as the sqlite FFI - their u8vector allocation in C boils down to:

___result = ___EXT(___alloc_scmobj)(___sU8VECTOR,len,___MOVABLE0);



Studying ##make-u8vector of _kernel.scm provides some inspiration: It

 1) Shows that it's fine to use ___STILL

 2) Uses  ___still_obj_refcount_dec ,

 3) Has its C code in a ##c-code and not a ##c-lambda

 4) Has its surrounding Scheme code in (##declare (not interrupts-enabled))

 5) Surrounds the ___alloc_scmobj call by some magic (___FRAME_STORE_RA(___R0)___W_ALL ___R_ALL ___SET_R0(___FRAME_FETCH_RA) )

(##make-u8vector provides a code path for small objects apart from this, though the use regarded here should be for u8vectors of nontrivial size so going with the codepath for large objects should always be fine.)


By applying 1) and 2) I get something that works but can't know if it's really correct and safe:


How do you allocate an u8vector in C code in a way that does not leak memory, and that safely transfers the new object reference from the C world to the Scheme world?



Thanks!
Mikael


How to reproduce
Running a test that repeats

((c-lambda () scheme-object "___result = ___EXT(___alloc_scmobj)(___sU8VECTOR,10000,___MOVABLE0);"))

over and over e.g.

(##gc-report-set! #t)
(for-each (lambda (x) ((c-lambda () scheme-object "___result = ___EXT(___alloc_scmobj)(___sU8VECTOR,10000,___MOVABLE0);")))
          (string->list (make-string 100000))
(##gc)

shows that this memory leaks all the allocated memory (!).


Fix, duno if safe & complete

(##gc-report-set! #t)
(for-each (lambda (x) ((c-lambda () scheme-object "___result = ___EXT(___alloc_scmobj)(___sU8VECTOR,10000,___STILL);
                                                   if (!___FIXNUMP(___result)) ___still_obj_refcount_dec (___result);
                                                   ")))
          (string->list (make-string 100000))
(##gc)


Copy of ##make-u8vector of _kernel.scm for reference

(define-prim (##make-u8vector k #!optional (fill (macro-absent-obj)))
  (##declare (not interrupts-enabled))
  (let ((v (##c-code #<<end-of-code

long i;
long n = ___INT(___ARG1);
long words = ___WORDS(n) + 1;
___SCMOBJ result;
if (n > ___CAST(___WORD, ___LMASK>>___LF))
  result = ___FIX(___HEAP_OVERFLOW_ERR); /* requested object is too big! */
else if (words > ___MSECTION_BIGGEST)
  {
    ___FRAME_STORE_RA(___R0)
    ___W_ALL
    result = ___alloc_scmobj (___sU8VECTOR, n, ___STILL);
    ___R_ALL
    ___SET_R0(___FRAME_FETCH_RA)
    if (!___FIXNUMP(result))
      ___still_obj_refcount_dec (result);
  }
else
  {
    ___BOOL overflow = 0;
    ___hp += words;
    if (___hp > ___ps->heap_limit)
      {
        ___FRAME_STORE_RA(___R0)
        ___W_ALL
        overflow = ___heap_limit () && ___garbage_collect (0);
        ___R_ALL
        ___SET_R0(___FRAME_FETCH_RA)
      }
    else
      ___hp -= words;
    if (overflow)
      result = ___FIX(___HEAP_OVERFLOW_ERR);
    else
      {
        result = ___TAG(___hp, ___tSUBTYPED);
        ___HEADER(result) = ___MAKE_HD_BYTES(n, ___sU8VECTOR);
        ___hp += words;
      }
  }
if (!___FIXNUMP(result) && ___ARG2 != ___ABSENT)
  {
    for (i=0; i<n; i++)
      ___U8VECTORSET(result,___FIX(i),___ARG2)
  }
___RESULT = result;

end-of-code

            k
            fill)))
    (if (##fixnum? v)
      (begin
        (##raise-heap-overflow-exception)
        (##make-u8vector k fill))
      v)))

_______________________________________________
Gambit-list mailing list
Gambit-list <at> iro.umontreal.ca
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Mikael | 16 Jun 2013 02:53
Picon
Gravatar

What's the best practice for forcing (lambda () ..) to generate a unique closure object always?

Dear Marc,

How can I make Gambit always generate unique closure objects for (lambda () ...) ?

A (declare) to enforce this would do the job.


I'm having a table with test: eq? where the key is a closure and thus needs to guaranteedly be unique. This should be a perfectly valid usecase.

I noted that currently in compiled code (lambda () ...) not guaranteedly returns a unique closure object in certain circumstances: if a closure closes over no variables, or Gambit optimizes away all closed over variables so no variables are closed over that way, then it does not generate a unique closure.

This was quite surprising to me as my best understanding of R5RS spec (here & here) is that eq? should work on procedures:

"Each procedure created as the result of evaluating a lambda expression is (conceptually) tagged with a storage location, in order to make eqv? and eq? work on procedures (see section 6.1)."

Perhaps the wording could have been even more precise.


I acknowledge this Gambit optimization is really useful many times. Though there should be a way to disable it as it wouldn't be a reliable coding strategy to need to outsmart the optimizer for correct function.

Thanks!
Mikael


Example:

$ gsc
Gambit v4.6.6

> (let loop () (define x (lambda () 'myvalue)) (print x "\n") (loop))
#<procedure #2 x>
#<procedure #3 x>
#<procedure #4 x>
#<procedure #5 x>
[...]
[ctrl+c],q

$ echo (let loop () (define x (lambda () 'myvalue)) (print x "\n") (loop)) > test.scm
$ gsc
Gambit v4.6.6

> (compile-file "test.scm")
"test.o1"
> (load "test.o1")
#<procedure #2>
#<procedure #2>
#<procedure #2>
#<procedure #2>
#<procedure #2>
#<procedure #2>
#<procedure #2>
[...]

This

(let loop ((v 0)) (define x (lambda () v 'myvalue)) (print x "\n") (loop 1))

gives the same behavior. Note that the lambda closes over v, though the compiler optimizes it away.

Neither 

(let loop ((v 0)) (define x (lambda (z) (declare (not optimize-dead-local-variables)) v 'myvalue)) (print x "\n") (loop 1))

works, which may appear a bit surprising!


Here's a hack around the optimizer though:

(let loop ((v 0)) (define x (lambda (z) (case z ((never-happens) v) (else 'myvalue)))) (print x "\n") (loop 1))


_______________________________________________
Gambit-list mailing list
Gambit-list <at> iro.umontreal.ca
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Kartik Saranathan | 9 Jun 2013 22:27
Picon

Macro defined in .gambcini.scm

I want to make available a macro in the REPL.  The macro is also used by a utility function which I also want to use in the repl

;; ~/.gambcini.scm
(define first car)
(define-macro (mac . args)
  (first args))

(define (foo . args)
  (mac args))

The macro is purposely unquoted since it is meant to change structure of its argument

When I run gsi I get

*** ERROR IN ##raise-unbound-global-exception -- Unbound variable: first

I think this happens because the macro is expanded before first is defined.  How do I avoid this problem and still have foo and mac available in the repl?

Thanks

_______________________________________________
Gambit-list mailing list
Gambit-list <at> iro.umontreal.ca
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Marc Feeley | 9 Jun 2013 10:47
Picon
Gravatar

Gambit in the browser

I have been experimenting with the emscripten C to JavaScript compiler.  I have used it to compile the Gambit
interpreter into JavaScript.  This allows the Gambit interpreter to run in the browser!  Just direct your
browser to

    http://feeley.github.io/gambit-in-the-browser

Be patient... it can take 30 seconds to a minute to load the page (there's about 11 MB of JavaScript code).  Use
a fast JIT based browser if possible (Firefox or Chrome have been tested).

Marc
Bradley Lucier | 7 Jun 2013 21:38
Picon
Favicon

Gambit versus Python+GMP: Timing for Chudnovskys' algorithm for pi

Bakul Shah wrote a particularly elegant Scheme program for Chudnovskys' 
algorithm for pi based on the Common Lisp program here:

https://bitbucket.org/tarballs_are_good/numericl/src/5fe8fe7089f48ab1c8a388632f815fc35b4dec7e/src/experimental/pi-chudnovsky.lisp?at=default

Nick Craig-Wood wrote a Python program using the GMP multiprecision 
library that appears to use exactly the same algorithm here:

http://www.craig-wood.com/nick/articles/pi-chudnovsky/

I modified both programs a bit and include them here.

They time the calculation of $10^n$ digits of pi for $n=1,2,3,4,5,6,7$.  
The results are

heine:~/programs/gambiteer/gambit> !py
python pi_chudnovsky_bs_gmpy.py
31415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679
('chudnovsky_gmpy_mpz_bs: digits', 10, 'time', 1.0967254638671875e-05)
('chudnovsky_gmpy_mpz_bs: digits', 100, 'time', 3.0040740966796875e-05)
Last 5 digits 70679 OK
('chudnovsky_gmpy_mpz_bs: digits', 1000, 'time', 0.00025582313537597656)
Last 5 digits 01989 OK
('chudnovsky_gmpy_mpz_bs: digits', 10000, 'time', 0.00386810302734375)
Last 5 digits 75678 OK
('chudnovsky_gmpy_mpz_bs: digits', 100000, 'time', 0.0834801197052002)
Last 5 digits 24646 OK
('chudnovsky_gmpy_mpz_bs: digits', 1000000, 'time', 1.655979871749878)
Last 5 digits 58151 OK
('chudnovsky_gmpy_mpz_bs: digits', 10000000, 'time', 30.67442488670349)
Last 5 digits 55897 OK
heine:~/programs/gambiteer/gambit> gsi chud1.scm
Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits 
10, CPU time: 0..
Last 5 digits 26535.
Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits 
100, CPU time: 0..
Last 5 digits 70679.
Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits 
1000, CPU time: .004.
Last 5 digits 1989.
Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits 
10000, CPU time: .028.
Last 5 digits 75678.
Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits 
100000, CPU time: .472.
Last 5 digits 24646.
Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits 
1000000, CPU time: 6.448.
Last 5 digits 58151.
Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits 
10000000, CPU time: 98.612.
Last 5 digits 55897.

So it appears that for this algorithm applied to large integers, GMP's 
bignum routines are about 3-4 times as fast as Gambit's bignum 
routines.  Not so bad.  For smaller bignums, GMP has a bigger advantage.

The C program gmp-chudnovsky.c includes certain optimizations to this 
basic algorithm:

http://gmplib.org/pi-with-gmp.html
ftp://ftp.gmplib.org/pub/misc/gmp-chudnovsky.c

On my machine, compiled with

gcc -O3 -march=native -o gmp-chudnovsky gmp-chudnovsky.c -lgmp -lm

the CPU times for 1,000,000 and 10,000,000 digits are 1.064 and 18.200 
seconds, respectively.

This is with a somewhat older machine

model name    : Intel(R) Core(TM)2 Quad  CPU   Q8200   <at>  2.33GHz

running Ubuntu 13.04 with

heine:~/programs/gambiteer/gambit> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 
4.7.3-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs 
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.7 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib 
--enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--enable-gnu-unique-object --enable-plugin --with-system-zlib 
--enable-objc-gc --with-cloog --enable-cloog-backend=ppl 
--disable-cloog-version-check --disable-ppl-version-check 
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)
heine:~/programs/gambiteer/gambit> gsi -v
v4.6.9 20130607151908 x86_64-unknown-linux-gnu "./configure 
'--enable-single-host' '--enable-multiple-versions' '--enable-shared'"

and the Ubuntu-provided GMP 5.0.5.  (I'm sure the GMP folks have a 
better way to build GMP on my machine than the "generic" 64-bit version 
provided by Ubuntu.)

Brad
Attachment (gmp-chudnovsky.c): text/x-csrc, 15 KiB
Attachment (chud1.scm): text/x-scheme, 1813 bytes
Attachment (pi_chudnovsky_bs_gmpy.py): text/x-python, 2772 bytes
_______________________________________________
Gambit-list mailing list
Gambit-list <at> iro.umontreal.ca
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Marc Feeley | 7 Jun 2013 18:31
Picon
Gravatar

Re: Consistent, small program segmentation fault between 4.6.7 and 4.5.8


On Jun 7, 2013, at 8:50 AM, Bradley Lucier <lucier <at> math.purdue.edu> wrote:

> On 06/07/2013 11:29 AM, Marc Feeley wrote:
>> So I have pushed a commit which reverts this back until I can investigate further and see which one of the
uses of a signed integer were really required. Marc 
> 
> Marc:
> 
> You didn't really revert it, you replaced one hack with a more complicated hack.
> 
> Perhaps you should really revert it and then come up with a different solution for the problem the first
hack was trying to fix.  Some of the SIZE_Ts replaced unsigned longs, so you're losing more information the
more hacks you layer on top of each other.
> 
> Brad

No.  Where there used to be a use of "long" there is now ___SIZE_TS and where there used to be a use of "unsigned
long" there is now ___SIZE_T.  There is no loss of information.  It is true that it is not an actual "revert"
textually, but semantically it is.

I want to commit a change that will allow you and others to keep on working with the latest version of Gambit,
and at the same time serve as a reminder of the places I need to double check at a later time.  I think 99% of the
uses of ___SIZE_TS can be replaced with ___SIZE_T, but I haven't yet located the 1% where a signed type is
used (adn at that point I will rename to ___SSIZE_T, and remove the definition of ___SIZE_TS).

I did verify that chud1.scm now works.  So you should be able to continue with your work.

I would be interested in knowing if this commit fixes the memory management problems other people have
encountered lately.

Marc

Gmane