Re: in the spirit of RosettaCode...

[Alexander Burger]

On Tue, Feb 28, 2017 at 05:21:52PM +0100, Alexander Burger wrote:
> > In the spirit of RosettaCode, may I present http://www.todobackend.com/ ?
> 
> Seems I should give it a try :)
> 
> I don't understand the full extent of the task yet, but could it be something

To be correct, I don't understand it at all!

Is the only "spec" a bunch of JavaScript sources? I don't feel like wanting to
analyze that, sorry!

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Scaled division and sqrt

[Lindsay John Lawrence]

allbase   -->  tankfeeder / exercism-io / a-f.l

/Lindsay


On Tue, Feb 28, 2017 at 3:41 AM, Danilo Kordic  wrote:
>> If you are going to use a list, could also just put the 'scale' in a property
>> of the list?
>
>   I wouldn't call it a propert to avoid confusion with PicoLisp `prop'erties.
>
>   I couldn't find `allbase'.
>
>   I had [[https://en.wikipedia.org/wiki/Algebraic_data_type][Algebraic
> DataTypes]]
> in mind, just like fractions.
>
> (= (Float B S E)
>(* S (** B E)) )
>
>
>   ``(314 E -2)'' looks like
> [[https://en.wikipedia.org/wiki/Scientific_notation][Scientific
> notation]].
> And wouldn't cause an error in PicoLisp.
>
>   Current implementation of PicoLisp numbers is also a linked list:
> [path "@doc64/structures"].  Too bad they can not be manipulated like any 
> other
> list.  Base is (** 2 64).
>
>   [[https://en.wikipedia.org/wiki/Quote_notation][Quote notation]]: If we 
> allow
> circular reference in the `Num' structure it will result in a subset of
> rational numbers.  Arithmetic Shift, `AS', will give the rest.
> ``I mean, how hard could it be?  ''
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Scaled division and sqrt

[Lindsay John Lawrence]

Hi,

I practiced a bit more with the built-in functions...

https://github.com/thinknlive/picolisp-gosper.git

/Lindsay
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: in the spirit of RosettaCode...

[Alexander Burger]

On Tue, Feb 28, 2017 at 05:21:52PM +0100, Alexander Burger wrote:
> Hi Loyall,

Oops! I mean "Hi Dave!" :)
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: in the spirit of RosettaCode...

[Joe Bogner]

Hi David, Alex

Not exactly the same thing (both front-end and back-end)... I created a
todo example last year: https://github.com/joebo/pil-mithril-todo. This is
not a pure pil way since it uses a javascript framework - so it could be a
PicoLisp / Mithril.js combo. It would be nice to see a pure pil way. If
someone else wants to take it on, they might be able to use what I have as
a starting point (feel free!)

To see my example: I restarted the example at http://csilo.com:8088/
username: admin , password: admin ... It takes a few seconds to log in due
the bcrypt hashing

Thanks,
Joe

On Tue, Feb 28, 2017 at 11:21 AM, Alexander Burger 
wrote:

> Hi Loyall,
>
> > In the spirit of RosettaCode, may I present http://www.todobackend.com/
> ?
>
> Seems I should give it a try :)
>
> I don't understand the full extent of the task yet, but could it be
> something
> similar to http://picolisp.com/wiki/?mindbgui with some modifications and
> extensions?
>
> ♪♫ Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: in the spirit of RosettaCode...

[Alexander Burger]

Hi Loyall,

> In the spirit of RosettaCode, may I present http://www.todobackend.com/ ?

Seems I should give it a try :)

I don't understand the full extent of the task yet, but could it be something
similar to http://picolisp.com/wiki/?mindbgui with some modifications and
extensions?

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

in the spirit of RosettaCode...

[Loyall, David]

In the spirit of RosettaCode, may I present http://www.todobackend.com/ ?

Perhaps one of you skilled picolisp folks could submit a new implementation to 
their growing list.

Cheers,
--Dave
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Scaled division and sqrt

[Danilo Kordic]

> If you are going to use a list, could also just put the 'scale' in a property
> of the list?

  I wouldn't call it a propert to avoid confusion with PicoLisp `prop'erties.

  I couldn't find `allbase'.

  I had [[https://en.wikipedia.org/wiki/Algebraic_data_type][Algebraic
DataTypes]]
in mind, just like fractions.

(= (Float B S E)
   (* S (** B E)) )


  ``(314 E -2)'' looks like
[[https://en.wikipedia.org/wiki/Scientific_notation][Scientific
notation]].
And wouldn't cause an error in PicoLisp.

  Current implementation of PicoLisp numbers is also a linked list:
