Greetings! Bill Page <[EMAIL PROTECTED]> writes:
> Camm Maguire wrote: > > >> (if (pathname-name (pathname fn)) > >> (with-open-file (q fn) (si::copy-stream q s)) > >> (dolist (l (directory fn)) (format s "~a~%" (namestring l))))) > >> > >>It would be nicer to make the result and the content type depend > >>on whether something was a directory or on the type of the file > >>etc instead of the syntax of the name, but I could not easily > >>discover how to do that in GCL. Specifically how can I tell a > >>directory from a file? Can anyone suggest a suitable "Getting > >>started in GCL" tutorial? > >> > > > >In lisp, the file system is accessed via a 'pathname' abstraction. > >Think of this a sa structure with several components, name, directory, > >type (e.g. suffix), device, even host and version if I recall. > >Directories have nil in the name and type fields. The sample code > >uses this to distinguish between them. > > > I guess the lisp code in the previous paragraph is intended to > distinquish between > directories and files, as you say but on Windows at least, all this > code succeeds > in doing is distinguishing syntactically between `/msys/home/' (which > it treats as a > directory because the "name" part is missing and '/msys/home' (which > it treats as a > file) apparently without asking the operating system. Does this work > properly > on linux? > Yes, please see my second post on this. Common lisp seems to have been designed to handle systems without directories, like mainframes, is my guess for why the standard works this way. In sum, my understanding for detecting files and directories in standard cl is: (probe-file "filename") -> pathname iff filename is a file (directory "filename/") -> non-nil list iff filename is a non-empty directory This behavior should now be exhibited by 2.6.7pre (and CVS head). > Inside the (dolist (l (directory fn)) ... ) I would like to treat > sub-directories > and files differently, i.e. different color, different type of links, > etc. How can > I do that in GCL? I could not seem to get > > (if (pathname-name (pathname l)) ... > > to work. Is that right approach? > I'd first probe-file -> file, else ensure a trailing slash and do a directory -> non-empty directory, else non-existent or empty directory. > >As for content-type analysis on files, you have the following options > >in order of simplicity to performace: > > > >1) Use an external utility via run-process: > > > I think that for content type I would be happy to try to interpret the file > extension as is done in most web servers, e.g. name.html is of > content-type: text/html and name.txt is of content-type: text/plaintext > etc. > > >As for tutorials, I'd suggest: > > > >1) Practical Common Lisp: > > > > http://www.gigamonkeys.com/book/ > > > >2) The Common Lisp Hyperspec: > > > > http://www.lisp.org/HyperSpec/FrontMatter/index.html > > > > > Thanks! > > >>Anyway, it seems clear that we could use this approach to develop > >>a portable HyperTex browser for Axiom if we decide to go that > >>root. > >> > >If I can delay the stdin/socket multiplexing, this might be > >preferrable at this point. I need to know if blocking the axiom > >process while serving the hyperdoc on Windows is a showstopper. > > > For most applications I think it would be fine to run only one Axiom > process, > so that if a user executes a long running command from the command window, > hypertex would have to wait (and vice versa). > Well, at this burning moment (given your results, not Mike's for the sake of argument), a Windows user would have to do '-> hyperdoc'; at the terminal to get the web served pages served to a separate browser, thereby locking the terminal. One link on the pages might serve instruct the server process to quit, releasing the terminal for further use. (i.e. just like (bar ...) behaves in the example, but with a quit mechanism implemented). On Linux, the process could be backgrounded freeing the terminal for simultaneous work. Is this a problem? In all the web models, to my understanding, axiom via the server process will be unable to push a page to the browser, unless one makes use of the 'refresh' mechanism in html to ensure a call back at some point. The gcl-tk model, in contrast, allows the user to interact with the process from both gui -> command line and command line -> gui at the same time. Don't know how critical this might be. gcl-tk, at least on Linux, already has an effective stdin multiplexer, which I might provide to generic sockets as described earlier if it is really important. Would prefer to delay, of course. Sounds to me like the existing options, presuming they work cross-platform as described above, are sufficient enough for axiom's purpose as to not delay 2.6.7. Please correct me if I'm mistaken. Take care, > Regards, > Bill Page. > > > > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
