headers
Henrik Sarvell | 2 Apr 2009 02:33
Picon
Gravatar

Re: Cookie question

It's been a long time and I've finally had some time to revisit this
code, if I recall correctly I had it kind of working last time with
the *Cookies global as per the instructions in the prior post by Alex,
however when I run the application with the newest pico I get nowhere,
I don't know if something new has been introduced but I've been
following the discussions and I don't think so, but I'm not 100% sure,
hence this post.

This is what the relevant code looks like at the moment:

(de signin ()
   (app)
   (action
      (rss-html
         (form NIL
            (<table> NIL NIL NIL
               (<row> NIL "Username"  (gui 'uname '(+TextField) 10))
               (<row> NIL "Password"  (gui 'pwd   '(+PwField)   10))
               (<row> NIL
                  (gui '(+Button) "Login"
                     '(let Uid 1118474715114943738 # (chkLogin (val>
(: home uname)) (val> (: home pwd)))
                         (if Uid
                            (prog
                               (cookie 'uid Uid)
                               (setq *Cookies (cons 'uid Uid))
                               (redirect (pack *Domain " <at> desktop")))
                            (err "Could not login.")))))
               (<row> NIL (<href> "Sign Up" " <at> register")))))))
(Continue reading)

Permalink | Reply | 7 comments |
headers
Tomas Hlavaty | 2 Apr 2009 10:01
Picon
Favicon

Re: Cookie question

Hi Henrik,

