Temat: Czy używał ktoś DDE z R ?

Czy używał ktoś DDE (Dynamic Data Exchange) z R ? Chciałbym ustawić komunikację pomiędzy aplikacją dostarczającą dane w czasie rzeczywistym, a R by przy pomocy R'a zapisywać na bieżąco dane do pliku. (chociaż ponoć R jest słaby w zastosowaniach online)

Temat: Czy używał ktoś DDE z R ?

DDE to 16 bitowy relikt z czasów Win 9x. Nawet nie wiem, czy będzie obecny w przyszłych Windowsach. Jestem w szoku, że wspiera go Win7, chociaż jak czytałem, to są z nim problemy.

Możesz przecież korzystać z OLE COM, albo wprost z R.DLL
W tym pierwszym przypadku fakt, będzie nieco wolno (setki ms reakcji), w tym drugim szybko (pojedyncze, góra dziesiątki ms reakcji). Jakiej przepustowości oczekujesz?

Chyba, że Twoja aplikacja wspiera tylko DDE. Wtedy można napisać adapter:
Klient (DDE) <--> adapter <--> R. Najszybciej będzie napisać to w C# (.NET) albo MFC.

Rzuć okiem tutaj: http://www.goldenline.pl/forum/2478242/nowy-interfejs-...

Może znajdziesz coś także tu:
http://cran.r-project.org/web/packages/IBrokers/vignet...

Rzuć okiem także na pakiet tcltk2: http://cran.r-project.org/web/packages/tcltk2/

Temat: Czy używał ktoś DDE z R ?

Masz tutaj kompletny tutorial do R i DDE:
http://lojze.lugos.si/~darja/software/r/library/tcltk2...

Wykonałem kilka typowych poleceń dotyczących operacji na zmiennych w obie strony i działało.



Nie udało mi się zmusić IExplorera, Worda ani Excela do współpracy. Pewnie jakieś błędy w tutorialu - nie mam czasu sprawdzać. Jedynie poprawiłem sekwencje unikowe (\\)

Uważaj na wielkość liter w nazwach funkcji, czyli np. tclVarName a nie tclVarname (w tutorialu).Adrian Olszewski edytował(a) ten post dnia 25.11.11 o godzinie 17:39

Temat: Czy używał ktoś DDE z R ?

myślę o zgrywaniu notowań giełdowych kilkudziesięciu walorów z rozdzielczością sekundową, podawanych w czasie rzeczywistym przez program NOL comarchu (udostępnia go wiele domów maklerskich) lub Notowania3/Notowania3MAX (provider danych Statica.pl), nie umiem programować, więc pomyślałem, że użyję R'a do komunikacji z powyższymi aplikacjami i zapisywania na dysku na danych zebranych danych, w opisach obu programów jest wytłuszczony skrót DDE - więc poszedłem tym tropem, jest jeszcze jakieś API w NOLu (FIXAPI – interfejs programowania oparty na protokole FIX) trudno mi oszacować wielkość transferu stawiam na maksymalnie kilka kilobajtów, również słyszałem, że DDE jest leciwą technologią, dzięki zza skrót helpa do funkcji tk2dde, gdy googlowałem nie natknąłem się na nią :)Kamil Bęczyński edytował(a) ten post dnia 25.11.11 o godzinie 19:04

Temat: Czy używał ktoś DDE z R ?

Zatem ilość danych jest znikoma. Wszystko jedno, z czego skorzystasz.

Jeśli interesuje Cię DDE, to z tego tutoriala, co podałem, zainteresuj się nie tyle ustawianiem zawartości zmiennych, co wywoływaniem funkcji R z poziomu aplikacji DDE, gdzie jako parametr funkcji podasz konkretne wartości, przekazując je "on demand" do R:

# Now, the other way: execute a R function from wish

# You first need to register a R function for callback

# (I don't how yet to deal with arguments here, so, use functions without args!)

doDDE <- function() cat("DDE execute!\n")  # A simple function without arguments

tclFun(doDDE)

# And in wish

# % dde execute TclEval R doDDE

A co do programowania, jest taka "złota myśl":
Can one be a good data analyst without being a half-good programmer? The short answer to
that is, "No." The long answer to that is, "No."
—Frank Harrell
1999 S-PLUS User Conference, New Orleans (October 1999)

...więc warto zacząć, to się szybko zwróci :)

Temat: Czy używał ktoś DDE z R ?

Adrian Olszewski:
A co do programowania, jest taka "złota myśl":
Can one be a good data analyst without being a half-good programmer? The short answer to
that is, "No." The long answer to that is, "No."
—Frank Harrell
1999 S-PLUS User Conference, New Orleans (October 1999)

...więc warto zacząć, to się szybko zwróci :)

