Javascript with weblocks

[Mackram]

So i have been looking at the doc and trying to understand how
weblocks deals with javascript. Now from my assessment the porting of
the js files as mentioned in the js-backend-absraction. And my
understanding is that we would like to have a function define-
javascript-backend which will define the framework you will include
(along with the corrected ported files). Now my problem is trying to
figure out where weblocks adds all its js code. A bit of search lead
me to application.lisp where the different js files are appended.
However the demo outputs a combined file .... how does it do it and
where does the aggregator, so to speak, gets its list of files?


Regards,

Mackram

[Leslie P. Polzer]

Mackram wrote:
>
> So i have been looking at the doc and trying to understand how
> weblocks deals with javascript. Now from my assessment the porting of
> the js files as mentioned in the js-backend-absraction. And my
> understanding is that we would like to have a function define-
> javascript-backend which will define the framework you will include
> (along with the corrected ported files).

Yes, the idea is to have several backends like this

pub/scripts/backends
/prototype
/jquery
/yui

Each one of those would have a matching DEFINE-JAVASCRIPT-BACKEND
expression.

Each webapp could then select one of those by its unique name.

Example:

(defwebapp foo :prefix "/" :javascript-backend prototype)

> Now my problem is trying to
> figure out where weblocks adds all its js code. A bit of search lead
> me to application.lisp where the different js files are appended.
> However the demo outputs a combined file

Note: you can turn this off by specifying :DEBUG T.

> .... how does it do it and where does the aggregator, so to speak,
> gets its list of files?

The list of files is fed into COMPACT-DEPENDENCIES which in turn
calls BUNDLE-DEPENDENCIES. See bundling.lisp and versioning.lisp
for the whole fun.

But I don't think you need to understand bundling. You just
need to parameterize the list of default application dependencies
(in application.lisp) on the selected js backend.

Leslie

[Mackram]

Okay that is great Leslie,

So i will work on porting the js files to jquery and will implement
the functionality in this weekend. By that way hopefully ver 0.8.3
will have support out of the box for both jquery and prototype :)

Mackram

On Jul 1, 12:23 pm, "Leslie P. Polzer" <s...@viridian-project.de>
wrote:

[Mackram]

I just wanted to ask about one little note. In the docs you state that
the following need to be ported
weblocks.js
weblocks-debug.js
dialog.js
datagrid.js
hard-coded js in src/

while in the application.lisp the following are added:
((:stylesheet "layout")
(:stylesheet "main")
(:stylesheet "dialog")
(:script "prototype")
(:script "scriptaculous")
(:script "shortcut")
(:script "weblocks")
(:script "dialog"))

basically i am asking why not port shortcut (I can understand datagrid
would be called by its respective widget and hence does not explicitly
get called in applicaiton).

[Leslie P. Polzer]

Mackram wrote:

> So i will work on porting the js files to jquery and will implement
> the functionality in this weekend. By that way hopefully ver 0.8.3
> will have support out of the box for both jquery and prototype :)

Cool! Thanks in advance for your work!

It's about time we got rid of our Prototype lock-in.

[Leslie P. Polzer]

Mackram wrote:

> basically i am asking why not port shortcut (I can understand datagrid
> would be called by its respective widget and hence does not explicitly
> get called in applicaiton).

Shortcut isn't tied to a particular backend, it's self-sufficient.

And a small note: we (or initially you, whichever you prefer)
need to define an abstract API for the js backend that needs
to be implemented by each one.

Example:

/* abstract as used by Weblocks files */
function applyEffect(type, targetEl) {}

/* prototype/scriptaculous impl */
function applyEffect(type, targetEl) {
switch (type) {
case 'fade':
Effect.fade(target);
break

// ...
}

/* jquery impl */
[...]

That should also resolve your question about datagrid.js
and dialog.js: they may remain in the standard application
dependencies and need to be converted to use the abstract
API.

[Mackram]

Yes i like the idea of abstraction and it makes sense that way but I
was thinking more along the following lines:
weblocks.js:
function applyEffect(type, targetEl) {}

weblocks-jquery.js:
window.applyEffect = function(type,targetEL){....} /* jquery impl
*/

weblocks-prototype.js
window.applyEffect = function(type,targetEL){....} /* prototype/
scriptaculous impl */

That way the lisp code will only add the required implementation
rather then all of them and hence make the js code smaller. Also it
would probably make debugging easy.

What do you think?

Mackram
On Jul 1, 9:27 pm, "Leslie P. Polzer" <s...@viridian-project.de>
wrote:

[Leslie P. Polzer]

On Wed, Jul 01, 2009 at 11:59:06AM -0700, Mackram wrote:
>
> Yes i like the idea of abstraction and it makes sense that way but I
> was thinking more along the following lines:
> weblocks.js:
> function applyEffect(type, targetEl) {}
>
> weblocks-jquery.js:
> window.applyEffect = function(type,targetEL){....} /* jquery impl
> */
>
> weblocks-prototype.js
> window.applyEffect = function(type,targetEL){....} /* prototype/
> scriptaculous impl */
>
> That way the lisp code will only add the required implementation
> rather then all of them and hence make the js code smaller. Also it
> would probably make debugging easy.
>
> What do you think?

Yes, that was my intention above, I just left out the file names for
brevity.

However I think that every backend should have a separate
directory to make it possible to use multiple files without
cluttering one top-level directory.

[Mackram]

So I worked on this a pit last night and had some progress and then
realised we need a design decision. Current frameworks seem to have
their own css which means we probably should not just limit ourselved
to setting the javascript framework.

Basically what i am suggesting is that rathere than having the (define-
javascript-backend NAME ROOT FILES) as mentioned in the docs we would
have (define-client-backend NAME :js-root JROOT :js-files JFILES :css-
root CROOT :css-files CFILES). The definition of paths will follow
that of the doc.

I think this would give us a better step for the future, but I want to
make sure it is inline with what we want to be added to the weblocks
main branch so what do you think?

On Jul 1, 10:04 pm, "Leslie P. Polzer" <s...@viridian-project.de>
wrote:

[Leslie P. Polzer]

Mackram wrote:

> Basically what i am suggesting is that rathere than having the (define-
> javascript-backend NAME ROOT FILES) as mentioned in the docs we would
> have (define-client-backend NAME :js-root JROOT :js-files JFILES :css-
> root CROOT :css-files CFILES). The definition of paths will follow
> that of the doc.
>
> I think this would give us a better step for the future, but I want to
> make sure it is inline with what we want to be added to the weblocks
> main branch so what do you think?

Looks good to me!

[Mackram]

Okay so i have written the lisp code and tried running it through the
old patch of tests that is there (I am not done with a test file for
this specific patch yet) and I have a few comments to make:

1- I have had to modify a couple of tests so that they continue to
behave in the default manner. Specifically in the old version
prototype is added by default with the new version we can not add
anything by default since you would have to specify its files.
Accordingly I have had to add an extra argument for the webapp in the
cases where it was tested.

2- In some tests where bundling is compared the script hierarchy is
hardcoded into the test and for us to move the scripts to a more
appropriate location would require the change of these tests as well.

3- I have had only 3 failures in all the tests and they are all under
handle-request.lisp. Specifically I am having trouble with handle-
client-request-6, handle-client-request-7 (in both these cases I get
result 1 when 2 is expected) and handle-client-request-10 (I get the
result "nil" when the result expected is "http://nil/?weblocks-
session=1%3atest"). My question is can anyone point me on to what
these are trying to test specifically?

Thanks,

Mackram

On Jul 2, 2:32 pm, "Leslie P. Polzer" <s...@viridian-project.de>
wrote:

[Leslie P. Polzer]

Mackram wrote:
>
> Okay so i have written the lisp code and tried running it through the
> old patch of tests that is there (I am not done with a test file for
> this specific patch yet) and I have a few comments to make:
>
> 1- I have had to modify a couple of tests so that they continue to
> behave in the default manner. Specifically in the old version
> prototype is added by default with the new version we can not add
> anything by default since you would have to specify its files.
> Accordingly I have had to add an extra argument for the webapp in the
> cases where it was tested.
>
> 2- In some tests where bundling is compared the script hierarchy is
> hardcoded into the test and for us to move the scripts to a more
> appropriate location would require the change of these tests as well.

Those two changes are perfectly alright.

> 3- I have had only 3 failures in all the tests and they are all under
> handle-request.lisp. Specifically I am having trouble with handle-
> client-request-6, handle-client-request-7 (in both these cases I get
> result 1 when 2 is expected) and handle-client-request-10 (I get the
> result "nil" when the result expected is "http://nil/?weblocks-
> session=1%3atest"). My question is can anyone point me on to what
> these are trying to test specifically?

It's unfortunate that the tests are just numbered instead
of having a descriptive name.

I've glossed over them:

HCR-6 tests PRE-RENDER and POST-RENDER session hooks.
HCR-7 tests PRE-ACTION and POST-RENDER request hooks.
HCR-10 tests PRE-ACTION and POST-ACTION session hooks and
simple action handling.

For 6 and 7 (and maybe the second value of 10 too) you
need to check why the hooks don't get run.

For 10 check where redirects happen (or where they don't
but should). Also check manually whether a request of
the form http://server/?action=foo causes a redirect.

[Mackram]

Okay some help here is really appreciated. Can anyone point me to
where datagrid.js is added to the project cause I just can't find
it :).

On a side note if I force the abstraction to show datagrid-
prototype.js all the time then we are done but I do not like this
approach so help is needed. And oh the abstraction passes all the
tests so we are almost done.

Regards,

Mackram

On Jul 3, 10:12 am, "Leslie P. Polzer" <s...@viridian-project.de>
wrote:

[Leslie P. Polzer]

Mackram wrote:
>
> Okay some help here is really appreciated. Can anyone point me to
> where datagrid.js is added to the project cause I just can't find
> it :).

For each widget that is rendered we check whether there exists
a CSS and JS file with its class name (i.e. datagrid.js as Javascript
for DATAGRID). If it exists we include it.

> On a side note if I force the abstraction to show datagrid-
> prototype.js all the time then we are done but I do not like this
> approach so help is needed.

Widgets should be backend-agnostic; they should only use
functions from the common abstract JS API.

Example:

API (e.g. pub/scripts/backend/weblocks-api/foo.js):
weblocks.doFoo() = function ()
{ throw "Uh oh, doFoo() not defined for your backend. :("; };

Backend1 (e.g. pub/scripts/backend/prototype/foo.js):
weblocks.doFoo = function () { prototype.doFoo(); };
Backend2 (e.g. pub/scripts/backend/jquery/foo.js):
weblocks.doFoo = function () { jquery.doFoo(); };

Caller (e.g. datagrid.js in pub/scripts):
weblocks.doFoo(); /* must NOT use or know about
prototype.doFoo or jquery.doFoo */

> And oh the abstraction passes all the tests so we are almost
> done.

Ah, so you've managed to fix those test cases we talked about?

That's good.

Leslie

[Mackram]

Okay I did that but found myself really surprised when I noticed that
clicking on the Add button in say the companies page of weblocks-demo
included the css and the doms all over again. Why is that and where to
find it?


On Jul 5, 12:14 pm, "Leslie P. Polzer" <s...@viridian-project.de>
wrote:

[Leslie P. Polzer]

Mackram wrote:
>
> Okay I did that but found myself really surprised when I noticed that
> clicking on the Add button in say the companies page of weblocks-demo
> included the css and the doms all over again. Why is that and where to
> find it?

The code responsible for sending deps on AJAX requests is
in RENDER-DEPENDENCY-IN-AJAX-RESPONSE, which is called
by the default RENDER-WIDGET method (src/widgets/widget/widget.lisp).

We just send all deps for widgets marked dirty in the AJAX
request to ensure that the client has them.

This is crude since it doesn't take into account dependencies
that are already existing. Plus it doesn't work in all cases
(<script src="..."/> comes to mind, and there are other
subtleties), but all in all it does more good than harm,
especially as far as CSS is concerned.

But feel free to propose a better mechanism.

[Mackram]

Okay top of my head thinking will lead me to do the following
algorithim:

1- Before returning the JSON response check if the script or
stylesheet is already in the page-dependencies if it is eliminate the
script/stylesheet from being sent since the bundle has already
included it
2- By adding a js function on the client side we can check the json
response and if the stylesheet/script has already been added then do
not add it again.

The above will make sure that in webpages that are heavy in both css &
javascript (much of Web 2.0) we do not keep requesting the client to
reload the same page and more importantly global variables/functions
are not over-written.

What do you think? Should I go ahead and implement this?

Mackram

On Jul 5, 2:29 pm, "Leslie P. Polzer" <s...@viridian-project.de>
wrote:

[Leslie P. Polzer]

On Sun, Jul 05, 2009 at 05:13:39AM -0700, Mackram wrote:
>
> Okay top of my head thinking will lead me to do the following
> algorithim:
>
> 1- Before returning the JSON response check if the script or
> stylesheet is already in the page-dependencies if it is eliminate the
> script/stylesheet from being sent since the bundle has already
> included it
> 2- By adding a js function on the client side we can check the json
> response and if the stylesheet/script has already been added then do
> not add it again.
>
> The above will make sure that in webpages that are heavy in both css &
> javascript (much of Web 2.0) we do not keep requesting the client to
> reload the same page and more importantly global variables/functions
> are not over-written.
>
> What do you think? Should I go ahead and implement this?

I think that the penalty isn't that high since CSS and JS files
should always be cached anyway.

But it would be much cleaner with your proposal, plus a bit more efficient
especially when one does have external files without cache time.

So it would be cool indeed if you enhanced this mechanism.

Leslie

[Mackram]

Okay, so it is with great pleasure that I announce javascript
abstraction is actually done for weblocks :).

