Quoteing matz@ruby-lang.org, on Thu, Dec 04, 2003 at 02:56:07PM +0900:
Is it a “feature”, then?
If so, may I ask why?
It’s just because I haven’t decided how to dump File::Stat object.
OK, I begin to understand.
You can’t just write all the fields when marshalling?
#<File::Stat dev=234881029, ino=1357757, mode=17407, nlink=10, uid=0,
gid=0, rdev=0, size=340, blksize=4096, blocks=0, atime=Sat Dec 06
08:56:41 EST 2003, mtime=Sat Dec 06 11:57:09 EST 2003, ctime=Sat Dec
06 11:57:09 EST 2003>
Maybe the answer is that File::Stat looks different on other systems?
Even if I save all these fields, File::Stat doesn’t have a constructor I
can use, so I have no way to make a File::Stat out of information I
save!
Can I create, somehow, an initializer like:
File::Stat.new2(dev,ino,mode,nlink,uid,gid,rdev,size,… etc…)?
I want a File::Stat, because it has many useful methods, and I have
had to write them myself since I wrote my own equivalent class that
can be written to disk.
Or, if I don’t need portable, could I extend File::Stat to support being
marshalled? Would that be a ‘back door’ way that would allow me to
create one?
I don’t understand why a files stat would be unmarshable, even in
C I could write a stat_t to file.
But you don’t do it in C for portability, do you?
Yes, but I don’t need portability. I am doing it in Ruby because of
speed of prototyping, the plan was to rewrite it in C later, using dbm
to store struct_t’s, if ruby is too slow. So far, ruby is fast enough,
but development was less trivial than expected because of this
difficulty.
Thanks,
Sam
···
In message “Re: bug? ruby -e 's=File.stat(”/“);Marshal.dump(s);'” > on 03/12/04, Sam Roberts sroberts@uniserve.com writes: