Użytkownik "Piotr Gałka" napisał w wiadomości grup
dyskusyjnych:npk58c$414$...@n...chmurka.net...
Użytkownik "Marek" <f...@f...com> napisał w wiadomości
>> Dzisiaj 95-99% kodu to bibliotek a pozostała reszta to wartość
>> dodana "user space".

>W mikrokontrolerach dopiero niedawno rozmiary Flash (w funkcji ceny)
>pozwalają chyba na takie podejście

A to zalezy co rozumiemy za mikrokontroler.
Taka np nawigacja samochodowa, pierwsze byly chyba juz z 15 lat temu,
a program mial pare MB (plus dane).

Telefon komorkowy siemens ME45, rok 2001, firmware liczyl cos 6MB.
A tam tylko 3 gry byly i zadnej Javy :-)

J.

do góry

MKi pisze:
>>> Dlaczego "za kilka dni"? Oczywiście karty trzeba było wydziurkować,
>>> ale wyniki były tego samego dnia.
>>
>> Może. Nie pamiętam dokładnie.
>
> Ja pamiętam dokładnie.
> Ośrodek Obliczeniowy Politechniki Gdańskiej formalnie wydawał
> wydruki "następnego dnia". Praktyka była taka, że dwa - trzy razy
> dziennie pani operatorka przewoziła wózek z wydrukami z sali
> komputera do korytarza, do którego dostęp mieli studenci.
>
> Jak ktoś miał super szczęście, to wydruk dostawał po godzinie.
> Niestety, te terminy były bardzo nieregularne - próbowaliśmy
> wykryć jakąś regularność czasem wręcz koczując pod ośrodkiem,
> nic z tego.
>
> A najbardziej frustrujący był odbiór wydruku z zaznaczonymi
> błędami syntaktycznymi - bo czytnik przekłamał odczyt jakiejś
> karty. Zazwyczaj po trzecim użyciu danej karty należało ją
> zastąpić nową.

Na Wydziale Elektroniki Politechniki Warszawskiej (czyli na popularnie
mówiąc Elce) programy na Odr 1402 spisywało się na pliku specjalnych
arkuszy ochrzczonych mianem sheetów, potem odbierało się ważący parę
kilo plik kart Holleritha, przeglądało i własnoręcznie edytowało karty
źle zakodowane...

--
Darek

do góry

Użytkownik "Piotr Gałka"

...
> że można po prostu cofnąć się do ostatniej pasującej wersji biblioteki.
Ale to było na temat tego artykułu. Jakoś się okazało, że oni nie mogli się
cofnąć do poprzedniej wersji jak te 11 linijek zniknęło z internetu.
---
A nie kojarzę by z artykułu wynikało, że nie mogą cofnąć. Gość tylko usunął
swój kod, bo uznał, że ma do tego prawo. Ale to z reguły znaczy, że ten kod
w centralnym repozytorium jest tyle, że został przez niego usunięty z
najnowszych wersji, które użytkownicy czerpią w ciemno, ale przecież nic nie
stoi na przeszkodzie by po zauważeniu problemu wycofać. No i są rozproszone
systemy wersjonowania, gdzie nawet nie dałoby się usunąć dostępu do tych
starych wersji.

> Że nie odkryłeś testów automatycznych to już wiem :-)
Wiem, że w toku dyskusji wykazałem się bardzo wieloma brakami w odkryciach,
ale jakbyś jakoś zdefiniował/opisał co rozumiesz pod pojęciem testy
automatyczne (jakiś przykład) to byłbym dźwięczny. Czuję, że wiąże się to z
czymś co ja nazywam wektory testowe, ale nie wiem czy to jest to samo, czy
coś więcej.
---
Jest wiele różnych metod testowania oprogramowania. Mnie chodzi tylko o to,
że są metody automatycznego testowania umożliwiające szybkie stwierdzenie,
że po zmianie nie działa zgodnie z założeniami. Stawiałeś taki problem.

do góry

Użytkownik "Piotr Gałka"

Spróbuj odkryć :)
Bo SVN lub ewentualnie git (choć do prostych spraw lepszy svn IMHO) to fajna
sprawa.
Coś w rodzaju aktówki windowsowej i automatycznego kopiowacza który zapisuje
poszczególne zmiany w plikach zapisywanych. Fajna sprawa.
Przydaje sie nie tylko do kodu.
Może śledzić również dokumenty, pliki binarne itp...
--------
Nie czuję potrzeby. ... po jakimś
czasie wyłączłem jego funkcje pamiętania iluś tam ostatnich wersji plików
...
---
Więc taka sytuacja jak opisana w artykule mogłaby się zdarzyć z twoim kodem

do góry

Użytkownik "Piotr Gałka"


Ja np. korzystam z SVN do synchronizowania plików między komputerami, jako
backup i system wersjonowania.
Całość to w sumie dwa skrypty (update i commit) a pożytek ogromny.
Jak pracuję na jednym komputerze i tworzę coś to wystarczy że wyślę aktualny
stan pracy do svn jednym skryptem, nastepnie idę do drugiego komputera i
uruchamiam update, robie co mi tam trzeba i wynik znowu wysylam do svn
(commit).
To w sumie nic kosmicznego ale bardzo ułatwia pracę.

-----------
Przekonałeś mnie na tyle, że zapisałem sobie to SVN (+ wcześniej wymieniony
git) do sprawdzenia kiedyś.....
Ja pracuję na jednym komputerze i nie mam potrzeby synchronizacji
czegokolwiek.
---
Przepuszczanie kodu przez inne komputery umożliwia zweryfikowanie
kompletności projektu.

do góry

Użytkownik "Piotr Gałka"