Znam to :D używam R dosyć długo i zdarza mi się napisać trochę bardziej skomplikowanego kodu - implementacja jakichś algorytmów, modeli statystycznych, z VBA też radziłem sobie dobre, ale nie mam potrzeby by go używać. Myślałem o nauce Pythona, który posiada sporą grupę użytkowników zainteresowanych używaniem go w statystyce, data mining i machine learning, istnieje więc dużo kodu, tutoriali forów, temu poświęconych. Tylko czy język skryptowy i język klasy 4GL to dobre połączenie ? Oba nadają się raczej do prototypowania algorytmów, niż ich docelowej implementacji, chociaż przy dzisiejsze szybkości procesorów ma to znaczenie, chyba tylko przy pracy z dużymi zbiorami danych, więc sam nie wiem co zrobić, bo nauka c++ mogłaby okazać się zbyt czasochłonna - szczególnie brakuje mi narzędzi do szybkiej oceny/podsumowania wyników działania algorytmów, wszystko trzeba samemu napisać, lub znaleźć odpowiednią bibliotekę - R mnie pod tym względem rozleniwił :DKamil Bęczyński edytował(a) ten post dnia 26.11.11 o godzinie 11:58

Temat: Czy używał ktoś DDE z R ?

Kamil Bęczyński:
Znam to :D używam R dosyć długo i zdarza mi się napisać trochę bardziej skomplikowanego kodu - implementacja jakichś algorytmów, modeli statystycznych, z VBA też radziłem sobie dobre, ale nie mam potrzeby by go używać.

Więc jesteś programistą :) Programista to ten, kto potrafi skutecznie wykorzystać dostępne narzędzia programistyczne do rozwiązania problemów.

R to środowisko obliczeniowe, a nie środowisko tworzenia aplikacji. Owszem, z biegiem czasu wyposażono je w biblioteki do wyświetlania okien, różne interfejsy wymiany danych i komunikacji, ma komplet funkcji wejścia/wyjścia, a nawet obsługę wyrażeń regularnych i tak dalej. Można w nim zrobić zaj*ście wiele, ale to nadal tylko "pakiet statystyczny", przeznaczony zupełnie do innych celów, gdzie te jego dodatkowe funkcje, to tylko taki "helper", który czasem się przyda, by bez dodatkowych narzędzi osiągnąć doraźnie efekt zbliżony do pożądanego. R jest świetny jako serwer obliczeń, ale generowanie w nim stron HTML z wynikami, czy wyświetlanie złożonych formatek, zarządzanei oknami wykresów, praca asynchroniczna to koszmar w relacji do choćby Javy, .NET, Delphi czy VB. Praca z nim powinna sprowadzać się do podania mu źródła danych (czy to przesłanie ich w tablicy, czy załadowanie ich przez RODBC, read.table i tak dalej), wykonania obliczeń i odebrania jakiejś struktury z wynikami (np. XML).

Z drugiej strony, nie ma najmniejszego sensu samemu bawić się w pisanie pakietu statystycznego i samodzielną implementację np. GLM, jeśli mamy gotowe i darmowe cudo w postaci "R".

Najlepiej, niech każde narzędzie robi to, co umie najlepiej :)

poświęconych. Tylko czy język skryptowy i język klasy 4GL to dobre połączenie ?

Jeśli realizują to, co chcesz uzyskać, to nawet assembler i Macromedia Authorware da radę. Pytanie, ile się przy tym namęczysz. Akurat język 4 generacji jest świetny do szybkiego prototypowania. Z kolei język skryptowy wymaga instalacji runtime'u, ale... który obecnie nie wymaga? Java, .NET, Python, Ruby... Tylko regularne aplikacje Win32/64 tego nie potrzebują (chociaż nieraz potrzebują dziesiątek MB bibliotek, jak MFC).

Oba nadają się raczej do prototypowania algorytmów, niż ich docelowej implementacji,

To zależy, co chcesz zrobić. Jeśli możesz oprzeć się o gotowe algorytmy matematyczne, to nie próbuj pisać "optymalniejszych", niż te napisane przez specjalistów (w C). Strata czasu i wyważanie otwartych drzwi. Spędzono wiele osobogodzin nad ich optymalizacją. Wtedy język 4G, który udostępnia Ci te algorytmy jest niezastąpiony, a Ty nie tracisz nic z wydajności.

Jeśli sam implementujesz coś zupełnie "from scratch", to faktycznie, nauka języka niskopoziomowego będzie właściwa. Jeśli robisz to często, na pewno nie pożałujesz nauki języka niskopoziomowego. Ale coś za coś :) Np. arytmetyka wskaźników i samodzielne zarządzanie pamięcią i innymi zasobami (np. podczas rysowania czegoś na ekranie). W R nie musiałeś o tym myśleć.

