> Ok, I spent some time digging through commits and writing tests. The
> tests I wrote actually don't have anything to do with reloading
> because I couldn't find a recent commit that required any forking or
> spawning to test.
>
> http://github.com/Manfred/rails/commits/railties-tests
>
> Josh,
On Wed, Feb 25, 2009 at 4:25 AM, Manfred Stienstra wrote:
>
> Ok, I spent some time digging through commits and writing tests. The
> tests I wrote actually don't have anything to do with reloading
> because I couldn't find a recent commit that required any forking or
> spawning to test.
>
> http
Ok, I spent some time digging through commits and writing tests. The
tests I wrote actually don't have anything to do with reloading
because I couldn't find a recent commit that required any forking or
spawning to test.
http://github.com/Manfred/rails/commits/railties-tests
Josh, can you point
>>> That sounds like a job for forking.
>>
>> That makes accumulating the failures from the child process
>> essentially impossible though, you'd end up with crazy output
>> intertwined with the parent process.
Well, let's just talk code shall we (: I'll write up some stuff and
present it to th
On Wed, Feb 25, 2009 at 4:59 PM, Michael Koziarski
wrote:
>
>> That sounds like a job for forking.
>
> That makes accumulating the failures from the child process
> essentially impossible though, you'd end up with crazy output
> intertwined with the parent process.
My assumption was that we woul
> That sounds like a job for forking.
That makes accumulating the failures from the child process
essentially impossible though, you'd end up with crazy output
intertwined with the parent process.
--
Cheers
Koz
--~--~-~--~~~---~--~~
You received this message b
On Wed, Feb 25, 2009 at 3:03 PM, Chad Woolley wrote:
> The tricky part of this would be to ensure that the spawned
> environment is identical to the current environment. For example,
> environment/rake variables, ruby interpreter being used, etc, etc.
That sounds like a job for forking.
--~--~
On Tue, Feb 24, 2009 at 12:41 PM, Manfred Stienstra wrote:
> My first intuition is to spawn new Rails process from a test and see
> if it behaves the way it should. I'll try to free up some time
> tomorrow to give it a try.
The tricky part of this would be to ensure that the spawned
environment
That sounds like a plan. Thanks for the response.
Eloy
On 24 feb 2009, at 20:41, Manfred Stienstra wrote:
>
>
> On Feb 24, 2009, at 8:36 PM, Joshua Peek wrote:
>
>>
>> On Tue, Feb 24, 2009 at 1:19 PM, Eloy Duran
>> wrote:
>>> I've also been worried about the lack of testing present in some
>>>
On Feb 24, 2009, at 8:36 PM, Joshua Peek wrote:
>
> On Tue, Feb 24, 2009 at 1:19 PM, Eloy Duran
> wrote:
>> I've also been worried about the lack of testing present in some
>> commits lately. ActionPack, and especially the Rack related code,
>> seem
>> to lack lots of necessary testing.
>>
On Tue, Feb 24, 2009 at 1:19 PM, Eloy Duran wrote:
> I've also been worried about the lack of testing present in some
> commits lately. ActionPack, and especially the Rack related code, seem
> to lack lots of necessary testing.
> Afaik the Rails policy used to be; have good test coverage or don't
Hi,
I've also been worried about the lack of testing present in some
commits lately. ActionPack, and especially the Rack related code, seem
to lack lots of necessary testing.
Afaik the Rails policy used to be; have good test coverage or don't
commit. Has this been changed?
Eloy
On 18 feb
12 matches
Mail list logo
