Seen on IRC yesterday. The python-scripting capability of FreeCAD(a Qt + OpenCascade based free CAD-program) allows calling opencamlib for toolpath-calculations much like is done from HeeksCAD/CNC(a Wx + OpenCascade based free CAD-program).
Cool.
Another screenshot with waterline:
I normally don't run many laps around a short loop, but in the combination of heavy winds, heavy rain, lightning, and thunder yesterday evening I thought it would be nice to stay close to home. After 2k of warmup I tried to keep the pace up. The fastest kilometer was 4:53 and the slowest 5:11.
Testing gigabit ethernet from work (top GbE, bottom 100Mbit):
Full-moon and clouds do not make for good astrophotography...
Here's a simple test program using LibQGLViewer (screen capture with xvidcap). The vertex array and the index array that OpenGL draws (using glDrawElements) are held in a GLData class which holds a mutex. The Viewer class locks the mutex while drawing, and the worker-thread locks the mutex while updating the data. Here the worker task re-positions the original vertex position, signals the Viewer to draw, and then sleeps for 40 ms. When we don't rotate or zoom with the mouse the frame-rate should thus be 25 Hz. Rotating or zooming causes more frequent re-draws and a higher frame-rate.
To gain any real benefit on a multi-core machine I think the worker thread needs to work on a 'dirty' copy of the data, and we only lock the mutex for a minimal time while swapping in the updated data for the real data. Anyone have any good example code for this? Both a case where the worker produces new data at a slow rate (slower than Viewer re-draws), and at a faster rate should be handled.
Here's an UML(ish) diagram drawn with dia:
Code.
4.2km course. Ran about 5.45km in a time of 1h 4 mins.
A bit of a loop when searching for #1. Between #2-#3 there's some unnecessary zigzag. #5-#6 should have probably taken a straighter path on compass heading through the woods to the open clearing (now just ran along paths). Otherwise OK orienteering-wise, but quite slow going in the dark and rain. Would need more courage to run fast in the wet dark slippery conditions...
I've looked at this example from 2003 and converted it to something that compiles with qt4.7. Here: https://github.com/aewallin/sandbox/tree/master/qt_opengl_threads
Each window is a QGLWidget with its own QThread associated with it that does the drawing. That means the UI should stay responsive despite heavy processing in the threads.
I wonder if this can be made to work with libQGLViewer ?
(The screenshot has caught many windows in the middle of a drawing operation. I couldn't get double-buffering to work. In practice it looks very smooth to the eye.)
Long slow distance at 6:40/km
Update5: Day 4 and it looks like this: laptop 18078 items (5.5Gb), desktop 17803 items (5.5Gb). I wonder why the file-count differs?
Update4: Day 3 of this experiment. Machines have been online for more than 72 hours. In total 50Mb have been uploaded from laptop today (since reboot in the morning). That might be a good sign. All the files should now be in the "cloud". But are they synced to my other machines? Laptop still shows 18800+ files, desktop now shows 17800 files. Getting close...
Update3: Here's another observation, when the laptop, which still has about 11000 un-synced files in the One-folder, boots up, ubuntuone-syncdaemon can take 1-3 minutes of 100% cpu and about 300Mb RAM. After that it settles down, but 100% cpu means the machine is slow and unresponsive for a while 🙁
Update2: Someone at canonical asked for my log-files (they are in ~/.cache/ubuntuone/log/), and I've sent them. Hope they find what is going wrong!
Update1: the sync does seem coupled to a reboot. This morning it appears about 400Mb more was synced after a reboot of the machine. I still have about 11000 files un-synced after 48 hours.
These days data wants to be distributed and in the cloud. This image shows my Ubuntu One folders on three machines. They are supposed to be in sync, but are far from that after being connected to a high-speed network for more than 24 hours 🙁
OK, so let's go buy 20Gb of space on Ubuntu One, and transfer my working-set of work/hobbies/etc files there and see how it goes. I use about three computers regularly, a new laptop at work, and a desktop and an old laptop at home. The work machine is on the university network where bandwidth shouldn't be a problem, and I have 40Mbit broadband from welho at home. What could possibly go wrong?
Ubunutu One is very very slow. I didn't just dump all my files and pictures into the shared-folder at once, I thought I'd start with a subset which happened to be 18064 files taking up 5.5Gb. It appears that in the first 24 hours roughly 700 Mb of data was synced. Now I have rebooted the primary laptop and it has very rapidly sent out another 500 Mb - but then slowed down to a creep. Is there a bandwidth-cap? For paying users?
Does anyone use Dropbox for lots (10s of thousands) of files? Does it work? Fast?
