New release

[Waldek Hebisch]

I am thinking about new release. To say the truth we have
quite long list of open bugs and it would be good to fix
some of them before release. However there is long time
from last release, we have new code that should get more
use. And most bugs probaly will require long time to fix.
For example several integration bugs should vanish if
we rewrite top level of integration routines, but seem
very hard to solve otherwise. Similarly for limits.
I will write more about this in separate posts.

Concerning release, I would like to finish some features
that I started implementing and I have to fix a few
more bugs. But I would like in two-three weeks to
have a cutoff (== only simple fixes or relase critical
bugs allowed before release) and then release (which
will take few days).

--
Waldek Hebisch

[Martin R]

I would like to have the patch proposed in https://groups.google.com/forum/#!msg/fricas-devel/j-dy6TXiX9E/CG4JFGYeGgAJ in the new release, fixing a bug in the InputForm of formal derivatives.

That would be great,

Martin

[Waldek Hebisch]

On Fri, Feb 21, 2020 at 02:40:48PM -0800, 'Martin R' via FriCAS - computer algebra system wrote:
> I would like to have the patch proposed in
> https://groups.google.com/forum/#!msg/fricas-devel/j-dy6TXiX9E/CG4JFGYeGgAJ in
> the new release, fixing a bug in the InputForm of formal derivatives.

Well, there is question about correctness of proposed patch. I there
were no alternative then the patch would be improvement on current
situation. However, there is obviously correct alternative, that
is always using a new symbol and you advocate reusing dummy
from representation of derivative. Without proper justifiction
for reuse I think we should use new symbol.

Always using new symbol uncovers problem with testing machinery:
when input form uses different symbol name it signals spurious error.
So we will have to rethink our approach to testing.

--
Waldek Hebisch

[Kurt Pagani]

I'd like to point out two small issues. Would be great if one or the other could
be resolved in a next release:

-- The (TexFormat) output of derivatives of (univariate) functions looks ugly.
Examples:
- http://fricas-wiki.math.uni.wroc.pl/TexFormat0
- http://fricas-wiki.math.uni.wroc.pl/DerivFunc

The same also holds for TeXmacs (see attached pdf).

Personally, I'm using a slightly hacked version of TexFormat:
- http://fricas-wiki.math.uni.wroc.pl/TexFormat1
Maybe someone has a better idea (op 'PRIME)?
Another story would be the untimely \over, \sb, \sp commands, but those are
manageable by macros.

The second issue concerns big files (compile or read doesn't matter):


--ECL
-- (1) -> )r bigfile
--
-- >> System error:
-- C-STACK overflow at size 1042432. Stack can probably be resized.
-- Proceed with caution.

--SBCL
-- >> System error:
-- Control stack exhausted (no more space for function call frames).
-- This is probably due to heavily nested or infinitely recursive function
-- calls, or a tail call that SBCL cannot or has not optimized away.
--
-- PROCEED WITH CAUTION.

Example:
- http://fricas-wiki.math.uni.wroc.pl/AWAIC
- attached bigfile.input (mostly comments, ~30k lines)

I'm wondering why reading a file uses recursion?

[Ralf Hemmecke]

On 2/27/20 10:41 PM, Kurt Pagani wrote:
> I'd like to point out two small issues. Would be great if one or the other could
> be resolved in a next release:
>
> -- The (TexFormat) output of derivatives of (univariate) functions looks ugly.
> Examples:
> - http://fricas-wiki.math.uni.wroc.pl/TexFormat0
> - http://fricas-wiki.math.uni.wroc.pl/DerivFunc

The problem is not the conversion to TeX, but rather a strange way of
storing that in OutputForm.

(12) -> (eq1 :: OutputForm) pretend SExpression

(12) (= ((PRIME f ",,,") x) (^ x n))

Wouldn't it make more sense to store it as (PRIME f 3) and let the
Formatter deal with how it is shown? Here eq1::OutputForm does too much.
In other words, I would be in favour of moving the code

add_prime(a : %, s : %) : % == convert [eform 'PRIME, a, s]
prime(a, nn) == (s := new(nn, char ","); add_prime(a, sform s))

away from OutputForm and simply say something like

prime(a, nn) ==
if a is of form (PRIME x n) then
(PRIME x n+nn)
else
(PRIME a nn)

Then i-output.boot or the various Formatters would have to deal with
translating that s-expression into something nice.

Ralf

[Kurt Pagani]

>
> The problem is not the conversion to TeX, but rather a strange way of
> storing that in OutputForm.
>
> (12) -> (eq1 :: OutputForm) pretend SExpression
>
> (12) (= ((PRIME f ",,,") x) (^ x n))
>

You're right, of course. The root of all evil (not all, though) in TEX is found
in OUTFORM. However, the line

https://github.com/fricas/fricas/blob/master/src/algebra/tex.spad @ line 354
op = 'PRIME =>
formatSpecial('SUPERSUB, [first args, " "::E, second(args)], prec)

makes it even worse. One might change " "::E to hspace(1), but the ugly ",,,"
will remain (I'd prefer ''' ;). In the console it looks ok.

> Wouldn't it make more sense to store it as (PRIME f 3) and let the
> Formatter deal with how it is shown? Here eq1::OutputForm does too much.
> In other words, I would be in favour of moving the code
>
> add_prime(a : %, s : %) : % == convert [eform 'PRIME, a, s]
> prime(a, nn) == (s := new(nn, char ","); add_prime(a, sform s))
>
> away from OutputForm and simply say something like
>
> prime(a, nn) ==
> if a is of form (PRIME x n) then
> (PRIME x n+nn)
> else
> (PRIME a nn)
>
> Then i-output.boot or the various Formatters would have to deal with
> translating that s-expression into something nice.

Indeed, this would simplify the construction of a reasonable LaTeX string.
Moreover it could provide more flexibility (in TexFormat) for multivariate
functions as well (e.g. f_x, f_y instead of only f_{,1}, f_{,2}).

>
> Ralf
>

[Waldek Hebisch]

On Fri, Feb 21, 2020 at 02:40:48PM -0800, 'Martin R' via FriCAS - computer algebra system wrote:

> I would like to have the patch proposed in
> https://groups.google.com/forum/#!msg/fricas-devel/j-dy6TXiX9E/CG4JFGYeGgAJ in
> the new release, fixing a bug in the InputForm of formal derivatives.

As I wrote proposed fix looks problematic due to reuse of dummies.
I think that attached patch is safer.

--
Waldek Hebisch

[Waldek Hebisch]

On Thu, Feb 27, 2020 at 10:41:32PM +0100, Kurt Pagani wrote:
>
> The second issue concerns big files (compile or read doesn't matter):
>
>
> --ECL
> -- (1) -> )r bigfile
> --
> -- >> System error:
> -- C-STACK overflow at size 1042432. Stack can probably be resized.
> -- Proceed with caution.
>
> --SBCL
> -- >> System error:
> -- Control stack exhausted (no more space for function call frames).
> -- This is probably due to heavily nested or infinitely recursive function
> -- calls, or a tail call that SBCL cannot or has not optimized away.
> --
> -- PROCEED WITH CAUTION.
>
> Example:
> - http://fricas-wiki.math.uni.wroc.pl/AWAIC

That one looks like sbcl bug: stack overflow is during lisp compilation.

> - attached bigfile.input (mostly comments, ~30k lines)
>
> I'm wondering why reading a file uses recursion?

Recursion in general is reasonable. Our scanned uses too complicated
method which usually keeps recursion depth low. But on long
streches of comments the method backfires and recursion depth
is very high. Adding some actual code (so distnce between executable
lines is at most 5000) between comment makes problem go away,
so it there is at least partial workaround. Anyway, I was
thinking about simplifyng scanner, but up to now "do not fix
what is not broken" won. Now I will have good excuse
to work on it. To say the truth I am more worried about
releated problem: skiping long parts using ')if' and ')endif'
also leads to crash...

--
Waldek Hebisch

[Kurt Pagani]

On 28.02.2020 17:58, Waldek Hebisch wrote:
> On Thu, Feb 27, 2020 at 10:41:32PM +0100, Kurt Pagani wrote:
>>
>> The second issue concerns big files (compile or read doesn't matter):
>>
>>
>> --ECL
>> -- (1) -> )r bigfile
>> --
>> -- >> System error:
>> -- C-STACK overflow at size 1042432. Stack can probably be resized.
>> -- Proceed with caution.
>>
>> --SBCL
>> -- >> System error:
>> -- Control stack exhausted (no more space for function call frames).
>> -- This is probably due to heavily nested or infinitely recursive function
>> -- calls, or a tail call that SBCL cannot or has not optimized away.
>> --
>> -- PROCEED WITH CAUTION.
>>
>> Example:
>> - http://fricas-wiki.math.uni.wroc.pl/AWAIC
>
> That one looks like sbcl bug: stack overflow is during lisp compilation.

Yes, ECL and ABCL the same/similar.

>
>> - attached bigfile.input (mostly comments, ~30k lines)
>>
>> I'm wondering why reading a file uses recursion?
>
> Recursion in general is reasonable.

Dear me, nothing against recursion. I forgot the 'scanner', probably because one
is used to read the whole file into memory before preocessing nowadays (e.g.
Python).

> Our scanned uses too complicated
> method which usually keeps recursion depth low. But on long
> streches of comments the method backfires and recursion depth
> is very high. Adding some actual code (so distnce between executable
> lines is at most 5000) between comment makes problem go away,
> so it there is at least partial workaround. Anyway, I was
> thinking about simplifyng scanner, but up to now "do not fix
> what is not broken" won. Now I will have good excuse
> to work on it. To say the truth I am more worried about
> releated problem: skiping long parts using ')if' and ')endif'
> also leads to crash...
>

The strange thing is that the (compiled) AWAIC example
(http://fricas-wiki.math.uni.wroc.pl/AWAIC) worked some years ago. Unfortunately
I can't remember which Fricas version. I found one old version only (1.2.7,
2016) and this one is able to read the bigile but cannot compile the AWAIC
either. By the way, I thought it wouldn't matter whether comments or commands
are read, however, this seems not to be case, indeed (the snippet below creates
a file that runs with 100k lines without any problem at all). So mucht the more
I'm wondering why the AWAIC won't compile. It's certainly not a problem of
upmost priority, though.

---
N:=100000
f:=open("bigfile2.input"::FileName,"output")$TextFile
writeLine!(f,"X:=[0 for i in 1.." string(N) "]")
for i in 1..N repeat
writeLine!(f,"X." string(i) ":=random(" string(N) ")")
close!(f)
)q

---



(2) -> )r bigfile
x:=0


(2) 0
Type: NonNegativeInteger
(3) -> x

(3) 0
Type: NonNegativeInteger
(4) -> )lisp (lisp-implementation-version)

Value = "1.3.0"
(4) -> )lisp (lisp-implementation-type)

Value = "SBCL"

[Neven Sajko]

> The second issue concerns big files (compile or read doesn't matter):

> ...

> --SBCL
> -- >> System error:
> -- Control stack exhausted (no more space for function call frames).
> -- This is probably due to heavily nested or infinitely recursive function
> -- calls, or a tail call that SBCL cannot or has not optimized away.

SBCL imposes limits on stack and heap size. To configure them (increase

the limits), run configure before compiling Fricas like this:

./configure '--with-lisp=sbcl --control-stack-size 512 --dynamic-space-size 6000'

This are, in fact, the exact options used in the Archlinux AUR package

for Fricas.

Warning: these limits may be too high if Fricas runs on a system with

limited memory. On the other hand one may want to use even greater

limits if enough memory is available (e.g., on a server computer).

I guess similar adjustments may be possible for ECL.

[Kurt Pagani]

Thanks for the hint. Actually this was discussed several times in the forum:

https://groups.google.com/forum/#!searchin/fricas-devel/dynamic-space-size%7Csort:date

Nevertheless this might be always an option, as a last resort ;)
If it could be fixed in the code, however, then it should be done.

BTW I wasn't aware of https://aur.archlinux.org/packages/?O=0&K=fricas
a fricas package. Very interesting!

https://aur.archlinux.org/packages/fricas/

This ought to be mentioned somewhere (@Ralf: maybe http://fricas.github.io/)

> --
> 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 fricas-devel...@googlegroups.com
> <mailto:fricas-devel...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/d669ca75-c7c6-46da-a240-15b4f831e24b%40googlegroups.com
> <https://groups.google.com/d/msgid/fricas-devel/d669ca75-c7c6-46da-a240-15b4f831e24b%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Neven Sajko]

Waldek, Ralf; regarding my previous email, I should have mentioned that

info about stack and heap limits and how to raise them should be

documented better for users of Fricas. Probably should go into the

INSTALL file. Do you want a Github pull request, or something?

[Waldek Hebisch]

On Fri, Feb 28, 2020 at 07:40:22PM +0100, Kurt Pagani wrote:
> On 28.02.2020 17:58, Waldek Hebisch wrote:
> > On Thu, Feb 27, 2020 at 10:41:32PM +0100, Kurt Pagani wrote:
> >>
> >> The second issue concerns big files (compile or read doesn't matter):
> >>
> >>
> >> --ECL
> >> -- (1) -> )r bigfile
> >> --
> >> -- >> System error:
> >> -- C-STACK overflow at size 1042432. Stack can probably be resized.
> >> -- Proceed with caution.
> >>
> >> --SBCL
> >> -- >> System error:
> >> -- Control stack exhausted (no more space for function call frames).
> >> -- This is probably due to heavily nested or infinitely recursive function
> >> -- calls, or a tail call that SBCL cannot or has not optimized away.
> >> --
> >> -- PROCEED WITH CAUTION.
> >>
> >> Example:
> >> - http://fricas-wiki.math.uni.wroc.pl/AWAIC
> >
> > That one looks like sbcl bug: stack overflow is during lisp compilation.
>
> Yes, ECL and ABCL the same/similar.

With ECL (using current stable release, that is 16.1.3) compilation
worked for me. It took long time, 180s for spad and List to C compilation
and more than 10 minutes for C compilation. And gcc produced
message that it run out of storage for variable tracking but
eventually produced object file.

> >
> >> - attached bigfile.input (mostly comments, ~30k lines)
> >>

Should be fixed now.

> The strange thing is that the (compiled) AWAIC example
> (http://fricas-wiki.math.uni.wroc.pl/AWAIC) worked some years ago. Unfortunately
> I can't remember which Fricas version. I found one old version only (1.2.7,
> 2016) and this one is able to read the bigile but cannot compile the AWAIC
> either.

AFAICS this is mostly Lisp compiler thing. Compared to older version
sbcl significantly increased it memory use during compilation.
One possible option may be to lower optimization settings in
sbcl to profer compilation speed over code speed (after all, this
code is executed once per session...).

--
Waldek Hebisch

[Waldek Hebisch]

On Thu, Feb 27, 2020 at 10:41:32PM +0100, Kurt Pagani wrote:

> I'd like to point out two small issues. Would be great if one or the other could
> be resolved in a next release:
>
> -- The (TexFormat) output of derivatives of (univariate) functions looks ugly.
> Examples:
> - http://fricas-wiki.math.uni.wroc.pl/TexFormat0
> - http://fricas-wiki.math.uni.wroc.pl/DerivFunc
>
> The same also holds for TeXmacs (see attached pdf).
>
> Personally, I'm using a slightly hacked version of TexFormat:
> - http://fricas-wiki.math.uni.wroc.pl/TexFormat1
> Maybe someone has a better idea (op 'PRIME)?

The attached diff solves TeX problem in similar but I
think slightly better way. It may also work for TeXmacs,
but that I did not test it. In particular I do not know
if "<prime>" is the right TeXmacs sequence to get derivative sign.
--
Waldek Hebisch

[Waldek Hebisch]

On Fri, Feb 28, 2020 at 12:05:12AM +0100, Ralf Hemmecke wrote:
> On 2/27/20 10:41 PM, Kurt Pagani wrote:
>
> The problem is not the conversion to TeX, but rather a strange way of
> storing that in OutputForm.
>
> (12) -> (eq1 :: OutputForm) pretend SExpression
>
> (12) (= ((PRIME f ",,,") x) (^ x n))
>
> Wouldn't it make more sense to store it as (PRIME f 3) and let the
> Formatter deal with how it is shown?

At first glance it looks attractive. But currently higher derivative
use Roman numerals. IMO decision between primes, roman numeral
and may be arabic is somewhat higher level and should be common to
all formatters. To say the truth, calling roman convertion from
Boot code is somewhat awkward, so it is simpler to do this at
higher level.

> Here eq1::OutputForm does too much.
> In other words, I would be in favour of moving the code
>
> add_prime(a : %, s : %) : % == convert [eform 'PRIME, a, s]
> prime(a, nn) == (s := new(nn, char ","); add_prime(a, sform s))
>
> away from OutputForm and simply say something like
>
> prime(a, nn) ==
> if a is of form (PRIME x n) then
> (PRIME x n+nn)
> else
> (PRIME a nn)

Hmm, I am not sure what you mean here. AFAICS you propose new
behaviour not present in current code. And it looks that you
hardcode here associative property of PRIME. This may be not
bad, but before writing such code it would be good to say
which transformation OutputForm can do and which are not allowed.
For example we may have "commutative and associative +" which
OutputForm may rearrange and looking the same "literal +"
which is considered non-commutative and non-associative.
Or maybe do it in different way, say via rigid and flexible
trees (OutputForm would be allowed to rearrange flexible tree,
but preseve tree structure of rigid ones).

--
Waldek Hebisch

[Waldek Hebisch]

ATM master sources are in svn, so diff is better than pull request.
And in case of INSTALL, if you have better wording in mind you
may just post relevant passage here.

--
Waldek Hebisch

[Ralf Hemmecke]

> ATM master sources are in svn, so diff is better than pull request.

When do we switch to git?

Ralf

[Waldek Hebisch]

On Sat, Feb 29, 2020 at 03:48:43PM +0100, Ralf Hemmecke wrote:
> > ATM master sources are in svn, so diff is better than pull request.
>
> When do we switch to git?
>

Well, some time ago I thought that I am almost ready for switch.
But then Camm Maguire wrote "fetch this special gcl branch".
Given branch name it worked, but without knowing the name
I was unable to find it in gcl git repo. So either git
allows you to create invisible branches, which I consider
evil, or I my understanding of git is way below what is
needed to effectivly use it. I use git for less important
projects, so I can survive using it. But I feel that
for me to use it for FriCAS developement is still too
inefficient and risky.

--
Waldek Hebisch

[Dima Pasechnik]

On Sat, 29 Feb 2020, 08:11 Waldek Hebisch, <heb...@math.uni.wroc.pl> wrote:

On Sat, Feb 29, 2020 at 03:48:43PM +0100, Ralf Hemmecke wrote:
> > ATM master sources are in svn, so diff is better than pull request.
>
> When do we switch to git?
>

Well, some time ago I thought that I am almost ready for switch.
But then Camm Maguire wrote "fetch this special gcl branch".
Given branch name it worked, but without knowing the name
I was unable to find it in gcl git repo. 

saying "check out that very special commit"  from svn repo does not get one far either.

So either git
allows you to create invisible branches,

git branch

lets you list all the  branches on a repo.

Branch is basically a label for a well-behaved subset of commits, not much more than that.

(there are also tags, something a bit different)

which I consider
evil, or I my understanding of git is way below what is
needed to effectivly use it.  I use git for less important
projects, so I can survive using it.  But I feel that
for me to use it for FriCAS developement is still too
inefficient and risky.

one need not be forced to use github/gitlab workflows of pull/merge requests. One can instead work with named branches.

--------

The bottom line is that nowadays most people either never used svn, or already forgot all about it.

(yes, I did use svn for  a year in 1999 a lot, and for few more years later too, a bit, but now it is a source of major annoyance if I need to use it, it's like going back to Fortran 4 or punchcards).

The projects that stick to cvs or svn suffer, as cvs and svn are legacy tools, and forcing it on contributors is counterproductive.

Dima

--
                              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 fricas-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20200229151147.GA12206%40math.uni.wroc.pl.

[Waldek Hebisch]

On Sat, Feb 29, 2020 at 11:01:45AM -0500, Dima Pasechnik wrote:
> On Sat, 29 Feb 2020, 08:11 Waldek Hebisch, <heb...@math.uni.wroc.pl> wrote:
>
> > On Sat, Feb 29, 2020 at 03:48:43PM +0100, Ralf Hemmecke wrote:
> > > > ATM master sources are in svn, so diff is better than pull request.
> > >
> > > When do we switch to git?
> > >
> >
> > Well, some time ago I thought that I am almost ready for switch.
> > But then Camm Maguire wrote "fetch this special gcl branch".
> > Given branch name it worked, but without knowing the name
> > I was unable to find it in gcl git repo.
>
>
> saying "check out that very special commit" from svn repo does not get one
> far either.
>
> So either git
> > allows you to create invisible branches,
>
>
> git branch
>
> lets you list all the branches on a repo.
> Branch is basically a label for a well-behaved subset of commits, not much
> more than that.
> (there are also tags, something a bit different)

So I thought. But all my attempts to list the branch, of course
starting form 'git branch' failed. Yet knowing the name switch
to the branch worked.

> which I consider
> > evil, or I my understanding of git is way below what is
> > needed to effectivly use it. I use git for less important
> > projects, so I can survive using it. But I feel that
> > for me to use it for FriCAS developement is still too
> > inefficient and risky.
> >
>
> one need not be forced to use github/gitlab workflows of pull/merge
> requests. One can instead work with named branches.

Well, for FriCAS traditional branches are of limited use. My
main developement flow is interactive, compiling only edited
files and loading them, while if possible reusing test data
stored in the executing image. In fact, for new code I prefer
interpreter where I can work out expressions on command line,
then wrap them in a function, gradualy function by function
growing the code. Neither git nor svn help with this.

> --------
>
> The bottom line is that nowadays most people either never used svn, or
> already forgot all about it.
>
> (yes, I did use svn for a year in 1999 a lot, and for few more years later
> too, a bit, but now it is a source of major annoyance if I need to use it,
> it's like going back to Fortran 4 or punchcards).
>
> The projects that stick to cvs or svn suffer, as cvs and svn are legacy
> tools, and forcing it on contributors is counterproductive.

Well, I used cvs and svn was a definite progress compared to cvs.
Not so with git, at least for projects like FriCAS. I understand
that there is familiarity factor, different tool feels clumsy
because it is different, regardless of objective features. OTOH
which version control software is in use should not matter much
for contributors, main work is elsewere.

--
Waldek Hebisch

[Dima Pasechnik]

On Sat, 29 Feb 2020, 09:51 Waldek Hebisch, <heb...@math.uni.wroc.pl> wrote:

On Sat, Feb 29, 2020 at 11:01:45AM -0500, Dima Pasechnik wrote:
> On Sat, 29 Feb 2020, 08:11 Waldek Hebisch, <heb...@math.uni.wroc.pl> wrote:
>
> > On Sat, Feb 29, 2020 at 03:48:43PM +0100, Ralf Hemmecke wrote:
> > > > ATM master sources are in svn, so diff is better than pull request.
> > >
> > > When do we switch to git?
> > >
> >
> > Well, some time ago I thought that I am almost ready for switch.
> > But then Camm Maguire wrote "fetch this special gcl branch".
> > Given branch name it worked, but without knowing the name
> > I was unable to find it in gcl git repo.
>
>
> saying "check out that very special commit"  from svn repo does not get one
> far either.
>
> So either git
> > allows you to create invisible branches,
>
>
> git branch
>
> lets you list all the  branches on a repo.
> Branch is basically a label for a well-behaved subset of commits, not much
> more than that.
> (there are also tags, something a bit different)

So I thought.  But all my attempts to list the branch, of course
starting form 'git branch' failed.  Yet knowing the name switch
to the branch worked.

I gather that you switched to a "tag", i.e. a frozen branch (listed by "git tag") 

gcl git repo does not use branches, as far as I can tell,

it uses tags only (the difference is that branches are mutable, whereas tags are not).

No wonder that 

git branch 

does not report anything interesting

dimpase@penguin:/tmp/gcl$ git branch
* master

whereas 

there are quite a few tags:

dimpase@penguin:/tmp/gcl$ git tag | wc -l
175

e.g.

dimpase@penguin:/tmp/gcl$ git tag | grep list_order.21
list_order.21

and so one can do

dimpase@penguin:/tmp/gcl$ git checkout list_order.21
Note: checking out 'list_order.21'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 918026228 undef SGC on alpha for now

> which I consider
> > evil, or I my understanding of git is way below what is
> > needed to effectivly use it.  I use git for less important
> > projects, so I can survive using it.  But I feel that
> > for me to use it for FriCAS developement is still too
> > inefficient and risky.
> >
>
> one need not be forced to use github/gitlab workflows of pull/merge
> requests. One can instead work with named branches.

Well, for FriCAS traditional branches are of limited use.  My
main developement flow is interactive, compiling only edited
files and loading them, while if possible reusing test data
stored in the executing image.  In fact, for new code I prefer
interpreter where I can work out expressions on command line,
then wrap them in a function, gradualy function by function
growing the code.  Neither git nor svn help with this.

git and other VCS are mostly for keeping track of the history of changes (I presume you commit your code to master once in a while), and for testing/merging work of

different people. It's pretty much orthogonal to developing code (unless you/your collaborators work on different features, and

merging them as you go along - in this case branches are useful even locally).

Another extremely useful feature of git is that's easy to set up automated continuous integration

(you certainly don't want to wait for tests for all the different Lisp compilers you support, if you want to check something, and this is very easy with git repo hosted on GitHub or GitLab, you just push a commit there, and

the builds and the tests are run automatically, somethething that doing manually can take days if not weeks)

> --------
>
> The bottom line is that nowadays most people either never used svn, or
> already forgot all about it.
>
> (yes, I did use svn for  a year in 1999 a lot, and for few more years later
> too, a bit, but now it is a source of major annoyance if I need to use it,
> it's like going back to Fortran 4 or punchcards).
>
> The projects that stick to cvs or svn suffer, as cvs and svn are legacy
> tools, and forcing it on contributors is counterproductive.

Well, I used cvs and svn was a definite progress compared to cvs.
Not so with git, at least for projects like FriCAS.  I understand
that there is familiarity factor, different tool feels clumsy
because it is different, regardless of objective features.  OTOH
which version control software is in use should not matter much
for contributors, main work is elsewere.

svn is, however a major stubling block fo people who want to do an occasional contribution, and

have no clue about svn, and it's not only to them, but to the project:

surely they can email a patch, but this way all the checks a VCS can do are not done

 - i.e. one has no idea to which state of the development tree the patch must be applied to,

and whether it will merge cleanly.

In fact, git allows one to email patches synched against a particular branch (git send-email),

and automatically apply these to the right place. (This is how Linux kernel changes are reviewed/merged).

This is another kind of workflow, I suppose sometimes useful (never used it myself though).

Dima

 

--
                              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 fricas-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20200229165118.GA36920%40math.uni.wroc.pl.

[Ralf Hemmecke]

>> one need not be forced to use github/gitlab workflows of pull/merge
>> requests. One can instead work with named branches.
>
> Well, for FriCAS traditional branches are of limited use. My
> main developement flow is interactive, compiling only edited
> files and loading them, while if possible reusing test data
> stored in the executing image. In fact, for new code I prefer
> interpreter where I can work out expressions on command line,
> then wrap them in a function, gradualy function by function
> growing the code. Neither git nor svn help with this.

Sorry to say, but you are wrong at least if you use git.

Forget about the idea that "a commit is something that lives forever in
the repository". You should rather consider git to be a database that
you can freely modify.

The "master" branch is usually used for "linear" development as you know
it from svn trunk.

When you do development locally, you say

git checkout -b NEW-BRANCH-NAME

and all commit you ever do on this branch is never seen by anyone else
unless you push it somewhere. So you can commit after each function you
add to the code. That are, let's say 20 commits. When everything works
for you, you can now decide what to do with all thoses commits.

1) Merge your commit into the master branch.
git checkout master
git merge NEW-BRANCH-NAME
2) Rebase your changes on top of the new master branch in case
the master branch has meanwhile progressed by commits from other
people.
git rebase master
# now "fast-forward" the master branch
git checkout master
git merge --ff-only NEW-BRANCH-NAME
3) You don't want other people to see you intermediate commits, i.e.,
you want to put just one commit on top of master. So you squash all
your 20 commits into just one.

git rebase -i HEAD~21

This brings you into an interaction with git where you can say what
to do with the commits. Except for the first, you mark them as "fix".

After that you do (1) or (2) from above.

Later you say
git branch -D NEW-BRANCH-NAME
and your development branch is gone as if it has never existed.

https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging

Why do you think that doesn't help? Because you do not want to use git
locally for your own safety? It might happen that you develop two
features at the same time. Working on different branches allows you to
keep the feature commits separated without the need to open differnt
working directories.

>> The projects that stick to cvs or svn suffer, as cvs and svn are legacy
>> tools, and forcing it on contributors is counterproductive.
>
> Well, I used cvs and svn was a definite progress compared to cvs.
> Not so with git, at least for projects like FriCAS. I understand
> that there is familiarity factor, different tool feels clumsy
> because it is different, regardless of objective features. OTOH
> which version control software is in use should not matter much
> for contributors, main work is elsewere.

Don't you think that some contributors feel like "oh they are still
using git... uff that's not modern. Let's look somewhere else...".

Of course, main work is somewhere else, but if the first hurdle is
unnecessarily high, that's not good. I'm sure you are clever enough to
learn git than it is for the younger generation to go back and learn svn.

Ralf

[Bill Page]

On Sat, Feb 29, 2020 at 11:02 AM Dima Pasechnik <dim...@gmail.com> wrote:
> ...

> The projects that stick to cvs or svn suffer,
> as cvs and svn are legacy tools, and forcing
> it on contributors is counterproductive.
>

+1 for git. Please.

[Neven Sajko]

Just to add to this message, git supports an interactive rebase history
editing feature. One runs, e.g., git rebase -i master (note the "-i"),
which lets do user select which commits should be edited, squashed,
reordered, etc.

[Kurt Pagani]

On 29.02.2020 15:15, Waldek Hebisch wrote:

> The attached diff solves TeX problem in similar but I
> think slightly better way.

Indeed, perfect (tex_rev2620.pdf). Thanks!

It may also work for TeXmacs,
> but that I did not test it. In particular I do not know
> if "<prime>" is the right TeXmacs sequence to get derivative sign.
>

Unfortunately, TeXmacs doesn't recognize <prime> (tm_rev2620.pdf file).
I use texmacs only with latex commands, i.e. I do not know many key bindings and
the like. It seems, however, that when entering "\prime" in TM, it doesn't work
either (unless sent via an ESC interface sequence). All I found so far:

http://www.texmacs.org/tmweb/manual/webman-math.en.html
3.Main mathematical constructs
Primes, subscripts and superscripts are created as follows:
Shortcut Purpose
' Primes
‘ Back-primes

Maybe one could define a macro in TM to define <prime>? I've no clue at the moment.

[Waldek Hebisch]

On Mon, Mar 02, 2020 at 03:36:34AM +0100, Kurt Pagani wrote:
> On 29.02.2020 15:15, Waldek Hebisch wrote:
>
> > The attached diff solves TeX problem in similar but I
> > think slightly better way.
>
> Indeed, perfect (tex_rev2620.pdf). Thanks!
>
> It may also work for TeXmacs,
> > but that I did not test it. In particular I do not know
> > if "<prime>" is the right TeXmacs sequence to get derivative sign.
> >
>
> Unfortunately, TeXmacs doesn't recognize <prime> (tm_rev2620.pdf file).
> I use texmacs only with latex commands, i.e. I do not know many key bindings and
> the like. It seems, however, that when entering "\prime" in TM, it doesn't work
> either (unless sent via an ESC interface sequence). All I found so far:
>
> http://www.texmacs.org/tmweb/manual/webman-math.en.html
> 3.Main mathematical constructs
> Primes, subscripts and superscripts are created as follows:
> Shortcut Purpose
> ' Primes

> ??? Back-primes

>
> Maybe one could define a macro in TM to define <prime>? I've no clue at the moment.

Well, it seems that the patch get rid of string qoutes (that was
regression due to change in OutputForm). So I commited part of
the patch, but without '<prime>' part for Texmacs. If anybody
knows how to send proper derivative sign to Texmacs please say
(or propose a patch). Otherwise Texmacs interface will be back
at older behaviour, not great but IIRC no so bad either.

--
Waldek Hebisch

[Ralf Hemmecke]

I've setup an automatic check. After applying this patch,

commit 917f06d2921e44f541f0440f693d1f9312a5f5c4
Author: Waldek Hebisch <heb...@math.uni.wroc.pl>
Date: Mon Mar 2 14:55:49 2020 +0000

Generalize GENUPS

git-svn-id:
https://fricas.svn.sourceforge.net/svnroot/fricas/trunk@2626
b0c55286-4f34-0410-a049-a1e7e93b0762

the compilation of libfricas.al aborts with

"ap/GENUPS2.ap", line 60:
(|If| (|Test| (|Has| |#2| (|Apply| |FunctionSpace| |#1|)))
....................................................................^
[L60 C69] #1 (Error) Argument 1 of `FunctionSpace' did not match any
possible parameter type. The rejected type is Join(IntegralDomain,
RetractableTo(Integer)) with .
Expected type Comparable.

aldor -Wname=fricas -Mno-abbrev -Mpreview -Y al -L
FriCASLib=fricas_INTAF -fao=ao/INTAF.ao ap/INTAF.ap 2>&1 | tee
tmp/INTAF_ao.out
"ap/GENUPS2.ap", line 60:
(|If| (|Test| (|Has| |#2| (|Apply| |FunctionSpace| |#1|)))
....................................................................^
[L60 C69] #1 (Error) Argument 1 of `FunctionSpace' did not match any
possible parameter type. The rejected type is Join(IntegralDomain,
RetractableTo(Integer)) with .
Expected type Comparable.

Obvioustly, we have

FunctionSpace(R : Comparable) : Category == Definition where

but you only require

GenerateUnivariatePowerSeries2(R, FE) : Exports == Implementation where
R : Join(IntegralDomain, RetractableTo Integer)
FE : Join(Ring, RetractableTo SY)

so

if FE has FunctionSpace(R) then

cannot work. You need

R : Join(IntegralDomain, RetractableTo Integer, Comparable)

It compiles fine with the attached patch.

Ralf

[Waldek Hebisch]

On Mon, Mar 02, 2020 at 08:21:58PM +0100, Ralf Hemmecke wrote:
> I've setup an automatic check. After applying this patch,
>
> commit 917f06d2921e44f541f0440f693d1f9312a5f5c4
> Author: Waldek Hebisch <heb...@math.uni.wroc.pl>
> Date: Mon Mar 2 14:55:49 2020 +0000
>
> Generalize GENUPS
>
> git-svn-id:
> https://fricas.svn.sourceforge.net/svnroot/fricas/trunk@2626
> b0c55286-4f34-0410-a049-a1e7e93b0762
>
> the compilation of libfricas.al aborts with
>
> "ap/GENUPS2.ap", line 60:
> (|If| (|Test| (|Has| |#2| (|Apply| |FunctionSpace| |#1|)))
> ....................................................................^
> [L60 C69] #1 (Error) Argument 1 of `FunctionSpace' did not match any
> possible parameter type. The rejected type is Join(IntegralDomain,
> RetractableTo(Integer)) with .
> Expected type Comparable.
>

<snip>

>
> Obvioustly, we have
>
> FunctionSpace(R : Comparable) : Category == Definition where
>
> but you only require
>
> GenerateUnivariatePowerSeries2(R, FE) : Exports == Implementation where
> R : Join(IntegralDomain, RetractableTo Integer)
> FE : Join(Ring, RetractableTo SY)
>
> so
>
> if FE has FunctionSpace(R) then
>
> cannot work.

What about attached patch.

Note: I prefer to weaken requirements of GenerateUnivariatePowerSeries2,
instead of replacing them by stronger ones.

--
Waldek Hebisch

[Ralf Hemmecke]

Hi Waldek,

you can commit it. After applying to trunk, the libfricas.al build works
again.

Thank you,
Ralf

[Waldek Hebisch]

Trunk is now closed for release. In next days I will add
release notes, create release branch and tarballs.

--
Waldek Hebisch

[Kurt Pagani]

Good :)

BTW I compiled yesterday the current rev (fresh clone). I guess the version
dates (2018) were already wrong in the last release (1.3.5 / 3 February 2019;
according to https://en.wikipedia.org/wiki/FriCAS)? Or asked differently, is
there a special policy?


FriCAS Computer Algebra System
Version: FriCAS 2018-03-10
Timestamp: Thu Mar 5 20:11:13 CET 2020
-----------------------------------------------------------------------------
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave FriCAS and return to shell.
-----------------------------------------------------------------------------


(1) -> )version
Value = "FriCAS 2018-03-10 compiled at Thu Mar 5 20:11:13 CET 2020"
(1) ->

[Waldek Hebisch]

On Fri, Mar 06, 2020 at 09:25:54PM +0100, Kurt Pagani wrote:
> Good :)
>
> BTW I compiled yesterday the current rev (fresh clone). I guess the version
> dates (2018) were already wrong in the last release (1.3.5 / 3 February 2019;
> according to https://en.wikipedia.org/wiki/FriCAS)? Or asked differently, is
> there a special policy?

Yes. The policy is: in the mainline date is date of last modification
to configure.ac. Release gets number and no date.

--
Waldek Hebisch