On Tue, Aug 18, 2020 at 10:22:12PM +0100, Aaron Sloman wrote: > Bill wrote: > > > I am now getting the help, teach, help and ref functions as advertised. > > Also I thought I had found a bug in clisp, but now it has gone away as > > well. > > > > Many thanks to all! > > > > Bill Wood > > Thanks very much for reporting success and to Waldek for spotting the need > to export a bash variable - totally unobvious to a tcsh user like me who > would have written in a tcsh script: > > setenv usepop .... > > Waldek wrote: > > > Such terminals are good reason to use terminfo. AFAICS this terminal > > works after change poposed by Andreas Eder (now in git repo and > > attached to this mail). > > I presume that the change by Andreas is not urgent? I could add it either > by altering the main poplog tar ball, or much more simply by running the > diff file after installing poplog. > > Bill's experience also suggests to me the possibility of a simple > explanation of the need for my script build_all.csh after I had failed to > get build_all.sh to work with my additions. > > This worked > > http://www.cs.bham.ac.uk/research/projects/poplog/V16/build_all.csh > > This did not: > > http://www.cs.bham.ac.uk/research/projects/poplog/V16/build_all.sh > > I possibly needed to export something -- in the second script??
AFAICS the sh version was missing: usepop=`pwd` export usepop at the start. To allow real sh (and not only bash), instead of source $usepop/pop/com/poplog.sh it needs . $usepop/pop/com/poplog.sh Command for unpacking packages-V16.tar.bz2 needed fix, correct version is tar xfj ../../packages-V16.tar.bz2 After those changes the script work OK for me. At http://www.math.uni.wroc.pl/~hebisch/poplog/build_all.sh you can see what I tried (I also trimmed comments and some printouts for better readability). Extra comment: On debian 'sh' is 'dash', which has less features than other shells, but is simpler and faster. Users may prefer one of 'bash', 'zsh', 'ksh'. Our scripts should use 'sh', unless we really need features from other shells. > > FUTURE STEPS: > > I don't regard my installation system as permanent: it's a stop-gap for > users who need to have a poplog installation that includes things (like the > packages directory including teach files and demos) not in the github > system. > > It now occurs to me that if someone can provide a script to download and > install Waldek's github poplog, then I should be able to provide a script > that is run afterwards to add the Birmingham extras and then rebuild > whatever needs to be rebuilt, e.g. basepop11, saved images, and ved search > lists. Well, download from github is very easy, either: git clone https://github.com/hebisch/poplog to get copy of repository (there is extra bulk due to revision history) or wget https://github.com/hebisch/poplog/archive/master.zip to get latest version (sligtly smaller, but no revision history). To build ATM one needs extra scripts. 'com' subdirectory is the same as in 'poplog_base'. 'build_pop0' and 'build_pop2' are changing. In principle rather simple script can merge bham tarballs with github repo, and currently the result should build OK. Note, that if you use first method (that is 'git clone') to get github repo and you add extra files needed for build (and possibly packages/documentation), then git pull in the top directory of the repo will fetch all changes from github. This may fail if you have local changes to files from the repo (git may report that there are conflictiong changes). BTW: I frequently work on machines which have no direct network connection. I can transfer files to them, but say 'wget' from net will fail. This is general problem, because for security reasons machines can be behind firewall which disallows direct connection. In such case it is really desirable to have separate 'fetch' stage (preferably single tarball) and build/install stage. > That would make it *much* easier than it is now to combine the github > version with bham extras. > There would be two separate parts for the bham bit: > > -- fetch bham extras > -- rebuild current poplog using bham extras > > Only the second would need to run after an update from github, > > Comments? Does that sound feasible? > > Waldek: if you like this solution, perhaps you could provide a script that > could be run to fetch and install your github poplog? > > That would hugely simplify what I have -- until such time as everything is > in github, or whatever. > > It would also give me a chance to test your motif changes. > > I would never have thought of this divide and conquer strategy, but for > Bill's problem and Waldek's modification of the earlier suggested solution. > > It's a funny small joined up world. Well, I think that that we have somewhat different views what is hard and what is difficult. For testing, once you have working build tree you can apply patch and test result. For loadable stuff one can just run appropriate program. For stuff going into save image one needs to rebuild saved images. For core things one needs to re-run build_pop2. The scripts I provided were designed in such a way that one can run them multiple time (nothing needed by build script gets deleted during/after build). Motif patch I think requires full rebuild (build_pop2). So in the usepop directory: save attachement to motif.diff patch -p1 < motif.diff ./build_pop2 IMO much easier than trying to update distribution and using download script. Note: patch -p1 -R < motif.diff will undo the change, so this is easy reversible way to test changes. For distribution, when given set of patches works well, one can create merged tarball (like 'poplog_base' tarballs that I provided, but containg all extras of full release). My personal estimate is doing merge by hand 5 times is comparable or less effort compared to working out script like 'getpoplog.sh'. I really hope that cleaning up and completing what is in github repo will take less time than 5 releases, so by reasoning above I felt that merge script is not necessery. Note: I appreciate that you and others may differently estimate difficulty. It is late today, I will write more about needed changes tomorrow. -- Waldek Hebisch