The changes so far have allowed for a client backend abstraction that
abstracts both js and css used in a framework. Also the core js files
have been changed to become generic functions with only an alert in
them with the backend overwriting those functions. Finally I also
changed the way scripts were loaded through AJAX previously, now only
those scripts/stylesheets that were not part of the bundle and were
not previously included are included.

I still have a few things such as changing the other examples and also
modifying the default application not to mention writing the jquery
part because I want to use it :). But in any case this list is pretty
short and would probably be done in a few hours. So if it is not too
stupid a question how do we go about merging my change with the main
code branch?

Now for the question part, as I mentioned earlier I intend to use
weblocks in production-grade code (I am starting my own company) but I
am scared of some shortcomings such as the loading of scripting
through AJAX. You see the scripts were being loaded every time you
made an ajax call (something like 10 files) a few click happy
customers and I am not sure how responsive the page would become.
Luckily that was an easy fix ;). Anyways, if you happen to know of
anything inside weblocks that is in need of immediate work to make it
more production ready, please let me know I am willing to volunteer
the time after all it will just make my work even better :).



On Jul 5, 3:36 pm, "Leslie P. Polzer" <s...@viridian-project.de>
wrote:

[Leslie P. Polzer]

Mackram wrote:
>
> Okay, so it is with great pleasure that I announce javascript
> abstraction is actually done for weblocks :).

I'm likewise filled with great pleasure to hear this!

> I still have a few things such as changing the other examples and also
> modifying the default application not to mention writing the jquery
> part because I want to use it :). But in any case this list is pretty
> short and would probably be done in a few hours. So if it is not too
> stupid a question how do we go about merging my change with the main
> code branch?

I've noticed that you already forked a repository on Bitbucket.

Here are the next steps:

1. push your code to your public repository

2. notify us and wait for comments

3. fix missing things or things that need to be corrected.
go back to (2) as necessary.

After that I'll pull your changes into -dev from where they
will eventually make their way into -stable.

> Luckily that was an easy fix ;). Anyways, if you happen to know of
> anything inside weblocks that is in need of immediate work to make it
> more production ready, please let me know I am willing to volunteer
> the time after all it will just make my work even better :).

I like your attitude. Now there's one thing that would be suitable
for immediate work and will provide great gains, and that is the
view system rework.

You can find a lot on this topic by searching the discussion archive
for 'views'. In short there are two big problems:

1. Views and widgets share a common problem domain but are quite
separate right now. The limited view DSL is nice for a lot of
purposes but often you need to fully replace it with a widget
or resort to ugly hacks to get the flexibility you need.

2. Views (and presentations, and parsers) are singletons. This
makes it difficult to dynamically configure views per-request
and even per-session.

Both of these problems can be tackled at once by implementing views
via widgets. Jan Rychter and Saikat Chakrabarti had some interesting
ideas.

In fact some of the work has already been done by Saikat.

You can find it here:

http://bitbucket.org/saikat/weblocks-saikat/

Leslie

[Mackram]

Okay cool so I have already pushed all my changes to my fork on
bitbucket so you can have a look. I will try to finish the few things
that I mentioned in the next few days so that the change is complete
on all examples and people can easily choose jquery as well.

In the mean time any things that do not look good please let me know.
And I will try to find the time to draw a plan for tackling the
problem you mentioned during this week.

Regards,

Mackram

On Jul 5, 9:26 pm, "Leslie P. Polzer" <s...@viridian-project.de>
wrote:

[Leslie P. Polzer]

On Jul 5, 10:32 pm, Mackram <mack...@gmail.com> wrote:

> In the mean time any things that do not look good please let me know.

Please try to put only things that belong together into your commits.
'hg record' is helpful for doing this.

Likewise please provide specific commit messages that show what
has changed in a synoptical way.

These two things make it easier for people to review your commits
and identify problems later.


Comments on the code follow. I've reviewed them starting with
the oldest so it might happen that I criticize things that
you have fixed or changed in later commits.

* please try to keep your lines (including docstrings) roughly to 80
characters.

* define-client-backend: not sure if this should be a DEFVAR instead
of a DEFPARAMETER...

* make-backend-dependency: I haven't checked more closely but
it seems to contain a lot of code already found in make-local-
dependency
(or some other dep function). Is there a way to merge them?

* build-client-backend: let's use NCONC here instead of APPEND.
This dep stuff is in the performance-critical path.

* build-client-backend: use WHEN if your IF only has one consequent.
This also leads to the more idiomatic
(loop for file in (files backend)
when (string/= ...)
collect file)

* webapp class, slot javascript-backend: provide an INITFORM here.
We can't run without a backend. JQuery is a good default.

This also removes the conditional

