similar to: [PATCH] generator: small optimization of pod2text cache memoization

- refactor memoization code - pass pod as stdin rather than files Pino Toscano (3): generator: isolate memoized cache in own module generator: adjust variable names generator: improve pod2text invocation generator/Makefile.am | 3 ++ generator/memoized_cache.ml | 62 +++++++++++++++++++++ generator/memoized_cache.mli | 29 ++++++++++ generator/utils.ml | 101

These safe wrappers around Pervasives.open_in and Pervasives.open_out ensure that exceptions escaping cannot leave unclosed files. --- common/mlstdutils/std_utils.ml | 39 ++++++++++++++++++++-------------- common/mlstdutils/std_utils.mli | 12 +++++++++++ common/mltools/tools_utils.ml | 39 +++++++++++++++++----------------- dib/dib.ml | 9 ++++----

- feed the content directly to stdin, avoid the need of read (and write) a temporary file - read all the output at once, without a tail-recurive function - apply trimming and first line discarding after closing the process --- generator/utils.ml | 35 ++++++++++++++++------------------- 1 file changed, 16 insertions(+), 19 deletions(-) diff --git a/generator/utils.ml b/generator/utils.ml index

I was wondering what was the reasoning behind freezing the Memoizable return values? Thanks -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to

Maybe this is because I''m missing something but it seems to me that asking users of a memoized method to know when the method needs to be reloaded is a bit backwards. To me it seems like whoever is messing with something that affects the results of the memoized function should be the one that after doing its work should call something like memoized_method(:reset). Thoughts? -- You

Hi, That''s a bit off topic but since I use Spork + Rspec... Well, my classes are reloaded between each test wave so Rails'' "memoize" method raises an error (which is expected, see code: http://rubydoc.info/docs/rails/3.0.0/ActiveSupport/Memoizable:memoize) Anyone resolved this issue with an elegant solution?

This patch fixes an issue with protected methods becoming public if they are memoized. Looking for +1''s and/or a commit by core... https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/5695 Thanks. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to

qemu feature detection takes about 95ms on my laptop. The overhead is almost all due to the time taken by the glibc link loader opening the 170+ libraries that qemu is linked to (×2 because we need to run qemu twice). Fixing that is seriously hard work. Therefore memoize the results of guestfs_int_test_qemu. This is keyed on the size and mtime of the qemu binary, so if the user changes the

My goal is simple: calcuate GC content of each sequence in a list of nucleotide sequences. I have figured out how to vectorize, but all my attempts at memoization failed. Can you show me how to properly memoize my function? There is a StackOverflow post on the subject of memoization, but it does not help me: http://stackoverflow.com/questions/7262485/options-for-caching-memoization-hashing-in-r

v1 -> v2: - Rebase on top of Pino's version work. Two patches went upstream, these are the two remaining patches. Note the generation number is still inside the qemu.stat file. We could put it in the filename, I have no particular preference. Rich.

--- generator/utils.ml | 8 +++++++- generator/utils.mli | 3 +++ 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/generator/utils.ml b/generator/utils.ml index b24ba8c..3a62084 100644 --- a/generator/utils.ml +++ b/generator/utils.ml @@ -360,4 +360,10 @@ let args_of_optargs optargs = | OInt64 n -> Int64 n | OString n -> String n | OStringList n ->

Doing qemu feature detection in the direct backend takes ~100ms because we need to run `qemu -help' and `qemu -devices ?', and each of those interacts with glibc's very slow link loader. Fixing the link loader is really hard. Instead memoize the output of those two commands. This patch series first separates all the code dealing with qemu into a separate module (src/qemu.c) and

Mostly like StringList (so it can used in current StringList parameters), but checking client- and daemon-side that the elements are relative paths. --- generator/bindtests.ml | 3 ++- generator/c.ml | 29 ++++++++++++++++++++++++----- generator/csharp.ml | 4 ++-- generator/daemon.ml | 20 ++++++++++++++++++-- generator/erlang.ml | 2 +- generator/fish.ml |

Mostly like StringList (so it can used in current StringList parameters), but checking client- and daemon-side that the elements are file names. --- generator/bindtests.ml | 3 ++- generator/c.ml | 29 ++++++++++++++++++++++++----- generator/csharp.ml | 4 ++-- generator/daemon.ml | 20 ++++++++++++++++++-- generator/erlang.ml | 2 +- generator/fish.ml | 10

Per discussion on IRC, here are two changes to convert all TABs-as-indentation to spaces. The first one is the fully-automated conversion. However, note that the command mentioned uses a file (the .x-sc* one) that is added only in the following patch. The second patch adds rules to help keep things that way: Document and enforce the new spaces-only indentation policy. * cfg.mk

For a very long time we have maintained two sets of utility functions, in mllib/common_utils.ml and generator/utils.ml. This changes things so that the same set of utility functions can be shared with both directories. It's not possible to use common_utils.ml directly in the generator because it provides several functions that use modules outside the OCaml stdlib. Therefore we add some