Michał Turecki - c#

On Protobuf.Net, using AsReference and multiple instances of object which should be deserialized only once.

Michał Turecki — Thu, 27 Nov 2014 14:13:47 +0000

There is a ProtoBuf.Net fact regarding using AsReference which somehow I missed when digging into why [ProtoAfterDeserialization] attribute is not applied for some objects.
The truth is that it is applied for some but not other objects even if I used AsReference attribute in some places. The AsReference attribute should be applied to ALL REFERENCES TO THE OBJECT, both collections and navigational properties, NOT JUST REFERENCES OTHER THAN THE REFERENCE WE CONSIDER MAIN ONE.

A simple test to prove it is below:

using System.Collections.ObjectModel;
using System.IO;
using System.Linq;
using NUnit.Framework;
using ProtoBuf;

namespace ProtoBufAsReferenceTest
{
    [ProtoContract]
    public class Office
    {
        public static int DeserializationCounter = 0;

        [ProtoMember(1)]
        public Collection<Computer> Computers { get; private set; }

        [ProtoMember(2)]
        public Collection<Person> People { get; private set; }

        public Office()
        {
            Computers = new Collection<Computer>();
            People = new Collection<Person>();
        }

        [ProtoAfterDeserialization]
        protected void OnDeserialize()
        {
            DeserializationCounter++;
            foreach(var computer in Computers)
            {
                computer.Office = this;
            }
            foreach(var person in People)
            {
                person.Office = this;
            }
        }
    }

    [ProtoContract]
    public class Computer
    {
        public static int DeserializationCounter = 0;

        [ProtoMember(1, AsReference = true)]
        public Person Person { get; set; }

        [ProtoIgnore]
        public Office Office { get; set; }

        [ProtoAfterDeserialization]
        protected void OnDeserialize()
        {
            DeserializationCounter++;
        }
    }

    [ProtoContract]
    public class Person
    {
        public static int DeserializationCounter = 0;

        [ProtoMember(1, AsReference = true)]
        public Computer Computer { get; set; }

        [ProtoIgnore]
        public Office Office { get; set; }

        [ProtoAfterDeserialization]
        protected void OnDeserialize()
        {
            DeserializationCounter++;
        }
    }

    [TestFixture]
    public class TestClasses
    {
        [Test]
        public void TestAsReference()
        {
            // 3 instances are created 1 of each type
            var office = new Office();
            var computer = new Computer();
            var developer = new Person();

            office.Computers.Add(computer);
            office.People.Add(developer);
            computer.Person = developer;
            developer.Computer = computer;

            using(var ms = new MemoryStream())
            {
                Serializer.NonGeneric.Serialize(ms, office);
                ms.Position = 0;
                Check(Serializer.Deserialize<Office>(ms));
            }
        }

        private void Check(Office office)
        {
            Assert.AreEqual(1, Office.DeserializationCounter);
            Assert.AreEqual(1, Person.DeserializationCounter); // fails - 2
            Assert.AreEqual(1, Computer.DeserializationCounter); // fails - 2
            var computer = office.People.First().Computer;
            Assert.IsNotNull(computer.Office); // fails - Office is null
        }
    }
}

Office class contains collections of Computers and Peoople without AsReference attribute. Person reference to the Computer for a change uses AsReference attribute. In the end 2 instances of Computer and 2 instances of Person are created.

Only change necessary to fix this problem is adding AsReference to the Office class collections:

        [ProtoMember(1, AsReference = true)]
        public Collection Computers { get; private set; }

        [ProtoMember(2, AsReference = true)]
        public Collection People { get; private set; }

I am not sure if this is common mistake people make when using ProtoBuf.Net but I suspect this might be the case as none of the questions on StackOverflow I've seen in the past mention this.
Or maybe it is only me who when using word "reference" thinks of references to the actual object which implies having at least a single copy of the actual object marked without "AsReference".
Bottom line is if you use AsReference, use it everywhere the object is referenced.

programming

protobuf

serialization

FlowDocument from a different thread - "The calling thread cannot access this object because a different thread owns it."

Michał Turecki — Mon, 07 Jul 2014 14:28:23 +0000

The FlowDocument along with most of the elements it contains inherits from DispatcherObject class. This means when constructed, it becomes linked to the thread in which it was constructed and causes several implications.

I'm sure such link was created for a reason - so that FlowDocument objects presented using WPF are not modified in a background thread as the updating is probably not implemented. I also won't debate on why objects contained in FlowDocument have no common, shared way of visiting them (IAddChild interface is helping with adding but something like IHaveChildren is not implemented).

Back to the topic - FlowDocument created by one thread cannot be used in another nor any of each one's inner objects. Or can't it?

One solution includes serializing a document in one thread and deserializing it in another (see this blog entry). This is a slow process as serialization is costly and serialization of a FlowDocument object with images and other graphical elements might not work at all unless XamlPackage format is used - and this one is even slower as requires ZIP compression/decompression.

Another is to create all FlowDocument objects on UI thread (see this SO article). Seems easy to do but what if there are thousand of objects which need to be added to a FlowDocument and at the same time user interface should stay responsive, even if it only needs to display a progress dialog ?

I found out another way to solve this problem, it is kind of hackish but seems to do the job for my needs:

public static void AttachToCurrentThread(this FlowDocument document)
{
	var dispatcher = Dispatcher.CurrentDispatcher;
	var field = typeof(DispatcherObject).GetField("_dispatcher", BindingFlags.NonPublic | BindingFlags.Instance);
	if(field == null)
	{
		throw new InvalidOperationException("_dispatcher property missing on DispatcherObject");
	}
	SetDispatcher(document, field, dispatcher, FlowDocumentVisitors);
}

private static readonly Func<object, object>[] FlowDocumentVisitors =
{
	x => (x is FlowDocument) ? ((FlowDocument) x).Blocks : null,
	x => (x is Section) ? ((Section) x).Blocks : null,
	x => (x is BlockUIContainer) ? ((BlockUIContainer) x).Child : null,
	x => (x is InlineUIContainer) ? ((InlineUIContainer) x).Child : null,
	x => (x is Span) ? ((Span) x).Inlines : null,
	x => (x is AnchoredBlock) ? ((AnchoredBlock) x).Blocks : null,
	x => (x is Paragraph) ? ((Paragraph) x).Inlines : null,
	x => (x is Table) ? ((Table) x).RowGroups : null,
	x => (x is Table) ? ((Table) x).Columns : null,
	x => (x is Table) ? ((Table) x).RowGroups.SelectMany(rg => rg.Rows) : null,
	x => (x is Table) ? ((Table) x).RowGroups.SelectMany(rg => rg.Rows).SelectMany(r => r.Cells) : null,
	x => (x is TableCell) ? ((TableCell) x).Blocks : null,
	x => (x is TableCell) ? ((TableCell) x).BorderBrush : null,
	x => (x is List) ? ((List) x).ListItems : null,
	x => (x is ListItem) ? ((ListItem) x).Blocks : null
};
	
private static void SetDispatcher(object item, FieldInfo field, object value, params Func<object, object>[] selectors)
{
	if(item is DispatcherObject)
	{
		var currentDispatcher = field.GetValue(item);
		if(currentDispatcher != null && currentDispatcher != value)
		{
			field.SetValue(item, value);
		}
	}
	if(item is IEnumerable)
	{
		foreach(var subItem in item as IEnumerable)
		{
			SetProperty(subItem, field, value, selectors);
		}
	}
	if(selectors != null)
	{
		foreach(var selector in selectors.Select(x => x(item)).Where(x => x != null))
		{
			SetProperty(selector, field, value, selectors);
		}
	}
}

Basically it just traverses FlowDocument and it's objects searching for DependencyObject instances and using reflection updates the _dispatcher private variable. This variable name can change in the future, the FlowDocument structure also can change so this solution can be considered not elegant or not stable but having said that DispatcherObject didn't change since .Net 3.5 and AttachToCurrentThread function can be easily adapted to handle different types of FlowDocument blocks and it's inner objects when those inherit from DispatcherObject.

If you are just reading this paragraph then feel free to leave some feedback, especially if I missed any important collections of DispatcherObject instances in the selectors array.

Update:

The previous code was expecting an IEnumerable as input and while this is fine and optimal (less calls) but not flexible enough to handle special cases well.
Unfortunately loading of a packed FlowDocument object, saved using XamlPackage format will fail on a non-STA thread ("The calling thread must be STA, because many UI components require this" exception thrown when TextRange.Load is called on a non-UI thread). This is a show-stopper for me so I can't use the code above anymore but it might become handy for someone not using Images.
I also updated it to support tables and lists and commented out style handling which I did not need (Styles are usually not tied to a thread anyway).
Actually the code can be generalized to handle any object, just change AttachToCurrentThread document argument type to object.

Update 2:
Some cosmetic changes and added a couple additional FlowDocument elements in a visitor.

flowdocument

programming

Kalkulator wygranych amino lotto 2009 oraz 2010

Michał Turecki — Sat, 29 Aug 2009 09:44:58 +0000

Do końca roku Amino przygotowało ciekawą loterię - mozna wygrać wielokrotność 1000 złotych, ale nie więcej niż 10000 zł zbierając opakowania na przyprawy z zupek, na których jest jedna lub dwie kwoty, które należy sumować. Do tej żmudnej operacji przygotowałem narzędzie, które jest zdecydowanie łatwiejsze w użyciu niż kalkulator na stronie producenta.

Wiadomo, że szanse wygranej są na tyle duże, na ile drukowane liczby są spreparowane przez producenta tak, aby sumy dawały okrągłe liczby tylko dla pewnej części opakowań, a z tego co zdążyłem zauważyć pula liczb jest dość ograniczona dając bardzo przewidywalne ilości wygranych. Z mojej puli liczb, nawet powtórzonej kilkukrotnie, nie udało się uzyskać żadnej wygranej. Pomimo tego spróbować można, w końcu zupki Amino nie są takie złe :)

Kalkulator korzysta ze słownika liczb umieszczonego w folderze z programem, o nazwie "amino.txt", który wczytuje przy otwieraniu programu i zapisuje przy zamykaniu, aby ułatwić zarządzanie swoją indywidualną pulą liczb. Liczby wprowadza się w nowych liniach lub przez oddzielenie spacjami, a słowa które nie są liczbami są pomijane. Parametry wyliczania można zmienić, jeśli kiedyś powstanie inna podobna loteria. Przycisk wylicz powoduje wyszukanie wygranych, znajdywane są wszystkie kombinacje liczb (również wielokrotne wystąpienia tych samych) i wiadomo - lepiej wybrać najwyższą lub zebrać więcej opakowań i poczekać na jeszcze wyższą.

Dołączam też źródła programu z licencją "róbta co chceta" w zamian za podziękowanie w komentarzu.

Aktualizacja

Ponieważ program nie działał wystarczająco szybko przy dużej ilości wprowadzonych liczb, przerobiłem go tak aby używał HashSet i wyznaczał wartość hash dla szukanych sum:


int hash = (nums.IndexOf(item) + 1) * num.Value;
int sumHash = hash1 ^ hash2;

Aktualizacja

Na stronie http://www.e-konkursy.info/forum/post-870037-cat-1-pg-20.html jest umieszczony wątek na temat konkursu. Z kwot uzbieranych przez forumowiczów jasno wynika, że gdy liczba znaleziona w opakowaniu jest podzielna przez 11 wygranej nie będzie, gdyż suma dowolnych liczb podzielnych przez 11 nie da wielokrotności liczby 1000 mniejszej niż 11000. Tak czy inaczej kalkulator pomoże znaleźć kombinację liczb dającą najwyższą wygraną, jeśli łut szczęścia dopisze i trafimy na liczbę niepodzielną przez 11. Powodzenia !

Aktualizacja 24.09.2009 (wersja 2.0)