Ale nowoczesne języki, jak np. C# (.NET) pozwalają zejść do arytmetyki wskaźników (tryb "unsafe") i łączyć się z natywnymi bibliotekami DLL, a prostota, z jaką wykorzystuje się w nim mechanizmy komunikacyjne, pisze serwisy www, bogate interfejsy użytkownika (np. WPF - część .NETa) jest nie do pogardzenia.Adrian Olszewski edytował(a) ten post dnia 26.11.11 o godzinie 22:58

Temat: Czy używał ktoś DDE z R ?

Adrian Olszewski:
Zatem ilość danych jest znikoma. Wszystko jedno, z czego skorzystasz.

  tk2dde.services()

 [1] "Excel {[dde.xlsx]Arkusz1}" "Excel {[dde.xlsx]Arkusz2}" "Excel {[dde.xlsx]Arkusz3}"

 [4] "Excel System"              "TclEval wish"              "TclEval R"                

 [7] "PROGMAN PROGMAN"           "Shell AppProperties"       "Folders AppProperties"    

[10] "PROGMAN PROGMAN"          



tk2dde.poke("Excel", "Sheet1", "R1C1", "{5.7}") 

Error in structure(.External("dotTcl", ..., PACKAGE = "tcltk"), class = "tclObj") : 

  [tcl] dde command failed.



[1] "Error in structure(.External(\"dotTcl\", ..., PACKAGE = \"tcltk\"), class = \"tclObj\") : \n  [tcl] dde command failed.\n\n"

attr(,"class")

[1] "try-error"

attr(,"condition")

<simpleError in structure(.External("dotTcl", ..., PACKAGE = "tcltk"), class = "tclObj"): [tcl] dde command failed.

Nie działa, używam Excela 2007. Jednak jakaś komunikacja została ustawiona. Gdyż po zapisaniu arkusza excelowego jako dde.xlsx komenda tk2dde.services() pokazuje nazwy 'Zeszyt1' nazwę 'dde.xlsx'. Zapisując plik dde.xlsx w opcjach Excela zaznaczyłem 'Recencja-> Udostępnij Skoroszyt -> Edycja -> Pozwól na zmiany wprowadzane jednocześnie przez wielu użytkowników...', ale to również nie pomogło.

Zastanawiam się czy problem nie leży po stronie ustawień w Excelu.

Tak na marginesie : "Regardless of advice to the contrary there are many applications that make their data available to Excel via DDE. Most of the market data providers (Reuters, Bloomberg, Platts etc) provide DDE access to their data."

Gdy w Excelu wybrałem 'Ignoruj inne aplikacje używające DDE', a potem użyłem tk2dde.services() Excel zniknął z listy, wydaje mi się że składnia polecenia :
tk2dde.poke("Excel", "Sheet1", "R1C1", "{5.7}")
jest błędna, naiwnie zamieniałem 'Sheet1' na 'Zeszyt1' ale to nie to.
Sądzę, że składnia polecenia jest błędna, gdyż po zamianie 'Excel' i 'Sheet1' na bezsensowne ciągi znaków, R komunikuje błąd wykonania komendy w ten sam sposób.

chyba dobry post (nie rozumiem wszystkiego do końca) :

http://r.789695.n4.nabble.com/R-and-DDE-Dynamic-Data-E...

Jak powinien wyglądać przykładowy link DDE w arkuszu Excela mający dostęp do zmiennej 'x' z R ?Kamil B edytował(a) ten post dnia 05.02.12 o godzinie 14:13

Temat: Czy używał ktoś DDE z R ?

Wszystko jest OK, bo to podstawowa składnia DDE. Nic nie zmieniaj w ustawieniach, a co zmieniłeś, przywróć do defaultów.

1. jeśli skoroszyt został zapisany do pliku, to podajemy nazwę tego pliku wraz z rozszerzeniem. Jeśli nie, to podajemy nazwę zeszytu. Posługujemy się nazwami narodowymi, czyli dla polskiej wersji Excela jest to "arkusz", dla angielskiego - "sheet".

Ściślej ujmując - podajemy jedną z pozycji, które zobaczymy po wykonaniu komendy tk2dde.services(). Ona wyświetla dokładnie to, co powinniśmy podać, żeby działało - nazwy zarejestrowanych "nasłuchów" DDE.

3. Podobnie adres komórek podajemy w postaci narodowej, czyli dla polskiej wersji Excela mamy "WiKj" (Wiersz Kolumna), dla angielskiej - "RiCj" (Row Column).

3. wielkość liter nie jest ważna

Przykłady:

