Re: [racket-users] Re: [racket] How to call a Julia function from DrRacket?
On 03/05/2015 00:00, Geoffrey Knauth wrote: On Friday, May 1, 2015 at 5:53:04 PM UTC-4, Greg Trzeciak wrote: It's an old thread but just in case someone is looking for the answer Julia has (now?) C API: http://julia.readthedocs.org/en/latest/manual/embedding/ I hesitate to mention connecting Racket to Fortran some day but I wonder if that's ever been done. Nine years ago when I worked on parallel programming enhancements to Octave, the free MATLAB-workalike written in C++, Octave leaned heavily on Fortran scientific libraries that had been highly optimized over decades. Julia is also speedy doing math. If it's old Fortran 77 code (BLAS, LAPACK, etc.), C interfacing techniques work quite well in practice. You have to know how the Fortran compiler's API maps to a C API, but there are only two or three conventions around, which differ in trivial things like underscores added to subroutine names. Fortran 95 and later are a different story. Konrad. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] racket on openwrt devices
On 2015-05-02 2:29 PM, Neil Van Dyke wrote: > What's the current viability of running Racket on a small OpenWRT > device? (Anything new, such as due to the recent modularization of the > core?) Nothing that I know of since 2011ish. The smaller core might make it a little easier to assemble a minimal set of collections. > For example of specs of a popular beefy retail home WiFi router that > runs OpenWRT well: > Processor: Atheros AR7161 rev 2 680MHz (MIPS arch) > RAM: 64MiB > Flash: 16MiB Nice. Hmm, that amount of nonvolatile storage will be a challenge. Racket will run in 64MB RAM on a machine of that class, though not well, if my intuitions from 2011 still hold. (Last time I ran Racket on OpenWRT, I was using a Netgear WNDR3700v2.) Tony -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] racket on openwrt devices
Tony Garnock-Jones wrote on 05/03/2015 12:55 PM: On 2015-05-02 2:29 PM, Neil Van Dyke wrote: What's the current viability of running Racket on a small OpenWRT device? (Anything new, such as due to the recent modularization of the core?) Nothing that I know of since 2011ish. The smaller core might make it a little easier to assemble a minimal set of collections. OK, thanks, Tony. I'll have to give this a try in a week or two. (Last time I ran Racket on OpenWRT, I was using a Netgear WNDR3700v2.) I have a collection of these and similar WNDRs (my home office network is run by two 3700v2 and a 3800, running OpenWRT). For Racket, I'll probably try a 3700v4 or 4300v1 first, since they're 128 RAM and 128 NAND flash, albeit with a different SoC with lower CPU clock rate. I don't want to rely on USB Storage for this project. (Aside: A challenge for an open source project that you want large numbers of people to be able to adopt grassroots-style is to find router model(s) with sufficient specs, and that run OpenWRT well, and yet are still easily available for purchase online and at big-box retailers. Additionally, vendors like Netgear and Linksys often replace the product guts of a model with very different hardware, without changing the model number; so, someone ordering a "WNDR3700" online could be getting any of 4+ different devices, with widely varying specs, and some of which don't run OpenWRT. Some open source projects can also work on Raspberry Pi devices, but sometimes you need the NICs/radios/switch hardware of a cheap router anyway, so you might as well do everything in one appliance box. A soho router is more polished and less expensive than a RasPi with a bunch of daughterboards and USB hubs and devices hanging off of it precariously.) Neil V. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] racket on openwrt devices
On 2015-05-03 2:50 PM, Neil Van Dyke wrote: > 128 RAM and 128 NAND flash, albeit with a different SoC with lower > CPU clock rate. I don't want to rely on USB Storage for this > project. I should mention also that I couldn't do anything useful with Racket 5.x (as it was at the time) on the WNDR3700v2 without using a swap file on a USB stick (!). Simply not enough RAM or storage for Racket. Tony -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] racket on openwrt devices
Tony Garnock-Jones wrote on 05/03/2015 03:10 PM: On 2015-05-03 2:50 PM, Neil Van Dyke wrote: 128 RAM and 128 NAND flash, albeit with a different SoC with lower CPU clock rate. I don't want to rely on USB Storage for this project. I should mention also that I couldn't do anything useful with Racket 5.x (as it was at the time) on the WNDR3700v2 without using a swap file on a USB stick (!). Simply not enough RAM or storage for Racket. Very good to know. Guess I'll just target the 128MB RAM devices, and not even bother with 64MB. This weekend I'm writing a (hopefully) very-small-footprint HTTP-serving module in pure Racket. Neil V. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] performance with freeze from 2htdp/image on very complex images
I’m trying to use 2htdp/image to generate images of fractals. But while generating the images is “relatively” quick, it is freezing the images that’s taking a long time. For the most complicated one, I started it running two nights ago, and the freeze operation on it still hasn’t finished. For the next worst one, it takes about 21 times longer to freeze it than it takes to generate it. Why is it taking so long to freeze these images, and is there anything I can do about it, like create the images in a certain way or give hints? The code that generates these fractals is here: https://github.com/AlexKnauth/koch-snowflake (and it is racket code, in case you’re wondering) For relatively small/simple fractals, freezing it takes anywhere from 1.5 to 3.9 times longer than creating it. For this one, freezing it takes a bit more than 3.5 times longer than creating it. time(img-expr): cpu time: 186 real time: 185 gc time: 26 time(freeze(img)) : cpu time: 668 real time: 667 gc time: 31 For this, about 3.9 times longer: time(img-expr): cpu time: 141 real time: 141 gc time: 22 time(freeze(img)) : cpu time: 549 real time: 549 gc time: 20 For a more complex fractal, about 21 times longer: time(img-expr): cpu time: 18722 real time: 18807 gc time: 4304 time(freeze(img)) : cpu time: 400357 real time: 405312 gc time: 214723 And for this, about 18 times longer: time(img-expr): cpu time: 8425 real time: 8547 gc time: 1203 time(freeze(img)) : cpu time: 152594 real time: 153001 gc time: 64968 And for this, about 17.8 times longer: time(img-expr): cpu time: 27232 real time: 27264 gc time: 4254 time(freeze(img)) : cpu time: 485319 real time: 504408 gc time: 210964 For the worst one: time(img-expr): cpu time: 2177463 real time: 2455108 gc time: 1189933 time(freeze(img)) : hasn’t finished yet For this one, I started it two nights ago, and it’s still running. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] Re: performance with freeze from 2htdp/image on very complex images
Those are beautiful. First, make sure in Choose Language / Show Details that it's set to "No debugging or profiling", and that "Preserve stacktrace" not set. The 2htdp/image library has immutable images, so the image you're creating contains all the line drawing "unexecuted" until you display or freeze it. There's a lot of symmetry, so rather than passing an image as a parameter can you express the algorithm as returning one of the component images at each level, then rotating and combining it with itself? As long as the result is symmetric that will create a rather narrow Direct Acyclic Graph of images. You can then also experiment with freezing some of those intermediate images, especially at the top levels where rotating a bitmap might be faster than executing the drawing actions in a rotated co-ordinate system. But that's speculation, not experience. Other than that, consider drawing directly into a mutable bitmap% from racket/draw, or explore images/flomap. Then there are the possibilities of Typed Racket optimizations, and profiling and the Optimization Coach in general. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
