So recently I saw a couple of posts that mention APL approaches to problems. The cool thing is that I saw those in a Perl related forum and a Ruby one.
- https://www.youtube.com/watch?v=UBl6t7zNfwE
- https://zverok.github.io/blog/2020-05-16-ruby-as-apl.html
Mostrando entradas con la etiqueta ruby. Mostrar todas las entradas
Mostrando entradas con la etiqueta ruby. Mostrar todas las entradas
martes, 26 de mayo de 2020
lunes, 11 de noviembre de 2019
Some Forth Implementations
To finish up one of the geekiest weekends in the last months, I just wanted to point to a few Forth implementations, from where I learned some nice tricks (from both forth and the implementation languages)
- Bashforth/Perlforth
- Rubyforth
- Miniforth
- ItsyForth
I spent a lot of time grasping Bashforth, with its usage of some smart tricks that you don't usually see in bash scripts. Also, the fact that array indices are used as a sort of pointers makes total sense, but it wasn't obvious to me at first (I had to research a bit about "delcare"). Perlforth is done by the same guy, so it uses a similar approach.
Miniforth is Lua, and uses a different kind of implementation, and gets to bootstrap something forthish in 40 lines of lua. Not bad :)
Rubyforth is the one I touched less, but looks like a variation of miniforth with more Forth compliance.
Now a quick bash quiz: What does it echo? AnswerHere
Well, there are two more canonical forth implementations that is worth mentioning them here, because if you're gonna just look at one implementation, you should take these ones as more "de facto" implementations.
- pforth
- jonesforth
- Bashforth/Perlforth
- Rubyforth
- Miniforth
- ItsyForth
I spent a lot of time grasping Bashforth, with its usage of some smart tricks that you don't usually see in bash scripts. Also, the fact that array indices are used as a sort of pointers makes total sense, but it wasn't obvious to me at first (I had to research a bit about "delcare"). Perlforth is done by the same guy, so it uses a similar approach.
Miniforth is Lua, and uses a different kind of implementation, and gets to bootstrap something forthish in 40 lines of lua. Not bad :)
Rubyforth is the one I touched less, but looks like a variation of miniforth with more Forth compliance.
Now a quick bash quiz: What does it echo? AnswerHere
#!/bin/bash
fun() {
local var="local value of var"
echo "$ref";
}
var="global var"
declare -n ref=var
fun
Well, there are two more canonical forth implementations that is worth mentioning them here, because if you're gonna just look at one implementation, you should take these ones as more "de facto" implementations.
- pforth
- jonesforth
viernes, 15 de enero de 2016
MemoYzing: memoize using Y Combinator
Lately I've had to speed up an openresty-lua application. As most of the code is just applications of transformations to data, and it's mainly functional, I thought that memoizing would be the easiest way to go.
After generating a flamegraph for the code, I spotted a couple of functions that could be memoized. Problem solved.
While looking for a nice way to write the memoize function, I remembered the shortest memoizing code ever in lua. Also I googled a bit and found kikito's memoize library. So far so good. But they both share a problem. What about recursive functions? They will get catched only on the top level, because the self referencing calls , after memoizing are not self referencing anymore, and they point to the old function.
Perl memoize module overwrites the symbol table to alias the functions. In ruby 2.0 you can memoize a recursive function using Module#prepend. With the Y combinator
Here's this article from Matt Might about how YCombinator makes it possible to turn a recursive function into a memoized recursive function caching the intermediate results, using the indirect self-reference that it provides.
EDIT: I just published the button and then thought "what if I wanna convert a doubly recursive function (fib) into a iterative one (tail call) by using accumulators? I can obviously memoize according to the two args, but it gets pretty useless, as the results can be hardly reused. I found this series of articles "from recursion to iteration" that provide some tricks. Haven't fully understood it, but I'm on it.
After generating a flamegraph for the code, I spotted a couple of functions that could be memoized. Problem solved.
While looking for a nice way to write the memoize function, I remembered the shortest memoizing code ever in lua. Also I googled a bit and found kikito's memoize library. So far so good. But they both share a problem. What about recursive functions? They will get catched only on the top level, because the self referencing calls , after memoizing are not self referencing anymore, and they point to the old function.
Perl memoize module overwrites the symbol table to alias the functions. In ruby 2.0 you can memoize a recursive function using Module#prepend. With the Y combinator
Here's this article from Matt Might about how YCombinator makes it possible to turn a recursive function into a memoized recursive function caching the intermediate results, using the indirect self-reference that it provides.
EDIT: I just published the button and then thought "what if I wanna convert a doubly recursive function (fib) into a iterative one (tail call) by using accumulators? I can obviously memoize according to the two args, but it gets pretty useless, as the results can be hardly reused. I found this series of articles "from recursion to iteration" that provide some tricks. Haven't fully understood it, but I'm on it.
domingo, 3 de enero de 2016
Continuations as accumulators
Some months ago I read The Little Schemer, an amazing book that guides through many functional programming concepts in a very different way to other books.
To me, by far the most challenging part of the book whas that exercise in page 137 which uses a continuation as an accumulator. I remember being hours staring at it thinking "WTF?". In fact I also remembered that in SICP there was a code example (in the compiler chapter IIRC) that used this style of programming, and also got me puzzled, and I ended up letting it go, and continuing reading (after some time staring at it also).
Months after TLS and years after SICP, I'm reading Concepts, Techniques, and Models of Computer Programming (CTM), and at some point it talks about recursion, and accumulators. At the point it starts explaining multiple accumulators, I had an 'aha' moment, closing the multirember&co problem. In fact CTM doesn't talk about CPS (at least in that part). But somehow intuitively they're talking about the same concept.
I decided to reimplement a variant of it in ruby. Now that I look at it, it's super simple... I guess some things just need time to settle.
Here are some related links, talking about the technique or explanations of the original problem.
To me, by far the most challenging part of the book whas that exercise in page 137 which uses a continuation as an accumulator. I remember being hours staring at it thinking "WTF?". In fact I also remembered that in SICP there was a code example (in the compiler chapter IIRC) that used this style of programming, and also got me puzzled, and I ended up letting it go, and continuing reading (after some time staring at it also).
Months after TLS and years after SICP, I'm reading Concepts, Techniques, and Models of Computer Programming (CTM), and at some point it talks about recursion, and accumulators. At the point it starts explaining multiple accumulators, I had an 'aha' moment, closing the multirember&co problem. In fact CTM doesn't talk about CPS (at least in that part). But somehow intuitively they're talking about the same concept.
def odd_even_part(l, &block) if l.empty? yield([], []) elsif l[0].even? odd_even_part(l[1..-1]) do |odds, evens| yield(odds, evens + [l[0]]) end else odd_even_part(l[1..-1]) do |odds, evens| yield(odds + [l[0]], evens) end end end odd_even_part([1,2,3,4]) do |odds, evens| puts "odds => #{odds}" puts "evens => #{evens}" end
I decided to reimplement a variant of it in ruby. Now that I look at it, it's super simple... I guess some things just need time to settle.
Here are some related links, talking about the technique or explanations of the original problem.
martes, 14 de abril de 2015
Cache is the new GC
Now all rubyists are pros in all Garbage Collection techniques.
And we all have to know the difference between mark&sweep, reference counting, generational, and whatnot (I also see more references to this in the lua mail list lately).
And we're already optimizing for not creating so many objects. And we pray Rust and Nim for being so powerful and fast and allow us to manage memory manually. and we decide that checking for existence of an element in a short Array is probably faster than checking in a small Set. Even more if we know the distribution of the expected values.... Well... now, the next step is Cache.
Interesting points here http://dev.mensfeld.pl/2015/04/ruby-global-method-cache-invalidation-impact-on-a-single-and-multithreaded-applications/ .
And after that, Locality of variables, and compiler tricks to optimize code. Here's a nice StackOverflow thread.
Inside this thread the thing that brings you back to reality is that compilers are allowed to do pretty amazing things . Things that are so complex, that if you have to have that in mind... well.... good luck. I guess for real time systems it makes sense, or very low level programming, but there are really complex techniques which seem really hard to anticipate .
What's the point of all that? No idea. it's just funny that sometimes we try to push low level languages to higher levels, and then, we program ruby as if we were forging asm. Funny :) . In the end, all benchmarks are made to lie in one or other regard, so I guess the most important thing, is having Amdahl's law in mind (or an adaptation of it): All the optimizations you'll do, will apply only to the percentage of code where the optimization is feasible. The original speaks about intrinsically serial code that cannot be parallelized. My idea is that optimizing for cache hits in ruby when you have a webapp which does http calls here and there to external systems is not really the way.
And we all have to know the difference between mark&sweep, reference counting, generational, and whatnot (I also see more references to this in the lua mail list lately).
And we're already optimizing for not creating so many objects. And we pray Rust and Nim for being so powerful and fast and allow us to manage memory manually. and we decide that checking for existence of an element in a short Array is probably faster than checking in a small Set. Even more if we know the distribution of the expected values.... Well... now, the next step is Cache.
Interesting points here http://dev.mensfeld.pl/2015/04/ruby-global-method-cache-invalidation-impact-on-a-single-and-multithreaded-applications/ .
And after that, Locality of variables, and compiler tricks to optimize code. Here's a nice StackOverflow thread.
Inside this thread the thing that brings you back to reality is that compilers are allowed to do pretty amazing things . Things that are so complex, that if you have to have that in mind... well.... good luck. I guess for real time systems it makes sense, or very low level programming, but there are really complex techniques which seem really hard to anticipate .
What's the point of all that? No idea. it's just funny that sometimes we try to push low level languages to higher levels, and then, we program ruby as if we were forging asm. Funny :) . In the end, all benchmarks are made to lie in one or other regard, so I guess the most important thing, is having Amdahl's law in mind (or an adaptation of it): All the optimizations you'll do, will apply only to the percentage of code where the optimization is feasible. The original speaks about intrinsically serial code that cannot be parallelized. My idea is that optimizing for cache hits in ruby when you have a webapp which does http calls here and there to external systems is not really the way.
domingo, 10 de noviembre de 2013
Jekyll with basic auth in heroku
Dabbling with different systems to write a static site, I was wondering if there would be a way to build a jekyll like site with access control (basic auth is fine) at zero cost.
rack-jekyll is needed to turn jekyll to a rack-like app. Once we're in rack universe, we can easily add basic auth to it.
Unfortunately, I can't show the repo itself (remember, I needed auth....), but most interesting stuff is just in the following links. The job left to be done is the glue-ing part.
But If I could do it myself, it can't be any hard.
But If I could do it myself, it can't be any hard.
miércoles, 20 de marzo de 2013
occur: Poor man's taglist
From time to time I see some vim screencast and think: "oh, taglist, that was nice...", and yeah, in emacsland we have lots of alternatives, like full blown ecb, or imenu, or idomenu, I guess there might even exist something with speedbar...
But none of them really cuts it for me, I'd need the ecb one without all other ecb features. Or something like that
So here's the plain dead simple elisp I'm using lately. Just occur-mode and a keybinding to update the search. For ruby, it can't find all the dinamic shit in there, but you get a nice overview of what's in your file, and if it's properly indented (which should be) you also get the notion of what's public, private, etc...
Surprisingly, I'm using it more and more, and I can have different regexes for different filetypes. (even tune it to look for 'get\\|post' if I'm editing sinatra things.)
Dead simple, but it kind of works.
But none of them really cuts it for me, I'd need the ecb one without all other ecb features. Or something like that
So here's the plain dead simple elisp I'm using lately. Just occur-mode and a keybinding to update the search. For ruby, it can't find all the dinamic shit in there, but you get a nice overview of what's in your file, and if it's properly indented (which should be) you also get the notion of what's public, private, etc...
Surprisingly, I'm using it more and more, and I can have different regexes for different filetypes. (even tune it to look for 'get\\|post' if I'm editing sinatra things.)
Dead simple, but it kind of works.
(defun rgc-show-ruby-tags () (interactive) (occur "^\\s-*\\\(class \\\|module \\\|def \\\|[^:]include \\\|private\\b\\\|protected\\b\\\)")) (define-key ruby-mode-map (kbd "C-c t") 'rgc-show-ruby-tags)
jueves, 29 de noviembre de 2012
a neat ruby idiom
[rgrau] guys, I just learned a new idiom [rgrau] (@foo ||= []) << bar [michal] :) [rgrau] It's not crystal clear, but I like it [rgrau] my perl background damaged my brain beyond repair [jakub] rgrau: idiom or idiot? [rgrau] you pick [jakub] ok, done [rgrau] I know which one you picked [jakub] u r smart [rgrau] u idiom [rgrau] that log goes to my blog inside ruby section
jueves, 9 de febrero de 2012
Kiss the cuke
miércoles, 25 de enero de 2012
stylish ruby
Here you have a couple of style guides related to ruby, rails, and some tips on functional programming and a few not-so-trivial techniques like currying, TCO, or just using immutable structures.
Apparently, all things explained in all those guides are obvious, or just a matter of taste, but you better read those guides a few times each to make those rules stick in your head, just to be sure :)
First, a guide from bbastov (of emacs prelude fame), that's already in github and forked more than a hundred times, so we could say it's a community ruby style guide.
Second, another bbastov's guide, this time on Rails 3.
And last but not least, slides of a friend of a friend's workshop on Functional Ruby. Really nice, and full of nice tricks that deserve to be read and understood.
That's all for now. Back to hacking
Apparently, all things explained in all those guides are obvious, or just a matter of taste, but you better read those guides a few times each to make those rules stick in your head, just to be sure :)
First, a guide from bbastov (of emacs prelude fame), that's already in github and forked more than a hundred times, so we could say it's a community ruby style guide.
Second, another bbastov's guide, this time on Rails 3.
And last but not least, slides of a friend of a friend's workshop on Functional Ruby. Really nice, and full of nice tricks that deserve to be read and understood.
That's all for now. Back to hacking
martes, 4 de enero de 2011
If you want a thing done well ....
...and continuously, and consistent way, let the computer do it for you.
gem install ZenTest
gem install autotest-rails
gem install redgreen
If you're on MAC:
gem install autotest-fsevent
echo "require 'autotest/fsevent'\nrequire 'redgreen'" >> ~/.autotest
If you're on GNU/Linux
gem install autotest-inotify
echo "require 'autotest/inotiny'\nrequire 'redgreen'" >> ~/.autotest
just run 'autotest' from your project root directory, and it will run the relevant tests on your modified files.
gem install ZenTest
gem install autotest-rails
gem install redgreen
If you're on MAC:
gem install autotest-fsevent
echo "require 'autotest/fsevent'\nrequire 'redgreen'" >> ~/.autotest
If you're on GNU/Linux
gem install autotest-inotify
echo "require 'autotest/inotiny'\nrequire 'redgreen'" >> ~/.autotest
just run 'autotest' from your project root directory, and it will run the relevant tests on your modified files.
jueves, 2 de diciembre de 2010
HAHA! You're not regular anymore!1

Via HN I saw praprog released another magazine, this one fully dedicated to ruby (What a coincidence! :) )
I skimmmed all the articles but paying more attention to a couple of them:
One of them talk about new features of Ruby 1.9.2. It seems ruby is getting faster and faster on every release (a good thing since speed is one of the major 'problems' I had read about ruby).
Another place where it has improved is on the regex side. Now ruby regexes allow named captures (feature added to perl in 5.10 IIRC), and recursive regexes (The not-so-regular regexes are here) there are some flags like /x /g and /k, that let you reference captures more easily than plain old \1, \2 ...
All in all, quite cool stuff that makes me feel a bit more at (perl) home.
Unfortunately, I couldn't practice with rails yet. I did some progress on ruby koans though. A busy week in Tenerife.
sábado, 20 de noviembre de 2010
I'm a LOL programmer (wannabie)

In my new job, it seems I'll be writing ruby (on rails).
I've been trying the language in my spare time, and it seems a fairly good compromise between Perl and Smalltalk.
Except a couple of features or idioms I saw, everything else was quite intuitive or easy to understand (at least coming from Perl/Smalltalk).
+ Sigils do exist, but denote scope oposed to type.
+ __DATA__
+ '=' can be part of a method name. And there's some magic involved there. def method=(attr) can be used as an assignment (sintactically) as parens are optional.
+ Integer class can be expanded or subclassed.
Here are the codes I wrote to grasp the language. These are the usual examples I write in every language I try to learn:
- a program to center paragraphs.
- guessing number
- Network with hosts that pass messages one to the other.
Here is a link that I found useful about ruby patterns and idioms.
http://scriptlandia.blogspot.com/2009/02/design-patterns-in-ruby.html
Suscribirse a:
Entradas (Atom)