Hi Hanak, > Thanks for this Git version of Poplog. It's really great!
I am glad you like it :) > Compared to what I call the "Poplog official version" (Sussex Poplog Version > 16.0, the one installed via > http://www.cs.bham.ac.uk/research/projects/poplog/V16/getpoplog.sh > <http://www.cs.bham.ac.uk/research/projects/poplog/V16/getpoplog.sh> ), there > are some differences. All the intended differences are documented here: https://github.com/GetPoplog/Seed/wiki/Differences-from-a-default-FreePoplog-build <https://github.com/GetPoplog/Seed/wiki/Differences-from-a-default-FreePoplog-build>. Because GetPoplog (the Git version) is very tightly based on FreePoplog there shouldn't be any other differences. > * First the positive differences > The "official version" has problems running some of programs from the > command line, and one has to first load the pop11 executable and load the > program, otherwise there's an infinite loop or getting some error message > regarding "<termin>" etc. These programs are mostly expert systems that > interact with input from the user, and they are all from some of the TEACH > examples. > > The Git version don't have this problem, so I can now run directly them as > $ poplog pop11 program.p That is actually a bit strange. The GetPoplog build process has had a lot of attention from both myself and Will Price, so it is possible that might make a difference. But, to be honest, I would not have expected this. > * Some things that don't work in the Git version > > Here are some things that work in the Poplog "official version", but not > the Git version. > > - evans analogy > My test program is http://hakank.org/poplog/evans_test.p > <http://hakank.org/poplog/evans_test.p> and the error can be reproduced by: > > $ poplog pop11 > : uses teaching; > ;;; LOADING LIB analogy > ;;; MISHAP - CAN'T OPEN FILE (Invalid directory) > ;;; INVOLVING: '$usepop/pop/lib/turtle/turtle.p' > ;;; FILE : > /home/hakank/poplog/git/hebish/poplog/pop/packages/lib/../teaching/auto/turtle.p > LINE NUMBER: 16 > ;;; PRINT DOING > ;;; DOING : discin proglist_new_state section Do_expr_syntax_opener > ;;; Comp_expr_seq search nextitem Comp_expr_seq search loadlib > pop_setpop_ > ;;; compiler > """ I set up a mirror of your $poplib, including the GOSPL library (from my repo at https://github.com/sfkleach/GOSPL <https://github.com/sfkleach/GOSPL>). It needed a trivial correction so that GOSPL was loaded from $poplib rather than /home/hakank. However I could not reproduce this issue locally. Just looking at the trace, it appears that you have some extra setup. The clue is in this line: > ;;; FILE : > /home/hakank/poplog/git/hebish/poplog/pop/packages/lib/../teaching/auto/turtle.p > LINE NUMBER: 16 That is saying that the turtle.p file it has found is buried somewhere odd. It looks like you have an extra Poplog-tree at ~/poplog/git/hebish/poplog. So I am fairly sure this is only very indirectly related to your GetPoplog installation. If you want to set aside some time, we could try investigating it over Skype together. My Skype handle is 'sfkleach'. (In fact I am on just about every popular collaboration platform but Skype has decent screen sharing.) > - Schemata test > This is from TEACH SCEMATA, and my test program is > http://hakank.org/poplog/schemata_test.p > <http://hakank.org/poplog/schemata_test.p> > > The error can be reproduced with: > """ > $ poplog pop11 > Setpop > : lib schema; > ;;; LOADING LIB schema > : lib someschemata; > ;;; LOADING LIB someschemata Again I couldn't replicate this - it all worked just fine locally. Obviously your init.p file loads 'teaching', which is a pre-requisite for 'lib schema' to work. But I suspect its the same problem as before. > The missing program "someschemata.p" is in the "official Poplog here: > poplog_base/pop/lib/data/someschemata.p > However, the Git version don't have the directory > pop/lib/data/ If that is true then you have a damaged installation. We have not seen any of those so far. Try this: % poplog shell > find $usepop -iname someschemata.p pop/lib/data/someschemata.p > exit You should see the exact same result. > I also checked which other directories that are missing from the Git > version's pop/lib directory (compared to the "official" version's directory > poplog_base_pop/lib). > Here are the missing directories: > - poplog_base/pop/lib: data > - poplog_base/pop/lib: demo > - poplog_base/pop/lib: obsolete > - poplog_base/pop/lib: proto > - poplog_base/pop/lib: psv > - poplog_base/pop/lib: sun > - poplog_base/pop/lib: turtle > > (I don't know much about these directories, just noticed that they are > not in the Git version.) They are definitely all part of the GetPoplog distribution. BUT there is no poplog_base folder. > * Performance > One of my standard performance tests is to run the euler*.p programs > (problems 1..50, see http://hakank.org/poplog/ <http://hakank.org/poplog/>) . > The Git version is about of the same speed as the "official version" - about > 10.4s to run all 50 programs - so there's no detectable difference there. GetPoplog imposes a tiny overhead on the launch of Poplog, although I would be very surprised if you could measure it. Unlike the FreePoplog distribution, where the environment variables are normally set up by a script at login, the 'poplog' command of GetPoplog is a binary executable that sets up the environment and then chains into the normal Poplog executable. As you can see, it is setting up the environment each time you run 'poplog'. Hence there must be an overhead. However the executable is tiny, lightweight, written in C and does very little other than move string pointers around. I would expect it to be undetectable. > About the only program that is discernible better when running in the Git > version is http://hakank.org/poplog/lucas_lehmer_test.p > <http://hakank.org/poplog/lucas_lehmer_test.p> (from > http://www.rosettacode.org/wiki/Lucas-Lehmer_test > <http://www.rosettacode.org/wiki/Lucas-Lehmer_test> ). > The "official version" (often but not always) throws an "MEMORY ACCESS > VIOLATION" mishap after printing M127 but I've not seen this problem using > the Git version. I suspect that this apparent advantage of the GetPoplog installation is that it is more recently built than your FreePoplog installation and perhaps built on a operating system version that is a better match. Rebuilding the FreePoplog version would likely give it a new lease of life. Steve
