Riccardo Guida wrote: > > 1) INSTALL. > Well, by definition, NO user will ever manually compile a source code. > Furthermore a user has no virtual machines and just one working environment > which she does not want to screw up if something goes wrong. > > The fricas binaries I downloaded worked, but an average user has to figure > out how to proceeed with the tar file. A step by step "for dummies" > explanation is important. (This is missing in INSTALL-bin.txt) . I'm at > higher computer level so to me the problem was hate for manual install and > paranoia, so I had to take the time to read the tar contents (I did not like > to have usr and usr/local system directories in the tar), write a script that > untars, installs, and creates hashes of all files to check for corruption. > This took time... > > COMPARE with (eg debian's) """ $ aptitude install axiom """ which in > seconds installs everything with no problems of reading instructins, broken > installs, broken environment, security, and with a guarantee of future > automatic upgrades.
root@lifebook:~# aptitude install axiom -su: aptitude: command not found On my machine it is "apt-get". And this is Debian machine. In general you need to figure out what package manager given disto uses and what flavour of packages it needs. That already two extra steps compared to using a tarball (OK, using a tarball you need to know if you run 32 bit distro or 64 bit one and you are out of luck if the machine is not PC-compatible, but still simpler). > > Having linux packages is strategic. I've seen here and there on fricas-devel > remarks about having debian packages soon but after months I do not see the > packages in debian repository. Having Mac/Windows installers would be surely > helpful, but I do not know how difficult it is, so I stop here. Having package in Linux distributions is matter of distributions, not us. To make it clearer, I have seen how things work: if somebody in distro is interested, then things go smoothly. If you came from outside and propose a new package you are likely to be ignored. I mean: you have packaged a program so that if fits into distribution, all that remians is to get official blessing. And you get no feedback... _You_ may voice request at distribution to include FriCAS. Requests coming from core developers are likely to be ignored -- there is simply too many strange programs which authors would like to push into Linux distributions. There were some interst on Debian side last year, but I have no new information. > 2) WEBSITE(S). > The site fricas.sourceforge.net is simple and effective but it refers to a > "fricas wiki" (axiom-wiki.newsynthesis.org) and to a "fricas API" > (http://fricas.github.io/api/genindex.html). > > The site fricas.github.io looks nice, and modern the API is as well very > good and modern (but it does not include all, where are the system > commands??). Had a good impression so I started browsing it, discovering > that there is more information. Happy but now confused, "what is official and > what not official"? Does it matter much what is official? If yes, then you should use Hyperdoc system for viewing documentation included with sources. fricas.github.io contains information automatically derived from souces, but IIUC the process is still under developement. > The axiom-wiki.newsynthesis.org contains a lot of useful information but > (sorry to the maintainer!) looks old-fashioned, weakly mantained, and > unstructured: in practice it is difficult to extract information the first > times. That is a wiki: by definition it is unstructured and disorganised. > What human being can take profit of this page: > http://axiom-wiki.newsynthesis.org/FrontPage/contents ? That is due to old support software. We need to replace it by something better. > (I must say that after 3 weeks of browsing there I've just discovered the > http://axiom-wiki.newsynthesis.org/SiteIndex glossary, which is much helpful > that the contents page. I know I know the "Site index" link is just below the > "Content index" but I am a user so I'm dumb! ) > > Well, no big problems here but my advice is that there should be just one > website (possibly modern and nice-looking like fricas.github.io) with all the > relevant infomation structured in an accessible wayy. Wiki is unstructured but some information is only there. Also, together with wiki you get opportunity to try FriCAS online. > 4) Latex friendly GUI. > It is *important*!!! The 2D output of fricas kernel is difficult to read. > (BTW I would definitely prefer a plain output equal to the input form but I > cannot find how to do it. That is weak point: there are ways to get output that can be feed back but not as easy as it should be and it may fail in more complicated situations (internal representation is richer than input and output). > 5) DOCUMENTATION. > The first problem I faced here is confusion on which source use. > > fricas.sourceforge.net shows a pdf of what now I know being a "Jenks Sutor > book". Furthermore I follow the link to the wiki and I find what looks like > the same thing in html (two sites, how do I know that they are equivalent?) > Ok but browsing the wiki I discover the axiom-developer website by T Daly and > ther I find many volumes with similar but not identical information. All > these books start with the same Axiom first page. Note that Tim Daly Axiom is indepentent project. I have no influence on what information he provides. And given common heritage it would be unfair not mention Axiom. I know that some projects in similar situation actively try to hide their past, but I looks like "kill your mother" recipe for success -- even if it works it does not feel right. > Confused, I go to fricas.github.io and I discover a nice-looking book.pdf > which at the beginning has a message which basically says (in scaring red) > something like, by memory, "this is the official fricas book but > unfortunately it is a work in process, so anything my be wrong" which I > interpret as "STAY AWAY". (Did not work, I must say.) Having a documentation > in pdf and html is strategical (even better if these contents are the > same...). > > COMPARE with the beautiful reference guide of maxima > http://maxima.sourceforge.net/docs/manual/maxima.html or the tutorial of > sympy http://docs.sympy.org/latest/tutorial/index.html where anybody can > modify and execute the code via the browser. > > So to summarize... > > If you want to stop giving a "USERS-STAY-AWAY" impression, the easiest > strategical points I would suggest you to develop are: > -- avoid reduncancies and move all information to one nice-looking website, > maybe fricas.github.io > -- improve the fricas documentation (may be with a dev full version and one > incomplete but reliable version) > -- capture linux users by distributing packages > -- give a reliable, latex-friendly GUI with Jupyter > > Cheers > ric > > PS The other way to capture (unpaid) developers I see, is to have an appeling > project where they could have fun and learn a lot. I see that sympy has many > gsoc students. My unprofessional impressions is that learning Boot, Lisp and > SPAD nowadays is not very motivating nowadays. Is there a loooong term goal > of porting FriCAS to Aldor or e.g. to more known functional languages like > Haskell (which in 1-2 years will have dependent types), its "son" Idris > (which has dependent types) ? In any case the fricas website should show a > "long term goal" ... it gives an impression of quite serious intentions. Long term goal is to get rid of Boot. Easy 50% of this is done (most in first year of FriCAS developement). Concernig Spad and Aldor: you are really talking about two implementations of the same language (call it FriCAS language). Aldor is newer and better developed. But at the language level there are few differences. Some folks consider those differences absolutely essential, but IMHO they are small. There are plans to improve FriCAS language. Concerning Lisp: you should be able to develop FriCAS without knowing Lisp. Currently Lisp gives us needed support infrastructure, but we actually use rather small part of Lisp. Of course, there are users that want to take advantage that Lisp "is included" inside FriCAS, but almost always you can work at level of FriCAS language. Concerning other languages: Spad and Aldor were designed to support needs of computer algebra, it is not easy to find language that fits equally well. So, we may consider changing implementation language, but improving Spad (possibly unifying it with Aldor) seem to be more promising. Also, I am confident that if needed we are able to migrate to other language, but such migration would be one-time event requiring appropriate effort. In particular, it makes no sense to plan for it as long as we did not decided to do it. -- Waldek Hebisch -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
