Comments for mBlog - a point in M-space http://blog.swidzinski.com Purveyor of fine irrelevance Thu, 29 Jul 2010 13:23:10 +0000 http://wordpress.org/?v=2.0.4 Comment on Protected: Kimchi lovers, beware of project managers by Vicodin addiction. http://blog.swidzinski.com/2007/01/02/kimchi-lovers-beware-of-project-managers.html#comment-16091 Wed, 21 Jul 2010 17:14:06 +0000 http://blog.swidzinski.com/2007/01/02/kimchi-lovers-beware-of-project-managers.html#comment-16091 Protected Comments: Please enter your password to view comments.

This post is password protected. To view it please enter your password below:

]]> Comment on Polonization of PRS-500 - spolszczenie PRS-500 by Ewa http://blog.swidzinski.com/2007/04/30/polonization-of-prs-500-spolszczenie-prs-500.html#comment-12704 Sat, 26 Dec 2009 21:32:22 +0000 http://blog.swidzinski.com/2007/04/30/polonization-of-prs-500-spolszczenie-prs-500.html#comment-12704 Pomocy kupilam e booka ale nie dziala na ekranie pojawia sieusing the stylus tap on the center of the target a po tem calibrtion error detected please restart celibration proces ale co to znaczy i jak? Pomocy kupilam e booka ale nie dziala na ekranie pojawia sieusing the stylus tap on the center of the target a po tem calibrtion error detected please restart celibration proces ale co to znaczy i jak?

]]> Comment on Sony Reader tip so simple that it hurts by sdf http://blog.swidzinski.com/2007/03/28/sony-reader-tip-so-simple-that-it-hurts.html#comment-9303 Tue, 09 Dec 2008 12:55:24 +0000 http://blog.swidzinski.com/2007/03/28/sony-reader-tip-so-simple-that-it-hurts.html#comment-9303 captcha есть премодерация http://blog.swidzinski.com/2007/03/28/sony-reader-tip-so-simple-that-it-hurts.html captcha есть премодерация
http://blog.swidzinski.com/2007/03/28/sony-reader-tip-so-simple-that-it-hurts.html

]]> Comment on Aren’t ClearCase triggers kind of broken??? by yo http://blog.swidzinski.com/2007/09/27/arent-clearcase-triggers-kind-of-broken.html#comment-9137 Fri, 28 Nov 2008 12:14:41 +0000 http://blog.swidzinski.com/2007/09/27/arent-clearcase-triggers-kind-of-broken.html#comment-9137 My impression is that everything is missed up in clearcase. The whole thing is so damm complex and a productivity dumper. If you use a simple repository system like cvs or subversion (the ones i know, call me ignorant), you can actually work without having to think all day about the repository. If you use clearcase you will remember (and damm) every 2 minutes that you are working on clearcase. It seems to me that ibm guys thought that software development was really easy and they made the rational monster. My impression is that everything is missed up in clearcase. The whole thing is so damm complex and a productivity dumper.

If you use a simple repository system like cvs or subversion (the ones i know, call me ignorant), you can actually work without having to think all day about the repository.

If you use clearcase you will remember (and damm) every 2 minutes that you are working on clearcase.

It seems to me that ibm guys thought that software development was really easy and they made the rational monster.

]]> Comment on Protected: The first time in my life by Doug http://blog.swidzinski.com/2006/03/28/the-first-time-in-my-life.html#comment-8553 Wed, 29 Oct 2008 18:59:28 +0000 http://blog.swidzinski.com/2006/03/28/the-first-time-in-my-life.html#comment-8553 Protected Comments: Please enter your password to view comments.

This post is password protected. To view it please enter your password below:

]]> Comment on Integrating Araxis Merge & ClearCase by Mikolaj http://blog.swidzinski.com/2005/06/08/integrating-araxis-merge-clearcase.html#comment-8072 Fri, 26 Sep 2008 10:42:34 +0000 http://blog.swidzinski.com/2005/06/08/integrating-araxis-merge-clearcase.html#comment-8072 Short: No, it tackles every dir and/or file separately. Long: I too, was tempted to use araxis for directory merges instead of clearcase. Actually the merging of directories is handled by cleardiffmrg.exe, so it looked doable. But cleardiffmrg does some magic when merging dirs. Whereas for files you just get the actual versions as input, what's happening with dirs is that clearcase creates temporary files in a special format and does comparisons of these files. Think about it - it needs to compare not only the names, but also the oids of the files (so that it handles cases like "a.c has been renamed to b.c, but these are still versions of the same file" or "the two c.h files are evil twins"). A lot of playing around would be needed to handle such cases correctly. Short: No, it tackles every dir and/or file separately.
Long: I too, was tempted to use araxis for directory merges instead of clearcase. Actually the merging of directories is handled by cleardiffmrg.exe, so it looked doable. But cleardiffmrg does some magic when merging dirs. Whereas for files you just get the actual versions as input, what’s happening with dirs is that clearcase creates temporary files in a special format and does comparisons of these files. Think about it - it needs to compare not only the names, but also the oids of the files (so that it handles cases like “a.c has been renamed to b.c, but these are still versions of the same file” or “the two c.h files are evil twins”). A lot of playing around would be needed to handle such cases correctly.

]]> Comment on Integrating Araxis Merge & ClearCase by Andrew http://blog.swidzinski.com/2005/06/08/integrating-araxis-merge-clearcase.html#comment-8063 Thu, 25 Sep 2008 17:48:28 +0000 http://blog.swidzinski.com/2005/06/08/integrating-araxis-merge-clearcase.html#comment-8063 Thanks for your prompt reply Mikolaj. Does ClearCase ever pass entire folder versions to Merge, or does it always pass files? Thanks for your prompt reply Mikolaj.

Does ClearCase ever pass entire folder versions to Merge, or does it always pass files?

]]> Comment on Integrating Araxis Merge & ClearCase by Mikolaj http://blog.swidzinski.com/2005/06/08/integrating-araxis-merge-clearcase.html#comment-8057 Thu, 25 Sep 2008 07:19:28 +0000 http://blog.swidzinski.com/2005/06/08/integrating-araxis-merge-clearcase.html#comment-8057 Well, I am working on base cc, so cannot give you a definite answer. But I frankly doubt that the merge tool itself gets or uses "stream knowledge". From what it looks like, cc is taking care of the whole "merge infrastructure", ie. it decides which files & versions are being merged. The actual merge program is simply taking the input file versions, spits out the merged file, then the ball is again on cc side. It would be a strange design decision if it also contained additional logic. Well, you could just log the parameters that it's getting for a while to see if anything like that happens. Well, I am working on base cc, so cannot give you a definite answer. But I frankly doubt that the merge tool itself gets or uses “stream knowledge”. From what it looks like, cc is taking care of the whole “merge infrastructure”, ie. it decides which files & versions are being merged. The actual merge program is simply taking the input file versions, spits out the merged file, then the ball is again on cc side. It would be a strange design decision if it also contained additional logic. Well, you could just log the parameters that it’s getting for a while to see if anything like that happens.

]]> Comment on Integrating Araxis Merge & ClearCase by Andrew http://blog.swidzinski.com/2005/06/08/integrating-araxis-merge-clearcase.html#comment-8055 Thu, 25 Sep 2008 01:47:42 +0000 http://blog.swidzinski.com/2005/06/08/integrating-araxis-merge-clearcase.html#comment-8055 My software project is considering using Araxis Merge in place of ClearCase's default merge utility. The project involves two separate streams each with their own snapshot views. In one stream (stream A) files have been moved to different locations within the stream’s view (view A) without modifying their content. In the other stream (stream B) the files’ content has been modified but their location remains the same. If our project used the merge utility included with ClearCase, when merging stream B to stream A, the merge utility would be aware of the new location in stream A for files common to both streams. It would merge modified files from stream B to their correct location in stream A. My question is if we use Araxis Merge, will this same behavior occur? We don’t want to end up with duplicate files, where one file contains updated content at an old location for a file and the location where the file should have ended up being merged to contains old content. I hope this is clear and that someone can clarify their experience in this matter. My software project is considering using Araxis Merge in place of ClearCase’s default merge utility. The project involves two separate streams each with their own snapshot views. In one stream (stream A) files have been moved to different locations within the stream’s view (view A) without modifying their content. In the other stream (stream B) the files’ content has been modified but their location remains the same.

If our project used the merge utility included with ClearCase, when merging stream B to stream A, the merge utility would be aware of the new location in stream A for files common to both streams. It would merge modified files from stream B to their correct location in stream A.

My question is if we use Araxis Merge, will this same behavior occur? We don’t want to end up with duplicate files, where one file contains updated content at an old location for a file and the location where the file should have ended up being merged to contains old content.