[path "@doc64/structures"].  Too bad they can not be manipulated like any other
list.  Base is (** 2 64).

  [[https://en.wikipedia.org/wiki/Quote_notation][Quote notation]]: If we allow
circular reference in the `Num' structure it will result in a subset of
rational numbers.  Arithmetic Shift, `AS', will give the rest.
``I mean, how hard could it be?  ''
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Workers for multicore processing (Question and RFC)

[Alexander Burger]

Hi Petr,

> I believe modern Linux systems have much higher than 1024 file descriptor
> per process limits.

Right. However Joh-Tob was talking about the number of child processes.

There is a limit in PicoLisp in how many child processes can be spawned with
(fork), caused by the size of an 'fd_set' structure for the select() system
call.

(fork) creates two pipes to the parent for each child process. The limitation
can be overcome with http://software-lab.de/doc/refD.html#detach for child
processes who do not depend on interprocess communication.

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Workers for multicore processing (Question and RFC)

[Robert Wörle]

Am 28.02.2017 um 12:04 schrieb Petr Gladkikh:
I believe modern Linux systems have much higher than 1024 file 
descriptor per process limits. E.g. on my system

$ uname -srv
Linux 4.4.0-64-generic #85-Ubuntu SMP Mon Feb 20 11:50:30 UTC 2017
$ cat /proc/sys/fs/file-max
2013532
And you can adjust this limit to your requirements.



Sorry to jump in here out of my closet,  but i think this fact needs 
some clarification. My research came up with the following:


/proc/sys/fs/file-max  is not the "per" process limit , rather then the 
overall limit of the system

This can also be controlled by writing into  /proc/sys/fs/file-max.

to get to know the hardlimit per process you use
ulimit -Hn
soft limit is showed via
ulimit -Sn

as the ulimit manpage states, the hard limit acts as a ceiling for the 
softlimit , which can be controlled.



So we have the per-proccess limitations, but as soon as we fork() and 
recieve a new pid, we can have yet another set of fds , right ?


cheers rob

Re: Workers for multicore processing (Question and RFC)

[Petr Gladkikh]

I believe modern Linux systems have much higher than 1024 file descriptor
per process limits. E.g. on my system
$ uname -srv
Linux 4.4.0-64-generic #85-Ubuntu SMP Mon Feb 20 11:50:30 UTC 2017
$ cat /proc/sys/fs/file-max
2013532
And you can adjust this limit to your requirements.

2017-02-25 12:26 GMT+01:00 Joh-Tob Schäg :

> There are limits on how many processes can exist at the same time and
> having more 'later processes than cores is wasteful and Linux only allows
> for 1024 file descriptors per process.
> ? (for N 1 (later (cons) (* N N)))
> !? (pipe (pr (prog (* N N
> Pipe error: Too many open files
> ? N
> -> 339
>
> Is there some "worker" implementation which keeps a queue of task to do
> and creates N worker processes which take tasks from the queue when they
> are finished?
>
> Ideas:
> Task would be copy of environment + function + values to apply the
> function too. There would be some optimization potential in case the
> function and environment is static, or reseted each time to a constant
> value but it should be possible to fetch a copy of the current environment
> to.
> Such a pool of workers is best represented with a symbol on which certain
> functions are applied which are may stored inside the symbol. This could be
> archived with some overhead with the picolisp object system when compared
> to a manual implementation since the worker queue should be accessible fast
> and putting it in val of the symbol would be the easiest way to achieve
> that.
>
> Further thoughts:
> It might be wise to give the possibility to register a callback on the
> return value.
> This would allow to make things more efficient.
> For example:
>
> (prog1  # Parallel background calculation of square numbers
>(mapcan '((N) (later (cons) )) (range 1 100))
>(wait NIL (full @)) )
>
> could be:
>
> (pool "squares.db")
> (with-workerpool W '((workers . 2) (callback . '((R) (put *DB (car R) (cadr 
> R ))
>(mapcar '((N) (add_task 'W '((N) (cons N (* N N))) N ) (range 1 100)) )]
>
> #Normally the with-workerpool should not finish until the queue is empty
>
> How ever it should also be possible to do something like that:
>
>
> (with-workerpool W '((callback . NIL) (return . nil) (output . "+file") (wait 
> . NIL))
>(for X 1000
>   (add_task  'W '((N) (ifn (= N (apply '* (prime-factors N)))
>  (print N))) X ] # workers run in background main thread can continue
>
> This usage may seem overly complex at first and the proposed interface is 
> horrible. However i think that such an library could be an valuable addition 
> to picolisp.
>
> Lets discuss the idea itself, your proposals for the interface and the 
> implementation.
>
>


-- 
Petr Gladkikh

Re: French localization

[Alexander Burger]

On Tue, Jan 24, 2017 at 07:49:43AM +0100, Alexander Burger wrote:
> Dear PicoLispers,
> 
> is anybody able and interested to do the French localization of PicoLisp?

How is the situation? Does anybody have good news? ;)

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe