gmane.lisp.openmcl.devel

Re: Lisp image filename.

Chun Tian (binghe — 2008-10-07T14:52:16

I also suggest this change (using .image convention on all platforms). Now It's impossible to checkout CCL repository (non-Mac platform) on Mac OS X, just because svn cannot distinguish the two files with the same name but different case. I'm running a Solaris 10 virtual machine on Mac OS X by VMware Fusion, and mapping HFS directories into Solaris. I want to checkout CCL for Solaris on Mac and then use it in Solaris, but cannot do (the reason above). Another side, install a svn client on Solaris 10 is quite hard, so many sunfreeware packages to install, and it could be avoid if CCL's svn file-case issue is gone... --binghe

Re: directory, create-directory, ...

Jon S. Anthony — 2008-10-07T04:45:01

I have, but really, this just isn't the issue. This is the issue. Though I do sympathize with the usual issues around open source. I am definitely spoiled by the completeness and direct access available on this sort of impl specific stuff in Allegro (and no doubt in other commercial offerings). Well, yes, _exactly_. Again, exactly. But also again, I understand the constraints in an open source world. For example, I am using CCL (and mostly without much issues) in a startup, and frankly the 12-15 hours a day at that work don't leave me in much of a mood or position to root around and find this information and then document it for the good of the "community". Actually, this isn't much good either as the source has little comments on what/how these are used. True, I could try to read the code and reverse engineer this, but see above.

Re: directory, create-directory, ...

Raffael Cavallaro — 2008-10-06T21:29:31

On Oct 6, 2008, at 4:01 PM, Gary Byers wrote: As a long time user of mcl/openmcl/clozure cl I'll just chime in to say that M-. is truly your friend. Raffael Cavallaro, Ph.D. raffaelcavallaro< at >mac.com

Re: Lisp image filename.

Gary Byers — 2008-10-06T20:26:17

On Mon, 6 Oct 2008, David Brown wrote: Lack of foresight, mostly. Inertia factors into it, too: there are a handful (maybe a few handfuls ...) of places in the code and documentation that "know" that some platforms use the case-inversion convention and others use ".image". There have always been exceptions to assumptions about a platform's case-sensitivity (it's usually an attribute of the filesystem, not of the OS), and those exceptions are likely to get more common. Using the ".image" convention on all platforms (as you propose) makes sense and I agree that it's worth doing, but the change will probably be at least a little disruptive. (Not so disruptive that it shouldn't be done, but at least a little disruptive.)

Re: directory, create-directory, ...

Gary Byers — 2008-10-06T20:01:16

