fricas-wiki is still down

[Ralf Hemmecke]

Hi Waldek,

it seems that it is too expensive to bring the wiki back.

https://fricas-wiki.math.uni.wroc.pl/PolynomialOverFiniteField

In the long run I propose to use the jupyter notebook format (actually
with the help of JupyText ordinary .input files that follow a certain
simple structure are sufficient) and store all this in the repo

https://github.com/fricas/fricas-notebooks/

and show it via (for example)

https://fricas.github.io/fricas-notebooks/FriCAS-FirstSteps.html

The git repo would also nicely record the history of the content.

Just an idea.
Of course, I'd need help to transfer important content from the wiki to
the git repo.

Ralf

[Waldek Hebisch]

On Tue, Jun 27, 2023 at 08:49:14PM +0200, Ralf Hemmecke wrote:
> Hi Waldek,
>
> it seems that it is too expensive to bring the wiki back.

Well, it boils down to versions of software. VirtualBox
seem to be problmatic, version used in the past is not compatible
with upgraded system. Newer VirtualBox apparently does not
work with old image. So I am looking into different setup
for virtual machine. One possible candidate is Xen, most
things looks good, but after installing Xen-enabled kernel
FriCAS seem to be much slower than before. ATM it is not
clear for me what really caused this. Could be some security
patch that just appeared when I installed new kernel.
Obvious net searches does not say anything. It is not
clear if KVM (which seem to another possibility) causes
the same slowdown.

Anyway, there is new server hardware and things are slowly
moving forward. New hardware was planned few month ago,
but became available only few weeks ago. Waiting for
hardware I did not look at VM, as new hardware got
newer system and VM setup on old hardware probably would
be irrelevant to new one.

Currently my main priority is release, but after release
I will at the wiki.

> In the long run I propose to use the jupyter notebook format (actually with
> the help of JupyText ordinary .input files that follow a certain simple
> structure are sufficient) and store all this in the repo
>
> https://github.com/fricas/fricas-notebooks/
>
> and show it via (for example)
>
> https://fricas.github.io/fricas-notebooks/FriCAS-FirstSteps.html
>
> The git repo would also nicely record the history of the content.
>
> Just an idea.
> Of course, I'd need help to transfer important content from the wiki to the
> git repo.

I am not sure what you really propose. One important point of FriCAS
Wiki is ablity to handle actual FriCAS input and show results.
Do Github allow installing our executable on their server for
this purpose? My understanding was that this was not possible.
And handling input coming from net is reason for VM.

Another thing is that I would prefer wiki with simpler and more
rational structure. It seems that Zope (on which current wiki
code is based) has a lot of fancy features, while we use only
tiny part of its functionality. OTOH Zope has nasty feature
of keeping data in its "object store", which makes backup and
transferring data more complicated. So I would welcome
_simpler_ and more managable system. But I am not eager to
replace overengineered system that reasonably well satisfies
our need by something which drops needed functionaly. And
I am not eager to replace one "object store" by different
"object store" which may be even less managable.

--
Waldek Hebisch

[Ralf Hemmecke]

> Currently my main priority is release, but after release I will at
> the wiki.

OK.

BTW, before official release, can we have a pre-release so that I can
again check the things I care about?

In particular we should have a freeze and then look at the stuff that
should go to fricas.github.io (i.e. all the things that live under
src/doc/sphinx). I had some ideas to restructure install.rst, but I am
not sure I find enough time to clean things up.

I am currently checking that the stuff for jfricas is nicely integrated
into the fricas repo.

BTW, do you already have a description for how to build hsbcl. In fact,
to keep it simple... hunchentoot should just live in the binary
distribution. There is actually no need to change anything in the fricas
documentation to describe an installation from the git repository that
works for jfricas. Maybe, I simply document this in jfricas itself.

What I, however, would like to see in the documentation of FriCAS is
reproducible description of how the binary release was produced.

>> In the long run I propose to use the jupyter notebook format
>> (actually with the help of JupyText ordinary .input files that
>> follow a certain simple structure are sufficient) and store all
>> this in the repo
>>
>> https://github.com/fricas/fricas-notebooks/
>>
>> and show it via (for example)
>>
>> https://fricas.github.io/fricas-notebooks/FriCAS-FirstSteps.html
>>
>> The git repo would also nicely record the history of the content.
>>
>> Just an idea. Of course, I'd need help to transfer important
>> content from the wiki to the git repo.
>
> I am not sure what you really propose. One important point of
> FriCAS Wiki is ablity to handle actual FriCAS input and show
> results.

I understand.

What I currently propose is more or less a static view. Giving people
tutorials in the for of working jupyter notebooks.

Having jfricas working with a webserver locally, it shouldn´t be a big
problem to put some machinery in front of it and serve a limited access
to a jFriCAS interface over the internet. Yes, of course, that needs
hardware on our side, but is probably more convenient than editing the
stuff in Zwiki.

> Do Github allow installing our executable on their server for this
> purpose? My understanding was that this was not possible. And
> handling input coming from net is reason for VM.

Yes, of course. Security is an issue. I am not at the stage of offering
something like CoCalc. Currently, I only want a static view, but some
day, we may switch to a web access for people to try out FriCAS, not for
serious computations.

> But I am not eager to replace overengineered system that reasonably
> well satisfies our need by something which drops needed functionaly.

You need not repeat. I know your opinion by now.

> And I am not eager to replace one "object store" by different "object
> store" which may be even less managable.

Oh, well. The zope object database is too much for my taste. Storing in
git is much simpler. And, in fact, github even offers to edit online and
commit. Have you seen the "Edit on Github" link? All that is needed for
a potential contributor is an account at github. There is not much (if
at all) knowledge about git needed.

Ralf

[Waldek Hebisch]

On Tue, Jun 27, 2023 at 10:50:58PM +0200, Ralf Hemmecke wrote:
> > Currently my main priority is release, but after release I will at
> > the wiki.
> OK.
>
> BTW, before official release, can we have a pre-release so that I can
> again check the things I care about?

Well, I can create source tarball somewhat in advance and make it
available immediately after it is created. Also, I can make
binary tarball available before it becomes official. OTOH
longer delay or multiple restarts would be quite inconvenient
for me.

> In particular we should have a freeze and then look at the stuff that
> should go to fricas.github.io (i.e. all the things that live under
> src/doc/sphinx). I had some ideas to restructure install.rst, but I am
> not sure I find enough time to clean things up.
>
> I am currently checking that the stuff for jfricas is nicely integrated
> into the fricas repo.
>
> BTW, do you already have a description for how to build hsbcl. In fact,
> to keep it simple... hunchentoot should just live in the binary
> distribution. There is actually no need to change anything in the fricas
> documentation to describe an installation from the git repository that
> works for jfricas. Maybe, I simply document this in jfricas itself.
>
> What I, however, would like to see in the documentation of FriCAS is
> reproducible description of how the binary release was produced.

Well, at:

http://www.math.uni.wroc.pl/~hebisch/fricas/install.rst

I have edited version of install.rst including new section
'Included hunchentoot'. There is also uptade to info about
GCL.

> > > In the long run I propose to use the jupyter notebook format
> > > (actually with the help of JupyText ordinary .input files that
> > > follow a certain simple structure are sufficient) and store all
> > > this in the repo
> > >
> > > https://github.com/fricas/fricas-notebooks/
> > >
> > > and show it via (for example)
> > >
> > > https://fricas.github.io/fricas-notebooks/FriCAS-FirstSteps.html
> > >
> > > The git repo would also nicely record the history of the content.
> > >
> > > Just an idea. Of course, I'd need help to transfer important
> > > content from the wiki to the git repo.
> >
> > I am not sure what you really propose. One important point of
> > FriCAS Wiki is ablity to handle actual FriCAS input and show
> > results.
>
> I understand.
>
> What I currently propose is more or less a static view. Giving people
> tutorials in the for of working jupyter notebooks.

That is valuable, but somewhat different than wiki.

--
Waldek Hebisch