Re: picoWiki

[konrad Zielinski]

Hi,


I think Picowiki could use a title index. As somthing that is
automatically generated

regs

Konrad.



2008/10/13 Tomas Hlavaty <[EMAIL PROTECTED]>:
>> I will have to implement some picoWiki markup for html anchor for
>> this.
>
> Anchors is a bad idea actually.  It does not go well with the wiki
> style links and page management.  Also, using anchors leads to long
> documents which are pain to edit in a wiki.  Every topic worth
> referencing should have its own page.
>
>> i.e. create a page classes, list there classes similar to the
>> reference for functions and refer markup there.
>
> I created http://logand.com/picoWiki/classes page with list of
> classes.  I started documenting a few,
> e.g. http://logand.com/picoWiki/+Blob so feel free to add more stuff
> if you feel other could benefit from your knowledge.
>
> Cheers,
>
> Tomas
> --
> UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
>
-- 
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]

Re: Variable number of arguments in SVG functions

[Tomas Hlavaty]

Hi Alex,

maybe it could become part of lib/xml.l?  I would use it as it looks
more convenient than building list for 'xml' function in some cases.

Thanks,

Tomas
-- 
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]

Re: Asyncronous IO

[Tomas Hlavaty]

Hi Konrad,

> would you be able to tell me what all the arguments to the functions
> in nb.l actually are. I mean what are they used for not just data
> type, as I can't say i fully follow it beyound that the first argument
> to rdx is a list beign used as a buffer.

I put the description into picoWiki at
http://logand.com/picoWiki/non-blocking

Also, see http://logand.com/sw/nb/nb-server.l for how to use them.

Cheers,

Tomas
-- 
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]

Re: Some questions about the Pico Lisp Interpreter

[Tomas Hlavaty]

Hi all,

>> 1) Does the Interpretor do any kind of tail call optimisation, I
>
> No, not at all.
>
> As far as I can see, this is not easy to implement in an efficient way.
> The interpreter would have to detect tail recursion at runtime, which
> takes much more than time than simply executing the call/return. Each
> function must inspect itself, just to find those (extremely few) cases
> of tail recursion.
>
> Above that, it would violate some basic principles of picoLisp. Trying
> to be clever behind the scenes, doing things the programmer did not
> explicitly specify, losing simplicity and what-you-see-is-what-you-get.
>
> Tail recursion is nothing more than a simple loop. So we might better
> write directly what we mean, using 'while', 'for', 'loop' etc.

there is a way around not having tail call optimisation even though it
is not very intuitive.  I just put some code on
http://logand.com/picoWiki/trampoline so feel free to comment on it.

Thanks,

Tomas
-- 
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]

Re: Asyncronous IO

[konrad Zielinski]

Hi Thomas,

Now that I can run your async reading and writing code.

would you be able to tell me what all the arguments to the functions
in nb.l actually are. I mean what are they used for not just data
type, as I can't say i fully follow it beyound that the first argument
to rdx is a list beign used as a buffer.

regs

Konrad

