[PROPOSAL] C<stat> opcode and interface
Leopold Toetsch
1) ops
stat (out PMC, in STR, in INT)
stat (out PMC, in PMC, in INT)
Return a new array-like[1] PMC $1 with file stats from file (PIO or
string) $2,
or PerlUndef, if file doesn't exist, $3 are flags:
.PARROT_STAT_NO_FOLLOW_LINK
The array(-like) has keyed access with these keys
.PARROT_STAT_FILE_SIZE
.PARROT_STAT_FILE_SIZE_LO
.PARROT_STAT_FILE_SIZE_HI
.PARROT_STAT_MODE a bitmask with these bits:
.PARROT_STAT_MODE_ISDIR
.PARROT_STAT_MODE_ISFILE
[ more platform-unspecific bits ]
.PARROT_STAT_PERM a bitmask with these bits
.PARROT_STAT_PERM_IS_READABLE
.PARROT_STAT_PERM_IS_WRITABLE
.PARROT_STAT_PERM_IS_EXECUTABLE
.PARROT_STAT_MTIME modified time
.PARROT_STAT_OS_TYPE a constant defining the os-specific
part that follows
.PARROT_STAT_stat
.PARROT_STAT_stat64
...
.PARROT_STAT_OS_SPECIFIC
A (Un)?ManagedStruct PMC with OS-specific data like a
struct stat64
2) Interface
PMC* Parrot_stat_s(Interp*, STRING* file, INTVAL flags);
PMC* Parrot_stat_p(Interp*, PMC* pio, INTVAL flags);
3) Interface to platforms
INTVAL Parrot_stat_os_s(Interp*, Parrot_stat*, STRING* file, INTVAL
flags);
INTVAL Parrot_stat_os_p(Interp*, Parrot_stat*, PMC* pio, INTVAL
flags);
typedef struct _parrot_stat {
size64_t size;
UINTVAL mode;
UINTVAL perm;
FLOATVAL mtime; // in Parrot units
UINTVAL os_stat_type;
union {
struct stat;
struct stat64;
...
} u;
} Parrot_stat;
4) Notes
The information in the first few fields should not be platform
specific. If platforms have more in common then above bits, the
structure should be expanded.
[1] it needs just these vtables implemeted: I0 = P0[i], N0 = P0[i],
i.e. get_{integer,number}_keyed_int
Comments, improvements, and implementations thereafter welcome
leo
Dan Sugalski
>Proposal C<stat> opcode and interface
While we need to do this, what you've got here's far too
platform-specific. From long, hard, unpleasant experience I can
guarantee that starting with a Unix view of this is going to generate
vast amounts of pain in the future. :(
Before we dig into the implementation maybe we better take a bit to
work out the information we want. From memory, I can think of:
*) File size
*) Permissions (read, write, execute, delete, enter (for dirs))
and that's for owner, group, everyone, and root
*) Times (create, modify, access)
*) ACL information (All horribly platform and filesystem specific IIRC)
*) Information (file, dir, softlink, hardlink, block dev, char dev,
socket, named pipe, semaphore)
*) user & group of file
*) File version (And not just for VMS -- my OS X manpages list this)
Some of this information will have to be synthesized on every
platform, but with a few exceptions (times, mainly) it's all doable.
If there's anything else that needs adding to this list, well, we
should do it now.
As you've probably noted I'd rather not re-implement and expose 35
years worth of "Whoops, that turned out to be a bad idea" crud.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Josh Wilmes
would like to remind folks about miniparrot- if we want it to work again,
there needs to be a smooth way to exclude opcodes or PMCs which are
not expecially portable on its platform (pure c89, no threads, etc).
This means one or more of the following will need to be done:
- all non-c89 code in config/gen/platform
- extra flag in the .ops files to identify ops to be excluded
- extra file to list explicitly which ops should be INcluded in
miniparrot, with all others left out.
- more #ifdef MINIPARROTs.
Personally i'm leaning towards the third option, but I think we should be
clear what the policy is with regard to config/gen/platform and functions
which aren't part of standard C (but which are available on most
platforms).
It's also quite possible that miniparrot is a waste of time. I'm pretty
much of the opinion myself that it's an academic exercise at this point,
but one which keeps us honest, even if we don't use it.
--Josh
--Josh
Brent "Dax" Royal-Gordon
> It's also quite possible that miniparrot is a waste of time. I'm pretty
> much of the opinion myself that it's an academic exercise at this point,
> but one which keeps us honest, even if we don't use it.
Miniparrot, or something very much like it, is the final build system.
--
Brent "Dax" Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
[Ugh.]
Dan Sugalski
>Josh Wilmes wrote:
>>It's also quite possible that miniparrot is a waste of time. I'm
>>pretty much of the opinion myself that it's an academic exercise at
>>this point, but one which keeps us honest, even if we don't use it.
>
>Miniparrot, or something very much like it, is the final build system.
Yep. We need to make sure it always works.
Which, unfortunately, will end up making things a hassle, since
there's no platform-independent way to spawn a sub-process, dammit. :(
Brent "Dax" Royal-Gordon
> Which, unfortunately, will end up making things a hassle, since there's
> no platform-independent way to spawn a sub-process, dammit. :(
Unixen seem to support system(). So does Windows. I suspect that most
OSes we want to run on have something pretty equivalent, even if it
doesn't have the exact same name. (Except for Palms, but Palms are
always cross-compiled to. Although I *did* see one C compiler that ran
on the Palm...)
I think that, in this particular area, it's okay to introduce a bit of
platform dependence into Miniparrot via #ifdefs. It's a critically
important function for Miniparrot to do its job, and if we're careful
about what programs we call and what sort of I/O redirections we try to
use, the portability concerns aren't too daunting.
Remember, the real thing won't be using 'perl -e', so quoting constructs
may not even come into play.
The plan was always *three*-step:
platform specific shell script -> miniparrot -> full parrot
The shell scripts (or batch files, or...) in the first steps can pass a
couple extra -Ds to Miniparrot if they're really necessary.
Dan Sugalski
>It's also quite possible that miniparrot is a waste of time. I'm pretty
>much of the opinion myself that it's an academic exercise at this point,
>but one which keeps us honest, even if we don't use it.
Nope, not a waste of time at all. It is part of the big plan, and as
such is really, really important.
Dan Sugalski
>Dan Sugalski wrote:
>>Which, unfortunately, will end up making things a hassle, since
>>there's no platform-independent way to spawn a sub-process, dammit.
>>:(
>
>Unixen seem to support system().
D'oh! It's C89 standard. I'm getting stuck in the 80s with the
multitude of exec variants. Yeah, with that issue taken care of it's
a lot more doable. Nevermind...
Larry Wall
: *) Times (create, modify, access)
Just a reminder that ctime on Unix is not "create" time, but time of
last inode change. I wish there were a create time on Unix, but there
ain't.
Larry
Dan Sugalski
Yup, that I know. Other, less broken filesystems have real create
times for files. :-P
I don't expect access time to be available for most files either,
even on systems that support it, because of the pretty massive
overhead it tends to incur. Still, it's there to be had in many
cases, so...
Nick Ing-Simmons
>At 10:11 AM -0800 3/10/04, Brent \"Dax\" Royal-Gordon wrote:
>>Josh Wilmes wrote:
>>>It's also quite possible that miniparrot is a waste of time. I'm
>>>pretty much of the opinion myself that it's an academic exercise at
>>>this point, but one which keeps us honest, even if we don't use it.
>>
>>Miniparrot, or something very much like it, is the final build system.
>
>Yep. We need to make sure it always works.
>
>Which, unfortunately, will end up making things a hassle, since
>there's no platform-independent way to spawn a sub-process, dammit. :(
On that topic specifically - the DOS style spawn() API is
easy to fake with fork/exec but converse is NOT true.
i.e. if Miniparrot assumes:
pid_t my_spawn(const char *progname,int argc,const char *argv[]);
int my_wait(pid_t proc);
then Unix-oids can have
pid_t my_spawn(const char *progname,int argc,const char *argv[]);
{
pid_t pid = fork();
if (pid)
return pid;
execv(progname,argc,argv);
}
Unidirectional popen() is also reasonably portable.
Nick Ing-Simmons
>At 11:12 AM -0800 3/10/04, Brent \"Dax\" Royal-Gordon wrote:
>>Dan Sugalski wrote:
>>>Which, unfortunately, will end up making things a hassle, since
>>>there's no platform-independent way to spawn a sub-process, dammit.
>>>:(
>>
>>Unixen seem to support system().
>
>D'oh! It's C89 standard. I'm getting stuck in the 80s with the
>multitude of exec variants. Yeah, with that issue taken care of it's
>a lot more doable. Nevermind...
But:
A. system() is blocking.
B. system() takes single string so whatever calls system()
has to be aware of the System's quoting rules.
Dan Sugalski
A is no problem -- for this, blocking is fine.
B is more of a problem to be sure, but if we're really careful I
think we'll be OK. Most of the uses of system for miniparrot are all
simple spawns of the C compiler, so there shouldn't be any quoting
going on.