I started to write a much longer response, but it was amounting to a CL pathname tutorial. As Hans pointed out, Peter Seibel has already written one (and it appears to be quite good). If reality doesn't match one's intuitions about it, there are two general explanations for that: 1) Reality is wrong somehow. 2) One's intuitions are ill-founded. I strongly suspect that reality is often just plain wrong, but that suspicion has never done me much good ... Please read Peter's tutorial. The keyword arguments to DIRECTORY should really be documented somewhere other than in comments in the source, but they have nothing to do with how namestrings are parsed into pathnames in general or in a particular implementation. (They do have to do with whether things which could potentially be included in DIRECTORY's results are in fact included in those results.) Likewise, it'd be better if the MODE argument to CREATE-DIRECTORY was documented (via DOCUMENTATION or the manual or both.) It'd be even worse than it

Re: directory, create-directory, ...

Chun Tian (binghe — 2008-10-06T18:15:49

Try this one: (directory (make-pathname :name :wild :type :wild :defaults #p"/x/ y/") :directories t) or just (directory #p"/x/y/*.*" :directories t) I think you'd better use CL-FAD package instead. I just learn above by reading CL-FAD's LIST-DIRECTORY function: (defun list-directory (dirname) "Returns a fresh list of pathnames corresponding to the truenames of all files within the directory named by the non-wild pathname designator DIRNAME. The pathnames of sub-directories are returned in directory form - see PATHNAME-AS-DIRECTORY." (when (wild-pathname-p dirname) (error "Can only list concrete directory names.")) #+:ecl (let ((dir (pathname-as-directory dirname))) (concatenate 'list (directory (merge-pathnames (pathname "*/") dir)) (directory (merge-pathnames (pathname "*.*") dir)))) #-:ecl (let ((wildcard (directory-wildcard dirname))) #+:abcl (system::list-directory dirname) #+(or :sbcl :cmu :scl :lispworks) (directory wil

Re: directory, create-directory, ...

2008-10-06T15:48:09

I sent this out, but I think I forgot to include the group... Anyway, yes, (directory "/x/y/*.lisp") for example does what you would expect. Using only a wild card though doesn't get all files: (directory "/x/y/*") => nil. You can use (directory "/x/y/*.*") but that would seem to indicate only files with a "." in their name. It may be that this is where the various keywords to directory come into play. Are/where are these described? Also, R.Stoye informed me that the MODE keyword for create-directory is for indicating the unix mode/permissions for the directory. Again, where is this impl specific type stuff described for CCL? For example, I now know what MODE is for, but still don't know how it is specified (ala' chmod or ???) Thanks! /Jon -------------------------------------------------------------------- mail2web - Check your email from the web at http://link.mail2web.com/mail2web

Re: directory, create-directory, ...

Gary Byers — 2008-10-06T12:57:56

On Mon, 6 Oct 2008, Hans Hbner wrote: And in the case of DIRECTORY, you're basically asking for a list of all files whose pathnames that match DIRECTORY's first argument. If that argument is #P"/home/jsa/" (with the trailing slash), then ? (pathname-name #P"/home/jsa/") NIL ? (pathname-type #P"/home/jsa/") NIL If you're able to create a file/directory with no name or type in that directory, DIRECTORY should return it. Since it's hard to create such a file or directory, DIRECTORY correctly returns NIL (though that may not have been what you expected and isn't analogous to how the unix "ls" program behaves.) It's often more useful to use wildcards as name and type components in DIRECTORY's first argument: ? (directory #P"/home/jsa/*.lisp") should return a list of all files with a type of "lisp" in that directory, etc.ld return a li!_______________________________________________ Openmcl-devel mailing list Openmcl-devel< at >clozure.com http://clozure.com/mailman/listinfo/openmcl-devel

Re: directory, create-directory, ...

Hans Hübner — 2008-10-06T12:42:26

Your directory pathnames need to end in a slash, as in #P"/home/jsa/". DIrectories and files are treated differently in the CL pathname system. See http://gigamonkeys.com/book/files-and-file-io.html#filenames for a discussion on the history and usage of pathnames. -Hans

directory, create-directory, ...

Jon S. Anthony — 2008-10-06T12:51:24

I have tried these on both Mac and Linux and they behave the same, and that is to do nothing. They don't error, but just return. create-directory returns the multiple values: path of the supposedly new directory and nil: (create-directory "/home/jsa/TEST") => #p"/home/jsa/TEST", NIL But the directory isn't created. I also haven't found what the MODE keyword is supposed to be or do. directory returns nil whether or not the directory given exists: (directory "/home/jsa") => nil (directory "/gobbledegook") => nil I also couldn't find the meaning of the various keywords to this either, but tried various permutations of :files t, :directories t, etc. with no apparent effect. I tried both with path syntax input as well: #p"/home/jsa/TEST", #p"/home/jsa", etc. Nothing. Anyone have any ideas?? /Jon

Lisp image filename.

David Brown — 2008-10-06T08:34:55

Is there any particular reason for the distinction on darwin of naming the image by tacking an ".image" onto the filename, and other platforms that use an equivalent named file in uppercase? The reason I ask is that I commonly work on Linux images running in a VM on MacOS. Generally, my home directory is just mapped through to the underlying HFS filesystem. With the case-paired filenames, I'm not able to store CCL in my home directory, but must expand it somewhere in a native filesystem. It seems like things would be simpler overall to just use an extension on the name, and allow things to work on any platform, even if the filesystem happens to be case insensitive. Thanks, David Brown

Re: Hash Table performance

Osei Poku — 2008-09-23T22:34:28

This is understood and I am in perfect agreement. In fact, my ultimate intent is quick lookups and not to use the hash table for iteration at all. I was looking into iteration to be able check the contents of the hash table for debugging purposes. I am perfectly happy with just being able to grab any key in the hash table and then displaying its value. I guess I got caught up with trying to use slime inspector (which uses WITH-HASH-TABLE-ITERATOR) and somewhere along the way I lost track of what I actually needed to do in the first place. After utilizing a few more brain cells, I realize I was wasting time tackling the wrong problem. I'm just trying to debug the parser that generated the hash table! I guess I just got lazy from always using slime inspector :) The problem still remains though. Is there some slightly less expensive way (than enumerating the entire hashtable) of grabbing an arbitrary key-value pair from a hash table? Osei

Re: Hash Table performance

Gail Zacharias — 2008-09-23T22:34:07

Sort of. CCL does rehashing in place. If a hash table were rehashed while you're iterating over it, the result would be totally random. However, there are potentially ways around this. For example, a hash table could know whether it's being iterated over, and do a copying rehash if so. Of course if this does happen (and especially if it happens repeatedly) you might end up consing as much or more as the current iterator, but only if your keys are address based and recently consed, so it's probably a good bet. The new "nearly lock free" hash tables that are in the trunk always do a copying rehash (for other reasons), so they especially should be made to iterate without copying.

Re: Hash Table performance

Chris Curtis — 2008-09-23T22:09:35

On Sep 23, 2008, at 5:58 PM, Osei Poku wrote: If you need to iterate through 10^8 entries, a hash table is simply not the right data structure. For that matter, if you need to iterate through any number of entries, a hashtable is generally a Bad Idea. I don't think this has anything to do with CCL. Hashtables get their insert and lookup performance at the expense of iterability. Linked lists get their iteration performance at the expense of insert and lookup performance. Trees of various types spread the expense around differently. --chris

Hash Table performance

Osei Poku — 2008-09-23T21:58:29

Hi, CCL extensively uses the ENUMERATE-HASH-KEYS-AND-VALUES function underneath most of hash table functions (MAPHASH, WITH-HASH-TABLE- ITERATOR). This causes a great deal of waste when iterating through a very large hash table (like I have now ~10^8 entries). The way I understand the code from briefly looking at l0-hash.lisp and hash.lisp, the contents of the hash table are first stored in a pair of vectors, then the vectors are iterated through. WITH-HASH-TABLE-ITERATOR is used everywhere like in the expansion of the LOOP macro. There is simply no standard way in CCL to iterate through the contents of a hash table without doing this double work. Is there some fundamental limitation of the way hash tables are implemented in CCL that prevent iterating through its contents only once? Osei

Re: planned trunk instability

Gary Byers — 2008-09-23T01:08:58

I think that 15 days counts as "a few", doesn't it ? As far as I know, we're through making changes to the trunk that require extensive bootstrapping, at least for a while. Changes that have occurred recently include: - "nearly lock free" hash tables (whose implementation is described at ). These are not yet enabled by default; a hash table created via (make-hash-table ... :LOCK-FREE T) allows concurrent read-write access to the resulting hash-table from multiple threads without locking overhead for most operations. (If I understand correctly, locking does come into play when the hash table needs to be rehashed due to growth or address-based key movement.) So far, the performance results seem to be encouraging, and I think that the plan is to make :LOCK-FREE T the default for shared hash-tables (and to try to descibe any usage patterns where it wouldn't be an appropriate default better than

Re: Clozure CL 1.2 released - building the IDE,where are working instructions?

R. Matthew Emerson — 2008-09-23T00:22:12

On Sep 22, 2008, at 5:31 AM, Rainer Joswig wrote: Argh! Storing the CCL directory in the user defaults database has caused nothing but pain. I see that we have a ticket about this now. http://trac.clozure.com/openmcl/ticket/332

Re: Clozure CL 1.2 released - building the IDE,where are working instructions?

Rainer Joswig — 2008-09-22T09:31:55

_______________________________________________ Openmcl-devel mailing list Openmcl-devel< at >clozure.com http://clozure.com/mailman/listinfo/openmcl-devel

Re: Clozure CL 1.2 released - type of cocoa-application ?

Gary Byers — 2008-09-22T01:38:16

On Sun, 21 Sep 2008, james anderson wrote: What streams are used for I/O (for error message, break loops, etc.) has more to do with what thread is doing the I/O (and what that thread's bindings of *ERROR-OUTPUT*, *DEBUG-IO*, etc. are) than with what other threads (and windows, and streams ...) exist when the I/O happens. To review some of the discussion in ticket 87 and elsewhere (as I understand and remember it): - it's clearly desirable for the IDE to load ~/ccl-init, and it should do this in more-or-less then same way as it's done in the TTY environment (in the initial listener thread, just before that thread enters its REPL.) Any interactive I/O that occurs while loading the init file should happen in the listener thread's standard streams (which are connected to the listener window/its buffer/whatever.) Whatever implements this would indeed do something like what CCL::STARTUP-CCL does in the TTY environment; in the IDE, the initial listener is created in response to so

Re: Clozure CL 1.2 released - type ofcocoa-application ?

james anderson — 2008-09-21T21:12:46

On 2008-09-21, at 15:17 , Gail Zacharias wrote: i don't know, but - reading those comments, maybe one is expecting too much from it. just reading the code, the notes, that output would go to the console, seem right-minded. if one puts a handled call to startup-ccl (or its equivalent) just before starting the event loop, that seems as late as possible before anything visible has happened. if something goes wrong, output appears on the console (somehow it's sometimes the ccl and sometimes the system console) and in any case the first listener appears. this is certainly enough to be useful.

Re: Clozure CL 1.2 released - type of cocoa-application ?

Gail Zacharias — 2008-09-21T19:17:07

There is some discussion of this in http://trac.clozure.com/openmcl/ticket/208 and http://trac.clozure.com/openmcl/ticket/87. It looks like the problem is not implementation as much as thinking it through and deciding what's right. At 9/21/2008 12:06 PM, james anderson wrote: