HEAD broken

classic Classic list List threaded Threaded
7 messages Options
tog
Reply | Threaded
Open this post in threaded view
|

HEAD broken

tog
héhé It's me again with two bad news  ;-)

1- Well you guess that HEAD is broken in UberTestCaseLongRunningTests
we have 15 new errors there related to:
  TupleListTest
  PropertyTest
  MethodTest
  GStringTest
  ForTest
  IfElseTest

2- ClassReloadingTest is working thanks to a Thread.sleep in between the
two file
writes. This could be a good news the bad thing is that we can't rely on
File.lastModified
to tell if a groovy file has been modified since in the previous
TestCase the method
returned the same value for two versions of the same file.

md5 : one point     lastModified : 0 point   (yes it's soon the
Eurovision song contest ;-) )

I will commit the modified test but we still have to think about this
proble.

cheers
tog
Reply | Threaded
Open this post in threaded view
|

Re: HEAD broken

Jochen Theodorou
tog schrieb:

> héhé It's me again with two bad news  ;-)
>
> 1- Well you guess that HEAD is broken in UberTestCaseLongRunningTests
> we have 15 new errors there related to:
>  TupleListTest
>  PropertyTest
>  MethodTest
>  GStringTest
>  ForTest
>  IfElseTest

fixed

> 2- ClassReloadingTest is working thanks to a Thread.sleep in between the
> two file writes. This could be a good news the bad thing is that we can't
 > rely on File.lastModified to tell if a groovy file has been modified
 > since in the previous TestCase the method returned the same value for
 > two versions of the same file.
>
> md5 : one point     lastModified : 0 point   (yes it's soon the
> Eurovision song contest ;-) )

so the contents where different but the lastModified not?

> I will commit the modified test but we still have to think about this
> proble.

hmm... yes

bye blackdrag

Reply | Threaded
Open this post in threaded view
|

Re: HEAD broken

Edward Povazan
In reply to this post by tog


tog wrote:
> This could be a good news the bad thing is that we can't rely on
> File.lastModified to tell if a groovy file has been modified since

lastModified is in millis - it is possible to write fast enough to be within 1
milli. I don't think you can rely on it anywhere, especially since the file
metadata is likely cached in ram and not written to disk right away (depending
on the OS).

Just run
def file = new File("hello.txt")
try {
        file << "Hey"
        println file.lastModified()
        file << "There"
        println file.lastModified()
} finally {
        file.delete()
}
repeatedly in GroovyConsole and you will see the same numbers appear.

-Ed
tog
Reply | Threaded
Open this post in threaded view
|

Re: HEAD broken

tog
In reply to this post by Jochen Theodorou


On 3/30/06, Jochen Theodorou <[hidden email]> wrote:
tog schrieb:
> héhé It's me again with two bad news  ;-)
>
> 1- Well you guess that HEAD is broken in UberTestCaseLongRunningTests
> we have 15 new errors there related to:
>  TupleListTest
>  PropertyTest
>  MethodTest
>  GStringTest
>  ForTest
>  IfElseTest

fixed

cool ;-)
 

> 2- ClassReloadingTest is working thanks to a Thread.sleep in between the
> two file writes. This could be a good news the bad thing is that we can't
> rely on File.lastModified to tell if a groovy file has been modified
> since in the previous TestCase the method returned the same value for
> two versions of the same file.
>
> md5 : one point     lastModified : 0 point   (yes it's soon the
> Eurovision song contest ;-) )

so the contents where different but the lastModified not?

exactly and that was the reason why the test did fails on Linux and MacOS X.
 

> I will commit the modified test but we still have to think about this
> proble.

hmm... yes

héhé now we have  to ;-)

bye blackdrag


Reply | Threaded
Open this post in threaded view
|

Re: HEAD broken

Jochen Theodorou
tog schrieb:
[...]
>      > I will commit the modified test but we still have to think about this
>      > proble.
>
>     hmm... yes
>
> héhé now we have  to ;-)

I asked for ideas in the german java newsgroup, always a good source for
ideas. There was a suggestion like this:

1. compare lastModified. if not equal -> change
2. if currentTime-lastModified > 2000 -> no change
3. compare file size. if not equal -> change
4. compare make checksums

so the checksum is only made if the changetime is newer than 2 seconds
ago and the file size is not changed. This means the checksum should eb
made only in rare cases.

bye blackdrag
tog
Reply | Threaded
Open this post in threaded view
|

Re: HEAD broken

tog


On 3/30/06, Jochen Theodorou <[hidden email]> wrote:
tog schrieb:
[...]
>      > I will commit the modified test but we still have to think about this
>      > proble.
>
>     hmm... yes
>
> héhé now we have  to ;-)

I asked for ideas in the german java newsgroup, always a good source for
ideas. There was a suggestion like this:

1. compare lastModified. if not equal -> change
2. if currentTime-lastModified > 2000 -> no change
3. compare file size. if not equal -> change
4. compare make checksums

so the checksum is only made if the changetime is newer than 2 seconds
ago and the file size is not changed. This means the checksum should eb
made only in rare cases.

Hum this cascading sounds good to me.
cheers
tog

bye blackdrag

tog
Reply | Threaded
Open this post in threaded view
|

Re: HEAD broken

tog
In reply to this post by Jochen Theodorou
I think we still need to correct the current code  - this should not prevent  to refactor it in some way if it  has to  be.

I was trying to implement your suggestion but neither checksum nor file size are available
and we are trying to compare the time from a class to the time of the groovy source code
so probably the class timestamp is always bigger that the one of the source file.

Therefore I think the cache should contain more information than just a name and the class itself including for example the initial file size. Does it make sense ?

cheers
tog




   

On 3/30/06, Jochen Theodorou <[hidden email]> wrote:
tog schrieb:
[...]
>      > I will commit the modified test but we still have to think about this
>      > proble.
>
>     hmm... yes
>
> héhé now we have  to ;-)

I asked for ideas in the german java newsgroup, always a good source for
ideas. There was a suggestion like this:

1. compare lastModified. if not equal -> change
2. if currentTime-lastModified > 2000 -> no change
3. compare file size. if not equal -> change
4. compare make checksums

so the checksum is only made if the changetime is newer than 2 seconds
ago and the file size is not changed. This means the checksum should eb
made only in rare cases.

bye blackdrag