[darcs-users] Linux in darcs: Repository not updated?

[Jan-Benedict Glaw]

On Fri, 2005-02-04 09:00:40 -0500, David Roundy <droundy at abridgegame.org>
wrote in message <20050204140033.GF5279 at abridgegame.org>:
> > > In case you're wondering, I've gone into this much detail partly because
> > > this looks like an area where you'd be particularly effective as a
> > > contributor...
> > 
> > Thanks:-)  As I said, just tell me what you'd like to see and I'll do it
> > for you. Though, I'll not yet touch Haskell code (maybe except the
> > really trivial things that seem obvious to me).
> 
> What I'd like to have is:
> 
> A wrapper on lstat that gives its output in a well-defined struct that I
> can read into haskell.  This doesn't need to read all the contents of
> lstat, but should read those things which are reasonably portable and that
> darcs uses.  This should be implemented for both windows and linux,
> although you don't need to do the windows implementation, since you don't
> have windows.  On the other hand, if you could scrounge some of the
> existing windows code, that would be great.
> 
> I'm imagining the output as something like (this is just a sketch)
> 
> struct darcs_stat {
>   u32 objtype; // file/directory/symlink/doesn't exist
>   u64 ctime;
>   u64 mtime;
>   u32 file_length; // or is this not returned by stat?
>   // I can't think what else at the moment.
> };
> 
> Perhaps just ints would be good, but we'd certainly have to be careful on
> these integer types to make sure I can line them up with the haskell code.

What should the u64 for times contain? Something like VMS? ...or a
time_t in the MSBs and usec/nsec in the LSBs?

> I'd also need a settimes call, and eventually would like to have a call to
> read a symlink's contents.

mtime, ctime and atime?

Reading a symlink's contents is reading the file name it points to?
Also, how do we want to handle this on Win32? IIRC, it'll create .lnk
files for it's "symlinks". Shall we internally just use the name without
the trailing .lnk? Or keep the suffix? From my memories, the windows VFS
API is a hugh mess...  Recording this suffix (and re-creating it
possibly again) will be a hugh mess if you replay the patch on a Un*x
system as well as on Windows...

> I think ideally I might want these calls to accept the file name as a char
> * to a non-null-terminated string together with a string length, since this
> would work best with darcs' internal format for strings (which isn't null
> terminated, so we can take substrings cheaply).

No problem with that. We'll then have to re-allocate for all file names
within the C part to get something \0 terminated.

> I'd also need a function to read the contents of a directory.  I'm not
> quite sure how best to return the results from this.  I'm thinking you
> could malloc an array of char, and then return the filenames as a
> null-terminated list? I'm not sure.  Returning variable-size arguments from
> C to haskell isn't as easy as fixed-size arguments.

Maybe something like a "directory handle" could be created to which the
Haskell code could refer to?

DIRHANDLE get_dir_contents (char *dirname, size_t dirnamelen);

...to be accessed by:
int get_number_of_dir_entries (DIRHANDLE handle);
struct darcs_stat * get_dir_entry (DIRHANDLE handle, int i);

(returning NULL for i outside bounds) and finished with

int put_dir_contents (DIRHANDLE handle);

With C code, this could be nicely used in a loop. Maybe Haskell can
access it like this, too, with DIRHANDLE basically being a pointer? In
Haskell, you'd be able to fill an own list with multiple calls to
get_dir_entry(), right?

> A "readfile" function might be nice, that would read a file into a buffer.

You don't want to do that :-)  Even right now, the memory footprint is
something that could proudly presented. (My understanding is that this
is more because of the way the compiler works, not generally because the
code is poorly designed.)

> This could come later, though, when I'm moving away from haskell IO.  Also,
> eventually, simple wrappers to output IO would be helpful, again when
> moving away from haskell IO.  These would allow me to avoid the cost of
> translations between haskell Strings (which are linked list of 32 bit
> unicode characters) and arrays of char.  Also in this category would be a

A linked list?! ...and in full-blown 32bit instead of something as sexy
as UTF-8? Wow, that a design decision 8^O

Is it 32bit unicode even on Windows? IIRC, all (newer) windows internal
APIs will use wchar_t, which is only 16bit on Windows.

However, on the long therm, there needs to be some decision about how to
use and store file names. IIRC, Windows offers a plain open() as well as
one that accepts 16bit wchar_t. Also, on eg. Linux, you can use UTF-8
encoded file names (or other encodings, as long as they don't contain \0
or '/').

On Linux, you may have '\\' in a filename, whereas on Windows you'll
face some trouble...

> new interface to zlib, which would eliminate the whole stupid thread and
> pipe business, and just run the threaded IO synchronously--and wouldn't try
> to treat the thread as a haskell Handle.  But again, this would only be
> used after I've got the haskell code reworked to avoid using Handles.

ACK :)  But I think the zlib code can be quite enhanced even without
doing much Haskell hacking.

> If someone else (a haskeller) were willing to come on board and be in
> charge of reworking the IO side of darcs, I'd definitely be willing to
> explain my ideas and let someone else work on this.  It's probably less
> than a month's work for me, but alas, that would mean not working on other
> stuff--such as the commutation problems, which are more severe.  I have a
> sketch of a class such as I'd need, but that's all.
> 
> In any case, the lstat and settimes wrappers could be put to use reasonably
> easily, so that's where you should start.

-- 
Jan-Benedict Glaw       jbglaw at lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20050204/451858fa/attachment.pgp