Użytkownik "Jarosław Sokołowski" napisał w wiadomości grup
dyskusyjnych:s...@f...lasek.waw.p
l...
Pan J.F. napisał:
>>> Tak, to jest główny powód -- prostota. Ale fakty przeczą temu,
>>> co było wcześniej powiedziane. Komputerowi łatwiej jest czytać
>>> "ludzki", tekstowy format, niż binarny przeznaczony dla maszyn.
>
>> Bo to jakies lesne dziadki programowaly :-)
>To tam jeszcze od Linusa Torvaldsa chyba jest. On miał wtedy ze
>dwadzieścia parę lat.

>> Od zawsze kompilator sluzyl do komunikacji z czlowiekiem, to
>> przyjmowal format tekstowy (programu).
>> A ze lesne dziadki wstretu dostawaly na slowo "grafika", a co
>> dopiero "multimedia", to nie przewidzialy zadnej mozliwosci
>> zaczytania danych binarnych z pliku :-)
>No ale ten plik PBM czytany jest właśnie przez kompilator,
>a grafika wstawiana w binarny kernel.

Ale to jest obejscie.
Brak operacji typu "a pod zmienna char xxxx[] wstaw zawartosc pliku
XX.BIN"

>Zresztą istnieje też
>format "c" zapisywany przez porogramy graficzne. Gotowy kod
>źródłowy w języku C (to znaczy deklaracja zmiennej to jest).

Obejscie do kwadratu :-)

Chociaz ... jak ktos dopiero system tworzy, to lepiej, ze ma taki plik
PBM i moze wpisac zawartosc z palca, a nie musi jakis program
graficzny odpalic, aby plik zapisac.

>>>> Excel ma tez jezyk programowania i prawdopodobnie dalo sie to
>>>> zrobic w tym VB ... tylko trzeba wiedziec jak, albo doczytac :-)
>>> Ja nie chcę wiedzieć jak. Zbyt wiele by to (moich) dupogodzin
>>> kosztowało.
>
>> Rozpoznanie tych plikow xml tez nie bylo 5 minutowe.

>15 sekundowe raczej. Główna robota to rozpakowanie zipa i spakowanie
>go nazad.

O Twoim czasie pisze. Trzeba rozpakowac, przejrzec, zauwazyc co i jak.
Potem stosowne programy/skrypty napisac.

J.

do góry

W dniu 2017-07-13 o 18:55, s...@g...com pisze:
> I z drugiej strony:
> xml niby fajny jest, czytelny i intuicyjny ale ma między innymi te wade ze jak jest
duzy i "fikuśny" to może byc trudno go wczytywać sekwencyjnie.
> Pamietam jak znajomy jakies 200MB xml-e próbował załadować aby po nich nastepnie
"pojeżdzić" programem. Na komputerze z 2GB ram biblioteka sie przewracała bo nawet
swapa zabrakło (system chyba 32bitowy byl).
>
> W praktyce przy zrobieniu paru założeń takiego xml-a sie daje wczytać bez problemu
ale jednak program sie robi nieco bardziej skomplikowany niż obsługa rekordu w
pascalu :)
>
Jakby ktoś chciał pisać własne programy do obsługi dużych XMLi, a nie
chce wymyślać wszystkiego sam, to niech poszuka biblioteki SAX (takie
coś jest w Javie, ale też w innych językach). Zamiast odtwarzać cały
dokument w pamięci (metoda DOM) czyta plik XML po linijce i generuje
odpowiednie zdarzenia, które potem trzeba samodzielnie przerobić na
odpowiednie dane/obiekty/operacje.
Dla większości programistów to pewnie oczywistość, ale może komuś się
przyda.
--
Pozdrawiam
Piotrek

do góry

Pan Piotr Gałka napisał:

>> Nie znam PSpice, ale z tego co widzę, tego nie "wywołuje się w jednej
>> krótkiej linijce poleceń". Czyli jednak inny obszar zastosowań.
>
> Nie za bardzo rozumiem po co potrzeba wywoływania w jednej linijce
> czegoś, czego efektem ma być wykres, który, jak rozumiem, ktoś ma
> obejrzeć, pomyśleć, pojeździć po nim kursorami, zastanowić się dlaczego
> akurat taki wyszedł, zmierzyć jakieś różnice dwu wykresów, czy np.
> odczytać fazę na jednym, gdy drugi przechodzi przez zero, itp.

Często zachodzi potrzeba wielokrotnego przeprowadzenia jakiegoś
eksperymentu. To może być rzeczywisty eksperyment, w krórym występują
dane pomiarowe. Może być symulacja, w której liczony jest ciąg danych
przy różnych parametrach. Mogą to być informacje ciągnięte z sieci.
W większości przypadkó te dane są jakimiś ciągami liczb. jeśli chcę
zobaczyć je w postaci wykresu, to potrzeba takieego wywołania.

> Domyślam się, że ma to związek z jakimiś skryptami. Nie wiem, czy dobrze
> rozumiem to słowo. Ja mam tylko dwa baty (Backup.bat i Backup_r.bat)
> które robią .zip mojej kartoteki roboczej (całej/rzeczy zmienionych od
> ostatniej całej).
> Czy to są skrypty, czy nie za do końca?

Zakładam, że jest, chociaż pewnie bardzo prosty.

> Nigdy nie miałem nic wspólnego z unixem. Wydaje mi się, że tam jest to
> bardziej popularne.

Jest. Za to nie jest popularne narzekanie, że nie ma jednego programu,
który robi wszystko. Mam program liczący współczynnik konwersji
i przedstawiający go jako wykres w dB na osi w MHz. Program jest jaki
jest, sam go napisałem, poradzili mi żeby wykres w SVG, co okazało się
dobrym rozwiązaniem. Ale nagle wyszło, że koniecznie muszę mieć wykresy
w plikach PNG zamiast SVG. No to dopisuję na końcu stryptu wołającego
program "convert plik.svg plik.png" -- i sprawa załatwiona. To samo
gdyby potrzebny był PDF. Unix ma całą basę programów robiących jedną
rzecz, za to dobrze. Przy odrobienie wprawy zestawia się z tego jedną
linie produkcyjną -- ustawia się programy jeden za drugim, zupełnie
jak maszyny w fabryce przy produkcji taśmowej. I za jednym pociągnięciem
za szmurek mam zrobione wszystko.

Skryptowanie zaspakaja potrzebę lenistwa, ale nie tylko. Jeśli sam robię
szereg czynności pod rząd, a w dodatku wiele ustawień musze po drodze
wyklikać, to nigdy ni mam pewności, że się nie pomyliłem. To znaczy
podejrzewam, że tak było, bo jestem roztargniony. Więc powtarzam wszystko
dla sprawdzenia, czy wyjdzie to samo. Skrypt jest jednocześnie dokumentacją
do uzyskanych wyników. To ważne.

> Na podsumowanie dziękuję wszystkim za udział w moim wątku. Szczególnie
> Jarkowi. To, czego chciałem się dowiedzieć już wiem (nawet trochę
> więcej). Jak przyjdzie na to czas to skorzystam z tej wiedzy.
>
> Jeszcze raz dzięki!

Cieszę się ogromnie. To jeszcze ten "convert". Też warto się zainteresować,
działa nie tylko w uniksach, jest wersja Windows. Przerabia każdy format
graficzny na dowolny inny (jeśli to ma sens). Ponadto robi wiele innych
manipulacji z plikami graficznymi -- https://www.imagemagick.org

--
Jarek

do góry

Pan J.F. napisał:

>>> Rozpoznanie tych plikow xml tez nie bylo 5 minutowe.
>> 15 sekundowe raczej. Główna robota to rozpakowanie zipa
>> i spakowanie go nazad.
>
> O Twoim czasie pisze. Trzeba rozpakowac, przejrzec, zauwazyc
> co i jak. Potem stosowne programy/skrypty napisac.

Też piszę o swoim. Struktura plików jest prosta, rozpoznanie
idzie szybko. A w skryptach właśnie to przepakowanie zajmuje
najwięcej. Zmiany były jedną linijką seda.

--
Jarek

do góry

W dniu czwartek, 13 lipca 2017 20:44:13 UTC+2 użytkownik Piotr Dmochowski napisał:
> W dniu 2017-07-13 o 18:55, s...@g...com pisze:
> > I z drugiej strony:
> > xml niby fajny jest, czytelny i intuicyjny ale ma między innymi te wade ze jak
jest duzy i "fikuśny" to może byc trudno go wczytywać sekwencyjnie.
> > Pamietam jak znajomy jakies 200MB xml-e próbował załadować aby po nich nastepnie
"pojeżdzić" programem. Na komputerze z 2GB ram biblioteka sie przewracała bo nawet
swapa zabrakło (system chyba 32bitowy byl).
> >
> > W praktyce przy zrobieniu paru założeń takiego xml-a sie daje wczytać bez
problemu ale jednak program sie robi nieco bardziej skomplikowany niż obsługa rekordu
w pascalu :)
> >
> Jakby ktoś chciał pisać własne programy do obsługi dużych XMLi, a nie
> chce wymyślać wszystkiego sam, to niech poszuka biblioteki SAX (takie
> coś jest w Javie, ale też w innych językach). Zamiast odtwarzać cały
> dokument w pamięci (metoda DOM) czyta plik XML po linijce i generuje
> odpowiednie zdarzenia, które potem trzeba samodzielnie przerobić na
> odpowiednie dane/obiekty/operacje.
> Dla większości programistów to pewnie oczywistość, ale może komuś się
> przyda.


Tak, racja. To były dosyć dawne czasy i SAX albo jeszce nie był rozwiniety albo miał
jakies tam problemy.
OIDP ten dokument był wciągany do bazy na zasadzie klucz, atrybut, wartosc.
W tym przypadku tak się dało bo xml nie był dziko opatrzony atrybutami w wielu
miejscach.

Tak czy siak. Widac tu dosyć mocno felery formatów tekstowych w porównaniu do
binariów.

do góry

W dniu czwartek, 13 lipca 2017 19:07:04 UTC+2 użytkownik J.F. napisał:
> Użytkownik sczygiel napisał w wiadomości grup
> dyskusyjnych:8bf50b8e-7e2b-42b0-8a53-52e5c3058080@go
oglegroups.com...
> W dniu czwartek, 13 lipca 2017 18:13:39 UTC+2 użytkownik Jarosław
> Sokołowski napisał:
> >Ja tylko lekko skomentuję:
> >Sporo formatów graficznych w dawnych czasach miało mocne koligacje z
> >tym jak sie te dane prezentowały w pamięci komputera podczas
> >wyświetlania.
> >Tak było w przypadku grafik na c64 i na amidze. Lub ewentualnie jesli
> >nie były dumpem pamięci to miały jakieś nieskomplikowane metody
> >kompresji.
> >Dlatego wtedy formaty tekstowe dla grafiki nie były prawie wcale
> >uzywane.
>
> Ale to w zasadzie nie na temat. Dumpy pamieci czy nie - jezyki
> programowania nie przewidywaly dolaczania danych binarnych.
>

W kodzie bezpośrednio nie. Ale juz jako załadowanie danych z dysku - bardzo
popularne. Choćby wspomniany pascalowy rekord. Czy wpisane z ręki w pliku źródłowym
czy załadowane z pliku za pomocą krótkiego polecenia - dla programisty problem
niewielki.

Jedyny problem jest taki ze jakos te dane binarne inicjalnie musza powstać i albo w
postaci tekstowej albo binarnej gdzieś się zapisać.
Tak czy siak czymś je trzeba było wytworzyć, Albo pracowicie wpisać w postaci
zrozumiałej i przetworzyc programem pomocniczym albo wciagnąć podobnym programem
pomocniczym z jakiejś innej formy.

> >Wyjatkami sa właśnie te wstawki w kodach źródłowych lub serie poleceń
> >DATA w basicu.
>
> DATA w basicu to ciagle tekst, DB czy DW w assemblerze to ciagle
> format tekstowy,

Tekst, ale niezbyt zjadliwy. Spróbuj takiego komodorowego duszka (dodac kropke tu i
ówdzie) czy inna sinusoidę edytowac (zmienić amplitude) tak z marszu ręcznie :)
Niewielka to pomoc w tym ze postac jest tekstowa :)

> w C tez tylko opis tekstowy byl mozliwy, i to ze sporym narzutem.
>
> Byc moze w czasach gdy pamieci bylo 16 czy 64KB nie bylo to wielkim
> problemem - takie dane byly malutkie, nie bylo problemu zapisac bajt
> po bajcie :-)
>

Ano, jakos w tamtych czasach ludzie mieli wiecej czasu. :)
Chyba ;)

>
> >Ale i tak preferuje te tekstowe formaty.
> >Troche z smutkiem obserwuje jak narzędzia sieciowe migrują w kierunku
> >pomotanych formatów czy ogólnie pojetego szyfrowania.
> >Nie będzie tak łatwo diagnozować co i dlaczego nie działa choć tu
> >obok działa bardzo dobrze :(
>
> Ale szyfrowanie w sieci jest konieczne :-(
>
>
Ano konieczne. Ale mocno utrudnia diagnostykę.
Pół biedy jak admin podzieli sie kluczem ssl i do wiresharka go mozna dodać.
Gorzej jak sie nie podzieli a nie ma jak prosto postawić sobie jakiegos proxy czy
innego stunnela :)

Dla mnie najoptymalniejsze bylo by gdyby protokoły były nieszyfrowane ale juz ich
zawartośc tak.

Cos na zasadzie requestów http z np. obrazkami. Co trzeba - widać (host, url,
cookiesy) a co tajne - zaszyfrowane...

Ale wiem, po metadanych tez mozna szpiegować. Nadzieja w tym ze protokoły będą
niegłupie. Ale po tym co sie dzieje z ipv6 czy wynalazkami w postaci t3 to optymizm
mam umiarkowany...

do góry

Dnia Thu, 13 Jul 2017 14:46:33 -0700 (PDT), s...@g...com
> W dniu czwartek, 13 lipca 2017 19:07:04 UTC+2 użytkownik J.F. napisał:
>> Użytkownik sczygiel napisał w wiadomości grup
>>>Sporo formatów graficznych w dawnych czasach miało mocne koligacje z
>>>tym jak sie te dane prezentowały w pamięci komputera podczas
>>>wyświetlania.
>>>Tak było w przypadku grafik na c64 i na amidze. Lub ewentualnie jesli
>>>nie były dumpem pamięci to miały jakieś nieskomplikowane metody
>>>kompresji.
>>>Dlatego wtedy formaty tekstowe dla grafiki nie były prawie wcale
>>>uzywane.
>>
>> Ale to w zasadzie nie na temat. Dumpy pamieci czy nie - jezyki
>> programowania nie przewidywaly dolaczania danych binarnych.
>>
>
> W kodzie bezpośrednio nie. Ale juz jako załadowanie danych z dysku -
> bardzo popularne. Choćby wspomniany pascalowy rekord. Czy wpisane z
> ręki w pliku źródłowym czy załadowane z pliku za pomocą krótkiego
> polecenia - dla programisty problem niewielki.

Ale nie o to chodzi, zeby program przy wykonaniu sobie przeczytal.
Tylko o to, zeby kompilator przeczytal i do kodu dolaczyl.

Takiej opcji nie ma, trzeba dane opisac tekstem.

>>>Wyjatkami sa właśnie te wstawki w kodach źródłowych lub serie poleceń
>>>DATA w basicu.
>> DATA w basicu to ciagle tekst, DB czy DW w assemblerze to ciagle
>> format tekstowy,
>
> Tekst, ale niezbyt zjadliwy. Spróbuj takiego komodorowego duszka
> (dodac kropke tu i ówdzie) czy inna sinusoidę edytowac (zmienić
> amplitude) tak z marszu ręcznie :) Niewielka to pomoc w tym ze
> postac jest tekstowa :)

w assemblerze byl format binarny :-)

>> Byc moze w czasach gdy pamieci bylo 16 czy 64KB nie bylo to wielkim
>> problemem - takie dane byly malutkie, nie bylo problemu zapisac bajt
>> po bajcie :-)
>>
> Ano, jakos w tamtych czasach ludzie mieli wiecej czasu. :)
> Chyba ;)

Chodzilo mi o to, ze jak mam sobie duszka zdefiniowac, cale 21 bajtow,
to moge sobie napisac w jakims DB, czy DATA.
Generator znakow do Spectrum, bodajze 1KB, juz troche uciazliwy.
A dzis wszystko znacznie wieksze.


J.

do góry

On 07/10/17 08:10, Piotr Gałka wrote:
> Jaki byście użyli program (darmowy) aby uzyskać z funkcji wykres w dB w
> funkcji częstotliwości (f w skali log)?
> Chodzi mi o to, aby ten wykres dało się potem elegancko przenieść do
> dokumentu tekstowego.
>
> Sądzę, że korzystając z wpisywania parametrów równaniami udało by mi się
> coś w tym stylu uzyskać z PSpice czy LTSpice ale jak z przeniesieniem
> potem do tekstu to nie próbowałem.
>
> Podejrzewam, że jakieś programy nie elektroniczne a matematyczne lepiej
> się do tego nadadzą, ale nigdy żadnego nie używałem.
>
> Liczę na wiedzę i uprzejmość grupy - że uzyskam listę nadających się do
> tego programów, albo że jest jakiś jeden jedynie słuszny :)
>
> Chcę uzyskać wykresy jak w:
> http://www.etsi.org/deliver/etsi_en/300300_300399/30
0330/02.01.01_60/en_300330v020101p.pdf


Ktoś już wspomniał o R, a ja chciałem poprzeć tę rekomendację. Do
robienia wykresów jest całe multum programów, ale ze wszystkich z
którymi miałem do czynienia R najbardziej przypadł mi do gustu.
Kilkoma komendami można w nim na szybko zrobić profesjonalnie
wyglądający wykres, a jeśli potrzeba zrobić coś mniej standardowego,
można się odwołać do podstawowych funkcji rysujących. Taki wykres
log-lin o jakim wspomniałeś robi się jednym poleceniem. Wymyślny opis
osi, siatka wg twojego własnego pomysły, itp - to wszystko załatwia się
dwoma-trzema linijkami kodu. Oczywiście nic nie stoi na przeszkodzie
żeby bardziej zaszaleć. Wszystko można oskryptowić w języku R i
wykorzystać w przyszłości do automatycznej generacji wykresów.
Tutaj masz przykład wykresu zrobionego w R: http://tinyurl.com/y9ok97k6
Nie pamiętam dokładnie ile nad nim siedziałem, ale dłużej zajęło mi
zebranie danych niż samo zrobienie obrazka.

Jacek.

do góry

On Fri, 14 Jul 2017 02:07:33 -0400, Jacek Radzikowski
<j...@s...die.die.die.piranet.org> wrote:
> Ktoś już wspomniał o R, a ja chciałem poprzeć tę rekomendację.

R jest klonem S. I są to całkiem niezłe języki/programy, tyle że
adresowane do statystyków.

Matlab/Octave jest w podobnej konwencji - gotowe funkcje, możliwość
pisania skryptów, łatwe robienie wykresów - ale bardziej dla
inżynierów.

do góry

W dniu 2017-07-14 o 10:26, slawek pisze:
> On Fri, 14 Jul 2017 02:07:33 -0400, Jacek Radzikowski
> <j...@s...die.die.die.piranet.org> wrote:
>> Ktoś już wspomniał o R, a ja chciałem poprzeć tę rekomendację.
>
> R jest klonem S. I są to całkiem niezłe języki/programy, tyle że
> adresowane do statystyków.
>
> Matlab/Octave jest w podobnej konwencji - gotowe funkcje, możliwość
> pisania skryptów, łatwe robienie wykresów - ale bardziej dla inżynierów.

Trochę mnie przygniata nadmiar możliwości.
Jest sprzeczny z moją naturą - bardzo dokładna analiza wszystkich za i
przeciw przed podjęciem decyzji. Z własną natura najtrudniej się walczy.
Ale czasy, gdy wybór był tylko jeden, jedynie słuszny jednak były gorsze :).
P.G.

do góry