> (cookie 'uid Uid)
> (setq *Cookies (cons 'uid Uid))
> (redirect (pack *Domain " <at> desktop")))

The problem is that 'redirect' does not set the cookies (see the
previous discussion and  <at> lib/http.l code for 'redirect', 'httpStat'
and 'httpHead').

Also, you do not need (setq *Cookies (cons 'uid Uid)) because *Cookies
is only for cookies received, not the ones being sent ("*Cookies"
internal to  <at> lib/http.l is used for that which is set by 'cookies'
function).

> I don't know if something new has been introduced but I've been
> following the discussions and I don't think so, but I'm not 100% sure,
> hence this post.

nothing has been changed in this area as far as I am aware.

We discussed this issue recently (see "cookies & redirect fix" thread)
but there did not seem much demand for fixing this in the official
distribution (I seemed to be the only one using cookies;-).  Maybe now
is the right time to go ahead with the fix?

I would suggest putting this in  <at> lib/http.l:

(de cookie  <at> 
   (let At (rest)
(Continue reading)

Permalink | Reply | 6 comments |
headers
Tomas Hlavaty | 2 Apr 2009 10:20
Picon
Favicon

Re: Status of 64 picoLisp

Hi Alex,

> However, I am aware of the fact that in picoLisp the printing of
> numeric results is often much more expensive than the actual
> calculations, due to the conversions necessary for the decimal base.

> If I take out the final (prinl Y) from gmp-test2.l, I get:
> It makes a considerable difference.

Interesting, it does not seem to make much difference with the C
version when I take the final 'printf' out of the C code.

> So I believe that for practical uses, where processing does not
> consist solely of arithmetics, the overhead will be negligible, and
> not justify extra efforts.

Yes, I haven't got any issues with bignum performance in picolisp;-)
We are not using picolisp to compute Mersenne prime numbers
http://www.mersenne.org/ after all:-D

Cheers,

Tomas
--

-- 
UNSUBSCRIBE: mailto:picolisp@...?subject=Unsubscribe
Permalink | Reply | 6 comments |
headers
Henrik Sarvell | 2 Apr 2009 10:38
Picon
Gravatar

Re: Cookie question

Thanks Tomas, yes I'm aware of that thread and will try it out.

I could've sworn though that I had it working somehow but I can't
remember anymore, could be that I've lost the working version because
I can't tell the difference anymore.

/Henrik

On Thu, Apr 2, 2009 at 10:01 AM, Tomas Hlavaty <kvietaag@...> wrote:
> Hi Henrik,
>
>> (cookie 'uid Uid)
>> (setq *Cookies (cons 'uid Uid))
>> (redirect (pack *Domain " <at> desktop")))
>
> The problem is that 'redirect' does not set the cookies (see the
> previous discussion and  <at> lib/http.l code for 'redirect', 'httpStat'
> and 'httpHead').
>
> Also, you do not need (setq *Cookies (cons 'uid Uid)) because *Cookies
> is only for cookies received, not the ones being sent ("*Cookies"
> internal to  <at> lib/http.l is used for that which is set by 'cookies'
> function).
>
>> I don't know if something new has been introduced but I've been
>> following the discussions and I don't think so, but I'm not 100% sure,
>> hence this post.
>
> nothing has been changed in this area as far as I am aware.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexander Burger | 2 Apr 2009 12:59
Picon

Re: Cookie question

Hi Tomas and Henrik,

ok, ok, now as there is such a _huge_ demand for cookies ;-)

I was always reluctant to include any cookie support at all, as the http
and form frameworks are designed to work without them, and I privately
consider cookies a bad design issue.

> (de cookie  <at> 
>    (let At (rest)
>       (if (assoc (car At) "*Cookies")
>          (con  <at>  (cdr At))
>          (push '"*Cookies" At) ) ) )

I would suggest a slight modification:

   (de cookie  <at> 
      (if (assoc (next) "*Cookies")
         (con  <at>  (rest))
         (push '"*Cookies" (cons (arg) (rest))) ) )

This needs one 'cons' less (in the (rest) calculation), but should
otherwise be equivalent.

> (de httpCookie (K V P E D S H)
>    (prin "Set-Cookie: " (ht:Fmt K) "=" (ht:Fmt V) "; path=" (or P "/"))
>    (when E (prin "; expires="  <at> ))
>    (when D (prin "; domain="  <at> ))
>    (when S (prin "; secure"))
>    (when H (prin "; HttpOnly"))
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alexander Burger | 2 Apr 2009 13:09
Picon

Re: Status of 64 picoLisp

Hi Tomas,

> Interesting, it does not seem to make much difference with the C
> version when I take the final 'printf' out of the C code.

That's why I suspect that there might be a way to speed it up.

On the other hand, bignum packages in C usually work with fixed length
arrays (as opposed to linked lists of cells in picoLisp), which make
things easier, and a lot more efficient. The picoLisp solution stays
with the philosophy "no limits", despite the fact that bignums
above a certain size (a few thousand digits?) make no sense.

Cheers,
- Alex
--

-- 
UNSUBSCRIBE: mailto:picolisp@...?subject=Unsubscribe
Permalink | Reply | 2 comments |
headers
Randall Dow | 2 Apr 2009 13:21
Picon

Re: Status of 64 picoLisp

Hi Alex,

I should have sent this yesterday on April 1 - but it is true!

For some people, a 11,185,272 digit number is very interesting ;-)

http://www.mersenne.org/

Maybe they should use picolisp.....

Cheers,
- Rand

On Thu, Apr 2, 2009 at 1:09 PM, Alexander Burger <abu@...> wrote:
> Hi Tomas,
>
>> Interesting, it does not seem to make much difference with the C
>> version when I take the final 'printf' out of the C code.
>
> That's why I suspect that there might be a way to speed it up.
>
> On the other hand, bignum packages in C usually work with fixed length
> arrays (as opposed to linked lists of cells in picoLisp), which make
> things easier, and a lot more efficient. The picoLisp solution stays
> with the philosophy "no limits", despite the fact that bignums
> above a certain size (a few thousand digits?) make no sense.
>
> Cheers,
> - Alex
> --
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alexander Burger | 2 Apr 2009 14:17
Picon

Re: Status of 64 picoLisp

Hi Randall,

> For some people, a 11,185,272 digit number is very interesting ;-)

You are very right. However, for such a specialized calculation even I
would not use picoLisp. :-)

Cheers,
- Alex
--

-- 
UNSUBSCRIBE: mailto:picolisp@...?subject=Unsubscribe
Permalink | Reply | 0 comments |
headers
Henrik Sarvell | 2 Apr 2009 18:14
Picon
Gravatar

Re: Cookie question

The only reason I'm opting for the cookie solution is that the current
session logic is using ports and there are not an unlimited amount of
ports, I don't like that, furthermore it seems overkill for what I
want to do here where I only want to use the current (app) logic in
the sign up form and the registration form.

What I really want is something like the way it works in PHP+Apache
where the session information is propagated with the help of a php
session id, either through a cookie or the url. I will rework the
current logic which stores the id in the user permanently, when I get
this to work.

The whole process is completely abstracted from the programmer, ie in
the url case one does not have to do anything special as the whole
thing is processed before your script starts (in http.l for instance
in our case)  and the session data is available in the $_SESSION
associative array. The only thing you have to do is to set a flag to
use cookies or not, if not then the url option is used.

And if I remember correctly php_sessid is not available in the $_GET
array either which contains the url variables, hence the abstraction I
mention above, the id can however be retrieved with a global function.

So Alex, how does the url option compare to the cookie solution, is it
equally unpalatable?

/Henrik

On Thu, Apr 2, 2009 at 12:59 PM, Alexander Burger <abu@...> wro=
te:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alexander Burger | 2 Apr 2009 18:48
Picon

Re: Cookie question

Hi Henrik,

> The only reason I'm opting for the cookie solution is that the current
> session logic is using ports and there are not an unlimited amount of
> ports, I don't like that, furthermore it seems overkill for what I
> ...
> So Alex, how does the url option compare to the cookie solution, is it
> equally unpalatable?

I'm not sure. As always, it depends ;-)

The current framework is intended for applications where a certain
amount of users is reading and writing the database concurrently. In
such a case, the limited amount of ports is never a problem, because the
system would not be able to handle, say, 30000 users at the same time.
If there were so many, we would need to distribute the app across
several hosts anyway.

If, on the other hand, the user interactions are just short single-shot
requests, it is also not a problem, as no ports are allocated at all.

So I never had (and also cannot imagine at the moment) a situation where
one of these two approaches were not satisfying.

It might be worth, though, to consider writing separate frameworks for
other types of applications. I would not try to overload the current
system to serve any conceivable situation. The purpose of picoLisp is to
make it easy writing lightweight vertical solutions, instead of heavy
all-purpose monsters.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane