May 2021 - Gambit-list - mailman.iro.umontreal.ca

Gambit versus Python+GMP: Timing for Chudnovskys' algorithm for pi
by Bradley Lucier 08 Apr '22

08 Apr '22

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/5fe8fe7089f48ab1c8a388… 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 @ 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

7 18

building git master fails
by Jörg F. Wittenberger 04 Jun '21

04 Jun '21

trying to build the master branch from githug fails I followed the steps from INSTALL.txt section 1 §2 (wget ...gambit-4_9_3-devel.tar.gz et.c) followed ./configure --enable-single-host --prefix=~/test make make bootstrap git pull make realclean # again: ./configure --enable-single-host --prefix=~/test make ---- The resulting ___CHARALPHABETICP being undefined I solved by adding a line to config.h.in: #define ___USE_C_RTS_CHAR_OPERATIONS But the "Ill-placed 'declare'" in _num.scm line 5525 is above my head. Looks an issue with `define-prim&proc` -- but I don't understand it. Any help appreciated. best Jörg

3 3

compiling for arm android on linux
by Sonny To 25 May '21

25 May '21

How to compile a simple hello world program on x86 to arm for android? --- hello.scm --- (define wassup (lambda () (display "hello from scheme\n"))) (wassup) ---end hello.scm--- % gsc -exe -target arm hello.scm % adb push ./hello /data/local/tmp % adb shell /data/local/tmp/hello /system/bin/sh: /data/local/tmp/hello: not executable: 64-bit ELF file % file hello hello: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=64cb09b1432959e8f4f9734d72e99580f6091497, for GNU/Linux 3.2.0, with debug_info, not stripped This doesn't like the -target option is generating an ARM binary. I tried to take a different route by generating C code like this but I can't even compile the generated C code on linux x86: % gsc -c hello.scm % gcc hello.c $GAMBIT_HOME/lib/libgambit.a $GAMBIT_HOME/lib//libgambitgsc.a $GAMBIT_HOME/lib/libgambitgsi.a -I$GAMBIT_HOME/include -lm /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o: in function `_start': (.text+0x24): undefined reference to `main' /usr/bin/ld: /tmp/ccWylAo9.o: in function `___H_hello_23_': hello.c:(.text+0xb4): undefined reference to `___G_wassup' /usr/bin/ld: hello.c:(.text+0x108): undefined reference to `___G_wassup' /usr/bin/ld: hello.c:(.text+0x186): undefined reference to `___G_wassup' /usr/bin/ld: /tmp/ccWylAo9.o: in function `___setup_mod': hello.c:(.text+0x3d4): undefined reference to `___G_hello_23_' /usr/bin/ld: /tmp/ccWylAo9.o: in function `___init_mod': hello.c:(.text+0x400): undefined reference to `___G_hello_23_' /usr/bin/ld: /tmp/ccWylAo9.o: in function `___LNK_hello': hello.c:(.text+0x41a): undefined reference to `___S_hello' /usr/bin/ld: hello.c:(.text+0x428): undefined reference to `___S_hello_23_' /usr/bin/ld: /usr/local/gambit/lib/libgambit.a(os_dyn.o): in function `___dynamic_load': os_dyn.c:(.text+0x1b0): undefined reference to `dlopen' /usr/bin/ld: os_dyn.c:(.text+0x1c8): undefined reference to `dlsym' /usr/bin/ld: os_dyn.c:(.text+0x2d9): undefined reference to `dlerror' /usr/bin/ld: os_dyn.c:(.text+0x305): undefined reference to `dlclose' /usr/bin/ld: /usr/local/gambit/lib/libgambit.a(os_dyn.o): in function `___cleanup_dyn_module': os_dyn.c:(.text+0x4db): undefined reference to `dlclose' /usr/bin/ld: /usr/local/gambit/lib/libgambit.a(os_io.o): in function `___device_stream_setup_from_process': os_io.c:(.text+0x3592): undefined reference to `openpty' collect2: error: ld returned 1 exit status How do I compile the generated C code? Thanks for any help

4 5

FFI/c-define-type is fine with the C++ std::shared_ptr RAII type?
by Phillip Suero 20 May '21

20 May '21