2008/10/10 Tomas Hlavaty <[EMAIL PROTECTED]>:
> Hi Alex,
>
>> The drawback of implementing such a fully non-blocking system will
>> be that the present separation of event generation (select) and data
>> processing (read) cannot be held up any longer, and a completely
>> different application flow is required.
>
> yes, indeed.
>
> I attach a simple non-blocking echo server.  There are some functions
> in C just to get the C read & write functions and some blocking stuff
> up to the picolisp level.  Then the echo server waits for events on a
> socket and writes back what it read.
>
> Conceptually it should not block, I am not sure how to test it though.
> Any ideas?
>
> There are some things that could be done better, like:
>
> - the buffer could be circular and support for this could be in the C
>  functions rdx and wrx.
>
> - buffer could be local for the sockets, so 'callback' should be a
>  closure...  I guess I would have to use 'job' but that's next lesson
>  I have to look at:-)
>
> It might be nice to build some kind of abstraction above this low
> level, non-blocking code.  Maybe to implement continuations to
> abstract away the event driven code.  Not sure how difficult it would
> be in picolisp.
>
> There should really be -m32 switch in the 'gcc' function.  It would
> also be useful if it would be possible optionally switch on -g without
> having to modify the gcc.l file.
>
> Cheers,
>
> Tomas
>
>
> (cd (pack (sys "HOME") "/picolisp"))
> (load (pack (sys "HOME") "/src/picolisp/nb.l"))
>
> # (out "/tmp/a" (wrx '(1 2 3 4) 4))
> # (out "/tmp/a" (wrx '(1 2 3 4) 3 1))
>
> # (setq *B (need 5))
> # (in "/tmp/a" (rdx *B 3))
> # (in "/tmp/a" (rdx *B 2 3))
> # *B
>
> # non-blocking echo server
>
> (setq *N 5) # try bigger buffer;-)
> (setq *B (need *N))
> (setq *I 0)
> (setq *J 0)
>
> (set 'EAGAIN (eagain))
>
> (de _rdx (Sock)
>   (in Sock
>  (let? N (rdx *B (- *N *I) *I)
> (when (gt0 N)
>(inc '*I N))
> N)))
>
> (de _wrx (Sock)
>   (out Sock
>  (let? N (wrx *B (- *I *J) *J)
> (when (gt0 N)
>(inc '*J N))
> N)))
>
> (de callback (Sock)
>   (let End NIL
>  (prinl "callback " Sock " J=" *J " I=" *I " N=" *N)
>  (block Sock NIL) # first time would be enough
>  (unless End
> (let N (_rdx Sock)
>(prinl "  read " N)
>(unless (or (gt0 N) (= N 'EAGAIN))
>   (setq End (cons rd N)
>  (unless End
> (let N (_wrx Sock)
>(prinl "  written " N)
>(unless (or (gt0 N) (= N 'EAGAIN))
>   (setq End (cons wr N)
>  (when End
> (prinl "  finish")
> (task Sock)
> (close Sock))
>  (when (<= *I *J)
> (prinl "  rotate J=" *J " I=" *I " N=" *N)
> (setq *I 0)
> (setq *J 0))
>  (prinl "end " Sock " J=" *J " I=" *I " N=" *N)))
>
> (task (port ) # Listen on port 
>   (when (accept @)   # A connect arrived
>  (task @ # Install another task on this socket
> Sock @   # Keep the socket in the task's env
>(callback Sock) ) ) )
>
>
-- 
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]

Re: Status of 64 picoLisp

[konrad Zielinski]

THe interesting thing will be handling C structs. As almost every
interesting C API makes heavy use of them.

My wish list would be to be able to create them from inside pico and
use them just like a native object. IE pass them arround as the values
of symbols and use 'get' and
'put' to read and write their fields.

regs

Konrad


2008/10/17 Alexander Burger <[EMAIL PROTECTED]>:
> Hi Eugene,
>
> thanks for your comments! :-)
>
>> It would appear that you could claim portability to any CPU. Afterall,
>> porting should only require writing a translator module for the
>
> Well, not really any CPU. It should have a 64 bit word size, with 8 bits
> per byte. And if it is a CPU that requires heavy instruction reordering,
> the translator module might be difficult to implement.
>
>> different instruction set. If anyone wants JVM or CLI then that should
>> be what needs rewriting.
>
> Yes, this would be an interesting exercise.
>
>
>> As for the gcc.l, as.l, and the generic call to external libraries, I
>> have a suggestion:
>> ...
>> 1. Shared libraries written in the normal manner (dlopen/dlsym
>> ...
>> A manifest file for each DL which lists the entry points, argument types and 
>> return value type.
>
> I'm thinking of something similar. Not with a separate manifest file,
> but with some encoding conventions in an s-expression, specifying the
> types and layouts of arguments and return values.
>
> This would allow to call almost any C function in an external library on
> the fly. The calling mechanism itself would be the same as it is in
> picoLisp-2.x, just with some glue functionality interpreting the encoded
> information, and preparing the arguments and return values
> appropriately.
>
> A slight disadvantage compared to your proposal is some runtime
> overhead, though. Let's see ...
>
> Cheers,
> - Alex
> --
> UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
>
-- 
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]

Re: Cookie question

[Alexander Burger]

On Mon, Oct 20, 2008 at 11:26:00PM +0700, Henrik Sarvell wrote:
> Simply manually navigating to http://localhost:8080/@desktop after
> this displays all the correct results. It seems I can not set the
> cookie and simply retrieve its contents through the use of *Cookies in
> the same request?

The function 'cookie' puts the keys and values into the transient symbol
"*Cookies" (internal to "lib/http.l"), to be inserted into the next HTTP
header. The global variable *Cookies, on the other hand, is filled
during the GET or POST request.

Do you still need to use cookies internally, once you passed the long
password id to the other server?


> Or does the problem have to do with the fact that
> I'm redirecting from a forked process since the sign in form is using
> the GUI stuff?

This should not matter. The redirection simply sends a page to the
browser that tells him another address.

Cheers,
- Alex
-- 
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]

Re: Variable number of arguments in SVG functions

[Alexander Burger]

On Mon, Oct 20, 2008 at 04:21:31PM +0100, Tomas Hlavaty wrote:
> That's nice.  It could even be:
> 
> (de  Prg
>(prin "<" (pop 'Prg))
>(while (atom (car Prg))
>   (prin " " (pop 'Prg) "=\"" (eval (pop 'Prg) 1) "\"") )
>(prin ">")
>(run Prg)   # the text, or other elements
>(prinl "") )
> 
> ( text id 123  dx (+ 3 4)  dy (* 3 4) 
>(prin "No font and color arguments yet") )  

Yes, that's even better.


In addition, to make it more robust, we should

1. Check for an empty body (avoid an infinite loop):

  (while (and Prg (atom (car Prg)))

2. Run the body in the binding environment of the caller:

  (run Prg 1)


Cheers,
- Alex
-- 
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]

Re: Cookie question

[Henrik Sarvell]

Since redirect won't set the cookie I tried a workaround:

(de signin ()
   (app)
   (action
 (html
..
(gui '(+Button) "Login"
   '(if (chkLogin (val> (: home uname)) (val> (: home pwd)))
   (redirect (pack *Domain "@desktop?+" @))
   (err "Could not login.")))
..

This correctly routes to
http://localhost:8080/@desktop?+1118474715114943738 and I set the
cookie in (desktop) instead with the help of the passed user id.
However this is what is shown on the page I redirect to:

HTTP/1.0 302 Found Server: PicoLisp Location: @signin Content-Type:
text/html Content-Length: 81
Found
HTTP/1.0 302 Found Server: PicoLisp Location: @signin Content-Type:
text/html Content-Length: 81
Found
Read all

That last "Read all" is printed if everything went according to plan,
however no articles were fetched as I would expect, otherwise they
would show underneath Read all.

Simply manually navigating to http://localhost:8080/@desktop after
this displays all the correct results. It seems I can not set the
cookie and simply retrieve its contents through the use of *Cookies in
the same request? Or does the problem have to do with the fact that
I'm redirecting from a forked process since the sign in form is using
the GUI stuff?

/Henrik
-- 
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]

Re: Variable number of arguments in SVG functions

[Tomas Hlavaty]

> How about the following?
>
>(de  Prg
>   (prin "   (while (atom (car Prg))
>  (prin " " (pop 'Prg) "=\"" (eval (pop 'Prg) 1) "\"") )
>   (prin ">")
>   (run Prg)   # the text, or other elements
>   (prinl "") )
>
> Then you could write
>
>: (  id 123  dx (+ 3 4)  dy (* 3 4) 
>   (prin "No font and color arguments yet") )  
>No font and color arguments yet

That's nice.  It could even be:

(de  Prg
   (prin "<" (pop 'Prg))
   (while (atom (car Prg))
  (prin " " (pop 'Prg) "=\"" (eval (pop 'Prg) 1) "\"") )
   (prin ">")
   (run Prg)   # the text, or other elements
   (prinl "") )

( text id 123  dx (+ 3 4)  dy (* 3 4) 
   (prin "No font and color arguments yet") )  

:-)

Tomas
-- 
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]

Re: Variable number of arguments in SVG functions

[Alexander Burger]

Hi Jon,

> then the calls would very often have a lot of NIL arguments, which looks 
> rather ugly. Should I switch to property lists? Any suggestions?

How about the following?

   (de  Prg
  (prin "")
  (run Prg)   # the text, or other elements
  (prinl "") )

Then you could write

   : (  id 123  dx (+ 3 4)  dy (* 3 4) 
  (prin "No font and color arguments yet") )  
   No font and color arguments yet

Cheers,
- Alex
-- 
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]

Variable number of arguments in SVG functions

[Jon Kleiser]

Hi,

I've started some work on doing SVG graphics from Pico Lisp, and I've 
written a few functions that produce SVG elements. I try to do this 
more or less in the same way the HTML elements are done in 
lib/xhtml.l. Some SVG elements have just a small number of 
attributes, but others, like 'text', may have quite a few optional 
attributes. In my current  function I have not yet taken care 
of the "presentation attributes". It looks like this:


(de  (Id X Y Dx Dy Rotate TextLength LengthAdjust . Prg)
(prin "")
(run Prg)   # the text, or other elements
(prinl "") )

A simple call to this function may look like this:

( NIL "10%" "50%" NIL NIL NIL NIL NIL
(prin "No font and color arguments yet") )

If I should go on adding more presentation arguments for this 
function, then the calls would very often have a lot of NIL 
arguments, which looks rather ugly. Should I switch to property 
lists? Any suggestions?


Here are some useful SVG pages:




/Jon
--
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]