Planning new release

[Waldek Hebisch]

I think that we should have new release around September. If
thing went really well it could be closer to endo of August,
but experience shows that there are always some delays, so
September is more realistic. OTOH I do not want to delay too
much, I would really prefer to release before end of September.

I currently have several things in various stages of developement,
I will try to include what is ready, but ATM I do not know
which one will be ready.

I think that for this release we should bump middle number,
that is call it 1.4.0. We have already more changes than
in typical recent release and it makes sense to reflect
this in release number.

--
Waldek Hebisch

[Qian Yun]

I'll try to make the kernel cache recycle patch ready soon.

And I'd like to include https://github.com/fricas/fricas/pull/213
(Replace sprintf usage), ignore the "rename fricas_sprintf helpers"
part. What do you think?

- Qian

[Ralf Hemmecke]

I would definitely like these two commits to be merged to the new release.

https://github.com/fricas/fricas/compare/master...hemmecke:fricas:wip/jfricas

See also

https://groups.google.com/g/fricas-devel/c/sTWdp7tkfcs/m/XItOsf1XBwAJ

I think that also the SPAD code is stable for inclusion into FriCAS.
In fact, except for those few changes to the ioHooks, there is no
interference with other parts of the FriCAS code base.
Everything is concentrated in jfricas.spad.

Ralf

PS: I'll soon be without Internet till end of August

[Waldek Hebisch]

On Sat, Aug 01, 2026 at 12:24:21PM +0200, 'Ralf Hemmecke' via FriCAS - computer algebra system wrote:
> I would definitely like these two commits to be merged to the new release.
>
> https://github.com/fricas/fricas/compare/master...hemmecke:fricas:wip/jfricas
>
> See also
>
> https://groups.google.com/g/fricas-devel/c/sTWdp7tkfcs/m/XItOsf1XBwAJ
>
> I think that also the SPAD code is stable for inclusion into FriCAS.
> In fact, except for those few changes to the ioHooks, there is no
> interference with other parts of the FriCAS code base.
> Everything is concentrated in jfricas.spad.

ATM I can not test the changes so I waited a bit to hear if
some other person tested it. In general the code looks OK.
I have few small doubts concerning changes to the ioHooks.
First, since we have "startPrompt" logically it should be
matched with "endPrompt". Second, markers are used by
Texmacs interface, so change to markers is likely to
break it. Third, normally I do such changes as a separate
commit, so that actual functional changes/additions are
not cluttered with irrelevant stuff.

--
Waldek Hebisch

[Waldek Hebisch]

On Sat, Aug 01, 2026 at 09:43:23AM +0800, Qian Yun wrote:
> I'll try to make the kernel cache recycle patch ready soon.
>
> And I'd like to include https://github.com/fricas/fricas/pull/213
> (Replace sprintf usage), ignore the "rename fricas_sprintf helpers"
> part. What do you think?

I have mixed feelings about this. I understand that people
want to do things following the rules. And there may be some
gain when code compiles without warnings at high warnings
settings. But this looks mainly as following rules just
to follow them. For example 'perror' is performing I/O and
the code does not check that perror was successful. But
'perror' in the patch is may fail with similar probablity
as 'write' (in both cases failure probablity is extremaly
low). The 'sprintf' changes in 'edible.c' are to debugging
code which is normally not compiled.

AFAICS gcc now understands 'sprintf' well enough that in
our use cases (buffers of known size) there is no gain
from using 'snprintf'. Rather, we may adjust sizes to
make sure that overflow is impossible.

--
Waldek Hebisch

[Dima Pasechnik]

On August 1, 2026 8:34:17 PM CDT, Waldek Hebisch <de...@fricas.org> wrote:
>On Sat, Aug 01, 2026 at 09:43:23AM +0800, Qian Yun wrote:
>> I'll try to make the kernel cache recycle patch ready soon.
>>
>> And I'd like to include https://github.com/fricas/fricas/pull/213
>> (Replace sprintf usage), ignore the "rename fricas_sprintf helpers"
>> part. What do you think?
>
>I have mixed feelings about this. I understand that people
>want to do things following the rules. And there may be some
>gain when code compiles without warnings at high warnings
>settings. But this looks mainly as following rules just
>to follow them. For example 'perror' is performing I/O and
>the code does not check that perror was successful. But
>'perror' in the patch is may fail with similar probablity
>as 'write' (in both cases failure probablity is extremaly
>low).

perror writes to stderr, which is
probably a different stream, much more robust - and no, there is no easy way to test whether perror failed, as it does not return anything.

The patch obviously makes the code more robust.

The 'sprintf' changes in 'edible.c' are to debugging
>code which is normally not compiled.

And? Let's keep buggy debugging code?

>
>AFAICS gcc now understands 'sprintf' well enough that in
>our use cases (buffers of known size) there is no gain
>from using 'snprintf'. Rather, we may adjust sizes to
>make sure that overflow is impossible.

gcc is not the only game in town.
Besides, why not leave this job to the compiler, instead of doing it manually, as you propose...



>

[Qian Yun]

I'd like to updated the year and percentage in FAQ:

"""
As of April 2013, in the src/algebra subdirectory,
which hosts mathematical functionality about 25% of code was added
after the fork.
"""

So we started with 153k (lines of code) in src/algebra,
then removed 11k literate boilerplate, changed 40k during
"whitespace Normalize", now at 224k. Git blames shows 72k
lines are never touched.

So if we take 153-11=142k as baseline, then
72~112k might not be changed,
at least 82k are newly added,
30~70k are modified.

So the new number shall be 82/142 (37%) or 82/224 (58%)?

- Qian

On 8/1/26 8:03 AM, Waldek Hebisch wrote:

[Waldek Hebisch]

On Sun, Aug 02, 2026 at 11:46:54AM +0800, Qian Yun wrote:
> I'd like to updated the year and percentage in FAQ:
>
> """
> As of April 2013, in the src/algebra subdirectory,
> which hosts mathematical functionality about 25% of code was added
> after the fork.
> """
>
> So we started with 153k (lines of code) in src/algebra,
> then removed 11k literate boilerplate,

There are several files that are removed, so baseline is slightly
lower.

> changed 40k during
> "whitespace Normalize", now at 224k.

In the statement above I deliberately exluded changed lines.
In fact, in the process I may have undercounded added lines,
but that figure were intended to be approximate anyway.

> Git blames shows 72k
> lines are never touched.
>
> So if we take 153-11=142k as baseline, then
> 72~112k might not be changed,
> at least 82k are newly added,
> 30~70k are modified.
>
> So the new number shall be 82/142 (37%) or 82/224 (58%)?

I counted lines in new files (they are essentially 100% new code). Then
added increase in size in few heavily modified files like efstruct
or combfunc. The figure you get in this way is lower, but corresponds
better to notion of 'new code'. Some modification are deep enough
to count as new code, some are improvement but are clearly
modification as opposed to new thing, some modifications are
trivial. It would be hard work to distinguished them, so I counted
none of this as new code. Some files are joined to have less files.
IIUC 'git blame' counts moved code as new one.

BTW: LOC may mean "non whitespace not comment lines". That gives
lower counts and probably gives lower percentage of new code
(as new code have some longish "literate" sections absent in
old code), but the difference in precentage should not be big.

I have the followin Perl script to keep only code lines:

$skipping = 0;
while(<>) {
if (/^\)if (false|LiterateDoc)/) {
$skipping = 1;
}
if (/\)endif/) {
$skipping = 0;
next;
}
if ($skipping == 1) { next; }
if (/^ *(--|\+\+)/) { next; }
if (/^$/) { next; }
print;
}

Using it I get 90728 LOC in NAG version, 134910 LOC in current trunk.
This script can not handle literate boilerplate, so can not handle
Axiom at time of the fork. But compared to NAG version there were
tiny changes, so 32% is practially a lower bound on new code.
--
Waldek Hebisch

[Waldek Hebisch]

Quick and dirty removal of "literate" boilerplate on "New algebra
bootstrap" commit to FriCAS repository gives 137634 wc lines
which correspond to 83017 LOC. This may undercount a bit, because
handling of "literate" constructs is very crude. But complicated
things were rare, so there should be not much difference. OTOH there
is question how to count guessing package by Martin Rubey. It
was included in wh-sandbox before fork, but it was not build
as part of mainline Axiom at that time or later (later code was
included in Axiom repository, but it was unused). Anyway,
taking at face value LOC counts we would get 38% of added code.

The following files are completetly removed:

ddfact.spad.pamphlet moddfact.spad.pamphlet
cyclotom.spad.pamphlet rdesys.spad.pamphlet
ffx.spad.pamphlet formula.spad.pamphlet
pdecomp.spad.pamphlet rderf.spad.pamphlet
unifact.spad.pamphlet

Parts of other files are removed, parts are modified to be shorter.
So reasonable estimate is that now we have about 40% of new code.

--
Waldek Hebisch

[Grégory Vanuxem]

Personally I think this is good, the object. Although pb-s related to Kernel related things make me dubious. I am pretty sure something good what happens. It's beyond me.

Greg