Dzisiaj podobno były zapisy do przedszkoli przez Internet. No i tak były, że ich nie było. Pewna pani w TVN skomentowała to mówiąc:
No przecież serwery tak mają.
No przecież…
Dzisiaj podobno były zapisy do przedszkoli przez Internet. No i tak były, że ich nie było. Pewna pani w TVN skomentowała to mówiąc:
No przecież serwery tak mają.
No przecież…
… nadjechało. Małe, ładne. Odtwarza DVD (nawet lepiej niż nasz leciwy odtwarzać), odtwarza blureje. Gra muzykę wystawianą na Linuksie (ale plejer beznadziejny jest). I divxy, choć póki co bez napisów. W wyścigi jakoś podejrzanie trudno się gra. Internetu nie umiem obglądać. Ciąg dalszy nastąpi.
Obsłużenie CSV w Excelu jest niebanalne. Jeśli zapisze się plik z rozszerzeniem .csv, Windows pokaże śliczną ikonkę, Excel radośnie rozpozna typ pliku i… otworzy pokazując, jakby cały wiersz był jednym polem. Metoda na skuteczne otwarcie:
Idziemy w chmurę. Poczta już poszła. Jutro pewnie pójdzie blog. A potem będziemy już się bujali w chmurach.
Normalnie powiadomienia niemal w czasie rzeczywistym. A z drugiej strony to dość idiotyczny pomysł wysyłać SMS, że ktoś dzwonił — telefon mi to pokazuje.
Wczoraj bua dostała spazmów i odmówiła dalszego działania. Okazało się, że skończyła się pamięć (cała!) i Linux zajmował się mieleniem dysku i niczym innym. Żadne próby reanimacji nie przyniosły skutku. Po restarcie wywaliłem swap. Stwierdziłem, że najwyżej ubije mi jakąś (firefoksa) aplikację i dalej będzie działać. A firefox umie odtworzyć ostatnio przeglądane strony. Więc w sumie OK. Ale nic z tego. Bez swapa, jak się skończy pamięć, Linux również zajmuje się głównie mieleniem dysku. Tylko nie wiem co on tam mieli. Tym razem przynajmniej udało się odratować i jakoś ubić firefoksa co pozwoliło na uniknięcie restartu.
Zużycie pamięci wygląda następująco:
Firefox (3.5.4pre) w chwili screenshota miał 23 otwarte zakładki.
Co robić, Droga Redakcjo?
Upgrejdnąłem WordPressa do najnowszej wersji. Duuuuże zaległości w tym temacie były. Śakiś inny jest od strony administracji jest. Chyba wszystko działa.
Kilka pierwszych wrażeń z używania ajfona:
No i póki co nadal używam Nokii e71 jako telefonu.
Recently we had reported several problems regarding PDU SMS decoding in gnokii. Apparently gnokii was unable to decode several messages that included TP-Parameter-Indicator field. Together with Daniele we’ve come across a specification, namely ETSI TS 123 040. There in chapter 9.2.3.27 it describes this field. And I think it is not clear what it claims. At least we and Nokia have different interpretations.
The most significant bit in octet 1 and any other TP-PI octets which may be added later is reserved as an extension bit which when set to a 1 shall indicate that another TP-PI octet follows immediately afterwards.
So, does it mean that there could be several TP-PI octets in row? If so, which one is the valid one? And how does it relate to SMS-SUBMIT-LAYOUT (9.2.2.4) which says that it is just 1 octet?
Further reading brings more information:
If a Reserved bit is set to „1” then the receiving entity shall ignore the setting. The setting of this bit shall mean that additional information will follow the TP-User-Data, so a receiving entity shall discard any octets following the TP-User-Data.
I completely don’t understand what is the reason for that. We say that there is additional information but it should be ignored? It’s beyond my perception.
Getting back to the problem. The general layout of TP-PI looks as follows:
And we had the following octets in the problem report:
Now, depending on interpretation of the specification, we can interpret differently the sequent octets. There are three:
First interpretation, is that TP-PI can be followed by next TP-PI octet, based on value of bit 7. All these records have it set, so we go till the last octet which would be TP-PI as well, but then there’s no room for at least TP-UDL which should be set. Doesn’t look right.
So, second interpretation (along with SMS-STATUS-REPORT layout): TP-PID, TP-DCS and TP-UDL will follow TP-PI octet. So we have:
So this interpretation looks even worse than the previous one. I’m used to bugs in software but this one really confuses me: I have no idea what would be a good way to interpret the message from the report. I’m committing the change that incorporated the first interpretation and doesn’t bother with missing TP-PID, TP-DCS, TP-UDL octets.
To summarize: specifications are good, but not all of them. Really try to be precise and unambiguous when writing a specification.