Użytkownik "Piotr Gałka" napisał w wiadomości grup
dyskusyjnych:ok53vj$fpc$1$P...@n...chmurka.ne
t...
W dniu 2017-07-12 o 13:43, slawek pisze:
> On Wed, 12 Jul 2017 12:24:23 +0200, Piotr
> Gałka<p...@c...pl> wrote:
>> W sumie nie rozumiem dlaczego w świecie Internetu i komputerów tak
>> dużo
>> formatów jest tekstowe.
>> Bo znacznie prościej zapisać w XML lub YML a potem skompresować.
>> Niż robić format binarny, męczyć little big endian itd.

>Jak formaty są tak zdefiniowane to tak się robi.
>Mi chodziło raczej - dlaczego są tak definiowane.
>Nie rozumiem w jakim sensie prościej?
>Dla mnie znacznie prostsze jest wstawianie/wybieranie liczb do/z
>pliku binarnego niż tekstowego.
>Jak liczba jest zapisana na konkretnych bajtach w konkretny sposób to
>po prostu jest. A jak jest tekstowo to jeszcze przy czytaniu trzeba
>analizować, czy nie ma błędów.

>Problem little/big jest prawie tego samego typu jak czy kropka czy
>przecinek w zapisie tekstowym.

>Dla wstawiania/wyczytywania odwrotnie niż moja maszyna ma w naturze
>jeszcze chyba w ubiegłym wieku napisałem sobie kilka jednolinijkowych
>funkcji (GetW, PutW, GetDW, PutDW, GetQW, PutQW).
>Jak ktoś używa innych liczb niż całkowite to musiałby jeszcze kilka
>podobnych funkcji mieć i koniec tego tematu.

No, jak to ma dzialac na roznych maszynach, to zwykly zmienny
przecinek nie jest juz taki prosty, bo trzeba jakos przetlumaczyc
formaty binarne.
Co prawda od pewnego czasu swiat sie przestawil na Intela, to i
problem mniejszy.

XML moze byc o tyle dobry, ze zapamietuje od razu strukture danych, i
to czesto zmienna. Przy formacie binarnym musialbys sie namyslic
dlugo.
Choc i tak musisz sie pozniej namyslic ... albo sie dziwisz, ze 4GHz
maszyna jest wolniejsza niz kiedys 100MHz, a 8GB RAM nie wystarcza :-)

Ale to jest jak mowimy o programach, pisanych od poczatku.

A mnie o takie ludzkie sprawy chodzilo - np trzeba z dwoch plytek
zrobic jedna dla plytkarni.
Albo mamy dobry program do schematow, dobry program do plytek,
netliste trzeba miedzy nimi przeniesc.
Czy jak widzisz - wykres narysowac na podstawie danych z arkusza.

Albo np dwa pliki JPK zlozyc w jeden.
Czy np plik sie nie chce wczytac do programu ... i co zrobic ?

Tekstowe formaty maja zalety.

J.

do góry

W dniu 2017-07-12 o 23:11, Jarosław Sokołowski pisze:

> Dltego warto czasem zadać takie pytanie. Można przeżyć miłe zaskoczenie
> i czegoś się dowiedzieć. Ale będę bezlitosny: pliki grafik bitmapowych
> też bywają plikami tekstowymi. I to własnie najstarsze, najdłużej używane
> formaty takie są.

Kiedyś drukarki umiały drukować tylko znaki więc grafikę się robiło
dobierając znaki o odpowiednim wypełnieniu (masa kropek daje jaśniejszy
odcień niż masa gwiazdek itp.).
Jeszcze jak byłem w szkole to widziałem takie "obrazy" zajmujące 3
arkusze papieru.
Na studiach miałem tylko jeden semestr ćwiczeń na temat programowania
komputerów w języku wysokiego poziomu (Algol) i moim zadaniem było
napisanie programu, który pouzupełnia przerwy w konturach obrazu. A
obraz był malowany gwiazdkami.

>> To jest ta sytuacja, gdy jakiś program robi sobie dla siebie
>> jakiś plik - nie wnikam.
>
> A mnie się już zdarzyło dłubać w plikach MS Office otwierając zipy
> i edytując wewnętrzne iksemele. Co więcej, napisałem kiedyś skrypt,
> który wsadowo poprawiał coś w całym tabunie plików. I oszczędził
> dziesiątki dupogodzin operatora Excela.

W czasach XT zdarzyło mi się popełnić programik, który przerabiał jakiś
plik z Orcada na netlistę do Racal-Redaca. Nie miałem opisu żadnego z
tych formatów więc musiało być na zasadzie czytania ze zrozumieniem i
zapewne pliki były tekstowe. Nie wiem dlaczego była taka potrzeba -
czyżby Racal-Redac nie miał edytora schematów. W każdym razie wszyscy w
koło (na Polibudzie) od razu przygarnęli mój programik.

> Gnuplota bym nie odpuszczał.

Nie odpuszczam tylko odkładam. Najpierw dokończę zabawę z KiCadem, do
której to zabawy i tak nie mogę w tej chwili wrócić.

> To tradycyjne oldskulowe narzędzie, które
> z naprędce wyplutych z jakiegoś programu dwóch kolumn liczb opisujących
> punkty wykresu robi przyzwoity wykres, dobierając przy tym wszystko co
> da się automatycznie dobrać. I wywołuje się to w jednej krótkiej linijce
> poleceń.

Do takiego celu użyłem PSpice. W 2004 weszło CE i EMC. Miałem potrzebę
przekucia teorii w praktykę. Mam oscyloskop cyfrowo/analogowy, który nie
ma FFT, ale mogę z niego dostać serie próbek. W PSpice jest źródło
napięcia sterowane próbkami z pliku i na oglądarce przebiegów można
włączyć FFT.
Czy to przypadkiem nie daje większych możliwości niż uzyskam z Gnuplota?

Tym sprzętem udało mi się zmierzyć pojemność własną dławika 100uH
wynoszącą 0,4pF i według mnie pomiaru dokonałem z dokładnością rzędu 0,1pF.
Ogólnie, cała moja koncepcja była błędna - chciałem jedną sekcją filtru
objąć jak najszersze pasmo. Teraz już tak nie robię i zawsze łączę dwie
sekcje - jedna dla wyższych, druga dla niższych częstotliwości.

> Chociaż ostatnio takie pozyskane
> jakbądź dane pomiarowe oglądam firefoksem z javascriptu (wektorowo).
> W razie czego służę skleconym szybko, ale użytecznym systemem bojowym.
> W myszowaty sposób pokazuje wartości w punktach, pozwala powiększać
> wykres, a kod zajmuje może kilkanaście linijek (plus biblioteka).

Dzięki, ale od tego 2004 nie miałem potrzeby oglądania na PC danych
pomiarowych. A jakbym miał to chyba znów użyję PSpice bo nie dość, że
mam opanowaną jego oglądarkę to jeszcze mogę te dane przefiltrować
dodając na schemacie kilka elementów lub bloków opisanych funkcjami
transmitancji.
P.G.

do góry

Użytkownik "Jarosław Sokołowski" napisał w wiadomości grup
dyskusyjnych:s...@f...lasek.waw.p
l...
>Dltego warto czasem zadać takie pytanie. Można przeżyć miłe
>zaskoczenie
>i czegoś się dowiedzieć. Ale będę bezlitosny: pliki grafik
>bitmapowych
>też bywają plikami tekstowymi. I to własnie najstarsze, najdłużej
>używane
>formaty takie są. Na przykład plik XPM może wyglądać tak (pierwszy,
>jaki
>mi się wylosował na dysku, to naprawdę jest jeszcze w użyciu):

>/* XPM */
>static char * 3d7_xpm[] = {
>"18 18 2 1",
>" c None",
>". c #000000",
>" ",
>" ",

>Albo PBM (plik wyjęty ze źródeł kernela Linuksa, całkiem
>współczesny):
>P1
># Standard black and white Linux logo
>80 80
>1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
>1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
># resztę wycinam, bo nudna.

Ale to z roznych rzecy moze wynikac.
Np na pewnym etapie chcemy miec dane obrazka w pamieci, a ten unixowy
linker nie przewiduje opcji "a tu wsadz zawartosc pliku aaaa.bmp".
Mam na mysli np etap bootowania, gdy nie mozna liczyc na zaczytanie
pliku z dysku przez biblioteke :-)

MS Windows przewidywal dawniej ze program zrodlowy sklada sie z tekstu
programu i "zasobow" - ikon, menu, wygladu okienek/formularzy ... ale
to IMO tez wcale takie dobre nie bylo.

>>> tak jak można robić notatki w Exelu i kolorować je na źółto,
>>> zielono i czerwono -- też bez analizy budowy pliku XLS.
>
>> To jest ta sytuacja, gdy jakiś program robi sobie dla siebie
>> jakiś plik - nie wnikam.

>A mnie się już zdarzyło dłubać w plikach MS Office otwierając zipy
>i edytując wewnętrzne iksemele. Co więcej, napisałem kiedyś skrypt,
>który wsadowo poprawiał coś w całym tabunie plików. I oszczędził
>dziesiątki dupogodzin operatora Excela.

Kosztem Twoich dupogodzin :-)

Excel ma tez jezyk programowania i prawdopodobnie dalo sie to zrobic w
tym VB ... tylko trzeba wiedziec jak, albo doczytac :-)

J.

do góry

Pan Piotr Gałka napisał:

>> To tradycyjne oldskulowe narzędzie, które z naprędce wyplutych z jakiegoś
>> programu dwóch kolumn liczb opisujących punkty wykresu robi przyzwoity
>> wykres, dobierając przy tym wszystko co da się automatycznie dobrać.
>> I wywołuje się to w jednej krótkiej linijce poleceń.
>
> Do takiego celu użyłem PSpice. W 2004 weszło CE i EMC. Miałem potrzebę
> przekucia teorii w praktykę. Mam oscyloskop cyfrowo/analogowy, który nie
> ma FFT, ale mogę z niego dostać serie próbek. W PSpice jest źródło
> napięcia sterowane próbkami z pliku i na oglądarce przebiegów można
> włączyć FFT.
> Czy to przypadkiem nie daje większych możliwości niż uzyskam z Gnuplota?

Nie znam PSpice, ale z tego co widzę, tego nie "wywołuje się w jednej
krótkiej linijce poleceń". Czyli jednak inny obszar zastosowań. Gnuplot
zdecydowanie nie jest Programem, Który Robi Wszystko. A nawet to co robi,
czasem trzeba poprawiać. Zajrzałem teraz do skryptu, który nieprzerwanie
od kilkunastu lat robi wykres. Oszacowałem, że musiał ich zrobić do tej
pory około 40 milionów. Więc sprawdzone rozwiązanie. Znalazłem tam taką
linijkę:

gnuplot $PLOT | sed 's/\x00\xEE\xEE/\xB0\xC0\xFF/' \

W zmiennej "PLOT" są parametry wywołania, z których wynika, że tworzy
on plik GIF. A że nie da się ustawić w parametrach dowolnego koloru,
więc edytor strumieniowy sed zamienia to co jest na bardziej wysmaczony
odcień. Hackerka na pliku binarnym, ale działa. Dzisiaj w tekstowych
formatach takie manipulacje są dużo łatwiejsze i bardziej pewne.

--
Jarek

do góry

Pan J.F. napisał:

>> Albo PBM (plik wyjęty ze źródeł kernela Linuksa, całkiem współczesny):
>> P1
>> # Standard black and white Linux logo
>> 80 80
>> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
>> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
>> # resztę wycinam, bo nudna.
>
> Ale to z roznych rzecy moze wynikac.
> Np na pewnym etapie chcemy miec dane obrazka w pamieci, a ten unixowy
> linker nie przewiduje opcji "a tu wsadz zawartosc pliku aaaa.bmp".
> Mam na mysli np etap bootowania, gdy nie mozna liczyc na zaczytanie
> pliku z dysku przez biblioteke :-)

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.

> MS Windows przewidywal dawniej ze program zrodlowy sklada sie z tekstu
> programu i "zasobow" - ikon, menu, wygladu okienek/formularzy ... ale
> to IMO tez wcale takie dobre nie bylo.

Tak przewidywał? Nie wiem, nie z nam się na MS Windows. Ale to Mac OS
miał w pliku "resource fork" z ikonami i innymi takimi.

>> A mnie się już zdarzyło dłubać w plikach MS Office otwierając zipy
>> i edytując wewnętrzne iksemele. Co więcej, napisałem kiedyś skrypt,
>> który wsadowo poprawiał coś w całym tabunie plików. I oszczędził
>> dziesiątki dupogodzin operatora Excela.
>
> Kosztem Twoich dupogodzin :-)

Ale dupę każdy ma swoją -- tak miałem wszystko szybciej.

> 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.

--
Jarek

do góry

Użytkownik "Jarosław Sokołowski" napisał w wiadomości
Pan J.F. napisał:
>>> Albo PBM (plik wyjęty ze źródeł kernela Linuksa, całkiem
>>> współczesny):
>>> P1
>>> # Standard black and white Linux logo
>>> 80 80
>>> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
>>> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
>>> # resztę wycinam, bo nudna.
>> Ale to z roznych rzecy moze wynikac.
>> Np na pewnym etapie chcemy miec dane obrazka w pamieci, a ten
>> unixowy
>> linker nie przewiduje opcji "a tu wsadz zawartosc pliku aaaa.bmp".
>> Mam na mysli np etap bootowania, gdy nie mozna liczyc na zaczytanie
>> pliku z dysku przez biblioteke :-)

>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 :-)

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 :-)

>> MS Windows przewidywal dawniej ze program zrodlowy sklada sie z
>> tekstu
>> programu i "zasobow" - ikon, menu, wygladu okienek/formularzy ...
>> ale
>> to IMO tez wcale takie dobre nie bylo.

>Tak przewidywał? Nie wiem, nie z nam się na MS Windows. Ale to Mac OS
>miał w pliku "resource fork" z ikonami i innymi takimi.

Tak bylo, a moze i jest. Ikonki, menu, kursory - to stanowilo
dodatkowa zawartosc pliku exe, a stosowne programy umozliwialy
przygotowanie danych, przechowywanie "projektu" i generacje pliku exe.

>>> A mnie się już zdarzyło dłubać w plikach MS Office otwierając zipy
>>> i edytując wewnętrzne iksemele. Co więcej, napisałem kiedyś
>>> skrypt,
>>> który wsadowo poprawiał coś w całym tabunie plików. I oszczędził
>>> dziesiątki dupogodzin operatora Excela.
>> Kosztem Twoich dupogodzin :-)
>Ale dupę każdy ma swoją -- tak miałem wszystko szybciej.

>> 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.

J.

do góry

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

>>> 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.

--
Jarek

do góry

W dniu 2017-07-13 o 17:17, Jarosław Sokołowski pisze:
>
> 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.

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?

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

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!
P.G.

do góry

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.
Wyjatkami sa właśnie te wstawki w kodach źródłowych lub serie poleceń DATA w basicu.

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 :)

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 :(

do góry

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.

>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,
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 :-)


>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 :-(

J.

do góry