tk2dde.poke("excel", "{[dde.xlsx]Arkusz1}", "W1K1", 2)

tk2dde.poke("excel", "{[Zeszyt3]Arkusz1}", "W1K1", "Ala ma kota")

tk2dde.poke("excel", "{[dde.xlsx]Arkusz1}", "W1K1", "=sin(pi()/3)^2 + cos(pi()/3))

Adrian Olszewski edytował(a) ten post dnia 05.02.12 o godzinie 14:34

Temat: Czy używał ktoś DDE z R ?

Super, dziękuję za odpowiedź :)

na WK zamiast RC bym nie wpadł, wpadłem za to na potrzebę zastosowania nawiasów w : '{[dde.xlsx]Arkusz1}'.

a w jaki sposób zbudować łącze DDE w Excelu mające dostęp do zmiennej z R ? Powinno to wyglądać mniej więcej tak : '=nazwa_programu|dalsza_czesc_adresu!zmienna'.Kamil B edytował(a) ten post dnia 05.02.12 o godzinie 14:40

Temat: Czy używał ktoś DDE z R ?

1. Wystaw (zdefiniuj) zmienną w R:

tclVarName("zm", "Ala ma kota")

Nie zapomnij jej potem uaktualniać przez:

tclSetValue("zm", "Jola ma psa")

2. Odbierz ją w Excelu:

=TclEval|R!zm

Adrian Olszewski edytował(a) ten post dnia 05.02.12 o godzinie 15:22

Temat: Czy używał ktoś DDE z R ?

Adrian Olszewski:
1. Wystaw (zdefiniuj) zmienną w R:

tclVarName("zm", "Ala ma kota")

Nie zapomnij jej potem uaktualniać przez:

tclSetValue("zm", "Jola ma psa")

2. Odbierz ją w Excelu:

=TclEval|R!zm

nie działa, Excel próbuje uruchomić aplikację 'TclEval.exe', może polecenie odbierające w Excelu trzeba zmienić, bo mam ustawioną nazwę :

tk2dde()

[1] "SciViewsR"

EDYCJA : restartowałem R, teraz wszystko działa,

tk2dde()

[1] "R"

nazwa zmieniła się na domyślną, czyli "R" tak jak w adresie '=TclEval|R!zm'
chodziło więc o nazwę serwera.Kamil B edytował(a) ten post dnia 05.02.12 o godzinie 15:40

Temat: Czy używał ktoś DDE z R ?

Ustawiłeś w R przez tk2dde("slot") to, z czego korzystasz w Excelu?

tk2dde("abc") --> TclEval|abc!zm

Temat: Czy używał ktoś DDE z R ?

Adrian Olszewski:
Ustawiłeś w R przez tk2dde("slot") to, z czego korzystasz w Excelu?

tk2dde("abc") --> TclEval|abc!zm

właśnie się wszystko wyjaśniło, edytowałem post, dziękuję za cierpliwość )Kamil B edytował(a) ten post dnia 05.02.12 o godzinie 15:39

Temat: Czy używał ktoś DDE z R ?

Adrian Olszewski:
1. Wystaw (zdefiniuj) zmienną w R:

tclVarName("zm", "Ala ma kota")

Nie zapomnij jej potem uaktualniać przez:

tclSetValue("zm", "Jola ma psa")

2. Odbierz ją w Excelu:

=TclEval|R!zm

Jasno, zwięźle i na temat, dziękuję :)Kamil B edytował(a) ten post dnia 08.02.12 o godzinie 20:49

Temat: Czy używał ktoś DDE z R ?

Adrian Olszewski:
Ustawiłeś w R przez tk2dde("slot") to, z czego korzystasz w Excelu?

tk2dde("abc") --> TclEval|abc!zm

Mam kolejny problem - przy pomocy DDE - funkcji tk2dde.request() ściągam dane z innego programu, kod wygląda z grubsza tak :

zmienna=0
wynik=numeric(100000)
while(zmienna<1){

wynik[i]=tk2dde.request(ustawienia)
i=i+1
Sys.sleep(0.5)
cat(wynik[i])
}

kod działa, tylko, ze po około pół godziny wszystko się wykrzacz :

"
Error in structure(.External("dotTcl", ..., PACKAGE = "tcltk"), class = "tclObj") :
[tcl] dde command failed.
"

wyskakuje po każdej iteracji, 'Menedżer zadań Windows' mówi, że R ciągle działa, a system ma nadal dużo pamięci, procesor nie jest obciążony

- po zatrzymaniu pętli widzę, że nastąpiło totalne zerwanie połączenie pomiędzy R a jakimkolwiek programem z uruchomionym DDE :

>tk2dde.services()
>character(0)

