Re: modules?
I'm a total Lisp noob (and a very rusty programmer), but from OO (Java, et
al) there is (behind the scenes, i.e., preprocessor) name mangling. There's
also tagging stuff with a huge hash generated numbers. I say all this
because I'm hearing the need for uniqueness and anti-name-clash -- across
files and systems. Is that a correct assumption here? So when you call
"your" getBob function, some other code you're involved with doesn't think
that its (totally by chance also named) getBob function is meant. Am I on
the right track?
LB
On Mon, Feb 9, 2015 at 7:12 PM, wrote:
> Hi list
>
> > Could we cook up a convention?
>
> Pretext
> -
> In this context I assume "modules" is meant not in the sense of program
> design but in the sense of "software packages", a format to download/copy a
> piece of picoLisp code (maybe accompanied by other files, e.g. pictures)
> and insert it into your own picoLisp environment and/or picoLisp
> application and getting it running without further manual adaption.
>
> I see a potentially big advantage of such a formalized system, as it could
> greatly enhance picoLisp code reuse, and also work somewhat against the
> "Lisp Curse" [1] and the sometimes claimed "lack of libraries".
>
> But it must be designed very carefully, keeping it as simple and short as
> possible, keeping it free from any assumptions (about the picoLisp
> environment or the layout of a picoLisp application) besides the absolute
> bare necessary ones, so no restrictions are put on the kind of code and
> applications using it. This thing is a easy path to bloatware, and to my
> understanding the picoLisp philosophy is all about precluding bloat.
>
> So I see following problems:
> 1) identity: how to identify a module and all parts belonging to it?
> (uniquely and universal)
> 2) dependencies on other modules: how to verify if another module, which
> the current module depends on, is 'installed' (and functional) ?
> 3) versioning of modules?
> 4) upgrading/downgrading of a module version, also: being able to use
> multiple versions of a module in the same environment
> 5) name clashing, especially of picoLisp code/symbols/function names/class
> names/etcetera
> 6) lets assume modules are not only used to extend the picoLisp
> environment (e.g. stuff in "@lib/"), but also for applications and parts of
> applications - then there should probably a way to formulate which database
> schema / class definitions (and more!) a module requires/expects for the
> environment where it should run in.
> 7) documentation - how does the interested module user find out what a
> given module does and how does he/she decide if it solves his/her needs?
> 8) in which form would a module be distributed?
> 9) uniform method of error reporting, especially to spot the source of an
> error in a composition of modules
> 10) other problems?
>
> Oh, special question
> -
> we have package manager on OS (e.g., apt-get), now we have all this hip
> programming languages with one or even multiple package managers each,
> ruby, node.js (npm), python?, .net, java?, php (pear and another one) and
> many more.
>
> DO WE REALLY NEED TO CREATE ANOTHER ONE?
>
> Maybe we could come up with a small tool, which can take picoLisp code
> (and a bunch of files) and create a package to use with one of those
> existing module/package managers?
> I mean the question in the spirit of http://xkcd.com/927/
>
> My thoughts on solutions
> --
> (previous question ignored for the moment)
> Whenever I stumble on such common software design problems, I query the
> Wiki (that is the first original wiki, originally being a collection and
> discussion of Design Patterns).
> A first search [2] brings some nice results like "What is a module" [3]
> and especially the "Module Dependency Problem" [4] (that one we should
> definitively look at!)
> (I didn't study the Wiki entries entirely yet, so maybe there are better
> solutions mentioned there then what I think about below).
>
> I was pondering about similiar stuff before, mainly to find a good way to
> organize my own code.
> For the moment, I created a directory "tgs" in the picoLisp installation
> ("tgs" being a shortname for my personal framework).
> In this directory I have several directories for different topics, and
> within those I keep *.l-files.
> Examples:
> @tgs/log/log.l
> @tgs/time/duration.l
> @tgs/time/tz-offset.l
> @tgs/time/utc2local.l
>
> When I like to use a specific function I load the specific
> "function.l"-file. This can easily be done with (unless tz-offset.l (load
> "@tgs/time/tz-offset.l"))
> I try to keep the individual files as granular and small as possible,
> often having only one function defined in such a file, so I can load single
> individual functions and avoid loading anything I don't need.
>
> I also have directory "x" (for extra/external) where I put picoLisp code
> which is neither part of the standard distrib
Re: modules?
Hi list> Could we cook up a convention?Pretext-In this context I assume "modules" is meant not in the sense of program design but in the sense of "software packages", a format to download/copy a piece of picoLisp code (maybe accompanied by other files, e.g. pictures) and insert it into your own picoLisp environment and/or picoLisp application and getting it running without further manual adaption.I see a potentially big advantage of such a formalized system, as it could greatly enhance picoLisp code reuse, and also work somewhat against the "Lisp Curse" [1] and the sometimes claimed "lack of libraries".But it must be designed very carefully, keeping it as simple and short as possible, keeping it free from any assumptions (about the picoLisp environment or the layout of a picoLisp application) besides the absolute bare necessary ones, so no restrictions are put on the kind of code and applications using it. This thing is a easy path to bloatware, and to my understanding the picoLisp philosophy is all about precluding bloat.So I see following problems:1) identity: how to identify a module and all parts belonging to it? (uniquely and universal)2) dependencies on other modules: how to verify if another module, which the current module depends on, is 'installed' (and functional) ?3) versioning of modules?4) upgrading/downgrading of a module version, also: being able to use multiple versions of a module in the same environment5) name clashing, especially of picoLisp code/symbols/function names/class names/etcetera6) lets assume modules are not only used to extend the picoLisp environment (e.g. stuff in "@lib/"), but also for applications and parts of applications - then there should probably a way to formulate which database schema / class definitions (and more!) a module requires/expects for the environment where it should run in.7) documentation - how does the interested module user find out what a given module does and how does he/she decide if it solves his/her needs?8) in which form would a module be distributed?9) uniform method of error reporting, especially to spot the source of an error in a composition of modules10) other problems?Oh, special question-we have package manager on OS (e.g., apt-get), now we have all this hip programming languages with one or even multiple package managers each, ruby, node.js (npm), python?, .net, java?, php (pear and another one) and many more.DO WE REALLY NEED TO CREATE ANOTHER ONE?Maybe we could come up with a small tool, which can take picoLisp code (and a bunch of files) and create a package to use with one of those existing module/package managers?I mean the question in the spirit of http://xkcd.com/927/My thoughts on solutions--(previous question ignored for the moment)Whenever I stumble on such common software design problems, I query the Wiki (that is the first original wiki, originally being a collection and discussion of Design Patterns).A first search [2] brings some nice results like "What is a module" [3] and especially the "Module Dependency Problem" [4] (that one we should definitively look at!)(I didn't study the Wiki entries entirely yet, so maybe there are better solutions mentioned there then what I think about below).I was pondering about similiar stuff before, mainly to find a good way to organize my own code.For the moment, I created a directory "tgs" in the picoLisp installation ("tgs" being a shortname for my personal framework).In this directory I have several directories for different topics, and within those I keep *.l-files.Examples:@tgs/log/log.l@tgs/time/duration.l@tgs/time/tz-offset.l@tgs/time/utc2local.lWhen I like to use a specific function I load the specific "function.l"-file. This can easily be done with (unless tz-offset.l (load "@tgs/time/tz-offset.l"))I try to keep the individual files as granular and small as possible, often having only one function defined in such a file, so I can load single individual functions and avoid loading anything I don't need.I also have directory "x" (for extra/external) where I put picoLisp code which is neither part of the standard distribution nor made by me.Examples:@x/cyborgar/web.l/...@x/regenaxer/osm/...@x/regenaxer/wiki/...-> So such a scheme may solve one part of problem 1), how the modules should look like on the filesystem when 'installed'---The biggest problem I see in 4), how to avoid or handle symbol name clashes.Maybe this can solved with namespace system present in picoLisp, I'm not so sure because I'm currently not using it.I think the current system somewhat requires for all definitions (which are meant to be in the same namespace) to be defined in the same go, probably for the best being defined all in the same file.This works against the small granulation I prefer as described above.Maybe someone with a better understanding of the picoLisp naming system (or someone who actually uses it - someone?) can say som
Re: modules?
Could we cook up a convention? On February 9, 2015 6:12:17 PM CET, Henrik Sarvell wrote: >Hi Lawrence, if you're talking about something like Ruby's gems, then >no. > >On Mon, Feb 9, 2015 at 5:45 PM, Lawrence Bottorff >wrote: > >> I'm wondering what you offer in lieu of modules (as with, say, >Python). Is >> there a "black box" way to "package up" code in picoLisp that has >> module-like serviceability? >> >> LB >> -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.
Re: modules?
Hi Lawrence, if you're talking about something like Ruby's gems, then no. On Mon, Feb 9, 2015 at 5:45 PM, Lawrence Bottorff wrote: > I'm wondering what you offer in lieu of modules (as with, say, Python). Is > there a "black box" way to "package up" code in picoLisp that has > module-like serviceability? > > LB >
Re: modules?
Hi Lawrence, > I'm wondering what you offer in lieu of modules (as with, say, Python). Is > there a "black box" way to "package up" code in picoLisp that has > module-like serviceability? I would say no, though I don't know the modules of Python. Similar to C, a source file has certain encapsulating properties (static scope in C versus transient symbol scope in PicoLisp). On the level of internal symbols, can use namespaces (via the function 'symbols', and its buddies 'local' and 'import') for encapsulation. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
modules?
I'm wondering what you offer in lieu of modules (as with, say, Python). Is there a "black box" way to "package up" code in picoLisp that has module-like serviceability? LB
RE: Installation issues
For what it is worth, here are the contents of every file named 'pil' in the
3.1.9 tarball.
hobbes@metalbaby:~/src/pil319/picoLisp$ find . -name pil -exec head -1000 {} +
==> ./bin/pil <==
#!/usr/bin/picolisp /usr/lib/picolisp/lib.l
(load "@lib/misc.l" "@lib/btree.l" "@lib/db.l" "@lib/pilog.l")
==> ./ersatz/pil <==
#!/bin/sh
# 29nov10abu
# Run Ersatz PicoLisp
exec java -DPID=$$ -cp .:tmp:${0%/*}/picolisp.jar PicoLisp ${0%/*}/lib.l "$@"
==> ./pil <==
#!/bin/sh
exec ${0%/*}/bin/picolisp ${0%/*}/lib.l @ext.l "$@"
NB the one that explicitly calls /usr/bin/picolisp (which is probably still the
one installed by your package manager) and interprets the rest of the file as
lisp source.
Cheers,
--Dave
p.s. Here's what I use for my interactive REPL:
hobbes@metalbaby:~/src/mb.pl.emu$ cat pil
#!/bin/sh
BROWSER=x-www-browser exec ${0%/*}/bin/picolisp ${0%/*}/lib.l @ext.l
@lib/misc.l @lib/btree.l @lib/db.l @lib/pilog.l "$@"
> -Original Message-
> From: picolisp@software-lab.de [mailto:picolisp@software-lab.de] On Behalf
> Of Alexander Burger
> Sent: Saturday, February 07, 2015 12:29 AM
> To: picolisp@software-lab.de
> Subject: Re: Installation issues
>
> Hi Lawrence,
>
> > I've gotten the latest picolisp, 3.1.9, and am trying to install locally.
>
> OK
>
> > Following the instructions for 64-bit on my linux, I've built the
> > executable picolisp all right. But the bin directory's pil seems to
> > pick up the previous version I installed before from Ubuntu:
>
> I think I know what the problem is. It may be that the wrong 'pil' is
> executed,
> because there is another one in /bin, which is intended for the
> global installation.
>
> You need to install /pil, e.g.
>
>$ cd
>$ ./pil +
>
> (the '+' at the end is recommended, to get into debug mode).
>
> You can run it from any place, e.g. with an absolute path
>
>$ /path/to/my/installation/pil +
>
> or with a relative path
>
>$ ../../installation/pil +
>
> or whatever.
>
> ♪♫ Alex
PԔ � &j)mX��� ��zV�u�.n7�
