I would like to create a command line application that generates jpg images using Quil. I plan to write a couple of generic image processing functions to mix and match (some fn drawing shapes and some manipulating the pixel array).
A simple example of what I would like to do is create one function that draws a circle then a second function that applies a dither algorithm to the pixel array.
(defn draw-circle [x y] ...) ;; e.g. internally uses Quil draw functions.
(defn apply-dither [pixels] ...) ;; e.g. internally uses Quil color functions on the pixels array.
(defn draw []
(draw-circle 100 100)
(apply-dither (pixels))
...)
(defsketch sketch
:draw draw)
What is causing me a bit of grief is all Quil functions seems to only run within a sketch macro. This means that my own functions using the Quil functions internally in turn cannot be directly called (must be called from a draw function triggered by a sketch macro), making debugging and running them individually from the repl harder/impossible.
How do I go about creating and debugging such generic functions? Am I stuck having sketch call functions on my behalf or is there another way?
There is also the possibility that Quil isn't the right tool for my project. I'm considering directly using java / processing classes.
My development environment is Emacs + Cider.
Thanks
I've created a series of quil sketches that run from the command line at https://github.com/rogerallen/qeom
I developed & iterated within emacs+cider and just recompiled the draw function to see the results update live in the sketch window.
I used an atom (defonce dump-image-count (atom 1)) to control when the draw function would save an image:
(defn draw []
...
(when (> #dump-image-count 0)
(save-frame "q007-dump-####.png")
(swap! dump-image-count dec)))
Hope this helps.
Related
(define (segments->painter segment-list)
(lambda (frame)
(for-each
(lambda (segment)
(draw-line
((frame-coord-map frame)
(start-segment segment))
((frame-coord-map frame)
(end-segment segment))))
segment-list)))
Some of you have already seen this sicp example before but for the first timers a brief explanation: segments->painter procedure takes arguments from segment list which has values are segments made up from vectors. for-each procedure acts like map but instead returns a list of value, it does operations like printing or in this code it draws lines. frame-coord-map scales frames according to unit square frame. What I don't understand in this code is where does first lambda function takes its argument (frame) from.
Here is a case of currying.
In your code
(define (segments->painter segment-list)
(lambda (frame)
...))
when you call segments->painter, scheme will return an object of some type, let us call figure. When you apply a graphical frame on this object, scheme will be able to draw your object.
(define obj1 (segments->painter seg1))
obj1 is an object of type figure and this object is able to receive frames. It is able to do only one action when it receives a frame, namely to get drawn in that frame: (obj1 frame1), (obj1 frame2), etc are actions you can do on that object.
Before to apply the graphical data on some object, it does make sense to talk about that object but it does not make sense to talk about a real representation of that object. In your case, the object can do one single action: to get drawn.
Between calling the contructor for the figure object and drawing the object you can do some (static) preprocessing, such that in the moment when you call the drawing method, you have already precomputed something.
This is how types are implemented in programming languages. This Peter Henderson's language is a first introduction to types and to combinators. This will be developped further in the 4th chapter, where the interpreter uses some precomputed data to execute (it converts the list input format to internal format).
Let's look at a simpler example:
(define (adder x)
(lambda (y)
(+ x y))
The analogous question would be, "Where does y come from, if you can call adder with only x?" As discussed in the comments, it comes from whoever calls the lambda that adder returns. You may write:
(define plus5 (adder 5))
(plus5 8) ; 13
(plus5 1) ; 6
At the point that you call adder, there is no y. In the next call, y is 8, and after that it is 1.
Likewise in your actual code, there is no frame until someone calls the returned lambda.
Apply is defined in 4.1.1 The Core of the Evaluator of SICP as:
(define (apply procedure arguments)
(cond ((primitive-procedure? procedure)
(apply-primitive-procedure ;
procedure
arguments));
((compound-procedure? procedure)
.....
(else
....)
I referenced the definition of apply-primitive-procedure in "4.1.4 Rnning the Evaluator as a Program" as:
(define (apply-primitive-procedure proc args)
(apply-in-underlying-scheme
(primitive-implementation proc) args))
So apply-primitive-procedure is implemented by apply-in-underlying-scheme
Nonetheless, refer to the footnotes:
Apply-in-underlying-scheme is the apply procedure we have used in earlier chapters. The metacircular evaluator's apply procedure
([[4.1.1]]) models the working of this primitive. Having two different
things called apply leads to a technical problem in running the
metacircular evaluator, because defining the metacircular evaluator's
apply will mask the definition of the primitive. One way around this is to rename the metacircular =apply= to avoid conflict with the name
of the primitive procedure. We have assumed instead that we have saved
a reference to the underlying =apply= by doing
(define apply-in-underlying-scheme apply)
before defining the metacircular apply. This allows us to access the original version of apply under a different name.
It states the apply-in-underlying-scheme is apply in 4.1.1.
In a summary:
,-> apply -> apply-primitive-procedure -> apply-in-underlying-scheme --.
'----------------------------------------------------------------------'
I guess it not a recursion.
What's wrong with my understanding?
Apply means function application for everything that is not a special form (the special forms are considered in eval). Apply is a recursive function that will ever finish.
Apply is subdivided in 2 cases of procedure application:
-- internal to the system that implements the language
This is the place where is made the transition between the target language and the language that is used to implement the target language (source language).
Here you need to evaluate each parameter (through eval) and convert the resulting object to a similar object in source language before to call the application function of the source language. For some parameters the recursion of eval->apply may happen.
-- a combination created in the target language by using the means of combination that the target language provides.
In this case also you need to recursively call eval for each parameter and use function application in the target language. In this case you do not need to convert the result of eval to an object in the source language.
So in case of combinations there is also recursion in apply, but it is a kind of recursion that will finish (function application function is a primitive-recursive function) because you evaluate a smaller piece each time (operator, operands vs the full initial expression).
I think that you did not notice that apply is a primitive-recursive operator and you were afraid it will not finish.
I would like to redefine a standard Racket function, namely display, within a lexical scope, as in this example:
(with-custom-display (display "hello"))
This should work even when the code within the scope of with-custom-display is from a different library or even racket/* packages.
Is this possible? If so, how to do it?
EDIT:
If not possible in general, at least for the case of display and other write functions... could I somehow transform every output by parameterizing on current-output-port then redirecting the transformed output to the original port?
While its not possible1 to globally replace arbitrary functions in Racket, you absolutely CAN change the standard out port that a Racket program uses (and by extension, functions like display). In fact, this is exactly what the readline collection in racket does, except for input ports rather than output ports.
Basically, all you need to do is parameterize current-output-port globally to be your special port. Since you want to ultimately write out to the original output port (but with colors), you can also grab the original output port before changing it to the new one. Your resulting code would look something like this:
#lang racket/base ;; init.rkt
(define orig-port (current-output-port))
(define new-output-port
.... uses orig-port ....)
(current-output-port new-ouput-port)
(replacing .... uses orig-port .... with the implementation of your new colored output port)
And now, any file that requires "init.rkt" will get color in its default output port.
(Note though that if you have multiple files that do this same sort of thing, you have to be careful to make sure that they don't happen in an unsafe order.)
You can also make your with-custom-display form as a simple language extension by doing:
#lang racket ;; custom-disp.rkt
(provide with-custom-display)
(require syntax/parse/define)
(define orig-port (current-output-port))
(define new-output-port
.... uses orig-port ....)
(define-simple-macro (with-custom-display body ...)
(parameterize ([current-output-port new-output-port])
body ...))
This is the general idea of how DrRacket is able to print output to a DrRacket specific repl, rather than your consoles stdout.
1Normally anyway, there are usually ways to break things if you really want to. But that's almost always a bad idea. ;)
Is there an emacs-lisp command which I could use to plot a collection of numbers with gnuplot, much like I can create simple line charts in Excel from an array of numbers?
For example, I would like to have a function called something like plot-with-gnuplot which I could call with something like:
(plot-with-gnuplot '((0 0.1) (0.1 1) (0.5 10)))
and have this produce a simple line plot going through those points.
Ultimately I will be using this to view mathematical functions that I am writing, it would be useful to be able to have a quick look at how my code is coming along by drawing a simple line plot of its values over a certain range.
It is not exactly what you want but you may find Org-babel-gnuplot from org-mode useful. I've made an example file, it should work if you have gnuplot.el and emacs24. Run the first code block (C-c C-c), and then run the third code block.
test.org:
#+BEGIN_SRC emacs-lisp :results silent
;; load gnuplot mode
(require 'gnuplot "~/Dropbox/emacs/gnuplot.el")
(require 'ob-gnuplot)
#+END_SRC
#+NAME: edata
#+BEGIN_SRC emacs-lisp
'((0 0.1) (0.1 1) (0.5 10)))
#+END_SRC
#+BEGIN_SRC gnuplot :file file.png :var data=edata
plot data w lp
#+END_SRC
I am new to VBA and I'm now working on a project where speed is absolutely everything. So as I'm writing the code, I noticed a lot of the cells in the sheet are named ranges and are referenced in the functions explicitly like this:
function a()
if range("x") > range("y") then
end if
... (just imagine a lot of named ranges)
end function
My question is, should i modify these functions so that the values in these named ranges are passed in as parameters like this:
'i can pass in the correct cells when i call the function
function a(x as int, y as int)
if x > y then
end if
...
end function
Will that speed things up a little bit? These functions are called almost constantly (except when the process is put to sleep on purpose) to communicate with a RTD server.
VBA is much slower at making "connections" to your worksheet than it is at dealing with its own variables. If your function refers to the same cell (or range) more than once then it would be advantageous to load those into memory before VBA interacts with them. For example if range("x")>range("y") is the only time in the function that either x or y are referred to then it won't matter. If you have if range("x")>range("a") and if range("x")>range("b") and so on then you'd be much better off starting your function with
varX=range("x")
varY=range("y")
and then working with the VBA variables.
It might seem that by parameterizing the function as your second example shows accomplishes my recommendation. This may or may not be the case because Excel might just treat those variables as references to the worksheet and not as values (I'm not sure). Just to be safe you should specifically define new variables at the beginning of your function and then only refer to those variables in the rest of your function.
To sum up the above wall of text, your goal should be to minimize the number of times VBA "connects" to the worksheet.