restartowanie tamtego programu nie przywraca połączenia, R nie widzi również Excela (w Excelu włączyłem DDE na 100%)

co ciekawe wysiada również możliwość otworzenia pliku z pomocą, komenda : ?lm
nie powoduje żadnej akcji gdy help_type="text, gdy "=html" wtedy działa i wywołuje przeglądarkę

konsola również wysiada - menu się nie rozwijaja, a w całym windowsie XP wysiada kliknięcie prawym przyciskiem myszy, dodam, że antywirusa wyłączyłem i wszystkie inne programy również, nie pokazuje się żadne inny błąd oprócz tego który jest w konsoli

Co ciekawe patrząc na wynik widzę, że DDE czasami ponownie działało :
"
[4006] "Error in structure(.External(\"dotTcl\", ..., PACKAGE = \"tcltk\"), class = \"tclObj\") : \n [tcl] dde command failed.\n\n"
[4007] "Error in structure(.External(\"dotTcl\", ..., PACKAGE = \"tcltk\"), class = \"tclObj\") : \n [tcl] dde command failed.\n\n"
[4008] "Error in structure(.External(\"dotTcl\", ..., PACKAGE = \"tcltk\"), class = \"tclObj\") : \n [tcl] dde command failed.\n\n"
[4009] "2353.00"
[4010] "2353.00"
[4011] "2353.00"
[4012] "2353.00"
[4013] "2353.00"
[4014] "Error in structure(.External(\"dotTcl\", ..., PACKAGE = \"tcltk\"), class = \"tclObj\") : \n [tcl] dde command failed.\n\n"
[4015] "Error in structure(.External(\"dotTcl\", ..., PACKAGE = \"tcltk\"), class = \"tclObj\") : \n [tcl] dde command failed.\n\n"
[4016] "Error in structure(.External(\"dotTcl\", ..., PACKAGE = \"tcltk\"), class = \"tclObj\") : \n [tcl] dde command failed.\n\n"
"

2. Jest jeszcze drugi problem, R nie widzi pewnej aplikacji poprzez DDE, a Excel ją widzi, zastanawiam się, co może być nie tak. Na razie przyszło mi tylko do głowy użycie starszych wersji R i pakiety tcltk2.Kamil B edytował(a) ten post dnia 10.02.12 o godzinie 13:37

Temat: Czy używał ktoś DDE z R ?

Skoro masz takie reakcje z samym OSem, to coś jest skopane w samej bibliotece TCL. Może gdzieś coś "nadpisuje" w pamięci (choć powinien wylecieć wyjątek naruszenia ochrony pamięci). Może też być, że "gdzieś-coś" nie jest zwalniane (pamięć) i masz wyciek zasobów (ale wtedy powinien wylecieć jakiś out-of-memory/resources albo coś podobnego). Niestety, trzeba pamiętać, że Windows NADAL wykorzystuje DDE do różnych operacji shella, m.in. "kopiuj/wklej", otwierania dokumentów, więc jak coś się spierniczy w samym mechanizmie, to może to wpłynąć na cały system operacyjny.

DDE pamięta czasy Windows 2.0 (tak, tak), było kilka razy przebudowywane, ale problemy z nim miałem jeszcze w 2003 roku, kiedy wykorzystywałem je w moim licencjacie. Zarzuciłem na rzecz TCP/IP, a potem OLE COM.

Naprawdę nie masz innej możliwości skomunikowania się z Twoją aplikacją? Gniazda, COM, baza danych, może choć pliki wymiany?

Wstaw większe opóźnienia między wywołaniami DDE. Na DDE opiera się kawałek systemu operacyjnego, a Ty ostro eksploatujesz DDE. Może jakieś operacje się na siebie nakładają (w ciągu takiego kawałka czasu nietrudno o to) i coś się sypie.

Swoją drogą R nie jest stworzony do pracy "w pętli", do tego powinno napisać się jakiś serwis albo aplikację wielowątkową. Z poziomu takiej aplikacji odpytujesz aplikacje po DDE i komunikujesz się z R (czy to przez R.DLL, czy poprzez COM).Adrian Olszewski edytował(a) ten post dnia 10.02.12 o godzinie 14:15

Temat: Czy używał ktoś DDE z R ?

Adrian Olszewski:
Skoro masz takie reakcje z samym OSem, to coś jest skopane w samej bibliotece TCL. Może gdzieś coś "nadpisuje" w pamięci (choć powinien wylecieć wyjątek naruszenia ochrony pamięci). Może też być, że "gdzieś-coś" nie jest zwalniane (pamięć) i masz wyciek zasobów (ale wtedy powinien wylecieć jakiś out-of-memory/resources albo coś podobnego). Niestety, trzeba pamiętać, że Windows NADAL wykorzystuje DDE do różnych operacji shella, m.in. "kopiuj/wklej", otwierania dokumentów, więc jak coś się spierniczy w samym mechanizmie, to może to wpłynąć na cały system operacyjny.

DDE pamięta czasy Windows 2.0 (tak, tak), było kilka razy przebudowywane, ale problemy z nim miałem jeszcze w 2003 roku, kiedy wykorzystywałem je w moim licencjacie. Zarzuciłem na rzecz TCP/IP, a potem OLE COM.

Naprawdę nie masz innej możliwości skomunikowania się z Twoją aplikacją? Gniazda, COM, baza danych, może choć pliki wymiany?

Wstaw większe opóźnienia między wywołaniami DDE. Na DDE opiera się kawałek systemu operacyjnego, a Ty ostro eksploatujesz DDE. Może jakieś operacje się na siebie nakładają (w ciągu takiego kawałka czasu nietrudno o to) i coś się sypie.

Swoją drogą R nie jest stworzony do pracy "w pętli", do tego powinno napisać się jakiś serwis albo aplikację wielowątkową. Z poziomu takiej aplikacji odpytujesz aplikacje po DDE i komunikujesz się z R (czy to przez R.DLL, czy poprzez COM).

Bardzo ciekawe histroria o Windowsie i DDE, wszystko by się zgadzało, gdyż nie mogłem odpalać aplikacji - nawet notatnika, gdy te błędy wyskoczyły, więc pewnie komunikacja przez DDE na poziomie samego XP padła.

Również słyszałem, że R nie nadaje się do zastosowań w czasie rzeczywistym, ciekawe jak będzie wyglądać sytuacja w przyszłości, trend w kierunku wielordzeniowości w dziedzinie procesorów jest trwały, jeśli standardem staną się maszyny o dużej ilości rdzeni (powiedzmy, że ponad 20), to aż głupio będzie odpalać dwa razy R, tak żeby pierwszy mielił dane - przez kilka godzin, podczas gdy my w drugim będziemy testować kod/eksplorować dane.

Zobaczymy co się stanie na razie zastanawia mnie ograniczenie dostępnej ilości RAMu oraz niechęć do wprowadzenia korzystania z pamięci wirtualnej, przecież dopuszczalne użycie tej ostatniej można ustawić domyślnie na zero, tak by dla przeciętnego użytkownika R nadal kojarzył się z szybkością działania.

Chyba poszukam jakiegoś wprowadzenia o COM-ach, DDE, a przede wszystkim komunikacji z DLL dla laików.

ps.z DDE szybko nie zrezygnują - jest ostro wykorzystywane w sektorze finansowym Reuters np. Bloomberg oferują ten protokół Ten post został edytowany przez Autora dnia 24.01.15 o godzinie 00:16

Temat: Czy używał ktoś DDE z R ?

Problem bierze się stąd, że Twoje podejście do kwestii wykorzystania R jako online'owego serwera obliczeń jest trochę uproszczone.

Na pierwszy rzut oka wszystko wydaje się być OK - pętla, odpytywanie aplikacji, obliczenia. Sam jednak widzisz, że to się nie sprawdza zbyt dobrze, a na dłuższą metę, gdy zapragniesz rozbudować Twoje rozwiązanie (a na pewno przyjdzie taki czas) o jakieś operacje na bazie danych, na komunikacji z innymi programami - utkniesz. A to wszystko dlatego, ze R "jako taki", taki, jak go widzisz po uruchomieniu, a więc konsola - nie został stworzony do takich celów, a w szczególności - pełnienia roli aplikacji odpytującej w pętli o dane. Nie zaimplementowano w nim łatwej możliwości tworzenia osobnych wątków - to trzeba robić w języku niższego poziomu (np. C) pisząc własną, wielowątkową bibliotekę.

Po kilku latach doświadczeń z pisaniem systemów obliczeniowych opartych o R mogę jednak zapewnić, że R można wykorzystać z powodzeniem w sytuacjach, gdy dane przychodzą "często i gęsto", np.:

- przetwarzanie danych z rozmaitych czujników i urządzeń pomiarowych
- złożona walidacja formularzy (np. eCRF), gdzie 500 użytkowników na raz wypełnia swoje formularze i trzeba błyskawicznie sprawdzać, czy wartość w danym polu jest poprawna, zależnie od wyników jakiegoś modelu

... ale trzeba do tego odpowiednio podejść, a przede wszystkim - nie dopuszczać, by R robił cokolwiek, poza obliczeniami, a więc:
- nie komunikował się z czujnikami (w ogóle O NIC nie odpytywał nikogo)
- komunikacja z nim przebiegała z jednej aplikacji, a nie z 10
- nie "chodził" w żadnej pętli oczekując na coś
- wprowadzić "politykę"
* zapytań do R,
* zarządzania sesjami obliczeniowymi oraz
* zarządzania przetwarzanymi danymi

1. wszystkimi obliczeniami zajmuje się biblioteka R.DLL, w której znajduje się interpreter języka i funkcje pomocnicze do zarządzania pamięcią, wejściem/wyjściem, wczytywaniem bibliotek eRowych, komunikacją z systemem operacyjnym. R.DLL, jak każda biblioteka, to jedynie zbiór funkcji odpowiedzialnych za różne operacje.

2. to, co uruchamiasz klikając ikonę R (RGui.exe) albo wpisując R w konsoli linuksowej, czy też wywołując Rscript.exe, to jedynie różne interfejsy użytkownika, które umożliwiają wprowadzenie danych do R i odebranie wyników. Są to programy klienckie, które stanowią środowisko uruchomieniowe dla R.DLL, wywołują odpowiednie funkcje biblioteki, przekazują do nich dane z wiersza poleceń i odbierają wyniki w celu przesłania ich wyświetlenia na ekranie. Np. RGui.exe zajmuje się instalacją pakietów/bibliotek, tworzeniem wątku obliczeń i jego przerywaniem (dzięki temu masz przycisk do przerwania bieżących obliczeń), oferuje uproszczony interfejs graficzny.

3. RGui.exe tworzy jeden wątek obliczeniowy, w którym wszystko się "kręci". Dzięki temu w trakcie wykonywania obliczeń mogą być wyświetlane wyniki (gdyby RGui.exe nie tworzyło nowego wątku dla obliczeń, okno nie mogłoby być w prosty sposób odświeżane). W tym wątku dzieje się wszystko, co zleciłeś eRowi, a więc wczytywanie danych, obliczenia, komunikacja z innymi programami, etc. I niestety, wszystko w nim się dzieje synchronicznie. Jeśli jakieś wywołanie zablokuje na dłużej wątek, to wszystko w tym wątku inne czeka na swoją kolej. (DDE nie wymaga osobnego wątku, wystarczy, że zarejestrujesz odbiór komunikatów DDE w głównej pętli komunikatów aplikacji, albo utworzysz własne, niewidoczne okno i własną kolejkę komunikatów (nie wiem jak to robi TCL)). Jeśli DDE lub jakaś biblioteka tworzy własne wątki, zwłaszcza takie, w których wykorzystywane są jakieś mechanizmy komunikacyjne, sprawy zaczynają się komplikować. Wątki mogą być w dowolnym momencie przerywane przez system operacyjny. Wątki współpracują ze sobą wymieniając dane, uruchamiając i zatrzymując się wzajemnie, oczekując na swoje wyniki. Funkcje wykorzystywane w wątkach muszą być "bezpieczne ze względu na wielowątkowość". Trzeba odpowiednio zabezpieczać przekazywanie danych między wątkami, gdyż np. przekazujesz 2 lub więcej bajtową liczbę, a tu wątek został przerwany po przesłaniu 1 bajta. Wątek, do którego przekazujesz dane widzi tylko "połowę zapisu" liczby lub jeszcze mniejszy jego fragment i masz problem z błędnymi danymi. Wątki się synchronizuje ze sobą, w wątkach mogą być rzucane wyjątki i tak dalej. Programowanie wielowątkowe to nietrywialne zagadnienie nawet dla doświadczonych programistów. Im więcej w głównym wątku roboczym użyjesz bibliotek, mechanizmów komunikacji (tworzących często własne wątki), tym większe szanse, że coś się pogryzie, bo nigdy nie wiesz, na ile poprawnie i bezpiecznie autor zaprogramował swój moduł pod tym kątem. W głównym wątku roboczym jest domyślnie pętla, w której konsola czeka na dane od Ciebie, uruchamia obliczenia i wypisuje wyniki. Być może RGui lub załadowane biblioteki wykonują jakieś dodatkowe akcje (np. odśmiecanie). W tej pętli (która może być przerywana przez system operacyjny) Ty deklarujesz swoją pętlę, w której nieustannie coś robisz, m.in. włączasz się z pętlą komunikatów DDE. No i jak widać coś się solidnie pogryzło. Skoro co jakiś czas zrywane jest połączenie i kładzie się na łopatki całe DDE, tzn. że albo nastąpiły jakieś deadlocki (wzajemnie blokujące wywołania), albo gdzieś pojawił się problem niewłaściwego przekazywania danych między wątkami i gdzieś poleciał wyjątek, który po prostu zabił całe DDE lub któreś z serwerów. Oczywiście to nie wina R, tylko albo samej biblioteki TCL, albo zestawienia wszystkiego w takiej konfiguracji.

