2012-01-01 6 views
6

Pracuję nad skryptem Scala, który używa czasu Jody. Aż do dzisiaj wszystko działało dobrze. W jakiś sposób coś się zmieniło i już nie działa.Dlaczego mogę używać biblioteki Java z REPL Scala, ale nie ze skryptu?

to działa:

$ scala -cp "lib/*" 
Welcome to Scala version 2.9.1.final (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_29). 
Type in expressions to have them evaluated. 
Type :help for more information. 

scala> import org.joda.time._ 
import org.joda.time._ 

scala> Period.minutes(5) 
res0: org.joda.time.Period = PT5M 

ale to nie:

$ scala -cp "lib/*" test.scala 
/Users/avi/Dev/experiments/rollups/scala/test.scala:4: error: object joda is not a member of package org 
import org.joda.time._ 
     ^
one error found 

test.scala zawiera tylko:

#!/usr/bin/env scala -cp lib/* -deprecation 
!# 

import org.joda.time._ 

Period.minutes(5) 

to też nie działa:

$ scala -cp "lib/*" -e "import org.joda.time._" 
/var/folders/c4/gh5y9_cx5bz8x_4wm060l_mm0000gn/T/scalacmd1248995773392653303.scala:1: error: object joda is not a member of package org 
import org.joda.time._ 
     ^
one error found 

To również nie jest spowodowane użyciem * w cp arg:

$ scala -cp lib/joda-time-2.0.jar:lib/joda-convert-1.2.jar -e "import org.joda.time._" 
/var/folders/c4/gh5y9_cx5bz8x_4wm060l_mm0000gn/T/scalacmd5438658792813459030.scala:1: error: object joda is not a member of package org 
import org.joda.time._ 
     ^
one error found 

... To tylko tak szalone, bo to działa ostatni raz pracował nad tym projektem, tylko dzień czy dwa lata temu! A teraz to nie działa i chyba musiałem coś zmienić, ale szczerze mówiąc nie mogę wymyślić, co to może być.

Pomoc!

Odpowiedz

12

TL; DR: fsc, "szybki demulator kompilacji", miał problem z jego pamięcią podręczną; fsc -shutdown rozwiązało problem.

Seth Tisue w the Scala IRC channel on FreeNode był w stanie pomóc mi rozwiązać mój problem - miało to coś wspólnego z fsc "demonem szybkiego kompilatora offline". Kiedy do uruchomienia skryptu użyto komendy scala, używa ona fsc i wydaje się, że w jakiś sposób ścieżka klas używana/buforowana przez demona została pomieszana.

Okazuje się, istnieje kilka sposobów obejścia tego:

  • przechodzą ARG -nocompdaemon do scala nie wystarczy użyć FSC na wszystkich
    • prac i powinna być failproof, ale powolny
  • prowadzony fsc -shutdown
    • demon zostanie automatycznie ponownie uruchomiony następnym razem użyć scala
  • bieg fsc -reset zresetować buforuje demona
    • będzie prawdopodobnie szybciej niż wyłączanie go, ale przynajmniej opcja failproof

ja nadal nie wiem dokładnie to, co spowodowało ten problem, w pierwszej kolejności, ale wrażenie, które dostałem od Setha i ze strony fsc jest takie, że czasami coś takiego się dzieje.

Dzięki, Seth!

+1

Najlepszą metodą radzenia sobie z nimi nie jest stosowanie względnych ścieżek w dyrektywach klasy ścieżki. –

+1

Dzięki @ DanielC.Sobral, to ma sens, ale wydaje się to niepraktyczne w przypadku skryptów. Mój skrypt ma to na górze: '#!/Usr/bin/env scala -cp lib/* -deprecation ! #' I chcę móc wywołać skrypt z dowolnej lokalizacji w bashu. Być może jest lepszy sposób na zrobienie tego, ale nie jest to dla mnie oczywiste, ponieważ nie jestem ekspertem od basha ani ekspertem od Scala. –

+0

Użyj trybu inwokacji alternatywnej - wywołaj sh, a następnie, z sh, wywołaj scala, w którym momencie możesz użyć pwd, aby uzyskać bieżący katalog. –

Powiązane problemy