headers
Andy Chambers | 2 Apr 2008 00:03

openair now works on my mac

So I've been working sideways a bit the last few days to get openair
working on my new mac (my girlfriend actually prefers the Linux and
doesn't want me spending all day coding on it.  How cool is that!!?).
Openair (and all its dependancies) actually didn't take much effort.
Most of the time was spent getting emacs setup the way I like it (and
getting used to the MAC keyboard).

I'm still working on that hello world.  I think I've got the ajax side
working but that's highlighted the fact that the updates slot isn't
working correctly.
Permalink | Reply | 0 comments |
headers
Andy Chambers | 2 Apr 2008 11:40

undersold aspect of cells

Hey Kenny,

Here's an aspect of cells that I haven't seen highlighted before.

The html macros I made pretty much constitute a schema for html.  Not
only does it
concisely say what attributes are allowed on each element, but it gives you the
object model for dealing with instances of these elements, and a nice set of
macros for easily creating them.

A couple of "validation" defmethods and I think we've got something that may be
better even than relax-ng (the unstated assumption here is that its
not hard to be
better than xml schema).

I know that lispers generally aren't that fond of xml but I bet there
are a few that
use it on their day job (as someone who's day job involves dealing with CDISC's
various models it certainly is important for me).

Since you're using your blog as a lisp/cells advocacy platform, maybe you could
demonstrate this by creating a few macros that do a similar thing for
RSS.  I'd do
it myself but I don't have a blog (I've never really felt that I've
had enough to say
to merit it but I am starting to get itchy fingers these days, hence
the ramblings
on cells-devel).

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ken Tilton | 2 Apr 2008 16:02
Favicon

Re: undersold aspect of cells

Now there's a subject line to wake up to in the morning! :)

Andy Chambers wrote:
> Hey Kenny,
> 
> Here's an aspect of cells that I haven't seen highlighted before.
> 
> The html macros I made pretty much constitute a schema for html.  Not
> only does it
> concisely say what attributes are allowed on each element, but it gives you the
> object model for dealing with instances of these elements, and a nice set of
> macros for easily creating them.
> 
> A couple of "validation" defmethods and I think we've got something that may be
> better even than relax-ng (the unstated assumption here is that its
> not hard to be
> better than xml schema).

I took a look at relax-ng. Pretty scary. And fascinating, that XML has 
conditioned them such that relax-ng is considered concise. :) No Real 
Lisper would look at that stuff for more than two seconds before dashing 
off some macrology.

> I know that lispers generally aren't that fond of xml but I bet there
> are a few that
> use it on their day job (as someone who's day job involves dealing with CDISC's
> various models it certainly is important for me).

Ah, CDISC! I guess you saw my blog entry on that clinical trial 
management software I did in Lisp. Too bad we could not sell it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ken Tilton | 2 Apr 2008 19:53
Favicon

Re: undersold aspect of cells

Andy Chambers wrote:
> On Wed, Apr 2, 2008 at 3:02 PM, Ken Tilton <kennytilton <at> optonline.net> wrote:
> 
> 
>> Yes, Lispers do a lot of this stuff. I appreciate the kind words on Cells,
>>but I think in this case the credit goes to lisp and macrology -- I think
>>whenever a Lisper wraps X they do not just wrap it, they also add value by
>>making X easier to generate and harder to get wrong.
> 
> 
> I suppose so.  The only cells-specific bit is the way the xhtml is constantly
> kept in sync with the model.

And hopefully this combined with the Lispy hiding/generation of a lot of 
unpleasant wiring will translate into a substantial qualitative leap 
forward for RIA authoring, in turn leading to wilder and cooler RIAs.

But looking at my Algebra software I can see I let the ease of adding 
astonishing whiz-bang stuff definitely distracted me from Actually 
Shipping. Yes, it was easy, but then there is no end to the fun one can 
drawn into -- better to get the thing into people's hands and then 
easily implement things they actually ask me for.

Lesson learned. :)

Well, it took some hammer and chisel work but I have somewhat of a clean 
build of Hunchentoot, leaving we wondering how hard it would be to run 
against AllegroServe. :)

Do I need a new release of o/a?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andy Chambers | 3 Apr 2008 15:27

Re: undersold aspect of cells

>  Thanks. I built your stuff against aserve, and the build looks OK. I did
> change a few 'request' references to be 'req' which was used other places,
> hope that was right.

Ooops

>
>  (defun test-page-allegro (path resource-class)
>   (lambda (req ent)
>     (with-http-response (req ent)
>       (with-http-body (req ent)
>         (let ((root (or (cdr (get-cookie-values req "root"))
>                       (not (print "creating new web-app..."))
>                       (mk-web-app (:prefix path
>                                     :request (c-in req))
>                         (make-instance
>                             resource-class
>                           :fm-parent *parent*)))))
>           (set-cookie-header req
>             :name "root"
>             :value root)
>           (funcall (handler root)))))))
>
>  I also had a bunch of errors on RELOAD, but I am guessing that one is for
> hunchentoot.
>
>  I can start allegroserve OK and I have gone thru their tutorial and got
> those to work anyway.
>
>  I ran this function:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Goenninger | 3 Apr 2008 22:36
Picon