>
> W naszych urządzeniach (to brat, nie ja) nie ma bibliotek i jest USB, ale
> tcpip załatwia scalak, który realizuje stos - czyli równoważnik użycia
> biblioteki.
> ---
> Czyli jednak użyłeś tej biblioteki
Dla mnie to nie jest użycie biblioteki tylko coś równorzędnego.
---
Co za różnica ?

Jak w mikrokontrolerze jest sprzęt liczący AESa i brat pisząc program
korzysta z niego to nie musi dołączać do swojego kodu żadnej biblioteki
tylko musi wiedzieć przez które rejestry i jak komunikować się z tym
sprzętem.
---
No właśnie, czyli zamiast napisać ten kod samodzielnie użyłeś jakiegoś
scalaka. Ten scalak ma jakiś kod, mikrokod czy cokolwiek, co jest gotową
biblioteką nawet jeśli zwykle tego tak nie określamy.

do góry

Jarosław Sokołowski pisze:
> Pan Piotr Gałka napisał:
>
>>> Ja odczuwałem różnicę. Wetknięcie tam command.com i paru innych
>>> rzeczy sprawiało, że system stawał się bardziej responsywny.
>>
>> A z polskiego na nasze, to co to oznacza? :)
>
> Responsywny system szybko reaguje na polecenia. A potem wykonuje
> je w swoim tempie. Możemy sobie wyobrazić komputer z zegarem 4 GHz
> i DOS-em uruchomionym z dyskietki. Wydajemy mu jakieś *zewnętrsne*
> polecenie, a on majestatycznie rozpędza plastik, czyta porozrzuzene
> sektory chrobocząc głowicą, aż w końcu w okamgnieniu wykona co
> od niego chcieliśmy. Komputer z zegarem 12 MHz, ale korzystający
> z ramdysku, zareaguje kilkaset razy szybciej, a wykona kilkaset
> razy wolniej. Z tym że to "wolniej" może być dla człowieka
> niezauważalne. A "szybciej" -- wręcz przeciwnie. Dla mnie nawet
> różnica między HDD i ramdyskiem była odczuwalna w normalnej (dla
> mnie) przcy z komputerem.
>
> Mniej lub bardziej responsywne są nie tylko komputery. Samochodów
> też to dotyczy. Statek pełnomorski jest bardzo mało responsywny,
> choć potrafi całkiem szybko pomykać przez oceany. Z ludźmi również
> tak jest. Jednych trzeba prosić miesiącami, ale jak im zaskoczy,
> to uwijają się żwawo. Inni od razu reagują "już lecę", a potem
> rok grzebią się z robotą.

I to jest taka pewna paranoja, ten command.com jako niejako system
powinien być permanentnie trzymany w RAM i zabezpieczony przed
wywaleniem przez coś innego, nie wiem czy tak się dzieje lub jest to w
ogóle możliwe, ale faktem jest że trzymanie pewnych rzeczy w ramdysku
zdecydowanie daje kopa maszynie, bawiłem się tym jeszcze za czasów 386
kiedy komp z 4MB RAM to był wypas a dyski twarde miały transfer rzędu
700kB/s. Nie wiem jak działa mechanizm alokacji pamięci (wtedy i teraz)
ale wygląda na to, że jak brakuje pamięci na coś co ma być uruchomione
to system czyści cache systemu plików bez patrzenia co tam siedzi.


--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html

do góry

Pan AlexY napisał:

> I to jest taka pewna paranoja, ten command.com jako niejako system
> powinien być permanentnie trzymany w RAM i zabezpieczony przed
> wywaleniem przez coś innego,

Nie taka tam znowu paranoja, jeśli wziąć pod uwagę gospodarowanie
ograniczoną pamięcią RAM. Command.com miał część rezydentną i
nierezydentną. Ta druga była wywalana z pamięci przed uruchomieniem
programu. A potem ładowana po jego zakończeniu.

> nie wiem czy tak się dzieje lub jest to w ogóle możliwe,

Shell uniksowy siedzi w ramie cały czas.

--
Jarek

do góry

Użytkownik "Jarosław Sokołowski" napisał w wiadomości grup
dyskusyjnych:s...@f...lasek.waw.p
l...
>Shell uniksowy siedzi w ramie cały czas.

Chyba nie tak calkiem - raz, ze przez mechanizm pamieci wirtualnej
moze z tej pamieci wyleciec na dysk.

Dwa - cos mi chodzi po glowie, ze byla mozliwosc "wyjdz z shella i
uruchorm inny program".
Malo uzyteczne, bo potem sie trzeba bylo zalogowac :-)

J.

do góry

> Na Wydziale Elektroniki Politechniki Warszawskiej (czyli na popularnie
> mówiąc Elce) programy na Odr 1402 spisywało się na pliku specjalnych
> arkuszy ochrzczonych mianem sheetów, potem odbierało się ważący parę
> kilo plik kart Holleritha,

U nas pisanie na sheetach też było w ofercie ośrodka obliczeniowego,
ale to wydłużało o jeden dzień proces tworzenia programu. Po paru
pierwszych programach wszyscy na roku nauczyliśmy się obsługiwać
perforatory. Dla wielu był to pierwszy kontakt z klawiaturą.

> przeglądało i własnoręcznie edytowało karty
> źle zakodowane...

Oj, tak, tak. Z definicji panie perforatorki miały obowiązek
przepisywać znak w znak, łącznie z błędami ortograficznymi
w komentarzach. A w rzeczywistości... raz zdarzył mi się
plik kart wydziurkowanych z przesunięciem o jeden znak w
lewo (czyli to, co miało być w 7 kolumnie, było w 6). Jak
ktoś pamięta FORTRAN, to wie, jak to było bolesne.

Pozdrowienia,
MKi

do góry