p4w-pathdev Mailing List for p4w - Powertools 4 Wisehackers
Status: Pre-Alpha
Brought to you by:
earnie
Menu
▾
▴
p4w-pathdev — Developer Collaboration for p4wPath
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(19) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: steve h. <st...@ho...> - 2003-08-17 12:31:55
|
Put a slightly cleaned up version at same url . http://www.houseman.demon.co.uk/p4wfs.tar.gz Has a changelog to indicate the few differences. Cheers, Steve Houseman -- currently : | for strace, an annotator see - steve at houseman demon co uk | http://www.houseman.demon.co.uk/ |
|
From: steve h. <st...@ho...> - 2003-08-15 13:16:51
|
On Fri, 15 Aug 2003, Earnie Boyd wrote: > > > > http://www.houseman.demon.co.uk/p4wfs.tgz > > > > Please rename the file to .tar.gz. Mozilla is thinking text mode for .tgz. > Done . Cheers, Steve Houseman -- currently : | for strace, an annotator see - steve at houseman demon co uk | http://www.houseman.demon.co.uk/ |
|
From: Earnie B. <ear...@ya...> - 2003-08-15 12:39:42
|
steve houseman wrote: > > http://www.houseman.demon.co.uk/p4wfs.tgz > Please rename the file to .tar.gz. Mozilla is thinking text mode for .tgz. Thanks, Earnie. |
|
From: steve h. <st...@ho...> - 2003-08-14 21:35:41
|
On Sun, 10 Aug 2003, Earnie Boyd wrote: > Ok. I'm vacation for a couple of weeks anyway. > > Earnie. > > steve houseman wrote: > > have put some better test stuff in and has revealed some bugs > > so probably better to leave a few days ... will post when > > is in better shape. > > > > Cheers, > > > > Steve Houseman > > > there's another cleaner version up now , still same url http://www.houseman.demon.co.uk/p4wfs.tgz will work on it some more but maybe you can take a look when you're back off vac ... happy hols :-) Cheers, Steve Houseman -- currently : | for strace, an annotator see - steve at houseman demon co uk | http://www.houseman.demon.co.uk/ |
|
From: Earnie B. <ear...@ya...> - 2003-08-10 18:15:15
|
Ok. I'm vacation for a couple of weeks anyway. Earnie. steve houseman wrote: > have put some better test stuff in and has revealed some bugs > so probably better to leave a few days ... will post when > is in better shape. > > Cheers, > > Steve Houseman > |
|
From: steve h. <st...@ho...> - 2003-08-10 12:16:57
|
have put some better test stuff in and has revealed some bugs so probably better to leave a few days ... will post when is in better shape. Cheers, Steve Houseman -- currently : | for strace, an annotator see - steve at houseman demon co uk | http://www.houseman.demon.co.uk/ |
|
From: steve h. <st...@ho...> - 2003-08-09 18:50:13
|
forgot to say that the msys root is hardcoded , search for getMingwRoot and adjust. Cheers, Steve Houseman -- currently : | for strace, an annotator see - steve at houseman demon co uk | http://www.houseman.demon.co.uk/ |
|
From: steve h. <st...@ho...> - 2003-08-09 18:38:46
|
Hello all, http://www.houseman.demon.co.uk/p4wfs.tgz You might want to take a look at this. There are some notes with it in the status file. I'll continue working on it as is . As I say in the notes, I'm hoping to get the rough edges removed and get it to a first pass usable form soon so I can get back to my main proj :-) . Cheers, Steve Houseman -- currently : | for strace, an annotator see - steve at houseman demon co uk | http://www.houseman.demon.co.uk/ |
|
From: Earnie B. <ear...@ya...> - 2003-08-09 11:27:13
|
steve houseman wrote:
> On Fri, 8 Aug 2003, Earnie Boyd wrote:
>
>
> A bit of research on the namspace idea makes that look ok.
> The names ? p4w is ok , fs ... is it a filesystem or a path conversion
> library or is that ultimately the same thing ?
> I dont feel strongly about it ... so whatever you think.
>
Paths are objects of a filesystem. Therefore IAOTO that methods that
operate on the filesystem should be identified as such. But, it may be
much too much. For now though let's assume that we will want to.
namespace p4w {
namespace fs {
...
}
}
Earnie.
|
|
From: steve h. <st...@ho...> - 2003-08-09 10:33:27
|
On Fri, 8 Aug 2003, Earnie Boyd wrote:
> For this effort I would like to consider the namespace name. I'm think
> that a namespace of ``fs'' for file system should be used. Too further
> clarify the namespace the ``fs'' namespace could reside in a ``p4w''
> namespace. So the classes would reside in
>
> namespace p4w {
> namespace fs {
> ...
> }
> }
>
> Comments?
>
> Earnie.
>
A bit of research on the namspace idea makes that look ok.
The names ? p4w is ok , fs ... is it a filesystem or a path conversion
library or is that ultimately the same thing ?
I dont feel strongly about it ... so whatever you think.
Cheers,
Steve Houseman
--
currently : | for strace, an annotator see -
steve at houseman demon co uk | http://www.houseman.demon.co.uk/
|
|
From: Earnie B. <ear...@ya...> - 2003-08-08 18:46:29
|
<file name="mount.h" type="partial header">
using std::string;
class mount_table {
public:
void init();
bool add (string posix, string win32);
mount_record *begin ();
mount_record *next ();
mount_record *current ();
mount_record *previous ();
mount_record *end ();
short getmountcnt () {return mountcnt;};
short getmountidx () {return mountidx;};
private:
mount_record **mounted;
short mountidx;
short mountcnt;
const short maxmountcnt = 256;
string rootpath;
}
</file>
|
|
From: Earnie B. <ear...@ya...> - 2003-08-08 18:32:02
|
<file name="mount.h" type="partial header">
using std::string;
class mount_record {
public:
string posix;
string win32;
};
</file>
Yea, I know this could be a struct, but I choose to only use class.
Earnie.
|
|
From: Earnie B. <ear...@ya...> - 2003-08-08 18:10:36
|
For this effort I would like to consider the namespace name. I'm think
that a namespace of ``fs'' for file system should be used. Too further
clarify the namespace the ``fs'' namespace could reside in a ``p4w''
namespace. So the classes would reside in
namespace p4w {
namespace fs {
...
}
}
Comments?
Earnie.
|
|
From: Earnie B. <ear...@ya...> - 2003-08-07 20:26:34
|
steve houseman wrote: > Hello all, > > I have the start of a path conversion lib, but there is a question > of uppercase vs lower case and what to do about it. > Using windows' _getcwd on my c drive returns C:\MSYS\1.0\BIN > and the e drive which is mounted from samba on my other > (linux) box) comes out as e:\src\whatever > The explorer shows the c path as C:\msys\1.0\bin > ie as I would expect. > is there someway to ensure the "correct" case'd path is > returned (for getcwd). > How about GetCurrentDirectory ()? I wouldn't worry too much with case other than in comparison and making sure the user get's back what is given by them. > I have written an unmangler using the _findfirst and friends, > but it seems a cumbersome way to get the real path? > I guess that the normal usage of getcwd is quite rare > (often only once per process?) so maybe it isnt such a problem . > I'm not sure what you're after. > Also, for threads, is a chdir process wide ie do all threads > have the same cwd or do they each have their own? > Hmm... If a thread does a chdir should it affect other threads that have done the same? Earnie. P.S.: I still owe an email on what I have already. Perhaps this weekend. |
|
From: steve h. <st...@ho...> - 2003-08-07 14:10:04
|
Hello all, I have the start of a path conversion lib, but there is a question of uppercase vs lower case and what to do about it. Using windows' _getcwd on my c drive returns C:\MSYS\1.0\BIN and the e drive which is mounted from samba on my other (linux) box) comes out as e:\src\whatever The explorer shows the c path as C:\msys\1.0\bin ie as I would expect. is there someway to ensure the "correct" case'd path is returned (for getcwd). I have written an unmangler using the _findfirst and friends, but it seems a cumbersome way to get the real path? I guess that the normal usage of getcwd is quite rare (often only once per process?) so maybe it isnt such a problem . Also, for threads, is a chdir process wide ie do all threads have the same cwd or do they each have their own? Cheers, Steve Houseman -- currently : | for strace, an annotator see - steve at houseman demon co uk | http://www.houseman.demon.co.uk/ |
|
From: Earnie B. <ear...@ya...> - 2003-08-04 14:33:28
|
Earnie Boyd wrote: > > > -------- Original Message -------- > Subject: Re: Would you be willing to work on a pathing library? > Date: Sun, 3 Aug 2003 19:36:29 +0100 (BST) > From: steve houseman <st...@ho...> > Reply-To: <st...@ho...> > To: Earnie Boyd <ear...@ya...> > > Hello Earnie, > > Hoping this doesnt cross over with any mail from you > and cause confusion .... I have spent the day thinking about > aspects of a system to convert a mingw unix path to the dos path > so I'm afraid there are more ramblinge enclosed. > > I have had a look at the holding of the info for each unix path.... > I assume the primary use would be the mapping of the unix paths > to their windows equivalent based on the /etc/fstab data? Yes. The / directory would be determined based on the location of the executing binary of if we produce a dll, then the location of that dll. The /bin location maps to the location of the executable or dll. The / location is the parent directory of /bin. And the /usr location maps to the the parent directory of /bin. All other mappings are based on /etc/fstab. > Maybe I guess doing the inverse conversion ? > I've contemplated this even before you've mentioned it. I'm certainly open to including it, but have yet to find a reason to do so. > My mind keeps turning to the idea of a hashtable but that is of zero > use for this appn .... I have roughed out (and coded roughly) a system > based on the directory hierarchy where all sub dirs are held together > in a set and and each sub dir holds its sub dirs etc etc. > I have my own version of the java util.Vector class which just holds > the data in an internal array and basically has m principal api of > int numElements() ; to allow iterations thru them > void * elementAt(ix); > void addElement(void * object); > > I havent implemented a binary chop search thru the sub dirs , it does > not seem to be worth while as the number of mount point would normally > be quite low and rarely exceed say 20 ?? > Also when I have implemented these in the past, there seems to be > a large ovehead which is ok if there are commonly sets of say 20 > or more items but doesnt seem to be worthwhile for say 3 or 4 > which seem to be the more likely scenario ... or are you thinking of > a more general purpos lib ? > Dont let this pre-empt you from making other suggestions . > Certainly we want this. The number of hits for just one path in our library will be tremendously unbelievable. I know based on tracing code in MSYS. I'm not certain how big the hash table should be, 20 sounds good, but we should experiment. Version 1.1 of MSYS will have the ability to have non-MSYS programs in /bin so finding /etc as it relates to MSYS becomes easier. This also allows us to hash /bin seperately for greater effectivness. > The other aspects are > - the reading and parsing of the /etc/fstab file (and knowing > where the msys root is in dos terms ... this must be part of > your normal startup stuff) ... I guess this code is already > lurking in the msys code source ? > Yes, but would not be directly copyable. > - the detection of the type of path given win vs unix and abs vs > relative. The path structure is such that the mount points are sorted via the length of the posix string descending order. Such that a mount point of /foo/bar/baz is found before a mount point of /foo/bar. Relative paths as it relates to the CWD, e.g. foo/bar, need not be converted. Relative paths containing ../ may need to be converted, especially if the drive changes in some way. Perhaps a /c/../d/ (simplistic) pattern is what I have in mind. > and conversion of the given path into an abspath with removal > of the /./ and /../ path frags . > so that have a clean abspath ... of which only the unix type needs > to be processed... by that I mean that if is a win path, then can > be passed to windows directly ... does this code already exist? Yes, but we want to be careful as it may be GPL, something I want to avoid. The /./ and /../ should be usable to a win path, as long as we don't cross drive boundaries. I'm thinking though that we want to retain the user path, a converted win32 path with relativness, an absolute win32 path and an absolute posix path. > One problem is whether a '\' in a supposedly unix path would consitute > an error ... > I typically convert to '/' and then before spawning, convert to '\'. The environment strings are a sticky wicket. The [GS]etEnvironmentString Win32 API functions are not the same as the getenv/putenv MSVCRT functions. :p > - handling of errors .... for debugging this would probably be worth > while have an env var maybe ...MINGW_PATH_CONVERSION_DEBUG which > could have say several values eg zero or not dsefined would > generate nothing, > 1 -> reports errors to say a home dir or the current dir in say > .mingwpathconversion.log or whatever . > 2 -> reports errors and warnings > 3 -> reports everything , for full debugging > We can develop this as we go. I'm thinking there is even code we can use already. > - library aspects ... I have never done any development for libraries > only standalone apps , so there are likely to be some flaws in my > thinking on what I can do ... frinst is there any problem initialising > data structures , and per thread ? probably a lot more will occur to > me and maybe some will bite me later . > Is C++ ok or does it need to be C ? > C++ is prefered with C bindings for the user API interface. This will allow us to use some advanced features of the STL. > - using buffers to process the data in , buffers on the stack seem > like the quickest way (ie not maloc'd) but I dont know how long > the max path length value is in reality and/or whether could impose > a shorter restriction with mingw eg 256 . > MAX_PATH is one less on W9x. :p So we set it to 255. There are ways around this limit in newer versions of the OS, but nothing we want to handle on an initial go round. > - how to implement ... whether to have a header to include or env vars > and should it be by #defining say open(..) > to mingw_open which in turn calls the real open , or is there > something better ... sdl has some system for defining sdl_main > and redefining it to be main ... I didnt understand it and I didnt > need to :-) ... but I could take a look. > This is something that we want to take a close look at. I'm mixed, replacement functions sound nifty but MACRO wrappers to the existing functions may be best. > - and the listing of all fns to be handled (I gave a partial set > in my last email) > > Anyway enough of my ramblings ... let me know what you have in mind etc . > Let's worry with creating the necessary classes and methods first. I'll post some of what I've got in my next mail. Earnie. |
|
From: Earnie B. <ear...@ya...> - 2003-08-04 13:40:39
|
Earnie Boyd wrote: > > > -------- Original Message -------- > Subject: Re: Would you be willing to work on a pathing library? > Date: Sat, 2 Aug 2003 19:02:05 +0100 (BST) > From: steve houseman <st...@ho...> > Reply-To: <st...@ho...> > To: Earnie Boyd <ear...@ya...> > > > On Fri, 1 Aug 2003, Earnie Boyd wrote: > >> I've several ideas to implement this, but lack time to properly code it. >> You seem to have a grasp at what is needed or at least the current >> state of the way things work. Let me know if you're willing to at least >> look at this. >> >> Thanks, >> Earnie. >> > > Hello Earnie, > > I would be willing to look at a "pathing library" , I am hesitant to > make a large commitment but certainly I would be happy to take a look. > My main programming is C/C++ on linux and have done almost no windows > stuff ... strangely one bit I did was on a "FilePath" .cpp,.h > which was intended to take a path , strip out ./ , ../.. etc > and provide an api set like exists(), readable(), writable() > getDir(),getFileExt() etc ... so some of this might be re-usable. > > I have put together a list of possible fns that take paths > by looking thru the linux man pages and also apuie , but there > are going to be many that I have missed and also windows only > ones that I am not aware of . > I assume that unix domain sockets ie name pipes/fifos dont exist > so mknod and mkfifo would not be needed. > > so fns are ... > should be ok as are C vcalls (?) > open , creat , mkdir , stat , lstat , opendir , > rename, fopen , freopen , remove , > You're on the right track here. > not recommended tmpnam , mktemp , > mkstemp ... BSD 4.3 ? > unistd > access , rmdir , chdir , > link , unlink , symlink , readlink .. does windows have links ? > chroot , chown , lchown , .. does windows have these ? > returns a path ! .... > getcwd , > get_current_dir_name , getwd .. does windows have these ? > > dlopen vs LoadLibrary ? > spawn/execve > > plus probably many windows api calls ? > I hadn't thought about the Windows API calls. I don't think we need to be concerned for these though as they don't really pose a UNIX -> Win32 problem. > Probably would want to also provide something like : > int convertPath2dos(const char * upath, char * dospathbuffer, > int bsize); > and vv . > I don't think this is needed either. Unless you think we need to support just plain old DOS. > I guess the lib would be pure C to prevent name mangling ? > Actually, I was thinking C++ with C bindings. I'm not strong in C++ but we can get there. C++ affords us some niceties that will make the coding easier if we use the STL. Earnie. |
|
From: Earnie B. <ear...@ya...> - 2003-08-04 12:57:13
|
-------- Original Message --------
Subject: Re: Would you be willing to work on a pathing library?
Date: Sun, 3 Aug 2003 19:36:29 +0100 (BST)
From: steve houseman <st...@ho...>
Reply-To: <st...@ho...>
To: Earnie Boyd <ear...@ya...>
Hello Earnie,
Hoping this doesnt cross over with any mail from you
and cause confusion .... I have spent the day thinking about
aspects of a system to convert a mingw unix path to the dos path
so I'm afraid there are more ramblinge enclosed.
I have had a look at the holding of the info for each unix path....
I assume the primary use would be the mapping of the unix paths
to their windows equivalent based on the /etc/fstab data?
Maybe I guess doing the inverse conversion ?
My mind keeps turning to the idea of a hashtable but that is of zero
use for this appn .... I have roughed out (and coded roughly) a system
based on the directory hierarchy where all sub dirs are held together
in a set and and each sub dir holds its sub dirs etc etc.
I have my own version of the java util.Vector class which just holds
the data in an internal array and basically has m principal api of
int numElements() ; to allow iterations thru them
void * elementAt(ix);
void addElement(void * object);
I havent implemented a binary chop search thru the sub dirs , it does
not seem to be worth while as the number of mount point would normally
be quite low and rarely exceed say 20 ??
Also when I have implemented these in the past, there seems to be
a large ovehead which is ok if there are commonly sets of say 20
or more items but doesnt seem to be worthwhile for say 3 or 4
which seem to be the more likely scenario ... or are you thinking of
a more general purpos lib ?
Dont let this pre-empt you from making other suggestions .
The other aspects are
- the reading and parsing of the /etc/fstab file (and knowing
where the msys root is in dos terms ... this must be part of
your normal startup stuff) ... I guess this code is already
lurking in the msys code source ?
- the detection of the type of path given win vs unix and abs vs
relative.
and conversion of the given path into an abspath with removal
of the /./ and /../ path frags .
so that have a clean abspath ... of which only the unix type needs
to be processed... by that I mean that if is a win path, then can
be passed to windows directly ... does this code already exist?
One problem is whether a '\' in a supposedly unix path would consitute
an error ...
- handling of errors .... for debugging this would probably be worth
while have an env var maybe ...MINGW_PATH_CONVERSION_DEBUG which
could have say several values eg zero or not dsefined would
generate nothing,
1 -> reports errors to say a home dir or the current dir in say
.mingwpathconversion.log or whatever .
2 -> reports errors and warnings
3 -> reports everything , for full debugging
- library aspects ... I have never done any development for libraries
only standalone apps , so there are likely to be some flaws in my
thinking on what I can do ... frinst is there any problem initialising
data structures , and per thread ? probably a lot more will occur to
me and maybe some will bite me later .
Is C++ ok or does it need to be C ?
- using buffers to process the data in , buffers on the stack seem
like the quickest way (ie not maloc'd) but I dont know how long
the max path length value is in reality and/or whether could impose
a shorter restriction with mingw eg 256 .
- how to implement ... whether to have a header to include or env vars
and should it be by #defining say open(..)
to mingw_open which in turn calls the real open , or is there
something better ... sdl has some system for defining sdl_main
and redefining it to be main ... I didnt understand it and I didnt
need to :-) ... but I could take a look.
- and the listing of all fns to be handled (I gave a partial set
in my last email)
Anyway enough of my ramblings ... let me know what you have in mind etc .
Cheers,
Steve Houseman
--
currently : | for strace, an annotator see -
steve at houseman demon co uk | http://www.houseman.demon.co.uk/
|
|
From: Earnie B. <ear...@ya...> - 2003-08-04 12:56:38
|
-------- Original Message --------
Subject: Re: Would you be willing to work on a pathing library?
Date: Sat, 2 Aug 2003 19:02:05 +0100 (BST)
From: steve houseman <st...@ho...>
Reply-To: <st...@ho...>
To: Earnie Boyd <ear...@ya...>
On Fri, 1 Aug 2003, Earnie Boyd wrote:
> I've several ideas to implement this, but lack time to properly code it.
> You seem to have a grasp at what is needed or at least the current
> state of the way things work. Let me know if you're willing to at least
> look at this.
>
> Thanks,
> Earnie.
>
Hello Earnie,
I would be willing to look at a "pathing library" , I am hesitant to
make a large commitment but certainly I would be happy to take a look.
My main programming is C/C++ on linux and have done almost no windows
stuff ... strangely one bit I did was on a "FilePath" .cpp,.h
which was intended to take a path , strip out ./ , ../.. etc
and provide an api set like exists(), readable(), writable()
getDir(),getFileExt() etc ... so some of this might be re-usable.
I have put together a list of possible fns that take paths
by looking thru the linux man pages and also apuie , but there
are going to be many that I have missed and also windows only
ones that I am not aware of .
I assume that unix domain sockets ie name pipes/fifos dont exist
so mknod and mkfifo would not be needed.
so fns are ...
should be ok as are C vcalls (?)
open , creat , mkdir , stat , lstat , opendir ,
rename, fopen , freopen , remove ,
not recommended tmpnam , mktemp ,
mkstemp ... BSD 4.3 ?
unistd
access , rmdir , chdir ,
link , unlink , symlink , readlink .. does windows have links ?
chroot , chown , lchown , .. does windows have these ?
returns a path ! ....
getcwd ,
get_current_dir_name , getwd .. does windows have these ?
dlopen vs LoadLibrary ?
spawn/execve
plus probably many windows api calls ?
Probably would want to also provide something like :
int convertPath2dos(const char * upath, char * dospathbuffer,
int bsize);
and vv .
I guess the lib would be pure C to prevent name mangling ?
anyway enough of my ramblings .... let me know your ideas and how you
think it could/should be implemented etc .
Cheers,
Steve Houseman
--
currently : | for strace, an annotator see -
steve at houseman demon co uk | http://www.houseman.demon.co.uk/
|