From henrik at evahjelte.com  Thu May  1 10:11:56 2008
From: henrik at evahjelte.com (Henrik Hjelte)
Date: Thu, 1 May 2008 12:11:56 +0200
Subject: [Bese-devel] UCW: The Future.
In-Reply-To: <bc10d2190804291452s69d4f3a7u79c4bb89d15a2746@mail.gmail.com>
References: <bc10d2190804291452s69d4f3a7u79c4bb89d15a2746@mail.gmail.com>
Message-ID: <50e8e4f60805010311j199e467ep3e26663fa12e8133@mail.gmail.com>

On Tue, Apr 29, 2008 at 11:52 PM, Drew Crampsie <drewc at tech.coop> wrote:
> Hello UCW users/developers,
>
>  The UCW project has been without direction for quite a while now.
>  We've got one of the most advanced web application development
>  environments out there, but it's not used widely, unstable,
>  underdocumented and a bit of a mess. In order to alleviate this
>  situation, and to bring UCW into the mainstream lisp web world, I've
>  volunteered to step in as maintainer/visionary.

Great.

UCW is not perfect, but not as bad as it sounds either. I think it is more
used than people think, there are some real production sites using it.

>  I'd like to find out who's using UCW, how they are using it, what
>  versions they are using (-dev, -ajax, -something-else) and what they'd
>  like to see happen to the project.

The http://stix.to true beta uses ucw_ajax, with some internal additions.
We have tried almost all backends, but are currently using iolib.
As a frontend to add gzip compression and for static files we use the
nginx webserver (stable version)and the HAProxy as a proxy server to
distribute requests with sticky sessions to currently 4 sbcl processes on
one dual-core server. Two of the processes are dedicated to serve
json-rpc requests.

The persistence library is elephant with a postgresql backend.

Since the processes crashes or becomes unresponsive from time to
time we have a monitoring script to check and restart the processes.
No big deal, Ruby works the same way :-) And I think Java does too,
except it never crashes just takes forever to load. The crashes also
seems to have disappeared with the newest sbcl version.

So far, we have been quite happy with ucw, but the basic stix.to site is
quite basic so far, and we will need to develop or improve it further.
In what direction? I don't know yet.. we hope to need scalability and
great features, and a framework we like. It might be ucw or the dwim
branch or something new. But, I see no need to do everything
from scratch, so the basic webserver functionality we will take from
one of these projects. I like that there are choices of backends in ucw,
if you have problem with one you can easily choose another. But it
can go to far also. Two or three should be enough. One simple, one fast
and a third for fun..

>  I'm going to be very aggressive in
>  following a few ideals/guidlines for UCW that should make it more
>  widely usable.
>
>  1) No arbitrary breaking. The test suite will be run and its results
>  included in every commit message. the API will not change drastically
>  all the time. Libraries will not be added/removed without taking steps
>  to make sure things work. A buildbot will be setup. UCW will become a
>  lot more professional.

I agree completely. It is important to make it possible to contribute to the
project without being afraid of breaking things. I think this will
increase the quality and involvement of developers.
Also, everyone should be responsible of making sure that the tests
are of high quality as well. For some reason Lispers seldom like testing.

I would like a fanatic test setup:
* Unittests in the same file as the code, to serve as tests and documentation.
* Refusal to add new features if they don't come with testcases. Or put them
in a second class code repo until they have tests..
* Code without tests is code you are allowed to remove.

We might consider selenium tests for browser testing.

>  4) documentation will be written, and maintained. Now new features
>  will be added unless documented and tested.
But if something is well written and well tested i see no use for
documentation in the code. When the documentation gets rotten it only
adds to the confusion. I fully agree with Attila in his second response.
But high level descriptions and documentation serves a purpose.

>
>  5) modularization will be more explicit. I added a patch a while ago
>  to allow a more 'plugin' like architecture, and this will be
>  exploited. component libraries, form libraries etc will not be part of
>  UCW proper as there are many possible implementations. Rather, a good
>  flexible modular architecture will let the user choose to mix and
>  match higher level code, be it Lisp-on-Lines, ucw-ajax, or
>  what-have-you.

It is a good goal. The problem is that it is difficult to do this grand
design, perfect for everyone. UCW has already been very modular,
despite this I think it has failed on this account. The very OO style
design has not solved every problem. I think more plug-in functions
should be used. Not one function for standard-error-handler, since
everyone will want his own. Rather a funcall *standard-error-handler*.
or generic function on a application object.

>
>  6) Javascript will _not_be required, but will be well supported. A
>  'simple' set of ucw operators will be introduced and used for the
>  examples and documentation.