Poza tym mając taką pętlę marnotrawisz moc obliczeniową R w sytuacji, gdyby miał robić kilka rzeczy na raz. Niestety, nie utworzysz w nim osobnego wątku, by sobie tam przerzucić pętlę.

4. Jak wspomniałem, w R można pracować wielowątkowo, jeśli tak została napisana określona biblioteka. Ale to wtedy nie "R pracuje wielowątkowo", tylko wczytana do R biblioteka tworzy i zarządza swoimi wątkami. Przykładem jest tutaj biblioteka RDCOM czy do obsługi gniazd TCP/IP. I właśnie pamiętam, że ze StatConnectorem były kiedyś problemy (zwłaszcza z poziomu RExcel), bo potrafił solidnie uwalić samego Excela, sypało wtedy po ekranie komunikatami błędu jak śniegiem w zamieć. Obecnie jest o wiele lepiej.

5. Najbezpieczniej jest pozostawić R same obliczenia. A to oznacza, że piszemy dedykowaną aplikację analityczną, która, pod naszą kontrolą, będzie:
- łączyć się zewnętrznymi aplikacjami po DDE, DCOM, TCP-UDP/IP, przez pliki wymiany, bazę danych, WM_COPYDATA, potoki nazwane czy jeszcze innymi kanałami komunikacji
- gromadzić dane w czasie rzeczywistym
- komunikować się z R i przesyłać mu polecenia i paczki danych (tu się kłania polityka przekazywania danych, zwłaszcza w systemach szybkiego przetwarzania, online)
- wystawiać wyniki różnymi interfejsami, np. po webserwisie, przez bluetooth, przez WWW i tak dalej.

6. R zostaje odciążony od tych wszystkich operacji, nie tworzysz w nim żadnych swoich pętli, a jedyne, co wykorzystujesz, to jedną bibliotekę wielowątkową do komunikacji.

Pamiętaj podstawową zasadę - to nie R ma odpytywać kogoś o dane, co musiałby robić w pętli ( Ty robisz to synchronicznie w głównym wątku), tylko to "ktoś ma szturchnąć R", że są gotowe dany a więc asynchronicznie (i do tego potrzebny jest osobny wątek lub funkcja zwrotna, tzw. callback). I jestem pewien, że DDE posiada taką możliwość, jak asynchroniczne wywołania albo callback. Tyle, że wtedy, niestety, to Twój broker danych musi umieć pracować w trybie powiadamiania o nowościach, a nie biernie oczekiwać na zapytania.

7. (D)COM ma tę zaletę, że możesz z R "rozmawiać" z dowolnej aplikacji, która umożliwia użycie tego mechanizmu, m.in. Word, Excel (RExcel), a nawet... SQL Server (przykład we wskazanym wyżej wątku o przetwarzaniu danych). Trzeba tylko określić politykę zarządzania sesjami - czy będzie to jedna wielka sesja, gdzie każdy user będzie miał swoje obszary danych (np. prefiksowane - userid_nazwa_ramki_danych), czy osobne sesje. Oba podejścia mają wady i zalety. Przykład wywołań z poziomu SQL Servera masz np. w wątku o zarządzaniu złożonymi danymi. Wygodne są także gniazda i webserwisy. Wszystkie te mechanizmy zwalniają R z odpytywania o dane, są asynchroniczne "by nature".

8. Bezpieczniejszym rozwiązaniem jest... samodzielne korzystanie z R.DLL z poziomu własnej aplikacji. Wtedy to my sami tworzymy środowisko dla biblioteki. Przykładem jest tutaj opisywana przeze mnie osobnym wątku biblioteka R.NET, która pozwala odwoływać się do R z poziomu aplikacji napisanej na platformę .NET. Nie wykorzystuje ona dodatkowych mechanizmów transportowych jak gniazda, COM czy DDE. Stanowi "opakowanie" dla R.DLL (mechanizm PInvoke platformy .NET) Jest z tego powodu bardzo szybka i do minimum zostaje zminimalizowany narzut wynikający ze stosowania pośrednich warstw komunikacji.

9. W pewnych zastosowaniach przydatne jest wykorzystanie Rscript.exe (tylko synchronicznie, wywołanie zabiera więcej czasu, zależnie od wpisów i ładowanych bibliotek w rprofile.site), albo R.DLL i np. "source". Przykład pokazywałem w wątku o R.NET, demonstrując aplikację przechwytującą wyjście konsoli R.

To ledwie kilka ogólnych uwag. Całe know-how dotyczące wykorzystania R to niestety wiele godzin i stron tekstu :)Adrian Olszewski edytował(a) ten post dnia 11.02.12 o godzinie 16:52