Status: Serialization and Spam
Gabriel M. Beddingfield
SUMMARY
-------
+ Still working on refactoring serialization. Had
a brief detour to implement smart pointers.
+ I've tweaked settings on this list so that there
should be spam. So far so good, I blocked 16
new spams the other day. :-)
I currently have about 1600 lines of patches on my hard
drive. I probably tried to chew too much at one time.
SERIALIZATION
-------------
After getting several hundred lines into refactoring the
file save/restore code (which is necc. to move the
Instruments into the Sampler), I realized that I was in dire
need of some reference-counted, managed pointer containers.
So, I stashed my changes and went back to do this.
I chose boost::shared_ptr<T> for the smart pointers. These
have a viral effect... sort of a Midas touch. Wherever they
touch, you find yourself having to convert /that/ stuff over
to a shared pointer.
It's worth it though. I found myself writing comments with
goofy contracts like, "this object takes ownership of the
pointer," and "Whoever owns this object needs to take
ownership of the objects contained in it," etc. That's all
gone. (However, I did get a couple of bugs /because/ of
the shared pointers... which was a nice learning
experience.)
I originally set out to make file save/restore totally
asynchronous. Then I realized I was taking on too much at
one time. So, I stopped where I was and used the new
Serialization as the implementation of the old stuff.
After it's all worked out, I can work on the asynchronous
save/restore.
Why do we want asynchronous save/restore? Currently, we
have to stop all audio processing in order to save or load
anything. This enables us to do it without stopping audio
processing.
SPAM
----
I'm sure that you've seen the spam. I've changed the
settings so that "messages from new members will be
moderated." I actually had it set over the holidays... but
it somehow got un-set. However, after re-setting it I was
able to trap about 16 messages.
I would like to avoid setting it where "people can request
an invitation to join the group." *I* would be a major
bottleneck in that system. :-)
Peace,
Gabriel
Patrick Shirkey
Gabriel M. Beddingfield
On Sun, 10 Jan 2010, Patrick Shirkey wrote:
> Have you checked the latest change into git?
>
> The last compile I made was around 27 Dec which went fine.
>
> Cheers.
Not yet. I bit off a big piece of meat with some gristle
in it. It's taken me a while to chew.
I finally got the changes to compile today. It fails
several of the basic tests. I expect to commit working code
in a day or two.
-gabriel
Gabriel M. Beddingfield
On Sun, 10 Jan 2010, Patrick Shirkey wrote:
> Have you checked the latest change into git?
>
> The last compile I made was around 27 Dec which went fine.
OK, you got 'em now. :-)
-gabriel
Patrick Shirkey
Gabriel M. Beddingfield
On Mon, 11 Jan 2010, Patrick Shirkey wrote:
> I get this when I try git pull
>
> Updating 0262ddf..4978d80
> error: Entry 'CMakeLists.txt' not uptodate. Cannot merge.
'git pull' is a fetch + merge. You can not merge unless
your working copy is clean. I'm guessing that you have some
sort of local modification to CMakeLists.txt.
This should get you going...
$ git reset --hard
$ git pull
A pull can sometimes fail if you're on the wrong branch,
too.
-gabriel