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 poprzednich częściach znęcałem się nad biblioteką ClrMd i zawartym w niej niedopatrzeniu – poważnym problemie z deadlockiem. Korzystając, że jest to Open Source dostępny na GitHubie, czuję się w obowiązku spróbować dostarczyć oficjalną poprawkę. A to świetna okazja do napisania artykuliku o tym, jak to formalnie przeprowadzić.
Mając namierzony błąd w ukochanym projekcie, zacząć musimy od rzeczy podstawowej - issue. Jeśli błąd zgłosił już ktoś inny, na razie nie musimy się tym przejmować. Ale jeśli jesteśmy “szczęściarzami” i pierwsi coś odkryliśmy, zanim przystąpimy do dalszych działań błąd taki najlepiej formalnie zgłosić. Więcej...
W poprzednim wpisie zmieniłem system zarządzania zależnościami z Nugeta na Paket. Ściąganie paczek Nugetowych skonwertowało się automatycznie za pomocą dołączonego narzędzia, teraz pora dodać główny cel tych zabiegów - archiwum z przenośną (samowystarczalną) wersją Neo4j.
Jest ona dostępna pod poniższym adresem i trochę waży:
$ wget http://neo4j.com/artifact.php?name=neo4j-community-3.0.1-windows.zip
...
Length: 62661995 (60M) [application/zip]
Aby dodać taką zależność musimy ją dodać do pliku packet.dependencies:
$ more paket.dependencies
source https://www.myget.org/F/roslyn-nightly/
source https://www.myget.org/F/dotnet-core
source https://www.nuget.org/api/v2/
framework >= net45
nuget FsXaml.Wpf 0.9.9
nuget Microsoft.Diagnostics.Runtime 0.8.31-beta
http http://neo4j.com/artifact.php?name=neo4j-community-3.0.1-windows.zip
Więcej...
Tak jak pisałem w jednym z poprzednich postów, zdecydowałem się użyć Paket do zarządzania zależnościami w projekcie. Dlaczego? Ponieważ poza zależnościami NuGetowymi, mam jedną dużą, niestandardową - standalone binarki bazy neo4j. Tak jak pisałem, Paket poza źródłami z serwerów NuGetowych potrafi korzystać ze źródeł Gita oraz po prostu zasobów dostępnych przez HTTP. Ostatnio trochę oszukałem, mówiąc, że neo4j jest dostępny w samowystarczalnym pliku ZIP pod adresem http://neo4j.com/download-thanks/?edition=community&flavour=winzip. Stronka ta jedynie rozpozczyna auto-download pliku pod adresem http://neo4j.com/artifact.php?name=neo4j-community-3.0.1-windows.zip i to ten plik będę musiał wskazać jako zależność HTTP.
Ten wpis opisuje natomiast sposób konwersji klasycznej solucji opartej o Nugety (i plik packages.config) do wersji używającej Paketa. Więcej...
Przygody z deadlockiem (czy jak kto woli – zakleszczeniem) w bibliotece ClrMd ciąg dalszy. W poprzedniej części obszedłem problem po stronie aplikacji, jednak chciałbym przyczynić się do poprawy życia ludzkości i naprawić ten problem w samej bibliotece. Widzę tu trzy wyjścia. 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...
Projekt MemoryVisualizera toczy się w kilku wątkach, ale jak na razie dość mało poświęciłem jednemu z najważniejszych - analizy pamięci. Planuję bardziej rozbudowany post o tym jak można się do pamięci dobrać i co tak naprawdę siedzi pod spodem. Na razie jednak jako "zajawkę" przedstawię sposób, którym się będę przez dłuższy czas posługiwał. A chodzi o świetną bibliotekę ClrMd, która to jako dostępna na Nuget, oferuje interfejs .NETowy do analizy pamięci. Szukając go w Visual Studio pamiętajmy zaznaczyć opcję "Include prerelease" ponieważ jest to wciąż biblioteka w wersji rozwojowej.
Więcej...
W poprzedniej części wątku WPFowego projektu MemoryVisualizer skupiłem się na przypomnieniu, czym jest i jak implementować komendę (interfejs ICommand) w C#. Dla przypomnienia, napisałem ogólne rozwiązanie, któremu podaje się odpowiednie metody, dzięki czemu jest całkowicie reużywalne:
public class CommandHandler : ICommand
{
private Action action;
private Func<bool> canExecute;
public CommandHandler(Action action, Func<bool> canExecute)
{
this.action = action;
this.canExecute = canExecute;
}
public event EventHandler CanExecuteChanged;
public bool CanExecute(object parameter)
{
return canExecute();
}
public void Execute(object parameter)
{
action();
}
}
Muszę to przełożyć na F#, żeby używać komend w MemoryVisualizerze. 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...