Zgodnie z wynikami wcześniejszych poszukiwań, do rysowania grafów w projekcie zamierzam używać biblioteki GraphX. Co prawda, jak słusznie zauważył w jednym z komentarzy Karol, istnieje bardzo ciekawa alternatywa. Syncfusion udostępnia bowiem swoje biblioteki za darmo w ramach licencji Community, dla projektów Open Source. A mają tam naprawdę mnóstwo świetnych kontrolek. I zapewne docelowo ich użyję - do zbudowania ładnego GUI. Jednak do rysowania grafów na razie wciąż spróbuję użyć GraphX, bo wydaje mi się bardziej zoptymalizowany do rysowania dużych zbiorów danych.
Na początku optymistyczne spróbowałem użyć tych kontrolek od razu w projekcie F#. Jednak odbiłem się od ściany licznych mniejszych lub większych problemów. Musiałem zatem zrobić krok wstecz i przygotować minimalny, działający przykład w starym, dobrym C#. W tym celu odchudziłem jak się tylko dało przykład .\GraphX\Examples\SimpleGraph i stworzyłem nowy projekt WPF. Jak zatem używa się GraphX? Więcej...
Trochę sporo ostatnio czasu w ramach projektu poświęciłem na naprawianie biblioteki ClrMd i pisania poradników o GitHubie. W ramach rdzennego rozwoju projektu skupiłem się na neo4j, teraz pora najwyższa wrócić do interfejsu i zastanowić się nad ważnym pytaniem - czego użyję jako biblioteki rysującej grafy. Na pierwszy ogień poszło przeglądanie “internetów” i wyszukanie opcji, których będę mógł użyć w WPF. Wynik tych poszukiwań nie jest przytłaczający. Wygląda na to, że jest pewne pole do popisu dla osoby, która napisze funkcjonalny i ładny komponent WPF do rysowania grafów. Ja w ramach tego projektu nie mam na to czasu, więc pozostaje mi korzystać z gotowców. Więcej...
W poprzednim poście posłużyłem się następującym kodem, mającym wczytać plik ze zrzutem pamięci i następnie załadować odpowiednią wersję pliku mscordacwks.dll:
use target = DataTarget.LoadCrashDump(@"..\..\..\..\data\ConsoleDump.exe.dmp")
target.SymbolLocator.SymbolPath <- @"SRV*http://msdl.microsoft.com/download/symbols"
target.SymbolLocator.SymbolCache <- @"c:\symbols"
for version in target.ClrVersions do
let dacInfo = version.DacInfo
let runtime = version.CreateRuntime()
Niestety, jak już wspomniałem, ten kod umieszczony w aplikacji WPF powoduje jej zawieszenie Więcej...
W rozwoju każdego oprogramowania przychodzi ten moment, że zdarza się pierwszy bug. Potem są już kolejne. No i ja mam za sobą ten etap – aż z wrażenia założyłem Issue we własnym projekcie:
Więcej...
Opis projektu MemoryVisualizera toczy się w kilku wątkach. Jednym z nich jest moja przygoda z F# w kontekście WPF. Po pierwszej części, w której w ogólności opisywałem jak możemy “pożenić” WPF z F#, pora kolejne kroki. Ale wcześniej potrzebne nam będzie krótkie przypomnienie z WPF w C#. Rzecz się tyczy użycia komend, do wykonywania akcji. Oraz nieśmiertelnego OnPropertyChanged do notyfikowania interfejsu o zmianie – ale o tym w kolejnej części.Więcej...
Kilka godzin pracy z F# w Visual Studio i kilka niespodzianek już za mną. Zainstalowanie Visual F# Tools (pozwalające tworzyć projekty F# w Visual Studio) jak się okazuje to był dopiero początek. Więcej...
Wstępniak: Uczę się używać F# wraz z postami o tym projekcie. Nie wszystko więc pewnie od razu będzie idealne. Za to w zamian cenne może być to, że dzielę się uwagami, spostrzeżeniami i zaskoczeniami w ramach tego procesu.
Po trzech pierwszych, wprowadzających postach pora wreszcie przejść do konkretów - kodu! MemoryVisualizer ma być aplikacją desktopową, napisaną w WPF. Nie mam jeszcze ani jednej linijki kodu, zacznę zatem od pustej aplikacji z jakiegoś szablonu. Gdybym zdecydował się na C#, sprawa byłaby prosta - startuję z pustego szablonu WPF Desktop Application i już. Mamy tam z pudełka obsługę XAML, code behind, designer itd. Jednak jak najwięcej chcę napisać w F#, zatem rodzi się pytanie - czy i jak zintegrować WPF z F#? Więcej...
W poprzedniej części opisałem wymagania wobec projektu MemoryVisualizer. Teraz pora przejść do konkretów, czyli technologii. Dla przypomnienia, piszę narzędzie, które pozwoli za pomocą jakiegoś języka zapytań wizualizować pamięć procesu .NETowego - czy to z memory dumpa, czy poprzez podpięty debugger. Wizualizacja ma być ładna - by posłużyć kiedyś do celów ilustracyjnych. Oraz szybka - by docelowo analizować gigabajtowe procesy.
Więcej...