From: Sam Roberts <sroberts@...>
Date: 2003-12-07T02:12:45+09:00
Subject: Re: bug? ruby -e 's=File.stat("/");Marshal.dump(s);'

Quoteing matz@ruby-lang.org, on Thu, Dec 04, 2003 at 02:56:07PM +0900:
> In message "Re: bug? ruby -e 's=File.stat("/");Marshal.dump(s);'"
>     on 03/12/04, Sam Roberts <sroberts@uniserve.com> writes:
> |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