From read at robertlread.net Tue May 9 17:14:05 2006 From: read at robertlread.net (Robert L. Read) Date: Tue, 09 May 2006 12:14:05 -0500 Subject: [elephant-devel] An intereste exchange between Ian and Rob.... Message-ID: <1147194846.3377.30.camel@localhost.localdomain> Dear Team, This is a long email exchange about future directions betwen Ian Eslick and myself that I thought worth archiving here. Robert, A few follow-on comments: - The implications and architecture of CRUD is outside my sphere of experience. Can you expand on what you'd like to enable? - Perhaps we should plan (or dream) about next generation features when we have some desired usage cases as targets. Small webapps, multi-server webapps, long-running systems with a need for recoverability (my research), etc. - We should have multiple ways to manage concurrency as concurrency problems come in many flavors. Same should be true for optimizing performance. A couple of models for common applications should be trivially supported. Webapps for example often have similar functionality in separate threads operating over a common database. Session objects don't need protection (could be 'local persistent') but shared data structures do if they're written (even something as simple as statistics counters). In my research system I have alot of analyzers groveling over my DB, sometimes on separate machines or CPUs so it's mostly read-only but sometimes I annotate objects which need to be protected by transactions in case of the rare conflict. > I can't comment intelligently on that. The point of my three categories was to allow a three-tier storage model using the elephant APIs to maintain the programmer's view of managed objects. An automatic generational system can upgrade/downgrade the storage class of an object or alternatively a manual director can do so by migrating things from in-memory director indexing to on-disk elephant indexing. local = normal in-memory object semantics + non-persistent indexing local persistent = fast reads + slower write-through + persistent indexing (this does not provide ACID properties but ensures that all writes are logged to the DB as atomic transactions for recoverability) global persistent = for objects that are accessed from multiple threads/processes (current elephant model of always read from disk) If an API allowed you to upgrade/downgrade storage classes then it would be trivial to write an automatic or manual director model on top of those primitive storage classes. > Yes (I think.) The ability to add function-based indexes that are very > lightweight in-memory, reconstitutable things seems like a powerful > feature to me. I'm not sure what part of what I was talking about you mean by "function based indexes" here... [Rob:] I mean the existing ability to build an index based on a function such as (x mod 10). Do you know what makes the SQL serializer so much slower than the BDB serializer? Is it just the conversion/copying to a 64-bit rep? [Rob:] It's because I use simple base-64 encoding to encode Unicode into ascii so that we can work easily with SQL back-ends; this would be easy to improve. Re: compressing serializer Not entirely sure what you were getting at here either, but it did lead me to think of a couple of things that hadn't occurred to me earlier: We might think about ways of extending the serializer for objects as well as aggregate user structures. For example we could add some serializer tables that could be cached in memory at the cost of lookups on infrequently accessed types. Right now we write the slot name and package for every slot in objects as well as for persistent objects. This adds hugely to the storage cost and serialization time. If we have an ID for slotnames and we have a cached serializer record for the class then we know how to map IDs to slotnames and can just increment IDs when we redefine classes and add/drop slots. This would work for non-persistent objects as well as for persistent slots. Currently we serialize non-persistent classes as: type-byte + serialize-id + classname + classpackage + slotname1 + slotpackage1 + slotvalue1 + ... slotvalueN In unicode systems the slotname & classname overhead for meaningful names can be 2-4 bytes per character. At 8 characters a piece a standard object in a 2-byte unicode system with one slot with a single 4-byte fixnum would take 1 + 4 + 16 + 16 + 16 + 16 + 5 = 70 bytes! To store a persistent reference: type + oid + classname + classpackage = 1 + 4 + 16 + 16 = 37 bytes To store a persistent slot fixnum: key: btree-oid + slot-name-string + slot-name-package value: serialized value = type + fixnum key = 4 + 16 + 16 = 36 value = 5 Ok, too many numbers but this is for archival purposes. :) If we introduce btrees that associate classes with a unique id and a serializer record: classname+package->classid (for finding the id on serialization, can cache in memory) classid->serializer-record (for deserialization, can cache this in memory) Then a serialized non-persistent class would be: type-byte + serialize-id + classid + slotid1 + slotvalue1 = 1 + 4 + 4 + 2 + 5 = 16 bytes as opposed to 70bytes of storage and a bunch of string manipulations. There is also great benefit for references: type + oid + classid = 9 bytes (vs. 37 on average) And even 40% for persistent slots: key = oid + classid + slotid = 10 (vs. 36) value = 5 (same) There are some challenges here. What happens if a non-persistent class is redefined? Probably the same that happens today, actually. This may be highly problematic to do in a backwards compatible way, but we could have an interim release that predicated deserialization semantics on the database version. So we save 3-5x storage and accordingly, probably 3-5x time for a negligible increase in main memory but for more complexity (tighter coupling between the serializer behavior and the current database. Maybe we could get a 'summer of code' project or two going on to extend / improve elephant and see if we can get it ready for a 1.0 release and mainstream use? Just an idle thought... You might want to forward excerpts of this discussion to the list for archival purposes! Robert L. Read wrote: > Dear Ian, > > You understand my thought better than I do. > > > Ultimately I think all these variations come down to trying to deal with > > the tension between persistence semantics, performance and concurrency. > > There is also the desire to implement a consistent CRUD interface for > a wide range or Tier 2 (business rule) objects (that's using the > terminology > of 6 years ago, perhaps it has progressed.) > > > > > DCM, if I understand you correctly, deals with archiving in-memory > > objects in a simple way. It is providing ODB semantics, addressing > > performance issues by keeping active objects in-memory and allowing for > > persistence by moving to a slower storage. It ignores concurrency. > > The semantic benefits are that you access and find objects the same way > > regardless of how they're stored; it's a separation of concerns (storage > > latency vs. indexing). > > Yes. The separation of concerns is key; in fact, it support a > non-persistent > model as well, although I don't actually use that in my current app. > > > > > Prevalence tries to solve the performance problem using traditional DB > > semantics and ignoring process or machine level concurrency. This is > > appropriate for most web environments with a single, multi-threaded > > application server. > > > > Elephant builds on top of BDB's model of supporting full ACID > > characteristics in the face of multi-process (but not multi-machine) > > concurrency, moderate performance levels (library vs. client/server) and > > so requires the more complex semantics of transactions. > > > > > > Now I'm not so sure that my indexing support helps your performance > > goals. You still have to index into the btree structures which, in the > > random case, will require log(N) disk accesses on retrieval. Elephant > > is more than happy to allow you to keep in-memory indices of persistent > > objects; they just don't persist between sessions. > > You're right; class indexing doesn't help. But being able to say > "Get me all objects in this class" is much easier with what you have done. > In fact, I have not yet felt the need for any indexing (beyond on the > primary > key, or id, of the objects.) But its nice to know that arrow is in my > quiver. > I think people really don't twig to how big a gigabyte really is, and with > 16-gig machines just around the corner, the old "look it up in the > database > every time" is as old a broadcast television. Of course, sometimes one > need to build an in-memory index (data structure) but even then with > no I/O > one can rip through a large set of objects very quickly on modern > machines. > > > > > The big improvement in speed I imagine we're looking for is being able > > to cache slot values in memory. This means for fast objects we have to > > back off on supporting concurrency. Ideally it seems we'd want to be > > able to declare a class or more likely an instance, to be one of > > 'local', 'local persistent' and 'global persistent' with semantics as > > follows: > > Yes --- personally, I like managing concurrency at the "director" level, > rather than the database level. I have a hunch that one ends up doing > it anyway---it just takes a little in-memory state to force concurrency > headaches. > > > > 'local' - uses the local indexing system but otherwise just like any > > other in-memory object > > 'local persistent' - uses the local indexing system, caches values > > in-memory but supports write through semantics so that any writes are > > persistent. This is basically like prevalence but might be slightly > > more costly than just writing a log file as we have to index and update > > the btree. This does not support concurrency and a given thread or > > process could perhaps 'lock' the entry so that there is no > > interference. The downside vs. typical prevalence is that we are still > > using the more complex ODB semantics rather than a simple logging > semantics. > > 'global persistent' - the current model > > I can't comment intelligently on that. > > > > > Some cheap features we might add to elephant to enable the DCM and > > prevalence models: > > > > 1) Allow for cached instance data - requires modifying the object > > shared-initialize protocol for allocating storage and the read/write > > protocol for accessing slot data (effort: medium) > > > > We can have a write-through mode to support the prevalence model or a > > 'snapshot' only model which does not provide ACID compliance but avoids > > the write overhead and instead allows a snapshot to be taken > > periodically by writing instance data to the underlying elephant store. > > > > new parameter: (make-instance 'foo :ele-allocation > > :local/local-writethrough/global) > > new api: (change-allocation instance :local/local- writethrough/global) > > (snapshot instance/index/:all) > > > > If you downgraded from local-persistent to global the local storage > > wouldn't be reclaimed until the object was garbage collected and > > re-retrieved because we'd rely on the underlying object storage. > > > > 2) Hierarchical indexing: not sure there's a natural semantics for > > this. One way might be to allow for an option which indicates :local, > > :global or :all to the retrieval functions (get-instances-for...). A > > local inverted index would be maintained in-memory allowing for :local > > retrievals to avoid going to memory, global to go after long-term memory > > and :all to do both (effort: medium) > > Yes (I think.) The ability to add function-based indexes that are very > lightweight in-memory, reconstitutable things seems like a powerful > feature to me. > > Let me mention another direction that I have been thinking of (which your > "liveness" discussion already hints at): > > 1) I would like to build an intelligent, use-analyzing "generational" > manager. > The relative use of each object is recorded, and the desired resource > allocation > (in terms of megabytes) in each layer of the storage hierarchy is > automatically > managed. So invisibly, without thought from the program, the system > decides to > move objects up and down the storager hierarchy based on usage. (This is > quite different than the current explicit usage that gdcm requires; > but it > is a step. > > 2) The current CLSQL serialization is horribly inefficient (by a > factor or > five, easy.) As I've mentioned, this doesn't bother me, because I only > go to the database on writes and at startup. But it could become an > issue. > An OBDB (or a relational one) could instead of using a context-free > serializer > could attempt to serialize an object in the context of the DCM > collection (or > your class indexing) in which it resides. For example, if one images a > class that has a slot that has some Guassian or Poisson distribution, > then one > could build a "compressing serializer". The effect would, I think, be > especially > tiny representations of the stored data. In my model of the universe > this > makes it all the more reasonable to move "up" the storage hierarchy > for the > "home" position of some object. In essence, you can make a 1 gigabyte > store > even bigger, and the number of pages you have to read from the disc > even smaller. > This would make a nice PhD thesis, btw. My own dissertation was somewhat > related to this. Unfortunately, doing that now would be "premature > optimization" > of my current business plans. > > > > > > > Anyway, a few thoughts to let simmer until the next time we feel > ambitious! > > > > Ian > > > > Thanks. I really appreciate all you have done; I don't mind > continuing to > be the maintainer of Elephant, but if you would rather take over that > would > be fine with me. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From read at robertlread.net Thu May 11 03:10:22 2006 From: read at robertlread.net (Robert L. Read) Date: Wed, 10 May 2006 22:10:22 -0500 Subject: [elephant-devel] Volunteers needed for testing in preparation of releasing 0.6.0 Message-ID: <1147317022.3377.186.camel@localhost.localdomain> Dear Team, Ian Eslick has now finished the alpha-candidate release of 0.6.0. This contains a very significant feature enhancement: the automatic indexing of slots in persistent classes. The associated API is very powerful. Like many things in computer programming, this doesn't let you do much you could not do before; but it makes it very, very convenient. This feature make 0.6.0 even easier to use for many applications, and even easier to prototype with. Moreover, Ian rewrote the internal structure, making it clearer and cleaner, although that should only be of interest to Elephant developers. Additionally, I have added a package called Data Collection Management (DCM) to the new "contrib" directory. This package is a layer on top of Elephant that is particularly convenient if you prefer create-read-update-delete semantics and like the idea of being able to choose the storage style as a strategy pattern. DCM has only sporadic internal documentation, but it has some test cases. Additionally, Ian has put a lot of time into making sure that one can upgrade from a 0.5.0 database to a 0.6.0 database smoothly. This is part of our attempt to mature Elephant, and to demonstrate that it is ready for serious applications and that in the future we will always provide a migration path to the latest release version. As you can imagine, this piece of functionality is somewhat harder to test than the main product. Before anyone attempts to upgrade a data store that they care about, they must remember to follow the standard procedure of first BACKING UP their data before upgrading, even though the upgrade process is not destructive. Upgrading the version of a repository is accomplished by migrating the data from an old (0.5.0) repository to a new repository. It is internally documented in the file "migrate.lisp". I have written some user-documentation about the other features of 0.6.0 but not the upgrade path. As you know, one of the great things that Ben Lee and Andrew Blumberg initiated and has been continuously strengthened is the extensive automated test suite containing more than 100 tests. The 0.5.0 release was tested and all-green under ACL, OpenMCL, and SBCL, on the BerkeleyDB backend and the SQLLite and Postgres SQL-based. Ideally, before giving 0.6.0 a formal release we would complete this matrix: LISP ACL OpenMCL SBCL Backend BerekeleyDB Tests?/Upgrade? Tests?/Upgrade? Tests?/Upgrade? Postgres Tests?/Upgrade? Tests?/Upgrade? Tests?/Upgrade? SQLLite Tests?/Upgrade? Tests?/Upgrade? Tests?/Upgrade? (Elephant is probably easily portable to other LISPs and easily supports other SQLs, but that issue is separate from release 0.6.0). I therefore ask for volunteers to perform the test suites and test upgrade migration on these LISP/backend combinations. (We may not get all of these combinations tested.) I have tagged the CVS repository ELEPHANT-0-6-0-rc2, as a reference point in case bugs are found. If you get the head of the CVS repository now (see http://common-lisp.net/project/elephant/ for instructions), that is what you will get. Ian has agreed to be more or less on call to deal with bugs that are found, and I will be actively managing things and assisting Ian. If this release is successful, I think I will put some energy into publicizing the project; it will be too useful not to be widely used. Thanks. ---- Robert L. Read, PhD read &T robertlread.net Consider visiting Progressive Engineering: http://robertlread.net/pe In Austin: 912-8593 "Think globally, Act locally." -- RBF -------------- next part -------------- An HTML attachment was scrubbed... URL: From read at robertlread.net Mon May 15 19:26:15 2006 From: read at robertlread.net (Robert L. Read) Date: Mon, 15 May 2006 14:26:15 -0500 Subject: [elephant-devel] Current test matrix for 0.6.0 Message-ID: <1147721175.3759.5.camel@localhost.localdomain> Ian and I have now completed part of the ideal tests matrix (he's probably done some upgrade tests, when I know for sure I will fill in this matrix further.) LISP ACL OpenMCL SBCL Backend BerekeleyDB Green/Upgrade? Tests?/Upgrade? Green/Upgrade? Postgres Tests?/Upgrade? Tests?/Upgrade? Green/Upgrade? SQLLite Green/Upgrade? Tests?/Upgrade? Green/Upgrade? Can I have someone who used OpenMCL check out the latest version and run the automated test suite, at least on BerkeleyDB, for example? ---- Robert L. Read, PhD read &T robertlread.net Consider visiting Progressive Engineering: http://robertlread.net/pe In Austin: 912-8593 "Think globally, Act locally." -- RBF -------------- next part -------------- An HTML attachment was scrubbed... URL: From read at robertlread.net Tue May 23 01:45:43 2006 From: read at robertlread.net (Robert L. Read) Date: Mon, 22 May 2006 20:45:43 -0500 Subject: [elephant-devel] Request for some sort of response.... Message-ID: <1148348744.3759.160.camel@localhost.localdomain> Is the mailing list broken, or have my recent posts calling for the testing of 0.6.0 just been extraordinarily soporific? Based on subscriptions to this lists, I think the use of Elephant is increasing rather than decreasing, but I would like to hear from someone to know that this communication channel still has some affect. Somebody please respond to this, or, if you prefer, respond to me personally at the address below. ---- Robert L. Read, PhD read &T robertlread.net Consider visiting Progressive Engineering: http://robertlread.net/pe In Austin: 912-8593 "Think globally, Act locally." -- RBF -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjg-lisp at pentaside.org Tue May 23 03:29:04 2006 From: tjg-lisp at pentaside.org (Tayssir John Gabbour) Date: Tue, 23 May 2006 05:29:04 +0200 Subject: [elephant-devel] Request for some sort of response.... In-Reply-To: <1148348744.3759.160.camel@localhost.localdomain> References: <1148348744.3759.160.camel@localhost.localdomain> Message-ID: <44728180.6000209@pentaside.org> Robert L. Read wrote: > Somebody please respond to this, or, if you prefer, respond to me > personally at the address below. Hi Robert. Sure, I'll help test... writing it down in my calendar for tomorrow. (I didn't read the volunteer email carefully, and assumed it was for people who already had serious codebases to test the upcoming version, rather than simply installing it and running your test cases...) Tayssir From cjstuij at gmail.com Tue May 23 12:48:07 2006 From: cjstuij at gmail.com (Ties Stuij) Date: Tue, 23 May 2006 14:48:07 +0200 Subject: [elephant-devel] Request for some sort of response.... In-Reply-To: References: <1148348744.3759.160.camel@localhost.localdomain> <44728180.6000209@pentaside.org> Message-ID: > When i open another database in the same image from within slime > everything works fine. When i for example try to close it from the > console, i get the same error. > > This makes developing a bit unpractical. Any ideas? > Worse, no matter if i have put objects in the database from either slime or console. When i try to get them on a webpage i also get the same error: While accessing database # with expression "SELECT VALUE FROM KEYVALUE WHERE ((CLCTN_ID = 0) AND (KEY = 'FRwAAAAzAAAAIAAAAEIAAABFAAAATAAAAEwAAABZAAAA'))": Error 21 / library routine called out of sequence has occurred. [Condition of type CLSQL-SYS:SQL-DATABASE-DATA-ERROR] greets, Ties From eslick at csail.mit.edu Tue May 23 13:08:54 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Tue, 23 May 2006 09:08:54 -0400 Subject: [elephant-devel] Request for some sort of response.... In-Reply-To: References: <1148348744.3759.160.camel@localhost.localdomain> <44728180.6000209@pentaside.org> Message-ID: <44730966.3010408@csail.mit.edu> Is it just me or am I accurately recalling that SQLite is not thread safe? MySQL and PostgreSQL should both work fine in this configuration? There is also an issue with properly binding shared variables into multiple threads accessing elephant. This has not been fully debugged so if you can reproduce the problem in MySQL for instance, I'll take the time to work through any threading issues you are having. Ian Ties Stuij wrote: >> When i open another database in the same image from within slime >> everything works fine. When i for example try to close it from the >> console, i get the same error. >> >> This makes developing a bit unpractical. Any ideas? >> > > Worse, no matter if i have put objects in the database from either > slime or console. When i try to get them on a webpage i also get the > same error: > > While accessing database # /home/zeno/lisp/sqlite3/ele9.db OPEN {D70DD81}> > with expression "SELECT VALUE FROM KEYVALUE WHERE ((CLCTN_ID = 0) > AND (KEY = 'FRwAAAAzAAAAIAAAAEIAAABFAAAATAAAAEwAAABZAAAA'))": > Error 21 / library routine called out of sequence > has occurred. > [Condition of type CLSQL-SYS:SQL-DATABASE-DATA-ERROR] > > greets, > Ties > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From cjstuij at gmail.com Tue May 23 11:00:04 2006 From: cjstuij at gmail.com (Ties Stuij) Date: Tue, 23 May 2006 13:00:04 +0200 Subject: [elephant-devel] Request for some sort of response.... In-Reply-To: <44728180.6000209@pentaside.org> References: <1148348744.3759.160.camel@localhost.localdomain> <44728180.6000209@pentaside.org> Message-ID: He there, Yes i've got a test result of sorts. Mind you, all the tests bar one run fine with sbcl 9.12 cvs elephant and sqlite3, but i've got another problem. When i load elephant on a console (together with ucw) and i try to access it from slime i get errors like: While accessing database # with expression "SELECT last_value,is_called FROM _CLSQL_SEQ_PERSISTENT_SEQ": Error 21 / library routine called out of sequence has occurred. [Condition of type CLSQL-SYS:SQL-DATABASE-DATA-ERROR] When i open another database in the same image from within slime everything works fine. When i for example try to close it from the console, i get the same error. This makes developing a bit unpractical. Any ideas? greets, Ties From cjstuij at gmail.com Tue May 23 18:04:01 2006 From: cjstuij at gmail.com (Ties Stuij) Date: Tue, 23 May 2006 20:04:01 +0200 Subject: [elephant-devel] Request for some sort of response.... In-Reply-To: <44730966.3010408@csail.mit.edu> References: <1148348744.3759.160.camel@localhost.localdomain> <44728180.6000209@pentaside.org> <44730966.3010408@csail.mit.edu> Message-ID: On 5/23/06, Ian Eslick wrote: > Is it just me or am I accurately recalling that SQLite is not thread > safe? MySQL and PostgreSQL should > both work fine in this configuration? > > There is also an issue with properly binding shared variables into > multiple threads accessing elephant. > This has not been fully debugged so if you can reproduce the problem in > MySQL for instance, I'll > take the time to work through any threading issues you are having. Thanks, didn't think about threads. I read up on it a bit and sqlite3 is thread-safe-ish. It has to be built with a threadsafe flag and even then it has some ifs and buts. I tried postgresql and it works perfectly fine up until now. Also the test-suite couldn't make a fault on my sbcl 9.12. greets, Ties From read at robertlread.net Sat May 27 20:05:07 2006 From: read at robertlread.net (Robert L. Read) Date: Sat, 27 May 2006 15:05:07 -0500 Subject: [elephant-devel] Elephant 0.6.0 is now released. Message-ID: <1148760307.3759.290.camel@localhost.localdomain> The latest release of the Elephant persistent object store is now available. It is numbered 0.6.0. It may be obtained from the project page either as a downloaded tgz file, or you make access it via anonymous CVS. http://common-lisp.net/project/elephant/ Ian Eslick made most of the code contributions to this release, which features a very elegant method of indexing the slots of a persistent class. For developers, the internals of Elephant were also significantly refactored by Ian. Additionally, a layer of data management on top of Elephant that implements a Director-like pattern called Data Collection Management has been added to the contrib directory. In addition to personally thanking Ian, I would like to say that I personally think Elephant has grown into an extraordinarily useful project. Let me just review the major advantages of Elephant as a persistent object store: 1) Extraordinarily convenient for the programmer, 2) An extensive test suite, 3) Tested on several major LISP implementations (ACL, SBCL, OpenMCL), 4) Ability to use multiple back-end data repositories and to migrate whole data stores seamlessly between those repositories, 5) Ability to BerkeleyDB, PostGres, SQLite 3, and probably other back- end databases, 6) Extremely convenient slot and functional indexing that can be dynamically changed. The overall effect of these features together is that Elephant is very flexible for serious application development: you can change fundamental implementation decisions easily as your application evolves. ---- Robert L. Read, PhD read &T robertlread.net Consider visiting Progressive Engineering: http://robertlread.net/pe In Austin: 912-8593 "Think globally, Act locally." -- RBF -------------- next part -------------- An HTML attachment was scrubbed... URL: From aycan.irican at core.gen.tr Sun May 28 11:15:43 2006 From: aycan.irican at core.gen.tr (Aycan iRiCAN) Date: Sun, 28 May 2006 14:15:43 +0300 Subject: [elephant-devel] Problem: The name NIL does not designate any package Message-ID: <87ejyetn6o.fsf@core.gen.tr> Hello, I just checked out the latest elephant from cvs. I'm getting this error with my existing web application (without existing data): ; loading system definition from /usr/share/common-lisp/systems/ele-bdb.asd ; into # ; registering # as ELE-BDB STYLE-WARNING: implicitly creating new generic function BUILD-BTREE-INDEX debugger invoked on a SIMPLE-ERROR in thread #: Error during processing of --eval option (LOAD #P"bin/start.lisp"): The name NIL does not designate any package. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [RETRY ] Retry performing # on #. 1: [ACCEPT ] Continue, treating # on # as having been successful. 2: [CONTINUE] Ignore and continue with next --eval option. 3: [ABORT ] Skip rest of --eval options. 4: Skip to toplevel READ/EVAL/PRINT loop. 5: [QUIT ] Quit SBCL (calling #'QUIT, killing the process). ((LAMBDA (SB-IMPL::E)) #) Any ideas? (Note: sbcl 0.9.12, linux x86) Best Regards, -- Aycan iRiCAN C0R3 Computer Security Group http://www.core.gen.tr -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From eslick at csail.mit.edu Sun May 28 14:23:38 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Sun, 28 May 2006 10:23:38 -0400 Subject: [elephant-devel] Problem: The name NIL does not designate any package In-Reply-To: <87ejyetn6o.fsf@core.gen.tr> References: <87ejyetn6o.fsf@core.gen.tr> Message-ID: <4479B26A.4080208@csail.mit.edu> Can you provide some more information? For example, can you load elephant by itself without loading the webapp? What are the contents of the file 'system'? Ian Aycan iRiCAN wrote: > Hello, > > I just checked out the latest elephant from cvs. I'm getting this > error with my existing web application (without existing data): > > ; loading system definition from /usr/share/common-lisp/systems/ele-bdb.asd > ; into # > ; registering # as ELE-BDB > STYLE-WARNING: implicitly creating new generic function BUILD-BTREE-INDEX > > debugger invoked on a SIMPLE-ERROR in thread > #: > Error during processing of --eval option (LOAD #P"bin/start.lisp"): > > The name NIL does not designate any package. > > Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. > > restarts (invokable by number or by possibly-abbreviated name): > 0: [RETRY ] Retry performing # on > #. > 1: [ACCEPT ] Continue, treating # on > # as having been > successful. > 2: [CONTINUE] Ignore and continue with next --eval option. > 3: [ABORT ] Skip rest of --eval options. > 4: Skip to toplevel READ/EVAL/PRINT loop. > 5: [QUIT ] Quit SBCL (calling #'QUIT, killing the process). > > ((LAMBDA (SB-IMPL::E)) #) > > Any ideas? > > (Note: sbcl 0.9.12, linux x86) > > Best Regards, > > > ------------------------------------------------------------------------ > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From der_julian at web.de Tue May 30 17:50:08 2006 From: der_julian at web.de (Julian Stecklina) Date: Tue, 30 May 2006 19:50:08 +0200 Subject: [elephant-devel] Fixes for CMUCL on FreeBSD Message-ID: <86r72bjtbj.fsf@dellbeast.localhost> Hello, the following patch is required for me to run Elephant 0.6.0: -------------- next part -------------- A non-text attachment was scrubbed... Name: elephant-bsd.patch Type: text/x-patch Size: 1651 bytes Desc: elephant patch URL: -------------- next part -------------- Regards, -- Julian Stecklina Being really good at C++ is like being really good at using rocks to sharpen sticks. - Thant Tessman From read at robertlread.net Tue May 30 18:35:06 2006 From: read at robertlread.net (Robert L. Read) Date: Tue, 30 May 2006 13:35:06 -0500 Subject: [elephant-devel] Fixes for CMUCL on FreeBSD In-Reply-To: <86r72bjtbj.fsf@dellbeast.localhost> References: <86r72bjtbj.fsf@dellbeast.localhost> Message-ID: <1149014107.3759.368.camel@localhost.localdomain> Thanks. I'll incorporate that patch tomorrow. On Tue, 2006-05-30 at 19:50 +0200, Julian Stecklina wrote: > Hello, > > the following patch is required for me to run Elephant 0.6.0: > > Regards, > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From der_julian at web.de Tue May 30 18:44:47 2006 From: der_julian at web.de (Julian Stecklina) Date: Tue, 30 May 2006 20:44:47 +0200 Subject: [elephant-devel] Fixes for CMUCL on FreeBSD In-Reply-To: <1149014107.3759.368.camel@localhost.localdomain> (Robert L. Read's message of "Tue, 30 May 2006 13:35:06 -0500") References: <86r72bjtbj.fsf@dellbeast.localhost> <1149014107.3759.368.camel@localhost.localdomain> Message-ID: <86zmgzfj34.fsf@dellbeast.localhost> "Robert L. Read" writes: > Thanks.? I'll incorporate that patch tomorrow. I just discovered that there is another misspelling of "freebsd" in elephant.asd. Copy'n'paste strikes back. :) Regards, -- Julian Stecklina Being really good at C++ is like being really good at using rocks to sharpen sticks. - Thant Tessman From read at robertlread.net Tue May 30 18:52:45 2006 From: read at robertlread.net (Robert L. Read) Date: Tue, 30 May 2006 13:52:45 -0500 Subject: [elephant-devel] Fixes for CMUCL on FreeBSD In-Reply-To: <86zmgzfj34.fsf@dellbeast.localhost> References: <86r72bjtbj.fsf@dellbeast.localhost> <1149014107.3759.368.camel@localhost.localdomain> <86zmgzfj34.fsf@dellbeast.localhost> Message-ID: <1149015165.3759.370.camel@localhost.localdomain> On Tue, 2006-05-30 at 20:44 +0200, Julian Stecklina wrote: > "Robert L. Read" writes: > > > Thanks. I'll incorporate that patch tomorrow. > > I just discovered that there is another misspelling of "freebsd" in > elephant.asd. Copy'n'paste strikes back. :) > > Regards, Whoops. My only excuse is I don't have a freebsd system to test on; thanks for the patch. I'll grep it out. ---- Robert L. Read, PhD read &T robertlread.net Consider visiting Progressive Engineering: http://robertlread.net/pe In Austin: 912-8593 "Think globally, Act locally." -- RBF -------------- next part -------------- An HTML attachment was scrubbed... URL: From aycan.irican at core.gen.tr Wed May 31 11:36:17 2006 From: aycan.irican at core.gen.tr (Aycan iRiCAN) Date: Wed, 31 May 2006 14:36:17 +0300 Subject: [elephant-devel] Problem: The name NIL does not designate any package In-Reply-To: <4479B26A.4080208@csail.mit.edu> (Ian Eslick's message of "Sun, 28 May 2006 10:23:38 -0400") References: <87ejyetn6o.fsf@core.gen.tr> <4479B26A.4080208@csail.mit.edu> Message-ID: <87vermfmtq.fsf@core.gen.tr> Ian Eslick writes: > Can you provide some more information? For example, can you load > elephant by itself without loading the webapp? What are the contents > of the file 'system'? Further examination showed us that this is not a problem with elephant but our code. We're trying to open the store before a package declaration. Thus elephant tries to intern a symbol to NIL. Best Regards, -- Aycan iRiCAN C0R3 Computer Security Group http://www.core.gen.tr -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From eslick at csail.mit.edu Wed May 31 11:49:36 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Wed, 31 May 2006 07:49:36 -0400 Subject: [elephant-devel] Problem: The name NIL does not designate any package In-Reply-To: <87vermfmtq.fsf@core.gen.tr> References: <87ejyetn6o.fsf@core.gen.tr> <4479B26A.4080208@csail.mit.edu> <87vermfmtq.fsf@core.gen.tr> Message-ID: <447D82D0.4010701@csail.mit.edu> Ok, good luck and let me know if you have any problems with elephant 0.6.0! Ian Aycan iRiCAN wrote: > Ian Eslick writes: > > >> Can you provide some more information? For example, can you load >> elephant by itself without loading the webapp? What are the contents >> of the file 'system'? >> > > Further examination showed us that this is not a problem with elephant > but our code. We're trying to open the store before a package > declaration. Thus elephant tries to intern a symbol to NIL. > > Best Regards, > > > ------------------------------------------------------------------------ > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel