ul. Rzędzińska 3
22 489 89 01

Inside Bricsys: wywiad z twórcą BLADE – nowego środowiska programistycznego Visual LISP BricsCAD V18.2

BLADE to nowa niezrównana funkcjonalność BricsCAD V18.2. Jako środowisko LISP w BricsCAD BLADE jest jego nową odsłoną.

Bricsys nie tylko właśnie doścignął Autodesk, ale wprowadził również tak wiele funkcjonalności wykraczających poza możliwości narzędzia Autodesk VLIDE z 1999 roku, że jest teraz mało prawdopodobne, aby kiedykolwiek dał się złapać konkurencji. Stawka pozostaje jednak nadal wyrównana i dzięki temu – motywująca do dalszego  działania.

Miałem szansę poznać to IDE podczas konferencji Bricsys 2017 (od ang. integrated development environment) w stadium przygotowań do wydania, w którym jego nazwa nie była jeszcze znana. Byłem zaskoczony i zachwycony możliwościami zaprezentowanymi przez jego twórcę, Tortsena Mosesa. W ostatnim czasie miałem okazję porozmawiać z Tortsenem o efekcie jego prac.

Tortsen, rozumiem, że stworzenie środowiska LISP dla BricsCAD było bardzo skomplikowane przez wzgląd na sposób jego działania. Czy możesz to wytłumaczyć?

BricsCAD LISP wykorzystuje rozwiązanie OpenLisp stworzone przez francuskiego programistę Christiana Julliena. To jedyny silnik LISP, który jest obecnie rozwijany. Postęp w pozostałych został zatrzymany w połowie lat 90.

OpenLisp jest bardzo nowoczesną implementacją, nieporównywalną ze starym dialektem XLisp wykorzystywanym w AutoLISP. Wspierane jest w nim nawet podejście programowania obiektowego. W ten sposób wewnętrzna reprezentacja wyrażeń LISP jest inna niż tekstowa, którą można zobaczyć w pliku LISP.

Oznacza to, że napisany przez mnie kod AutoLISP nie jest tym, który wykonuje BricsCAD?

Zgadza się. Wiele typowych konstrukcji AutoLISP było zaimplementowanych przez taką emulację, która wprowadza jeszcze więcej różnic pomiędzy wewnętrzną a tekstową reprezentacją. To sprawia, że całe zagadnienie synchronizacji wykonywania wewnętrznych wyrażeń OpenLisp z odpowiadającym im tekstowym reprezentacjom staje się ogromnym wyzwaniem.

Oprócz czystych technicznych detali, które na pozór wydawały się nierozwiązywalne, oczekiwano ogromnego wysiłku potrzebnego do zaimplementowania rozwiniętego interfejsu graficznego. Miał powstać nie tylko prosty edytor, ale w pełni funkcjonalne GUI.

Byłoby wielką katastrofą, ogromną hańbą, gdybyśmy zaoferowali jedynie VLIDE, które spełniało standardy AutoCADa sprzed 20 lat. Owszem, wtedy było to wspaniałe rozwiązanie, ale od tego czasu minęło 20 lat.

Pomysł stworzenia środowiska LISP dla BricsCADa wydawał się pociągać za sobą tak wiele problemów, że decydowaliśmy się to odkładać na późniejszy czas.

W jaki sposób udało się Ci ostatecznie pokonać te problemy?

Po pierwsze, to był czysty przypadek. (śmiech) Szczęśliwie odkryłem ukryty szczegół w OpenLisp – każdy symbol w LISP (a wyrażenia są pewnym anonimowym symbolem) może zawierać nieograniczoną ilość niestandardowych danych, podobnie do obiektów XData i bazie formatu DWG. Choć wiedziałem o tym od dawna, to nigdy nie dostrzegłem możliwości „niewłaściwego” użycia tego w celu dwukierunkowego połączenia wyrażeń LISP pomiędzy edytorem a debugerem. Kilka wstępnych testów pokazało, że to podejście było bardzo obiecujące.

Innym zbiegiem okoliczności okazało się odkrycie, że WxWidgets (wykorzystywana przez nas wieloplatformowa bibliotek, nie tylko do tworzenia GUI) wspiera już znany edytor Scintilla i jego szeroko wykorzystywany OpenSource’owy silnik.

