Another recap after doing stracing, it seems a "serious" application
needs to be started like this: ./p main.l -go -wait >> rss-reader.log
2>&1 &

I wasn't doing that and my site was subsequently visited by bots
(hence the random feeling time factor that was involved) which
triggered output on stderr, which I hadn't directed to a log file,
which in turn somehow tripped up the redirection in picolisp, hence
the strange problems I experienced.

After starting with the above line I haven't been able to reproduce the pro=

Maybe Alex can elaborate?


On Mon, Nov 30, 2009 at 11:17 PM, Henrik Sarvell <> wrote=
> To recap where we stand after the IRC discussion today.
> I've tried using (url) but it breaks in exactly the same way as
> (redirect), so does (redirect) immidiately followed by (bye).
> On Mon, Nov 30, 2009 at 8:50 AM, Henrik Sarvell <> wrot=
>> Maybe this information will help a little. I am logged in at the
>> moment (ie having a proper cookie), in Firefox and the app loads
>> properly.
>> I start Galeon (a mozilla based browser) and since I don't have a
>> cookie there I get the login form, however upon submitting it I'm not
>> redirected to /@desktop but to
>> :46953/402748303615582...@start?*menu=3d+0&*Tab=3D+1&*ID=3D
>> When I subsequently try to go to @desktop manually, I get the redirect
>> headers in the result which means (usrQuit) was called:
>> (de desktop (Uid)
>> =A0 (rss-html
>> =A0 =A0 =A0(if (; (usrQuit) feeds)
>> =A0 =A0 =A0 =A0 (<script> "loadPopularWords('getPopularWords', 0, 'repla=
>> =A0 =A0 =A0 =A0 (prin "Import some stuff and you will see something here=
>> (de usrQuit ()
>> =A0(let Usr (getUsr)
>> =A0 =A0 (unless Usr (redir "@logout")) Usr))
>> However this is what I get in the content area:
>> HTTP/1.0 303 See Other
>> Server: PicoLisp
>> Location:
>> Content-Type: text/html
>> Import some stuff and you will see something here.
>> This is the headers and the error message so I suppose the redirect
>> called by (usrQuit) isn't working properly.
>> Meanwhile I'm able to use the application properly in Firefox where I
>> do have a cookie, I think I'm going to try to investigate a little by
>> doing a redirect in (start), then I would know if the problem appears
>> with (redirect) even though I have a cookie.
>> The picolisp I'm using is a 32bit version compiled on a 64bit machine,
>> I hope this doesn't have anything to do with it.
>> /Henrik
>> On Sun, Nov 29, 2009 at 5:30 PM, Alexander Burger <> =
>>> On Sun, Nov 29, 2009 at 10:40:05AM +0100, Henrik Sarvell wrote:
>>>> Yes the (patch _htHead '(format (car @H)) 0) line didn't help in the e=
nd :(
>>> OK, so we know at least that it is not a HTTP/1.1 problem.
>>>> 1.) Started it and tried to break it by logging out and in a few times
>>>> from different browsers.
>>>> 2.) Went home a few hours later and tried from home and got it right a=
>>> Could it be that it has to do with some cookie timeout, or cookie vs.
>>> client-IP mismatch? If it is not a race condition or some other
>>> heisenbug, you should try to trace it down, to find out exactly where
>>> things go wrong. I would start with -traceAll with stderr redirected to
>>> a file like
>>> =A0 ./dbg login-test/main.l-- -traceAll -g 2>errlog
>>> Cheers,
>>> - Alex
>>> --

Reply via email to