I want to save my Pharo image every hour on the hour automatically.
How would you make this automatic within the image?
I've seen the Pier project do this.
But I'm not sure how they do it.
TIA
There is the Scheduler project on SqueakSource that looks like cron for Smalltalk. From the overview:
"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.
You could combine that with the blocking code or OSProcess's saveImageInBackgroundNicely mentioned above and have a nice easy solution.
Result of a discussion on the mailing list, with some icing around to run it only hourly:
[[self blockUI.
self doUpdate.
SmalltalkImage current snapshot: true andQuit: false.
self unblockUI.
(Delay forDuration: (Duration hours: 1)) wait] repeat] fork
You can do it and it might work just fine.
But I wouldn't do it.
Not fot persistence in production.
Why?
Because images are like your session in your laptop. Saving your image is like putting your laptop to sleep: it persists everything.
And in the long run, some state will have some unexplainable shit that can complicate something and you will need to do a hard reboot.
It doesn't help to try to be perfectionist about it (or maybe it does but is certainly not economic). It will just happen and rebooting your laptop is the cheap solution to have fresh state. But that for your smalltalk app may not be that cheap.
A hard reboot in smalltalk will mean that you have to take a fresh image and load again all your code (it can be automated but experience tells that could be time consuming).
Related
I'm using a Pharo 6.1 image to do some CSV file processing. Sometimes my image just becomes unresponsive — I have to terminate the Pharo VM from Task Manager.
Is it necessary to use somethings like:
ensure:[toStream close]
ensure:[fromStream close]
What's a simple but reliable approach to reading and especially writing files with Pharo?
The image is not really unresponsive but the UI thread for sure is when you do a long operation like reading a big CSV file.
The best would be to for a process for doing it.
Like in:
[ target doSomeLongThing ] fork.
You can view the process in the process browser from the world menu and terminate it there.
Now that is not really something one will think about when trying things out interactively in a playground.
What I do to alleviate this situation is twofold:
Put these things in a test. Why? Because tests have a maximum duration and if things are stuck, they will come back with a time exceeded notification from the test.
Start the Zinc REPL on a port, so that I can access the system from a web browser if the UI thread is kind of stuck and restart the UI thread.
I wish the interrupt key would work in all cases but well, it doesn't and is a solid annoyance.
I am of the opinion that images should be considered as discardable artifacts and CI job should be building them regularly (like daily) so that we have some recovery path.
This is not really cool as yes, using an image and being able to come back to it without having to rebuild stuff all the time when doing explorations shouldn't frustrate us with UI thread blockages. I hate that. I have an image that is stuck on restart from some Glamour problem, it is infuriating as it cannot be debugged or anything.
You can also use:
(FileLocation imageDirectory / 'somefile.csv') asFileReference readStreamDo: [ :stream |
"do something with the stream" ].
This will do the ensure: bit for you. Cleaner. Easier.
For CSV, also give a shot to NeoCSV as it will do the file handling for you as well.
HTH
As you are working on the IDE, suddenly it has no reaction, the whole IDE become inactive and can not operate on it, but with high CPU usage, If you kill the process from Windows Task Manager, after it launched, all modified lost since your last edit. This problem occurs every now and then.
My environments:
Windows 7, Intel i7, 16GB RAM, IDEA 12.1.6 with auto save enabled.
Did anyone come across this problem before, it's to bad as my changes lost and i have to rewrite it after restarted.
You'll want to upgrade to v12.1.6 as 12.1.5 had a major bug in it that was fixed in 12.1.6. The bug prevented compiling of code in some circumstances. 12.1.6 was released only a few days after 12.1.5. That may not be the cause of your issue, but is still good advice.
Other than that, the 12.1.x line has been very stable. I think your issue is an isolated case as I have not seen any mention of it in the IntelliJ IDEA forums or here. Often times, such deadlocks are caused by third party plug-ins. Take a look in the logs (Help > Show Log) to see if it has any information that explains the hang. Also, if IDEA becomes non responsive, it automatically logs thread dumps in the log directory. Those may have some information.
If you experience the issue again, you may want to disable any third-party plug-ins to see if that resolves it. If it happens frequently, you can take a CPU Snapshot as described in this document and submit it to the JetBrains.
Lastly, I recommend you tweak the following setting: File > Settings > [IDE Settings] > General > Save files automatically if application is idle for x sec." Set it to 15 or 30 seconds. (You don't want to go too low). This will help reduce any loss of work in the event of a hang (which after 10 years of daily IDEA use I can attest to as being very rare.)
I'd like Flash Builder to kill previous run instances when I run/debug.
It's driving me nuts that I can easily accumulate multiple instances of my project running outdated code if I don't go through and kill them individually each time I run.
Thank you
This is the best answer I was able to find thanks to Lee Burrows:
There is an unbound keybinding called "Terminate and Relaunch" in the general preferences which will terminate the run/debug that is currently connected to the debugger and start a new instance. So if you only use this you can avoid accumulating outdated instances.
Putting this as an answer, but I hope someone can make something that doesn't require a change in flow (still be able to use the debug button), and this will also not kill multiple instances if that somehow still happens.
I am trying to write a tool to automatically install a binary. Basically, I use comtypes and MSAA interface to interact with the installation windows and drive the installation procedure. When a window pops up, I recursively enumerate all elements on this window, pick the most appropriate element (typically a button) to interact, and so on. The tool sometimes works fine. But sometimes, it may take very long time in enumerating the elements (could be up to 1.5 mins for a window that is not very complex). And this problem seems to be timing related. It doesn't happy all the time. I have stuck on this problem for a week. Can someone help? Please!!!
One possibility I can think of is: while I am enumerating a window, this window is destroyed by the target application, then COM is mssed up and fails to do further navigation. Could it be a potential reason? I can't convince myself on this because the window is finally enumerated. If the window disappears during the enumeration, the traversal of the window element tree should fail, no?
Try profiling the script until the issue occurs, then look through the profiling information to find out where the extra time is being spent.
Whether this is possible I don't know, but it would mighty useful!
I have a process that fails periodically (running in Windows 2000). I then have just one chance to react to it before having to restart it and painfully wait for it to fail again. I didn't write the process so don't have the source to debug. The failure is seemingly random.
With a snapshot of the process I could repeatedly and quickly test reactions to the failure.
I had thought of running inside a VM but this isn't possible in this instance.
EDIT:
#Jon Cage asked:
When you say a snapshot, you mean capturing a process when it's about to fail (including memory, program state etc. etc.) ...and then replaying it's final few seconds repeatedly to see what effect it has on some other component?
This is exactly what I mean!
I think minidump is what you are looking for.
You can also used Userdump:
The User Mode Process Dumper
(userdump) dumps any running Win32
processes memory image (including
system processes such as csrss.exe,
winlogon.exe, services.exe, etc) on
the fly, without attaching a debugger,
or terminating target processes.
Generated dump file can be analyzed or
debugged by using the standard
debugging tools.
This article shows you how to use it.
My best bet is to start the process in a debugger (OllyDbg being my preferred tool).
The process will pause on an exception, and you can try to figure out what happened shortly before that.
This needs some understanding of assembler and does not allow to create a snapshot of the process for later analysis. You would need to write your own debugger for that - it should be theoretically possible.