Ok, for some sites it might be necessary, but I think rather that more
javascript support should be a more important feature. Some ideas:
allow a component to add javascript to the head and to the end of
the body easily, not just add things to the current output stream.
Allow a component to say: I depend on xyz.js, and the code
generation framework could assemble all distinct include
files. Perhaps optimize file load by seeing that xyz.js is also in the
optimized file complete.js

>
>  I have great plans for UCW over the next couple months. I'd like to
>  ask everybody who reads this to chime in now and say your piece...
>  lets make UCW the poster-boy for lisp web frameworks!

If you have great plans you haven't mentioned, consider sharing them.
The last discussion on refactoring UCW did not occur on the mailing list,
and I think we should avoid the situation of going from one main
developer to another one to another one. If we could get a group working
it would be better, but then we need to share our plans and designs
better I think, if possible.

Thanks Marco and Attila for everything you have done, you have both
taught me a lot, and thanks Drew for stepping in and continuing this,
I think it will be great!

I hope and think we can help as well,

Henrik Hjelte


From nathan at acceleration.net  Fri May  2 16:16:38 2008
From: nathan at acceleration.net (Nathan Bird)
Date: Fri, 02 May 2008 12:16:38 -0400
Subject: [Bese-devel] Re: UCW: The Future
Message-ID: <481B3E66.1040005@acceleration.net>

Hail!

We've[1] been working with a framework built around ucw_dev. We use our 
own html generation stuff and have built on top of/replaced ucw's 
components. As such point 5 on modularization sounds like a great idea; 
I suspect it might be tricky to get Right. Most of our work is intranet 
only although we are currently working on a couple new projects that 
should be public (and fairly cool) in a little while.  Has anyone done 
much with any of the python frameworks? I know there has been some 
debate there between frameworks that provide everything and ones that 
facilitate hooking other libraries together. My perspective is that UCW 
would do better in the latter category.

I've not used ucw_ajax beyond poking at it for 30 minutes a year ago. It 
looked like it added/refactored some things nicely but that it was going 
to be a bit of work to convert our app to it... and then that amount of 
work just grew and we never switched. The good news there is that 
ucw_dev has proven to be stable and complete enough for us to build our 
own stuff on top of fairly well.

1) on stability sounds good. We've been talking about a buildbot setup 
around our stuff in the last couple of weeks too. ucw itself has been 
fairly good though-- that nothing in our branch of ucw has changed in a 
long time helps.
2) on reader syntax: somewhat unconcerned about using this in ucw code; 
in as much as reducing external dependencies helps point 1 and being 
standard helps point 3 it is good. My bigger concern is that I would 
like to see most UCW functionality provided by functions and classes. I 
like macros, but they seem to do best as veneer over functionality 
implemented in a more map-able form.
3) coding standards are cool.
4) 'No new features without docs' is probably a good dictum... now that 
we are already over most of that hump it matters less to me than it did 
before.
6) Everything we do uses a little javascript (and less ajax) this will 
probably expand in the future. Feelings are mixed on parenscript: I 
think it's tolerable and vaguely useful, others here think it gets in 
the way (especially now that we use cl-interpol as a standard required lib).

We currently use the httpd backend-- behind apache mod_proxy taking care 
of static files and ssl. We used mod_lisp for a while, but there didn't 
seem to be any performance benefit there based on an afternoon doing 
some rough benchmarks and my understanding of how the two codepaths 
differ. Mod proxy is standard and widely used/developed on; Mod_lisp is 
a custom installation (not to bad) and we've had one or two minor 
bugs/complaints.

Good to see this is going somewhere, hopefully we can help out on it too.

Nathan Bird

[1] http://www.acceleration.net Small company with 3 of us in the 
programming department (birdman and ryepup on #lisp) actively developing 
in Common Lisp (where we can).


From sasha-lisp at arcocene.org  Wed May  7 22:55:02 2008
From: sasha-lisp at arcocene.org (Sasha Kovar)
Date: Wed, 7 May 2008 15:55:02 -0700
Subject: [Bese-devel] ucw_ajax and Accept-Language header
Message-ID: <20080507225501.GD43350@toonlet.com>

I'm seeing a badly formatted Accept-Language header in some browser out in
the wilds of the internet.  Contrary to the HTTP spec, it wraps the value in
square brackets, e.g. "[en-us, en, ko-kr, kr, ko, ja, jp, cn]".  

This is triggering a parse error when "[en-us" is passed to cl-l10n, as it
tries to use the passed value as part of a namestring.  Rather than debate
the wisdom of that, it seemed more correct to clean up what UCW is
handing to cl-l10n.  Brackets aren't allowed in the language range, so there
should be no danger in removing them.

The attached patch just strips any '[' or ']' characters from the header
when parsing.  Test with:  
  (parse-accept-language-header "[en-us, en, ko-kr, kr, ko, ja, jp, cn]")

If that looks reasonable, could someone please apply the patch?

Thanks much,
Sasha
-------------- next part --------------
A non-text attachment was scrubbed...
Name: accept-lang.patch
Type: text/x-diff
Size: 33901 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20080507/77d942ff/attachment.patch>

From evrim at core.gen.tr  Sun May 11 09:45:37 2008
From: evrim at core.gen.tr (Evrim Ulu)
Date: Sun, 11 May 2008 12:45:37 +0300
Subject: [Bese-devel] core-server first product: coretal
Message-ID: <4826C041.9050406@core.gen.tr>

Hi,

We've launched our first product, a remote content service: Coretal. The 
system is design agnostic so any design can be used alogn with Coretal. 
Also, we'r planning it to be used remotely (ie. html can be hosted 
elsewhere) since it's just javascript. We'r running the project on 
core-server.

Here are the screencasts: http://www.core.gen.tr/#coretal

Would love to hear feedback.

Evrim.

Drew: yes i should clean my disk before recoding, lol:)


From vanek at acd.net  Sun May 11 10:53:15 2008
From: vanek at acd.net (Lou Vanek)
Date: Sun, 11 May 2008 10:53:15 +0000
Subject: [Bese-devel] core-server first product: coretal
In-Reply-To: <4826C041.9050406@core.gen.tr>
References: <4826C041.9050406@core.gen.tr>
Message-ID: <4826D01B.8070004@acd.net>

Evrim Ulu wrote:
> Hi,
> 
> We've launched our first product, a remote content service: Coretal. The 
> system is design agnostic so any design can be used alogn with Coretal. 
> Also, we'r planning it to be used remotely (ie. html can be hosted 
> elsewhere) since it's just javascript. We'r running the project on 
> core-server.
> 
> Here are the screencasts: http://www.core.gen.tr/#coretal
> 
> Would love to hear feedback.
> 
> Evrim.
> 
> Drew: yes i should clean my disk before recoding, lol:)
> _______________________________________________
> bese-devel mailing list
> bese-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel
> 

Love your header graphic, but I would have made it a little smaller
so that the page fits better in the window. The graphic is a little
tall.
Love the way the page reloads (where have I seen that before :)

Not sure what Coretal CMS exactly is. I'm guessing it's site hosting
and editing service with one site template that CIT provides. I wish this was
explained in the webcast.

In the webcast, was that a low disk warning? :)

Is this a European date format? I don't recall seeing a period used in
this way before.
   11. May, 2008 - Sunday

The site has a techy overtone. "Index Page" is usually
called "Home" in the States. Wish there was more printed
explanation of what the CMS is that you provide. Recommend
you also mention this in the webcast instead of just talking
about technical details.

The site branding is confusing. I see four different brands:

   C0R3 Internet Services
   Core Internet Technologies
   Coretal
   www.core.gen

I'm having a hard time understanding what distinguishes the
four brands. I also think throwing the zero in C0R3 is kind of
confusing.

The title I see in IE7 is,
   CDR3 Internet Services#products#coretal#coretal
(FF3 shows it correctly: CDR3 Internet Services)
If you are concerned about SEO, this should be changed.

Instead of rounding just one of the corners,
rounding all four is more web 2.0.

I'm having a hard time figuring out whether Core is
more of an open source hacker club or a real business
that provides services and products for money. If the
later, I would focus your message and ditch any references
to open source/linux/CL/etc and present a more
business-friendly message. (That would include ditching
the personal blogs, or moving them to a less prominent
location.)

As always, just my opinion. Good work Evrim.


From gugamilare at gmail.com  Mon May 12 18:58:00 2008
From: gugamilare at gmail.com (Gustavo)
Date: Mon, 12 May 2008 15:58:00 -0300
Subject: [Bese-devel] UCW doesn't accept latest parenscript version?
Message-ID: <4be8713d0805121158o63169a12o8e7d3292849dccaa@mail.gmail.com>

Hello,

I am trying to install UCW from the tutorial (without ucw-boxset) and it
seems that ucw_dev (in file src/rerl/standard-dispatcher.lisp, line 229)
tries to access the function js:compile-parenscript-file-to-string which is
not defined in parenscript (neither unexported symbol). Am I doing something
wrong? Should I get an older version of parenscript or expect this bug to be
fixed?