Jednak ciągle to jedynie wsparcie dla samego edytora – nie dla pełnego GUI. Wtedy znalazłem odpowiedni rozszerzalny edytor, implementację GUI oraz zbudowany na tej podstawie system WxWidgets Scintilla na licencji OpenSource przypisanej do WxWidgets. Z tego powodu możemy korzystać z kodu źródłowego w komercyjnym wykrozystaniu. Ten edytor to wxStEditor.

Zweryfikowałem, że to źródło jest odpowiednie dla naszego LISP IDE i włożyłem mnóstwo pracy w jego rozszerzenie. Rozwój edytora wxStEditor zakończył się około 2008 roku i w gruncie rzeczy kompilował się i działał prawidłowo. Jednakże w procesie rozwoju tego GUI zlokalizowałem i naprawiłem mnóstwo defektów na wszystkich powiązanych poziomach.

Podsumowując, wszystko okazało się zbiorem zbiegów okoliczności, które nagle otworzyły drzwi do wspaniałych rozwiązań.

Odnotowałem wcześniej, że wykonywanie poleceń AutoLISP oraz VisualLISP na BricsCAD jest kilka razy szybsze niż w przypadku AutoCADa. Jak nowa technologia zmienia tę kwestię?

Wszystkie związane z BLADE kwestie nie wpływają na normalną wykonywalność poleceń LISP poza IDE i debugerem. Połączenie jest tworzone przez kilka wywołań, które potrzebują niemal zerowego czasu w normalnym procesowaniu. Dzięki temu nie ma możliwości do zakłócenia normalnej pracy.

„Implementacja BLADE jest bardzo bezpieczna. Wydajność w dalszym ciągu pozostaje na wysokim poziomie w trakcie normalnego użytkowania.”

Dla debugera i synchronizacji wszystko to jest domowym, naturalnym środowiskiem zoptymalizowanym na najlepszą wydajność nawet podczas debugowania i minimalnego wykorzystania systemowej oraz LISPowej pamięci.

W trakcie implementacji debugera oraz wewnętrznej przeciw zewnętrznej synchronizacji usunąłem także większość emulacji i zaimplementowałem to jako podstawową funkcjonalność OpenLisp. Efektem ubocznym tych działań jest zaś to, że funkcje repeat, foreach oraz vlax-for działają pięć razy szybciej. Zatem zamiast zwalniać dotychczasowe narzędzia, stworzenie BLADE przyspieszyło ich pracę!

Czy wersje na systemy Mac oraz Linux będą także posiadały tę funkcjonalność?

Tak, to jest w pełni kompatybilne. To dzięki implementacji WxWidgets oraz moich efektów działań. Udało mi się pozytywnie zweryfikować pracę BLADE w środowisku Linux. Nie ma żadnych różnic – nawet implementacyjny kod nie posiada elementów specyficznych dla systemu Windows.

Czy możesz podać prosty przykład specyfiki pracy podczas pojedynczej sesji debugowania?

Po pierwsze, nie ładuj żadnego pliku LISP do BricsCADa. Taki kod załadowany na zewnątrz debugera jest w pełni funkcjonalny, ale nie może być użyty do debugowania. Specjalne połączenie pomiędzy wewnętrzną a zewnętrzną reprezentacją jest ustanawiane jedynie podczas ładowania kodu LISP w stanie debugowania.

Następnie, wykorzystując BLADE otwórz istniejący projekt FAS lub VLX i/lub „Nazwaną sesję” lub po prostu jakikolwiek plik LISP, który chcesz debugować.

„Możesz teraz wybrać Rozpocznij Debugowanie z menu lub paska narzędzi lub wcisnąć klawisz F8. Pojawi się pasek narzędzi debugera. Możesz wybrać opcję AutoBreak, która zatrzymuję pracę debugera na pierwszym wykonywalnym fragmencie kodu, lub aktywować źródło LISP, gdzie chcesz rozpocząć debugowanie i wstawić kilka punktów przerwań.

Załaduj plik LISP, wykorzystując w tym celu standardową funkcję Wczytaj w BricsCAD lub wciskając odpowiadający jej przycisk w pasku narzędzi debugera. W momencie, gdy załadowany kod jest możliwy do debugowania, powinieneś zobaczyć wskazany plik i dostępne funkcje debugera w obszarze dwóch paneli po prawej stronie.

Kiedy debuger zatrzyma się na pierwszym punkcie przerwania, uaktywnią się wszystkie funkcje debugera w stanie zatrzymania. To coś więcej niż w przypadku VLIDE’a AutoCADa. Możesz ustawić obserwację poszczególnych zmiennych wybierając „Data Break Point”. W momencie, gdy śledzona zmienna zmieni swoją wartość, debuger również zatrzyma swoje działanie w odpowiednim miejscu instrukcji LISP.

Co jeśli Twój kod będzie chciał wywołać instrukcje z innych plików, których nie załadowałeś?

Nie martw się o to. Debuger rozpoznaje takie przypadki i prosi użytkownika o załadowanie odpowiednich plików LISP. W normalnym LISP otrzymałbyś błąd niezdefiniowanej funkcji, ale debuger radzi sobie z tym działając z wyprzedzeniem. Właściwie to jedna z wielu zaawansowanych funkcji – załaduj jedynie podstawowy plik LISP, a jakiekolwiek odwołania podczas samego debugowania zostaną określone w trakcie samego procesu poprzez załadowanie kolejnych plików. To jest bardzo użyteczne w przypadku pracy ze skomplikowanymi aplikacjami – nie ma konieczności ładowania jakichkolwiek plików LISP.

„Jestem przekonany, że doświadczyłeś na własnej skórze Prawa Murphy’ego, kiedy funkcja, której potrzebujesz nie jest tą, którą wczytałeś. Taki problem nie wystąpi w BLADE.”

Co teraz? Czy praca nad BLADE jest zakończona czy może są miejsca, w których można by dokonać poprawek?

Jako że BLADE to nadal bardzo młody produkt, wiele związanych z nim kwestii czeka na nas w przyszłości. Jak dotąd, głównym celem było dostarczenie dobrych funkcjonalności debugera i nieco możliwości obsługi projektów, ale bez skupiania uwagi na czystych możliwościach samego edytora.

„Moja lista rzeczy do zrobienia ma nadal wiele ważnych funkcjonalności do zaimplementowania. Chcemy dodać możliwość definiowania własnych skrótów klawiszowych – wiemy, że nauka z góry narzuconych jest dla programisty prawdziwym koszmarem! Naszym celem jest również stworzenie weryfikacji referencji w ramach pracy z jednym plikiem i jedną sesją, przede wszystkim dla większych aplikacji LISP.

Następnie, z czasem możliwości edytora będą rozwijane i ulepszane, dostarczając coraz więcej funkcjonalności. Jednym przykładem jest zapewnienie wyświetlania sygnatury funkcji i krótkiej pomocy w momencie obecności kursora w obrębie jej nazwy.

Oczywiście zdaję sobie sprawę z tego, że w momencie, kiedy użytkownicy rozpoczną pracę z BLADE docierać będzie do nas mnóstwo informacji zwrotnych w postaci życzeń, wskazówek do rozwoju oraz raportów błędów. Jest bardzo prawdopodobne, że wiele próśb będzie sprowadzać się do zbliżenia funkcjonalności BLADE do rozwiązania VLIDE AutoCADa. To może być momentami delikatnie skomplikowane i nie chcemy traktować tego jako główny cel. Mam nadzieję, że deweloperzy, przez wzgląd na ogromne zalety naszego rozwiązania, będą otwarci na różniącą się w małym stopniu specyfikę pracy.

„Generalnie przychylnie patrzymy na pomysły, potrzeby oraz wymagania deweloperów, podobnie jak to ma miejsce w przypadku BricsCADa. Na samym końcu chodzi przecież o to, żeby to deweloper mógł pracować z BLADE możliwie prosto i produktywnie.”

Już pierwsze wydanie BLADE oparte jest na wartościowym informacjom uzyskanym od beta testerów takich jak Martin Drese (CAD Wiesel).

BricsCAD V18.2 jest już dostępny!

Kiedy widzisz, jak wiele poświęcenia wkładają w swoją pracę członkowie naszego zespołu programistycznego, musisz zgodzić się z tym, że to właśnie przyszłość opartego na formacie .dwg oprogramowania CAD. Jako użytkownik BricsCADa, wartość, jaką otrzymujesz z faktu posiadania licencji, rośnie z każdym rokiem. To sytuacja win-win dla wszystkich zaangażowanych stron. Jeśli nie używasz BricsCAD dziś, powinieneś zdecydować się na to.

Wypróbuj BricsCAD V18.2 za darmo przez 30 dni

Wersja oryginalna: https://blog.bricsys.com/inside-bricsys-blade/ (aut. Steve Johnson)

Related Posts

Zostaw komentarz