Dear Marc, I was thinking, is the FFI (|c-define-type|) compatible with the C++ RAII in such a way that C++'s std::shared_ptr can be used as (c-define-type my-struct-shared "shared_ptr<my_struct>")? shared_ptr is a refcounted slot, where the +1 and -1 refcount update is carried out by the RAII. If I would not pass the std::shared_ptr as (c-define-type my-struct-shared "shared_ptr<my_struct>"), then instead I would wrap it in a C/C++ struct which then contains the std::shared_ptr as its only slot. Please let me know your thoughts on what's the best approach. Here is a test case: (c-declare #<<c-declare-end #include <memory> typedef struct my_struct { int value; } my_struct; using namespace std; c-declare-end ) (c-define-type my-struct-shared "shared_ptr<my_struct>") (define (make-my-struct) (c-lambda () my-struct-shared #<<c-lambda-end std::shared_ptr<my_struct> out = std::make_shared<my_struct>(); out->value = 0; ___return(out); c-lambda-end )) (make-my-struct) Gambit v4.9.3 > (load "shared_ptr") "/path/to/shared_ptr.o2" > (make-my-struct) #<procedure #2 shared_ptr#0> > (define a (make-my-struct)) > a #<procedure #2 shared_ptr#0> At least it does compile! Looking forward to your confirmation if this is safe & best practice. ( When I skip the "using namespace std;" and prepend "std::" to (c-define-type my-struct-shared "shared_ptr<my_struct>"), I do get weird compiler errors however. ) Phil

1 0

API to parse floats in Scheme
by Lassi Kortela 12 May '21

12 May '21

We are planning a simple SRFI to mae floats from integers (or from strings), since that's useful when parsing any kind of text syntax that has real numbers. The details are implementation-dependent and tricky to get right. Here's the spec we have so far: https://github.com/pre-srfi/make-float The API is: (inexact-real-from-strings int frac precision exp) -> real (inexact-real-from-integers int frac frac-length precision exp) -> real Example usage: (inexact-real-from-strings "-123" "45" 'e "6") ; => -123.45e6 (inexact-real-from-integers -123 45 2 'e 6) ; => -123.45e6 The 2 in the last example means two decimal places. It's needed to disambiguate between .6 .06 .006 .0006 etc. There are both math and Scheme wizards on this list. Could someone verify whether this is a sane design before we submit the SRFI draft? It's been ok'd by one mathematician already so I'm hopeful :) There's also an inverse API to serve as a backend for string formatting packages: (strings-from-inexact-real real frac-length) -> int; frac; exp (integers-from-inexact-real real frac-length) -> int; frac; exp

4 7

CFP: SLE 2021 - 14th ACM SIGPLAN International Conference on Software Language Engineering
by Andrei Chis 12 May '21

12 May '21

------------------------------------------------------------------------ 14th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2021) October 17-19, 2021 Chicago, Illinois https://conf.researchr.org/home/sle-2021 http://www.sleconf.org/2021 Follow us on twitter: https://twitter.com/sleconf ------------------------------------------------------------------------ We are pleased to invite you to submit papers to the 14th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2021), held in conjunction with SPLASH, GPCE and SAS 2021. Based on the future developments the conference will be hosted in Chicago, Illinois, United States on October 17-19, 2021 or will be held as a virtual event. --------------------------- Scope --------------------------- The ACM SIGPLAN International Conference on Software Language Engineering (SLE) is devoted to the principles of software languages: their design, their implementation, and their evolution. With the ubiquity of computers, software has become the dominating intellectual asset of our time. In turn, this software depends on software languages, namely the languages it is written in, the languages used to describe its environment, and the languages driving its development process. Given that everything depends on software and that software depends on software languages, it seems fair to say that for many years to come, everything will depend on software languages. Software language engineering (SLE) is the discipline of engineering languages and their tools required for the creation of software. It abstracts from the differences between programming languages, modelling languages, and other software languages, and emphasizes the engineering facet of the creation of such languages, that is, the establishment of the scientific methods and practices that enable the best results. While SLE is certainly driven by its metacircular character (software languages are engineered using software languages), SLE is not self-satisfying: its scope extends to the engineering of languages for all and everything. Like its predecessors, the 14th edition of the SLE conference, SLE 2021, will bring together researchers from different areas united by their common interest in the creation, capture, and tooling of software languages. It overlaps with traditional conferences on the design and implementation of programming languages, model-driven engineering, and compiler construction, and emphasizes the fusion of their communities. To foster the latter, SLE traditionally fills a two-day program with a single track, with the only temporal overlap occurring between co-located events. --------------------------- Topics of Interest --------------------------- SLE 2021 solicits high-quality contributions in areas ranging from theoretical and conceptual contributions, to tools, techniques, and frameworks in the domain of software language engineering. Broadly speaking, SLE covers software language engineering rather than engineering a specific software language. Topics of interest include, but are not limited to: * Software Language Design and Implementation - Approaches to and methods for language design - Static semantics (e.g., design rules, well-formedness constraints) - Techniques for specifying behavioral / executable semantics - Generative approaches (incl. code synthesis, compilation) - Meta-languages, meta-tools, language workbenches * Software Language Validation - Verification and formal methods for languages - Testing techniques for languages - Simulation techniques for languages * Software Language Integration and Composition - Coordination of heterogeneous languages and tools - Mappings between languages (incl. transformation languages) - Traceability between languages - Deployment of languages to different platforms * Software Language Maintenance - Software language reuse - Language evolution - Language families and variability * Domain-specific approaches for any aspects of SLE (design, implementation, validation, maintenance) * Empirical evaluation and experience reports of language engineering tools - User studies evaluating usability - Performance benchmarks - Industrial applications --------------------------- Important Dates --------------------------- All dates are Anywhere on Earth. * Mon 5 Jul 2021 - Abstract Submissions * Fri 9 Jul 2021 - Paper Submissions * Wed 1 Sep 2021 - Review Notification * Wed-Fri 1-3 Sep 2021 - Author Response Period * Mon 13 Sep 2021 - Notification * Wed 15 Sept 2021 - Artifact Submissions * Tue 28 Sep 2021 - Artifact Kick-the-tires Author Response * Tue 12 Oct 2021 - Artifact Notification * Sun-Tue 17-19 Oct 2021 - SLE Conference --------------------------- Types of Submissions --------------------------- SLE 2021 solicits three types of papers: * Research papers These are "traditional" papers detailing research contributions to SLE. These papers have a limit of 12 pages, and may optionally include 8 further pages of bibliography/appendices * Tool papers These are papers which focus on the tooling aspects which are often forgotten or neglected in research papers. A good tool paper focuses on practical insights that are likely to be useful to other implementers or users in the future. Any of the SLE topics of interest are appropriate areas for tool demonstrations. Submissions must not exceed 5 pages and may optionally include 1 further page of bibliography / appendices. They may optionally come with an appendix with a demo outline / screenshots and/or a short video/screencast illustrating the tool. The title of a Tool paper must start with "Tool Demo:". *New ideas / vision papers These are papers on forward-looking, innovative research in software language engineering. Our aim here is to accelerate the exposure of the software language engineering community to early yet potentially ground-breaking research results, or to techniques and perspectives that challenge the status quo in the discipline. New ideas / vision papers must not exceed 5 pages, and may optionally include 1 further page of bibliography / appendices. The title of a new ideas / vision papers must start with "New Ideas:" or "Vision:". --------------------------- Artifact Evaluation --------------------------- For the sixth year, SLE will use an evaluation process for assessing the quality of the artifacts on which papers are based to foster the culture of experimental reproducibility. Authors of accepted papers are invited to submit artifacts. For more information, please have a look at the Artifact Evaluation page (http://www.sleconf.org/2021/ArtifactEvaluation.html) --------------------------- Submission --------------------------- Submissions have to use the ACM SIGPLAN Conference Format “acmart” ( http://sigplan.org/Resources/Author/#acmart-format) please make sure that you always use the latest ACM SIGPLAN acmart LaTeX template( https://www.acm.org/binaries/content/assets/publications/consolidated-tex-t…) and that the document class definition is \documentclass[sigplan,anonymous,review]{acmart}. Do not make any changes to this format! Ensure that your submission is legible when printed on a black and white printer. In particular, please check that colors remain distinct and font sizes in figures and tables are legible. To increase fairness in reviewing, a double-blind review process has become standard across SIGPLAN conferences. In this line, SLE will follow the double-blind process. Author names and institutions should be omitted from submitted papers, and references to the authors’ own related work should be in the third person. No other changes are necessary, and authors will not be penalized if reviewers are able to infer their identities in implicit ways. All submissions must be in PDF format. Concurrent Submissions: Papers must describe unpublished work that is not currently submitted for publication elsewhere as described by SIGPLAN’s Republication Policy ( http://www.sigplan.org/Resources/Policies/Republication) Submitters should also be aware of ACM’s Policy and Procedures on Plagiarism ( http://www.acm.org/publications/policies/plagiarism_policy) Submissions that violate these policies will be desk-rejected. Submission Site: Submissions will be accepted at https://sle21.hotcrp.com/ --------------------------- Reviewing Process --------------------------- All submitted papers will be reviewed by at least three members of the program committee. Research papers and tool papers will be evaluated concerning novelty, correctness, significance, readability, and alignment with the conference call. New ideas / vision papers will be evaluated primarily concerning novelty, significance, readability, and alignment with the conference call. For fairness reasons, all submitted papers must conform to the above instructions. Submissions that violate these instructions may be rejected without review, at the discretion of the PC chairs. --------------------------- Awards --------------------------- * Distinguished paper: Award for most notable paper, as determined by the PC chairs based on the recommendations of the programme committee. * Distinguished reviewer: Award for distinguished reviewer, as determined by the PC chairs. * Distinguished artifact: Award for the artifact most significantly exceeding expectations, as determined by the AEC chairs based on the recommendations of the artifact evaluation committee. --------------------------- Publication --------------------------- All accepted papers will be published in the ACM Digital Library. AUTHORS TAKE NOTE: The official publication date is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. --------------------------- Organisation --------------------------- Chairs: * General chair: Eelco Visser, Delft University of Technology, Netherlands * Program co-chair: Dimitris Kolovos, University of York, United Kingdom * Program co-chair: Emma Söderberg, Lund University, Sweden * Artefact Evaluation co-chair: Elias Castegren, KTH, Sweden * Artefact Evaluation co-chair: Andreas Wortmann, RWTH Aachen University, Germany Program Committee: Vincent Aranega, University of Lille, France Mikhail Barash, University of Bergen, Norway Melanie Bats, Obeo, France David Broman, KTH, Sweden Shigeru Chiba, University of Tokyo, Japan Alfonso de la Vega, University of York, United Kingdom Juan De Lara, Universidad Autónoma de Madrid, Spain Davide Di Ruscio, University of L'Aquila, Italy Marcos Didonet del Fabro, Universidade Federal do Paraná, Brazil Juergen Dingel, Queen's University, Canada Michalis Famelis, University of Montreal, Canada Bernd Fischer, Stellenbosch University, South Africa Niklas Fors, Lund University, Sweden Antonio Garcia Dominguez, Aston University, United Kingdom Esther Guerra, Universidad Autónoma de Madrid, Spain Görel Hedin, Lund University, Sweden Stuart Hutchesson, Independent, United Kingdom Adrian Johnstone, Royal Holloway, United Kingdom Paddy Krishnan, Oracle Labs, Australia James Noble, Victoria University of Wellington, New Zealand Carlos Olarte, ECT UFRN, Brazil João Saraiva, HASLab / INESC TEC and Universidade do Minho, Portugal Anthony Sloane, Macquarie University, Australia Daniel Strüber, Radboud University , Netherlands Ulyana Tikhonova, CWI, Netherlands Mark van der Brand, TU Eindhoven, Netherlands Juan Manuel Vara, Universidad Rey Juan Carlos, Spain Ran Wei, Dalian University of Technology, China Bahman Zamani, University of Isfahan, Iran --------------------------- Contact --------------------------- For additional information, clarification, or answers to questions, please contact the Program Chairs (Emma Söderberg and Dimitris Kolovos).

1 0

georgjz/functional-geometry-gambit-scheme: A simple implementation based in Peter Henderson's paper "Functional Geometry"
by Bradley Lucier 09 May '21

09 May '21

https://github.com/georgjz/functional-geometry-gambit-scheme This appeared on Scheme Reddit, but I thought it may be of interest to some people on this list. Brad

2 1

Growing Open Source Projects with a Stable Foundation - growing-open-source-projects.pdf
by Lucier, Bradley J 06 May '21

06 May '21

This is a perspective on how to keep an open-source project running. I haven’t read it completely, but it may be of interest to the Gambit project. Brad https://www.cyrius.com/foss-foundations/growing-open-source-projects.pdf

2 1

Q: wrt. process devices - separating stdout/stderr
by Jörg F. Wittenberger 06 May '21

06 May '21

The gambit manual section 17.7.2 explains how to redirect stdout/stderr of child processes opened via `open-process` and siblings to the newly created port. That's the closest I could find to what I want to do: Run the child process and process return process the output when the child exits normally and raise an exception (containing what the child wrote to stderr) otherwise. I don't mind a few tricks. The fewer the better. But I need this on Linux and Windows, at least that it. But I don't see how to do that with Gambit. Thanks for any hint. /Jörg

1 0