(if (weblocks-webapp-javascript-backend app)

below.

* test HCR-10 (I think): prototype isn't quoted. This test
will fail.

* 6ebd733f23b9: do we need the *.0.* files in the repository?
(This is not a rhetorical question, I'm unsure myself)

* fb8f5271c109: you've changed the webapp description of the
demo into a meaningless string. Please revert to the old value
"A web application based on Weblocks" or a better one based on
that.

* ibid.: alert("Oops. You do not have a backend defined")
-- let's abstract that into a function called whenever
there's no backend. We should also take into account
partial implementations -- some backends might not
have effects stuff for example.

* ibid.: please trim down the number of chars per line here
as well.

* ibid. (src/dependencies.lisp): NCONC as well.

[Mackram]

Hey Guys,

First off sorry for not replying earlier but it is a hectic week okay
so here goes:

> Please try to put only things that belong together into your commits.
> 'hg record' is helpful for doing this.
>
> Likewise please provide specific commit messages that show what
> has changed in a synoptical way.
>

You are absolutely right, I should have taken the time to read a bit
more about mercurial before I started uploading.

> * please try to keep your lines (including docstrings) roughly to 80
> characters.

fair enough. Any other coding standards we are following?

> * define-client-backend: not sure if this should be a DEFVAR instead
> of a DEFPARAMETER...

Well I was thinking I wanted to overwrite the same symbol name so in
case we provide some symbol say jquery by default the user would be
able to change it by simply calling define-client-backend with symbol
jquery later on while if it was DEFVAR then he is stuck with the
default setup.

> * make-backend-dependency: I haven't checked more closely but
> it seems to contain a lot of code already found in make-local-
> dependency
> (or some other dep function). Is there a way to merge them?

I believe so, I started with a copy of make-local-dependency but had
changes specific to the ajax-backend but if memory serves I ended up
reverting to almost the same thing. I will check and merge if
possible.

> * build-client-backend: let's use NCONC here instead of APPEND.
> This dep stuff is in the performance-critical path.

Thanks for the tip did not know that nconc had a shorter execution
then APPEND. (by the way any suggestions how i can profile/debug
weblocks while i am running it a service ie with hunchentoot serving
the pages)

> * test HCR-10 (I think): prototype isn't quoted. This test
> will fail.

I believe you were looking at not the final commit since the final
commit I uploaded had passed all the tests.

> * 6ebd733f23b9: do we need the *.0.* files in the repository?
> (This is not a rhetorical question, I'm unsure myself)

No not at all. Did not even realize that I had uploaded those will be
more careful.

> * ibid.: alert("Oops. You do not have a backend defined")
> -- let's abstract that into a function called whenever
> there's no backend. We should also take into account
> partial implementations -- some backends might not
> have effects stuff for example.

Sure I will abstract that to one function. However there are no
effects that are in the core file that we have (I think) and all
should be implemented as I understood so correct me if I am wrong.

I will try to do the above list in the coming two days or early next
week (hectic weekend sorry).

Regards,

Mackram

[Leslie P. Polzer]

Hi Mackram,

great, I already thought I'd turned you off with my comments, heh.

>> * please try to keep your lines (including docstrings) roughly to 80
>> characters.
> fair enough. Any other coding standards we are following?

We're pretty loose about that right now.

I have (and I believe Stephen has too) found it helpful for
diffability/mergeability to have one symbol per line in EXPORT
expressions.

No other things come to my mind right now.

>> * define-client-backend: not sure if this should be a DEFVAR instead
>> of a DEFPARAMETER...
> Well I was thinking I wanted to overwrite the same symbol name so in
> case we provide some symbol say jquery by default the user would be
> able to change it by simply calling define-client-backend with symbol
> jquery later on while if it was DEFVAR then he is stuck with the
> default setup.

Let's keep it that way then.

>> * build-client-backend: let's use NCONC here instead of APPEND.
>> This dep stuff is in the performance-critical path.
> Thanks for the tip did not know that nconc had a shorter execution
> then APPEND.

Of course don't forget that the original list is clobbered with
NCONC. In the cases I mentioned we know that we're operating on
a private list so it's alright.

> (by the way any suggestions how i can profile/debug
> weblocks while i am running it a service ie with hunchentoot serving
> the pages)

You're lucky, I just implemented that very recently.

Try searching the group for "timings" and let me know
if you have any questions.

>> * test HCR-10 (I think): prototype isn't quoted. This test
>> will fail.
> I believe you were looking at not the final commit since the final
> commit I uploaded had passed all the tests.

No worries, I will test the whole thing after the pull anyway.

> Sure I will abstract that to one function. However there are no
> effects that are in the core file that we have (I think) and all
> should be implemented as I understood so correct me if I am wrong.

I'm not sure what you mean here. The Flash widget for example
uses the Appear effect of Scriptaculous.

Leslie

[Mackram]

Hey Everyone,

sorry that the change is taking so long but has been hectic week and I
hit a little snag (some cases do not seem to work, also there is some
hardcoding inside the weblocks code to use prototype so i am taking
that out). So I wanted to ask Leslie was mentioning a method of
debugging what the server is running so that i see the request and how
it is being passed through. Is this done? any suggestions on how to
use it.

Regards,

Mackram.

On Jul 9, 10:15 am, "Leslie P. Polzer" <s...@viridian-project.de>
wrote:

[Leslie P. Polzer]

Hey Mackram,

> So I wanted to ask Leslie was mentioning a method of
> debugging what the server is running so that i see the request and how
> it is being passed through. Is this done?

I think that was related to time/performance measurement.

What parts do you need to analyze?

Leslie

[Mackram]

Hey

So I wanted to check the json part/request handlers. For some reason I
am geting null response for the json response and I want to figure out
what is being sent from the client and what the server is attempting
to respond

[Leslie P. Polzer]

On Jul 20, 12:04 pm, Mackram <mack...@gmail.com> wrote:

> So I wanted to check the json part/request handlers. For some reason I
> am geting null response for the json response

Maybe it's the bug that was reported and fixed here:

http://groups.google.com/group/weblocks/browse_thread/thread/82bef10dc06f455a

> and I want to figure out what is being sent from the client and what the server is
> attempting to respond

Trace hunchentoot::process-request to see the requested URI
and weblocks:handle-client-request to see what Weblocks returns.

[Mackram]

I am not sure Leslie what i am missing but I am unable to see what is
requested or to debug the flow of the code. The trace shows something
like
0: (HUNCHENTOOT:PROCESS-REQUEST #<HUNCHENTOOT:REQUEST {B63CF79}>)
1: (WEBLOCKS:HANDLE-CLIENT-REQUEST #<WEBLOCKS-DEMO::WEBLOCKS-DEMO
{AAF9A19}>)
1: WEBLOCKS:HANDLE-CLIENT-REQUEST returned
"{\"widgets\":null,\"before-load\":null,\"on-load\":null}"
0: HUNCHENTOOT:PROCESS-REQUEST returned
#<SB-SYS:FD-STREAM for "a socket" {B1FA989}>

which does not tell me anything more then I already know. Am i missing
some obvious way to debug things, appreciate the help :)

Regards

On Jul 21, 4:10 pm, "Leslie P. Polzer" <leslie.pol...@gmx.net> wrote:
> On Jul 20, 12:04 pm, Mackram <mack...@gmail.com> wrote:
>
> > So I wanted to check the json part/request handlers. For some reason I
> > am geting null response for the json response
>
> Maybe it's the bug that was reported and fixed here:
>

> http://groups.google.com/group/weblocks/browse_thread/thread/82bef10d...

[Leslie P. Polzer]

Mackram wrote:
>
> I am not sure Leslie what i am missing but I am unable to see what is
> requested or to debug the flow of the code. The trace shows something
> like
> 0: (HUNCHENTOOT:PROCESS-REQUEST #<HUNCHENTOOT:REQUEST {B63CF79}>)
> 1: (WEBLOCKS:HANDLE-CLIENT-REQUEST #<WEBLOCKS-DEMO::WEBLOCKS-DEMO
> {AAF9A19}>)
> 1: WEBLOCKS:HANDLE-CLIENT-REQUEST returned
> "{\"widgets\":null,\"before-load\":null,\"on-load\":null}"
> 0: HUNCHENTOOT:PROCESS-REQUEST returned
> #<SB-SYS:FD-STREAM for "a socket" {B1FA989}>
>
> which does not tell me anything more then I already know.

You've asked for two things: (1) what the browser asks for
(2) what the answer contains.

The above answers (2).

As for (1): in Hunchentoot 1.0 it doesn't work as neatly
as in 0.15 because PROCESS-REQUEST just gets a request
object. Use this instead:

(defmethod weblocks:handle-client-request :before (app)
(format t "uri: ~S~%" (hunchentoot:request-uri*)))

Leslie

[Mackram]

Okay Guys,

So sorry for taking so long to do the changes but I got sidetracked by
a few personal issues that came up last week. Okay so the changes are
done (I think ;)). The added changes have the jquery functionality
added. At this point I would like to point out that one of the reasons
that it took so long for me to finish the change is that there was
quite a bit of hard-coding of prototype inside the weblocks lisp code
that I was unaware of initially. I have fixed all of these including
the tests but I have a little request from those adding code to the
core. Basically make sure that if you add any javascript code that it
is only generic code that is using the bare metal javascript/DOM
manipulation functions. Later in your backend specific functionality
you can use all the functionality you want. Also my second request
would be either to always make changes to all backends when we do a
change or to mark clearly that the change is not available for a
certain backend.

Leslie, I am not sure if this is a pressing issue but maybe we should
have a document with all the rules for changes that should be followed
so that people know what is expected from core code additions (that
probably applies to me first :D)

On Jul 22, 5:30 pm, "Leslie P. Polzer" <s...@viridian-project.de>
wrote:

[Leslie P. Polzer]

On Jul 27, 11:11 pm, Mackram <mack...@gmail.com> wrote:

> So sorry for taking so long to do the changes but I got sidetracked by
> a few personal issues that came up last week. Okay so the changes are
> done (I think ;)). The added changes have the jquery functionality
> added.

Thanks for your work, I'm going to review it today!

> Basically make sure that if you add any javascript code that it
> is only generic code that is using the bare metal javascript/DOM
> manipulation functions.

Alternatively it could just refer to a new common API function
that has to be filled by the respective backend developers.

In any case I will make sure that no backend-specific code
enters upstream in places where it shouldn't be.

> Later in your backend specific functionality
> you can use all the functionality you want. Also my second request
> would be either to always make changes to all backends when we do a
> change or to mark clearly that the change is not available for a
> certain backend.

I tend towards the latter, as most contributors (including me) are
not familiar with all frameworks we might support. At the moment
this is simple with only Prototype and JQuery, but YUI, Mootools,
MochiKit, ExtJS and all their friends will probably enter the game
later.

> Leslie, I am not sure if this is a pressing issue but maybe we should
> have a document with all the rules for changes that should be followed
> so that people know what is expected from core code additions (that
> probably applies to me first :D)

I'm not sure if I mentioned it before but there's a document at

http://trac.common-lisp.net/cl-weblocks/wiki/WeblocksDevelopment

that has quite a lot of information on that topic. Maybe you'd like to
add some information to it...

[Leslie P. Polzer]

On Jul 28, 9:06 am, "Leslie P. Polzer" <leslie.pol...@gmx.net> wrote:
> On Jul 27, 11:11 pm, Mackram <mack...@gmail.com> wrote:
>
> > So sorry for taking so long to do the changes but I got sidetracked by
> > a few personal issues that came up last week. Okay so the changes are
> > done (I think ;)). The added changes have the jquery functionality
> > added.
>
> Thanks for your work, I'm going to review it today!

Sorry Mackram, this will take me a bit longer. It's a large bunch of
stuff
and my main workstation broke yesterday.

Leslie

[Mackram]

Hey Leslie, no problem at all. Let me know if you want some help or
anything.

Note that I am going to be kind of busy in the coming weeks so i might
not have alot of time to work on the widget/view problem.

Let me know if you need anything.

Regards,
Mackram

[Maciej Katafiasz]

On Aug 1, 11:21 am, Mackram <mack...@gmail.com> wrote:
> Hey Leslie, no problem at all. Let me know if you want some help or
> anything.

Not to stress you out or anything, but any progress? I'd like to
avoid writing a huge bunch of code for prototype only to port it to
jquery later on when it becomes available. Prototype is very much not
my favourite framework (I had a brief professional encounter with
Rails, y'see, and it left a distaste for both), so options would be
good. Also, I have thoughts about the JS in general, but that's
blocking on me writing the huge email I mentioned in another thread.

Cheers,
Maciej

[Leslie P. Polzer]

Maciej Katafiasz wrote:

> Not to stress you out or anything, but any progress? I'd like to
> avoid writing a huge bunch of code for prototype only to port it to
> jquery later on when it becomes available.

I will try to review the code until next weekend.

You can rely on this code making it into mainline in any case though,
so do write your code for JQuery.

> Prototype is very much not my favourite framework

Yes. To be honest I'm not sure why it still exists except
for backwards compatibility.

> (I had a brief professional encounter with Rails, y'see, and it
> left a distaste for both),

Not to carry this too far OT here, but I'm curious what you
didn't like about it?

> Also, I have thoughts about the JS in general, but that's
> blocking on me writing the huge email I mentioned in another thread.

Please let us hear about it when you're ready.

Leslie

[Leslie P. Polzer]

On Aug 1, 11:21 am, Mackram <mack...@gmail.com> wrote:

> Hey Leslie, no problem at all. Let me know if you want some help or
> anything.
>
> Note that I am going to be kind of busy in the coming weeks so i might
> not have alot of time to work on the widget/view problem.
>
> Let me know if you need anything.

Two first observations:

1)

diff -r 5822fd897401 -r 826cbaa2b428 examples/weblocks-demo/weblocks-
demo.lisp
--- a/examples/weblocks-demo/weblocks-demo.lisp Sat Jul 04 22:00:07
2009 +0300
+++ b/examples/weblocks-demo/weblocks-demo.lisp Mon Jul 27 23:59:22
2009 +0300
@@ -24,9 +24,20 @@
"Access to a sandbox store in the session."
`(hunchentoot:session-value 'sandbox-store))

+(define-client-backend jquery :js-root "backends/jquery"
+ :js-files `("jquery"
+ "jquery-ui"
+ "dialog-jquery"
+ "weblocks-jquery"
+ "jquery-delayedObserver" "jquery-ui-autocomplete")
+ :css-root ""
+ :css-files `("main" "layout" "dialog" "jquery-ui"))

Weblocks should have the JQuery and Prototype backends defined out of
the box.

Also, what currently happens when we have multiple definitions for a
backend?


2) namespacing

We should structure the Weblocks API a bit. All elements should be
part
of a namespace/object named "Weblocks". Specialized APIs (e.g. Effect)
should probably have their own namespace beneath.

So blindUpEffectById() will become Weblocks.Effect.blindUpById().

Leslie

[Mackram]

Hey Leslie,

So to answer both your questions:

1- I only defined jquery because I though you said you want it to be
the default one. Defining prototype is easy (I already tested it with
both jquery and prototype) and I can put it in tonight when i get home
(different code machines). As for what happens, well since we define
the symbol as a defparameter it will get overwritten which is i think
how it should be done. The reason is that if someone wants to add even
more functionality to the definition they could and are not stuck with
what we define.

2- For the namespace i think that is a good idea (i thought about it
but i can not seem to remeber why i did not do it) I can easily do the
change if you want although I would not go so far as specialized APIs
since as i mentioned previously all "weblocks" API should be generic
and each person will extend in his own library the way they want. Tell
me what you think and if you want i can do it quickly.

Regards,

Mackram

[Leslie P. Polzer]

Mackram wrote:

> 1- I only defined jquery because I though you said you want it to be
> the default one. Defining prototype is easy (I already tested it with
> both jquery and prototype) and I can put it in tonight when i get home
> (different code machines).

Well my main question is why you define the backend in the Weblocks
demo code. Shouldn't it be part of the core code?

> As for what happens, well since we define
> the symbol as a defparameter it will get overwritten which is i think
> how it should be done. The reason is that if someone wants to add even
> more functionality to the definition they could and are not stuck with
> what we define.

Yes, that sounds sensible. I seem to remember that we discussed this
topic already.

> 2- For the namespace i think that is a good idea (i thought about it
> but i can not seem to remeber why i did not do it) I can easily do the
> change if you want although I would not go so far as specialized APIs
> since as i mentioned previously all "weblocks" API should be generic
> and each person will extend in his own library the way they want. Tell
> me what you think and if you want i can do it quickly.

It seems to be enough to put everything under the "Weblocks"
(or "weblocks") namespace to start with.

Leslie

[Maciej Katafiasz]

On Aug 7, 11:23 am, "Leslie P. Polzer" <s...@viridian-project.de>
wrote:

> Maciej Katafiasz wrote:
> > (I had a brief professional encounter with Rails, y'see, and it
> > left a distaste for both),
>
> Not to carry this too far OT here, but I'm curious what you
> didn't like about it?

Mostly the ever-present horrible hack culture. They're completely
happy to use magic to pretend problems disappear, and then leave it
largely unimplemented without even so much as hinting about it. So
you're led to believe it works, but then walk into a trap you couldn't
possibly see because the supposed magic obscured it. Prototype, which
is in every inch Rail's brainchild, does exactly the same; in fact,
there's an amusing class of bugs that depend their collective code and
docs being crappy and misleading in an interleaving way.

To give some examples (sorry about the lack of details, but it's been
a long time):
- ActiveRecord. The completely retarded join semantics which only make
sense if you know how retardedly (and completely non-conformingly)
MySQL behaves (but they still pretend to be DB-agnostic). The fact
that projections will pretend to be of some model class, but will lack
all the fields not included in the query, so methods will fail in
random and amusing ways.

- Rails REPL (aka console), which models only the C part of MVC,
meaning you're SoL when you need to touch the M or V parts. And the
fact that even the C part is all but useless without the magic request
object(*)

- Prototype releasing broken, untested versions. Which lead to a day
wasted searching for a bug in my commits that broke our -dev server,
despite it working fine on my own machine, before I realised that
someone updated Prototype (1.5.1 → 1.5.2 or something similarly minor)
and that they decided to do major refactoring in that version without
testing, breaking previously-working features. The obscure, unpopular
and definitely unused feature of popup completions in input fields.

- Speaking of which, Rails & Prototype docs both suggesting that
completing on custom values, not the ones shown, was supported and
nonchalantly referring to it as "unless specified differently by the
options", which took me half a day to figure out it wasn't actually
and that "specified differently by the options" means "you're actually
supposed to override the default get_completions controller and hack
it into providing a reply doing what you want using the protocol you
need to reverse engineer from what prototype then does with it". So I
did, and using some cleverness I was even able to make it backwards-
compatible with the ordinary invocations of get_completions, thus
avoiding the need to un-break all the other sites in the code relying
on it. To be honest, I can't remember if I ever got around to
submitting the patch upstream :)

- Speaking of which, the very "options" hash, which is always
nonchalantly described by "as specified by the options" in the docs,
before being passed through a twisty maze of ten undocumented function
calls, all alike.

Now, to be sure, a lot of the above, especially the lacking
documentation on the protocols things are supposed to follow (which is
made extra fun to investigate when the breaking code resides in a
piece transformed by the CPS magic), applies to Weblocks. But in Rails
it always felt as if they were perfectly fine with dirty hacks, and I
never felt that Rails was even aiming at the right abstraction level
anyway. In many ways Rails gives the impression of PHP built on a
better (but still incredibly hacky) language. Sure, it's incomparably
nicer to write in, but the culture of "works on my machine for the
single use-case I had at hand, let's commit to the main tree as a
builtin!" is similarly prevalent.

Cheers,
Maciej

(*) that reminds me, WITH-REQUEST & friends should *really* be a part
of our public API, not buried deep in the unit tests. Really. Unless
it's there and I'm just missing something.

[Mackram]

Oh regarding the defining of jquery in demo, the jquery is being
defined in the core. The redefinition in the demo was just for testing
that reassignment actually works we can rip it out now (since in the
final batch i submitted the core definition had all the js directly
included).

As for the namespace I will work on it this week and release it.

Regards,

Mackram

On Aug 7, 3:37 pm, "Leslie P. Polzer" <s...@viridian-project.de>
wrote:

[Leslie P. Polzer]

On Aug 7, 7:52 pm, Maciej Katafiasz <mathr...@gmail.com> wrote:

> Mostly the ever-present horrible hack culture. [...]

Thanks, that's been an interesting synopsis.

> (*) that reminds me, WITH-REQUEST & friends should *really* be a part
> of our public API, not buried deep in the unit tests. Really. Unless
> it's there and I'm just missing something.

Yes, that's part of my wishlist too but a lot of other things come
before
that... :/

[Leslie P. Polzer]

On Aug 7, 9:36 pm, Mackram <mack...@gmail.com> wrote:
> Oh regarding the defining of jquery in demo, the jquery is being
> defined in the core. The redefinition in the demo was just for testing
> that reassignment actually works we can rip it out now (since in the
> final batch i submitted the core definition had all the js directly
> included).

Ah, alright. Thanks for your incredible work so far! :)

[Leslie P. Polzer]

I have finished reviewing the diff now. Remaining comments, mostly
minor:

@@ -605,8 +612,12 @@
"Returns a list of dependencies on scripts and/or stylesheets that
will persist throughout the whole application. See documentation
for
'widget-application-dependencies' for more details."
- (build-local-dependencies
- (weblocks-webapp-application-dependencies app)))
+ (append
+ (if (weblocks-webapp-application-dependencies app)
+ (build-local-dependencies
+ (weblocks-webapp-application-dependencies app)))
+ (if (weblocks-webapp-javascript-backend app)
+ (build-client-backend (weblocks-webapp-javascript-backend
app)))))

These IF clauses don't have correct indentation. But since they are
missing
an else clause we can just use WHEN. And if you're not adverse to
anaphoric
macros (your choice) this boils down to

(awhen (weblocks-webapp-application-dependencies app)
(build-local-dependencies it))


+ (defun build-client-backend (backend)

Let's make this a generic function so we can specialize it for certain
backends.


diff -r 5822fd897401 -r 826cbaa2b428 src/widgets/widget/widget.lisp
--- a/src/widgets/widget/widget.lisp Sat Jul 04 22:00:07 2009 +0300
+++ b/src/widgets/widget/widget.lisp Mon Jul 27 23:59:22 2009 +0300
@@ -373,9 +373,9 @@
(defmethod render-widget (obj &rest args &key inlinep &allow-other-
keys)
(declare (special *page-dependencies*))
(if (ajax-request-p)
- (mapc #'render-dependency-in-ajax-response (dependencies obj))
- (setf *page-dependencies*
- (append *page-dependencies* (dependencies obj))))
+ (render-ajax-dependency-after-check (dependencies obj) *page-
dependencies*)
+ (setf *page-dependencies*
+ (append *page-dependencies* (dependencies obj))))
(let ((*current-widget* obj))
(declare (special *current-widget*))
(if inlinep
@@ -514,3 +514,10 @@
(timing (concatenate 'string "render-widget " (princ-to-string
widget))
(call-next-method)))

+(defun render-ajax-dependency-after-check (dependency-list page-
dependency)
+ "This helper function makes sure that only those dependencies that
have not yet been set in the page-dependency are added through json."
+ (loop for depend in dependency-list
+ collect
+ (if (member depend page-dependency)
+ (render-dependency-in-ajax-response depend))))
+

Does this code have any effect? I think we don't have any page deps
when
we're in an AJAX request...


diff -r 5822fd897401 -r 826cbaa2b428 test/weblocks-test.lisp
--- a/test/weblocks-test.lisp Sat Jul 04 22:00:07 2009 +0300
+++ b/test/weblocks-test.lisp Mon Jul 27 23:59:22 2009 +0300
@@ -16,6 +16,12 @@

(in-package :weblocks-test)

+;;Added the definition of the prototype backend so as to allow
testing to continue given that weblocks no longer has a default setup.
+(weblocks:define-client-backend prototype :js-root "backends/
prototype"
+ :js-files `("prototype" "scriptaculous")
+ :css-root ""
+ :css-files `("layout" "main" "dialog"))
+
(declaim (special *recovery-strategies*))

(defun call-with-test-environment (thunk)

Hm, looks like this should be in core as well.


diff -r 5822fd897401 -r 826cbaa2b428 pub/scripts/datagrid.js
--- a/pub/scripts/datagrid.js Sat Jul 04 22:00:07 2009 +0300
+++ b/pub/scripts/datagrid.js Mon Jul 27 23:59:22 2009 +0300
@@ -1,3 +1,9 @@
+////
+
+function throwAlertOnMissingBackend(){
+ alert('Oops, we could not complete your request because of an
internal error.');
+
+}

The error message is wrong (should probably be "Function XXX not
defined in
this backend"), and this function has a lot of duplicates in other
files, although
it should be part of the common API.


Lastly let's not use minified Javascript files. Later we can discern
between
production and debug mode and choose minified/vanilla versions based
on that, but until then let's just use the plain files.

That's it!

Leslie

[Mackram]

Hey Leslie,

The issues seem pretty simple so I will work and upload in the coming
two or three days (having some connection issues in my new "office") I
also finished the change so that all the javascript are in the
weblocks namespace.

Regards,

Mackram

[Leslie P. Polzer]

Mackram wrote:

> The issues seem pretty simple so I will work and upload in the coming
> two or three days (having some connection issues in my new "office") I
> also finished the change so that all the javascript are in the
> weblocks namespace.

Great! Don't forget to merge your branch with -dev afterwards that so
I can pull without conflicts. Your work should be merged soon after
that.

Leslie

[Mackram]

Hey Leslie

So i did a the changes including the namespace change. One thing
though

Leslie wrote:
>Does this code have any effect? I think we don't have any page deps
>when
>we're in an AJAX request...

The code does have effect since it stops any previous loaded js from
loading again. Also my testing showed that page deps are being sent in
the ajax request.

On a different note I did not merge with dev. I tried to do the merge
but when I did I ended up with 78 errors in the test suite so I am not
sure if I am doing something wrong or what can you help since the
errors had nothing to do with the javascript changes (about 20 were
navigation related)

Regards,

Mackram

On Aug 10, 11:24 am, "Leslie P. Polzer" <s...@viridian-project.de>
wrote:

[Leslie P. Polzer]

Mackram wrote:

> The code does have effect since it stops any previous loaded js from
> loading again. Also my testing showed that page deps are being sent in
> the ajax request.

I know what you're trying to do here, but I doubt that *PAGE-DEPENDENCIES*
has any effect. Maybe this helps sort it out:

This variable is bound in handle-client-request and used in
render-widget. But we only modify it in this place when we're
not in an AJAX request.

So how could it be anything else than NIL when an AJAX request
is happening?

> On a different note I did not merge with dev. I tried to do the merge
> but when I did I ended up with 78 errors in the test suite so I am not
> sure if I am doing something wrong or what can you help since the
> errors had nothing to do with the javascript changes (about 20 were
> navigation related)

It must be some changeset of yours since the current -dev test cleanly
apart from one case which involves those pesky versioning bits. :)

Try loading TRIVIAL-SHELL before you load the test suite, it will
point out the differences between expected and actual test results.

Bisecting your changesets is another effective option.

Leslie

[Leslie P. Polzer]

Oh, and do push your merge to Bitbucket so we can take a look at it if
you don't manage to find out what's wrong.

Leslie

[Mackram]

Hey Leslie,

So I merged and uploaded to BitBucket. I still get all the errors but
they are actually all one error. Maybe you can shed light on it. The
error is for example

The value #P"flash" is not of type SEQUENCE.

All 76 errors are the same giving that something is not of type
SEQUENCE.

I will try to look into this again but if you can help that would be
great.

Regards,

Mackram

[Leslie P. Polzer]

Hi Mackram,

the error is here:

(defun make-local-dependency (type file-name &key do-not-probe media
(webapp (current-webapp)) (import-p nil) (backend-root ""))
"Make a local (e.g. residing on the same web server) dependency of
type :stylesheet or :script. Unless :do-not-probe is set, checks if
file-name exists in the server's public files directory, and if it does,
returns a dependency object."
(let* ((relative-path (public-file-relative-path type
(merge-pathnames file-name
(if (string/= backend-root "")
(maybe-add-trailing-slash backend-root)
""))))

You're calling public-file-relative-path with a pathname but it's not prepared
for that. This function needs to be fixed.

Leslie

[Mackram]

Hey Leslie,

Thanks for the hint, I should have found it but I guess i was a bit
tired :). Any ways I fixed it and uploaded the final batch that passes
the tests.

I think it is all finished now.


Regards,

Mackram

On Aug 14, 2:44 pm, "Leslie P. Polzer" <s...@viridian-project.de>
wrote:

[Leslie P. Polzer]

On Aug 14, 7:37 pm, Mackram <mack...@gmail.com> wrote:

> Thanks for the hint, I should have found it but I guess i was a bit
> tired :). Any ways I fixed it and uploaded the final batch that passes
> the tests.
>
> I think it is all finished now.

Looks good, thanks! I should be able to do the pull tomorrow.

[Leslie P. Polzer]

Test suite still doesn't seem up to date:

Test Report for WEBLOCKS-SUITE: 718 tests run, 37 Errors, 18
Failures.

I think you need to update the tests to take the change from someFun()
to
weblocks.someFun() into account.

[Mackram]

Hey Leslie,

the test suit is updated to take into account the changes in the
namespace and I have uploaded everything two days ago (a check on the
repositaries shows that I have no change on my local machine) and all
tests pass on my machine (except for 1 which regards the bundling
version but is normal since i am at bundle version .25 while the test
is for .0).

Can you please recheck and let me know? (PS I faced this problem
before and I fixed it by deleting all the .fasl files in both test and
src with find and then compiled and loaded the whole thing again can
you try that).

Regards,

Mackram

[Leslie P. Polzer]

Mackram wrote:

> Can you please recheck and let me know? (PS I faced this problem
> before and I fixed it by deleting all the .fasl files in both test and
> src with find and then compiled and loaded the whole thing again can
> you try that).

I've made sure I'm up to date and deleted all FASLs. One problem
remains:

ERROR : widgets/dataedit/dataedit-suite : create-new-item-widget-gridedit-1
Condition: error opening
#P"/home/sky/projects/lisp/weblocks.mackram/pub/stylesheets/vzn/dataform-import.0.css":

I'm sure this can be fixed easily...

[Leslie P. Polzer]

> I've made sure I'm up to date and deleted all FASLs. One problem
> remains:
>
>   ERROR  : widgets/dataedit/dataedit-suite : create-new-item-widget-gridedit-1
>   Condition: error opening
> #P"/home/sky/projects/lisp/weblocks.mackram/pub/stylesheets/vzn/dataform-import.0.css":
>
> I'm sure this can be fixed easily...

I've just noticed that this happens with a pristine checkout of -dev
too. Stephen?

Leslie

[Leslie P. Polzer]

Hi Mackram,

I've fixed the failing tests in upstream, can you update your branch
so I can pull it in?

Thanks!

Leslie

[Mackram]

Done. Can you please pull in and make sure it works (on my side the
tests all pass)

Regards,

Mackram

[Leslie P. Polzer]

On Sep 12, 4:32 pm, Mackram <mack...@gmail.com> wrote:
> Done. Can you please pull in and make sure it works (on my side the
> tests all pass)

I get conflicts in two files:

merging pub/scripts/weblocks.js
warning: conflicts during merge.
merging pub/scripts/weblocks.js failed!
merging src/application.lisp
merging src/control-flow/dialog.lisp
merging src/dependencies.lisp
merging src/utils/html.lisp
merging src/utils/suggest.lisp
merging src/versioning.lisp
merging src/widgets/widget/widget.lisp
merging test/application.lisp
merging test/bundling.lisp
warning: conflicts during merge.
merging test/bundling.lisp failed!
merging test/control-flow/dialog.lisp
merging test/versioning.lisp
merging weblocks.asd
81 files updated, 11 files merged, 0 files removed, 2 files unresolved
use 'hg resolve' to retry unresolved file merges or 'hg up --clean' to
abandon

Am I missing something?

[Mackram]

That is really weird leslie unless somehting changed again. Can you
send me the output of hg resolve cause i ma not getting that.

[Leslie P. Polzer]

Mackram wrote:
>
> That is really weird leslie unless somehting changed again. Can you
> send me the output of hg resolve cause i ma not getting that.

I get this when I check out the current versions of -dev and your
branch, then try to pull and merge your branch into -dev.

Leslie