I hope this is clear and that someone can clarify their experience in this matter.

]]> Comment on Polonization of PRS-500 - spolszczenie PRS-500 by Mikolaj http://blog.swidzinski.com/2007/04/30/polonization-of-prs-500-spolszczenie-prs-500.html#comment-7768 Thu, 28 Aug 2008 20:55:53 +0000 http://blog.swidzinski.com/2007/04/30/polonization-of-prs-500-spolszczenie-prs-500.html#comment-7768 Otóź to co piszesz to nie całkiem prawda. Są nie tylko dwie metody uzyskania polskich liter - prócz Universal Flashera i "bezinwazyjnej" external fonts, jest metoda trzecia, również bezinwazyjna. Trochę o każdej z nich: a) flasher No cóż, nie będę ukrywał że ona mi najbardziej pasuje - flashowałem prs-500 i prs-505 (choć ten drugi z duszą na ramieniu) i jakoś działają. Z flashowaniem zawsze związane jest ryzyko "scegłowania readera", czyli wyrządzenia jakiejś nieodwracalnej szkody. Zwykle jeśli wgrany firmware nie działa, możliwe jest wrzucenie oficjalnego firmware i problem z głowy. Oczywiście zwykle nie znaczy zawsze :-), więc pewne inherentne ryzyko istnieje. W przypadku prs-505 do tego zwykłego ryzyka, przez długi czas dochodziło drugie, wynikające z braku oficjalnego firmware - to skutecznie ograniczało możliwośc powrotu do dobrego firmware. Sam przez długi czas się wstrzymywałem z kupnem prs-505, właśnie z tego powodu. W końcu i tak pękłem, kupiłem i zaryzykowałem - komentarze na mobileread.com były zachęcające - podmiana firmware przebiegła bezproblemowo. Teraz do miesiąca jest nowy oficjalny firmware, więc to drugie zagrożenie praktycznie znikło. Rzecz jasna, każdy sam musi ocenić czy stare "zwykłe" ryzyko mieści się w jego granicach komfortu psychicznego :-). Gwoli ścisłości, tu jest najnowsza wersja flashera: http://www.mobileread.com/forums/showthread.php?t=26831 W wątku jest image z cyrylicą, który zawiera też polskie litery. b) external fonts (podejrzewam że to się nie kwalifikuje do kategorii "dla laika") Wyobaźmy sobie że kiedyś jednak zdecydujemy się na zmiane firmware, albo może kiedyś zdarzy się cud i Sony wypuści reader z polskimi czcionkami. Bez sensu te same pliki znowu konwertować, najlepiej byłoby wyciąć external fonts z pliku lrf. Jak to zrobić: 0. Przede wszystkim przygotować się zawczasu. I podczas konwersji w bookdesignerze, NIE wybrać przypadkiem poniższej opcji, każdy inny header jest OK, title+author jest DEFINITYWNIE OUT: <img src="http://blog.swidzinski.com/images/bookdesigner.png" alt="title+author" /> 1. Zaopatrzyć się w kilka narzędzi: LRS to LRF converter (http://www.msh-tools.com/ebook/downloads.html) lrf2lrs (http://www.mobileread.com/forums/showthread.php?t=8788) (i pythona, lrf2lrs jest w pythonie) jedit (http://jedit.org), Trzeba w opcjach ustawić UTF-16LE, jak mnie pamięć nie myli w dwóch miejscach - global i buffer options. 2. Bierzemy nasz plik i zamieniamy z powrotem na lrs (lrs to format pośredni, z którego jest generowany lrf) >lrf2lrs.py naszplik.lrf Opisany w 0) header=title+author powoduje błąd w lrf2lrs, łatwiej go unikać vide 0), niż potem dłubać przy lrf2lrs.py, szczególnie że program nie cierpi na nadmiar komentarzy... 3. OK, więc lrf2lrs wypluł plik lrs, thumbnail, może jakieś obrazki czy fonty. 4. Otwieramy naszplik.lrs w jedit i szukamy nazwy naszych czcionek. Są dwa miejsca gdzie je znajdziemy: tag RegistFont, gdzie jest deklaracja czcionki oraz w tagi TextStyle. 5. Wywalamy tagi RegistFont, a w TextStyle podmieniamy fontfacename na nazwy wbudowanych czcionek (czyli Dutch801 Rm BT Roman,Swis721 BT Roman, bądź Courier 10 BT Roman czy Courier 10 Pitch Win95BT jeśli używamy radzieckiego image) 6. Jeszcze musimy trochę plik wyczyścić i podmienić wszystkie html entities na odpowiadające im znaki (vide http://htmlhelp.com/reference/html40/entities/ ) 7. Konwertujemy z powrotem na lrf. W porównaniu z tym ile trwało eksperymentowanie z edytorami, które w nieoczekiwany sposób obsługują UTF-16LE, ta procedura to pryszcz :-) c) Zostawiłem na deser. Czcionki można podmienić bez zmiany firmware: http://www.mobileread.com/forums/showthread.php?t=20644 Nie próbowałem - Never touch a running system! :-P Otóź to co piszesz to nie całkiem prawda. Są nie tylko dwie metody uzyskania polskich liter - prócz Universal Flashera i “bezinwazyjnej” external fonts, jest metoda trzecia, również bezinwazyjna. Trochę o każdej z nich:

