https://bugzilla.redhat.com/show_bug.cgi?id=2098398
Bug ID: 2098398 Summary: Review Request: picolisp - a pragmatic programming language , tiny footprint LISP interpreter Product: Fedora Version: rawhide Hardware: All OS: Linux Status: NEW Component: Package Review Severity: medium Assignee: nobody@fedoraproject.org Reporter: jason.vas.dias@gmail.com QA Contact: extras-qa@fedoraproject.org CC: package-review@lists.fedoraproject.org Target Milestone: --- Classification: Fedora
Spec URL: https://raw.githubusercontent.com/JVDptt/picolisp-rpm-spec/main/picolisp.spe... SRPM URL: https://github.com/JVDptt/picolisp-rpm-spec/blob/main/picolisp-22.6.17-1.fc3... Description: picolisp - a pragmatic programming language , tiny footprint LISP interpreter - see: https://picolisp.com Fedora Account System Username:jvd66
https://bugzilla.redhat.com/show_bug.cgi?id=2098398
--- Comment #1 from Jason Vas Dias jason.vas.dias@gmail.com --- Please consider including Alexander Burger's excellent picolisp small footprint LISP interpreter: https://picolisp.com - into Fedora.
I have written a pure "Shared-Library-Only" build of picolisp, which I use in both a working bash-builtin and in an Apache Module - I'd like to make these open source, available to any EPEL / Fedora or Ubuntu user, but picolisp has not as yet been delivered to Red Hat RPM users to my knowledge. It IS in Ubuntu / Debian and Android Termux.
It is very powerful, succinct, clear, well documented - see:
http://rosettacode.org/wiki/Category:PicoLisp
Do ask the author if it is OK : abu@software-lab.de
I think it would be fine with him, he already gave permission to Debian / Ubuntu ; I doubt he'd want to be bothered with Fedora Package Management, though -
I am happy to maintain the PicoLisp package for Fedora / EPEL, keeping it up to date with Alex's latest release once a week or so.
PicoLisp has a "less is more" programming philosophy:
"Perfection is attained not when there is nothing left to add but when there is nothing left to take away. "
(Antoine de Saint-Exupéry).
I have found it to be ultra robust and reliable, and efficient, when used correctly, when used incorrectly it core-dumps, or, if lucky, can '(throw ...) an error condition / exception that can be caught with (try (catch ...) (finally ...) (prog ...))).
The documentation is excellent, available from the REPL, or as HTML (shipped in RPM as /usr/share/picolisp/doc) : https://picolisp.com/wiki/?Documentation .
Please give Fedora / RHEL users the benefits of PicoLisp, enjoyed by Debian / Ubuntu / Android Termux users!
https://bugzilla.redhat.com/show_bug.cgi?id=2098398
--- Comment #2 from Jason Vas Dias jason.vas.dias@gmail.com --- Self-Review Issue #1: Oops : $ rpm -qp --requires picolisp-22.6.17-1.fc36.x86_64.rpm ... /data/data/com.termux/files/home/pil21/pil ...
Yes, the distro does include an optional PilBox Android Application, which can be built, if requisite Android Tools are installed, but the host Linux distro in no-way depends on this - it is just one of many optional extras, that users can optionally build, in the distro.
This was picked up by RPM's autoreqprov because: $ grep -RI '/data/data/com.termux/files/home/pil21/pil' . ./bin/pty:#!/data/data/com.termux/files/home/pil21/pil
./bin/pty is ONLY used on the Android Platform by PilBox .
I need to exclude this file somehow from the autoreqprov generator ...
https://bugzilla.redhat.com/show_bug.cgi?id=2098398
--- Comment #3 from Jason Vas Dias jason.vas.dias@gmail.com --- OK, .spec file now updated to exclude that problematic AutoReqProv.
Also updated .spec file to provide support for the '--with auto_download' option, to enable download of the latest pil21.tgz before building of it commences, and to determine the RPM version number dynamically from it.
There is an archive of the SRPM, the spec file, the RPM produced, and the build log, from a '--with auto_download' build, at:
https://drive.google.com/drive/folders/169COH6WSItF614WWpoGbrgFdpUyB2JLr?usp...
https://bugzilla.redhat.com/show_bug.cgi?id=2098398
Jason Vas Dias jason.vas.dias@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jason.vas.dias@gm | |ail.com) |
Product: Fedora Version: rawhide Component: Package Review
Jason Vas Dias jason.vas.dias@gmail.com has canceled Package Review package-review@lists.fedoraproject.org's request for Jason Vas Dias jason.vas.dias@gmail.com's needinfo: Bug 2098398: Review Request: picolisp - a pragmatic programming language , tiny footprint LISP interpreter https://bugzilla.redhat.com/show_bug.cgi?id=2098398
https://bugzilla.redhat.com/show_bug.cgi?id=2098398
--- Comment #5 from Jason Vas Dias jason.vas.dias@gmail.com --- Created attachment 2002941 --> https://bugzilla.redhat.com/attachment.cgi?id=2002941&action=edit latest source rpm building under FC-38 now
Please review & consider including picolisp in Fedora . The above picolisp.spec includes my most minimal patch to the original source to also produce a 'picolisp.so' shared library, and provide a 'const char* lisp_eval(const char*) // free() non-null returns' "C" entry point, entirely optionally, enabled with the '--with picolisp_dso' rpmbuild option, which enables expressions like : " const char *result = lisp_eval("(+ 2 2)"); printf("%s\n", result); free(result); " to print "4".
https://bugzilla.redhat.com/show_bug.cgi?id=2098398
--- Comment #6 from Jason Vas Dias jason.vas.dias@gmail.com --- I'd always recommend building with the rpmbuild '--with auto_download' option, which enables downloading https://software-lab.de/pil21.tgz , where Alex's latest source is regularly updated - the build from .spec with rpmbuild ALWAYS runs the test : $ ./pil$_just_built @lib/test.l -bye + which MUST succeed for the RPM build to succeed . I've never seen use of auto_download break a build yet !
https://bugzilla.redhat.com/show_bug.cgi?id=2098398
--- Comment #7 from Jason Vas Dias jason.vas.dias@gmail.com --- Created attachment 2002942 --> https://bugzilla.redhat.com/attachment.cgi?id=2002942&action=edit RPM spec file for picolisp, as in SRPM
https://bugzilla.redhat.com/show_bug.cgi?id=2098398
Benson Muite benson_muite@emailplus.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|nobody@fedoraproject.org |benson_muite@emailplus.org Flags| |fedora-review? Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value Blocks| |177841 (FE-NEEDSPONSOR) CC| |benson_muite@emailplus.org
--- Comment #8 from Benson Muite benson_muite@emailplus.org --- Can review, but you will need to find a sponsor to be come a packager. Following maybe helpful: https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process... https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsore...
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=177841 [Bug 177841] Tracker: Review requests from new Fedora packagers who need a sponsor
https://bugzilla.redhat.com/show_bug.cgi?id=2098398
Jason Vas Dias jason.vas.dias@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo? | |needinfo?(benson_muite@emai | |lplus.org)
--- Comment #9 from Jason Vas Dias jason.vas.dias@gmail.com --- How do I obtain a sponsor for this - maybe R.Dieter, sbcl package maintainer ? Perhaps you could contact him & ask ?
Please, Fedora Package Maintainer, consider adding picolisp to Fedora ! Debian / Ubuntu / Termux / BSD has had pil / picolisp for years ! It is a tiny, highly efficient, robust & pragmatic programming language and pure LISP interpreter, a super-shell, with some very advanced Prolog-Like and Database and HTML/HTTP processing features .
'pil' is what I use mainly nowadays in preference to bash / perl / python scripts, 'sbcl' is what I'd use for larger more modular 'compilation oriented' projects, in preference to Java / Scala, but I'd use both primarily as users of C/C++ libraries I develop and load with 'dlopen(3)' into running pil or sbcl images, or in the case of 'pil', as a loadable DSO built-in named '𝞴' which uses dlopen(3) to load /usr/share/picolisp/bin/picolisp.so, and then calls 'lisp_eval' , handler of picolisp expressions , and prints the result as a string, as a bash (Bourne Again Shell) built-in loadable shared object (DSO). Both have excellent FFI (foreign function interface) facilities.
See : https://rosettacode.org/wiki/Category:PicoLisp#:~:
https://bugzilla.redhat.com/show_bug.cgi?id=2098398
--- Comment #10 from Jason Vas Dias jason.vas.dias@gmail.com --- Note to maintainers / reviewers - if you do not have any 'pil' / 'picolisp' command in your $PATH when building for the first time, you are Bootstrapping . In that case, IFF a 32-bit Java 1.8 environment is in $PATH (and possibly also $LD_LIBRARY_PATH), then you can cd to the 'src32' directory and run make, that will build the 32-bit Java PicoLisp Simulator, that CAN be used to provide the 'picolisp' command necessary to build the (ONLY!) 64-bit picolisp for the first time.
But really, I'd recommend downloading the Ubuntu picolisp binary and building a libc it will link against, then running that, or getting a Fedora-38 built binary from me. Nothing else will suffice to build picolisp other than picolisp, it is its own Assembler / runner of 'opt', the LLVM Code Generator ... You can also build the old pre LLVM/Clang version of pil as a bootstrap picolisp, which is built also by running picolisp as an X86_64 Assembler generator, but that also requires at least the 32-bit simulator to be in $PATH in order to bootstrap.
https://bugzilla.redhat.com/show_bug.cgi?id=2098398
--- Comment #11 from Jason Vas Dias jason.vas.dias@gmail.com --- Here is what the build does :
../pil lib/llvm.l main.l -bye > base.ll mv base.map ../lib/map opt -O3 -opaque-pointers -o base.bc base.ll clang -O3 -w -fPIC -c -o lib.bc -D_OS='"Linux"' -D_CPU='"x86_64"' `pkg-config --cflags libffi` -emit-llvm lib.c llvm-link -o picolisp.bc base.bc lib.bc mkdir -p ../bin ../lib llc picolisp.bc -relocation-model=pic -o picolisp.s clang picolisp.s -o ../bin/picolisp -rdynamic -lc -lutil -lm -ldl -lreadline -lffi strip ../bin/picolisp
But ../bin/picolisp is referenced by ../pil, to produce 'base.ll' in the first step ;
I believe 'base.ll' left over from previous build and with earlier timestamp could also be shippped, then if this was a Bootstrap build, (no picolisp found), then that pre-generated base.ll could be used to produce a non-generated build of picolisp , skipping a most important build step for build customization, and expecting a Debian / Ubuntu libc. So ../bin/picolisp must exist, be the 32-bit simulator runner script, or be an SSH script that SSHes to an instance of Ubuntu running picolisp and which mounts the same build directory using NFS, eg. an Ubuntu VM, but 'picolisp' must be found in $PATH before building from generated base.ll will work.
https://bugzilla.redhat.com/show_bug.cgi?id=2098398
--- Comment #12 from Jason Vas Dias jason.vas.dias@gmail.com --- I should probably ship a 'base.prev.ll.xz' file in the SRPM, which would be from a Fedora-38 x86_64 build, not from a Ubuntu / Debian build at least , that would enable a bootstrap ../bin/picolisp to be used only for generating a new initial base.ll to be initially built , ie. running from 'opt -O3' line above where base.ll is initially base.prev.l, then once that ../bin/picolisp is produced, running that to produce a new base.ll .
https://bugzilla.redhat.com/show_bug.cgi?id=2098398
--- Comment #13 from Jason Vas Dias jason.vas.dias@gmail.com --- Created attachment 2002975 --> https://bugzilla.redhat.com/attachment.cgi?id=2002975&action=edit generated base.ll from an FC-38 x86_64, which is all that is necessary to build bootstrap ../bin/picolisp
https://bugzilla.redhat.com/show_bug.cgi?id=2098398
Benson Muite benson_muite@emailplus.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(benson_muite@emai | |lplus.org) |
--- Comment #14 from Benson Muite benson_muite@emailplus.org --- Initial comments: a) Get your package to build in copr and possibly also koji b) Auto download should not be used, need to check each release. Fedora builds do not have internet access to ensure integrity of what is built. c) Try to do a few informal reviews, it helps learn about the packaging process and makes it easier for a sponsor to see you have acquired skills necessary to package. You might also consider doing a few updates of other packages you are interested in, for example sbcl.
https://bugzilla.redhat.com/show_bug.cgi?id=2098398
Benson Muite benson_muite@emailplus.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(benson_muite@emai | |lplus.org) |
--- Comment #16 from Benson Muite benson_muite@emailplus.org --- Happy to continue the review.
https://bugzilla.redhat.com/show_bug.cgi?id=2098398
--- Comment #17 from Jason Vas Dias jason.vas.dias@gmail.com --- @benson_muite@emailplus.org:
RE:
Initial comments: a) Get your package to build in copr and possibly also koji
If those tools can use 'rpmbuild', this package will build fine.
b) Auto download should not be used, need to check each release. Fedora builds do not have internet access to ensure integrity of what is built.
Yes, by default, without the optional '--with auto_download' bcond, any existing pil21.tgz file in SOURCES will be built.
c) Try to do a few informal reviews, it helps learn about the packaging process and makes it easier for a sponsor to see you have acquired skills necessary to package. You might also consider doing a few updates of other packages you are interested in, for example sbcl.
Yes, I have done this - updated sbcl package submitted at around same time as this one.
Still no response from any package maintainer to either update request.
package-review@lists.fedoraproject.org