2011-01-11 13 views

risposta

5

C'è la Scheduler project on SqueakSource che assomiglia a cron per Smalltalk. Dalla panoramica:

"Start a new task scheduler and keep it around" 
scheduler := TaskScheduler new. 
scheduler start. 
"Let's save the image every hour" 
scheduler 
    do: [Smalltalk snapshot: true andQuit: false] 
    every: 60 minutes.

è possibile combinare che con il codice di blocco o di saveImageInBackgroundNicely OSProcess di cui sopra e hanno una bella soluzione facile.

+0

Grazie. Scheduler funziona abbastanza bene. Ho appena usato: do: [SmalltalkImage istantanea corrente: true eQuit: false.] E ha anche eseguito smalltalk Esegui come Adiministrator in modo che potesse salvare il file. – elviejo79

5

Result of a discussion on the mailing list, con qualche ciliegina intorno per eseguirlo solo oraria:

[[self blockUI. 
    self doUpdate. 
    SmalltalkImage current snapshot: true andQuit: false. 
    self unblockUI. 
    (Delay forDuration: (Duration hours: 1)) wait] repeat] fork 
+0

Più in basso [lo stesso thread] (http://lists.gforge.inria.fr/pipermail/pharo-project/2010-July/029851.html) c'è anche una menzione di "UnixProcess saveImageInBackgroundNicely" da * OSProcess * che può salvare un'immagine usando un processo Unix di sfondo. Potresti preferire l'uso di questo se non vuoi che l'immagine blocchi ogni ora. –

+0

Hmm. Non riesco a trovare un metodo denominato saveImageInBackgroundNicely in Pharo 1.1.1. Né una classe UnixProcess. Mi chiedo che cosa sia successo lì. – nes1983

+0

Quella classe proviene da [OSProcess] (http://www.squeaksource.com/OSProcess.html) che non è inclusa nel Pharo di base. –

1

Si può fare e potrebbe funzionare bene.

Ma io non lo farei.

Non persistenza in produzione.

Perché?

Perché le immagini sono come la tua sessione sul laptop. Salvare la tua immagine è come mettere a dormire il tuo portatile: persiste tutto.

E a lungo termine, alcuni stati avranno alcune cazzate inspiegabili che possono complicare qualcosa e sarà necessario eseguire un duro riavvio.

Non aiuta a cercare di essere perfezionista a riguardo (o forse lo fa ma non è certamente economico). Accadrà e riavviare il tuo computer portatile è la soluzione economica per avere un nuovo stato. Ma quello per la tua app smalltalk potrebbe non essere così economico.

Un duro riavvio in smalltalk significa che devi prendere una nuova immagine e caricare di nuovo tutto il tuo codice (può essere automatizzato ma l'esperienza dice che potrebbe richiedere molto tempo).

+0

+1 per aver portato questa vista ma non sono d'accordo. La persistenza basata sull'immagine può essere utilizzata con successo.Penso che anche Dabble DB si sia basato su di esso (usando un'immagine per cliente). Può essere più difficile identificare determinati problemi in un grafo di oggetti complesso piuttosto che un database basato su uno schema e Squeak stesso può gestire solo così tanti dati, ma è tutto incentrato sui trade-off. –

+1

Inoltre, per mantenere una ragionevole persistenza nelle immagini, è necessario essere flessibili sulle transazioni. Se il server (o la VM) si arresta per qualsiasi motivo prima di salvarlo, ** farà male. Non tutte le applicazioni possono consentire il lusso di non essere ACID. –

Problemi correlati