----- Original Message -----
From: "Yohanes Santoso" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, May 10, 2007 12:31 PM
Subject: Re: [id-ruby] "while" control menggunakan isi file
| "M. Ridho" <[EMAIL PROTECTED]> writes:
|
| > 1. betul sekali kalo filenya tidak ada, r+ akan throw exception.
| >
| > ruby -e "open('notexist', 'r+') {|f| puts f.read}" #=> *blank contents*
|
| Kalau begitu, kok malah blank content bukannya throw exception?
| maksudnya a+ kali ya (kamu copy-paste command yang salah).
yup, betul :-), salah paste kode, mestinya yang blank contents itu
read dengan mode a+.
|
|
| > again, it is totally right, some thing bizarre is happening here, may be
| > it is a kinda bug on ruby-freebsd.
| > ruby -e "open('sample', 'a+') {|f| puts f.read }" #=> **blank line**
|
| Jadinya di freebsd, a+ puts read pointer at EOF, bukan BOF. Setelah
| saya baca2x lagi dengan seksama C99 standard (p. 305, 7.19.5.3), point
| #5 dan #6, ternyata tidak dispecifikasikan initial state dari read
| pointer. Jadinya mungkin memang terserah implementation.
|
| Kalau begitu bukan bug di ruby-freebsd. Maaf atas informasi yang
| salah, padahal entah kenapa saya ingatnya begitu. Kalau mau pastikan,
| saya lampirkan C code yang buat baca file di a+ mode. Kalau memang di
| freebsd itu a+ mode menyebabkan read pointer pointing ke EOF, maka dia
| gak bakal baca apa2x. Kalau di linux:
|
| --------------------------------
| /tmp $ make read-append-mode
| cc read-append-mode.c -o read-append-mode
| /tmp $ ./read-append-mode
| Using temp file: /tmp/fileHAX1Hr
| Wrote |Testing| to test file
| Read from file: |Testing|
| --------------------------------
|
| Kalau di freebsd, last linenya mungkin seperti:
| Read from file: ||
|
attachment nya ketinggalan nih :-)
here is what man fopen says:
FOPEN(3) FreeBSD Library Functions Manual
FOPEN(3)
...
``r+'' Open for reading and writing. The stream is positioned at the
beginning of the file.
...
``a+'' Open for reading and writing. The file is created if it does
not
exist. The stream is positioned at the end of the file.
Subse-
quent writes to the file will always end up at the then current
end of file, irrespective of any intervening fseek(3) or
similar.
...
just skimming the man page, sepertinya dia tidak membedakan antara
read dan write pointer, there is only *stream positon* (--so it is why the
behavior
is like that i though).
|
| > ruby-yarv -e "open('sample', 'a+') {|f| puts f.read }" #=> TESTING
|
| Kalau benar freebsd buat read pointer ke EOF di a+ mode, artinya YARV
| reposition pointernya ke BOF. Ini kelakuan yang tidak patut.
|
hmm.. so it is yarv who is wrong here :-)
|
| > imo, snippet yang kemarin, behavior yang *betul* adalah yang win32,
|
| Hm?? Atas dasar apa automatic exclusive lock itu betul? Malahan saya
| sering sekali annoyed sama behaviour itu karena begitu
| artificial. Contohnya, MSWord selalu keep file open biarpun tidak ada
| yang belum di save. Selagi filenya open, gak bisa diattach ke Outlook
| atau bahkan di copy. Maksud sih baik supaya tidak ada process lain
| yang bisa buka file yang sama dan mungkin menyebabkan korupsi, tapi
| dalam praktek, kalau kamu mau attach filenya ke Outlook, Outlook tidak
| akan merubah2x isi file originalnya.
|
hehe, mungkin atas dasar ini supaya membahayakan bagi noobi :-),
asalkan syscall nya menyediakan cara bagaimana mem-bypass *automatic* lock,
rasanya lebih enak begini, save by default :-)
| > Sekarang jadi bingung kenapa freebsd tidak ada exclusive lock gitu
| > yah :D?
|
| Mendingan begitu, labih masuk akal. Tidak ada batasan artificial.
|
hmm, thats why people like unix or C, litle or no magic inside :-)
| > misalnya under freebsd, aggap saja rename itu atomic, apakah ini
| > berarti FileUtils.mv guaranted to be atomic
|
| Ingat, atomic atau tidak tergantung OS dan filesystem yang
| bersangkutan dan mungkin beberapa hal lainnya. Jadinya sama OS, tapi
| lain filesystem mungkin satu support atomic renaming, satu lagi tidak.
|
| > and hence, it is thread safe?
|
| Ini atomic di seluruh system, jadinya scopenya melebihi scope thread di
| process mana saja.
|
hmm.. sounds cool :D, jadi atomic and inter-process safe yah.
| Atau mungkin yang dimaksud adalah apakah FileUtils.mv itu thread-safe?
| Jawabannya ya. Tentu saja ini tidak berarti:
|
| Misalnya ada file "/tmp/foo" dan "/tmp2/bar":
| Thread.new { Dir.chdir("/tmp"); FileUtils.mv "foo" "foo2" }
| Thread.new { Dir.chdir("/tmp2"); FileUtils.mv "bar" "bar2" }
|
| akan digaransi selalu berhasil karena current directory (shared
| resource) dirobah tanpa ada synchronisation.
|
hmm.. got it, tapi menimbulkan pertanyaan berikut nya, --karena
konsep threading saya belum terlalu jauh, bukankah method2
yang perlu manual synchronization (e.g., mereka yang *harus* berada
dalam synchronize block atau yang semacemnya) itu berarti
atau disebut oleh orang sebagai *not thread safe* atau
*not multi-thread aware* ?
|
| YS.
|
Thanks for the lightening..
regards,
reedho.
