From ehuels at gmail.com Mon Jan 23 18:54:21 2006 From: ehuels at gmail.com (Erik Huelsmann) Date: Mon, 23 Jan 2006 19:54:21 +0100 Subject: [Bknr-devel] BKNR Subversion repository Message-ID: Hi! Erik Enge asked me to test his Subversion setup for him. As you are the first project he could think of actually using Subversion, I tried your repository. Although the test succeeded, the checkout of your repository failed. As a Subversion developer, I run an svn-trunk client. This client has lots of changes to the working copy code (the new 1.4 release will have many working copy improvements), so it may be well because of it that the checkout failed. But in order to diagnose the problem, I'd like to know a few things about your repository: - Did you create it with the Subversion supplied on common-lisp.net? - After creation, how did import old history? - If you used cvs2svn, which version did you use to generate the dumpfile? - Do you have any problems yourselves with checking out the repository? Thanks for helping me analyse before this becomes a problem in 1.4! bye, Erik. From hans.huebner at gmail.com Mon Jan 23 21:00:10 2006 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 23 Jan 2006 22:00:10 +0100 Subject: [Bknr-devel] BKNR Subversion repository In-Reply-To: References: Message-ID: Hi Erik, I created the repository using "svnadmin create" on common-lisp.net. Then I exported the existing repository on bknr.net using "svnadmin dump" and imported it on common-lisp.net using "svnadmin load". I followed the Subversion manual doing that, things seemed to work just fine. I use subversion-1.1.3 on my development system, bknr.net is running subversion-1.2.1. I checked in a few changes to the repository yesterday, without any problems. I did not freshly check out, though, but rather modified all the .svn/entries files in my checkout so that they point to the new location. I am using svn+ssh as the protocol. I hope this helps, let me know if you need more information. -Hans From ktomov at web.de Thu Jan 26 15:23:50 2006 From: ktomov at web.de (Kamen TOMOV) Date: Thu, 26 Jan 2006 17:23:50 +0200 Subject: [bknr-devel] threads with bknr-datastore Message-ID: <87oe1zgghl.fsf@web.de> Hi, Is bknr-datastore thread save? If we call the function make-blob-from-file it would create a blob object and will start copying the file. It seems to me that if we access the object before copying is completed its state would be undefined. Is there a known workaround? It should be some mechanism for locking/unlocking of blob objects. Thanks. -- Kamen TOMOV From hans.huebner at gmail.com Thu Jan 26 18:13:51 2006 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 26 Jan 2006 19:13:51 +0100 Subject: [bknr-devel] threads with bknr-datastore In-Reply-To: <87oe1zgghl.fsf@web.de> References: <87oe1zgghl.fsf@web.de> Message-ID: Hi Kamen, there is no provision for thread-safety in the bknr datastore. I don't have any need for thread safety, but if there are small patches which would help in such an environment, I'll be fine with having them. In general, I don't think that threads are such a good idea anyway. Cheers, Hans From ktomov at web.de Fri Jan 27 15:30:55 2006 From: ktomov at web.de (Kamen TOMOV) Date: Fri, 27 Jan 2006 17:30:55 +0200 Subject: [bknr-devel] threads with bknr-datastore In-Reply-To: (Hans =?iso-8859-15?q?H=FCbner's?= message of "Thu, 26 Jan 2006 19:13:51 +0100") References: <87oe1zgghl.fsf@web.de> Message-ID: <87bqxxn0wg.fsf@web.de> On Thu, Jan 26 2006, Hans H?bner wrote: > Hi Kamen, > > there is no provision for thread-safety in the bknr datastore. I > don't have any need for thread safety, but if there are small > patches which would help in such an environment, I'll be fine with > having them. In general, I don't think that threads are such a good > idea anyway. Dear Hans, Thank you for your message. It is not that I have decided to use threads in my application. The thing is that I am not aware of the alternatives that the platform presents. I am coming from a Algol-derived languages land. The application I am working on is a multiuser enterprise application. It definitely needs to be responsive. How would you achieve that without using threads with CL? Thank you. Regards, -- Kamen From hans.huebner at gmail.com Fri Jan 27 16:02:05 2006 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 27 Jan 2006 17:02:05 +0100 Subject: [bknr-devel] threads with bknr-datastore In-Reply-To: <87bqxxn0wg.fsf@web.de> References: <87oe1zgghl.fsf@web.de> <87bqxxn0wg.fsf@web.de> Message-ID: Hi Kamen, I have cross-checked the problem you pointed at, and in fact it is true: The file copying operation of the blob creation routines is not guarded against other processes accessing the datastore. I have not delved into this very far, but I suspect that under CMUCL and SERVE-EVENT based multiprocessing, no scheduling will occur during the file I/O operation, as the scheduler will run only when a file descriptor under control of the SERVE-EVENT subsystem is accessed. This is a guess only, though, and I have not looked up the source to verify what's going on. With a threaded Lisp, the mechanism could be much more problematic as the scheduler may run at any time and pre-empt the Lisp process, possibly in the middle of the file-copying operation. It depends on your application if this is a problem. If your application does not use the blob until it has been put into some application-defined data structure (as opposed to using the class' index), the incomplete blob will be no problem - Only the external data will not be complete. As we started implementing the datastore, we decided that the blob I/O operations should not be protected by the datastore locks, as this would possibly stall the system for a long time. This may or may not be good for your application, but it would require further analysis to really make a good judgement if blob writing should be further protected. This could, for example, be done with a "complete" slot that would be set after the blob has been completely written, in a seperate store transaction. Note that cmucl provides cooperative multiprocessing which is preferable to preemptive threading in many respects. It is simpler to understand, implement and debug. The only real disadvantage it has (in my eyes, anyway), is the fact that no two processes can run at the same time, if two CPUs are available. Cheers, Hans From ktomov at web.de Tue Jan 31 17:31:28 2006 From: ktomov at web.de (Kamen TOMOV) Date: Tue, 31 Jan 2006 19:31:28 +0200 Subject: [bknr-devel] string multiple-slot indices Message-ID: <87y80wi9sf.fsf@web.de> Hi, Is multiple-slot indices only for slots that are numbers? I tried with a multiple-slot array-index where one of the values is a string. It signaled a condition. What is the proper way to do that? Also I noticed that their size needs to be specified. Why is that? Thank you. -- Kamen TOMOV