Thanks,
Gustavo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20080512/79bcc87b/attachment.html>

From vanek at acd.net  Mon May 12 20:18:59 2008
From: vanek at acd.net (Lou Vanek)
Date: Mon, 12 May 2008 20:18:59 +0000
Subject: [Bese-devel] UCW doesn't accept latest parenscript version?
In-Reply-To: <4be8713d0805121158o63169a12o8e7d3292849dccaa@mail.gmail.com>
References: <4be8713d0805121158o63169a12o8e7d3292849dccaa@mail.gmail.com>
Message-ID: <4828A633.3030507@acd.net>

Gustavo wrote:
> Hello,
> 
> I am trying to install UCW from the tutorial (without ucw-boxset) and it 
> seems that ucw_dev (in file src/rerl/standard-dispatcher.lisp, line 229) 
> tries to access the function js:compile-parenscript-file-to-string which 
> is not defined in parenscript (neither unexported symbol). Am I doing 
> something wrong? Should I get an older version of parenscript or expect 
> this bug to be fixed?
> 
> Thanks,
> Gustavo
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> bese-devel mailing list
> bese-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel

if you weren't able to get this fixed or find an old version,
i uploaded an old parenscript at http://www.mediafire.com/?gwrxzm9rz6v
(1.8MB)
it uncompresses with standard unix tools, gunzip and tar.


From drewc at tech.coop  Mon May 12 20:41:52 2008
From: drewc at tech.coop (Drew Crampsie)
Date: Mon, 12 May 2008 13:41:52 -0700
Subject: [Bese-devel] UCW doesn't accept latest parenscript version?
In-Reply-To: <4be8713d0805121158o63169a12o8e7d3292849dccaa@mail.gmail.com>
References: <4be8713d0805121158o63169a12o8e7d3292849dccaa@mail.gmail.com>
Message-ID: <bc10d2190805121341q56b12aa6rf2fea15941ffb1d4@mail.gmail.com>

Hey Gustavo,

2008/5/12 Gustavo <gugamilare at gmail.com>:
> Hello,
>
> I am trying to install UCW from the tutorial (without ucw-boxset) and it
> seems that ucw_dev (in file src/rerl/standard-dispatcher.lisp, line 229)
> tries to access the function js:compile-parenscript-file-to-string which is
> not defined in parenscript (neither unexported symbol). Am I doing something
> wrong? Should I get an older version of parenscript or expect this bug to be
> fixed?

I can't imagine that ucw_dev still works with libraries in the wild. I
know the boxset if probably broken as well. I'm in the process of
making some efforts to clean all this up, but it's completely broken
right now AFAIK.

The Paragent.com guys use _dev for their open source application. If
you download and install it following their easy instructions, you'll
also have a working ucw_dev (ish)!  If you want some help with this,
please don't bug paragent. #ucw or the list here should be fine... bug
me all you want :).

I've never actually done what i'm suggesting, so i could be crazy, but
i think it just might work(tm).

Cheers,

drewc
>
> Thanks,
> Gustavo
>
> _______________________________________________
>  bese-devel mailing list
>  bese-devel at common-lisp.net
>  http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel
>
>


From attila.lendvai at gmail.com  Mon May 12 20:42:56 2008
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Mon, 12 May 2008 22:42:56 +0200
Subject: [Bese-devel] UCW doesn't accept latest parenscript version?
In-Reply-To: <4828A633.3030507@acd.net>
References: <4be8713d0805121158o63169a12o8e7d3292849dccaa@mail.gmail.com>
	<4828A633.3030507@acd.net>
Message-ID: <b54b34af0805121342o72832757t3bc506c0fe02fb66@mail.gmail.com>

>  if you weren't able to get this fixed or find an old version,
>  i uploaded an old parenscript at http://www.mediafire.com/?gwrxzm9rz6v

once i spent an hour or so to port ucw to the new ps codebase, but it
wasn't enough and i gave up. iirc, since then some things have changed
that removed the unnecessary burden, but i'll do my js generation
using cl-quasi-quote (once i get to finish the js part). for now just
darcs get the ps from under the ucw umbrella:

http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi

-- 
 attila


From evrim at core.gen.tr  Wed May 14 10:40:40 2008
From: evrim at core.gen.tr (Evrim Ulu)
Date: Wed, 14 May 2008 13:40:40 +0300
Subject: [Bese-devel] possible javascript unsafeties
Message-ID: <482AC1A8.4010804@core.gen.tr>

Hi,

I've been working our lisp->javascript transformer. Could anybody 
enlighten me about why parenscript uses temporary variables while 
looping? What are the possible unsafe code blocks that would result an 
error ?


Thanks,
Evrim.


Form: (JS+ (DOLIST (L BLORG) (DOCUMENT.WRITE (+ "L is " L))))
Expected value: "{
  var tmpArr1 = blorg;
  for (var tmpI2 = 0; tmpI2 < tmpArr1.length;
    tmpI2 = tmpI2 + 1) {
    var l = tmpArr1[tmpI2];
    document.write('L is ' + l);
  };
}"
Actual value: "for (var l = 0; l < blorg.length; l = l + 1) {
document.write('L is ' + l);
}"


From evrim at core.gen.tr  Sat May 24 10:53:57 2008
From: evrim at core.gen.tr (Evrim Ulu)
Date: Sat, 24 May 2008 13:53:57 +0300
Subject: [Bese-devel] core-server homepage
Message-ID: <4837F3C5.70507@core.gen.tr>

Hi,

We started building a homepage for core-server including documentation.

http://labs.core.gen.tr/

More to come:)
Evrim.


From henrik at evahjelte.com  Sun May 25 07:11:03 2008
From: henrik at evahjelte.com (Henrik Hjelte)
Date: Sun, 25 May 2008 09:11:03 +0200
Subject: [Bese-devel] core-server homepage
In-Reply-To: <4837F3C5.70507@core.gen.tr>
References: <4837F3C5.70507@core.gen.tr>
Message-ID: <50e8e4f60805250011u4c973159oab858abf2b829ecd@mail.gmail.com>

The page looks really nice. I haven't used core-server, but I can see from the
technology overview that we do some things in a simliar way,
have mirrored objects that can have methods both in Lisp and in Parenscript.

And I tried the demo site of the CMS thing, it is a good solution
for someone that wants a simple web page that is really simple to edit.
Like small businesses. But then you need to make it really easy to buy it as
well. I wouldn't hide in the products section of core. It should have its own
webpage, and installing/starting/buying should be really easy as well.

Just some ideas,
/Henrik Hjelte

On Sat, May 24, 2008 at 12:53 PM, Evrim Ulu <evrim at core.gen.tr> wrote:
> Hi,
>
> We started building a homepage for core-server including documentation.
>
> http://labs.core.gen.tr/
>
> More to come:)
> Evrim.
> _______________________________________________
> bese-devel mailing list
> bese-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel
>
>



-- 
Henrik Hjelte
henrik.hjelte at stix.to
+46703993945
http://stix.to
L?stmakarg 18-20 (IQube)
Box 7438
S-103 91 Stockholm
Sweden


From sohail at taggedtype.net  Thu May 29 04:57:28 2008
From: sohail at taggedtype.net (Sohail Somani)
Date: Wed, 28 May 2008 21:57:28 -0700
Subject: [Bese-devel] Parenscript: "escaping" symbols
Message-ID: <g1ld3o$tvb$1@ger.gmane.org>

Hi,

Various JS libraries have funky naming conventions LikeTHIS. 
OrMaybeLIKETHIS.

Anyway, I was wondering if there was a no-fooling, no trial-and-error 
way to escape the symbols so that I can have:

(magic-happens-here "LikeTHIS" "foo")

translate to

LikeTHIS("foo")

Thanks a lot.

-- 
Sohail Somani
http://uint32t.blogspot.com



From henrik at evahjelte.com  Thu May 29 06:30:26 2008
From: henrik at evahjelte.com (Henrik Hjelte)
Date: Thu, 29 May 2008 08:30:26 +0200
Subject: [Bese-devel] Parenscript: "escaping" symbols
In-Reply-To: <g1ld3o$tvb$1@ger.gmane.org>
References: <g1ld3o$tvb$1@ger.gmane.org>
Message-ID: <50e8e4f60805282330t341412acq5e56abbda6ae3f3c@mail.gmail.com>

On Thu, May 29, 2008 at 6:57 AM, Sohail Somani <sohail at taggedtype.net> wrote:
> Hi,
>
> Various JS libraries have funky naming conventions LikeTHIS.
> OrMaybeLIKETHIS.
>
> Anyway, I was wondering if there was a no-fooling, no trial-and-error way to
> escape the symbols so that I can have:
>
> (magic-happens-here "LikeTHIS" "foo")

*like-t-h-i-s translates to LikeTHIS

-- 
Henrik Hjelte