gmane.lisp.osicat.devel

[osicat-devel] Unicode error for Clozure when callingosicat-posix:mkdir on existing directory

Vladimir Sedach — 2012-04-15T23:29:46

I get a strange error when calling osicat-posix:mkdir on an already
existing directory in Clozure.

(osicat-posix:mkdir "/this/directory/exists/" #o777)

An error is thrown:

--------------------------------------------

#<error printing EEXIST #x1985838E>
   [Condition of type OSICAT-POSIX:EEXIST]

Restarts:
 0: [RETRY] Retry SLIME REPL evaluation request.
 1: [*ABORT] Return to SLIME's top level.
 2: [ABORT-BREAK] Reset this thread
 3: [ABORT] Kill this thread

Backtrace:
  0: (OSICAT-POSIX:POSIX-ERROR 17 NIL OSICAT-POSIX:MKDIR)
  1: (CCL::CALL-CHECK-REGS OSICAT-POSIX:MKDIR #P"/home/viper/tmp/bar/" 511)
  2: (CCL::CHEAP-EVAL (OSICAT-POSIX:MKDIR (MERGE-PATHNAMES "bar/"
"/home/viper/tmp/") 511))
  3: (SWANK::EVAL-REGION "(osicat-posix:mkdir (merge-pathnames
\"bar/\" \"/home/viper/tmp/\") #o777)\n")

--------------------------------------------

Select restart 1 (abort), another error comes up:

--------------------------------------------

Illegal :UTF-8 character starting at position 0.
   [Condition of typ

Re: [osicat-devel] walk-directory does not support unicode filename and diretoryname?

Nikodemus Siivola — 2012-03-30T14:44:37


Sounds like a strange interaction between CCL and CFFI -- could not
reproduce on SBCL.

Can you provide a tarball that has filenames that cause you trouble?

What locale are you using?

Cheers,

 -- Nikodemus

_______________________________________________
pg-cvs site list
pg-cvs< at >common-lisp.net
http://common-lisp.net/mailman/listinfo/pg-cvs

Re: [osicat-devel] prctl() support and test-related patches

Nikodemus Siivola — 2012-03-30T14:40:19


Thanks!


This one conflicts with the current tree, and the test breaks outside Linux.


Cherry-picked and pushed.


Cherry-picked and pushed.

Cheers,

 -- Nikodemus

_______________________________________________
pg-cvs site list
pg-cvs< at >common-lisp.net
http://common-lisp.net/mailman/listinfo/pg-cvs

Re: [osicat-devel] Patch to fix osicat on OpenBSD

Nikodemus Siivola — 2012-03-30T14:22:18


Thank you. Pushed ... we'll see if something breaks.

(Apropos: attachments generated with "git format-patch -1" are quicker
to apply.)

Cheers,

 -- nikodemus

_______________________________________________
pg-cvs site list
pg-cvs< at >common-lisp.net
http://common-lisp.net/mailman/listinfo/pg-cvs

Re: [osicat-devel] Fix out-getuid for Clisp

Nikodemus Siivola — 2012-03-30T14:13:11


Pushed, thanks!

Cheers,

 -- nikodemus

_______________________________________________
pg-cvs site list
pg-cvs< at >common-lisp.net
http://common-lisp.net/mailman/listinfo/pg-cvs

[osicat-devel] prctl() support and test-related patches

Nicolas Martyanoff — 2012-02-22T07:29:57

Hi,

I added support for the prctl() Linux syscall to Osicat, and made two
test-related fixes.

The patches are available on my Github Osicat fork [1], more
precisely:

https://github.com/galdor/osicat/commit/736bb5c10c9c55ed76def0d58da31c1ad1eeff05
https://github.com/galdor/osicat/commit/bede645f2a3d15d825160c7518c295c95bed4271
https://github.com/galdor/osicat/commit/288dc2ee6a6861ea272ea75bb3e346cda6ca85a7

You may be interested in picking them in the official Osicat repository
:)

[1] https://github.com/galdor/osicat

Regards,

[osicat-devel] walk-directory does not support unicode filename anddiretoryname?

Achilles Xu — 2012-02-06T09:22:08

It seems walk-directory will skip files and directories whose name is in
Unicode, such as Chinese.

Is this a bug?

Test platform: Mac OS 10.7 Lion, Clozure Common Lisp 1.8

Test Code:

(require "asdf")
(require "osicat")

(defpackage :com.losttemple.zip-db
  (:use :common-lisp :osicat))

(in-package :com.losttemple.zip-db)

(walk-directory
 (current-directory)
 #'(lambda (x) (format t "~a~%" (absolute-pathname x)))
 :test #'(lambda (x) (format t "---~a~%" (absolute-pathname x)) t)
 :directories :depth-first)

(in-package :common-lisp-user)
(quit)

[osicat-devel] Fix out-getuid for Clisp

Timo Myyrä — 2012-01-12T11:20:46

Clisp doesn't have (posix:getuid) function, instead it uses (posix:uid).
Here's small patch to fix it in osicat tests.

Timo

diff --git a/tests/tests.lisp b/tests/tests.lisp
index 2710a8f..7d0c399 100644
--- a/tests/tests.lisp
+++ b/tests/tests.lisp
< at >< at > -59,6 +59,6 < at >< at >
 (defun our-getuid ()
   #+sbcl (sb-unix:unix-getuid)
   #+cmu (unix:unix-getuid)
-  #+clisp (posix:getuid)
+  #+clisp (posix:uid)
   #+allegro (excl.osi:getuid)
   #-(or sbcl cmu clisp allegro) 0) ; A sane enough default for testing?

_______________________________________________
pg-cvs site list
pg-cvs< at >common-lisp.net
http://common-lisp.net/mailman/listinfo/pg-cvs

[osicat-devel] Patch to fix osicat on OpenBSD

Timo Myyrä — 2012-01-08T09:55:44

Hi,

Here's diff to make osicat work on OpenBSD.

OpenBSD doesn't define blksize_t and blkcnt_t so define them as
'long'. Not sure if this is correct but seems to work.
Neither does OpenBSD have the timer functions so omit them on OpenBSD.
The tests need to be tweaked for OpenBSD too, its similar to darwin in
this. Testing with other BSD's would be welcome to see if it its
needed there as well.

The funcall-getpw function seems to handle return values incorrectly.
As result it would cause exception on OpenBSD with incorrect entries
and not nil value as expected. The fix below works on OpenBSD but
could use some testing on other platforms as well.

Hopefully gmail won't break the diff.

Timo


diff --git a/posix/basic-unixint.lisp b/posix/basic-unixint.lisp
index 3ee3710..88371ae 100644
--- a/posix/basic-unixint.lisp
+++ b/posix/basic-unixint.lisp
< at >< at > -286,12 +286,18 < at >< at >
 (ctype dev "dev_t")
 (ctype ino "ino_t")

-#-windows
+#-(or windows openbsd)
 (progn
   (ctype nlink "nlink_t")
   (ctype blksize "blksize_t"

[osicat-devel] Patch to fix osicat on OpenBSD

Timo Myyrä — 2012-01-08T09:55:44

Hi,

Here's diff to make osicat work on OpenBSD.

OpenBSD doesn't define blksize_t and blkcnt_t so define them as
'long'. Not sure if this is correct but seems to work.
Neither does OpenBSD have the timer functions so omit them on OpenBSD.
The tests need to be tweaked for OpenBSD too, its similar to darwin in
this. Testing with other BSD's would be welcome to see if it its
needed there as well.

The funcall-getpw function seems to handle return values incorrectly.
As result it would cause exception on OpenBSD with incorrect entries
and not nil value as expected. The fix below works on OpenBSD but
could use some testing on other platforms as well.

Hopefully gmail won't break the diff.

Timo


diff --git a/posix/basic-unixint.lisp b/posix/basic-unixint.lisp
index 3ee3710..88371ae 100644
--- a/posix/basic-unixint.lisp
+++ b/posix/basic-unixint.lisp
< at >< at > -286,12 +286,18 < at >< at >
 (ctype dev "dev_t")
 (ctype ino "ino_t")

-#-windows
+#-(or windows openbsd)
 (progn
   (ctype nlink "nlink_t")
   (ctype blksize "blksize_t"

[osicat-devel] Patch to fix osicat on OpenBSD

Timo Myyrä — 2012-01-08T09:55:44

Hi,

Here's diff to make osicat work on OpenBSD.

OpenBSD doesn't define blksize_t and blkcnt_t so define them as
'long'. Not sure if this is correct but seems to work.
Neither does OpenBSD have the timer functions so omit them on OpenBSD.
The tests need to be tweaked for OpenBSD too, its similar to darwin in
this. Testing with other BSD's would be welcome to see if it its
needed there as well.

The funcall-getpw function seems to handle return values incorrectly.
As result it would cause exception on OpenBSD with incorrect entries
and not nil value as expected. The fix below works on OpenBSD but
could use some testing on other platforms as well.

Hopefully gmail won't break the diff.

Timo


diff --git a/posix/basic-unixint.lisp b/posix/basic-unixint.lisp
index 3ee3710..88371ae 100644
--- a/posix/basic-unixint.lisp
+++ b/posix/basic-unixint.lisp
< at >< at > -286,12 +286,18 < at >< at >
 (ctype dev "dev_t")
 (ctype ino "ino_t")

-#-windows
+#-(or windows openbsd)
 (progn
   (ctype nlink "nlink_t")
   (ctype blksize "blksize_t"

[osicat-devel] blksize_t and blkcnt_t undefined on OpenBSD

Timo Myyrä — 2012-01-02T12:43:39

Hi,

Osicat fails to compile on OpenBSD because of missing defines for
blksize_t and blkcnt_t.


External process exited with code 1.
Command was: "cc" "-m64"
"-I/home/zmyrgel/quicklisp/dists/quicklisp/software..." "-fPIC" "-o"
"/home/zmyrgel/.cache/common-lisp/sbcl-1.0.54.openb..."
"/home/zmyrgel/.cache/common-lisp/sbcl-1.0.54.openb..."
Output was:
/home/zmyrgel/.cache/common-lisp/sbcl-1.0.54.openbsd-bsd-x64/home/zmyrgel/quicklisp/dists/quicklisp/software/osicat-20110619-git/posix/basic-unixint.c:
In function 'main':
/home/zmyrgel/.cache/common-lisp/sbcl-1.0.54.openbsd-bsd-x64/home/zmyrgel/quicklisp/dists/quicklisp/software/osicat-20110619-git/posix/basic-unixint.c:2041:
error: 'blksize_t' undeclared (first use in this function)
/home/zmyrgel/.cache/common-lisp/sbcl-1.0.54.openbsd-bsd-x64/home/zmyrgel/quicklisp/dists/quicklisp/software/osicat-20110619-git/posix/basic-unixint.c:2041:
error: (Each undeclared identifier is reported only once
/home/zmyrgel/.cache/common-lisp/sbcl-1.0.54.openbsd-bsd-x64/home/zmy

never mind... Problem compiling osicat-posix with quicklisp on x86_64 with 32-bit lisp....

Peter Denno — 2011-11-27T00:00:54

Hi Osicat developers,

Disregard my previous note about problems compiling osicat-posix on 64-bit
for 32-bit lispworks. Thing work just fine if you install the 32-bit gcc,
and just let it happen!

Best regards,
   Peter
_______________________________________________
pg-cvs site list
pg-cvs< at >common-lisp.net
http://common-lisp.net/mailman/listinfo/pg-cvs

Problem compiling osicat-posix with quicklisp on x86_64with 32-bit lispworks

Peter Denno — 2011-11-26T22:49:56

Hi,

I ran into a problem compiling osicat-posix under the environment described
in the subject line. What I get:

[package osicat-posix]; /usr/bin/cc -m32
-I/home/pdenno/quicklisp/dists/quicklisp/software/cffi_0.10.6/ -fPIC -o
/home/pdenno/.cache/common-lisp/lw-6.0.1-linux-x86/home/pdenno/quicklisp/dists/quicklisp/software/osicat-20110619-git/posix/basic-unixint
/home/pdenno/.cache/common-lisp/lw-6.0.1-linux-x86/home/pdenno/quicklisp/dists/quicklisp/software/osicat-20110619-git/posix/basic-unixint.c

External process exited with code 1.
Command was: "/usr/bin/cc" "-m32"
"-I/home/pdenno/quicklisp/dists/quicklisp/software/..." "-fPIC" "-o"
"/home/pdenno/.cache/common-lisp/lw-6.0.1-linux-x86..."
"/home/pdenno/.cache/common-lisp/lw-6.0.1-linux-x86..."
Output was:
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/4.3/libgcc.a when
searching for -lgcc
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld:
cannot fi

Re: open-temporary-file

Elias Pipping — 2011-09-21T00:17:42

To answer my own question: This does not seem to be reasonable since

  [..] The file itself is unlinked once it has been opened. [..]

according to the documentation of `open-temporary-file`.


Regards,

Elias Pipping


_______________________________________________
pg-cvs site list
pg-cvs< at >common-lisp.net
http://common-lisp.net/mailman/listinfo/pg-cvs

open-temporary-file

Elias Pipping — 2011-09-19T16:40:01

Hello,

the function `open-temporary-file` currently returns a stream and
nothing else. Consequently, `with-temporary-file` only exposes a
stream to its body. From my understanding it is (intentionally,
because streams are an abstraction) not possible to tell what the name
of the corresponding temporary file is just by that.

Could open-temporary-file be made to return the name of that file as
well?

I'd like to be able to write code like the following

(osicat:with-temporary-file (stream filename)
  (format stream "some content")
  (= 0 (sb-ext:process-exit-code (sb-ext:run-program "./test.sh" (list filename)))))

In other words, I'd like to pass strings in the form of (temporary)
files to a script/program that reads from the file whose name it is
passed and use `with-temporary-file` for that. Is that reasonable?


Best regards,

Elias Pipping


_______________________________________________
pg-cvs site list
pg-cvs< at >common-lisp.net
http://common-lisp.net/mailman/listinfo/pg-cvs

Re: osicat dotted-namestrings and absolute-pathname interaction around directory iterators

Nikodemus Siivola — 2011-08-22T16:02:50


I think I agree. I'll need to think on this -- and the split in
responsibility between the host lisp and CL some more, though.


No, please. Don't assume that. See the docstring:

 Returns a fresh list of pathnames corresponding to all files
 within the directory named by the non-wild pathname designator
 PATHSPEC.
 If BARE-PATHNAMES is non-NIL only the files's bare pathnames are returned
 (with an empty directory component), otherwise the files' pathnames are
 merged with PATHSPEC.

Nothing about ABSOLUTE-PATHNAME there.


This is not an unreasonable thing to want, but wrong for "." given
LIST-DIRECTORY's contract.

One of the key features of LIST-DIRECTORY is that if you feed it a
relative pathname, you get a list of relative pathnames back.

Changing that as a default is not acceptable.

You have to remember that we're talking about _lisp_ pathnames and
namestrings here, not POSIX ones -- so meaning of "." is
implementation dependent to a frightening degree.

/Practically/ at the end of the day, it most

Re: osicat dotted-namestrings and absolute-pathname interaction around directory iterators

MON KEY — 2011-08-21T22:44:31

On Thu, Aug 18, 2011 at 2:47 AM, Nikodemus Siivola
<nikodemus< at >random-state.net> wrote:

Great! I apologize if my previous communication was opaque.


I'm not clear on this. What is meant by:

"is consistent with the way other directory name designators are dealt
 with"

Is the referenced consistency w/r/t Osicat's dealings or CL's
dealings?


Maybe, but these also seem braindamaged:

 (osicat:absolute-pathname ".")
 ;=> #P"/home/bubba/quux/."

 (osicat:absolute-pathname "..")
 ;=> #P"/home/bubba/quux/.."

Whereas the equivalent of SBCL's CL pathname logic does not:

(truename (make-pathname :directory (pathname-directory ".")
                         :defaults *default-pathname-defaults*))
;=> #P"/home/bubba/quux/"

(truename (make-pathname :directory '(:RELATIVE :UP)
                         :defaults *default-pathname-defaults*))
;=> #P"/home/bubba/"


I will answer your question with the proviso that I am currently given
to believe that the return value of OSICAT:LIST-DIRECTORY is
predicated upon the retu

Re: osicat dotted-namestrings and absolute-pathname interaction around directory iterators

Nikodemus Siivola — 2011-08-18T06:47:58


I honestly didn't understand /what/ you were finding objectionable
before. So we're making progress here...

However, I disagree with this: treating "." and "./" identically is
consistent with the way other directory name designators are dealt
with, and has more to do with the CL pathname logic (and braindamage)
than with POSIX.

Two questions:

1. Assuming current directory contains a single file "foo.txt", what
would you like (osicat:list-directory ".") and (osicat:list-directory
"./") to return?

2. What's the use-case?

Re. Osicat and POSIX:

Yep, the README is out of date. *However* Osicat is not /just/ a POSIX
API. It has two layers:

* The Osicat API in package OSICAT.

* The low-level APIs: currently OSICAT-POSIX and OSICAT-MACH. In the
future there will probably be OSICAT-WIN32 as well.

The Osicat API is not a POSIX API. It tries to find a place to stand
among the concepts shared by modern OSes and be a nice Lispy extension
to things in the standard.

Cheers,

 -- Nikodemus

Crowdfunding SBCL: h

Re: osicat dotted-namestrings and absolute-pathname interaction around directory iterators

Stelian Ionescu — 2011-08-17T19:04:29

That's how I see it



POSIX says that 3 or more "/" are to be normalized to a single one



[...]

I read all that but I still don't understand your point

Re: osicat dotted-namestrings and absolute-pathname interaction around directory iterators

MON KEY — 2011-08-17T18:39:29

So, are you suggestiong that osicat is intended as POSIX-style API?


Permit me to disagree.

By all means feel free to ignore my objections to Osicat's behaviour
around a corner case in differences between CL pathnames and POSIX.
However, please have the courtesy to at least consider that my
citation of section 4.12 IEEE Std 1003.1-2008 was not without reason
and was in fact an attempt to illustrate reasonably that POSIX 2008
_does_ have some fairly clear stipulations about the syntax for
pathnames around a file and a directory not always being the same.

POSIX prescribes certain syntax as denoting a "special filename":

 "."    (dot)
 ".."   (dot-dot)
 "/"    (<slash>)
 "//"   (<slash> <slash>)
 "///*" (<slash> <slash> <slash>*)


FFR following are what i believe to be relevant sections of POSIX-2008:

,----
| 3.266 Pathname
|
| A character string that is used to identify a file. In the context of
| POSIX.1-2008, a pathname may be limited to {PATH_MAX} bytes, including
| the terminating null byte. It has