- osicat-devel - mailman3.common-lisp.net

Packaging an app that uses osicat with asdf:make
by Jason McBrayer 29 Jun '19

29 Jun '19

Hi, I'm new to the list and fairly new to common-lisp. I have a question that is not actually 100% specific to osicat, probably, but I don't know where to ask, and osicat was where I ran into the problem. My apologies if this is off topic or otherwise inappropriate. I've written a small application that uses osicat for finding file permissions and distinguishing files from directories. It has an asdf system definition, and I load it with ql:quickload.I've packaged it into a single executable using asdf:make, and it works fine, as long as I'm running it as the user I built it as. Running as another user, it errors out on not being able to load a shared library somewhere in my .cache directory; I guess this is what osicat compiled when I did (ql:quickload :osicat). My question is, how can I make this application available to other users on my system? I've tried putting the shared library in /usr/local/lib64 and running ldconfig, but the application still looks for it in its original location. For reference, I am using SBCL 1.4.14 on 64-bit Fedora Linux. -- +----------------------------------------------------------------------+ | Jason F. McBrayer jmcbray(a)carcosa.net | | The scalloped tatters of the King in Yellow must hide Yhtill forever.|

2 2

Osicat/github
by Nikodemus Siivola 18 Jun '15

18 Jun '15

I'd quite forgotten that Osicat had moved to github, and pushed a commit on https://gitlab.common-lisp.net/osicat/osicat . Oops. There's a corresponding pull request on github. Cheers, -- nikodemus

1 0

[Osicat-devel] patch adding wrappers for C macros WIFEXITED(), WEXITSTATUS() ...
by Massimiliano Ghilardi 26 Dec '14

26 Dec '14

Hello, I noticed osicat-posix is missing wrappers for WIFEXITED(), WEXITSTATUS() and other C macros needed to inspect the return value of wait() and waitpid(). In attachment a patch to define them - please let me know if it's good as it is or it needs improvements/cleanups. Regards, Massimiliano Ghilardi

2 1

[Osicat-devel] Travis CI and Osicat 0.7.0
by Luís Oliveira 23 Dec '14

23 Dec '14

Hello Osicat users and developers, I've set up Travis CI for the osicat repository at <https://github.com/osicat/osicat>. In the process of doing that, I noticed that CCL fd-streams were broken so I removed them. Also released 0.7.0, which was long overdue. :-) Cheers, -- Luís Oliveira http://kerno.org/~luis/

2 1

bug in mmap() and mremap() return value - and a fix
by Massimiliano Ghilardi 22 Jan '14

22 Jan '14

Running 32-bit CCL on 64-bit Linux (but it can happen in any setup), I noticed that (osicat-posix:mmap) does not correctly handle return addresses larger than the maximum C "long" value, but instead throws an exception. In such cases, it means the underlying C mmap() function returned successfully a pointer in the top half of the addressable virtual memory, but the Lisp wrapper for mmap() and mremap() chokes on such pointers. A patch that solves this problem is attached. Feedback on the analysis and the solution is welcome :) Best regards, Massimiliano Ghilardi ------------------ longer explanation ----------------------------- While invoking (osicat-posix:mmap (cffi-sys:null-pointer) 4096 (logior osicat-posix:prot-read osicat-posix:prot-write) osicat-posix:map-shared *fd* 0) with a file descriptor *fd* correctly open on a 4096-byte file, I encountered the error: ------------------------------------------------------------------- The value -143798272 is not of the expected type (UNSIGNED-BYTE 32). [Condition of type TYPE-ERROR] 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: (CFFI-SYS:MAKE-POINTER -143798272) 1: (CCL::CALL-CHECK-REGS OSICAT-POSIX:MMAP #<A Null Foreign Pointer> 4096 3 1 4 0) 2: (CCL::CHEAP-EVAL (OSICAT-POSIX:MMAP (CFFI-SYS:NULL-POINTER) 4096 (LOGIOR OSICAT-POSIX:PROT-READ OSICAT-POSIX:PROT-WRITE) OSICAT-POSIX:MAP-SHARED *FD* ...)) ------------------------------------------------------------------- A simple analysis (cat /proc/<ccl-pid>/maps) shows that mmap() actually succeeded and returned the value #xf76dd000, which was converted to -143798272 because OSICAT wrapper for mmap() is defined to return a C "long", that is limited to the range -#x80000000 to #x7fffffff, thus converting #xf76dd000 to a C long overflows and gives a negative value. But calling (cffi-sys:make-pointer) chokes on negative values, at least on CCL.

3 10

colons in pathnames - SBCL vs CCL
by John Morrison 08 Jan '14

08 Jan '14

Ran into CCL (but not SBCL) choking on filenames that contain colons (it interprets them as logical hosts, regardless of the fact they're not recognized ones -- and in contravention of the CLHS?). Seems like the divergence in behavior between CCL and SBCL is in merge-pathnames - below the level of osicat. My perhaps naive and overly simplistic expectation of behavior is that of SBCL (not choking, arguably closer adherence to CLHS). [jm@jm7 ~]$ lx86cl64 Welcome to Clozure Common Lisp Version 1.9-r15870 (LinuxX8664)! ? (merge-pathnames "foo:bar" #P"" :newest) > Error: "foo" is not a defined logical host > While executing: CCL::PATHNAME-HOST-SSTR, in process listener(1). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 1 > (apropos "host-translations") CCL::%LOGICAL-HOST-TRANSLATIONS%, Value: (("ccl" (#P"ccl:l1;**;*.*" #P"ccl:level-1;**;*.*") (#P"ccl:l1f;**;*.*" #P"ccl:l1-fasls;**;*.*") (#P"ccl:ccl;*.*" #P"/opt/ccl/*.*") (#P"ccl:**;*.*" #P"/opt/ccl/**/*.*")) ("home" (#P"home:**;*.*" #P"/home/jm/**/*.*"))) Found this when rehabbing the ancient CLIM "indented-lists" tree widget, replacing the buggy (in CCL again) pathname hackery therein with osicat (which cleaned up the code). Turns out dbus/dcop create these files/symlinks in one's home directory, so it's not like I went looking for corner cases... If possible, I would of course prefer to be able to rely on osicat or the like to insulate me from system or implementation-dependent behavior. Does anybody have any guidance? Thanks in advance. -jm

3 6

osicat:native-namestring undocumented.
by Max Rottenkolber 11 May '13

11 May '13

Hi, I was about to write a portable NATIVE-NAMESTRING function when I noticed the package conflict with OSICAT. Since I don't have texinfo-docstrings I can only guess what's missing so here is a diff: diff --git a/doc/osicat.texinfo b/doc/osicat.texinfo index 53df0bf..05965de 100644 --- a/doc/osicat.texinfo +++ b/doc/osicat.texinfo @@ -99,6 +99,7 @@ @include include/macro-osicat-with-temporary-file.texinfo @include include/fun-osicat-make-link.texinfo @include include/fun-osicat-read-link.texinfo +@include include/fun-osicat-native-namestring.texinfo @node Users @section Users Cheers, max

1 0

[osicat-devel] Unicode error for Clozure when calling osicat-posix:mkdir on existing directory
by Vladimir Sedach 27 Mar '13

27 Mar '13

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 type BABEL-ENCODINGS:INVALID-UTF8-STARTER-BYTE] Restarts: 0: [*ABORT] Return to SLIME's top level. 1: [ABORT-BREAK] Reset this thread 2: [ABORT] Kill this thread Backtrace: 0: (BABEL-ENCODINGS::UTF-8-DECODER #<A Foreign Pointer [stack-allocated] #x7F60D08> 0 3 "^@^@^@" 0) 1: (CFFI:FOREIGN-STRING-TO-LISP #<A Foreign Pointer [stack-allocated] #x7F60D08> :OFFSET 0 :COUNT NIL :MAX-CHARS 16777215 :ENCODING :UTF-8) 2: (OSICAT-POSIX:STRERROR 17) 3: ((:INTERNAL (PRINT-OBJECT (OSICAT-POSIX:POSIX-ERROR T)))) 4: (CCL::%PRINT-UNREADABLE-OBJECT #<EEXIST #<error printing OSICAT-POSIX:EEXIST #x19797F2E> #<STRING-OUTPUT-STREAM #x1979BB66> T NIL #<COMPILED-LEXICAL-CLOSURE (:INTERNAL ..)) 5: (#<STANDARD-METHOD PRINT-OBJECT (OSICAT-POSIX:POSIX-ERROR T)> #<EEXIST #<error printing OSICAT-POSIX:EEXIST #x19797F2E> #<STRING-OUTPUT-STREAM #x1979BB66>) 6: (CCL::%CALL-NEXT-METHOD (NIL #<STANDARD-METHOD PRINT-OBJECT (OSICAT-POSIX:POSIX-ERROR T)> . 4670269)) 7: (CCL::%%STANDARD-COMBINED-METHOD-DCODE (#<CCL::STANDARD-KERNEL-METHOD PRINT-OBJECT :AROUND (T T)> #<STANDARD-METHOD PRINT-OBJECT (OSICAT-POSIX:POSIX-ERROR T)>) 4670269) 8: (NIL #<Unknown Arguments>) 9: (CCL::WRITE-A-FROB #<EEXIST #<error printing OSICAT-POSIX:EEXIST #x19797F2E> #<STRING-OUTPUT-STREAM #x1979BB66> 536870911 NIL) 10: (CCL::WRITE-INTERNAL #<STRING-OUTPUT-STREAM #x1979BB66> #<EEXIST #<error printing OSICAT-POSIX:EEXIST #x19797F2E> 536870911 NIL) 11: (CCL::WRITE-1 #<EEXIST #<error printing OSICAT-POSIX:EEXIST #x19797F2E> #<STRING-OUTPUT-STREAM #x1979BB66> 536870911) 12: (PRIN1 #<EEXIST #<error printing OSICAT-POSIX:EEXIST #x19797F2E> #<STRING-OUTPUT-STREAM #x1979BB66>) 13: (PRIN1-TO-STRING #<EEXIST #<error printing OSICAT-POSIX:EEXIST #x19797F2E>) 14: (SWANK:EVAL-FOR-EMACS (SWANK:LISTENER-EVAL "(osicat-posix:mkdir (merge-pathnames \"bar/\" \"/home/viper/tmp/\") #o777)\n") "COMMON-LISP-USER" 63) -------------------------------------------- This doesn't come up in SBCL or CLISP - they both print the EEXIST error normally. The environment is Clozure Version 1.9-dev-r15251M (LinuxX8632) on SLIME on Ubuntu, both locale and ccl:*default-file-character-encoding* are utf-8. Vladimir

2 1

Re: [osicat-devel] bug in UNMERGE-PATHNAMES when called with #P
by Luís Oliveira 15 Jul '12

15 Jul '12

On Mon, Jul 2, 2012 at 5:09 PM, <max(a)mr.gy> wrote: > I understand now. You are right it's not a bug. Instead of having arbitrary no-op behaviour, signalling errors forces the programmer to > be explicit. Yeah, when in doubt I tend to go that way. I thought about this a little bit more; the argument for the no-op behaviour is that it would make unmerge-pathnames work more like the inverse of merge-pathnames, which has no trouble mixing relative and absolute pathnames. But that just makes it clear that unmerge-pathnames is a misnomer, since it only deals with directories and ignores other components. A better name for this function would perhaps reflect its similarities with enough-namestring. Another problem with unmerge-pathnames only taking the directory component into account is that it fails to do the right thing on Windows, where the device component is particularly relevant for this operation. Do you feel like taking a stab at these issues? Cheers, -- Luís Oliveira http://r42.eu/~luis/

1 0

Re: [osicat-devel] bug in UNMERGE-PATHNAMES when called with #P
by max＠mr.gy 29 Jun '12

29 Jun '12

> What should it do when it gets a relative pathname? E.g.: > #p"foo/bar/". I think #p"/" should not be treated fundamentally different to #p"foo/". E.g.: (unmerge-pathnames #p"foo/bar/baz" #p"foo/bar/") => #p"baz" (unmerge-pathnames #p"/foo/bar/baz" #p"foo/bar/") => #p"/foo/bar/baz"

2 1