a) flasher
No cóż, nie będę ukrywał że ona mi najbardziej pasuje - flashowałem prs-500 i prs-505 (choć ten drugi z duszą na ramieniu) i jakoś działają.
Z flashowaniem zawsze związane jest ryzyko “scegłowania readera”, czyli wyrządzenia jakiejś nieodwracalnej szkody. Zwykle jeśli wgrany firmware nie działa, możliwe jest wrzucenie oficjalnego firmware i problem z głowy. Oczywiście zwykle nie znaczy zawsze :-), więc pewne inherentne ryzyko istnieje. W przypadku prs-505 do tego zwykłego ryzyka, przez długi czas dochodziło drugie, wynikające z braku oficjalnego firmware - to skutecznie ograniczało możliwośc powrotu do dobrego firmware. Sam przez długi czas się wstrzymywałem z kupnem prs-505, właśnie z tego powodu. W końcu i tak pękłem, kupiłem i zaryzykowałem - komentarze na mobileread.com były zachęcające - podmiana firmware przebiegła bezproblemowo. Teraz do miesiąca jest nowy oficjalny firmware, więc to drugie zagrożenie praktycznie znikło. Rzecz jasna, każdy sam musi ocenić czy stare “zwykłe” ryzyko mieści się w jego granicach komfortu psychicznego :-).
Gwoli ścisłości, tu jest najnowsza wersja flashera:
http://www.mobileread.com/forums/showthread.php?t=26831
W wątku jest image z cyrylicą, który zawiera też polskie litery.
b) external fonts (podejrzewam że to się nie kwalifikuje do kategorii “dla laika”)
Wyobaźmy sobie że kiedyś jednak zdecydujemy się na zmiane firmware, albo może kiedyś zdarzy się cud i Sony wypuści reader z polskimi czcionkami.
Bez sensu te same pliki znowu konwertować, najlepiej byłoby wyciąć external fonts z pliku lrf. Jak to zrobić:
0. Przede wszystkim przygotować się zawczasu. I podczas konwersji w bookdesignerze, NIE wybrać przypadkiem poniższej opcji, każdy inny header jest OK, title+author jest DEFINITYWNIE OUT:
title+author
1. Zaopatrzyć się w kilka narzędzi:
LRS to LRF converter (http://www.msh-tools.com/ebook/downloads.html)
lrf2lrs (http://www.mobileread.com/forums/showthread.php?t=8788) (i pythona, lrf2lrs jest w pythonie)
jedit (http://jedit.org), Trzeba w opcjach ustawić UTF-16LE, jak mnie pamięć nie myli w dwóch miejscach - global i buffer options.
2. Bierzemy nasz plik i zamieniamy z powrotem na lrs (lrs to format pośredni, z którego jest generowany lrf) >lrf2lrs.py naszplik.lrf
Opisany w 0) header=title+author powoduje błąd w lrf2lrs, łatwiej go unikać vide 0), niż potem dłubać przy lrf2lrs.py, szczególnie że program nie cierpi na nadmiar komentarzy…
3. OK, więc lrf2lrs wypluł plik lrs, thumbnail, może jakieś obrazki czy fonty.
4. Otwieramy naszplik.lrs w jedit i szukamy nazwy naszych czcionek. Są dwa miejsca gdzie je znajdziemy:
tag RegistFont, gdzie jest deklaracja czcionki oraz w tagi TextStyle.
5. Wywalamy tagi RegistFont, a w TextStyle podmieniamy fontfacename na nazwy wbudowanych czcionek (czyli Dutch801 Rm BT Roman,Swis721 BT Roman, bądź Courier 10 BT Roman czy Courier 10 Pitch Win95BT jeśli używamy radzieckiego image)
6. Jeszcze musimy trochę plik wyczyścić i podmienić wszystkie html entities na odpowiadające im znaki (vide http://htmlhelp.com/reference/html40/entities/ )
7. Konwertujemy z powrotem na lrf.
W porównaniu z tym ile trwało eksperymentowanie z edytorami, które w nieoczekiwany sposób obsługują UTF-16LE, ta procedura to pryszcz :-)

c) Zostawiłem na deser. Czcionki można podmienić bez zmiany firmware: http://www.mobileread.com/forums/showthread.php?t=20644
Nie próbowałem - Never touch a running system! :-P

]]>