OpenAir: Where, what, how ? - I want it ...

Gentlemen (hi Andy, hi Kenny) -

would like to try this (don't feel like going to bed yet, so ...). RIA  
is what I need for my next bigger project: A Master Data Management  
system for a semiconductor manufacturing company.

If we can do this with a RIA based on Lisp, Cells, etc I'd be very  
excited to start in about 6 weeks with this project...

So - How, where, etc (I haven't been able to follow all the emails on  
this one) Any short intro, what to install etc available?

Thanks for info.

Best,
   Frank
Permalink | Reply | 1 comment |
headers
Andy Chambers | 3 Apr 2008 22:53

Re: OpenAir: Where, what, how ? - I want it ...

On Thu, Apr 3, 2008 at 9:36 PM, Frank Goenninger <frgo <at> mac.com> wrote:
> Gentlemen (hi Andy, hi Kenny) -
>
>  would like to try this (don't feel like going to bed yet, so ...). RIA is
> what I need for my next bigger project: A Master Data Management system for
> a semiconductor manufacturing company.

Its in a bit of a state at the moment because I've been trying to make
it work with
allegroserve.  I've fixed a couple of things but just noticed that
allegro doesn't have
sessions like hunchentoot.  That might be a bit of work.  I'll have to
check and see
what hunch does.

Do you have git?  If so, the best bet is to clone the repo at gitorious

git clone git://gitorious.org/hunchncells/mainline.git

If the version you get doesn't work, try successively checking out
previous versions by

git checkout HEAD^
git checkout HEAD^^
...

I've been committing even if stuff doesn't work and am going to use
tags to mark known
good points (of which there haven't really been many so far)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andy Chambers | 4 Apr 2008 12:08

openair progress

I got the js-escape working better last night and went on to try and
fill out the apropos demo but ran into
some difficulties.

I may need to rethink the macrology because when I put the following
into the web-apropos model, I just got
a list of progvs.

(mk-div ()
   (mk-ul ()
      (loop for func in (apropos-list "prog")
         collect (mk-li ()
                      (mk-text func)))))

Also, only changes to attributes are getting propagated to the updates
slot, not changes to kids.

In short, I'm still plugging away at this but I might be further away
from producing something
useful than it has seemed so far.  Sorry if I've got people's hopes
up.  Its just the typical time estimates of
an inexperienced programmer.

I'm going to go back to celtk and try to understand the way it does
things a bit better and see if there's
anything fundamental I've missed.  I should maybe code the apropos
thing in celtk to check how the user
code should look and make similar sort of code work for the web.

Here's a quick question.  If you want to make the kids of a mk-stack
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ken Tilton | 4 Apr 2008 15:46
Favicon

Re: openair progress

Andy Chambers wrote:
> I got the js-escape working better last night and went on to try and
> fill out the apropos demo but ran into
> some difficulties.
> 
> I may need to rethink the macrology because when I put the following
> into the web-apropos model, I just got
> a list of progvs.
> 
> (mk-div ()
>    (mk-ul ()
>       (loop for func in (apropos-list "prog")
>          collect (mk-li ()
>                       (mk-text func)))))

Don't feel bad, that is frequent "gotcha" even for loop veterans (and it 
is loop, not macrology, slowing you down (somewhat abbreviated):

(loop for x in (apropos-list "prog")
       collect (let ((x x)) ;; shadow the "x" abused by loop
                  (mk-text x)))

> Also, only changes to attributes are getting propagated to the updates
> slot, not changes to kids.

Hey, just send me the latest code and I'll figure it out. If you do not 
have aserve working, we can probably figure it out with a test harness 
that writes updates to the console.

I would make a top-level class:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ken Tilton | 4 Apr 2008 16:42
Favicon

Re: openair progress

More thoughts...

Andy Chambers wrote:
> I'm going to go back to celtk and try to understand the way it does
> things a bit better and see if there's
> anything fundamental I've missed.  I should maybe code the apropos
> thing in celtk to check how the user
> code should look and make similar sort of code work for the web.

That's a good idea, btw. A bit of work but I guess all the widgets are 
there and it would be a good learning experience. But first send me a 
zip of your latest/greatest so I can stare at it in parallel.

> 
> Here's a quick question.  If you want to make the kids of a mk-stack
> dependant on some other field in celtk,
> do you have to explicitly (make-instance 'stack :kids (c? ...) or
> should you still be able to use (mk-stack () ...)

As I said, that should work and a very quick glance at the example you 
sent last time looks reasonable, so send me what you have now and we can 
sort it out pretty quickly.

One general pointer, to be remembered especially when nothing seems to 
be working: always call cells-reset at the start of any test. It's a 
long story, but there is a global *stop* that gets set when things go 
wrong that cells code checks before doing anything, as a way of getting 
the thing to actually stop in a situation where a process keeps feeding 
us events even after we have backtraced, putting us in a loop as we try 
to handle the new events and backtrace again.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane