similar to: Lazy Loading?

How do I do multiple layouts for a single controller: I am aware I can do... render(:layout =>''mylayout'') for individual actions, however this becomes a multiple render problem. I tried this... layout "mylayout", :except => [:myaction, :myotheraction] layout "myotherlayout", :only => [:myaction, :myotheraction] However that doesn''t

When I do periodically_call_remote with e.g. :frequency => 30 after initial page load I have to wait 30 seconds until this partial renders first time. Does anybody know how to make ROR to render partial on web page load, and then start periodic calls every 30 seconds? I tried to put <div id=''mydiv''><%= render(:partial, :action=>''myaction'')

Hi everyone. : ) I meet problem when use form tag in actionmailer. (content-type is text/html, surely) I want to use form action in actionmailer''s view (.rhtml) for some reason. 1. I use start_form_tag helper method as normally, but how I can ? I did <%= start_form_tag :action => "http://myhostname/mycontroller/myaction" %> or <%= start_form_tag :action =>

Hello all, Following a question in r-help, where I was wondering why my large package with lots of "Depends:" did load so slowly (almost 30 sec in lazy loading in R 2.0.0 under Win XP, for 3.4 sec in R 1.9.1 on the same machine), I discovered that a correct namespace changes everything: with the namespace added, loading of my package drops to circa 1 sec, which is more that three times

Hi All, I have read the article on lazy-loading in the September R news letter, and think I have at least a vague grasp on what is happening. Am I right in thinking that, assuming I were using the same packages, I could copy the .rdb & .rdx files from one installation of R (2.0.0) to another? I ask this as I'm trying to cross-compile R (for ARM), and need to use R itself to perform the

I have a function in one of my packages that I would like to print using the original source rather than the deparse of the function. The package uses lazy loading and the help page for library (under keep.source) says that keep.source does not apply to packages that use lazy loading and that whether those functions keep the source depends on when they are installed. This package is on R-forge

I have two objects that are associated in the following way: class Class1 < ApplicationController has_and_belongs_to_many :class2s has_and_belongs_to_many :otherClasses end class Class2 < ApplicationController has_and_belongs_to_many :class1s has_and_bleongs_to_many :otherClasses end Now, when I run the following query, @objects = Class1.find(:all, :conditions

On Wed, Oct 28, 2009 at 9:50 AM, Chris Lattner <clattner at apple.com> wrote: > > On Oct 28, 2009, at 9:41 AM, Jeffrey Yasskin wrote: > >> In r85295, in response to the discussion at http://llvm.org/PR5184 >> (Lazy JIT ain't thread-safe), I changed the default JIT from lazy to >> non-lazy. It has since come to my attention that this may have been >> the

On Oct 28, 2009, at 9:41 AM, Jeffrey Yasskin wrote: > In r85295, in response to the discussion at http://llvm.org/PR5184 > (Lazy JIT ain't thread-safe), I changed the default JIT from lazy to > non-lazy. It has since come to my attention that this may have been > the wrong change, so I wanted to ask you guys. > > A couple reasons to make the default non-lazy compilation:

>From where I sit, this boils down to a very simple question (modulo Chris's point): Either choice will surprise some users. Which surprise is worse? Personally, I'd always prefer correct but slow behavior by default, and explicitly enabling dangerous (but in some cases fast) behavior. I would also point out that it seems that most of the people new to the JIT are surprised by the

On Wed, Oct 28, 2009 at 9:57 AM, Jeffrey Yasskin <jyasskin at google.com> wrote: > On Wed, Oct 28, 2009 at 9:50 AM, Chris Lattner <clattner at apple.com> wrote: >> >> On Oct 28, 2009, at 9:41 AM, Jeffrey Yasskin wrote: >> >>> In r85295, in response to the discussion at http://llvm.org/PR5184 >>> (Lazy JIT ain't thread-safe), I changed the

Dear Lister, I work with R 2.0.1 and Windows XP, and meet a strange trouble trying to make a R package with a make-package.bat file John Fox has kindly provided (see detailed script below). I am working with it since some months with excellent results (I do'nt use compiled C code so far). Just adding a new function in the R directory today, when running make-package and thus excuting

Hi, > I looks like the code is calling dlopen() on LLVMPolly.so and it or something it links against has an initializer. The initialer is run before dlopen() returns and the crash is in the initializer. The message: > > dyld: fast lazy bind offset out of range (53437, max=7640) in image /sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/cc1 > > means the initializer

On Wed, Oct 28, 2009 at 12:21 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Oct 28, 2009, at 10:07 AM, Chandler Carruth wrote: > >> From where I sit, this boils down to a very simple question (modulo >> Chris's point): Either choice will surprise some users. Which surprise >> is worse? Personally, I'd always prefer correct but slow behavior by

Code that takes the default lazy behavior will still work if the default is changed to non-lazy. The only way non-lazy breaks (as far as I know) is if you've already done some lazy JITting and left some lazy stubs laying around. And code that does that will still work, after adjusting to an API change. This is one of the least disruptive breaking API changes imaginable. And getting rid of

In r85295, in response to the discussion at http://llvm.org/PR5184 (Lazy JIT ain't thread-safe), I changed the default JIT from lazy to non-lazy. It has since come to my attention that this may have been the wrong change, so I wanted to ask you guys. A couple reasons to make the default non-lazy compilation: * The lack of thread-safety surprises new users * Crashes due to this will be rare

Are you objecting to Chris's proposal? I was waiting to implement it until you replied so I wouldn't have to implement two things. I disagree with a lot of what you wrote below, but it's not worth arguing about if there's a compromise we can both live with. On Thu, Oct 29, 2009 at 12:36 AM, Evan Cheng <evan.cheng at apple.com> wrote: > There is nothing here that prevents

On 2009-11-01 08:40, Jeffrey Yasskin wrote: > 2009/10/30 Török Edwin <edwintorok at gmail.com>: > >> On 2009-10-29 23:55, Jeffrey Yasskin wrote: >> >>> On Thu, Oct 29, 2009 at 2:30 PM, Nicolas Geoffray >>> <nicolas.geoffray at lip6.fr> wrote: >>> >>> >>>> Hi Jeffrey, >>>> >>>>

There is nothing here that prevents users from enabling or disabling lazy JIT. We're talk about flipping the default behavior. That does not make the API any better or worse. Nor does it fix the inherent thread safety issue. I can tell you there are no Apple clients that depend on the lazy JIT. Please do not imply I am being secretive. I am simply busy. My objection is simple.

A possible patch implementing this is at http://codereview.appspot.com/144074 (http://codereview.appspot.com/download/issue144074_1.diff). I do NOT think we should accept this patch: It changes a lot of APIs and makes users specify the choice in many places, while I think most users really just want one choice for their whole app. There's a good argument to be made that users may want to