June 2016 - Gambit-list - mailman.iro.umontreal.ca

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

07 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

Re: [gambit-list] JavaScript backend
by Marc Feeley 13 Feb '17

13 Feb '17

First of all, this change is for the universal backend. It is more of a temporary kludge to experiment with dynamically loading files generated by the universal backend. Here’s how it works… At the end of the link file, the Gambit linker generates a table of the Scheme modules required by the program. The table is passed as a parameter to the g_module_registry_init function of the Gambit runtime system. For example, the link command: gsc -link -l lib/_gambit.js a.js b.js will generate at the end of the link file “b_.js”: g_module_registry_init([new G_ModLinkInfo("_gambit",0), new G_ModLinkInfo("a",1), new G_ModLinkInfo("b",2)]); At then end of a file generated for the compilation of a module there is a call to a runtime system function that registers the module in the module registry. For example, when “a.scm” is compiled with the command “gsc -target js -c a.scm”, the file “a.js” generated ends with: g_module_register([g_make_interned_symbol("a"),g_bb1__20_a,1,null,false]); The parameter of g_module_register is a “module descriptor” giving information on the module: name, main function (g_bb1__20_a), preload flag (1), module meta information (null), and a dummy field (false) that is only interesting for the C backend. So when the files of generated code are loaded (incrementally) by the JS VM, g_module_register accumulates the modules in a table. When all the modules required by the program have beed loaded (in the example, _gambit, a and b) the function g_module_register will call the main function of the first module. This will run the Scheme code at the toplevel of the first module. The first module contains a loop, in Scheme, that iterates over the module registry and calls the main function of each of the remaining modules in the registry (this information is available in Scheme in the global variable ##program-descr). Specifically, the first module is the Gambit universal library (lib/_univlib.scm), which ends with a call to ##load-vm (a procedure defined in lib/_kernel.scm that runs each module other than the first). What my most recent change does is extend g_module_register so that any subsequent module that is loaded by the JS VM causes its immediate execution by calling the module's main function. In the C backend the mechanism is slightly different (and more flexible): the ##load-object-file procedure of the Gambit runtime library constructs a vector of module descriptors and this vector is passed to ##register-module-descrs-and-load! (defined in lib/_kernel.scm) which then runs the modules. It is more flexible because the loaded object file can contain more than one module, and also control goes through Scheme before the module is executed. Marc > On Jan 3, 2016, at 2:54 AM, Adam <adam.mlmb(a)gmail.com> wrote: > > Marc, > > Wait, what's the point? > > That is effectively C modules' default behavior isn't it? (even if it's the runtime or linker-generated code that actually does the actual run command.) > > So this way you create symmetrical behavior but the actual run command is in the module file itself rather than in runtime/linker - > > Is there any disadvantage.. could be, no, like, I need more modules loaded at the same time and with this model you introduced now, the global namespace in JS files is evaluated at load time so could cause a problem? > > > 2016-01-03 14:10 GMT+08:00 Marc Feeley <feeley(a)iro.umontreal.ca>: > I’ve just pushed a small change to the module registration method. Now, loading the generated .js file will run that file. > > Marc > > > On Jan 2, 2016, at 11:39 PM, Blake McBride <blake(a)mcbride.name> wrote: > > > > Yes, and I use jQuery get and html methods to load the html part. > > > > > > On Sat, Jan 2, 2016 at 8:43 PM, Marc Feeley <feeley(a)iro.umontreal.ca> wrote: > > That’s an interesting app! > > > > As I said, it shouldn’t be hard to do. In your app, how do you load new JS code? Are you using jQuery and the getScript method? > > > > Marc > > > > > On Jan 2, 2016, at 8:42 PM, Blake McBride <blake(a)mcbride.name> wrote: > > > > > > Hi Marc, > > > > > > Thanks for the reply. > > > > > > I started development of a Web based business application in 2006. The app is in production use. The front-end is about 450 screens written in Flash. The back-end is written in Java (over 9,000 classes) on top of an SQL database with 250 tables accessed through Hibernate. The front-end and back-end communicate through SOAP web services. > > > > > > Since Flash is now dead, I need to re-write at least parts of the front-end in JS to support tablets and phones at least. I have front-end JS code that communicates with the back-end SOAP Web services so I theoretically wouldn't need to touch the back-end. > > > > > > I have a preference to utilize scheme if I can, but the back-end is already written and works. It doesn't make sense to mess with it given the investment. > > > > > > The problems I had with Gambit (as well as many other systems) is as follows: > > > > > > Once a user logs in, my app has a consistent visual / UI framework. Beyond this framework, there are 450 different screens that appear within the framework (like in one of the div's). > > > > > > A. I cannot load all 450 screen at system startup. I must lazy load them as they are called up. > > > > > > B. The initial UI framework code should contain all of the Gambit machinery and libraries so that each of the 450 screens can be small, light-weight, compiled separately yet have full access to the entire Gambit facility. > > > > > > With respect, my investigation into Gambit as a possible solution in the past led me to the conclusions at that time it was not possible to produce separately compiled modules that leveraged off of a single main module for the Gambit machinery and libraries. > > > > > > I suppose some time has passed and I wanted to see if the situation has changed. I can only use Gambit if: > > > > > > 1. I can compile and load each screen separately > > > > > > 2. I only have to have one copy of the Gambit machinery and library so that the separate screens are small. > > > > > > Thank you. > > > > > > Blake > > > > > > > > > On Sat, Jan 2, 2016 at 7:06 PM, Marc Feeley <feeley(a)iro.umontreal.ca> wrote: > > > asmjs is cool and Gambit has already been compiled to it thanks to emscripten (see “Gambit in the browser”: http://feeley.github.io/gambit-in-the-browser/) The performance is not bad, perhaps 10x to 20x slower than when Gambit is compiled by gcc to native code. The main problem is the size of the JS that is generated when compiling Gambit-C with emscripten to JS. The gsi interpreter yields roughly 10 MB of asmjs code. > > > > > > As far as code size is concerned, a better solution is to use Gambit's JS backend with the Gambit library. The code generated is roughly half the size when minimized (and it could be even less if some thought went into how identifiers are encoded). > > > > > > Even more savings can be had by doing away with the default Gambit library and writing a custom library specialized for the application. Gambit’s library has lots of functionality that is not normally needed by typical applications. For example, the predefined map procedure can handle an arbitrary number of list parameters. If the application only uses the single list version, then this definition would be sufficient: > > > > > > (define (map f lst) > > > (if (pair? lst) > > > (cons (f (car lst)) (map f (cdr lst))) > > > ‘())) > > > > > > That 4 line version is 1/20th the size of the map defined in the Gambit library (which handles multiple lists, has type checking, precise error messages, same list length checking and is safe for multithreading). > > > > > > So perhaps what’s needed for Gambit to be more successful for web dev is the creation of such a “slim” library for Gambit to replace the default feature-full library. Gambit’s “tree shaker” would also help to eliminate the unused procedures of the slim library (unfortunately this only works for “whole program” compilation, so separate compilation would only be used for the development phase). > > > > > > Anyway, if this interests you please let me know. > > > > > > Marc > > > > > > > On Jan 1, 2016, at 11:44 AM, Blake McBride <blake(a)mcbride.name> wrote: > > > > > > > > Just some opinions. > > > > > > > > asmjs.org defines a portable subset that allows JS platforms to compile into very fast code. Targeting that subset, and within their spec, is probably a good idea. > > > > > > > > JS has, and is becoming increasingly, a very, very important platform. With ajax and rest services, code increasingly independent from the back-end is being developed. So, in a very important sense, JS has become its own platform, just like X86, and X86_64, along with Linux, Windows, Mac, etc. > > > > > > > > Many apps consist of two major parts: the back-end processing, and the front-end human interface. While one can write the back-end processing in any of dozens of languages targeting X86 or a VM, and the OS, there is really only one target for the other half - the human interface - and that is JS. > > > > > > > > While many languages are now targeting the JS platform (I am using the word "platform" to mean X86, X86_64, either, plus the OS) including, believe it or not, Smalltalk, there are few that can, IMO, be used in a real world application for several reasons. But, these issues will likely be resolved soon. > > > > > > > > With respect, Gambit, at least in the past, was in many ways another toy solution - one with a functioning "Hello world" application but missing important features that make it usable in a real-world situation. I would love to be a part of that solution, but alas, life doesn't offer me that level of freedom. I am only capable of using a system that is reportedly working, reporting bugs, making small adjustments, and providing feedback. Regardless of my attitude, preferences, and intentions, I cannot provide more. > > > > > > > > Look at node (JS for the back-end) and its vastly increasing popularity. Since developers are being forced to use JS on the front-end, it's bleeding over to the back-end. I think solutions that take JS seriously at this stage will prosper greatly. > > > > > > > > Now, having said all that, I would love to see Gambit target JS as a high-priority, first-class target. If that were the case, I would be happy to contribute what I stated above. > > > > > > > > Thanks! > > > > > > > > Blake McBride > > > > > > > > _______________________________________________ > > > > Gambit-list mailing list > > > > Gambit-list(a)iro.umontreal.ca > > > > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list > > > > > > > > > > > > _______________________________________________ > Gambit-list mailing list > Gambit-list(a)iro.umontreal.ca > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list >

2 1

Gambit version for medical apps?
by Gorges, Matthias 01 Aug '16

01 Aug '16

Greetings, I have a question for the community in general, and Marc in particular. As some of you may know the Pediatric Anesthesia Research team at UBC uses Gambit as part of their LambdaNative framework (http://www.lambdanative.org/) to develop medical software. Some of our applications are mission and safety critical as they control drug delivery to patients (doi: 10.1145/2635648.2635651), or provide decision support during triage of pregnant women by community health workers (doi: 10.1109/JBHI.2014.2301156). Hence, we are trying to identify which version of Gambit to use, with the main deciding factor being reliability and stability. While the main LambdaNative branch uses 4.7.9 - we are considering updating to 4.8.5 once we figure out how to integrated the revised tracing into our exception handler/logger, we use much older versions for our production-quality applications: Specifically, we use 4.7.2 for our mobile Android apps, as there were issues with both the ##thread-heartbeat! and other hard-to-reproduce crashes in very large Android apps with later Gambit versions. For our closed-loop system on Linux we reverted back even further at 4.7.0. Here, our attempt to update to 4.7.9 resulted in weeks of debugging after the application segfaulted during clinical pilot testing, having passed weeks of both manual and automated system tests in the lab. Unfortunately, we were never to identify the exact crash location, but all we could show was that the crash did not originate from our (user-level) code but the Gambit infrastructure code. I appreciate that the project's current goals are more along the line of making a more universal output language processor, which is a laudable endeavor e.g. for improved in-browser support. However, I would appreciate some guidance in helping us chose a "stable" version without potentially wasting man-months in testing (and failing) to identify such a version ourselves. Many Thanks, Matthias

6 25

Fwd: Printing unicode characters in Gambit
by Vijay Mathew 26 Jun '16

26 Jun '16

---------- Forwarded message ---------- From: Vijay Mathew <vijay.the.lisper(a)gmail.com> Date: Sun, Jun 26, 2016 at 10:51 AM Subject: Re: [gambit-list] Printing unicode characters in Gambit To: Adam <adam.mlmb(a)gmail.com> Thanks Adam, will try what you suggested. But I really don't understand why a special switch is required to properly print Unicode characters. Even if the user is unaware of this, 'print' going into a loop is bad behavior. --Vijay On Jun 26, 2016 8:26 AM, "Adam" <adam.mlmb(a)gmail.com> wrote: > You need to switch on unicode output for the output medium (gsc -t8) and > maybe also specify the maximum unicode character number that the writer > will accept to write. Please report back when you figured. > > 2016-06-26 10:34 GMT+08:00 Vijay Mathew <vijay.the.lisper(a)gmail.com>: > >> How can I make gambit to print a Unicode character's symbol (or glyph)? >> For example, I want to display the Unicode infinity symbol ∞ (#\u221E). >> Calling `(display #\u221E)` or `(print #\u221E)` throws the REPL into an >> infinite loop. >> (This happens for most Unicode literals I tried, not just the infinity >> symbol :-)) >> >> $ gsc >> Gambit v4.8.4 >> >> > (print #\u221E) >> *** ERROR IN ##wr-ch -- Can't convert to C char-string >> (write-char #\*** ERROR IN ##wr-ch -- Can't convert to C char-string >> (write-char #\*** ERROR IN ##wr-ch -- Can't convert to C char-string >> (write-char #\*** ERROR IN ##wr-ch -- Can't convert to C char-string >> (write-char #\*** ERROR IN ##wr-ch -- Can't convert to C char-string >> >> Thanks, >> >> --- Vijay >> >> >> _______________________________________________ >> Gambit-list mailing list >> Gambit-list(a)iro.umontreal.ca >> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list >> >> >

2 3

Re: [gambit-list] Printing unicode characters in Gambit
by Adam 26 Jun '16

26 Jun '16

Print going into a loop is not OK, I suppose Marc fixes that. Needing a switch for switching on Unicode is OK though. When that option is off, you could do your prints by serializing to UTF8 binary yourself and then writing it byte by byte to the console. 2016-06-26 13:21 GMT+08:00 Vijay Mathew <vijay.the.lisper(a)gmail.com>: > Thanks Adam, will try what you suggested. But I really don't understand > why a special switch is required to properly print Unicode characters. Even > if the user is unaware of this, 'print' going into a loop is bad behavior. > > --Vijay > > On Jun 26, 2016 8:26 AM, "Adam" <adam.mlmb(a)gmail.com> wrote: > >> You need to switch on unicode output for the output medium (gsc -t8) and >> maybe also specify the maximum unicode character number that the writer >> will accept to write. Please report back when you figured. >> >> 2016-06-26 10:34 GMT+08:00 Vijay Mathew <vijay.the.lisper(a)gmail.com>: >> >>> How can I make gambit to print a Unicode character's symbol (or glyph)? >>> For example, I want to display the Unicode infinity symbol ∞ (#\u221E). >>> Calling `(display #\u221E)` or `(print #\u221E)` throws the REPL into an >>> infinite loop. >>> (This happens for most Unicode literals I tried, not just the infinity >>> symbol :-)) >>> >>> $ gsc >>> Gambit v4.8.4 >>> >>> > (print #\u221E) >>> *** ERROR IN ##wr-ch -- Can't convert to C char-string >>> (write-char #\*** ERROR IN ##wr-ch -- Can't convert to C char-string >>> (write-char #\*** ERROR IN ##wr-ch -- Can't convert to C char-string >>> (write-char #\*** ERROR IN ##wr-ch -- Can't convert to C char-string >>> (write-char #\*** ERROR IN ##wr-ch -- Can't convert to C char-string >>> >>> Thanks, >>> >>> --- Vijay >>> >>> >>> _______________________________________________ >>> Gambit-list mailing list >>> Gambit-list(a)iro.umontreal.ca >>> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list >>> >>> >>

1 0

Printing unicode characters in Gambit
by Vijay Mathew 25 Jun '16

25 Jun '16

How can I make gambit to print a Unicode character's symbol (or glyph)? For example, I want to display the Unicode infinity symbol ∞ (#\u221E). Calling `(display #\u221E)` or `(print #\u221E)` throws the REPL into an infinite loop. (This happens for most Unicode literals I tried, not just the infinity symbol :-)) $ gsc Gambit v4.8.4 > (print #\u221E) *** ERROR IN ##wr-ch -- Can't convert to C char-string (write-char #\*** ERROR IN ##wr-ch -- Can't convert to C char-string (write-char #\*** ERROR IN ##wr-ch -- Can't convert to C char-string (write-char #\*** ERROR IN ##wr-ch -- Can't convert to C char-string (write-char #\*** ERROR IN ##wr-ch -- Can't convert to C char-string Thanks, --- Vijay

2 1

{Spam?} must have
by goetter＠mazama.net 24 Jun '16

24 Jun '16

Hey, I've seen some cool stuff on the web, this is definitely must have of the season! Look at it here <http://questushuzu.skinnydipcandles.com/aephhmep> Typos courtesy of my iPhone, goetter(a)mazama.net

1 0

Any way in the Scheme code to get filename, define name and line number at compile time for debug?
by Adam 24 Jun '16

24 Jun '16

Marc, is there any way I can get the sourcecode filename, name of global define, and line number, that a particular line was compiled at? E.g. (so here, ##file, ##in-define and ##line would be output by the macro so the compiler would actually compile those at line 3, 6 and 8.) (define-macro (loc) `(print "This was printed at " ##file " in define " ##in-define " line " ##line "\n")) (loc) (define (something) (loc)) (loc) ? Thanks.

2 1

Re: [gambit-list] Can I imply a FORCE all over? (**Prio Q for this weekend or so :D )
by Bradley Lucier 09 Jun '16

09 Jun '16

I'm taking the liberty of adding the Gambit mail list to the CC, since this may be of general interest. "make check" fails after configuring with ./configure 'CC=/usr/local/gcc-6.1.0/bin/gcc -march=native' '--enable-single-host' '--enable-multiple-versions' '--enable-shared' --enable-auto-forcing "make -i check" (to ignore errors and continue) gives ------------ TEST 1 (debugging support) LD_LIBRARY_PATH=../lib:../gsi:../gsc:/usr/local/Gambit/current/lib:/usr/local/netpbm10/lib:/usr/local/gcc-6.1.0/lib/: ../gsi/gsi -:~~bin=../bin,~~lib=../lib,~~include=../include -f debug.scm > test1.out diff test1.ok test1.out && rm -f test1.out 81a82 > #return(##cprc-if2 3) : ($code rte) 85a87 > #return(##cprc-if3 3) : ($code rte) 108a111 > #return(##cprc-cond-if 3) : ($code rte) 112a116 > #return(##cprc-cond-or 3) : ($code rte) 117,120c121,126 < #return(##cprc-cond-send-red 3) : ($code rte pred) < #procedure(##cprc-cond-send-red 4) < #return(##cprc-cond-send-red 5) : ($code rte oper) < #return(##cprc-cond-send-red 6) : ($code rte) --- > #return(##cprc-cond-send-red 3) : ($code rte) > #return(##cprc-cond-send-red 4) : ($code rte pred) > #return(##cprc-cond-send-red 5) : ($code rte pred) > #procedure(##cprc-cond-send-red 6) > #return(##cprc-cond-send-red 7) : ($code rte oper) > #return(##cprc-cond-send-red 8) : ($code rte) 125,127c131,135 < #return(##cprc-cond-send-sub 3) : ($code rte pred) < #return(##cprc-cond-send-sub 4) : ($code rte oper) < #return(##cprc-cond-send-sub 5) : ($code rte) --- > #return(##cprc-cond-send-sub 3) : ($code rte) > #return(##cprc-cond-send-sub 4) : ($code rte pred) > #return(##cprc-cond-send-sub 5) : ($code rte pred) > #return(##cprc-cond-send-sub 6) : ($code rte oper) > #return(##cprc-cond-send-sub 7) : ($code rte) 131a140 > #return(##cprc-or 3) : ($code rte) 135a145 > #return(##cprc-and 3) : ($code rte) 140c150,151 < #return(##cprc-case 3) : (rte $code) --- > #return(##cprc-case 3) : ($code rte) > #return(##cprc-case 4) : (rte $code) 250,251c261,263 < #procedure(##cprc-app0-red 3) < #return(##cprc-app0-red 4) : ($code rte) --- > #return(##cprc-app0-red 3) : ($code rte) > #procedure(##cprc-app0-red 4) > #return(##cprc-app0-red 5) : ($code rte) 257,259c269,272 < #procedure(##cprc-app1-red 4) < #return(##cprc-app1-red 5) : ($code rte oper) < #return(##cprc-app1-red 6) : ($code rte) --- > #return(##cprc-app1-red 4) : ($code rte oper) > #procedure(##cprc-app1-red 5) > #return(##cprc-app1-red 6) : ($code rte oper) > #return(##cprc-app1-red 7) : ($code rte) 266,268c279,282 < #procedure(##cprc-app2-red 5) < #return(##cprc-app2-red 6) : ($code rte oper) < #return(##cprc-app2-red 7) : ($code rte) --- > #return(##cprc-app2-red 5) : ($code rte oper arg1) > #procedure(##cprc-app2-red 6) > #return(##cprc-app2-red 7) : ($code rte oper) > #return(##cprc-app2-red 8) : ($code rte) 276,278c290,293 < #procedure(##cprc-app3-red 6) < #return(##cprc-app3-red 7) : ($code rte oper) < #return(##cprc-app3-red 8) : ($code rte) --- > #return(##cprc-app3-red 6) : ($code rte oper arg1 arg2) > #procedure(##cprc-app3-red 7) > #return(##cprc-app3-red 8) : ($code rte oper) > #return(##cprc-app3-red 9) : ($code rte) 287,289c302,305 < #procedure(##cprc-app4-red 7) < #return(##cprc-app4-red 8) : ($code rte oper) < #return(##cprc-app4-red 9) : ($code rte) --- > #return(##cprc-app4-red 7) : ($code rte oper arg1 arg2 arg3) > #procedure(##cprc-app4-red 8) > #return(##cprc-app4-red 9) : ($code rte oper) > #return(##cprc-app4-red 10) : ($code rte) 297,298c313,315 < #procedure(##cprc-app-red 6) < #return(##cprc-app-red 7) : ($code rte) --- > #return(##cprc-app-red 6) : ($code rte oper) > #procedure(##cprc-app-red 7) > #return(##cprc-app-red 8) : ($code rte) 303a321 > #return(##cprc-app0-sub 4) : ($code rte) 310c328,329 < #return(##cprc-app1-sub 5) : ($code rte) --- > #return(##cprc-app1-sub 5) : ($code rte oper) > #return(##cprc-app1-sub 6) : ($code rte) 317,318c336,338 < #return(##cprc-app2-sub 5) : ($code rte oper) < #return(##cprc-app2-sub 6) : ($code rte) --- > #return(##cprc-app2-sub 5) : ($code rte oper arg1) > #return(##cprc-app2-sub 6) : ($code rte oper) > #return(##cprc-app2-sub 7) : ($code rte) 326,327c346,348 < #return(##cprc-app3-sub 6) : ($code rte oper) < #return(##cprc-app3-sub 7) : ($code rte) --- > #return(##cprc-app3-sub 6) : ($code rte oper arg1 arg2) > #return(##cprc-app3-sub 7) : ($code rte oper) > #return(##cprc-app3-sub 8) : ($code rte) 336,337c357,359 < #return(##cprc-app4-sub 7) : ($code rte oper) < #return(##cprc-app4-sub 8) : ($code rte) --- > #return(##cprc-app4-sub 7) : ($code rte oper arg1 arg2 arg3) > #return(##cprc-app4-sub 8) : ($code rte oper) > #return(##cprc-app4-sub 9) : ($code rte) 345,346c367,369 < #procedure(##cprc-app-sub 6) < #return(##cprc-app-sub 7) : ($code rte) --- > #return(##cprc-app-sub 6) : ($code rte oper) > #procedure(##cprc-app-sub 7) > #return(##cprc-app-sub 8) : ($code rte) makefile:113: recipe for target 'test1' failed make[1]: [test1] Error 1 (ignored) I don't know whether this is important. Brad On 06/09/2016 02:11 PM, Mikael More wrote: > Awesomeness, thanks!!!!! > > Fantastic, this means tight integration with a functional object > database is possible. > > I guess the expression code is running under the scheduler too, opening > for storage of the database on non-low-latency facilities too, great! > > > > 2016-06-10 1:30 GMT+08:00 Bradley Lucier <lucier(a)math.purdue.edu > <mailto:lucier@math.purdue.edu>>: > > Try adding --enable-auto-forcing to your configure of Gambit. > > > On 06/09/2016 01:20 PM, Adam wrote: > > Hi Marc! > > I have a practical question: > > I am thinking about the possibility of realizing a TIGHTLY > integrated > persistent object store ("object database"). > > (Tightly integrated, that is, with the Scheme heap.) > > The object store would be functional, so the host system can cache > object references as much as it wants. > > > My question is: > > The best thing would be to > > 1) Have lazy loading of objects into the Scheme heap from the > database > (because the stored structures may have wather depth and shape > meaning > that precaching algorithms never would have an idea about what > really > needs to be loaded, so better let the code show that simply > through what > slots etc. it accesses), *AND* to at the same time > > 2) *NOT* need to customize the Scheme code for the lazy loading, > i.e., > have implicit |force| all over the code? > > > A final wish here would be > > 3) The option that the |force| would be run as a procedure > within the > green threading system, so that other green threads would continue > executing while the lazy value is being loaded. Not sure about > this one > though - maybe for code-performance reasons it would be better > to have > it block. > > > Even runtime procedures would need to do the implicit |force|. > So the > values that not are loaded right now, would be represented by a > loading > closure, and the result of closure invocation would be the value > that > should take the place of the respective accessed slot. > > > Can this be done in Gambit, in its current form or with some > very slight > modification? > > Thanks! > > >

3 5

SIGPLAN Programming Languages Mentoring Workshop @ ICFP
by Lindsey Kuper 01 Jun '16

01 Jun '16

SIGPLAN Programming Languages Mentoring Workshop @ ICFP Nara, Japan (co-located with ICFP 2016) Sunday, September 18th, 2016 http://conf.researchr.org/track/icfp-2016/PLMW-ICFP-2016/ We are pleased to invite students interested in functional programming research to the programming languages mentoring workshop at ICFP. The goal of this workshop is to introduce senior undergraduate and early graduate students to research topics in functional programming as well as provide career mentoring advice. We have recruited leaders from the functional programming community to provide overviews of current research topics and give students valuable advice about how to thrive in graduate school, search for a job, and cultivate habits and skills that will help them in research careers. This workshop is part of the activities surrounding ICFP, the International Conference on Functional Programming, and takes place the day before the main conference. One goal of the workshop is to make the ICFP conference more accessible to newcomers and we hope participants will stay through the entire conference. Through the generous donation of our sponsors, we are able to provide travel scholarships to fund student participation. These travel scholarships will cover reasonable travel expenses (airfare and hotel) for attendance at both the workshop and the main three days of the ICFP conference. The workshop is open to all. Students with alternative sources of funding for their travel and registration fees are welcome. In particular, many student attendance programs provide full or partial travel funding for students to attend ICFP 2016, including the ACM Student Research Competition. More information about student attendance programs at ICFP is available: http://conf.researchr.org/home/icfp-2016 Application for Travel Support: The travel funding application is available from the PLMW webpage. The deadline for full consideration of funding is July 1st, 2016. Selected participants will be notified by July 15th. Organizers: Amal Ahmed, Northeastern University Robby Findler, Northwestern University Atsushi Igarashi, Kyoto University

1 0