Przygotowałem kolejną wersję programu, która w porównaniu z poprzednią nie pokazuje powtarzających się wygranych, liczy dużo pewniej niż poprzednia i zdecydowanie szybciej. Uaktualniony jest też kod źródłowy programu do pobrania (amino_source.zip). Wszystkich zgłoszonych błędów już nie ma, ale oczywiście do uruchomienia programu potrzebny jest .Net framework 3.5 SP1 - (http://www.microsoft.com/downloads/details.aspx?FamilyID=AB99342F-5D1A-413D-8319-81DA479AB0D7&displaylang=pl)

Aktualizacja 15.10.2009 (wersja 2.5)

W związku z licznymi prośbami o szybsze działanie programu dziś powstała nowa wersja, która przed wyszukaniem kombinacji liczb szuka liczb podzielnych przez 11 i jeśli wszystkie liczby są podzielne przez 11, informuje, że nie znaleziono wygranej. Oczywiście liczbę 11 można zmienić lub nie wpisać jej wcale. W prawdzie jest to tylko ominięcie problemu, ale dla loterii jest całkiem skuteczne - jeśli masz dużo liczb i program się zawiesi przy liczeniu to prawdopodobnie masz wygraną :)
Przyspieszenie liczenia kombinacji jest możliwe, ale wymaga stosowania bardziej złożonych technik liczenia kombinacji, a "brutalne" liczenie (prawie) wszystkich kombinacji użyte w programie jest bardzo czasochłonne stąd mała jego wydajność - ilość obliczeń dla każdej kolejnej ilości wygranych liczb wyznaczana jest według wzoru: http://pl.wikipedia.org/wiki/Kombinacja_bez_powtórzeń

Aktualizacja 22.11.2009

Do sprawdzania podzielności kwot przez 11 i szukania potencjalnych wygranych przygotowałem kalkulator online, który we wprowadzonym tekście wyszukuje kwoty trzy i czterocyfrowe, które mogą dać wygraną. Zbieżność dnia i miesiąca dzisiejszej daty z podzielnością w loterii amino jest czysto przypadkowa :)

Aktualizacja 29.12.2009

Ponieważ loteria dobiega końca, udostępniłem do pobrania kalkulator onima.exe, który 2-3 miesiące temu był wystawiony na allegro, a w międzyczasie został dopracowany. Kalkulator jest szybki i bezbłędny, polecam.

Aktualizacja 18.07.2010

Witam wszystkich! Nie miałem możliwości śledzenia losów nowej loterii, więc aktualizuję stronę dopiero teraz. Tym razem loterię sponsoruje liczba 13, więc zrobiłem kilka zmian - szukanie liczb podzielnych przez 13 działa od dzisiaj na stronie w forumlarzu poniżej, można szybko sprawdzić czy mamy wygrywającą liczbę. W pobieralni wrzuciłem onima2010.exe, który liczy zgodnie z zasadami nowej loterii i znajduje kombinacje liczb dające wygraną. Niestety nie gwarantuję, że program działa poprawnie, gdyż piszę z wysp i nie widziałem loterii na oczy, sugeruję się tylko tym co piszecie poniżej. Powodzenia!

Aktualizacja 20.07.2010

Jeszcze o licencji: kalkulator onima (2009 i 2010) jest i będzie darmowy, możecie go używać bez ograniczeń, jednak nie można go sprzedawać, modyfikować czy podszywać się pod autora. Jeśli ktoś z Was znajdzie onima2010 w sprzedaży na Allegro, Ebay lub innym serwisie aukcyjno-ogłoszeniowym, dajcie znać w komentarzach, a najlepiej od razu zgłoście do obsługi tego serwisu jako naruszenie regulaminu. Dzięki, pozdrawiam.

Wyszukiwarka liczb wygrywających
Wprowadź do pola poniżej liczby, oddzielone dowolnymi znakami i naciśnij Szukaj.

Wklej tekst do pola powyżej i naciśnij przycisk "Wylicz" ...

Attachment	Size
onima.exe - wydajny kalkulator (loteria 2009)	20 KB
onima2010.exe	20 KB

download

programming