From mb at bese.it Mon Feb 2 18:44:56 2004 From: mb at bese.it (Marco Baringer) Date: Mon, 2 Feb 2004 19:44:56 +0100 Subject: [Bese-devel] Problemi con l'installazione di cl-icu In-Reply-To: <401E023F.8000706@quinary.com> Message-ID: On Luned?, feb 2, 2004, at 08:54 Europe/Rome, Giannandrea Castaldi wrote: > I'm using cmucl 18e-r2 and I'm already using uffi 1.4.6. The complete > backtrace is the following: > Execution of a form compiled with errors: > (ALIEN:DEF-ALIEN-TYPE IT.BESE.CL-ICU::UCALENDAR (* C-CALL:VOID)) > [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR] i spent a bit of time today with cmucl and managed to get to the bottow of this. the issues i found were: 1) when we want a void pointer on cmucl we need something of type (* t), not (* c-call:void), which is what uffi translates (* :void) into under cmucl. this can be fixed by changing all the def-foreign-type (* :void) to :pointer-void, or by having uffi special case (* :void) on cmucl. this also requires modifying all the calls to make-null-pointer which pass :void as the pointer type. 2) cmucl wants foreign-strings to be arrays of type (signed 8), not (unsigned 8). cl-icu should pass foreign-string and not cstrings to the alien functions. i branched uffi and commited these changes, cl-icu was updated to fix a few other misc errors which came up. using the latest revision from bese-2004 at common-lisp.net/cl-icu--dev--0.1 and the modified uffi from bese-devel at common-lisp.net/uffi--cmucl-void-pointers--1.4 i was able to compile load and run the examples. i don't really think what i did to uffi was the best possible solution, but at least it works. p.s. - this probably broke cl-icu on openmcl.... -- 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 Feb 3 21:50:12 2004 From: mb at bese.it (Marco Baringer) Date: Tue, 3 Feb 2004 22:50:12 +0100 Subject: [Bese-devel] Problemi con l'installazione di cl-icu In-Reply-To: Message-ID: ok, i have updated cl-icu to not use (* :void) where it really should be using :pointer-void. however, the bug in uffi regarding signed vs unsigned bytes in foreign string remains. it should now be sufficent to run the latest cl-icu using a uffi with patch-3 (to be precise: uffi--cmucl-void-pointers--1.4--patch-3) applied. -- 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 Thu Feb 5 19:43:37 2004 From: mb at bese.it (Marco Baringer) Date: Thu, 5 Feb 2004 20:43:37 +0100 Subject: [Bese-devel] Problemi con l'installazione di cl-icu In-Reply-To: Message-ID: <97576EAE-5813-11D8-9DA1-000393599076@bese.it> ok, fixed, no changes to uffi neccessary (a few changes to my mind were however in order). in particular bese-2004 at common-lisp.net/cl-icu--dev--0.1--patch-5 is a working (with cmucl and an unmodified uffi) version of cl-icu. -- 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 Feb 7 19:32:43 2004 From: mb at bese.it (Marco Baringer) Date: Sat, 7 Feb 2004 20:32:43 +0100 Subject: [Bese-devel] ucw session transactions Message-ID: <6631397E-59A4-11D8-A07D-000393599076@bese.it> we've got session transactions! have a look at examples/transaction.lisp in a upto the minute ucw (ucw--dev--0.1--patch-94). nested transaction need a bit more thought but basically the idea is this: you setup up a start and end session-frame, when you get past the end frame every action beteen the start and end is substituted with an action which just takes you to the final component. the request-response loop has been completly refactored, i've elimintated a bunch of special variables in favor of a single *context* special which is a request-contex object holding all the various "stuff" we need during a request-response iteration. in the process ucw has lost a lot of error handling code, a bunch of things which previously gave you a heplful page explaining what went wrong now just drop you into the debugger. anyway, if anybody wants to go stomp on ucw a bit i'd be happy to know where it breaks. (i've tested lightly and only on openmcl + aserve.) -- 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 Mon Feb 9 22:31:47 2004 From: mb at bese.it (Marco Baringer) Date: Mon, 9 Feb 2004 23:31:47 +0100 Subject: [Bese-devel] [ucw] back to a past which doesn't exist anymore Message-ID: while playing around with transactions i ran into the following situation: suppose components A and B are called sequentially within a transaction. after the transaction terminates the user is taken to the "final" component (whatever that may be). now let's suppos the user returns to the page rendered by A and attempts to follow a link, at this point our transaction voodoo comes in and simply returns the user to the "final" component, and this is Good. however let's suppose the user then returns again but this time goes back to a page rendered by B and follows a link. Ascii art: t -> A [follow a link] B [follow a link] C [back button * 2] A [back button * 2] B [follow a link] ERROR Since the user followed a link on the A "page" (ie the output of the component A) the session stack was wiped from A onwards, hence we no longer have any reference the actions available from B and the server errors. This is not only a transaction issue, any time we go back to a componnet and then go back to a component which came after the component we went back to we'll run inte this inexistent action error. Having the session stack be a tree would solve this, but what would we gain? We could simply incode session + frame + action in a single value and put them in a application wide hash table, then we could update all the actions which a back action has elimintated, but this would mean that we'd need to look a basically global variable every time we get a request, which doesn't seem like a great idea either. so, i'm stumped. p.s. - does anybody follow ucw-devel at common-lisp.net from nntp? -- 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 Mon Feb 9 22:41:09 2004 From: mb at bese.it (Marco Baringer) Date: Mon, 9 Feb 2004 23:41:09 +0100 Subject: [Bese-devel] [ucw] rfc: how to handle transactions Message-ID: <0E3B48F2-5B51-11D8-AA95-000393599076@bese.it> christion queinnec (one very smart cookie) implements transactions with something along these lines: (let ((done-p nil)) (when done-p (call sorry-cant-do-this-more-than-once) (exit-from-let-body)) (call some-page) (setf done-p t)) basically the use of the lexical done-p ensures that the body of the let will only be executed once (due to the fact that done-p is a closed over variable which doesn't change values on subsequent returns from (call same-page)). i'd really love the implementation of transactions in ucw to be this simple, however unlike queinnec's model we can't be sure that the call to call will only show one page (in fact in his model CALL is actually SHOW-PAGE (or something similar)). anyway, what i'm wondering is this: if component FOO is in a transaction, and that transaction has already terminated, should we simply not allow FOO to return multiple times (as would happen with the above implementation) or should we do keep doing what ucw currently does and not allow any of the pages generated by FOO (or components called by FOO) to call actions? -- 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 Thu Feb 12 15:23:54 2004 From: mb at bese.it (Marco Baringer) Date: Thu, 12 Feb 2004 16:23:54 +0100 Subject: [Bese-devel] [ucw] 0.1.1 Message-ID: <785E8D66-5D6F-11D8-A91A-000393599076@bese.it> i've put up a snapshot of ucw (with the latest versions of all the required libraries) as it is today, it's not 0.2 or anything but it'll at least let people play with some of the new features (hint hint hint). ftp://ftp.common-lisp.net/pub/project/ucw/ucw_0.1.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 mh-freiburg.de Thu Feb 12 15:50:44 2004 From: rm at mh-freiburg.de (Le grand pinguin) Date: Thu, 12 Feb 2004 16:50:44 +0100 Subject: [Bese-devel] [ucw] 0.1.1 In-Reply-To: <785E8D66-5D6F-11D8-A91A-000393599076@bese.it>; from mb@bese.it on Thu, Feb 12, 2004 at 04:23:54PM +0100 References: <785E8D66-5D6F-11D8-A91A-000393599076@bese.it> Message-ID: <20040212165044.A15829@forte.mh-freiburg.de> On Thu, Feb 12, 2004 at 04:23:54PM +0100, Marco Baringer wrote: > i've put up a snapshot of ucw (with the latest versions of all the > required libraries) as it is today, it's not 0.2 or anything but it'll > at least let people play with some of the new features (hint hint hint). > > ftp://ftp.common-lisp.net/pub/project/ucw/ucw_0.1.1.tar.gz Thanks for the work Ralf Mattes > -- > 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 mbkennedy at austin.rr.com Fri Feb 13 07:24:05 2004 From: mbkennedy at austin.rr.com (Matthew Kennedy) Date: Fri, 13 Feb 2004 01:24:05 -0600 Subject: [Bese-devel] problem compiling arnesi-1.1.1 on clisp-2.32 Message-ID: <87fzdffnmy.fsf@killr.ath.cx> Hi Marco, I'm experiencing a problem compiling arnesi-1.1.1 with clisp. The error message is below. The problem seems to be in src/specials.lisp, def-special-environment, check-required, but I can't see why it would work in SBCL and CMUCL but not CLISP. CLISP-ism perhaps? Matt [1]> (asdf:oos 'asdf:compile-op :arnesi) ... Compiling file /home/mkennedy/tmp/arnesi_1.1.1/src/code-transformers/walk/walk.lisp ... ** - Continuable Error EVAL: undefined function CHECK-REQUIRED If you continue (by typing 'continue'): Retry The following restarts are also available: STORE-VALUE :R1 You may input a new value for (FDEFINITION 'CHECK-REQUIRED). USE-VALUE :R2 You may input a value to be used instead of (FDEFINITION 'CHECK-REQUIRED). RETRY :R3 Retry performing # on #. ACCEPT :R4 Continue, treating # on # as having been successful. Break 1 ARNESI[2]> -- Matthew Kennedy -------------- 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 Feb 14 13:37:04 2004 From: mb at bese.it (Marco Baringer) Date: Sat, 14 Feb 2004 14:37:04 +0100 Subject: [Bese-devel] problem compiling arnesi-1.1.1 on clisp-2.32 In-Reply-To: <87fzdffnmy.fsf@killr.ath.cx> Message-ID: On Venerd?, feb 13, 2004, at 08:24 Europe/Rome, Matthew Kennedy wrote: > Hi Marco, > > I'm experiencing a problem compiling arnesi-1.1.1 with clisp. The > error message is below. The problem seems to be in > src/specials.lisp, def-special-environment, check-required, but I > can't see why it would work in SBCL and CMUCL but not CLISP. > CLISP-ism perhaps? i don't really know, it would seem that the macro expanders are losing the flet'd function check-required. you could try putting the def-special-enviroment form in another file, compiled and loaded before walk.lisp. btw, what does this return: (flet ((a () 4)) (defmacro b () (a))) (b) p.s. - arnesi 1.1.2 contains a new cps transformer (if that's what you're interested in) which, among other things, doesn't use def-special-enviroment, is faster and can handle more of comman lisp (in particular its handling of declarations is much improved). -- 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 Mon Feb 16 15:52:47 2004 From: mb at bese.it (Marco Baringer) Date: Mon, 16 Feb 2004 16:52:47 +0100 Subject: [Bese-devel] [ucw] i18n Message-ID: <2A672084-6098-11D8-B733-000393599076@bese.it> before i explain the i18n stuff i need to explain what's been going on with the rerl api lately. As anyone who has tried to load (let alone compile) ucw from patch-104 onwards knows: NOTHING EVER WORKED! sorry, it was painfull but neccessary, i probably should have done the work on a seperate branch, but when i started it was just a minor touchup here and there and the change kind of snowballed from there. We now have a real protocol which defines how the various "phases" of the request-response loop work. The protocol is defined in the aptly named src/rerl/procotocl.lisp, methods are defined in terms of generic "application", "server", "session" abjocts and implementations are providide via "standard-server", "standard-application", ... objects. This protocol is designed to allow changes to request-response handling to be done in a modular and clean way without having to go in and change the ucw core. the i18n application is the test of this protocol. Now, i18n. Our goal is to make it easy to handle requests differently based an the languages the client prefers. We have a class i18n-application (sub class of standard-application) which, at request-context creation time, inspects the request and choses, among the locales the application knows about, the "best" one (based on the client's accept-language header). The collest thing (from a design point of view) is that this i18n stuff is done by defining 2 new clasess and 2 new methods, in theory i could have done without access to the ucw source code. Currently the only visible change is that when you call render-template we first look for a locale specific version of the template, if that fails we fall back to a generic un specified version. We would really like this voodoo to happen when a tal:include tag is found, i'm currently looking into how to best redefine that tag. I've decided that people who use the yaclml macros are own their own, they can always get at the current locale vio the context, but ucw isn't going to do much more code side. Next on the list is a collection of tags for formatting and parsing dates and numbers (preferably integrated with the ucw:accessor attributes), then we'll see about pluging into resource bundles to provide translated messages nested inside templates without having to create a whole now template. Since i've learned my lesson i'm leaving the ucw--dev branch alone and all this work is being done on ucw at common-lisp.net/ucw--i18n--0.1 branch. this isn't really ready enough that i can say "GO! HACK IT 'TILL IT BREAKS!", however if anyone has any comments to make regarding the integration of i18n and ucw i'd like to hear them now, as opposed to months from now. -- 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 Mon Feb 16 17:14:05 2004 From: mb at bese.it (Marco Baringer) Date: Mon, 16 Feb 2004 18:14:05 +0100 Subject: [Bese-devel] Re: [ucw] i18n (locale sensitive template inclusion) In-Reply-To: <2A672084-6098-11D8-B733-000393599076@bese.it> Message-ID: <8616934B-60A3-11D8-95EC-000393599076@bese.it> On Luned?, feb 16, 2004, at 16:52 Europe/Rome, Marco Baringer wrote: > Currently the only visible change is that when you call > render-template we first look for a locale specific version of the > template, if that fails we fall back to a generic un specified > version. We would really like this voodoo to happen when a tal:include > tag is found, i'm currently looking into how to best redefine that > tag. damn that was really easy. turns out that yaclml goes through a method named template-truename, by creating a new template-generator (subclass of yaclml:file-system-generator) i got render-template and tal:include to be locale sensitive. Now your i18n apps will need to specify that the tal generators are of class i18n-tal-generator but that's all you have to do. every now and then you realize what's so cool obout clos (and OO). -- 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 Thu Feb 19 09:43:26 2004 From: mb at bese.it (Marco Baringer) Date: Thu, 19 Feb 2004 10:43:26 +0100 Subject: [Bese-devel] pxmlutils, xml parsing and *respect-readtable-case* Message-ID: <113540C4-62C0-11D8-9098-000393599076@bese.it> very recently (yesterday or the day before) i added the following feature to pxmlutils: When tags are converted to symbols if the variable pxmlutils:*respect-readtable-case* is true than the symbols will be upcase/downcase/preserve'd accoring to the value of (readtable-case *readtable*). I'm going to test this for a few days and if it turns out be work ok then i'm going to release pxmlutils version 1.0. they only reason i'm hesitante obut this is that it makes pxmlutils into a fork of franz's xmlutils, and not just a porting operation. oh well. these changes are in bese-2004 at common-lisp.net/pxmlutils--dev--1.0 -- 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 Mon Feb 23 12:36:53 2004 From: mb at bese.it (Marco Baringer) Date: Mon, 23 Feb 2004 13:36:53 +0100 Subject: [Bese-devel] [ucw] 0.2.0pre0 Message-ID: ftp://ftp.common-lisp.net/pub/project/ucw/ucw_0.2.0pre0.tar.gz The tar ball contains a file called RELEASE which summarizes all the changes since 0.1.0, here's a summary of the more important ones: 1) We now have a protocol which defines how the various "phases" of the request-response loop work. The protocol is defined in terms of generic "application", "server", "session" objects and implementations are providide via "standard-server", "standard-application", etc classes and methods. This protocol is designed to allow changes to request-response handling to be done in a modular and clean way without having to go in and change the ucw core. 2) UCW's standard-session understands "session transactions" which allow use to explicity define blocks of code which have "once and only once" interaction properties. 3) TAL templates are now XML documents. This premits us to use xml namespaces to associate names with handlers, this is a much cleaner and extensable solution than the "let's fake it with keywords with funky names" solution we had before. Definig yaclml tags and tal attribute/tag handlers is stiil something of a bitch though. ======== as with the 0.1.1 release this tarball also contains the proper versions of all the supported libraries, make sure that asdf sees these new versions. -- 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 Mon Feb 23 12:40:51 2004 From: mb at bese.it (Marco Baringer) Date: Mon, 23 Feb 2004 13:40:51 +0100 Subject: [Bese-devel] [ucw] 0.2.0pre0 In-Reply-To: Message-ID: <83776485-65FD-11D8-AFF7-000393599076@bese.it> p.s. - GO! HACK IT 'TILL IT BREAKS! -- 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 mh-freiburg.de Mon Feb 23 19:44:17 2004 From: rm at mh-freiburg.de (Le grand pinguin) Date: Mon, 23 Feb 2004 20:44:17 +0100 Subject: [Bese-devel] [ucw] 0.2.0pre0 In-Reply-To: <83776485-65FD-11D8-AFF7-000393599076@bese.it>; from mb@bese.it on Mon, Feb 23, 2004 at 01:40:51PM +0100 References: <83776485-65FD-11D8-AFF7-000393599076@bese.it> Message-ID: <20040223204417.A27610@forte.mh-freiburg.de> On Mon, Feb 23, 2004 at 01:40:51PM +0100, Marco Baringer wrote: > p.s. - GO! HACK IT 'TILL IT BREAKS! Oh, we do! just spent some time migrating TAL to xml :-/ Bummer, you were faster. BTW, i seem to miss some bits of information regarding the TAL templates: I'd like to have the TAL transformer substitute some attribute values, i.e.
    • All i get is href='$rl' -- is this not yet implemented? Who is eating the 'u'? Thanks anyway Ralf Mattes > -- > 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 mb at bese.it Mon Feb 23 20:11:16 2004 From: mb at bese.it (Marco Baringer) Date: Mon, 23 Feb 2004 21:11:16 +0100 Subject: [Bese-devel] [ucw] 0.2.0pre0 In-Reply-To: <20040223204417.A27610@forte.mh-freiburg.de> Message-ID: <6F920470-663C-11D8-AFF7-000393599076@bese.it> Luned?, 23 feb 2004, alle 20:44 Europe/Rome, Le grand pinguin ha scritto: > I'd like to have the TAL transformer substitute some attribute > values, i.e. > >
  • tal:replace='$name'>
    • > > All i get is href='$rl' -- is this not yet implemented? Who is > eating the 'u'? [the #\u getting removed is a bug] [This is an as yet un documented bit of TAL:] You can put lisp expressions in tal files in two places: 1) tal: or ucw: attributes (like tal:dolist or ucw:accessor), in these cases the value of the attribute is really just lisp code with #\$ bound to a read macro. 2) in every other attribute (like your href above) we use this syntax: everything in the attribute is concatenade together, if we find a ${...} then the result of elavuating ... is concatenated, if we find a @{...} then every element of the list returned by ... is concatended individually. In both cases ... is read with the usual #\$ read macro. examples (assuming url is bound to "ucw" is the enviroment): A) NAME -- 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 mh-freiburg.de Mon Feb 23 20:25:49 2004 From: rm at mh-freiburg.de (Le grand pinguin) Date: Mon, 23 Feb 2004 21:25:49 +0100 Subject: [Bese-devel] [ucw] 0.2.0pre0 In-Reply-To: <6F920470-663C-11D8-AFF7-000393599076@bese.it>; from mb@bese.it on Mon, Feb 23, 2004 at 09:11:16PM +0100 References: <20040223204417.A27610@forte.mh-freiburg.de> <6F920470-663C-11D8-AFF7-000393599076@bese.it> Message-ID: <20040223212549.C27610@forte.mh-freiburg.de> On Mon, Feb 23, 2004 at 09:11:16PM +0100, Marco Baringer wrote: > Luned?, 23 feb 2004, alle 20:44 Europe/Rome, Le grand pinguin ha > scritto: > > > I'd like to have the TAL transformer substitute some attribute > > values, i.e. > > > >
  • > tal:replace='$name'>
    • > > > > All i get is href='$rl' -- is this not yet implemented? Who is > > eating the 'u'? > > [the #\u getting removed is a bug] I guessed so :-) > [This is an as yet un documented bit of TAL:] > [....] > Ah, thank's, i just changed my code and now it works fine. 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 From mb at bese.it Mon Feb 23 21:27:42 2004 From: mb at bese.it (Marco Baringer) Date: Mon, 23 Feb 2004 22:27:42 +0100 Subject: [Bese-devel] [ucw] 0.2.0pre0 In-Reply-To: <20040223212549.C27610@forte.mh-freiburg.de> Message-ID: <1CDE8FF9-6647-11D8-AFF7-000393599076@bese.it> Luned?, 23 feb 2004, alle 21:25 Europe/Rome, Le grand pinguin ha scritto: > On Mon, Feb 23, 2004 at 09:11:16PM +0100, Marco Baringer wrote: >> Luned?, 23 feb 2004, alle 20:44 Europe/Rome, Le grand pinguin ha >> scritto: >> >>> I'd like to have the TAL transformer substitute some attribute >>> values, i.e. >>> >>>
  • >> tal:replace='$name'>
    • >>> >>> All i get is href='$rl' -- is this not yet implemented? Who is >>> eating the 'u'? >> >> [the #\u getting removed is a bug] > > I guessed so :-) this patch fixes it: bese-2004 at common-lisp.net/yaclml--dev--0.3--patch-6 ("tla replay" from the directory ucw_0.2.0pre0/libs/yaclml/ will grab the patch assuming you have tla and the bese-2004 at common-lisp.net archive registered) -- 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 Feb 27 17:13:25 2004 From: mb at bese.it (Marco Baringer) Date: Fri, 27 Feb 2004 18:13:25 +0100 Subject: [Bese-devel] ucw status Message-ID: <40BADD36-6948-11D8-B842-000393599076@bese.it> i fixed same issues with the i18n tags (i18n:date-accessor and i18n:format) and refactored the systems so that you can now use some i18n featuers even without cl-icu. i've also added a tabbed-pane component and converted the admin application to use it, nested tabs look really really ugly (does anybody have a quick 'n easy suggestion for making ucw look a litte bit better?). ucw is currently ONLY being tested on openmcl on darwin (i'm without access to an x86 machine), if anybody has any problems using ucw on other systems please speak up. hopefully i'll update the docs and have a 0.2.0 out by early next week (but there won't be a functional changes before then so if you want to take ucw for a spin now is as good a time as any). for the curious here's a tentative todo list for 0.3.0: a) More components (tree view, i18n stuff, grid view). b) flash based components (color or date pickers) c) form validation and processing APIs d) macros for constructing pages from components ala CLIM. e) session serialization. -- 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 asf at boinkor.net Sat Feb 28 10:26:59 2004 From: asf at boinkor.net (Andreas Fuchs) Date: Sat, 28 Feb 2004 11:26:59 +0100 Subject: [Bese-devel] ucw status In-Reply-To: <40BADD36-6948-11D8-B842-000393599076@bese.it> References: <40BADD36-6948-11D8-B842-000393599076@bese.it> Message-ID: <868yin33f0.wl%asf@boinkor.net> On 2004-02-27, Marco Baringer wrote: > i fixed same issues with the i18n tags (i18n:date-accessor and > i18n:format) and refactored the systems so that you can now use some > i18n featuers even without cl-icu. i've also added a tabbed-pane > component and converted the admin application to use it, nested tabs > look really really ugly (does anybody have a quick 'n easy > suggestion for making ucw look a litte bit better?). As to making it look a little better, I have only one advice: Drop the tables and use a style sheet. especially for the tabbed panes, I think this will really pay off. For two nice examples, have a look at http://csszengarden.com/?cssfile=/057/057.css&page=3 and http://www.csszengarden.com/?cssfile=053%2F053%2Ecss (I know that there is another design which has a beautiful tabbed bar, but I'm currently unable to find it. Will report back when I found it.) > ucw is currently ONLY being tested on openmcl on darwin (i'm without > access to an x86 machine), if anybody has any problems using ucw on > other systems please speak up. Using sbcl on x86, I can't compile ucw--dev--0.1--patch-173 with a current bese (built config from dev/1.1). There are a few errors regarding the symbol yaclml:*uri-for-package*, which is not in the YACLML package. which is the recommended version of bese to use with current UCW? > for the curious here's a tentative todo list for 0.3.0: > > a) More components (tree view, i18n stuff, grid view). > > b) flash based components (color or date pickers) > > c) form validation and processing APIs > > d) macros for constructing pages from components ala CLIM. > > e) session serialization. Sounds great! Very much looking forward to showing off ucw to the few java web hackers that I know (-: -- Andreas Fuchs, , asf at jabber.at, antifuchs From mb at bese.it Sat Feb 28 13:38:54 2004 From: mb at bese.it (Marco Baringer) Date: Sat, 28 Feb 2004 14:38:54 +0100 Subject: [Bese-devel] ucw status In-Reply-To: <868yin33f0.wl%asf@boinkor.net> Message-ID: <735F4003-69F3-11D8-B842-000393599076@bese.it> On Sabato, feb 28, 2004, at 11:26 Europe/Rome, Andreas Fuchs wrote: > As to making it look a little better, I have only one advice: Drop the > tables and use a style sheet. especially for the tabbed panes, I think > this will really pay off. > > For two nice examples, have a look at > http://csszengarden.com/?cssfile=/057/057.css&page=3 and > http://www.csszengarden.com/?cssfile=053%2F053%2Ecss cool, will do after 0.2.0. If i keep adding stuff before 0.2.0 i'll never get it out, and i'd like to, occasionally at least, have recognizable milestones. > Using sbcl on x86, I can't compile ucw--dev--0.1--patch-173 with a > current bese (built config from dev/1.1). There are a few errors > regarding the symbol yaclml:*uri-for-package*, which is not in the > YACLML package. due to various issues (bugs i couldn't fix and speed) the YACLML package no longer uses pxmlutils but uses Miles Egan's XMLS parser (a heavly modified version). UCW as it stands requires yaclml 0.4.0. > which is the recommended version of bese to use with current UCW? it's somthing of a problem since the various packages are evolving together and i keep changing them and there's no way to know what i'm doing unless i announce it (which i don't). Here's the list of versions i'm currently using (and which are included in the soon to be released 0.2.0pre1): [except ucw all the trees are in the bese-2004 at common-lisp.net archive] yaclml: yaclml--dev--0.4 arnesi: arnesi--dev--1.1 cl-icu (optional): cl-icu--dev--0.0 ucw: ucw at common-lisp.net/ucw--dev--0.1 pxmlutils is no longer required. other than these you'll need recent CVS versions of portableaserve (recent enough to have puri packaged in it) and slime. Due to these incompatable changes when you're playing around with ucw you need to make sure that asdf sees the proper version of all 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 mb at bese.it Sat Feb 28 14:45:29 2004 From: mb at bese.it (Marco Baringer) Date: Sat, 28 Feb 2004 15:45:29 +0100 Subject: [Bese-devel] ucw 0.2.0pre1 Message-ID: due to some issues people (myself included) were having running the latest ucw i've put up a new tar ball of ucw in it's current state: ftp://ftp.common-lisp.net/pub/project/ucw/ucw_0.2.0pre1.tar.gz This tar ball contains ucw and the versions of all the latest libs i'm using to test and develop. Testing this dist should be a simple matter of: 1) get and unpack the tarball 2) setup asdf so that it sees the ucw_0.2.0pre1/systems/ directory (if you have other versions of ucw, yaclml, cl-icu, portableaserve, cl-ppcre, puri, etc. make sure those are _not_ visible). It should be sufficent to set asdf:*central-registry* to (list "ucw_0.2.pre1/systems") to ensure this (everything ucw needs is in the tar ball and all the asdf systms are linked into that directory). 3) load the examples/run-examples-aserve.lisp or run-examples-modlisp.lisp 4) PROFIT! -------- Here's the scheme i'm currently using for building ucw dists, it may be usefull to figure out what you need for each version: the bese-2004 at common-lisp.net archive has a tree (support--dists--1.0) which contains configs for the simple libraries (yaclml, arnesi, cl-icu, etc.) and for ucw you'll find a directory for every release i've made. Those directories (currently we have 0.1.0, 0.2.0pre0 and 0.2.0pre1) have a RELEASE file describing what it is and a build script which pulls all the required stuff, builds up a tar ball and sends it off to common-lisp.net (obviously only I can perform that last step). So if you want to know what is required for using ucw 0.2.0pre1 you can just look in ucw/0.2.0pre1/build and see what it grabs. If anybody wants to suggest another way to create and manage these dists i'm all ears. -- 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