Gambit-list Juillet 2017

gambit-list@iro.umontreal.ca

12 participants
16 discussions

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

07 Avr '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

Re --enable-auto-forcing: Scope, how/where implemented, how build (with) it properly?
by Adam 18 Sep '17

18 Sep '17

Hi Marc! Three questions regarding promise auto-forcing: 1) Scope If build correctly (e.g. per the instructions below), every single Scheme-world evaluation in the whole GVM will be included in the auto forcing scheme, right? E.g. (begin (declare (not safe)) (print (##string-append (delay "Hello world")) "\n")) and any other quirky Scheme code cases are also included. Do any declares affect auto-forcing behavior? 2) How/where is it implemented? I'm trying to follow the code path of the "--enable-auto-forcing" ./configure argument, but I cannot figure out how it is propagated as to affect anything in include/ , gsc/ , lib/ , anywhere. Also I can't find any logics in gsc/ , lib/ or include/ (that's where they should be I supposed) that pertain to automatic forcing of promises. Possibly the "macro-force-vars", which is used all over the runtime and compiler, would have something to do with this, but I don't find its definition anywhere. What am I missing, would you like to take a minute to describe where and how the auto-forcing logics are implemented? 3) How build Gambit with it enabled properly? Also, enabling auto-force requires a full recompile of Gambit's own sources (for *all* C files involved to be recompiled, including the runtime, e.g. including the repl, will auto-force, and not just user code and hence just a tiny part of the logics, which would lead to a totally uneven application of auto-forcing), right, so the following is how to properly switch it on right?: git clone https://github.com/gambit/gambit.git cd gambit ./configure --enable-auto-force make -j4 mv gsc/gsc gsc-boot make bootclean make -j4 sudo make install Or do you suggest any other sequence or way? Should I use "from-scratch" instead of "make bootclean" + "make"? Thanks!

3 15

Making UTF-8 the default for Gambit
by Faré 15 Aoû '17

15 Aoû '17

Is it possible to build Gambit such that UTF-8 is the default for I/O? Or should it heed the LC_CTYPE or LC_ALL variable? I had a bug while compiling gerbil code that vyzo traced to disagreement between I/O options used by gambit and gerbil. The workaround was to export GAMBOPT=t8,f8,-8 rather than fight to propagate the proper options to gsc. I would like to build gambit with these options as the default, so I can distribute a version that works out of the box. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org He wa'n't no common dog, he wa'n't no mongrel; he was a composite. A composite dog is a dog that is made up of all the valuable qualities that's in the dog breed — kind of a syndicate; and a mongrel is made up of all riffraff that's left over. — Mark Twain

4 5

Asynchronous Interrupts
by Faré 30 Jul '17

30 Jul '17

Dear Marc & Gambiteers, I was hoping to write a short email about a simple way to support asynchronously aborting threads, as per https://github.com/gambit/gambit/issues/275 Then I realized that the problem was (Faré's PhD thesis)-complete, and what I ended up writing was a statement of intent for the non-trivial hacking of Gambit that I need to achieve to complete my thesis at https://j.mp/FarePhD It's all connected, but I'll include copious background, so if you have time not to skip this message, go grab yourself some tea/coffee/etc. I'm enjoying actor programming on Gambit Scheme (actually using Gerbil Scheme as a layer on top of it). But, especially so after I noticed an actor going crazy and busy looping with 100% of CPU, I realized that I *really* wanted to be able to develop robust actor systems in the style of Erlang — except on top of Gambit. Erlang allows programmers to build extremely robust systems by being based on the principle that errors, failures and mistakes WILL happen, and that the system should as mattter of course easily recover from them — by killing and restarting the failed subsystems. To elucidate the paradigm shift in this approach to software, see notably the great 2017 paper by Tomas Petricek "Miscomputation in software Learning to live with errors" http://tomasp.net/academic/papers/failures/ or his much shorter 2015 blog post: http://tomasp.net/blog/2015/failures/ One key mechanism to achieving this very robust style of developing distributed systems based on actors (that Erlang calls "processes") is Erlang's ability to safely kill a process at any point in time. There are many reasons why a process may fail: its execution may hit a software bug; it may hit a hardware bug; it may be hit by cosmic rays or outer forces; it may fall victim to some "wrench" thrown by software like Chaos Monkey https://blog.codinghorror.com/working-with-the-chaos-monkey/ that deliberately introduces random failures into the system to ensure that robustness issues are found and addressed earlier rather than later; it may be targetted by some denial-of-service attack; it may exceed some resource threshhold; it may otherwise enter a state where it fails to correct respond to queries, especially so to semi-random semi-periodic probing queries by its supervisor. Whatever the reason, inasmuch as the supervisor can detect failure, it can safely kill the failing process, and restart a new one to replace it. The process will be unregistered from whatever service broker it was subscribed to, and the incoming request traffic will be picked up by its healthy registered peers until the replacement is fully operational. Because interesting services are made of many actors (or "processes" in Erlang parlance) that act in concert and have mutually-dependent state, when a process dies (whether of natural or super-natural causes), all the processes linked to it (parents and children) are in turn sent a signal to shutdown graciously. They can explicitly catch and handle this signal if they really care to survive or to cleanup something before they die; but by default, the linked process just dies immediately, freeing all its resources; when it dies, so will a graceful shutdown signal be sent to its own linked processes, recursively, in a tree of related processes. In Erlang, this ability to safely kill entire process trees is essential to build an extremely robust architecture where large services made of many coordinated actors automatically restart in a coherent way when errors (or regular system upgrades) happen. I have long dreamed to have this Erlang-style robustness in a Lisp — rather than building a Lisp on top of Erlang, like LFE, that while robust would miss a lot of the system programming tradition of Lisp and its performant compilers. And Gambit is oh so close to it, yet I realize still so far. Importantly, in Erlang, the actor shutdown signal works asynchronously, at least by default, for regular actors that don't explicitly catch and handle these signals. This means that a regular process may die in the middle of whatever the hell it is doing. This works well in Erlang, because of its programming model where processes are made of pure functions and communicate exclusively via message passing. The model ensures by construction that there is precious little shared state that may be left in an invalid state when an asynchronous signal happens, only the message mailbox and a shared buffer extension sometimes used for performance reasons. And the system implementation ensures that accesses to this shared state are atomic with respect to asynchronous signal delivery, so the rest of the process is all private state and can be released without any resource leak. Now, in Scheme (and most other languages, except maybe Haskell), there can be a LOT more shared state that may be left in disarray if a thread is interrupted in the middle of random operations. Stateful data structures are a common thing to use; if anything, making system calls or using libraries often involves a lot of state; the language implementation's runtime environment itself has plenty of shared state, and was never designed to play well with asynchronous interrupts. Which means that, if an asynchronous interrupt happens (a signal in Unix parlance), it must be expected that some this shared data will be in some intermediate state, and that killing the current thread would leave the program unstable and unable to operate correctly: a lock may be held that will never be released; the state protected by that lock may violate necessary invariants to its operation; some resource borrowed from another thread such as a handler granted by a server may never be released or otherwise complete its usage cycle the program may be experience a deadlocked or livelock; some distributed protocol that was previously initiated (e.g. voting, partaking in some transaction, etc.) may never complete; another thread waiting on a spinlock may spin the CPU forever in a tight loop; if a low-level invariant is broken, the program may crash in ugly low-level ways, or worst of all, it may return wrong answers and do the wrong thing to your system — which can conceivably cause death and/or loss of millions of dollars. On the other hand, if you fail to interrupt the thread when it is failing, then it might keep running in a zombie state that eats all your CPU or holds onto critical resources (shared data structures, sheer amount of memory, file handles, etc.) that blocks the other computations from successfully making progress. Or its known failing state may lead to corruption of critical data. In this case too, costly or deadly failure may happen. Therefore, in Scheme, as in most languages, at least at present, the limited solutions to providing an ersatz of Erlang-style robustness are as follow: 1- Do NOT allow for asynchronous killing at all at the Scheme level. Have only synchronous killing at the Scheme level. 2- Socially enforce a convention that all actors should regularly go back to the message loop, and that there should never be a deadlock, live lock, non-terminating computation or runaway code execution between two consecutive calls home to the message handling loop. 3- If some algorithm require indefinitely long computations, their implementation must maintain a discipline of "cooperative multitasking", like in the bad old days of the 1980s, whereby these long-lived computations will be specially modified to periodically "yield" execution and give the message loop process the opportunity to process any synchronous shutdown message while the program is in a stable state. 4- Consider Scheme as a replacement not for Erlang, but for the lower-level language in which the Erlang VM is implemented (i.e. C), that has to deal with all the ugly synchronization details, without being able to fully abstract over them. 5- Build further abstractions over this lower-level language, and stick to them by social convention. A regular Scheme cannot enforce these social conventions and prevent users from breaking the abstractions and reaching into the implementation details; however, Gerbil allows you to build and enforce a full abstraction for module, thanks to its Racket-like #lang feature, that impose global (rather than merely local) restrictions on what a module can express. 6- If you really want a group of actors that live and die together, put them in a same Operating System level process (and either use OS process groups to implement trees of related processes, or implement yourself that notion using some kind of supervisor process). Then you can kill and restart the entire process (or set of processes). Unlike Erlang processes or Gambit threads, It's heavy weight; but it works, and sometimes that's what's exactly needed. 7- In general, as much as possible, use pure functional style and/or restrict side-effects to local state that is private (not shared), thus reducing issues related to shared state for processes that use this style. However, because the Scheme implementation's runtime and the available libraries were never designed for asynchronous interrupts, their own use of shared resources can still cause catastrophic failures in case of asynchronous aborts. This strategy of course works, but leads to code that is awkward, inefficient, not modular, tiresome and error-prone to write, impractical except at a small scale, and still fragile. It is not satisfactory to only provide fragile constructs that will explode if users fail to respect non-trivial coding conventions and maintain them as the software evolves. This issue really calls for some robust abstraction mechanism that will automatically enforce any invariant though coherent automated code generation rather than manual discipline. Well, at least, Scheme is not worst than any other random language. The only languages that stand out for their robustness are those based on the Erlang VM, BEAM, i.e. Erlang itself, Elixier, LFE, Efene, Joxa, and whatever Erlang flavor of the day. Now, what I would really like is to enhance Gambit Scheme with basic mechanisms to really allow safe asynchronous killing of threads. I told vyzo and he opened issue https://github.com/gambit/gambit/issues/275 on asynchronous aborts. My first reflex was to think that if you somehow have a notion of pseudo-atomic code blocks and you can ensure that asynchronous signals are deferred until the end of current code block, then everything will be fine. Cleanup forms in "finally" clauses or dynamic-wind forms may have to be considered atomic, or at least start with interrupts disabled. But otherwise, it should be pretty much a straightforward extension of what the GVM already supports for the sake of e.g. garbage collection, right? Nope. It actually takes a whole lot to make proper asynchronous interrupts work in presence of shared state. After thinking about the issue a bit more, I realized that it's actually the very same problem that plagued me for years, and that I have solved in theory my (incomplete) PhD thesis, but that still requires a practical implementation. And I also realized that my thesis has a solid argument why there is no shortcut to the complete solution proposed in my thesis, of a general protocol for declaring "observability" of computations. Indeed, for each level of abstraction that you (or your users) care about, there will be high-level invariants on the shared state that, if broken, leave the entire program unable to make progress at that level of abstraction, even though the state may be perfectly fine at lower-levels of abstractions. Solving the problem at a low-level of abstraction can never be enough to solve the issue at higher levels of abstraction, that the lower-levels are only a means to support. Thus, you can never safely kill any thread in any existing language, with the exception of Erlang. Yet, Erlang does it for all programs. And if you look carefully, you'll see that each and every programming language with preemptive user-level threads or a garbage collector supports pseudo-atomic blocks and properly deferred asynchronous signal delivery to suitable "safe points", so the invariants of its own virtual machine are enforced before a context switch may proceed without the asynchronous signal handler interfering with low-level implementation details of the language's virtual machine. In the case of Gambit, quite remarkably, asynchronous signal handling by the system is compatible since 2015 with migrating processes from one GVM to another, e.g. C to JS to PHP — by making sure the signal to migrate is only processed at safe points relative to the GVM. To find a general solution to the issue, you must first step back and look at the bigger picture: software can be seen as a "semantic tower", where each layer is the implementation of some more abstract computation A using some more concrete computation C. For instance, your program implements a user abstraction U on top of your programming language abstraction P; the compiler you use implement this abstraction P in terms of a lower-level virtual machine V. Then a lower layer expresses V in terms of a low-level view O of the system as provided by the operating system. The operating system itself implements O in terms of the documented CPU and chipset semantics C. C may include microcode that realize the CPU abstraction in terms of a digital circuit D. D is implemented as transistors in terms of analog electrical circuits E. E is implemented in terms of quantum mechanics Q. Q is implemented by God in terms of his own digital physics computer a la Ed Fredkin. Many more abstraction levels may exist above, below, or in the middle, that were omitted in this list, yet may be added when observing the semantic tower from a wider point of view or with a finer resolution of details. >From this point of view, the issue of asynchronous signal handling is then that at each layer of implementation, a low-level asynchronous interrupt signals may be received at a safe point for the lower level of abstraction, but that the implementation may want to deliver a higher-level asynchronous signal, to be handled at a safe point for the higher level of abstraction. Each level of abstraction thus has its own notion of safe point, with its own restrictive invariants, that its implementation must express in terms of the lower abstraction's level of safe-point, using the language in which it is written, that is expressed in terms of that lower abstraction's state and its laxer invariants. The general architecture of this semantic tower must therefore support "lifting" the notion of safe point, so that a higher-level safe point may be recovered from a lower-level safe point. In my thesis I call the corresponding property of implementations that can lift this notion of safe-point "observability". The developer in charge of providing an abstraction level must make sure it can never be caught "with its pants down" (to reuse the metaphor by ITS hackers, as narrated by Alan Bawden in his great article on PCLSRing, an early documented instance of the notion of observability, in an 1960s operating system). And he must for that use on the lower-level system provided by the programming language he uses, that he may hopefully rely on itself never being caught with their pants down, but only observed in stable states. Therefore, when an asynchronous signal is received for which a handler is registered at a given level of abstraction A, the system must somehow synchronize to a safe point for A before to run the handler, and in general this level may be higher than that of Gambit's virtual machine. Furthermore, in the case of aborting a thread, this level of abstraction is the highest at which this thread matters to anyone (user, or supervisor program that knows how to rebuild higher abstractions). In simple cases, recovering a safe point for a level of abstraction A is simply a case of letting the code run, and checking at each safe point reached whether an interrupt was received that requires processing at that level of abstraction (or one below). But for many reasons may require to support less simple cases: there may be ongoing transactions that need to be rolled back (aborted) or rolled forward (eagerly completed, or maybe partially completed but with some clean stable state register that will cause a follow up transaction); the abstract state may be a composite of the states of several concurrent systems, that may each have to be stopped and synchronized to an observable state; performance may require shortcuts to be taken in the regular case that have to be compensated for when an interrupt is caught. In the most general case, whichever programmer is specifying the abstraction level A is himself using a programming language providing a more concrete level of abstraction C. When specifying a handler of asynchronous signals to recover a stable state at level A, the programmer necessarily needs to express it the language he is using, in terms of the state at level C. Therefore, for that handler to run and synchronize to a safe point for A, the platform should first be able not just to synchronize to a safe point for C, but also to let the handler observe (recover, extract, reconstruct, inspect) the state at level C. Now, since there may be an even higher abstraction level H on top of A, it is not enough to synchronize to a safe point for A, the platform must also support observing (recoving, extracting, reconstructing, inspecting) the state at the level A so the handler of the implementation of H with A can itself specify how to synchronize to a safe point for H and let yet higher levels of abstractions observe the state at level H. Now, a naive understanding of "recovering the state at level A" can be expensive: you don't want to serialize the entire state of the virtual machine (potentially gigabytes of memory or more) every time you process an asynchronous interrupt handler. You want this recovery to be lazy, so only the bits of state actually required by the handler need to be partially reified at the required level of abstraction. A naive implementation of safe points would create a closure to express this recovery, at every safe point. A slightly less naive implementation would only create that closure *if* an interrupt was caught at that safe point. Therefore, the general protocol for a safe point is therefore to have some kind of special form (safe-point level state), where level is some kind of object identifying the level of abstraction of the safe point (if possible known at compile-time, usually implicit when discussing safe points of a well-identified layer of the semantic tower), and state is a form only evaluated when an interrupt is caught at said level, that permits recovery of the state at specified abstraction level, if possible lazily. The compiler hopefully knows how to merge safe-points between levels of abstractions, so that tests for asynchronous interrupts at higher level safe-point and creation of corresponding higher-level state objects only happen if an asynchronous interrupt was already caught at the corresponding lower-level safe-point, yet wasn't handled already by a lower-level handler. An even better compiler would eliminate redundant consecutive safe point checking, so e.g. check points are only checked at the beginning of functions or loops (just like the implementation already does for its own lower-level checkpoints). Now, it is not enough to have compiler support. The runtime library must also be written in a way that supports asynchronous interrupts, and the programming language must provide suitable abstractions. Notably, when allocating *any* kind of resource that an asynchronous interrupt may necessitate to release, the atomic operation with respect to interrupts should be not merely allocating the resource, but allocating it AND atomically binding some variable to it; only then may a "finally" clause properly release the resource without a leak should an asynchronous abort be received. (The "finally" clause will also handle synchronous exceptions or regular exit). Potentially long-running library functions, and especially higher-order functions, may also have their own issues with respect to declaring safe-points for higher levels of abstraction within the dynamic extent of their function call. When an abstraction level reexports such functionality from lower levels, it may have to subtly wrap this functionality in variants that suitably handle safe-points. And the compiler may have to be able to suitably optimize away most wrappers. There is also the case when a thread receives a further asynchronous abort in the middle of processing an existing one; or when it gets stuck while executing cleanup forms in general. My understanding is that asynchronous aborts are specified with a target level of abstraction. By default, an abort signal (as a Unix kill -TERM) works at the highest level of abstraction that the programmer cares about, and should run all the cleanup forms. If the operator gets impatient, he may send signals with lower levels of target abstraction (down to a Unix kill -KILL), at which point levels of abstractions higher than the target level are invalidated, their cleanup forms are eschewed, and all linked processes at this level of abstraction are killed (and hopefully restarted by their supervisor). It is therefore possible to "lose" a layer of abstraction -- if there was a bug in the implementation of this layer of abstraction, at which point, well, that is exactly what "having a bug" means. All in all, it's a lot of non-trivial work, especially since I need to modify the Gambit compiler to itself follow the protocol for the layers between Scheme and the GVM (it already follows it for the layers below the GVM, yay Marc!). But the result might be worth it, because, as I argue in my thesis (incomplete, but you can already read 141 pages worth of it), successfully enforcing this protocol unlocks an entire world of further cool features. I solved it all in theory. But since this is computing, not mathematics, theory is not enough and now I need to work on the implementation. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Happiness is a journey, not a destination; happiness is to be found along the way not at the end of the road, for then the journey is over and it's too late. The time for happiness is today not tomorrow. — Paul H. Dunn

3 5

Longer term suggestions: Implement userland ports, and then move SSL logics out of Gambit (made github issues of these)
by Adam 25 Jul '17

25 Jul '17

Created GitHub issues for these: https://github.com/gambit/gambit/issues/284 , "Implement userland ports." https://github.com/gambit/gambit/issues/285 , "Move the SSL logic out of Gambit, as to keep Gambit lean and secure. (Prerequisite: Userland ports)" Obviously these are my suggestions and not set in stone or anything. Any yay/nay-ing appreciated.

1 1

Gambit debugging compile modes, hopefully final thread :))
by Adam 25 Jul '17

25 Jul '17

Hi Marc! The following topic has been important since a long time. I think there are like 10 bumps in the mailing list on this one for many years. Maybe it was bumped so many times on the ML that if you answered at some point I might even have missed that response. Now to get to the bottom with this: Your complete response on this one would be very valuable. Gambit debugging can regard both interpreted and compiled modes. There's intra-Gambit debugging (singlestepping, ,bt , pp etc.), and there's extra-Gambit debugging (GDB bt , core files, etc.). Let's categorize the more subtle debugging options such as the "console" file output and any debug output in the memory subsystem etc. as extra-Gambit here too. Gambit's intra-Gambit debugging of interpreted code is always enabled in the default distro. The remainder of debugging functionality is off by default, and enabled by the --enable-debug option to ./configure . --enable-debug unfortunately is a double edged sword, it will give you some nice debugging stuff - and it will crash your whole operating system given the "right" parameters, which are very easy to run into without in any way having aimed at them intentionally. The things I am aware that --enable-debug does are: 1. It enables C-level debugging symbols, i.e. adds "-g" or the like to gcc/the C compiler. 2. It enables debugging information for compiled code, within the Gambit environment, so that |pp|, |bt| etc. will show code instead of nothing/just #<procedure 123>. 3. It enables debugging information for compiled code, on the level of the C code, so that GDB/the C-level debugger, will show Scheme code too (right?) 4. It enables the production of the 5. Some more stuff maybe? The disaster happens in 4. : your "console" file will fill the disk which causes system havoc, and "rm console" will not fix the problem as the OS will unlink the file at first when you close Gambit, duh! However, to the best of my awareness, there is no way to enable/disable the debugging options with any granularity at all. The only convenient option below the disastrous "--enable-debug", is "CC_FLAGS="-g" ./configure", which enables too few options and hence is unsatisfactory. This overall gives me the impression that the debugging options have not been tailored to match the needs for users (i.e. for helping users debug their code) but for Gambit development (for helping resolve internal Gambit bugs and aid Gambit system development). What I would like here is simply to be able to enable/disable these five individually. In normal cases, I want 1-3 to be enabled, and all else disabled. I consider 4-5 to be for debugging of the Gambit system itself, only. Probably normally, I'd actually make 1 going via CC_FLAGS as I want to choose the C compiler's -O option myself, and then use the specific ./configure arguments for enabling 2 and 3 only - and hence implicitly keep the feared 4 (and any 5 that I wouldn't want anyhow), disabled. Would you be able to implement this this year? Any comments from other users would also be much appreciated. Thanks!

1 1

-cfg option
by Marc Feeley 19 Jul '17

19 Jul '17

I’ve just added the -cfg option to gsc to generate a visual representation of the control flow graph. This is useful for debugging the compiler, but it may also help understand the code generated by the compiler for specific (small) programs. This option generates a .cfg file that can be processed by the “dot” program. For example, the attached PDF file “fib.cfg.pdf” was generated using the commands: % gsc -c -cfg fib.scm % dot -O -Tpdf fib.cfg from the file: (declare (standard-bindings) (block) (not safe) (fixnum) (not inline) (not interrupts-enabled) ) (define (fib n) (if (< n 2) n (+ (fib (- n 1)) (fib (- n 2))))) Have fun! Marc

1 0

Call for Participation: ICFP 2017
by Lindsey Kuper 18 Jul '17

18 Jul '17

[ Early registration ends 4 August. ] ===================================================================== Call for Participation ICFP 2017 22nd ACM SIGPLAN International Conference on Functional Programming and affiliated events September 3 - September 9, 2017 Oxford, UK http://icfp17.sigplan.org/ ===================================================================== ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. A full week dedicated to functional programming: ICFP, 2 co-hosted conferences, 1 co-hosted symposium, workshops, tutorials, programming contest results, student research competition, and mentoring workshop * Overview and affiliated events: http://icfp17.sigplan.org/home * Program: http://icfp17.sigplan.org/program/program-icfp-2017 * Accepted papers: http://icfp17.sigplan.org/track/icfp-2017-papers * Registration is available via: https://regmaster4.com/2017conf/ICFP17/register.php Early registration is due 4 August, 2016. * Programming contest, 4-7 August, 2016: http://2017.icfpcontest.org * Student Research Competition: http://icfp17.sigplan.org/track/icfp-2017-Student-Research-Competition * Follow @icfp_conference on twitter for the latest news: http://twitter.com/icfp_conference There are several events affiliated with ICFP: Sunday, September 3 Workshop on Higher-order Programming with Effects Workshop on Type-Driven Development Scheme and Functional Programming Workshop Programming Languages Mentoring Workshop ICFP Tutorials Monday, September 4 – Wednesday, September 6 ICFP FSCD - Days 1-3 Thursday, September 7 Haskell Symposium – Day 1 ML Family Workshop Workshop on Functional High-Performance Computing Commercial Users of Functional Programming – Day 1 FSCD - Day 4 Friday, September 8 Haskell Symposium – Day 2 OCaml Workshop Erlang Workshop Commercial Users of Functional Programming – Day 2 Saturday, September 9 Commercial Users of Functional Programming – Day 3 Haskell Implementors Workshop Functional Art, Music, Modeling and Design Conference Organizers: General Chair: Jeremy Gibbons (University of Oxford, UK) Program Chair: Mark Jones (Portland State University, USA) Artifact Evaluation Co-Chair: Matthew Flatt (University of Utah, USA) Artifact Evaluation Co-Chair: Ryan R. Newton (Indiana University, USA) Industrial Relations Chair: Ryan Trinkle (Obsidian Systems LLC, USA) PLMW Co-Chair: Neelakantan R. Krishnawami (University of Cambridge, UK) PLMW Co-Chair: Dan Licata (Wesleyan University, USA) PLMW Co-Chair: Brigitte Pientka (McGill University, Canada) Programming Contest Organiser: Sam Lindley (University of Edinburgh, UK) Publicity and Web Chair: Lindsey Kuper (Intel Labs, USA) Student Research Competition Chair: Ilya Sergey (University College London, UK) Student Volunteer Co-Captain: Yosuke Fukuda (Kyoto University, Japan) Student Volunteer Co-Captain: Yuki Nishida (Kyoto University, Japan) Student Volunteer Co-Captain: Jakub Zalewski (University of Edinburgh, UK) Video Chair: Jose Calderon (Galois, Inc., USA) Workshops Co-Chair: Andres Löh (Well-Typed LLP, UK) Workshops Co-Chair: David Christiansen (Indiana University, USA) Sponsors and industrial partners: Platinum partners Ahrefs Jane Street Capital Gold partners Bloomberg X Silver partners Galois Oracle Bronze partners Obsidian Systems Portland State University Well-Typed

1 0

reading shared structure conforming to SRFI-38
by Sven Hartrumpf 15 Jul '17

15 Jul '17

Hi all. The following code cannot read some larger structures conforming to SRFI-38 (gambit 4.8.8). Is there a size limit or similar to be configured? > (define p (open-input-file "mm")) > (define rt (input-port-readtable p)) > (readtable-sharing-allowed?-set rt #t) > (define x (read p)) *** ERROR IN "mm"@78.25 -- Incomplete form Note that the file mm can be read by 'read' or 'read-with-shared-structure' of other Scheme implementations. If needed, I can send the file mm in a direct mail. Greetings Sven

2 2

Re: [gambit-list] [Chicken-users] reachable top-level functions and variables
by Sven Hartrumpf 14 Jul '17

14 Jul '17

Hi Marc. SH wrote, 2017-07-12: >> I am looking for a compiler option that will produce output >> that could give me a start for determining a list of reachable >> top-level functions/variables. I have tried other compilers but they >> tend to deliver too many false positives for complex programs. MF wrote, 2017-07-13 04:20: > Have you tried the declaration (optimize-dead-definitions) in Gambit? > There’s also the -report compiler option. Thanks for the suggestions. I could not use Gambit for my sources because they need cond-expand AND syntax-rules AND Gambit keywords. The interesting Gambit feature made me write a little preprocessor that expands (top-level) cond-expand's and define-syntax (via alexpander) so that I might be able to port my sources to Gambit again :-) BTW (documentation of -report): gambit.pdf (Sec. 3.3) says: "defined, referenced, mutated and called" while the compiler uses: D A R C Should this be matched in reading order? Ciao Sven

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Gambit-list Juillet 2017