From mb at bese.it Mon Mar 1 12:55:23 2004 From: mb at bese.it (Marco Baringer) Date: Mon, 1 Mar 2004 13:55:23 +0100 Subject: [Bese-devel] UnCommon Web 0.2.0 - learning to crawl Message-ID: i've put up version 0.2.0 of ucw at: ftp://ftp.common-lisp.net/pub/project/ucw/ucw_0.2.0.tar.gz i'm going to release it tomorow, would people mind downloading it and making sure i haven't botched the tar ball in some stupid way? -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From mb at bese.it Tue Mar 2 18:17:14 2004 From: mb at bese.it (Marco Baringer) Date: Tue, 2 Mar 2004 19:17:14 +0100 Subject: [Bese-devel] Re: Proposal (was: [Lispweb] [ANN] UnCommon Web 0.2 - learning to walk) In-Reply-To: <20040302165232.GA6890@www> Message-ID: On Marted?, mar 2, 2004, at 17:52 Europe/Rome, rm at fabula.de wrote: > Just a question: i'm currently using the yaclml:tal stuff from within > araneida. > What do you think of making LOOKUP-TAL-VARIABLE a generic method > instead of a > function? That way one could path all sorts of interesting things to > the tal renderer. > Think of specialising lookup-tal-variable for uncommonsql queries that > return > CLOS objects ... one could do a TAL:DOLIST over a query result and > have a method > that returns the slot values of CLOS object. I think it's an excellent idea (sorta goes against the whole "code in one place presentation elswhere" idea, but I'm still deciding about that). However, we'd need to define a tal enviroment api, would this cover everything you need: (defgeneric lookup-tal-variable (name enviroment) (:documentation "Return the value assciated with NAME (a symbol) in the enviroment ENVIROMENT.")) (defgeneric extend-tal-enviroment (new-env old-env) (:documentation "Create a new enviroment with all the bindings in both NEW-ENV and OLD-ENV. If both enviroments bind the same names the bindings in NEW-ENV must shadow those in OLD-ENV.")) (defgeneric add-binding (name value enviroment) (:documentation "Create a new enviroment which is like ENVIROMENT but also has VALUE bound to NAME.")) This should be enough to genericly implement DOLIST and INCLUDE which are, so far, the only tags i have which mess with the enviroment. It's been implemented in yaclml--dev--0.4--patch-5. Makes me wonder if cacheable/lazy enviroments would be a good idea. p.s. - Would it be dificult to write an araneida backend for ucw? -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From rm at fabula.de Tue Mar 2 18:34:54 2004 From: rm at fabula.de (rm at fabula.de) Date: Tue, 2 Mar 2004 19:34:54 +0100 Subject: [Bese-devel] Re: Proposal (was: [Lispweb] [ANN] UnCommon Web 0.2 - learning to walk) In-Reply-To: References: <20040302165232.GA6890@www> Message-ID: <20040302183454.GC6890@www> On Tue, Mar 02, 2004 at 07:17:14PM +0100, Marco Baringer wrote: > > I think it's an excellent idea (sorta goes against the whole "code in > one place presentation elswhere" idea, but I'm still deciding about > that). Well, i just got tired ouf having to build a deeply nested plist that mirrors the objects i want to render -- the code has to walk the object structure to create the plist which is then walked by the tal function. > However, we'd need to define a tal enviroment api, would this > cover everything you need: > > (defgeneric lookup-tal-variable (name enviroment) > (:documentation "Return the value assciated with NAME (a > symbol) in the enviroment ENVIROMENT.")) > > (defgeneric extend-tal-enviroment (new-env old-env) > (:documentation "Create a new enviroment with all the bindings > in both NEW-ENV and OLD-ENV. If both enviroments bind the same > names the bindings in NEW-ENV must shadow those in OLD-ENV.")) > > (defgeneric add-binding (name value enviroment) > (:documentation "Create a new enviroment which is like > ENVIROMENT but also has VALUE bound to NAME.")) Ah, i see. So your code does in fact modify the environment. I guess i would imagine a stack based environment object with a generic 'fetch-value (name)'. A lookup would would apply this method to all objects on the stack until successfull. > > This should be enough to genericly implement DOLIST and INCLUDE which > are, so far, the only tags i have which mess with the enviroment. It's > been implemented in yaclml--dev--0.4--patch-5. Good ;-) I'll check it out. > Makes me wonder if cacheable/lazy enviroments would be a good idea. In certain cases i'd think so. > > p.s. - Would it be dificult to write an araneida backend for ucw? Gosh, i'm not the person to ask this, just an araneida beginner myself (desperately lokking for documentation) :-) I would be fine to have one but i'm affraid i'm way too busy right now to hack one myself. Thank's RalfD > - > Marco > Ring the bells that still can ring. > Forget the perfect offering. > There is a crack in everything. > That's how the light gets in. > -Leonard Cohen > > > _______________________________________________ > Lispweb mailing list > Lispweb at red-bean.com > http://www.red-bean.com/mailman/listinfo/lispweb From mb at bese.it Tue Mar 2 19:38:52 2004 From: mb at bese.it (Marco Baringer) Date: Tue, 2 Mar 2004 20:38:52 +0100 Subject: [Bese-devel] Re: Proposal (was: [Lispweb] [ANN] UnCommon Web 0.2 - learning to walk) In-Reply-To: <20040302183454.GC6890@www> Message-ID: <3C81E1CA-6C81-11D8-9C2B-000393599076@bese.it> On Marted?, mar 2, 2004, at 19:34 Europe/Rome, rm at fabula.de wrote: > Well, i just got tired ouf having to build a deeply nested plist > that mirrors the objects i want to render -- the code has to walk > the object structure to create the plist which is then walked by the > tal function. i get tired of that too. i guess we need a better way to create enviroments, for starts slots-to-tal-enviroment should probably be moved from ucw to yaclml. > Ah, i see. So your code does in fact modify the environment. otherwise there is no way from within a dolist to access the "outer" bindings. > I guess i would imagine a stack based environment object with a generic > 'fetch-value (name)'. A lookup would would apply this method to all > objects on the stack until successfull. Come to think of it this would also allow us to use different binding mechanisms (hash tables if there are lots of bindings; directly use objects instead of converting the slots to a list; etc.) based on the specs. We could do this with: (defgeneric lookup-tal-variable (name enviroment) (:documentation "Return the value assciated with NAME in the enviroment ENVIROMENT.")) (defgeneric fetch-value (name binding) (:documentation "Return the value associated with NAME in the binding set BINDING.")) (defgeneric push-binding (binding enviroment) (:documentation "Create a new enviroment with all the bindings in BINDING. Any bindings in BINDING must shadow (on successive calls to LOOKUP-TAL-VARIABLE) other bindings currently present in ENVIROMENT.")) (defgeneric add-binding (name value binding) (:documentation "Create a new binding which is like BINDING but also has VALUE bound to NAME.")) The standard implementation of push-binding would generally be enough for whatever you wanted to do, and we'd provide standard methods which operate on lists (used by include), but you could, if the need arises, change any part of it. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From g.castaldi at quinary.com Wed Mar 3 07:49:53 2004 From: g.castaldi at quinary.com (Giannandrea Castaldi) Date: Wed, 03 Mar 2004 08:49:53 +0100 Subject: [Bese-devel] Compilation errof for mod_lisp.c Message-ID: <40458E21.6090807@quinary.com> Hi, I know that this is not an apache mailing list but I've had the following error executing the mod_lisp installation (apxs2 -i -c mod_lisp.c) for ucw and then maybe someone may help me. I'm using Gentoo distribution of Linux with apache-2.0.48-r1. I have found apxs2 and not apxs but it's the new version. I haven't found the command httpd to verify the dynamic lib support but only the script /etc/init.d/apache2 to start it. I can anyway pass to apache-1.3.29-r1. Giannandrea calcolino mod-lisp # apxs2 -i -c mod_lisp.c /usr/lib/apache2/build/libtool --silent --mode=compile gcc -prefer-pic -march=pentium3 -O3 -pipe -fomit-frame-pointer -DAP_HAVE_DESIGNATED_INITIALIZER -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -pthread -I/usr/include/apache2 -I/usr/include/apache2 -I/usr/include/apache2 -c -o mod_lisp.lo mod_lisp.c && touch mod_lisp.slo mod_lisp.c:149:58: util_date.h: No such file or directory mod_lisp.c:196: parse error before '*' token mod_lisp.c:196: warning: data definition has no type or storage class mod_lisp.c:209: parse error before "lisp_module" mod_lisp.c:209: warning: data definition has no type or storage class mod_lisp.c: In function `our_dconfig': mod_lisp.c:339: request for member `module_index' in something not a structure or union mod_lisp.c: At top level: mod_lisp.c:467: parse error before '*' token mod_lisp.c: In function `SendLispString': mod_lisp.c:470: `Line' undeclared (first use in this function) mod_lisp.c:470: (Each undeclared identifier is reported only once mod_lisp.c:470: for each function it appears in.) mod_lisp.c:471: `BuffSocket' undeclared (first use in this function) mod_lisp.c: At top level: mod_lisp.c:477: parse error before '*' token mod_lisp.c: In function `SendLispHeaderLine': mod_lisp.c:479: `BuffSocket' undeclared (first use in this function) mod_lisp.c:479: `Name' undeclared (first use in this function) mod_lisp.c:483: `Value' undeclared (first use in this function) mod_lisp.c: At top level: mod_lisp.c:490: parse error before '*' token mod_lisp.c: In function `FlushLispBuffSocket': mod_lisp.c:492: `BuffSocket' undeclared (first use in this function) mod_lisp.c: At top level: mod_lisp.c:511: parse error before "BUFF" mod_lisp.c: In function `ForceGets': mod_lisp.c:517: `s' undeclared (first use in this function) mod_lisp.c:517: `len' undeclared (first use in this function) mod_lisp.c:517: `BuffSocket' undeclared (first use in this function) mod_lisp.c:520: `B_RD' undeclared (first use in this function) mod_lisp.c: In function `lisp_handler': mod_lisp.c:563: `BUFF' undeclared (first use in this function) mod_lisp.c:563: `BuffSocket' undeclared (first use in this function) mod_lisp.c:591: `SERVER_ERROR' undeclared (first use in this function) mod_lisp.c:593: `B_SOCKET' undeclared (first use in this function) mod_lisp.c:593: `B_RDWR' undeclared (first use in this function) mod_lisp.c:612: `array_header' undeclared (first use in this function) mod_lisp.c:612: `env_arr' undeclared (first use in this function) mod_lisp.c:613: `table_entry' undeclared (first use in this function) mod_lisp.c:613: `elts' undeclared (first use in this function) mod_lisp.c:613: parse error before ')' token mod_lisp.c:664: `hdr_arr' undeclared (first use in this function) mod_lisp.c:665: parse error before ')' token mod_lisp.c:726: parse error before ')' token mod_lisp.c:729: `l' undeclared (first use in this function) mod_lisp.c:737: parse error before ')' token mod_lisp.c:746: warning: initialization makes pointer from integer without a cast mod_lisp.c:753: warning: assignment makes pointer from integer without a cast mod_lisp.c:776: warning: passing arg 4 of `ap_log_error' makes integer from pointer without a cast mod_lisp.c:776: warning: passing arg 5 of `ap_log_error' from incompatible pointer type mod_lisp.c:780: warning: passing arg 4 of `ap_log_error' makes integer from pointer without a cast mod_lisp.c:780: warning: passing arg 5 of `ap_log_error' from incompatible pointer type mod_lisp.c:784: warning: passing arg 4 of `ap_log_error' makes integer from pointer without a cast mod_lisp.c:784: warning: passing arg 5 of `ap_log_error' from incompatible pointer type mod_lisp.c:788: warning: passing arg 4 of `ap_log_error' makes integer from pointer without a cast mod_lisp.c:788: warning: passing arg 5 of `ap_log_error' from incompatible pointer type mod_lisp.c:792: warning: passing arg 4 of `ap_log_error' makes integer from pointer without a cast mod_lisp.c:792: warning: passing arg 5 of `ap_log_error' from incompatible pointer type mod_lisp.c:796: warning: passing arg 4 of `ap_log_error' makes integer from pointer without a cast mod_lisp.c:796: warning: passing arg 5 of `ap_log_error' from incompatible pointer type mod_lisp.c:800: warning: passing arg 4 of `ap_log_error' makes integer from pointer without a cast mod_lisp.c:800: warning: passing arg 5 of `ap_log_error' from incompatible pointer type mod_lisp.c:804: warning: passing arg 4 of `ap_log_error' makes integer from pointer without a cast mod_lisp.c:804: warning: passing arg 5 of `ap_log_error' from incompatible pointer type mod_lisp.c:808: warning: passing arg 4 of `ap_log_error' makes integer from pointer without a cast mod_lisp.c:808: warning: passing arg 5 of `ap_log_error' from incompatible pointer type mod_lisp.c:735: break statement not within loop or switch mod_lisp.c: At top level: mod_lisp.c:828: warning: parameter names (without types) in function declaration mod_lisp.c:828: warning: data definition has no type or storage class mod_lisp.c:829: parse error before "if" mod_lisp.c:855: warning: parameter names (without types) in function declaration mod_lisp.c:855: warning: data definition has no type or storage class mod_lisp.c:856: parse error before "if" mod_lisp.c:907: parse error before "pool" mod_lisp.c: In function `lisp_init': mod_lisp.c:909: warning: passing arg 1 of `ap_add_version_component' from incompatible pointer type mod_lisp.c:909: too few arguments to function `ap_add_version_component' mod_lisp.c: At top level: mod_lisp.c:928: parse error before "pool" mod_lisp.c: In function `lisp_child_init': mod_lisp.c:930: warning: assignment makes pointer from integer without a cast mod_lisp.c: At top level: mod_lisp.c:950: parse error before "pool" mod_lisp.c:968: parse error before '*' token mod_lisp.c: In function `lisp_create_dir_config': mod_lisp.c:972: `dirspec' undeclared (first use in this function) mod_lisp.c:977: `p' undeclared (first use in this function) mod_lisp.c:992: warning: assignment makes pointer from integer without a cast mod_lisp.c: At top level: mod_lisp.c:1011: parse error before '*' token mod_lisp.c: In function `lisp_merge_dir_config': mod_lisp.c:1015: `p' undeclared (first use in this function) mod_lisp.c:1016: `parent_conf' undeclared (first use in this function) mod_lisp.c:1017: `newloc_conf' undeclared (first use in this function) mod_lisp.c:1024: warning: assignment makes pointer from integer without a cast mod_lisp.c: At top level: mod_lisp.c:1073: parse error before '*' token mod_lisp.c: In function `lisp_create_server_config': mod_lisp.c:1077: `s' undeclared (first use in this function) mod_lisp.c:1083: `p' undeclared (first use in this function) mod_lisp.c:1093: warning: assignment makes pointer from integer without a cast mod_lisp.c: At top level: mod_lisp.c:1110: parse error before '*' token mod_lisp.c: In function `lisp_merge_server_config': mod_lisp.c:1114: `p' undeclared (first use in this function) mod_lisp.c:1115: `server1_conf' undeclared (first use in this function) mod_lisp.c:1116: `server2_conf' undeclared (first use in this function) mod_lisp.c:1126: warning: assignment makes pointer from integer without a cast mod_lisp.c: At top level: mod_lisp.c:1331: warning: initialization from incompatible pointer type mod_lisp.c:1362: parse error before "lisp_handlers" mod_lisp.c:1364: warning: braces around scalar initializer mod_lisp.c:1364: warning: (near initialization for `lisp_handlers[0]') mod_lisp.c:1364: warning: initialization makes integer from pointer without a cast mod_lisp.c:1364: warning: excess elements in scalar initializer mod_lisp.c:1364: warning: (near initialization for `lisp_handlers[0]') mod_lisp.c:1365: warning: braces around scalar initializer mod_lisp.c:1365: warning: (near initialization for `lisp_handlers[1]') mod_lisp.c:1365: warning: initialization makes integer from pointer without a cast mod_lisp.c:1366: warning: data definition has no type or storage class mod_lisp.c:1382: conflicting types for `lisp_module' mod_lisp.c:209: previous declaration of `lisp_module' mod_lisp.c:1384: `this_module_needs_to_be_ported_to_apache_2_0' undeclared here (not in a function) mod_lisp.c:1384: initializer element is not constant mod_lisp.c:1384: (near initialization for `lisp_module.version') mod_lisp.c:1385: warning: initialization makes integer from pointer without a cast mod_lisp.c:1386: warning: initialization makes integer from pointer without a cast mod_lisp.c:1387: warning: initialization from incompatible pointer type mod_lisp.c:1389: warning: initialization from incompatible pointer type mod_lisp.c:1390: warning: initialization makes integer from pointer without a cast mod_lisp.c:1391: warning: initialization from incompatible pointer type mod_lisp.c:1392: warning: initialization from incompatible pointer type mod_lisp.c:1393: warning: initialization from incompatible pointer type mod_lisp.c:1394: warning: initialization from incompatible pointer type mod_lisp.c:1395: warning: initialization from incompatible pointer type mod_lisp.c:1396: warning: initialization from incompatible pointer type mod_lisp.c:1397: warning: initialization from incompatible pointer type mod_lisp.c:1398: warning: excess elements in struct initializer mod_lisp.c:1398: warning: (near initialization for `lisp_module') mod_lisp.c:1400: warning: excess elements in struct initializer mod_lisp.c:1400: warning: (near initialization for `lisp_module') mod_lisp.c:1403: warning: excess elements in struct initializer mod_lisp.c:1403: warning: (near initialization for `lisp_module') mod_lisp.c:1406: warning: excess elements in struct initializer mod_lisp.c:1406: warning: (near initialization for `lisp_module') mod_lisp.c:1411: warning: excess elements in struct initializer mod_lisp.c:1411: warning: (near initialization for `lisp_module') apxs:Error: Command failed with rc=65536 From mb at bese.it Wed Mar 3 08:03:06 2004 From: mb at bese.it (Marco Baringer) Date: Wed, 3 Mar 2004 09:03:06 +0100 Subject: [Bese-devel] Compilation errof for mod_lisp.c In-Reply-To: <40458E21.6090807@quinary.com> Message-ID: <344BF032-6CE9-11D8-9C2B-000393599076@bese.it> On Mercoled?, mar 3, 2004, at 08:49 Europe/Rome, Giannandrea Castaldi wrote: > Hi, > I know that this is not an apache mailing list but I've had the > following error executing the mod_lisp installation (apxs2 -i -c > mod_lisp.c) for ucw and then maybe someone may help me. > I'm using Gentoo distribution of Linux with apache-2.0.48-r1. I have > found apxs2 and not apxs but it's the new version. I haven't found the > command httpd to verify the dynamic lib support but only the script > /etc/init.d/apache2 to start it. > I can anyway pass to apache-1.3.29-r1. the mod-lisp distributed with ucw is for apache1.X, apache2 has a completly different API. macro antoniotti has kindly given me a version of mod_lisp ported to apache2, however i've never tested it and don't know enough about apache2 to say how i should be installed. I'm attaching it and if you manage to get ucw working with it that'd be great. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mod_lisp2.c URL: -------------- next part -------------- -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From mb at bese.it Wed Mar 3 13:22:46 2004 From: mb at bese.it (Marco Baringer) Date: Wed, 3 Mar 2004 14:22:46 +0100 Subject: [Bese-devel] Re: Proposal (was: [Lispweb] [ANN] UnCommon Web 0.2 - learning to walk) In-Reply-To: <3C81E1CA-6C81-11D8-9C2B-000393599076@bese.it> Message-ID: get yaclml--dev--0.4--patch-7 and you'll find the tal enviroment based on three methods: (defgeneric lookup-tal-variable (name enviroment) (:documentation "Return the value assciated with NAME in the enviroment ENVIROMENT.")) (defgeneric fetch-value (name binding) (:documentation "Return the value associated with NAME in the binding set BINDING.")) (defgeneric push-binding (binding enviroment) (:documentation "Create a new enviroment with all the bindings in BINDING. Any bindings in BINDING must shadow (on successive calls to LOOKUP-TAL-VARIABLE) other bindings currently present in ENVIROMENT.")) (defun make-standard-enviroment (&rest binding-sets) "Given a list of binding-sets (BINDING-SETS) creates a new standard TAL enviroment. The enviroment is created by, conceptually, taking the elements of binding-sets in reverse order and push-binding them onto an initially empty enviroment.") I removed add-binding since that's binding-set specific (for example the binding-set based on objects doesn't even have it). I've included an implementation of fetch-value for standard-objects, hash tables and alists, which should cover most common uses. Binding-sets in an enviroment can, and, in ucw at least, often are, be of different types. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From mb at bese.it Wed Mar 3 15:29:34 2004 From: mb at bese.it (Marco Baringer) Date: Wed, 3 Mar 2004 16:29:34 +0100 Subject: [Bese-devel] Re: Proposal (was: [Lispweb] [ANN] UnCommon Web 0.2 - learning to walk) In-Reply-To: <20040303144424.GD10925@www> Message-ID: <92DA5EE2-6D27-11D8-913F-000393599076@bese.it> On Mercoled?, mar 3, 2004, at 15:44 Europe/Rome, rm at fabula.de wrote: > On Wed, Mar 03, 2004 at 02:22:46PM +0100, Marco Baringer wrote: >> >> get yaclml--dev--0.4--patch-7 and you'll find the tal enviroment based >> on three methods: > > Hmm, i seem to have problems with arch (grr, i hate tools where i > seem to not understand the docs at all). > > > bash-2.05b$ tla my-default-archive bese-2004 at common-lisp.net > bash-2.05b$ tla revisions yaclml--dev--0.4 > bash-2.05b$ well, that sucks. aparently everything you're doing is correct. is the location for bese-2004 at common-lisp.net exactly 'http://www.common-lisp.net/project/bese/bese-2004 at common-lisp.net'? since it appears to work i've put up a 0.4.1 dist at: ftp://ftp.common-lisp.net/pub/project/bese/yaclml/yaclml_0.4.1.tar.gz -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From rm at fabula.de Wed Mar 3 14:44:24 2004 From: rm at fabula.de (rm at fabula.de) Date: Wed, 3 Mar 2004 15:44:24 +0100 Subject: [Bese-devel] Re: Proposal (was: [Lispweb] [ANN] UnCommon Web 0.2 - learning to walk) In-Reply-To: References: <3C81E1CA-6C81-11D8-9C2B-000393599076@bese.it> Message-ID: <20040303144424.GD10925@www> On Wed, Mar 03, 2004 at 02:22:46PM +0100, Marco Baringer wrote: > > get yaclml--dev--0.4--patch-7 and you'll find the tal enviroment based > on three methods: Hmm, i seem to have problems with arch (grr, i hate tools where i seem to not understand the docs at all). bash-2.05b$ tla my-default-archive bese-2004 at common-lisp.net bash-2.05b$ tla revisions yaclml--dev--0.4 bash-2.05b$ Note: no revisions reported! bash-2.05b$ tla get bese-2004 at common-lisp.net/yaclml--dev--0.4 get: no revisions in version (bese-2004 at common-lisp.net/bese-2004 at common-lisp.net/yaclml--dev--0.4) ???? RalfD From rm at fabula.de Wed Mar 3 15:48:36 2004 From: rm at fabula.de (rm at fabula.de) Date: Wed, 3 Mar 2004 16:48:36 +0100 Subject: [Bese-devel] Re: Proposal (was: [Lispweb] [ANN] UnCommon Web 0.2 - learning to walk) In-Reply-To: <92DA5EE2-6D27-11D8-913F-000393599076@bese.it> References: <20040303144424.GD10925@www> <92DA5EE2-6D27-11D8-913F-000393599076@bese.it> Message-ID: <20040303154836.GE10925@www> On Wed, Mar 03, 2004 at 04:29:34PM +0100, Marco Baringer wrote: > > well, that sucks. aparently everything you're doing is correct. is the > location for bese-2004 at common-lisp.net exactly > 'http://www.common-lisp.net/project/bese/bese-2004 at common-lisp.net'? > > since it appears to work i've put up a 0.4.1 dist at: Ah, that was it -- somehow the bese-2004 at common-lisp.net as pointing at the wrong archive location -- everything works fine now. Thanks RalfD From g.castaldi at quinary.com Thu Mar 4 12:26:16 2004 From: g.castaldi at quinary.com (Giannandrea Castaldi) Date: Thu, 04 Mar 2004 13:26:16 +0100 Subject: [Bese-devel] Compilation errof for mod_lisp.c In-Reply-To: <344BF032-6CE9-11D8-9C2B-000393599076@bese.it> References: <344BF032-6CE9-11D8-9C2B-000393599076@bese.it> Message-ID: <40472068.7070800@quinary.com> Hi, I've installed the mod_lisp2.c in Apache2 without problem. For the configuration I've added the LoadModule command in the file apache2.conf (the AddModule command there isn't anymore in Apache2) and now I should execute 'LispServer 127.0.0.1 3001 "ucw"' but I don't know where type it (in the file apache2.conf?). Another question, in the ucw.pdf there is "The id address must be that of the machine running UnCommon Web and the port must be port UCW is listening for" but I haven't found how to start ucw. Thanks for the help. Giannandrea From mb at bese.it Thu Mar 4 13:23:40 2004 From: mb at bese.it (Marco Baringer) Date: Thu, 4 Mar 2004 14:23:40 +0100 Subject: [Bese-devel] Compilation errof for mod_lisp.c In-Reply-To: <40472068.7070800@quinary.com> Message-ID: <26A0B88F-6DDF-11D8-913F-000393599076@bese.it> On Gioved?, mar 4, 2004, at 13:26 Europe/Rome, Giannandrea Castaldi wrote: > Hi, > I've installed the mod_lisp2.c in Apache2 without problem. For the > configuration I've added the LoadModule command in the file > apache2.conf (the AddModule command there isn't anymore in Apache2) > and now I should execute 'LispServer 127.0.0.1 3001 "ucw"' but I don't > know where type it (in the file apache2.conf?). i just downloaded and installed apache 2.0.48, i ran apxs -i -c mod_lisp2.c and added this to my httpd.conf (i don't have a file named apache2.conf): LoadModule lisp_module modules/mod_lisp2.so LispServer 127.0.0.1 3001 "ucw" Then at the bottow of the config file i added: SetHandler lisp-handler I was then able to start ucw (by loading the run-examples-mod_lisp.lisp file), and some things worked and some things didn't, the socket handling code in mod_lisp2 isn't perfect. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From g.castaldi at quinary.com Thu Mar 4 13:49:40 2004 From: g.castaldi at quinary.com (Giannandrea Castaldi) Date: Thu, 04 Mar 2004 14:49:40 +0100 Subject: [Bese-devel] Compilation errof for mod_lisp.c In-Reply-To: <26A0B88F-6DDF-11D8-913F-000393599076@bese.it> References: <26A0B88F-6DDF-11D8-913F-000393599076@bese.it> Message-ID: <404733F4.6070401@quinary.com> Hi, I'm sorry for all the problems I send you but I've tried to start run-examples-mod_lisp.lisp and I've found that I must install acl-compat, I've tried to install it (asdf-install:install "acl-compat") but I've the following error: The slot ASDF::RELATIVE-PATHNAME is unbound in the object # [Condition of type UNBOUND-SLOT] Restarts: 0: [RETRY] Retry installation 1: [ABORT] Return to Slime toplevel. 2: [ABORT] Return to Top-Level. Backtrace: 0: ("DEFMETHOD SLOT-UNBOUND (T T T)" # # # # ...) 1: ("DEFMETHOD COMPONENT-RELATIVE-PATHNAME (MODULE)" (#(NIL 2) . #()) # #) 2: ("DEFMETHOD COMPONENT-PATHNAME (COMPONENT)" # # #) 3: (COMMON-LISP-CONTROLLER::BENEATH-SOURCE-ROOT? #) 4: ("DEFMETHOD ASDF:OUTPUT-FILES :AROUND (ASDF:OPERATION ASDF:COMPONENT)" # #S(PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (2)) # #) 5: ("DEFMETHOD OPERATION-DONE-P (OPERATION COMPONENT)" # # # #) 6: ("DEFMETHOD TRAVERSE (OPERATION COMPONENT)" (#(NIL 5) . #()) # # #) 7: (ASDF::DO-DEP ASDF:COMPILE-OP (:CMUCL-GRAYSTREAM :CL-PPCRE :PURI)) 8: ("DEFMETHOD TRAVERSE (OPERATION COMPONENT)" (#(NIL 5) . #()) # # #) 9: (ASDF::DO-DEP ASDF:COMPILE-OP ("acl-compat")) 10: ("DEFMETHOD TRAVERSE (OPERATION COMPONENT)" (#(NIL 5) . #()) # # #) 11: (ASDF:OPERATE ASDF:LOAD-OP "acl-compat") 12: (ASDF:OPERATE 2 ASDF:LOAD-OP "acl-compat")[:EXTERNAL] 13: (ASDF-INSTALL::ONE-ITER ("acl-compat")) 14: (ASDF-INSTALL:INSTALL "acl-compat") 15: (ASDF-INSTALL:INSTALL 1)[:EXTERNAL] It's strange because I've already used asdf and asdf-install to install many package: USER> (in-package asdf) # ASDF> (apropos 'relative-pathname) RELATIVE-PATHNAME COMPONENT-RELATIVE-PATHNAME [function] SLOT-ACCESSOR-NAME::|ASDF RELATIVE-PATHNAME slot READER| [function] SLOT-ACCESSOR-NAME::|ASDF RELATIVE-PATHNAME slot BOUNDP| SLOT-ACCESSOR-NAME::|ASDF RELATIVE-PATHNAME slot WRITER| [function] ; No value ASDF> any help? Thanks a lot. Giannandrea From mb at bese.it Thu Mar 4 15:20:55 2004 From: mb at bese.it (Marco Baringer) Date: Thu, 4 Mar 2004 16:20:55 +0100 Subject: [Bese-devel] Compilation errof for mod_lisp.c In-Reply-To: <404733F4.6070401@quinary.com> Message-ID: <87F47259-6DEF-11D8-BCC5-000393599076@bese.it> On Gioved?, mar 4, 2004, at 14:49 Europe/Rome, Giannandrea Castaldi wrote: > [snip acl-compat problems] > any help? I don't know. The first thing i can think of is that the version of acl-compat installed via asdf-install is old, maybe... try using the versions of the libs distributied with ucw (assuming you get the 0.2.0 tarball), see the README file fer instructions on how to setup UCW using just those versions of the various libs. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From g.castaldi at quinary.com Thu Mar 4 17:24:58 2004 From: g.castaldi at quinary.com (Giannandrea Castaldi) Date: Thu, 04 Mar 2004 18:24:58 +0100 Subject: [Bese-devel] Compilation errof for mod_lisp.c In-Reply-To: <87F47259-6DEF-11D8-BCC5-000393599076@bese.it> References: <87F47259-6DEF-11D8-BCC5-000393599076@bese.it> Message-ID: <4047666A.8020606@quinary.com> Marco Baringer wrote: > On Gioved?, mar 4, 2004, at 14:49 Europe/Rome, Giannandrea Castaldi > wrote: > >> [snip acl-compat problems] >> any help? > > > I don't know. The first thing i can think of is that the version of > acl-compat installed via asdf-install is old, maybe... > > try using the versions of the libs distributied with ucw (assuming you > get the 0.2.0 tarball), see the README file fer instructions on how to > setup UCW using just those versions of the various libs. > > -- > Marco > Ring the bells that still can ring. > Forget the perfect offering. > There is a crack in everything. > That's how the light gets in. > -Leonard Cohen > > Hi, I'm using your library but I've the following error: File-error in function TRUENAME: The file "library:subsystems/gray-streams-library.x86f" does not exist. [Condition of type KERNEL:SIMPLE-FILE-ERROR] Restarts: 0: [CONTINUE] Return NIL from load of #p"/home/gcast/.asdf-install-dir/systems/acl-compat.asd". 1: [CONTINUE] Return NIL from load of "/home/gcast/.asdf-install-dir/site/ucw_0.2.0/examples/run-examples-mod-lisp.lisp". 2: [ABORT] Return to Slime toplevel. 3: [ABORT] Return to Top-Level. Backtrace: 0: (TRUENAME "library:subsystems/gray-streams-library.x86f") 1: ("Top-Level Form")[:TOP-LEVEL] 2: (COMMON-LISP::SLOLOAD #) 3: (COMMON-LISP::INTERNAL-LOAD #p"/home/gcast/.asdf-install-dir/systems/acl-compat.asd" #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/acl-compat/acl-compat.asd" :ERROR :SOURCE) 4: (COMMON-LISP::INTERNAL-LOAD #p"/home/gcast/.asdf-install-dir/systems/acl-compat.asd" #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/acl-compat/acl-compat.asd" :ERROR NIL) 5: (LOAD #p"/home/gcast/.asdf-install-dir/systems/acl-compat.asd" :VERBOSE NIL :PRINT ...) 6: (ASDF:FIND-SYSTEM "acl-compat" NIL) 7: ("DEFMETHOD FIND-COMPONENT ((EQL NIL) T)" # # # "acl-compat" ...) 8: (ASDF::DO-ONE-DEP ASDF:COMPILE-OP :ACL-COMPAT NIL) 9: (ASDF::DO-DEP ASDF:COMPILE-OP (:ACL-COMPAT :UCW)) 10: ("DEFMETHOD TRAVERSE (OPERATION COMPONENT)" (#(NIL 5) . #()) # # #) 11: (ASDF::DO-DEP ASDF:COMPILE-OP ("ucw.mod-lisp")) 12: ("DEFMETHOD TRAVERSE (OPERATION COMPONENT)" (#(NIL 5) . #()) # # #) 13: (ASDF:OPERATE ASDF:LOAD-OP :UCW.MOD-LISP) 14: (ASDF:OPERATE 2 ASDF:LOAD-OP :UCW.MOD-LISP)[:EXTERNAL] 15: (COMMON-LISP::SLOLOAD #) 16: (COMMON-LISP::INTERNAL-LOAD #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/examples/run-examples-mod-lisp.lisp" #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/examples/run-examples-mod-lisp.lisp" :ERROR :SOURCE) 17: (COMMON-LISP::INTERNAL-LOAD #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/examples/run-examples-mod-lisp.lisp" #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/examples/run-examples-mod-lisp.lisp" :ERROR NIL) 18: (LOAD "/home/gcast/.asdf-install-dir/site/ucw_0.2.0/examples/run-examples-mod-lisp.lisp" :VERBOSE NIL :PRINT ...) Thanks for the help. Giannandrea From mb at bese.it Thu Mar 4 17:35:56 2004 From: mb at bese.it (Marco Baringer) Date: Thu, 4 Mar 2004 18:35:56 +0100 Subject: [Bese-devel] Compilation errof for mod_lisp.c In-Reply-To: <4047666A.8020606@quinary.com> Message-ID: <64A3E9C6-6E02-11D8-BCC5-000393599076@bese.it> On Gioved?, mar 4, 2004, at 18:24 Europe/Rome, Giannandrea Castaldi wrote: > Hi, > I'm using your library but I've the following error: > > File-error in function TRUENAME: > The file "library:subsystems/gray-streams-library.x86f" does not > exist. > [Condition of type KERNEL:SIMPLE-FILE-ERROR] This really looks like a messed up CMUCL install . What's happening is that acl-compat is attempting to load the gray-streams system. On CMUCL this is usually distributed with cmucl and placed in a particular directory along with the other cmucl subsystems (like clx and hemlock). Does the file $CMUCL_LIB_DIR/subsystems/gray-streams-sibrary.x86f actually exist? Can you try re-unpacking your CMUCL tarball and putting that file where CMUCL expocts to find it? -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From g.castaldi at quinary.com Thu Mar 4 17:33:15 2004 From: g.castaldi at quinary.com (Giannandrea Castaldi) Date: Thu, 04 Mar 2004 18:33:15 +0100 Subject: [Bese-devel] Compilation errof for mod_lisp.c In-Reply-To: <4047666A.8020606@quinary.com> References: <87F47259-6DEF-11D8-BCC5-000393599076@bese.it> <4047666A.8020606@quinary.com> Message-ID: <4047685B.70101@quinary.com> Giannandrea Castaldi wrote: > Marco Baringer wrote: > >> On Gioved?, mar 4, 2004, at 14:49 Europe/Rome, Giannandrea Castaldi >> wrote: >> >>> [snip acl-compat problems] >>> any help? >> >> >> >> I don't know. The first thing i can think of is that the version of >> acl-compat installed via asdf-install is old, maybe... >> >> try using the versions of the libs distributied with ucw (assuming >> you get the 0.2.0 tarball), see the README file fer instructions on >> how to setup UCW using just those versions of the various libs. >> >> -- >> Marco >> Ring the bells that still can ring. >> Forget the perfect offering. >> There is a crack in everything. >> That's how the light gets in. >> -Leonard Cohen >> >> > Hi, > I'm using your library but I've the following error: > > File-error in function TRUENAME: > The file "library:subsystems/gray-streams-library.x86f" does not exist. > [Condition of type KERNEL:SIMPLE-FILE-ERROR] > > Restarts: > 0: [CONTINUE] Return NIL from load of > #p"/home/gcast/.asdf-install-dir/systems/acl-compat.asd". > 1: [CONTINUE] Return NIL from load of > "/home/gcast/.asdf-install-dir/site/ucw_0.2.0/examples/run-examples-mod-lisp.lisp". > > 2: [ABORT] Return to Slime toplevel. > 3: [ABORT] Return to Top-Level. > > Backtrace: > 0: (TRUENAME "library:subsystems/gray-streams-library.x86f") > 1: ("Top-Level Form")[:TOP-LEVEL] > 2: (COMMON-LISP::SLOLOAD # "/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/acl-compat/acl-compat.asd">) > > 3: (COMMON-LISP::INTERNAL-LOAD > #p"/home/gcast/.asdf-install-dir/systems/acl-compat.asd" > #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/acl-compat/acl-compat.asd" > :ERROR :SOURCE) > 4: (COMMON-LISP::INTERNAL-LOAD > #p"/home/gcast/.asdf-install-dir/systems/acl-compat.asd" > #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/acl-compat/acl-compat.asd" > :ERROR NIL) > 5: (LOAD #p"/home/gcast/.asdf-install-dir/systems/acl-compat.asd" > :VERBOSE NIL :PRINT ...) > 6: (ASDF:FIND-SYSTEM "acl-compat" NIL) > 7: ("DEFMETHOD FIND-COMPONENT ((EQL NIL) T)" # > # # "acl-compat" ...) > 8: (ASDF::DO-ONE-DEP ASDF:COMPILE-OP :ACL-COMPAT NIL) > 9: (ASDF::DO-DEP ASDF:COMPILE-OP (:ACL-COMPAT :UCW)) > 10: ("DEFMETHOD TRAVERSE (OPERATION COMPONENT)" (#(NIL 5) . #()) > # # # "ucw.mod-lisp" {485EB65D}>) > 11: (ASDF::DO-DEP ASDF:COMPILE-OP ("ucw.mod-lisp")) > 12: ("DEFMETHOD TRAVERSE (OPERATION COMPONENT)" (#(NIL 5) . #()) > # # # "ucw.mod-lisp" {485EB65D}>) > 13: (ASDF:OPERATE ASDF:LOAD-OP :UCW.MOD-LISP) > 14: (ASDF:OPERATE 2 ASDF:LOAD-OP :UCW.MOD-LISP)[:EXTERNAL] > 15: (COMMON-LISP::SLOLOAD # "/home/gcast/.asdf-install-dir/site/ucw_0.2.0/examples/run-examples-mod-lisp.lisp">) > > 16: (COMMON-LISP::INTERNAL-LOAD > #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/examples/run-examples-mod-lisp.lisp" > #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/examples/run-examples-mod-lisp.lisp" > :ERROR :SOURCE) > 17: (COMMON-LISP::INTERNAL-LOAD > #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/examples/run-examples-mod-lisp.lisp" > #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/examples/run-examples-mod-lisp.lisp" > :ERROR NIL) > 18: (LOAD > "/home/gcast/.asdf-install-dir/site/ucw_0.2.0/examples/run-examples-mod-lisp.lisp" > :VERBOSE NIL :PRINT ...) > > Thanks for the help. > > Giannandrea > > > > _______________________________________________ > bese-devel mailing list > bese-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/bese-devel Hi, The problem is that in my cmucl installation there isn't gray-streams. Thanks anyway. Giannandrea From mb at bese.it Thu Mar 4 22:26:14 2004 From: mb at bese.it (Marco Baringer) Date: Thu, 4 Mar 2004 23:26:14 +0100 Subject: [Bese-devel] Compilation errof for mod_lisp.c In-Reply-To: <4047685B.70101@quinary.com> Message-ID: On Gioved?, mar 4, 2004, at 18:33 Europe/Rome, Giannandrea Castaldi wrote: > Hi, > The problem is that in my cmucl installation there isn't gray-streams. > Thanks anyway. [che sfiga.] what version of cmucl? can you try just downloading a cmucl binary distribution and using that gray-streams? -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From mb at bese.it Fri Mar 5 10:06:02 2004 From: mb at bese.it (Marco Baringer) Date: Fri, 5 Mar 2004 11:06:02 +0100 Subject: [Bese-devel] the archives (the ucw development branch is MOVING!) Message-ID: just a quick note, i've upgraded to tla 1.2 and have added checksums to the ucw at common-lisp.net archive and bese-2004 at common-lisp.net archives. ucw version 0.2 development is going to happen in a new archive ucw-2004 at common-lisp.net, this archive will be signed with my gpg key (available from the cl.net keyring). The branch will be be ucw--dev--0.2. i realize that in the past three months i've moved or messed with all the archives twice and that this has created some confusion. sorry. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From jan at rychter.com Fri Mar 5 06:46:46 2004 From: jan at rychter.com (Jan Rychter) Date: Thu, 04 Mar 2004 22:46:46 -0800 Subject: [Bese-devel] Problems compiling 0.2.0 with CMUCL Message-ID: Hmm. I've posted this in local.ucw.devel on nntp.common-lisp.net, but this group seems to be attracting more attention. Is the other one dead? Here is what I get when trying to compile ucw: Execution of a form compiled with errors: (DEFMETHOD IT.BESE.UCW::REMOVE-EXPIRED-SESSIONS ((IT.BESE.UCW::APP IT.BESE.UCW::APPLICATION)) (WITH-HASH-TABLE-ITERATOR (IT.BESE.UCW::SESSION-ITERATOR #) (IT.BESE.ARNESI:WHILE-BIND # # #))) [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR] Restarts: 0: [CONTINUE] Return NIL from load of #p"/home/jwr/lisp/ucw_0.2.0/src/rerl/standard-application.x86f". 1: [RETRY] Retry performing # on #. 2: [ACCEPT] Continue, treating # on # as having been successful. 3: [ABORT] Return to SLIME toplevel. 4: [ABORT] Return to Top-Level. Backtrace: 0: (C::DO-CALL # 168 169 4 ...) 1: (LISP::FOP-FUNCALL-FOR-EFFECT) 2: (LISP::LOAD-GROUP #) 3: (LISP::FASLOAD #) 4: (LISP::INTERNAL-LOAD #p"/home/jwr/lisp/ucw_0.2.0/src/rerl/standard-application.x86f" #p"/home/jwr/lisp/ucw_0.2.0/src/rerl/standard-application.x86f" :ERROR :BINARY) 5: (LISP::INTERNAL-LOAD #p"/home/jwr/lisp/ucw_0.2.0/src/rerl/standard-application.x86f" #p"/home/jwr/lisp/ucw_0.2.0/src/rerl/standard-application.x86f" :ERROR NIL) 6: (LOAD #p"/home/jwr/lisp/ucw_0.2.0/src/rerl/standard-application.x86f" :VERBOSE NIL :PRINT ...) [...] Any hints? The same method compiles fine when compiled interactively From XEmacs. --J. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: From mb at bese.it Fri Mar 5 13:41:36 2004 From: mb at bese.it (Marco Baringer) Date: Fri, 5 Mar 2004 14:41:36 +0100 Subject: [Bese-devel] Problems compiling 0.2.0 with CMUCL In-Reply-To: Message-ID: On Venerd?, mar 5, 2004, at 07:46 Europe/Rome, Jan Rychter wrote: > Hmm. I've posted this in local.ucw.devel on nntp.common-lisp.net, but > this group seems to be attracting more attention. Is the other one > dead? yes, since there is quite a bit of overlap between ucw and bese (and not enough movement) i decided fairly early on to not use the ucw-devel mailing lists. i'll see about getting the ucw mailing lists removed from the nntp server. > Here is what I get when trying to compile ucw: > > Execution of a form compiled with errors: > (DEFMETHOD IT.BESE.UCW::REMOVE-EXPIRED-SESSIONS > ((IT.BESE.UCW::APP IT.BESE.UCW::APPLICATION)) > (WITH-HASH-TABLE-ITERATOR (IT.BESE.UCW::SESSION-ITERATOR #) > (IT.BESE.ARNESI:WHILE-BIND # # #))) > [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR] > [snip backtrace] > Any hints? The same method compiles fine when compiled interactively > From XEmacs. my understanding is that the code failed to compile yet the fasl file was written anyway, yet you say that if you compile it interactively it works fine, very weird. I'm guessing this must be a problem with loading/compiling the files out of order. could you try something: 1) load up a fresh cmucl instance. 2) (asdf:oos 'asdf:load-op :arnesi) 3) (asdf:oos 'asdf:load-op :yaclml) 4) C-cC-k ucw/src/packages.lisp 5) C-cC-k ucw/src/loggers.lisp 6) C-cC-k ucw/src/backend/protocol.lisp 7) C-cC-k ucw/src/rerl/protocol.lisp 8) C-cC-k ucw/src/rerl/standard-application.lisp 9) tell me about any and every warning/error you get. If you're able to do this then the asdf file must be missing a dependency some place. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From g.castaldi at quinary.com Fri Mar 5 17:02:49 2004 From: g.castaldi at quinary.com (Giannandrea Castaldi) Date: Fri, 05 Mar 2004 18:02:49 +0100 Subject: [Bese-devel] Compilation errof for mod_lisp.c In-Reply-To: References: Message-ID: <4048B2B9.9050007@quinary.com> Hi, Finally I've installed a new version of cmucl and apache (net-www/apache-1.3.29-r1) and now I launch the examples without problem but when I try to access the url http://127.0.0.1:3001/ucw/admin there is a timeout. Some info: I've added in /etc/apache/conf/apache.conf (there isn't httpd.conf): ... LoadModule lisp_module modules/mod_lisp.so (at the end of LoadModule section) ... AddModule mod_lisp.c (at the end of AddModule section) and at the end of /etc/apache/conf/commonapache.conf: LispServer 127.0.0.1 3001 "ucw" (I tried this line also at the end of apache2.conf) SetHandler lisp-handler I haven't found in both files SSLOptions and adding I've a failure. Any suggestion? Thanks. Giannandrea From mb at bese.it Fri Mar 5 17:27:02 2004 From: mb at bese.it (Marco Baringer) Date: Fri, 5 Mar 2004 18:27:02 +0100 Subject: [Bese-devel] Compilation errof for mod_lisp.c In-Reply-To: <4048B2B9.9050007@quinary.com> Message-ID: <50840F80-6ECA-11D8-A596-000393599076@bese.it> On Venerd?, mar 5, 2004, at 18:02 Europe/Rome, Giannandrea Castaldi wrote: > Hi, > Finally I've installed a new version of cmucl and apache > (net-www/apache-1.3.29-r1) and now I launch the examples without > problem yes! > but when I try to access the url http://127.0.0.1:3001/ucw/admin there > is a timeout. By default the admin app is at /ucw/admin/ (notice the trailing slash). You should see an INEXISTENT-APPLICATION error in your cmucl buffer. However, 3001 is the default port for the portableaserve backend, the mod_lisp backend listens off whatever port apache is listening off of, usually 80 or 8080. The mod_lisp backend listens on port 3001, but it waits for connections form _apache_ on that port, not connections from the browser. Connections from the browser have to go through apache and hence whatever port apache has been setup to listen off. Are you sure you're not runnig the portableaserve backend? > Some info: > I've added in /etc/apache/conf/apache.conf (there isn't httpd.conf): > ... > LoadModule lisp_module modules/mod_lisp.so (at the end of > LoadModule section) > ... > AddModule mod_lisp.c (at the end of AddModule section) > > and at the end of /etc/apache/conf/commonapache.conf: > > LispServer 127.0.0.1 3001 "ucw" (I tried this line also at the end of > apache2.conf) > > SetHandler lisp-handler > > > I haven't found in both files SSLOptions and adding I've a failure. SSLOptions only works if you have the ssl module built, i'm assuming you don't. > Any suggestion? > Thanks. thanks for being patient and working through this. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From jan at rychter.com Fri Mar 5 23:03:04 2004 From: jan at rychter.com (Jan Rychter) Date: Fri, 05 Mar 2004 15:03:04 -0800 Subject: [Bese-devel] Problems compiling 0.2.0 with CMUCL References: Message-ID: >>>>> "Marco" == Marco Baringer writes: Marco> On Venerd?, mar 5, 2004, at 07:46 Europe/Rome, Jan Rychter Marco> wrote: >> Hmm. I've posted this in local.ucw.devel on nntp.common-lisp.net, >> but this group seems to be attracting more attention. Is the other >> one dead? Marco> yes, since there is quite a bit of overlap between ucw and bese Marco> (and not enough movement) i decided fairly early on to not use Marco> the ucw-devel mailing lists. i'll see about getting the ucw Marco> mailing lists removed from the nntp server. Ah, ok, I see. Yes, I'd suggest just removing the other lists. Still, I do find the naming confusing -- I want to use UncommonWEB (UCW), so I go looking for... bese? Hmm. [...] Marco> could you try something: Marco> 1) load up a fresh cmucl instance. Marco> 2) (asdf:oos 'asdf:load-op :arnesi) Marco> 3) (asdf:oos 'asdf:load-op :yaclml) This step produces two problems: ; Byte Compiling Top-Level Form: ; Converted PARSE. ; Compiling DEFUN PARSE: ; ; ; File: /home/jwr/lisp/ucw_0.2.0/libs/yaclml/src/tal/xmls.lisp ; In: DEFUN TEST ; (PARSE (OPEN TEST) :COMPRESS-WHITESPACE T) ; Warning: :COMPRESS-WHITESPACE is not a known argument keyword. ; ; Converted TEST. ; Compiling DEFUN TEST: ; Byte Compiling Top-Level Form: ; /home/jwr/lisp/ucw_0.2.0/libs/yaclml/src/tal/xmls.x86f written. ; File: /home/jwr/lisp/ucw_0.2.0/libs/yaclml/src/tal/xmls.lisp ; In: DEFUN XMLS::TEST ; (TOXML (PARSE # :COMPRESS-WHITESPACE T) :INDENT T) ; Warning: Undefined function XMLS:TOXML ; Warning: This function is undefined: ; XMLS:TOXML ... but they don't seem to have much to do with what happens later. Marco> 4) C-cC-k ucw/src/packages.lisp Marco> 5) C-cC-k ucw/src/loggers.lisp Marco> 6) C-cC-k ucw/src/backend/protocol.lisp Marco> 7) C-cC-k ucw/src/rerl/protocol.lisp Marco> 8) C-cC-k ucw/src/rerl/standard-application.lisp At this point, I get: Execution of a form compiled with errors: (DEFMETHOD IT.BESE.UCW::REMOVE-EXPIRED-SESSIONS ((IT.BESE.UCW::APP IT.BESE.UCW::APPLICATION)) (WITH-HASH-TABLE-ITERATOR (IT.BESE.UCW::SESSION-ITERATOR (IT.BESE.UCW::APPLICATION.SESSION-TABLE IT.BESE.UCW::APP)) (IT.BESE.ARNESI:WHILE-BIND (IT.BESE.UCW::MORE? IT.BESE.UCW::SESSION-ID IT.BESE.UCW::SESSION) (IT.BESE.UCW::SESSION-ITERATOR) (WHEN (IT.BESE.UCW::EXPIREDP IT.BESE.UCW::SESSION) (IT.BESE.UCW::EXPIRE-SESSION IT.BESE.UCW::SESSION) (REMHASH IT.BESE.UCW::SESSION-ID (IT.BESE.UCW::APPLICATION.SESSION-TABLE IT.BESE.UCW::APP)))))) [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR] Marco> 9) tell me about any and every warning/error you get. Overall, at this point I get a number of errors and warnings. I've pasted the SLIME summary, let me know if you want more details. -+ Warnings (4) |-- These functions are undefined: | (SETF SESSION.ID) COOKIE INSERT-WITH-NEW-KEY |-- Undefined function INSERT-WITH-NEW-KEY |-- Undefined function COOKIE `-- Undefined function (SETF SESSION.ID) as the argument to FUNCTION -+ Errors (2) |-- (during macroexpansion) | Error in FDEFINITION: the function APPLICATION.SESSION-TABLE is undefined. `-- (during macroexpansion) Error in FDEFINITION: the function APPLICATION.SESSION-TABLE is undefined. The "Undefined function COOKIE" occurs in defmethod service, and INSERT-WITH-NEW-KEY is unknown in defmethod make-request-context. The (setf session.id) problem is from make-new-session. If I may humbly suggest one more thing. It might seem that packaging all required libraries makes things easier for beginners -- but it doesn't. Now that we have portable ASDF-INSTALL (many thanks to Dan Barlow and Edi Weitz), installing things like acl-compat, xmls or UFFI is easy. If you include these libraries, there is a whole new class of problems: duplicate libraries, your modified versions (are they modified or not?), etc. I understand that it is easier for you not to deal with the problems of various versions of libraries floating around (let's hope ASDF-INSTALL gets support for library versions soon, so that you can easily tell which version you have and easily upgrade to the latest version), but I still think it makes much more sense to push libraries towards inclusion in the ASDF-INSTALL system and work with the authors. It would go a long way towards creating a "CL world of software" instead of fragmented projects. thanks, --J. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: From jan at rychter.com Fri Mar 5 23:03:12 2004 From: jan at rychter.com (Jan Rychter) Date: Fri, 05 Mar 2004 15:03:12 -0800 Subject: [Bese-devel] the archives (the ucw development branch is MOVING!) References: Message-ID: >>>>> "Marco" == Marco Baringer writes: Marco> just a quick note, i've upgraded to tla 1.2 and have added Marco> checksums to the ucw at common-lisp.net archive and Marco> bese-2004 at common-lisp.net archives. Marco> ucw version 0.2 development is going to happen in a new archive Marco> ucw-2004 at common-lisp.net, this archive will be signed with my Marco> gpg key (available from the cl.net keyring). The branch will be Marco> be ucw--dev--0.2. Marco> i realize that in the past three months i've moved or messed Marco> with all the archives twice and that this has created some Marco> confusion. sorry. Thanks for the note. I wonder if there are people on this list that don't find arch confusing :-) It has certainly been very confusing for me. Do you find it significantly better than, say, subversion? (I guess the simple CVS is out of fashion these days) --J. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: From mb at bese.it Sat Mar 6 12:32:05 2004 From: mb at bese.it (Marco Baringer) Date: Sat, 6 Mar 2004 13:32:05 +0100 Subject: [Bese-devel] Problems compiling 0.2.0 with CMUCL In-Reply-To: Message-ID: <46F8E5D6-6F6A-11D8-8E2B-000393599076@bese.it> On Sabato, mar 6, 2004, at 00:03 Europe/Rome, Jan Rychter wrote: > Ah, ok, I see. Yes, I'd suggest just removing the other lists. Still, I > do find the naming confusing -- I want to use UncommonWEB (UCW), so I > go > looking for... bese? Hmm. Basically I don't think UCW, by itself, has enough of a community to merit it's own mailing list, while ucw+yaclml+arnesi+FiveAM does. > -+ Errors (2) > |-- (during macroexpansion) > | Error in FDEFINITION: the function APPLICATION.SESSION-TABLE is > undefined. > `-- (during macroexpansion) > Error in FDEFINITION: the function APPLICATION.SESSION-TABLE is > undefined. well, well, well. Here's the problem. The file standard-application defines the class standard-application which has an accessor application.session-table which is not part of the protocol. That accessor isn't defined unitl the defclass is executed, yet the with-hash-table-iterator macro tries to analyze its args at macro expansion time (this is probably a bug in cmucl), and doesn't find the function application.session-table (at least this is my understanding of the issue). ucw-2004 at common-lisp.net/ucw--dev--0.2--patch-5 moves all the class definitons into a seperate file (standard-classes.lisp) and loads that before the code which uses the classes and the accessors, this should fix the issue. > If I may humbly suggest one more thing. It might seem that packaging > all > required libraries makes things easier for beginners -- but it > doesn't. Now that we have portable ASDF-INSTALL (many thanks to Dan > Barlow and Edi Weitz), installing things like acl-compat, xmls or UFFI > is easy. If you include these libraries, there is a whole new class of > problems: duplicate libraries, your modified versions (are they > modified > or not?), etc. [Everyone has the right to humbly suggest anything, and is in fact incorreged to do so.] You are most certainly right, however there are the issues i have to deal with when making a ucw release: portableaserve - currently not asdf-installable. until very recently the stable version was 18 months old and ucw requried the CVS version. arnesi, yaclml and cl-icu - evolving with ucw, often ucw will depend on development versions of these libraries. xmls - the version included in yaclml is based on xmls version 1.0, but has been heavily modified[1] acl-compat and uffi - could easily be installed via asdf-install So basically i could, if i so desired, distribute ucw via asdf-install with just arnesi, yaclml and cl-icu and have instructions for getting portableaserve and use asdf-install to grab uffi (since you have to get portableaserve out of band anyway there's no need to also grab acl-compat). Maybe when a version 1.0 comes out i'll do just that, hopefully by that time (around 2018 :)) ucw will depend on stable, released and asdf-installable versions of portableaserve, uffi, acl-compat, yaclml, arnesi and cl-icu. Until then I think most people who grab UCW don't really want to use it to do major work, they just want to try it out, so asking them to change asdf:*central-registry* doesn't seem like a big deal (to me). Feedback welcome. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From mb at bese.it Sat Mar 6 12:37:42 2004 From: mb at bese.it (Marco Baringer) Date: Sat, 6 Mar 2004 13:37:42 +0100 Subject: [Bese-devel] Why we use arch [Was: the archives (the ucw development branch is MOVING!)] In-Reply-To: Message-ID: <1014EB28-6F6B-11D8-8E2B-000393599076@bese.it> On Sabato, mar 6, 2004, at 00:03 Europe/Rome, Jan Rychter wrote: > It has certainly been very confusing for me. Do you find it > significantly better than, say, subversion? (I guess the simple CVS is > out of fashion these days) [CVS is not just out of fashion, CVS would be a bad engineering choice for new projects.] Here's why, just under a year ago, I started using arch and have since stuck with it: 0) If you ever want to take ucw and modify it you can, completely independantly, branch from the ucw tree, selectvly update from the "official" ucw repo and easly send your patches back to me. You do not need commit rights on the main tree to develop UCW, you just need to tell we which patch to merge in, i do a 'tla replay ucw at rychter.com/ucw--cool-featureX--0.2--patch-3' and commit, this works, automatically resolves most conflicts when you, for example, updated with the main dev branch half way through your changes, and maintians all associated logs. 1) When I started using arch subversion did not have a stable release, maybe is was just FUD but the "grapevine" said to wait for 1.0 2) Arch works in terms of changesets, which contain a single log message, a globally (yes globally) unique id and all associated changes (renames, moves, adds, deletes and modifications). I find this to be a much better match to how I think than subversion's "every modification to the file system is a single, independent, change". Now, I could build something like this on top of subversion, and i'm sure someone has, but why do the extra work? 3) Arch knows which changesets have gone into a tree, this means that if i'm working on the yaclml--use-xmls--0.4 branch and i get a patch for yaclml--dev--0.4 i can apply that to the dev branch, merge that into the use-xmls branch and then, when i'm done with the use-xmls branch and want to merge it back into the dev branch arch knows that patch has already been applied. This makes branching and merging much more manageable. Subversion plans on addidng these merging features but hasn't yet. 4) Arch uses a dumb-server. While subversion requires a WebDAV server i was able to setup the arch repos on cl.net by simply creating a directory in my public_htdocs tree, at the same time all commits are done via ssh, subversion would have required much more work on erik's part. 5) Very recently arch has gained the ability to gpg sign all patches, while this isn't essential it does make me feel better. At the same time arch does have its quirks: 1) It imposes the weird category--branch--version--patch-level syntax. 2) Arch doesn't have the concept of a "root" repository, which is confusing. 3) When you update a tree you only get the patches in that revision, so if you have ucw--dev--0.1 and i strat working on ucw--dev--0.2 you won't get the patches from 0.2 unless you explicitly do a tla replay ucw--dev--0.2 and then tla set-tree-version ucw--dev--0.2. 4) Arch doesn't provide support for "symbolic" tags, and the configs are something of a joke. 5) arch can, at first, seem overwhelming with it's 100+ commands. so, i think arch is better than subversion, is arch better "enough" to make the added confusion worth it? i don't know. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From g.castaldi at quinary.com Mon Mar 8 07:48:35 2004 From: g.castaldi at quinary.com (Giannandrea Castaldi) Date: Mon, 08 Mar 2004 08:48:35 +0100 Subject: [Bese-devel] Compilation errof for mod_lisp.c In-Reply-To: References: Message-ID: <404C2553.5030501@quinary.com> Hi, How you can see from the netstat command the ucw server is listening on port 8080 (indeed the final line of repl is 'Example Server Running'). Also Apache is running without problem on port 80, the only message there is in error log about lisp is this: [Sun Mar 7 11:01:29 2004] [notice] Apache/1.3.29 (Unix) (Gentoo/Linux) mod_lisp/2.33 configured -- resuming normal operations but if I try to go with mozilla to http://127.0.0.1/ucw/admin/ in the status bar it says 'waiting for 127.0.0.1'. Looking at the Recv-Q column of the netstat result seems that ucw has sent the response but apache doesn't read it (from man netstat: Recv-Q: The count of bytes not copied by the user program connected to this socket.) Any suggestion? Thanks. Giannandrea. Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State User Inode tcp 0 0 127.0.0.1:32840 0.0.0.0:* LISTEN 1000 3738 tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 0 2519 tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 0 33389 tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 1000 3745 tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN 0 2791 tcp 551 0 127.0.0.1:8080 127.0.0.1:32863 CLOSE_WAIT 0 0 tcp 550 0 127.0.0.1:8080 127.0.0.1:32861 CLOSE_WAIT 0 0 tcp 526 0 127.0.0.1:8080 127.0.0.1:32859 CLOSE_WAIT 0 0 tcp 0 0 127.0.0.1:32839 127.0.0.1:32838 ESTABLISHED 1000 3736 tcp 525 0 127.0.0.1:8080 127.0.0.1:32857 CLOSE_WAIT 0 0 tcp 0 0 127.0.0.1:32838 127.0.0.1:32839 ESTABLISHED 1000 3737 tcp 0 0 127.0.0.1:32841 127.0.0.1:32840 ESTABLISHED 1000 3739 tcp 0 0 127.0.0.1:32840 127.0.0.1:32841 ESTABLISHED 1000 3740 tcp 550 0 127.0.0.1:8080 127.0.0.1:32849 CLOSE_WAIT 0 0 tcp 1 0 127.0.0.1:8080 127.0.0.1:32847 CLOSE_WAIT 1000 33034 tcp 526 0 127.0.0.1:8080 127.0.0.1:32866 CLOSE_WAIT 0 0 From ivan.toshkov at travelstoremaker.com Tue Mar 9 10:44:50 2004 From: ivan.toshkov at travelstoremaker.com (Ivan Toshkov) Date: Tue, 09 Mar 2004 12:44:50 +0200 Subject: [Bese-devel] UCW 0.2.0 Bug using SBCL or CMUCL on i386 Message-ID: <404DA022.7000406@travelstoremaker.com> Hi, I've tried to run the examples on i386 with CMUCL 18e and SBCL 0.8.8 and the following happens when I request a page from it: ---------------------------------------------------------------- * Reaping dead sessions. Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: #\f is not of type VECTOR Restarts: 0: [ABANDON] Abandon this request and wait for the next one 1: [DESTROY] Destroy the process Debug (type H for help) (VECTOR-PUSH-EXTEND 2 "" #\f "frob3-loooooooooooooong=val3-loooooooooooooong; frob2=val2; froba=vala")[:EXTERNAL] Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:code/array.lisp. 0] 0 ---------------------------------------------------------------- Regards, Ivan From mb at bese.it Tue Mar 9 11:12:36 2004 From: mb at bese.it (Marco Baringer) Date: Tue, 9 Mar 2004 12:12:36 +0100 Subject: [Bese-devel] UCW 0.2.0 Bug using SBCL or CMUCL on i386 In-Reply-To: <404DA022.7000406@travelstoremaker.com> Message-ID: On Marted?, mar 9, 2004, at 11:44 Europe/Rome, Ivan Toshkov wrote: > Hi, > > I've tried to run the examples on i386 with CMUCL 18e and SBCL 0.8.8 > and the following happens when I request a page from it: This looks like an error in the backend, are you using mod_lisp or portableaserve? can you send a backtrace? -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From sdr at jhb.ucs.co.za Tue Mar 9 11:16:52 2004 From: sdr at jhb.ucs.co.za (Sean Ross) Date: Tue, 09 Mar 2004 13:16:52 +0200 Subject: [Bese-devel] UCW 0.2.0 Bug using SBCL or CMUCL on i386 In-Reply-To: <404DA022.7000406@travelstoremaker.com> (Ivan Toshkov's message of "Tue, 09 Mar 2004 12:44:50 +0200") References: <404DA022.7000406@travelstoremaker.com> Message-ID: <87d67mnucb.fsf@sdr.ucs.co.za> I seem to remember having this problem before. If I remember correctly clearing out the browsers cookies stopped it from happening although what causes it is beyond me. Regards Sean. -- The pen is mightier than the sword. Only if the sword is very short and the pen is very sharp. Terry Pratchett. From mb at bese.it Tue Mar 9 11:29:13 2004 From: mb at bese.it (Marco Baringer) Date: Tue, 9 Mar 2004 12:29:13 +0100 Subject: [Bese-devel] UCW 0.2.0 Bug using SBCL or CMUCL on i386 In-Reply-To: <87d67mnucb.fsf@sdr.ucs.co.za> Message-ID: On Marted?, mar 9, 2004, at 12:16 Europe/Rome, Sean Ross wrote: > If I remember correctly clearing out the browsers > cookies stopped it from happening although > what causes it is beyond me. and in fact there was a silly typo in the parsing of multi-valued cookies. fix is in the works. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From ivan.toshkov at travelstoremaker.com Tue Mar 9 11:21:31 2004 From: ivan.toshkov at travelstoremaker.com (Ivan Toshkov) Date: Tue, 09 Mar 2004 13:21:31 +0200 Subject: [Bese-devel] UCW 0.2.0 Bug using SBCL or CMUCL on i386 In-Reply-To: References: Message-ID: <404DA8BB.6090803@travelstoremaker.com> Hi Marco, I'm using Aserve. Here is the backtrace: ------------------------------------------------------------- 0] backtrace 0: (VECTOR-PUSH-EXTEND 2 "" #\f "frob3-loooooooooooooong=val3-loooooooooooooong; frob2=val2; froba=vala")[:EXTERNAL] 1: ("DEFMETHOD COOKIE (REQUEST T)" # # # "ucw-session-id") 2: ("DEFMETHOD SERVICE (STANDARD-APPLICATION REQUEST-CONTEXT)" # # # #) 3: ("LAMBDA (PCL::EFFECTIVE-METHOD-GENSYM-0 PCL::EFFECTIVE-METHOD-GENSYM-1 PCL::EFFECTIVE-METHOD-GENSYM-2)" # # # #) 4: ("DEFMETHOD HANDLE-REQUEST (STANDARD-SERVER REQUEST RESPONSE)" # # # # ...) 5: ("DEFMETHOD PROCESS-ENTITY (HTTP-REQUEST COMPUTED-ENTITY)" # # # #) 6: ("DEFMETHOD HANDLE-REQUEST (HTTP-REQUEST)" # # #) 7: (NET.ASERVE::PROCESS-CONNECTION #) 8: (NET.ASERVE::HTTP-WORKER-THREAD) 9: (MULTIPROCESSING::APPLY-WITH-BINDINGS # NIL ((NET.ASERVE:*WSERVER* QUOTE #))) 10: ("DEFUN RESTART-PROCESS") 0] ------------------------------------------------------------- Marco Baringer wrote: > On Marted?, mar 9, 2004, at 11:44 Europe/Rome, Ivan Toshkov wrote: > >> Hi, >> >> I've tried to run the examples on i386 with CMUCL 18e and SBCL 0.8.8 >> and the following happens when I request a page from it: > > > This looks like an error in the backend, are you using mod_lisp or > portableaserve? can you send a backtrace? > > -- > Marco > Ring the bells that still can ring. > Forget the perfect offering. > There is a crack in everything. > That's how the light gets in. > -Leonard Cohen > > > -- *Ivan Toshkov* - Director of Software Development Technology Department *TravelStoreMaker.com Inc.* Phone: +359 2 983 4416 Fax: +359 2 983 6475 From mb at bese.it Tue Mar 9 11:44:54 2004 From: mb at bese.it (Marco Baringer) Date: Tue, 9 Mar 2004 12:44:54 +0100 Subject: [Bese-devel] UCW 0.2.0 Bug using SBCL or CMUCL on i386 In-Reply-To: Message-ID: <2ECF2FB9-71BF-11D8-B76F-000393599076@bese.it> On Marted?, mar 9, 2004, at 12:29 Europe/Rome, Marco Baringer wrote: > and in fact there was a silly typo in the parsing of multi-valued > cookies. fix is in the works. ucw--dev--0.2--patch-6 and ucw--dev--0.2--patch-7. However, if that was the real backtrace, how did stuff like froba and frob-looooooooooong get into the cookie headers? Ivan did you set those yourself or is ucw going nuts? -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From g.castaldi at quinary.com Wed Mar 10 08:32:02 2004 From: g.castaldi at quinary.com (Giannandrea Castaldi) Date: Wed, 10 Mar 2004 09:32:02 +0100 Subject: [Bese-devel] UCW: Problem with cmucl Message-ID: <404ED282.8090104@quinary.com> Hi, Given that I haven't found a solution for the problem with apache I've tried to use ucw with portable allegro serve but I've the same problem: when I try to go to the address http://127.0.0.1:3001/ucw/admin the browser remains waiting for a response and looking at the netstat report I've the same situation as apache: Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:33010 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:3001 0.0.0.0:* LISTEN tcp 494 0 127.0.0.1:3001 127.0.0.1:33069 ESTABLISHED tcp 0 0 127.0.0.1:33009 127.0.0.1:33008 ESTABLISHED tcp 0 0 127.0.0.1:33008 127.0.0.1:33009 ESTABLISHED tcp 0 0 127.0.0.1:33011 127.0.0.1:33010 ESTABLISHED tcp 0 0 127.0.0.1:33010 127.0.0.1:33011 ESTABLISHED tcp 1 0 127.0.0.1:3001 127.0.0.1:33015 CLOSE_WAIT There are that 494 bytes to be read by browser but it doesn't read them (it's right or is the server that doesn't read them? the man page isn't clear). Any suggestion? I've also tried portable allegro serve alone and it works than I think that the problem is in the use of ucw with cmucl (my vesion is 18e). I've seen that someone else have problems in using ucw+cmucl, Is there someone that use both wihout problems? Thanks for the help. Giannandrea From mb at bese.it Wed Mar 10 08:50:37 2004 From: mb at bese.it (Marco Baringer) Date: Wed, 10 Mar 2004 09:50:37 +0100 Subject: [Bese-devel] UCW: Problem with cmucl In-Reply-To: <404ED282.8090104@quinary.com> Message-ID: <0018028E-7270-11D8-B3F3-000393599076@bese.it> On Mercoled?, mar 10, 2004, at 09:32 Europe/Rome, Giannandrea Castaldi wrote: > Hi, > Given that I haven't found a solution for the problem with apache I've > tried to use ucw with portable allegro serve but I've the same > problem: when I try to go to the address > http://127.0.0.1:3001/ucw/admin the browser remains waiting for a > response and looking at the netstat report I've the same situation as > apache: what about the url http://127.0.0.1:3001/ucw/admin/ (notice the trailing slash)? > I've seen that someone else have problems in using ucw+cmucl, Is there > someone that use both wihout problems? there was a bug in how UCW parsed cookies, it shouldn't be related to your problems with getting the server running. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From g.castaldi at quinary.com Wed Mar 10 11:01:00 2004 From: g.castaldi at quinary.com (Giannandrea Castaldi) Date: Wed, 10 Mar 2004 12:01:00 +0100 Subject: [Bese-devel] UCW: Problem with cmucl In-Reply-To: <0018028E-7270-11D8-B3F3-000393599076@bese.it> References: <0018028E-7270-11D8-B3F3-000393599076@bese.it> Message-ID: <404EF56C.1010501@quinary.com> Hi, Marco Baringer wrote: > what about the url http://127.0.0.1:3001/ucw/admin/ (notice the > trailing slash)? > The behavior doesn't change (sorry, you already told me of the trailing slash). Giannandrea From mb at bese.it Wed Mar 10 11:15:23 2004 From: mb at bese.it (Marco Baringer) Date: Wed, 10 Mar 2004 12:15:23 +0100 Subject: [Bese-devel] UCW: Problem with cmucl In-Reply-To: <404EF56C.1010501@quinary.com> Message-ID: <39B4B344-7284-11D8-B3F3-000393599076@bese.it> On Mercoled?, mar 10, 2004, at 12:01 Europe/Rome, Giannandrea Castaldi wrote: > The behavior doesn't change (sorry, you already told me of the > trailing slash). sorry, but i had to ask that first. Can you send whatever output ucw is giving on the terminal? It should be logging access and errors on the terminal, if it isn't then something very very funny is going on. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From g.castaldi at quinary.com Wed Mar 10 11:36:40 2004 From: g.castaldi at quinary.com (Giannandrea Castaldi) Date: Wed, 10 Mar 2004 12:36:40 +0100 Subject: [Bese-devel] UCW: Problem with cmucl In-Reply-To: <39B4B344-7284-11D8-B3F3-000393599076@bese.it> References: <39B4B344-7284-11D8-B3F3-000393599076@bese.it> Message-ID: <404EFDC8.8070206@quinary.com> Hi, Marco Baringer wrote: > On Mercoled?, mar 10, 2004, at 12:01 Europe/Rome, Giannandrea Castaldi > wrote: > >> The behavior doesn't change (sorry, you already told me of the >> trailing slash). > > > sorry, but i had to ask that first. > > Can you send whatever output ucw is giving on the terminal? It should > be logging access and errors on the terminal, if it isn't then > something very very funny is going on. Here is all the output, there isn't any message about my access: ; SLIME 2004-03-09 CL-USER> (load ".asdf-install-dir/site/ucw_0.2.0/examples/run-examples-aserve.lisp") ; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/examples/run-examples-aserve.lisp". ; loading system definition from /home/gcast/.asdf-install-dir/systems/ucw.asd ; into # ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/ucw.asd". ; registering # as UCW ; registering # as UCW.ASERVE ; registering # as UCW.MOD-LISP ; registering # as UCW.ADMIN ; registering # as UCW.CL-ICU ; registering # as UCW.EXAMPLES ; registering # as UCW.EXAMPLES.I18N ; loading system definition from ; /home/gcast/.asdf-install-dir/systems/swank.asd into ; # ;; Loading #p"/home/gcast/.asdf-install-dir/site/slime/swank.asd". ; registering # as SWANK ; loading system definition from ; /home/gcast/.asdf-install-dir/site/ucw_0.2.0/systems/yaclml.asd into ; # ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/yaclml/yaclml.asd". ; registering # as YACLML ; registering # as YACLML.TEST ; loading system definition from ; /home/gcast/.asdf-install-dir/systems/arnesi.asd into ; # ;; Loading #p"/home/gcast/.asdf-install-dir/site/arnesi_1.1.2/arnesi.asd". ; registering # as ARNESI ; registering # as ARNESI.TEST ;; Loading #p"/home/gcast/.asdf-install-dir/site/arnesi_1.1.2/src/packages.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/arnesi_1.1.2/src/one-liners.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/arnesi_1.1.2/src/accumulation.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/arnesi_1.1.2/src/asdf.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/arnesi_1.1.2/src/list.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/arnesi_1.1.2/src/string.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/arnesi_1.1.2/src/csv.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/arnesi_1.1.2/src/flow-control.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/arnesi_1.1.2/src/cps.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/arnesi_1.1.2/src/debug.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/arnesi_1.1.2/src/hash.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/arnesi_1.1.2/src/vector.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/arnesi_1.1.2/src/http.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/arnesi_1.1.2/src/io.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/arnesi_1.1.2/src/lambda.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/arnesi_1.1.2/src/numbers.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/arnesi_1.1.2/src/log.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/arnesi_1.1.2/src/matcher.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/arnesi_1.1.2/src/mop.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/arnesi_1.1.2/src/sequence.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/arnesi_1.1.2/src/specials.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/yaclml/src/packages.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/yaclml/src/attribute-bind.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/yaclml/src/yaclml.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/yaclml/src/tags/html4.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/yaclml/src/tags/standard-yaclml.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/yaclml/src/tags/html+.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/yaclml/src/bracket-reader.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/yaclml/src/tal/xmls.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/yaclml/src/tal/compile.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/yaclml/src/tal/generator.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/yaclml/src/tal/handlers.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/slime/swank-loader.x86f". ;;; Loading #p"/home/gcast/.asdf-install-dir/site/slime/fasl/cmu/swank-backend.x86f". Warning: SWANK-BACKEND also exports the following symbols: (SWANK-BACKEND:LISP-IMPLEMENTATION-TYPE-NAME SWANK-BACKEND:CURRENT-THREAD SWANK-BACKEND:PROFILE SWANK-BACKEND:INSPECTED-PARTS SWANK-BACKEND:REMOVE-FD-HANDLERS SWANK-BACKEND:COMPUTE-BACKTRACE SWANK-BACKEND:WHO-CALLS SWANK-BACKEND:CALL-WITH-LOCK-HELD SWANK-BACKEND:UNPROFILE-ALL SWANK-BACKEND:PROFILE-RESET SWANK-BACKEND:THREAD-STATUS SWANK-BACKEND:ALL-THREADS SWANK-BACKEND:DESCRIBE-DEFINITION SWANK-BACKEND:PROFILED-FUNCTIONS SWANK-BACKEND:REMOVE-SIGIO-HANDLERS SWANK-BACKEND:CREATE-SOCKET SWANK-BACKEND:STARTUP-MULTIPROCESSING SWANK-BACKEND:MAKE-FN-STREAMS SWANK-BACKEND:PRINT-FRAME SWANK-BACKEND:WHO-SPECIALIZES SWANK-BACKEND:FRAME-CATCH-TAGS SWANK-BACKEND:INTERRUPT-THREAD SWANK-BACKEND:UNPROFILE SWANK-BACKEND:EVAL-IN-FRAME SWANK-BACKEND:WHO-MACROEXPANDS SWANK-BACKEND:RETURN-FROM-FRAME SWANK-BACKEND:MAKE-LOCK SWANK-BACKEND:RECEIVE SWANK-BACKEND:CALL-WITHOUT-INTERRUPTS SWANK-BACKEND:KILL-THREAD SWANK-BACKEND:SPAWN SWANK-BACKEND:SWANK-COMPILE-STRING SWANK-BACKEND:ADD-SIGIO-HANDLER SWANK-BACKEND:RESTART-FRAME SWANK-BACKEND:SEND SWANK-BACKEND:SWANK-COMPILE-SYSTEM SWANK-BACKEND:ARGLIST SWANK-BACKEND:DESCRIBE-SYMBOL-FOR-EMACS SWANK-BACKEND:MACROEXPAND-ALL SWANK-BACKEND:WHO-BINDS SWANK-BACKEND:ACCEPT-CONNECTION SWANK-BACKEND:EMACS-CONNECTED SWANK-BACKEND:WHO-REFERENCES SWANK-BACKEND:THREAD-ALIVE-P SWANK-BACKEND:FRAME-LOCALS SWANK-BACKEND:THREAD-NAME SWANK-BACKEND:PROFILE-PACKAGE SWANK-BACKEND:GETPID SWANK-BACKEND:FIND-DEFINITIONS SWANK-BACKEND:CLOSE-SOCKET SWANK-BACKEND:DESCRIBE-PRIMITIVE-TYPE SWANK-BACKEND:LIST-CALLEES SWANK-BACKEND:PREFERRED-COMMUNICATION-STYLE SWANK-BACKEND:ADD-FD-HANDLER SWANK-BACKEND:SWANK-COMPILE-FILE SWANK-BACKEND:LOCAL-PORT SWANK-BACKEND:PROFILE-REPORT SWANK-BACKEND:CALL-WITH-COMPILATION-HOOKS SWANK-BACKEND:WHO-SETS SWANK-BACKEND:FRAME-SOURCE-LOCATION-FOR-EMACS SWANK-BACKEND:LIST-CALLERS SWANK-BACKEND:CALL-WITH-DEBUGGING-ENVIRONMENT) ;;; Loading #p"/home/gcast/.asdf-install-dir/site/slime/fasl/cmu/swank-source-path-parser.x86f". ;;; Loading #p"/home/gcast/.asdf-install-dir/site/slime/fasl/cmu/swank-cmucl.x86f". ;;; Loading #p"/home/gcast/.asdf-install-dir/site/slime/fasl/cmu/swank.x86f". Warning: SWANK also exports the following symbols: (SWANK:COMPILER-NOTES-FOR-EMACS SWANK:TOGGLE-TRACE-FDEFINITION SWANK:INSPECT-NTH-PART SWANK:COMPLETIONS SWANK:INSPECT-IN-FRAME SWANK:SWANK-MACROEXPAND-ALL SWANK:PPRINT-EVAL SWANK:UNTRACE-ALL SWANK:SWANK-MACROEXPAND SWANK:QUIT-THREAD-BROWSER SWANK:SWANK-MACROEXPAND-1 SWANK:FRAME-LOCALS-FOR-EMACS SWANK:ARGLIST-STRING SWANK:EVAL-STRING SWANK:INTERACTIVE-EVAL-REGION SWANK:TOGGLE-PROFILE-FDEFINITION SWANK:LIST-THREADS SWANK:RE-EVALUATE-DEFVAR SWANK:DEBUGGER-INFO-FOR-EMACS SWANK:SET-PACKAGE SWANK:CONNECTION-INFO SWANK:FIND-FUNCTION-LOCATIONS SWANK:THROW-TO-TOPLEVEL SWANK:LIST-ALL-PACKAGE-NAMES SWANK:BACKTRACE SWANK:DESCRIBE-FUNCTION SWANK:XREF SWANK:INTERACTIVE-EVAL SWANK:INVOKE-NTH-RESTART-FOR-EMACS SWANK:COMPILE-STRING-FOR-EMACS SWANK:ONEWAY-EVAL-STRING SWANK:DESCRIBE-DEFINITION-FOR-EMACS SWANK:LISTENER-EVAL SWANK:FRAME-CATCH-TAGS-FOR-EMACS SWANK:DOCUMENTATION-SYMBOL SWANK:DESCRIBE-INSPECTEE SWANK:LOAD-FILE SWANK:APROPOS-LIST-FOR-EMACS SWANK:COMPILE-FILE-FOR-EMACS SWANK:TAKE-INPUT SWANK:PPRINT-EVAL-STRING-IN-FRAME SWANK:SIMPLE-COMPLETIONS SWANK:INIT-INSPECTOR SWANK:UNDEFINE-FUNCTION SWANK:QUIT-INSPECTOR SWANK:DISASSEMBLE-SYMBOL SWANK:INVOKE-NTH-RESTART SWANK:INSPECTOR-NEXT SWANK:SWANK-LOAD-SYSTEM SWANK:SET-DEFAULT-DIRECTORY SWANK:INSPECTOR-POP SWANK:EVAL-STRING-IN-FRAME SWANK:DESCRIBE-SYMBOL SWANK:SLDB-ABORT SWANK:STATE-STACK SWANK:SLDB-CONTINUE) Warning: These Swank interfaces are unimplemented: (RESTART-FRAME RETURN-FROM-FRAME WHO-MACROEXPANDS WHO-SPECIALIZES) ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/packages.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/config.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/helpers.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/loggers.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/backend/accept.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/backend/protocol.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/backend/cookie.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/rerl/protocol.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/rerl/conditions.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/rerl/request-loop-error.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/rerl/standard-action.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/rerl/standard-application.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/rerl/standard-request-context.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/rerl/standard-server.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/rerl/standard-session-frame.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/rerl/standard-session.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/yaclml/yaclml.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/yaclml/tal.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/components/standard-component.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/components/error.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/components/login.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/components/message.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/components/option-dialog.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/components/range-view.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/components/tabbed-pane.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/components/ucw-inspector.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/i18n/i18n.x86f". ; loading system definition from ; /home/gcast/.asdf-install-dir/site/ucw_0.2.0/systems/aserve.asd into ; # ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/aserve/aserve.asd". ; registering # as ASERVE ; loading system definition from ; /home/gcast/.asdf-install-dir/site/ucw_0.2.0/systems/acl-compat.asd into ; # ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/acl-compat/acl-compat.asd". ; registering # as CMUCL-GRAYSTREAM ; registering # as ACL-COMPAT ; loading system definition from ; /home/gcast/.asdf-install-dir/systems/cl-ppcre.asd into ; # ;; Loading #p"/home/gcast/.asdf-install-dir/site/cl-ppcre-0.7.4/cl-ppcre.asd". ; registering # as CL-PPCRE ; loading system definition from ; /home/gcast/.asdf-install-dir/site/ucw_0.2.0/systems/puri.asd into ; # ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/libs/puri-1.3.1/puri.asd". ; registering # as PURI ; registering # as PURI-TESTS ; loading system definition from ; /home/gcast/.asdf-install-dir/site/ucw_0.2.0/systems/htmlgen.asd into ; # ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/aserve/htmlgen/htmlgen.asd". ; registering # as HTMLGEN ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/libs/puri-1.3.1/src.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/cl-ppcre-0.7.4/packages.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/cl-ppcre-0.7.4/specials.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/cl-ppcre-0.7.4/util.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/cl-ppcre-0.7.4/errors.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/cl-ppcre-0.7.4/lexer.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/cl-ppcre-0.7.4/parser.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/cl-ppcre-0.7.4/regex-class.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/cl-ppcre-0.7.4/convert.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/cl-ppcre-0.7.4/optimize.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/cl-ppcre-0.7.4/closures.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/cl-ppcre-0.7.4/repetition-closures.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/cl-ppcre-0.7.4/scanner.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/cl-ppcre-0.7.4/api.x86f". ;; Loading #p"/usr/local/lib/cmucl/lib/subsystems/gray-streams-library.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/acl-compat/packages.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/acl-compat/lw-buffering.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/acl-compat/acl-excl-common.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/acl-compat/cmucl/acl-excl.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/acl-compat/chunked-stream-mixin.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/acl-compat/cmucl/acl-mp.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/acl-compat/cmucl/acl-socket.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/acl-compat/cmucl/acl-sys.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/aserve/htmlgen/htmlgen.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/aserve/packages.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/aserve/macs.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/aserve/main.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/aserve/headers.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/aserve/parse.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/aserve/decode.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/aserve/publish.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/aserve/authorize.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/aserve/log.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/aserve/client.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/libs/portableaserve/aserve/proxy.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/backend/aserve.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/admin/admin.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/src/admin/admin-inspector.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/examples/examples.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/examples/counter.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/examples/hello-world.x86f". ;; Loading #p"/home/gcast/.asdf-install-dir/site/ucw_0.2.0/examples/transaction.x86f". Example Server Running. T CL-USER> Thanks. Giannandrea From g.castaldi at quinary.com Wed Mar 10 13:00:36 2004 From: g.castaldi at quinary.com (Giannandrea Castaldi) Date: Wed, 10 Mar 2004 14:00:36 +0100 Subject: [Bese-devel] UCW: Problem with cmucl In-Reply-To: <404ED282.8090104@quinary.com> References: <404ED282.8090104@quinary.com> Message-ID: <404F1174.7030101@quinary.com> Hi, Giannandrea Castaldi wrote: > Hi, > Given that I haven't found a solution for the problem with apache I've > tried to use ucw with portable allegro serve but I've the same > problem: when I try to go to the address > http://127.0.0.1:3001/ucw/admin the browser remains waiting for a > response and looking at the netstat report I've the same situation as > apache: > > Active Internet connections (servers and established) > Proto Recv-Q Send-Q Local Address Foreign Address State > tcp 0 0 0.0.0.0:111 0.0.0.0:* > LISTEN > tcp 0 0 127.0.0.1:33010 0.0.0.0:* > LISTEN > tcp 0 0 0.0.0.0:23 0.0.0.0:* > LISTEN > tcp 0 0 0.0.0.0:3001 0.0.0.0:* > LISTEN > tcp 494 0 127.0.0.1:3001 127.0.0.1:33069 > ESTABLISHED > tcp 0 0 127.0.0.1:33009 127.0.0.1:33008 > ESTABLISHED > tcp 0 0 127.0.0.1:33008 127.0.0.1:33009 > ESTABLISHED > tcp 0 0 127.0.0.1:33011 127.0.0.1:33010 > ESTABLISHED > tcp 0 0 127.0.0.1:33010 127.0.0.1:33011 > ESTABLISHED > tcp 1 0 127.0.0.1:3001 127.0.0.1:33015 > CLOSE_WAIT > > There are that 494 bytes to be read by browser but it doesn't read > them (it's right or is the server that doesn't read them? the man page > isn't clear). That I wrote is wrong. The 494 bytes on the recv-q column must be read by the ucw server but it doesn't read them. Indeed on the ucw output there isn't any message about the reception of the request. Thanks for the help. Giannandrea From lam at tuxfamily.org Wed Mar 10 17:58:08 2004 From: lam at tuxfamily.org (Lam) Date: Wed, 10 Mar 2004 18:58:08 +0100 Subject: [Bese-devel] problem to try UCW Message-ID: hello i would like to try ucw, i get 0.2 tar.gz this is what i do : * (push "/home/nlamirault/src/ucw_0.2.0/systems/" asdf:*central-registry*) ("/home/nlamirault/src/ucw_0.2.0/systems/" #p"/usr/share/common-lisp/systems/" *DEFAULT-PATHNAME-DEFAULTS*) * (load "examples/run-examples-mod-lisp.lisp") .... [ some messages ] Example Server Running. T * after i try this URL : $> w3m http://localhost:8080/ucw/examples/hello-world.ucw w3m: Can't load http://localhost:8080/ucw/examples/hello-world.ucw. do u know where i make a mistake ? thanks for any help -- Nicolas Lamirault From mb at bese.it Wed Mar 10 20:10:03 2004 From: mb at bese.it (Marco Baringer) Date: Wed, 10 Mar 2004 21:10:03 +0100 Subject: [Bese-devel] problem to try UCW In-Reply-To: Message-ID: On Mercoled?, mar 10, 2004, at 18:58 Europe/Rome, Lam wrote: > Example Server Running. > T > * > > after i try this URL : > > $> w3m http://localhost:8080/ucw/examples/hello-world.ucw > w3m: Can't load http://localhost:8080/ucw/examples/hello-world.ucw. is this cmucl? if not, does the aserve backend work for you? -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From lam at tuxfamily.org Thu Mar 11 08:40:48 2004 From: lam at tuxfamily.org (Lam) Date: Thu, 11 Mar 2004 09:40:48 +0100 Subject: [Bese-devel] problem to try UCW In-Reply-To: (Marco Baringer's message of "Wed, 10 Mar 2004 21:10:03 +0100") References: Message-ID: Marco Baringer writes: > On Mercoled?, mar 10, 2004, at 18:58 Europe/Rome, Lam wrote: > >> Example Server Running. >> T >> * >> >> after i try this URL : >> >> $> w3m http://localhost:8080/ucw/examples/hello-world.ucw >> w3m: Can't load http://localhost:8080/ucw/examples/hello-world.ucw. > > is this cmucl? if not, does the aserve backend work for you? yes is Cmucl $> dpkg -l | grep cmucl ii cmucl 18e-7 ii cmucl-docs 18e-7 ii cmucl-source 18e-7 ii encycmuclopedia 20010617-1 -- Nicolas Lamirault From mb at bese.it Thu Mar 11 11:50:07 2004 From: mb at bese.it (Marco Baringer) Date: Thu, 11 Mar 2004 12:50:07 +0100 Subject: [Bese-devel] UCW: Problem with cmucl In-Reply-To: <404ED282.8090104@quinary.com> Message-ID: <3E35D18E-7352-11D8-8495-000393599076@bese.it> i admit to being very confused. The complete lack of output seems very strange, not even an error message. On Mercoled?, mar 10, 2004, at 09:32 Europe/Rome, Giannandrea Castaldi wrote: > Active Internet connections (servers and established) > Proto Recv-Q Send-Q Local Address Foreign Address > State > tcp 0 0 0.0.0.0:111 0.0.0.0:* > LISTEN > tcp 0 0 127.0.0.1:33010 0.0.0.0:* > LISTEN > tcp 0 0 0.0.0.0:23 0.0.0.0:* > LISTEN > tcp 0 0 0.0.0.0:3001 0.0.0.0:* > LISTEN > tcp 494 0 127.0.0.1:3001 127.0.0.1:33069 > ESTABLISHED > tcp 0 0 127.0.0.1:33009 127.0.0.1:33008 > ESTABLISHED > tcp 0 0 127.0.0.1:33008 127.0.0.1:33009 > ESTABLISHED > tcp 0 0 127.0.0.1:33011 127.0.0.1:33010 > ESTABLISHED > tcp 0 0 127.0.0.1:33010 127.0.0.1:33011 > ESTABLISHED > tcp 1 0 127.0.0.1:3001 127.0.0.1:33015 > CLOSE_WAIT why is 127.0.0.1:3001 both ESTABLISHED and CLOSED_WAIT? > I've seen that someone else have problems in using ucw+cmucl, Is there > someone that use both wihout problems? it doesn't seem so. ok, could you do me a favor: could you load the examples and then, before making a request from the browser, inspect the *default-server* object's backend slot? how many active processes are there and what state are they in? If you try some of the other examples (try /ucw/examples/hello-world.ucw), what happens? thanks, -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From rm at fabula.de Thu Mar 11 11:49:28 2004 From: rm at fabula.de (rm at fabula.de) Date: Thu, 11 Mar 2004 12:49:28 +0100 Subject: [Bese-devel] UCW: Problem with cmucl In-Reply-To: <3E35D18E-7352-11D8-8495-000393599076@bese.it> References: <404ED282.8090104@quinary.com> <3E35D18E-7352-11D8-8495-000393599076@bese.it> Message-ID: <20040311114928.GA20220@www> On Thu, Mar 11, 2004 at 12:50:07PM +0100, Marco Baringer wrote: > i admit to being very confused. The complete lack of output seems very > strange, not even an error message. Weeell, that's how ucw looked and acted on my box for quite a while. Only recent versions seem to work (btw, i only really tested it with recent SBCLs). Unfortunately i'm way too busy to dive into debugging ... Ralf MAttes > On Mercoled?, mar 10, 2004, at 09:32 Europe/Rome, Giannandrea Castaldi > wrote: > > >Active Internet connections (servers and established) > >Proto Recv-Q Send-Q Local Address Foreign Address > >State > >tcp 0 0 0.0.0.0:111 0.0.0.0:* > >LISTEN > >tcp 0 0 127.0.0.1:33010 0.0.0.0:* > >LISTEN > >tcp 0 0 0.0.0.0:23 0.0.0.0:* > >LISTEN > >tcp 0 0 0.0.0.0:3001 0.0.0.0:* > >LISTEN > >tcp 494 0 127.0.0.1:3001 127.0.0.1:33069 > >ESTABLISHED > >tcp 0 0 127.0.0.1:33009 127.0.0.1:33008 > >ESTABLISHED > >tcp 0 0 127.0.0.1:33008 127.0.0.1:33009 > >ESTABLISHED > >tcp 0 0 127.0.0.1:33011 127.0.0.1:33010 > >ESTABLISHED > >tcp 0 0 127.0.0.1:33010 127.0.0.1:33011 > >ESTABLISHED > >tcp 1 0 127.0.0.1:3001 127.0.0.1:33015 > >CLOSE_WAIT > > why is 127.0.0.1:3001 both ESTABLISHED and CLOSED_WAIT? > > >I've seen that someone else have problems in using ucw+cmucl, Is there > >someone that use both wihout problems? > > it doesn't seem so. > > ok, could you do me a favor: could you load the examples and then, > before making a request from the browser, inspect the *default-server* > object's backend slot? how many active processes are there and what > state are they in? If you try some of the other examples (try > /ucw/examples/hello-world.ucw), what happens? > > thanks, > -- > Marco > Ring the bells that still can ring. > Forget the perfect offering. > There is a crack in everything. > That's how the light gets in. > -Leonard Cohen > > > _______________________________________________ > bese-devel mailing list > bese-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/bese-devel From g.castaldi at quinary.com Thu Mar 11 13:01:03 2004 From: g.castaldi at quinary.com (Giannandrea Castaldi) Date: Thu, 11 Mar 2004 14:01:03 +0100 Subject: [Bese-devel] UCW: Problem with cmucl In-Reply-To: <3E35D18E-7352-11D8-8495-000393599076@bese.it> References: <3E35D18E-7352-11D8-8495-000393599076@bese.it> Message-ID: <4050630F.3000809@quinary.com> Marco Baringer wrote: > i admit to being very confused. The complete lack of output seems very > strange, not even an error message. > > On Mercoled?, mar 10, 2004, at 09:32 Europe/Rome, Giannandrea Castaldi > wrote: > >> Active Internet connections (servers and established) >> Proto Recv-Q Send-Q Local Address Foreign Address >> State >> tcp 0 0 0.0.0.0:111 0.0.0.0:* >> LISTEN >> tcp 0 0 127.0.0.1:33010 0.0.0.0:* >> LISTEN >> tcp 0 0 0.0.0.0:23 0.0.0.0:* >> LISTEN >> tcp 0 0 0.0.0.0:3001 0.0.0.0:* >> LISTEN >> tcp 494 0 127.0.0.1:3001 127.0.0.1:33069 >> ESTABLISHED >> tcp 0 0 127.0.0.1:33009 127.0.0.1:33008 >> ESTABLISHED >> tcp 0 0 127.0.0.1:33008 127.0.0.1:33009 >> ESTABLISHED >> tcp 0 0 127.0.0.1:33011 127.0.0.1:33010 >> ESTABLISHED >> tcp 0 0 127.0.0.1:33010 127.0.0.1:33011 >> ESTABLISHED >> tcp 1 0 127.0.0.1:3001 127.0.0.1:33015 >> CLOSE_WAIT > > > why is 127.0.0.1:3001 both ESTABLISHED and CLOSED_WAIT? Because I tried twice to go to the html page and one connection expired for timeout and the other is waiting for a response. > >> I've seen that someone else have problems in using ucw+cmucl, Is >> there someone that use both wihout problems? > > > it doesn't seem so. > > ok, could you do me a favor: could you load the examples and then, > before making a request from the browser, inspect the *default-server* > object's backend slot? how many active processes are there and what > state are they in? If you try some of the other examples (try > /ucw/examples/hello-world.ucw), what happens? Sorry, but I've just discovered that the inspect doesn't work in cmucl 18e (isn't possible look at the object slots). I've just tried to compile a src version of cmucl but it isn't simple. As soon as possible I'll send you the inspect results. Thanks. Giannandrea From g.castaldi at quinary.com Fri Mar 12 09:40:06 2004 From: g.castaldi at quinary.com (Giannandrea Castaldi) Date: Fri, 12 Mar 2004 10:40:06 +0100 Subject: [Bese-devel] Problem with fiveAM Message-ID: <40518576.9000104@quinary.com> Hi, I've discovered that if I write a test as the following: (test simple-test (is (= 4 5))) I've the following error: Type-error in KERNEL::OBJECT-NOT-LIST-ERROR-HANDLER: 25029047 is not of type LIST [Condition of type TYPE-ERROR] Restarts: 0: [ABORT] Return to SLIME toplevel. 1: [ABORT] Return to Top-Level. Backtrace: 0: (CONDITIONS::CONDITION-READER-FUNCTION # IT.BESE.FIVEAM::TEST-CASE) 1: ("DEFMETHOD EXPLAIN (DETAILED-TEXT-EXPLAINER T T)" #<#1=unused-arg> #<#1#> #<#1#> (# #) ...) Giannandrea From mb at bese.it Mon Mar 22 19:50:38 2004 From: mb at bese.it (Marco Baringer) Date: Mon, 22 Mar 2004 20:50:38 +0100 Subject: [Bese-devel] ucw and cmucl problems Message-ID: <317CF5B2-7C3A-11D8-AFFA-000393599076@bese.it> i had a very strange experince with cmucl today: the run-examples-aserve.lisp file compilied and loaded fine, however all requests to http://localhost:3001/ucw/admin/ errored (host did not respond). however, http://127.0.0.1:3001/ucw/admin/ worked perfectly. does anybody know why this would be? i tried creating the aserve server with different parameters and there was no noticable change. apparently i have run into a wall in my linux, or aserve or networking knowledge. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From jan at rychter.com Thu Mar 25 21:32:32 2004 From: jan at rychter.com (Jan Rychter) Date: Thu, 25 Mar 2004 13:32:32 -0800 Subject: [Bese-devel] Problems compiling 0.2.0 with CMUCL References: Message-ID: Ok, the continuing saga of problems. I've gotten past the problems with acl-compat on CMUCL (notably it having a strange way of loading gray-streams which fails and it redefining without-package-locks). I am now at a stage when yaclml and ucw compile and load fine. ucw.mod-lisp also compiles fine, but when I try to load it, I get: Attempt to modify the locked package COMMON-LISP, by redefining function STREAM [Condition of type LISP::PACKAGE-LOCKED-ERROR] Restarts: 0: [CONTINUE] Ignore the lock and continue 1: [UNLOCK-PACKAGE] Disable package's definition-lock, then continue 2: [UNLOCK-ALL] Disable all package locks, then continue 3: [CONTINUE] Return NIL from load of #p"/home/jwr/lisp/ucw-arch/ucw/src/backend/mod-lisp.x86f". 4: [RETRY] Retry performing # on #. 5: [ACCEPT] Continue, treating # on # as having been successful. 6: [ABORT] Return to SLIME toplevel. 7: [ABORT] Return to Top-Level. Backtrace: 0: (LISP::REDEFINING-FUNCTION STREAM #) 1: (LISP::%SET-FDEFINITION STREAM #) 2: (C::%%DEFUN STREAM # NIL NIL) 3: (C::%%DEFUN 3 STREAM # NIL ...)[:EXTERNAL] 4: ((SETF PCL::GDEFINITION) # STREAM) 5: (PCL::REAL-ENSURE-GF-USING-CLASS--NULL # STREAM) 6: ((FLET PCL::FIX PCL::FIX-SLOT-ACCESSORS) STREAM STREAM PCL::R) 7: (PCL::FIX-SLOT-ACCESSORS # (# #) PCL::ADD) 8: ("DEFMETHOD SHARED-INITIALIZE :AFTER (STD-CLASS T)" (#(15 5 8) . #()) #<#1=unused-arg> # #<#1#> ...) 9: ("PRECOMPILE-RANDOM-CODE-SEGMENTS PCL" #<#1=unused-arg> #<#1#> # T ...) 10: ("DEFMETHOD MAKE-INSTANCE (CLASS)" #<#1=unused-arg> #<#1#> # (:NAME IT.BESE.UCW::MOD-LISP-MESSAGE :DIRECT-SUPERCLASSES NIL :DIRECT-SLOTS ...)) 11: ("DEFMETHOD ENSURE-CLASS-USING-CLASS (NULL T)" #<#1=unused-arg> #<#1#> NIL IT.BESE.UCW::MOD-LISP-MESSAGE ...) 12: (C::DO-CALL # 66 67 4 ...) 13: (LISP::FOP-FUNCALL-FOR-EFFECT) 14: (LISP::LOAD-GROUP #) 15: (LISP::FASLOAD #) [...] Attempting to continue unlocking the package (option [1]) results in: Execution of a form compiled with errors: (DEFMETHOD PRINT-OBJECT ((IT.BESE.UCW::REQUEST IT.BESE.UCW::MOD-LISP-MESSAGE) STREAM) (PRINT-UNREADABLE-OBJECT (IT.BESE.UCW::REQUEST STREAM :TYPE T) (FORMAT STREAM ":RAW-URL ~S" (IT.BESE.UCW::RAW-URL IT.BESE.UCW::REQUEST)))) [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR] Restarts: 0: [CONTINUE] Return NIL from load of #p"/home/jwr/lisp/ucw-arch/ucw/src/backend/mod-lisp.x86f". 1: [RETRY] Retry performing # on #. 2: [ACCEPT] Continue, treating # on # as having been successful. 3: [ABORT] Return to SLIME toplevel. 4: [ABORT] Return to Top-Level. Backtrace: 0: (C::DO-CALL # 10 11 4 ...) 1: (LISP::FOP-FUNCALL-FOR-EFFECT) 2: (LISP::LOAD-GROUP #) [...] Any hints? --J. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: From mb at bese.it Thu Mar 25 23:43:11 2004 From: mb at bese.it (Marco Baringer) Date: Fri, 26 Mar 2004 00:43:11 +0100 Subject: [Bese-devel] Problems compiling 0.2.0 with CMUCL In-Reply-To: Message-ID: <2D69018C-7EB6-11D8-99DB-000393599076@bese.it> On Gioved?, mar 25, 2004, at 22:32 Europe/Rome, Jan Rychter wrote: > Ok, the continuing saga of problems. we need a name for this soap opera. > I've gotten past the problems with acl-compat on CMUCL (notably it > having a strange way of loading gray-streams which fails and it > redefining without-package-locks). i think rudi fixed that in a recent enough acl-compat, i seem to recall talking to him about that exact issue. > I am now at a stage when yaclml and ucw compile and load > fine. yippy! were there any specific changes you needed to make to yoclml or ucw? are there some hints i should put into the docs? > ucw.mod-lisp also compiles fine, but when I try to load it, I get: > > Attempt to modify the locked package COMMON-LISP, by redefining > function > STREAM > [Condition of type LISP::PACKAGE-LOCKED-ERROR] ok, this is a mistake. the class mod-lisp-message has a slot named stream (the stream connected to apache) with an accessor named stream. we don't use that accessor, so it could just as well be removed. > Attempting to continue unlocking the package (option [1]) results in: > > > Execution of a form compiled with errors: this is, afaict, a cmucl odity. basically this is the same problem we had with the standard-whatever classes. the other thing to note is that when you get an "Execution of a form compiled with errors" it's the compiliation pass which has failed, you need to retry compiling that file to see what the real error is. Anyway, sometimes (i can't seem to understand when) CMUCL wants class definitions to be loaded before it can compile code which uses the accessor defined in the defclass form. In this particular case we have the method print-object which uses the raw-url accessor defined in a defclass in that same file. attempting to compile the file without loading it first gives this error. you have two (or three) options: 1) move the defclass form into an eval-when or another file, 2) use (slot-value object 'raw-url) as opposed to (raw-url object) and 3) talk to some people who know cmucl better than I and see whats really going on. hope this helps. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From jan at rychter.com Fri Mar 26 01:12:43 2004 From: jan at rychter.com (Jan Rychter) Date: Thu, 25 Mar 2004 17:12:43 -0800 Subject: [Bese-devel] Problems compiling 0.2.0 with CMUCL In-Reply-To: <2D69018C-7EB6-11D8-99DB-000393599076@bese.it> (Marco Baringer's message of "Fri, 26 Mar 2004 00:43:11 +0100") References: <2D69018C-7EB6-11D8-99DB-000393599076@bese.it> Message-ID: [...] >> I've gotten past the problems with acl-compat on CMUCL (notably it >> having a strange way of loading gray-streams which fails and it >> redefining without-package-locks). Marco> i think rudi fixed that in a recent enough acl-compat, i seem to Marco> recall talking to him about that exact issue. Seems it isn't fixed in the asdf-installable acl-compat that I use. >> I am now at a stage when yaclml and ucw compile and load fine. Marco> yippy! were there any specific changes you needed to make to Marco> yoclml or ucw? are there some hints i should put into the docs? Well, I still get this: SWANK-BACKEND:SET-DEFAULT-DIRECTORY already names an ordinary function or a macro. If you want to replace it with a generic function, you should remove the existing definition beforehand. Otherwise, things look fine. >> ucw.mod-lisp also compiles fine, but when I try to load it, I get: >> >> Attempt to modify the locked package COMMON-LISP, by redefining >> function STREAM [Condition of type LISP::PACKAGE-LOCKED-ERROR] Marco> ok, this is a mistake. the class mod-lisp-message has a slot Marco> named stream (the stream connected to apache) with an accessor Marco> named stream. we don't use that accessor, so it could just as Marco> well be removed. Ahem, actually, we do -- in make-mod-lisp-response. I've removed the accessor and replaced this access with (slot-value). >> Attempting to continue unlocking the package (option [1]) results >> in: >> >> >> Execution of a form compiled with errors: Marco> this is, afaict, a cmucl odity. basically this is the same Marco> problem we had with the standard-whatever classes. the other Marco> thing to note is that when you get an "Execution of a form Marco> compiled with errors" it's the compiliation pass which has Marco> failed, you need to retry compiling that file to see what the Marco> real error is. Marco> Anyway, sometimes (i can't seem to understand when) CMUCL wants Marco> class definitions to be loaded before it can compile code which Marco> uses the accessor defined in the defclass form. In this Marco> particular case we have the method print-object which uses the Marco> raw-url accessor defined in a defclass in that same Marco> file. attempting to compile the file without loading it first Marco> gives this error. you have two (or three) options: 1) move the Marco> defclass form into an eval-when or another file, 2) use Marco> (slot-value object 'raw-url) as opposed to (raw-url object) and Marco> 3) talk to some people who know cmucl better than I and see Marco> whats really going on. I've chosen option (2). I'd also like to understand why this happens some day. Hmm, trying to run UCW feels like walking a minefield. I hit one other problem about CMUCL complaining about function "package" being redefined. Seems this is because of the admin-repl component. Renaming the "package" slot (and the accessor) to "ucw-package" fixed this problem. And hey, I was ready to run the example! Lo and behold, it all worked, and the example presented me with a nice login screen, where I entered "admin/admin". And... *** BOOM! *** [3289250968] Recursive request error #. Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: 134249192 is not of type (UNSIGNED-BYTE 27) [Condition of type TYPE-ERROR] Restarts: 0: [ABORT ] Abort this request 1: [RETRY ] Retry rendering ucw/admin/admin-repl.tal. 2: Retry rendering the component. 3: Retry rendering ucw/tabbed-pane.tal. 4: Retry rendering the component. 5: Retry rendering ucw/admin/server-admin-interface.tal. 6: Retry rendering the component. 7: Clearout the response and retry calling the action. 8: [SERVER-ERROR] Send the client an internal server error page. 9: [DESTROY ] Destroy the process Debug (type H for help) (DEBUG::DEBUG-LOOP) Source: ; File: target:code/debug.lisp (DEBUG-INTERNALS:TOP-FRAME) 0] 8 Ok, 8 seems like a good choice. But... [3289251043] Reaping dead sessions. ; [GC threshold exceeded with 49,911,368 bytes in use. Commencing GC.] ; [GC completed with 48,886,432 bytes retained and 1,024,936 bytes freed.] ; [GC will next occur when at least 60,886,432 bytes are in use.] ; [GC threshold exceeded with 60,894,696 bytes in use. Commencing GC.] ; [GC completed with 60,894,704 bytes retained and -8 bytes freed.] ; [GC will next occur when at least 72,894,704 bytes are in use.] ; [GC threshold exceeded with 72,904,568 bytes in use. Commencing GC.] ; [GC completed with 72,906,440 bytes retained and -1,872 bytes freed.] ; [GC will next occur when at least 84,906,440 bytes are in use.] ; [GC threshold exceeded with 84,920,416 bytes in use. Commencing GC.] ; [GC completed with 81,347,584 bytes retained and 3,572,832 bytes freed.] ; [GC will next occur when at least 93,347,584 bytes are in use.] ; [GC threshold exceeded with 93,356,768 bytes in use. Commencing GC.] ; [GC completed with 93,358,640 bytes retained and -1,872 bytes freed.] ; [GC will next occur when at least 105,358,640 bytes are in use.] ; [GC threshold exceeded with 105,372,680 bytes in use. Commencing GC.] ; [GC completed with 105,372,688 bytes retained and -8 bytes freed.] ; [GC will next occur when at least 117,372,688 bytes are in use.] ; [GC threshold exceeded with 117,382,592 bytes in use. Commencing GC.] ; [GC completed with 117,384,464 bytes retained and -1,872 bytes freed.] ; [GC will next occur when at least 129,384,464 bytes are in use.] ; [GC threshold exceeded with 129,398,496 bytes in use. Commencing GC.] ; [GC completed with 129,395,232 bytes retained and 3,264 bytes freed.] ; [GC will next occur when at least 141,395,232 bytes are in use.] ; [GC threshold exceeded with 141,405,024 bytes in use. Commencing GC.] ; [GC completed with 141,406,896 bytes retained and -1,872 bytes freed.] ; [GC will next occur when at least 153,406,896 bytes are in use.] ; [GC threshold exceeded with 153,420,992 bytes in use. Commencing GC.] ; [GC completed with 153,421,040 bytes retained and -48 bytes freed.] ; [GC will next occur when at least 165,421,040 bytes are in use.] ; [GC threshold exceeded with 165,430,976 bytes in use. Commencing GC.] [...snipped...] ; [GC completed with 463,511,624 bytes retained and -80 bytes freed.] ; [GC will next occur when at least 475,511,624 bytes are in use.] ; [GC threshold exceeded with 475,521,480 bytes in use. Commencing GC.] ; [GC completed with 475,523,352 bytes retained and -1,872 bytes freed.] ; [GC will next occur when at least 487,523,352 bytes are in use.] ; [GC threshold exceeded with 487,537,384 bytes in use. Commencing GC.] Process inferior-lisp terminated This is when I finally managed to kill the lisp process after a lengthy swap session. I'm scared now. GC showing negative numbers of bytes freed? For the reference, this is CMUCL snapshot 2003-12, mod-lisp 2.33. thanks, --J. From mb at bese.it Fri Mar 26 20:50:32 2004 From: mb at bese.it (Marco Baringer) Date: Fri, 26 Mar 2004 21:50:32 +0100 Subject: [Bese-devel] Problems compiling 0.2.0 with CMUCL In-Reply-To: Message-ID: <392C6F6A-7F67-11D8-99DB-000393599076@bese.it> On Venerd?, mar 26, 2004, at 02:12 Europe/Rome, Jan Rychter wrote: > Seems it isn't fixed in the asdf-installable acl-compat that I use. you might want to try using the CVS version, but if it seem s to work then i'd just stick with what you have. > Well, I still get this: > > SWANK-BACKEND:SET-DEFAULT-DIRECTORY already names an ordinary > function or a > macro. If you want to replace it with a generic function, you > should remove > the existing definition beforehand. this is a slime bug which was fixed a few hours ago. > the "package" slot (and the accessor) to "ucw-package" fixed this > problem. And hey, I was ready to run the example! Lo and behold, it all > worked, and the example presented me with a nice login screen, where I > entered "admin/admin". And... *** BOOM! *** [well, our soap opera has found it's theme song: cue Mindfields by the Prodigy] do you also have problems with the portableaserve backend? unfortunetely i didn't have time to install an apache on the x86 box so i couldn't verify this personally. it does look very "interesting" > [3289250968] Recursive request error #. recursive request errors happen when there's an error in the action code and the error handling code also signals an error. the code which could cause this is the inspectable backtrace generator (see request-loop-error.lisp), which, given the really weird errors you're getting could mean that i'm using the sldb code in ways it shouldn't be used. The fact that the error occurs while calling DEBUG-INTERNALS:TOP-FRAME supports this. what error do you get if you set ucw::*debug-on-error* to nil? > [snip wierd gc messasges] > I'm scared now. GC showing negative numbers of bytes freed? yeah, the latest cmucl versions can actually allocate (and free) anti-matter. :) -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From jan at rychter.com Fri Mar 26 21:53:06 2004 From: jan at rychter.com (Jan Rychter) Date: Fri, 26 Mar 2004 13:53:06 -0800 Subject: [Bese-devel] Problems compiling 0.2.0 with CMUCL In-Reply-To: <392C6F6A-7F67-11D8-99DB-000393599076@bese.it> (Marco Baringer's message of "Fri, 26 Mar 2004 21:50:32 +0100") References: <392C6F6A-7F67-11D8-99DB-000393599076@bese.it> Message-ID: [...] >> the "package" slot (and the accessor) to "ucw-package" fixed this >> problem. And hey, I was ready to run the example! Lo and behold, it >> all worked, and the example presented me with a nice login screen, >> where I entered "admin/admin". And... *** BOOM! *** Marco> [well, our soap opera has found it's theme song: cue Mindfields Marco> by the Prodigy] Yes, that would fit very well indeed! Marco> do you also have problems with the portableaserve backend? I've just tried it. I have a different set of problems with the portableaserve backend. It kind-of works, produces these from time to time: No matching method for the generic function #, when called with arguments (NIL). [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR] Restarts: 0: [CONTINUE] Retry call to :FUNCTION. 1: [ABANDON ] Abandon this request and wait for the next one 2: [DESTROY ] Destroy the process Debug (type H for help) ("DEFMETHOD NO-APPLICABLE-METHOD (T)" # # # (NIL)) Source: ; File: target:pcl/braid.lisp (CERROR "Retry call to ~S." 'NO-APPLICABLE-METHOD-ERROR :FUNCTION GENERIC-FUNCTION ...) 0] and mostly presents me with very cool Internal Server Error screens with monstrous and scary backtraces, after a lengthy wait (boy, is it slow). But hey, I ran the Hello World example and it worked. So, yes, the portableaserve backend works kind of better :-) --J. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: