From evrim at core.gen.tr  Tue Jan  2 20:45:51 2007
From: evrim at core.gen.tr (Evrim ULU)
Date: Tue, 02 Jan 2007 22:45:51 +0200
Subject: [Bese-devel] arnesi last 2 patches
Message-ID: <459AC47F.4050707@core.gen.tr>

Below two patches gives an error on my lisp machine. Am i missing
something? What is dwim btw?

evrim at evrim ~/lisp/arnesi_dev $ darcs unpull

Mon Dec 25 18:06:57 EET 2006  attila.lendvai at gmail.com
  * Specialize slime inspection of log categories, added [set level]
action with predefined minibuffer history
Shall I unpull this patch? (1/318)  [ynWvpxqadjk], or ? for help: y

Sun Dec 24 15:08:40 EET 2006  attila.lendvai at gmail.com
  * Added swank inspector dwim lookup hook for logger stuff (e.g. 'log
or 'log.debug)
Shall I unpull this patch? (2/318)  [ynWvpxqadjk], or ? for help: y

Tue Dec 19 19:17:54 EET 2006  attila.lendvai at gmail.com
  * Small fix for the slime-repl-log-appender
Shall I unpull this patch? (3/318)  [ynWvpxqadjk], or ? for help: ?
How to use unpull...
y: unpull this patch
n: don't unpull it
w: wait and decide later, defaulting to no

v: view this patch in full
p: view this patch in full with pager
x: view a summary of this patch

d: unpull selected patches, skipping all the remaining patches
a: unpull all the remaining patches
q: cancel unpull

j: skip to next patch
k: back up to previous patch
h or ?: show this help

<Space>: accept the current default (which is capitalized)

Tue Dec 19 19:17:54 EET 2006  attila.lendvai at gmail.com
  * Small fix for the slime-repl-log-appender
Shall I unpull this patch? (3/318)  [ynWvpxqadjk], or ? for help: d
Finished unpulling.



From attila.lendvai at gmail.com  Tue Jan  2 22:33:26 2007
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Tue, 2 Jan 2007 23:33:26 +0100
Subject: [Bese-devel] arnesi last 2 patches
In-Reply-To: <459AC47F.4050707@core.gen.tr>
References: <459AC47F.4050707@core.gen.tr>
Message-ID: <b54b34af0701021433h691bcc16rd6b0f115a77fe950@mail.gmail.com>

> Below two patches gives an error on my lisp machine. Am i missing
> something? What is dwim btw?

you need the latest slime for them to work. (although i payed some
attention to make them at least compile without the latest changes in
slime, but i may have missed something)

-- 
- attila

"- The truth is that I've been too considerate, and so became
unintentionally cruel...
 - I understand.
 - No, you don't understand! We don't speak the same language!"
(Ingmar Bergman - Smultronst?llet)

From evrim at core.gen.tr  Thu Jan  4 13:09:58 2007
From: evrim at core.gen.tr (Evrim ULU)
Date: Thu, 04 Jan 2007 15:09:58 +0200
Subject: [Bese-devel] presentations & ressurection
Message-ID: <459CFCA6.5090009@core.gen.tr>

Hi,

There is an interesting error while loading ucw-presentations. When I
require :ucw-presentations, swank/slime is killed unexpectedly
complaining about the slime two way stream. There are small errors in
presentations due to API change (widget-component.css-class) but i don't
think it's related to this. The problem persists in form.lisp. When i
compile

(define-ie-type (interface-element interface-element) ((ie-type t))
 ...)

slime dies. I've tried with sbcl1.0 & slime-cvs. Below lies the error
message, i can't debug fully since connection is aborted.


Any ideas?
evrim.

The stream
#<TWO-WAY-STREAM
  :INPUT-STREAM #<SWANK-BACKEND::SLIME-INPUT-STREAM {B6B1E91}>
  :OUTPUT-STREAM #<SWANK-BACKEND::SLIME-OUTPUT-STREAM {B611E39}>>
has no suitable method for OUTPUT-STREAM-P, and so has fallen through to
this
method.  If you think that this is a bug, please report it to the applicable
authority (bugs in SBCL itself should go to the mailing lists referenced
from
<http://www.sbcl.org/>).
   [Condition of type SIMPLE-ERROR]

Restarts:
  0: [TERMINATE-THREAD] Terminate this thread (#<THREAD
"auto-flush-thread" {B6B2631}>)

Backtrace:
  0: ((SB-PCL::FAST-METHOD OUTPUT-STREAM-P (STREAM)) #<unavailable
argument> #<unavailable argument> #<TWO-WAY-STREAM :INPUT-STREAM
#<SWANK-BACKEND::SLIME-INPUT-STREAM {B6B1E91}> :OUTPUT-STREAM
#<SWANK-BACKEND::SLIME-OUTPUT-STREAM {B611E39}>>)
  1: ((SB-PCL::FAST-METHOD OUTPUT-STREAM-P (STREAM)) #<unavailable
argument> #<unavailable argument> #<TWO-WAY-STREAM :INPUT-STREAM
#<SWANK-BACKEND::SLIME-INPUT-STREAM {B6B1E91}> :OUTPUT-STREAM
#<SWANK-BACKEND::SLIME-OUTPUT-STREAM {B611E39}>>)
  2: ((LAMBDA (SWANK-BACKEND::X)) #<TWO-WAY-STREAM :INPUT-STREAM
#<SWANK-BACKEND::SLIME-INPUT-STREAM {B6B1E91}> :OUTPUT-STREAM
#<SWANK-BACKEND::SLIME-OUTPUT-STREAM {B611E39}>>)
  3: (REMOVE-IF #<FUNCTION (LAMBDA #) {B9AE72D}> (#<TWO-WAY-STREAM
:INPUT-STREAM # :OUTPUT-STREAM #1=#> #1#))
  4: (SWANK-BACKEND::FLUSH-STREAMS)
  5: ((LAMBDA ()))
  6: ("foreign function: call_into_lisp")
  7: ("foreign function: funcall0")
  8: ("foreign function: new_thread_trampoline")
  9: ("foreign function: #xB7FC461B")


From evrim at core.gen.tr  Thu Jan  4 13:17:27 2007
From: evrim at core.gen.tr (Evrim ULU)
Date: Thu, 04 Jan 2007 15:17:27 +0200
Subject: [Bese-devel] presentations & ressurection
In-Reply-To: <459CFCA6.5090009@core.gen.tr>
References: <459CFCA6.5090009@core.gen.tr>
Message-ID: <459CFE67.8030009@core.gen.tr>

Btw, the error message is thrown by the swank auto flush thread, i've
double checked the auto-flush-streams list and see if i can call
(output-stream-p bogus-two-way-stream) and it returned t without a problem.

evrim.


From attila.lendvai at gmail.com  Thu Jan  4 14:56:26 2007
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Thu, 4 Jan 2007 15:56:26 +0100
Subject: [Bese-devel] (no subject)
In-Reply-To: <Pine.GSO.4.58L0.0612271105580.25889@balu.sch.bme.hu>
References: <Pine.GSO.4.58L0.0612271105580.25889@balu.sch.bme.hu>
Message-ID: <b54b34af0701040656u2cf66a2akfa62fdb550e37e1d@mail.gmail.com>

> I have spent a little time on making the sharpl support more "correct" in
> arnesi. Unfortunately, the patch is really intrusive since I had to modify
> the code walker to make it work correctly -- basically, the code walker
> called macro functions in the null lexical environment, and that made it
> impossible for the #l reader to work in some more convoluted cases, so I
> had to fix it. This should benefit call/cc too by making it work in more
> cases.

fyi, i've applied this locally and stuff seems to keep on working, but
i'd better leave the pushing of this for someone with more experience
with the walker...

but if nothing happens for long enough i'll push it eventually,
because it looks good for my uneducated eyes.

-- 
- attila

"- The truth is that I've been too considerate, and so became
unintentionally cruel...
 - I understand.
 - No, you don't understand! We don't speak the same language!"
(Ingmar Bergman - Smultronst?llet)

From kilian.sprotte at googlemail.com  Sun Jan  7 04:35:23 2007
From: kilian.sprotte at googlemail.com (Kilian Sprotte)
Date: Sun, 7 Jan 2007 05:35:23 +0100
Subject: [Bese-devel] arnesi's swank dependency
Message-ID: <1d26dc7e0701062035q45d4e56ftcc617de1ead4cd89@mail.gmail.com>

Hi,

I am currently having a problem with arnesi's new requirement of swank.
First of all this is my own fault, cause my slightly extended slime
version was actually depending an arnesi.....

But on the other hand, if you do M-x slime, swank will be loaded by
swank-loader.lisp, so loading arnesi after this will reload
everything, cause the system swank had not been loaded yet.

Finally, what do you think about separating those logging facilities
that depend on swank and only load them, if swank is already present?

Hope that makes sense,
bye,

  Kilian


From attila.lendvai at gmail.com  Sun Jan  7 09:12:11 2007
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Sun, 7 Jan 2007 10:12:11 +0100
Subject: [Bese-devel] arnesi's swank dependency
In-Reply-To: <1d26dc7e0701062035q45d4e56ftcc617de1ead4cd89@mail.gmail.com>
References: <1d26dc7e0701062035q45d4e56ftcc617de1ead4cd89@mail.gmail.com>
Message-ID: <b54b34af0701070112o43e3c8eft799b37d5c2cbf0d3@mail.gmail.com>

> But on the other hand, if you do M-x slime, swank will be loaded by
> swank-loader.lisp, so loading arnesi after this will reload
> everything, cause the system swank had not been loaded yet.

this was causing us headaches, too before we used core files and
unconditionally loaded swank.

either swank-loader.lisp should be guarded for reloads, or
slime-init-command should be smarter in slime.el.

> Finally, what do you think about separating those logging facilities
> that depend on swank and only load them, if swank is already present?

i think it's long due to cut arnesi into at least the following modules:
 - logging
 - walker and call/cc
 - rest

but how should they be called? and it's Marco who has the final word
on this, anyway, so i don't want to speak on my own in this.

about the swank dependency:
 - either load swank always and uncoditionally and forget the problem
(but you have inter-dependency...)
 - or just delete/unpull the slime logging stuff from your local repo
 - or we could use asdf-system-connections
 - or we could #+#.(cl:find-package "SWANK") and delete the swank
dependency from the .asd

1 works for me, but neither of them is such a good solution for you.
on the short term i would do 2 if i were you.

-- 
- attila

"- The truth is that I've been too considerate, and so became
unintentionally cruel...
 - I understand.
 - No, you don't understand! We don't speak the same language!"
(Ingmar Bergman - Smultronst?llet)

From kilian.sprotte at googlemail.com  Sun Jan  7 12:37:39 2007
From: kilian.sprotte at googlemail.com (Kilian Sprotte)
Date: Sun, 7 Jan 2007 13:37:39 +0100
Subject: [Bese-devel] arnesi's swank dependency
In-Reply-To: <b54b34af0701070112o43e3c8eft799b37d5c2cbf0d3@mail.gmail.com>
References: <1d26dc7e0701062035q45d4e56ftcc617de1ead4cd89@mail.gmail.com>
	<b54b34af0701070112o43e3c8eft799b37d5c2cbf0d3@mail.gmail.com>
Message-ID: <1d26dc7e0701070437p7bdd6682mf7d65e5f8ba94a58@mail.gmail.com>

Hi,

thanks a lot for your reply!

>  - or we could #+#.(cl:find-package "SWANK") and delete the swank
> dependency from the .asd

For the time being, this is working for me.
IMHO I second cutting arnesi into modules, though.

Cheers,
  Kilian


From gwking at metabang.com  Sun Jan  7 13:47:54 2007
From: gwking at metabang.com (Gary King)
Date: Sun, 7 Jan 2007 08:47:54 -0500
Subject: [Bese-devel] arnesi's swank dependency
In-Reply-To: <1d26dc7e0701062035q45d4e56ftcc617de1ead4cd89@mail.gmail.com>
References: <1d26dc7e0701062035q45d4e56ftcc617de1ead4cd89@mail.gmail.com>
Message-ID: <650EEC4B-C0E7-4F2A-8E9C-AEC04F6E80F7@metabang.com>

For what it's worth, ASDF-System-Connections might help in this  
regard...

On Jan 6, 2007, at 11:35 PM, Kilian Sprotte wrote:

> Finally, what do you think about separating those logging facilities
> that depend on swank and only load them, if swank is already present?

--
Gary Warren King, metabang.com
Cell: (413) 885 9127
Fax: (206) 338-4052
gwkkwg on Skype * garethsan on AIM






From evrim at core.gen.tr  Sun Jan  7 14:35:21 2007
From: evrim at core.gen.tr (Evrim ULU)
Date: Sun, 07 Jan 2007 16:35:21 +0200
Subject: [Bese-devel] ucw frames
Message-ID: <45A10529.5010809@core.gen.tr>

Hi,

What would happen if frame values are ordered 1,2,3.. instead of hash
values?

Thanks,
Evrim.




From mbaringer at common-lisp.net  Mon Jan  8 05:00:16 2007
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Mon,  8 Jan 2007 00:00:16 -0500 (EST)
Subject: [Bese-devel] New patches to arnesi_dev:  7-Jan-2007
Message-ID: <20070108050016.30A605F01A@common-lisp.net>


Sun Jan  7 14:38:46 EST 2007  attila.lendvai at gmail.com
  * test-op is never done

    M ./arnesi.asd +3

Sun Jan  7 14:37:36 EST 2007  attila.lendvai at gmail.com
  * FIX: unescape-as-uri (of + -> space) broke in my previous patch. fix and add test case.

    M ./src/http.lisp -4 +3
    M ./t/http.lisp -1 +4


An updated tarball of arnesi_dev's source can be downloaded here:
http://common-lisp.net/project/bese/tarballs/arnesi_dev-20070107.tar.gz

Darcsweb URL:
http://uncommon-web.com/darcsweb/darcsweb.cgi?r=arnesi_dev;a=summary


From mbaringer at common-lisp.net  Wed Jan 10 05:05:03 2007
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Wed, 10 Jan 2007 00:05:03 -0500 (EST)
Subject: [Bese-devel] New patches to fiveam:  9-Jan-2007
Message-ID: <20070110050503.CDB9717045@common-lisp.net>


Tue Jan  9 09:55:26 EST 2007  Marco Baringer <mb at bese.it>
  * Export results-status

    M ./src/packages.lisp -1 +2


An updated tarball of fiveam's source can be downloaded here:
http://common-lisp.net/project/bese/tarballs/fiveam-20070109.tar.gz

Darcsweb URL:
http://uncommon-web.com/darcsweb/darcsweb.cgi?r=fiveam;a=summary


From lists at infoway.net  Mon Jan 15 21:14:30 2007
From: lists at infoway.net (lists at infoway.net)
Date: Mon, 15 Jan 2007 16:14:30 -0500 (EST)
Subject: [Bese-devel] Learning UCW
Message-ID: <58272.192.168.1.71.1168895670.webmail@192.168.1.71>

Hello again,

Well, after some going back-and-forth and with the help of the members of this list, I finally seem to have a stable UCW environment under OS X with SBCL.

I have been fiddling around trying to learn UCW. However, to be honest, I'm disappointed at the lack of documentation and/or the steep learning curve required to get going with it, so I'm back here asking for help/direction.

I originally started looking at many public tutorials. However, they are all obsolete and don't even run in the current version of UCW, so I wouldn't want to spend too much time learning something that has been deprecated or that simply won't work.

I then started going through the example applications. They seem to illustrate more functionality than any of the tutorials I found. However, there is a severe lack of "explanation" bundled with the examples.

Then I went to http://uncommon-web.com/qbook/ucw_dev/ but there is also a lack of explanation/description of many of the methods and the overall "ucw development methodology".

The one thing I _think_ learned from all this is, I believe I understand the concepts around the different basic components that make up a simple application.

However, since the only running sample code I have is that found in the examples, that's the one thing I end up reviewing the most. I spent a lot of time going through UCW's source code documentation as I read the example code. Some of it makes sense, some is not so well documented.

Then, there is the notion that I see the examples make extensive use of package::function within the ucw package. If even the examples make such use of this, why aren't all these functions publicly exported so they may be formally documented?

You can say that I'm a new Lisper and, so far, seem somewhat comfortable with the "hacking" mentality that I could always go to the source to understand how things work. However, even doing so is extremely difficult in UCW because not everything has comments and having to understand code makes it that much more difficult when you don't really know where to look, so I end up looking at one file and then have to look through n files until a simple concept may be cleared up.

UCW seems to have a somewhat active community, so I ask for anyone to provide more concise direction as to how you would "welcome" a newbie into the UCW world. I don't mean any negative criticism in this email, if anything, I just hope it's for the best so more people can join this community.

I'm really eager and want to start doing something productive here, but I really feel my hands are tight in learning the available API and overall UCW development mindset.

I know there are many out there listening, just hope someone is able to respond promptly :)

Thanks again,
Daniel



From mbaringer at common-lisp.net  Tue Jan 16 05:20:05 2007
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Tue, 16 Jan 2007 00:20:05 -0500 (EST)
Subject: [Bese-devel] New patches to parenscript: 15-Jan-2007
Message-ID: <20070116052005.7B03A3800D@common-lisp.net>


Mon Jan 15 09:19:48 EST 2007  Henrik Hjelte <henrik at evahjelte.com>
  * conditional attributes in html-generator

    M ./docs/manual.pdf
    M ./docs/reference.lisp +17
    M ./src/js-html.lisp -28 +43


An updated tarball of parenscript's source can be downloaded here:
http://common-lisp.net/project/ucw/tarballs/parenscript-20070115.tar.gz

Darcsweb URL:
http://uncommon-web.com/darcsweb/darcsweb.cgi?r=parenscript;a=summary


From reddaly at gmail.com  Tue Jan 16 10:58:55 2007
From: reddaly at gmail.com (Red Daly)
Date: Tue, 16 Jan 2007 02:58:55 -0800
Subject: [Bese-devel] Advancing Parenscript - current and future improvements
Message-ID: <45ACAFEF.3070802@gmail.com>

I am not an Uncommon Web user, but I have been using Parenscript heavily 
for a few months.  Hopefully this list will be interested in the 
improvements to Parenscript I have made and has suggestions to 
outstanding issues in Parenscript development.

I have a pretty stable implementation of a CLOS-like metaobject system 
in Parenscript called the Parenscript Object System.  There is currently 
support for generic functions and class inheritance.  It also has some 
cool (beta) features, like importing a CLOS class and sending instances 
of that class across the net as a JSON object.  There are also things 
that I haven't figured out how to do best, like slot definitions.  See 
http://scratchpad.wikia.com/wiki/Parenscript_Object_System for more details.

The standard Javascript function definition is fairly bland, so I also 
implemented lisp's function declaration syntax.  Keyword arguments, 
defaulting parameters, and &rest arguments all expand to proper 
Javascript function definitions.  Parenscript function definitions are 
indistinguishable from their Lisp counterparts, since the code to parse 
the paren-lambda lists is ripped from SBCL.

Now, there are a few problems that I would like to solve with the 
assistance of interested parties :).

There is still no clear solution for packaging code into modules in 
Javascript. This roughtly breaks down into two classes of problems: 
namespace problems and packaging problems.

Namespace issues
Namespace problems are those related to name conflicts in the Javascript 
environment. Currently developers work around this by introducing simple 
objects that serve as Java-esque prefixes: dojo.widgets.bloated, 
Ajax.Request, etc. Using prefixes is a good idea, but importing a 
package's "symbols" is sort of awkward. For example, a way to import 
everying from the dojo package is this:

for (var dojoSym in dojo)
   window[dojoSym] = dojo[dojoSym];

However, once those symbols are imported, they are imported into the 
global scope where they may conflict.

Does with(dojo) solve this problem at all?  I remember reading that 
with() is evil for performance and other reasons--it doesn't do what you 
think.

I would like to come up with a more elegant solution for namespacing 
Parenscript code.  Ideally there could be (defpackage) and (in-package) 
forms hide the dirty object declarations and such from a Parenscript 
user.  Ideas??

Packaging issues

Right now there is no consistent packaging strategy for Javascript code. 
In most cases, developers wishing to use the latest and greatest will 
download a project, add it to their own source tree, and then follow 
special instructions about how to actually include the scripts in their 
web sites. This works O.K. most of the time, but it is indeed not the 
smartest system.

Parenscript should probably take advantage of Lisp's Another System 
Definition Facility (ASDF) to define packages. I have not worked out the 
details of how to define Parenscript systems yet. It should be easy to 
(1) install somebody else's parenscript package (via an asdf:load-op) 
and (2) include individual Parenscript components in web pages.

Packaging issues are not as important as namespace issues to me, since a 
large packaging system doesn't matter if there are name conflicts 
everywhere.

Thanks for listening.  I hope this message reaches the right people!

Sincerely,
Red Daly





From henrik at evahjelte.com  Tue Jan 16 18:23:50 2007
From: henrik at evahjelte.com (Henrik Hjelte)
Date: Tue, 16 Jan 2007 19:23:50 +0100
Subject: [Bese-devel] Learning UCW
In-Reply-To: <58272.192.168.1.71.1168895670.webmail@192.168.1.71>
References: <58272.192.168.1.71.1168895670.webmail@192.168.1.71>
Message-ID: <1168971830.19299.111.camel@trinidad>

On Mon, 2007-01-15 at 16:14 -0500, lists at infoway.net wrote:
> Hello again,
> 
> Well, after some going back-and-forth and with the help of the members of this list,
> I finally seem to have a stable UCW environment under OS X with SBCL.
> 
> I have been fiddling around trying to learn UCW. However, to be honest, 
> 'm disappointed at the lack of documentation and/or the steep learning
>  curve required to get going with it, so I'm back here asking for help/direction.
> 
You shouldn't be disappointed with the steep learning curve. If it was
simple and obvious you would learn nothing. I believe it is called
uncommon for a reason. If you think that you will fire up UncommonWeb
fast and easy without knowing much Lisp and expect to understand
everything in a month I think you have set your ambitions way too high.

For me learning UnCommonWeb and relearning Lisp has made me much humbler
as a programmer. I now understand that I don't know everything. I find
it refreshing to learn every day. 

> I originally started looking at many public tutorials. However, they 
> are all obsolete and don't even run in the current version of UCW, 
> so I wouldn't want to spend too much time learning something
>  that has been deprecated or that simply won't work.

If you check the number of authors mailing list you can probably guess
how large this community is. We could probably fit into an old
Volkswagen. Definitely in my Saab. So any help is appreciated, for
example in maintaining and updating the documentation there is. 

And again, you will need to spend much time learning, and things will
not always work. But things will get much better when you learn how to
get around fast in the source code with slime, how to use the debugger
and so on.

> I then started going through the example applications. They seem to 
> illustrate more functionality than any of the tutorials I found. 
> However, there is a severe lack of "explanation" bundled with the examples.

The examples and code can be documented better. Sometimes what is
obvious to the author is not obvious to everybody else, but then please
join in and improve the documentation. For example by writing down your
questions somewhere.


> I spent a lot of time going through UCW's source code documentation as 
> I read the example code. Some of it makes sense, some is not so well documented.
I think the code is documented at about the right level. You have seen
the problems with documentation, it sometimes gets obsolete. Then you
have to figure out if it is the code or documentation that is wrong. 
But maybe some areas need improvement, there are always things I don't
understand immediately when I navigate through the code. But I don't
think that more documentation in the code itself, would help me much. I
rather think that more high-level documentation would be good.

I prefer pedagogical testcases to documentation, then you can see in the
testcode how things work. 
> 
> Then, there is the notion that I see the examples make extensive 
> use of package::function within the ucw package. 
> If even the examples make such use of this, why aren't all these functions
>  publicly exported so they may be formally documented?
Probably because someone forgot or didn't bother. You only need to make
change it, darcs record, darcs send -o mypatch and send it to the
mailing list. 

> 
> You can say that I'm a new Lisper and, so far, seem somewhat comfortable
>  with the "hacking" mentality that I could always go to the source
>  to understand how things work.
Most of us are beginners. Most of us don't always understand things.

>  However, even doing so is extremely difficult in UCW because not everything
>  has comments and having to understand code makes it that much more difficult
>  when you don't really know where to look, so I end up looking at one file 
> and then have to look through n files until a simple concept may be cleared up.
If functions, methods and parameters are named properly there shouldn't
be a need for lots of comments. Understanding code is sometimes
difficult. Sometimes you get frustrated.

> UCW seems to have a somewhat active community, so I ask for anyone to 
> provide more concise direction as to how you would "welcome" a newbie into the UCW world. 
I think we answer most answerable questions prompt and fast. We answer
emails. Marco has made an instruction video. The boxset was a step to
make uncommonweb easier to start with.

> I don't mean any negative criticism in this email, if anything, 
> I just hope it's for the best so more people can join this community.
Me neither, and I sincerely hope more people join. I am no spokesperson
for this community, but I think we all agree with this.

> I'm really eager and want to start doing something productive here, 
> but I really feel my hands are tight in learning the available API 
> and overall UCW development mindset.
As said, there are many things to do and we are a little community. You
don't have to know much to start updating the documentation and pointing
out problems. 

Here are some random ideas, suitable for all levels of Lisp expertise.
You don't even have to know lisp. 
* Do tests for the example application using selenium
* Remove obsolete bits in the parenscript documentation
* Write a todo-list of documentation that need updating.
* Update the documentation. 
* Do some kind of script that automatically tests uncommonweb and its
dependencies. I looked at the python buildbot today, it can be used.

> I know there are many out there listening, just hope someone is able to respond promptly :)
> 
> Thanks again,
> Daniel

I hope you stay with UnCommonWeb! I think that most of the problems you
have come from a small community, and having too high expectations on
learning everything fast.

/Henrik Hjelte




From henrik at evahjelte.com  Tue Jan 16 19:49:52 2007
From: henrik at evahjelte.com (Henrik Hjelte)
Date: Tue, 16 Jan 2007 20:49:52 +0100
Subject: [Bese-devel] Advancing Parenscript - current and future
	improvements
In-Reply-To: <45ACAFEF.3070802@gmail.com>
References: <45ACAFEF.3070802@gmail.com>
Message-ID: <1168976992.19299.187.camel@trinidad>

On Tue, 2007-01-16 at 02:58 -0800, Red Daly wrote:

> I have a pretty stable implementation of a CLOS-like metaobject system 
> in Parenscript called the Parenscript Object System.  There is currently 
> support for generic functions and class inheritance.  
Looks great! I have to check this out soon..

> It also has some 
> cool (beta) features, like importing a CLOS class and sending instances 
> of that class across the net as a JSON object.  
FYI: If you use cl-json on the server, there are some updates in the
darcs repo compared to the release version.

> There are also things 
> that I haven't figured out how to do best, like slot definitions.  See 
> http://scratchpad.wikia.com/wiki/Parenscript_Object_System for more details.
> 
> The standard Javascript function definition is fairly bland, so I also 
> implemented lisp's function declaration syntax.  Keyword arguments, 
> defaulting parameters, and &rest arguments all expand to proper 
> Javascript function definitions.  Parenscript function definitions are 
> indistinguishable from their Lisp counterparts, since the code to parse 
> the paren-lambda lists is ripped from SBCL.
> 
> Now, there are a few problems that I would like to solve with the 
> assistance of interested parties :).
> 
> There is still no clear solution for packaging code into modules in 
> Javascript. This roughtly breaks down into two classes of problems: 
> namespace problems and packaging problems.
> 
> Namespace issues
> Namespace problems are those related to name conflicts in the Javascript 
> environment. Currently developers work around this by introducing simple 
> objects that serve as Java-esque prefixes: dojo.widgets.bloated, 
> Ajax.Request, etc. Using prefixes is a good idea, but importing a 
> package's "symbols" is sort of awkward. For example, a way to import 
> everying from the dojo package is this:
> 
> for (var dojoSym in dojo)
>    window[dojoSym] = dojo[dojoSym];
> 
> However, once those symbols are imported, they are imported into the 
> global scope where they may conflict.
> 
> Does with(dojo) solve this problem at all?  I remember reading that 
> with() is evil for performance and other reasons--it doesn't do what you 
> think.
I don't think with is a good idea for the reasons you mention. 

> I would like to come up with a more elegant solution for namespacing 
> Parenscript code.  Ideally there could be (defpackage) and (in-package) 
> forms hide the dirty object declarations and such from a Parenscript 
> user.  Ideas??

Since the javascript is generated, there is no reason why this:
myLibrary.myFunction();

couldn't look like this in parenscript:

(in-package :my-library)
(my-function)

Anything could be generated, myLibrary_myFunction or
x345657as_myFunction if you want to avoid all name collisions. Some
people care how the generated code looks, I don't very much.

What I have thinked about and would very much like is that parenscript
knew about dependencies and kept track of them. The idea is that you
shouldn't need to include lots of large javascript files even though you
only need one or two functions in a library. For the example above, when
parenscript should generates code for (my-function), it would look in
the package :my-library to see if there was a function definition for
my-function there. If not it would look at the imports in my-library.
Finally we could have "external" javascript definitions, for example the
core javascript functions or the "window" global scoped functions (or
objects). If there was no definition reachable for my-function
parenscript would show a Warning. All typo errors would disappear! You
could also warn about missing arguments and other things, and perhaps do
optimizations.

For those of us that care about performance and bandwidth,
a great thing could be that you could compile a .js file that included
exactly all functions you need and no more, in one file. 

In common-lisp code:
(with-js-environments (core-javascript window-object dojo-library)
   (generate-all 
     `((in-package :my-library)
       (my-function))))
would return something like:
"
function myLibrary_myFunction () {
  alert("hello");
};
myLibrary_MyFunction();
"

This would mean a lot of changes to parenscript. But it shouldn't be
that difficult should it?

One could also consider to start over again from the start with a new
project. The parenscript code has it's quirks that I'm not particular
found of, code such as dwim-join-strings.


> Packaging issues
> 
> Right now there is no consistent packaging strategy for Javascript code. 
> In most cases, developers wishing to use the latest and greatest will 
> download a project, add it to their own source tree, and then follow 
> special instructions about how to actually include the scripts in their 
> web sites. This works O.K. most of the time, but it is indeed not the 
> smartest system.
> 
> Parenscript should probably take advantage of Lisp's Another System 
> Definition Facility (ASDF) to define packages. I have not worked out the 
> details of how to define Parenscript systems yet. 
Parenscript and client-side web-applications (the main target for
javascript) are different from Lisp. I don't think you can just take
ASDF and put it in parenscript. I think one need to ask what exactly is
needed for a javascript environment. But something similar to asdf
syntax-wise would be nice. 

> Packaging issues are not as important as namespace issues to me, since a 
> large packaging system doesn't matter if there are name conflicts 
> everywhere.
I agree that packaging issues are of less importance (at least until
there are any packages to get). But it is not name conflicts that I'm
afraid of, it is loading and initializing all these files on the client.
Including dojo is not nice! I need a mapcar function and what do I get,
20 files and three seconds load time. Whereas in my dream solution I
would only get the little mapcar function from somewhere in my server
side library at compile time, then saved to a little page-specific js
file.

> 
> Thanks for listening.  I hope this message reaches the right people!
> Sincerely,
> Red Daly

And thank you! clos in javascript is way cool.

I'm interested in contributing to evolving parenscript. This mailing
list isn't that crowded, so it is a good place to discuss on isn't it?

Best wishes,
Henrik Hjelte







From lists at infoway.net  Tue Jan 16 22:15:08 2007
From: lists at infoway.net (lists at infoway.net)
Date: Tue, 16 Jan 2007 17:15:08 -0500 (EST)
Subject: [Bese-devel] Learning UCW
Message-ID: <39983.192.168.1.71.1168985708.webmail@192.168.1.71>

Henrik,

Thanks for your reply. In order to keep the email "short", I am just going to address some of the things you mentioned without necessarily quoting you.

Anyway, I don't expect everything to be served in a silver platter. If that was the case, I would just stay with Ruby on Rails. I have been learning Lisp for several months and still consider myself a newbie. However, the only reasons I decided to learn Lisp was because of the reason everyone should learn Lisp :), and because of UCW. I think it seems like a fantastic framework and wish I could just speed up time so I become more proficient with it. So, to go straight to the point, I will stick around for as long as it takes or until you guys kick me out for "asking too many questions" :)

Now, as far as code documentation, I don't mean comments for "every line of code", but may be better high-level package/file/function/macro comments. There are many functions that don't have comments at all, so I assume they must be helper functions, but then I see them being used in the examples as "API-like" functions. Then your comment that maybe someone forgot to export a symbol makes it more difficult to understand whether something was really meant to be private or not, and if so, why is it being used in the examples, or if not, why is it not documented.

I don't mind contributing as I move along and decipher what's going on, but having said the above, makes it harder for me to know the real author's intentions.

The other problem is that, it could be that UCW may not be too hard to grasp. However, because it uses so many other libraries (as core, in the examples, and I would assume in production code as well) that I then have to learn these other libraries, which some of them are at the same or worse level of documentation.

I will try to follow your advise as much as possible and contribute as much as possible as well. I just hope I go in the right direction without confusing things more than they need to, given the circumstances.

Thanks again,
Daniel

On Tue, January 16, 2007 1:23 pm, Henrik Hjelte <henrik at evahjelte.com> said:
>
> snip...
> 
> I hope you stay with UnCommonWeb! I think that most of the problems you
> have come from a small community, and having too high expectations on
> learning everything fast.
> 
> /Henrik Hjelte
> 
> 
> 



From reddaly at gmail.com  Tue Jan 16 23:52:43 2007
From: reddaly at gmail.com (Red Daly)
Date: Tue, 16 Jan 2007 15:52:43 -0800
Subject: [Bese-devel] Advancing Parenscript - current and
	future	improvements
In-Reply-To: <1168976992.19299.187.camel@trinidad>
References: <45ACAFEF.3070802@gmail.com> <1168976992.19299.187.camel@trinidad>
Message-ID: <45AD654B.7080409@gmail.com>

Henrik Hjelte wrote:
>> It also has some 
>> cool (beta) features, like importing a CLOS class and sending instances 
>> of that class across the net as a JSON object.  
>>     
> FYI: If you use cl-json on the server, there are some updates in the
> darcs repo compared to the release version.
>
>   
Thanks, I'll update my cl-json when I have a chance.  I actually lied, 
though, when I said it generates strict JSON.  It actually generates a 
modified JSON that has support for typing and cross-references (though 
not circular references yet).
>> I would like to come up with a more elegant solution for namespacing 
>> Parenscript code.  Ideally there could be (defpackage) and (in-package) 
>> forms hide the dirty object declarations and such from a Parenscript 
>> user.  Ideas??
>>     
>
> Since the javascript is generated, there is no reason why this:
> myLibrary.myFunction();
>
> couldn't look like this in parenscript:
>
> (in-package :my-library)
> (my-function)
>   
I agree.  Most of the legwork should be done when Parenscript is 
translated to Javascript.
> Anything could be generated, myLibrary_myFunction or
> x345657as_myFunction if you want to avoid all name collisions. Some
> people care how the generated code looks, I don't very much.
>   
It would be ideal to generate code that is readable so that 
non-Parenscript users could use libraries written in Parenscript.  Using 
dot-delimited package qualifiers would be a decent convention.
> What I have thinked about and would very much like is that parenscript
> knew about dependencies and kept track of them. The idea is that you
> shouldn't need to include lots of large javascript files even though you
> only need one or two functions in a library. For the example above, when
> parenscript should generates code for (my-function), it would look in
> the package :my-library to see if there was a function definition for
> my-function there. If not it would look at the imports in my-library.
> Finally we could have "external" javascript definitions, for example the
> core javascript functions or the "window" global scoped functions (or
> objects). If there was no definition reachable for my-function
> parenscript would show a Warning. All typo errors would disappear! You
> could also warn about missing arguments and other things, and perhaps do
> optimizations.
> For those of us that care about performance and bandwidth,
> a great thing could be that you could compile a .js file that included
> exactly all functions you need and no more, in one file. 
>
> In common-lisp code:
> (with-js-environments (core-javascript window-object dojo-library)
>    (generate-all 
>      `((in-package :my-library)
>        (my-function))))
> would return something like:
> "
> function myLibrary_myFunction () {
>   alert("hello");
> };
> myLibrary_MyFunction();
> "
>   
This sounds like a good route to me, though figuring out dependencies 
might be tricky.  Deciding what to consider as part of the package could 
be accomplished through defined semantics.  defun, defconstant, 
defclass, ... and some other forms could define exportable parts of a 
package.  However, making sense of parenscript symbols seems more 
difficult.  For example,

(defpackage cow)
(in-package :cow)

(defun moo () (alert "global moooo")) ; defines function, moo, that is 
registered as a symbol of cow

(moo) ; should

(defun main ()
    (let ((moo (lambda () (alert "correct mooo")))) ; this is a local moo
       ; this should alert "correct mooo"
       ; it should not expand to cow.moo(), but just moo()
       (moo)))

Some level of program analysis seems necessary to determine the scope

I have not thought this through, though.  First I would like to figure out

> This would mean a lot of changes to parenscript. But it shouldn't be
> that difficult should it?
>
> One could also consider to start over again from the start with a new
> project. The parenscript code has it's quirks that I'm not particular
> found of, code such as dwim-join-strings.
>   
Overhauling Parenscript sounds fine.  If we decide to make drastic 
changes, it sounds reasonable to fork the project.  I am not intimately 
familiar with its innards right now, though I have noticed while working 
that the library isn't perfect.   It would be ideal in a fresh 
implementation to expose more of the compiler, since it seems that 
optimization and parenscript interpretation are important facets of this 
packaging system.
>
>   
>> Packaging issues
>>
>> Right now there is no consistent packaging strategy for Javascript code. 
>> In most cases, developers wishing to use the latest and greatest will 
>> download a project, add it to their own source tree, and then follow 
>> special instructions about how to actually include the scripts in their 
>> web sites. This works O.K. most of the time, but it is indeed not the 
>> smartest system.
>>
>> Parenscript should probably take advantage of Lisp's Another System 
>> Definition Facility (ASDF) to define packages. I have not worked out the 
>> details of how to define Parenscript systems yet. 
>>     
> Parenscript and client-side web-applications (the main target for
> javascript) are different from Lisp. I don't think you can just take
> ASDF and put it in parenscript. I think one need to ask what exactly is
> needed for a javascript environment. But something similar to asdf
> syntax-wise would be nice.
>   
What I meant is that parenscript project ASD files will contain a lisp 
source component and a parenscript source component.  The parenscript 
compiler then knows how to locate certain parenscript files within a 
parenscript project.  Say the "dom-util.paren" file in the 
"bobs-paren-utilities-system" package..

(defsystem bobs-paren
    (:components ((:module "lisp-src"
                                  (:file "bobs-paren-macros"))
                             (:module "paren-src" :depends-on ("lisp-src")
                                   (:paren-file "general-util"
                                   (:paren-file "dom-util" :depends-on 
("general-util"))))))
(defsystem reds-paren
    (:components ((:module "paren-src"
                                  (:paren-file "main-site" :depends-on 
("bobs-paren/dom-util"))))))

This isn't refined, but you can see how ASDF could be adequate for 
defining Parenscript systems.

>   
>> Packaging issues are not as important as namespace issues to me, since a 
>> large packaging system doesn't matter if there are name conflicts 
>> everywhere.
>>     
> I agree that packaging issues are of less importance (at least until
> there are any packages to get). But it is not name conflicts that I'm
> afraid of, it is loading and initializing all these files on the client.
> Including dojo is not nice! I need a mapcar function and what do I get,
> 20 files and three seconds load time. Whereas in my dream solution I
> would only get the little mapcar function from somewhere in my server
> side library at compile time, then saved to a little page-specific js
> file.
>   
With the compiler enhancements you talked about, an ASD file could 
delineate general project dependencies, and very specific package 
requirements could be determined.  This way, we can avoid 
over-inclusion.  A less full-blown solution is for ASD descriptions of a 
Parenscript file can include more than package-level dependency 
information (a la :depends-on ("bobs-paren/dom-util")).

> And thank you! clos in javascript is way cool.
>
> I'm interested in contributing to evolving parenscript. This mailing
> list isn't that crowded, so it is a good place to discuss on isn't it?
>
> Best wishes,
> Henrik Hjelte
>
>   
Sounds good. Thanks for your interest,
Red Daly








From mbaringer at common-lisp.net  Wed Jan 17 05:30:17 2007
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Wed, 17 Jan 2007 00:30:17 -0500 (EST)
Subject: [Bese-devel] New patches to ucw_dev: 16-Jan-2007
Message-ID: <20070117053017.CBC1B7D1A5@common-lisp.net>


Tue Jan 16 07:44:40 EST 2007  evrim at core.gen.tr
  * print-object for url-matcher, standard-disaptchers function for ease of use.

    M ./src/rerl/standard-classes.lisp -9 +1
    M ./src/rerl/standard-dispatcher.lisp -4 +17


An updated tarball of ucw_dev's source can be downloaded here:
http://common-lisp.net/project/ucw/tarballs/ucw_dev-20070116.tar.gz

Darcsweb URL:
http://uncommon-web.com/darcsweb/darcsweb.cgi?r=ucw_dev;a=summary


From marijnh at gmail.com  Wed Jan 17 08:43:34 2007
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Wed, 17 Jan 2007 09:43:34 +0100
Subject: [Bese-devel] Advancing Parenscript - current and future
	improvements
In-Reply-To: <45AD654B.7080409@gmail.com>
References: <45ACAFEF.3070802@gmail.com> <1168976992.19299.187.camel@trinidad>
	<45AD654B.7080409@gmail.com>
Message-ID: <befaa7aa0701170043i1868f7beh954ca46ae0157144@mail.gmail.com>

Neat ideas, but wouldn't they be much better implemented as separate
libraries that depend on parenscript? Parenscript just does plain lisp to
javascript compilation, and I think that's a nice, well-defined role for a
library.

Regards,
Marijn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20070117/91f3e459/attachment.html>

From vagif at cox.net  Thu Jan 18 00:49:01 2007
From: vagif at cox.net (Vagif Verdi)
Date: Wed, 17 Jan 2007 16:49:01 -0800
Subject: [Bese-devel] Error on Lispworks on windows
Message-ID: <20070118004901.OCUS25875.fed1rmmtao11.cox.net@fed1rmimpo02.cox.net>

Windows Lispworks 4.4.6 and latest ucw-boxset.

After commenting out l10n application in start-common.lisp, starts ok.

But when going to localhost:8080 url gives following error:

 

16:44 UCW.BACKEND/+ERROR+: Error in worker loop: "/" is not of type
CHARACTER..

16:44 UCW.BACKEND/+ERROR+: Worker thread #<IT.BESE.UCW::HTTPD-WORKER
21AF4274> reported #<TYPE-ERROR 20690B8C>.

 

Same error, when to localhost:8080/index.ucw

 

16:44 UCW.BACKEND/+ERROR+: Error in worker loop: "/favicon.ico" is not of
type CHARACTER..

16:44 UCW.BACKEND/+ERROR+: Worker thread #<IT.BESE.UCW::HTTPD-WORKER
21AF43EC> reported #<TYPE-ERROR 21B49FDC>.

16:45 UCW.BACKEND/+ERROR+: Error in worker loop: "/index.ucw" is not of type
CHARACTER..

16:45 UCW.BACKEND/+ERROR+: Worker thread #<IT.BESE.UCW::HTTPD-WORKER
21AF4514> reported #<TYPE-ERROR 21B72554>.

 

Regards,

Vagif

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bese-devel/attachments/20070117/7041603c/attachment.html>

From evrim at core.gen.tr  Sat Jan 20 14:02:28 2007
From: evrim at core.gen.tr (Evrim ULU)
Date: Sat, 20 Jan 2007 16:02:28 +0200
Subject: [Bese-devel] <:css macro
Message-ID: <45B220F4.7070905@core.gen.tr>

Hi,

I've written a small css macro for ucw+, i wonder if anybody has already
done the same thing. There is one inside parenscript but it does not
allow cascading. I may merge it to _dev if requested.

(in-package :it.bese.ucw)

(defvar *current-selected* nil)
(deftag-macro <:css (selectors &allow-other-attributes others &body body)
  `(let ((*current-selected* (if *current-selected*
                 (reduce #'(lambda (acc item)
                         (nconc acc                           
                            (mapcar #'(lambda (current)
                                (js::string-join (list current item) " "))
                                *current-selected*)))
                     (list ,@(ensure-list selectors))
                     :initial-value nil)
                 (list ,@(ensure-list selectors)))))
     (<:ai
      (format nil "~A {~%~A};~%~%"
          (js::string-join *current-selected* ", ")
          (reduce #'(lambda (acc item)
              (if (keywordp item)
                  (concatenate 'string acc " " (string-downcase (string
item)) ":")
                  (concatenate 'string acc " " item ";" ~%)))
              (list , at others)
              :initial-value nil)))
     , at body))

;; Test
;; (<:css ("div.abc" "div.def")
;;        :def "gef"
;;        :color "#000"
;;        (<:css ("a:hover" "a:active" "a:link")
;;           :abc "def"))

;; div.abc, div.def {
;;  def: gef;
;;  color: #000;
;; };

;; div.abc a:hover, div.def a:hover, div.abc a:active, div.def a:active,
div.abc a:link, div.def a:link {
;;  abc: def;
;; };


thanks.
evrim.



From mbaringer at common-lisp.net  Fri Jan 26 05:30:15 2007
From: mbaringer at common-lisp.net (Marco Baringer)
Date: Fri, 26 Jan 2007 00:30:15 -0500 (EST)
Subject: [Bese-devel] New patches to ucw_dev: 25-Jan-2007
Message-ID: <20070126053015.336D256006@common-lisp.net>


Thu Jan 25 05:26:08 EST 2007  evrim at core.gen.tr
  * session-id-length, frame-id-length, callback-id-length is not constant now. defvar is sufficient.

    M ./src/rerl/standard-vars.lisp -7 +4


An updated tarball of ucw_dev's source can be downloaded here:
http://common-lisp.net/project/ucw/tarballs/ucw_dev-20070125.tar.gz

Darcsweb URL:
http://uncommon-web.com/darcsweb/darcsweb.cgi?r=ucw_dev;a=summary