On 6/2/24 08:29, Qian Yun wrote:
On 6/2/24 02:24, Waldek Hebisch wrote:
It seems that all discovered issues are resolved now. It is not
clear to me it is worth splitting disscusion into separate threads.
Concerning splitting patches, I think it would be natural to
commit chages
On 6/2/24 02:24, Waldek Hebisch wrote:
On Sat, Jun 01, 2024 at 12:56:26PM +0800, oldk1331 wrote:
Hmm... cannot we also have something like this -paste option
for the .ps file generation?
To Ralf: we can, but we also decided to decouple book generation
with hypertex pages generation.
This patch is to fix https://github.com/fricas/fricas/issues/170,
aka when quitting FriCAS, the HyperDoc started by ")hd" should
exit properly.
"viewman" started by ")startGraphics" can exit properly,
see src/graph/viewman/viewman.c line 188:
viewType = get_int(spadSock);
if
On 6/1/24 13:04, Ralf Hemmecke wrote:
On 6/1/24 06:56, oldk1331 wrote:
Hmm... cannot we also have something like this -paste option
for the .ps file generation?
To Ralf: we can, but we also decided to decouple book generation
with hypertex pages generation.
I somehow meant that there is
Commit fcacacff fixed one regression in radicalSolve,
but it introduces another:
(1) -> radicalSolve(8*x^3+12*x^2+6*x-1,x)
+---+ +-+ +---+ +-+
- \|- 1 \|3 - 3 \|- 1 \|3 - 3
(1) [x = , x = --, x = 0]
On 5/31/24 00:38, Waldek Hebisch wrote:
On Thu, May 30, 2024 at 07:43:30PM +0800, Qian Yun wrote:
On 5/29/24 22:51, Waldek Hebisch wrote:
first build went fine, but a few later failed. Actually, it looks
worse than previous version where probability of success looked
higher.
Yes
On 5/29/24 22:51, Waldek Hebisch wrote:
first build went fine, but a few later failed. Actually, it looks
worse than previous version where probability of success looked
higher.
Yes, problem is because some .tex files are truncated. In one run it
was 'ug10.tex', in few cases it was
Qian
On 5/29/24 19:37, Ralf Hemmecke wrote:
On 5/29/24 11:24, Qian Yun wrote:
Do you think this is a problem that needs to be fixed before commit?
If I had something to say, I would like to solve that problem once and
for all. Would it be too hard to synchronize the writeout of files by a
On 5/27/24 22:10, Waldek Hebisch wrote:>
What's its CPU model and how many threads are you using to build
the book?
Quad core Core 2 2.4.GHz. I just did 'make book', that is serial
build.
I limit my CPU to 800MHz, but still can't reproduce it.
I suspect that this may disc drive. I
Seems like ")trace" can count function calls:
)trace COMPLEX )math )count
complex(2,3)^2
)trace )stats
- Traced function execution counts -
Complex.*,33 : 1 times
Complex.+,31 : 0 times
Complex.-,32 : 0 times
Complex.OMwrite,20 : 0 times
On 5/27/24 10:00, Waldek Hebisch wrote:
On Mon, May 27, 2024 at 08:50:31AM +0800, Qian Yun wrote:
OK, what's the version of texlive on this old machine?
epstopdf has inside comment saying: 2014-06-18
Changelog shows "2017/01/07 v2.26". I can add "--output="
to ma
OK, what's the version of texlive on this old machine?
What's its CPU model and how many threads are you using to build
the book?
- Qian
On 5/27/24 07:37, Waldek Hebisch wrote:
On Fri, May 17, 2024 at 08:38:35PM +0800, Qian Yun wrote:
I'd like to upstream my improvements to the reference book
lso I don't like its overhead when we only read a few bytes,
I hope in the future we can avoid the overhead if we are
building in release mode (aka when there is no DEBUG defined).
- Qian
On 5/26/24 20:05, Waldek Hebisch wrote:
On Sat, May 25, 2024 at 06:27:10PM +0800, Qian Yun wrote:
verbatim
"algebra stream" output, the default setting is a bit short.
- Qian
On 5/17/24 20:38, Qian Yun wrote:
I'd like to upstream my improvements to the reference book.
The patches are in this branch:
https://github.com/oldk1331/fricas/commits/new-ps-book/
1. build book with PS images
Sorry, the problem is not "fricas_sprintf_to_buf", but
"extern char errorStr [80];".
I want to avoid this global variable and implementation
detail to leak to util.c.
- Qian
On 5/24/24 23:40, Waldek Hebisch wrote:
On Fri, May 24, 2024 at 05:04:08PM +0800, Qian Yun wrote
On 5/24/24 06:32, Waldek Hebisch wrote:
I am not sure. At least we world need proper dependencies. Most of
those files are categories. We compile categories because compiling
may need to load compiled categories. And compiling a category need
categories that it uses. Our list of
I wanted to avoid pulling in "fricas_sprintf_to_buf".
Turns out I can use
const char *errorStr = "read from viewport manager\n";
Are you OK with this?
- Qian
On 5/24/24 07:19, Waldek Hebisch wrote:
It is good to fix buffer overflow. But you also remove error
checking (use of 'check').
The daase generation is not that long on a fast machine:
it's around 25 seconds with sbcl.
boo_db.input
)boot $SaveParseOnly := true
)read komp_all.input
)boot processGlobals()
)boot $SaveParseOnly := nil
)boot $bootStrapMode := true
)boot $bootstrapDomains := true
)boot $createLocalLibDb
This patch fixes many memory issues related with title --
especially with long titles in graphs.
The fix includes:
1. memory overwrite in 'spadAction'
(1) -> vp := draw(x,x=1..2); title(vp, new(100, "a".1)$String)
Compiling function %C with type DoubleFloat -> DoubleFloat
Graph data
I'd like to upstream my improvements to the reference book.
The patches are in this branch:
https://github.com/oldk1331/fricas/commits/new-ps-book/
1. build book with PS images generated by FriCAS
https://github.com/oldk1331/fricas/commit/b1def5000c1fe4db3c68ac6a189dccb6b839d667
2. fix chapter
OK, so for radicals, there should be a much more effective
method to determine its sign. Seems like current method is
mostly focused on polynomials and pretty limited for radicals.
- Qian
On 5/15/24 19:12, Waldek Hebisch wrote:
On Wed, May 15, 2024 at 06:47:45PM +0800, Qian Yun wrote:
You
You said before AlgebraicNumber should represent any branch
of the root, but here we are talking about the sign of radical.
Does that mean we are taking a specific branch interpretation here?
- Qian
On 5/15/24 17:42, Waldek Hebisch wrote:
TrigonometricManipulations (which implements imag) is
One possible explanation:
)compile a spad file clears internal Kernel cache.
So the following computation can have messed up Kernel order.
So after compiling a spad file, do not use kernels created before that.
- Qian
On 5/14/24 22:40, Ralf Hemmecke wrote:
Some more experiments with the
Hi,
Can you tell me more about the advantages of installer over zip file?
(Other than start menu entry and desktop icon.)
Also, it would be good to integrate it with Github CI.
- Qian
On 5/13/24 07:43, Grégory Vanuxem wrote:
Hello folks,
Below is a link to a Windows setup program to install
+ # path >= # $spadroot and EVERY(function CHAR_=, $spadroot, path)
On 5/14/24 01:40, Waldek Hebisch wrote:
On Mon, May 13, 2024 at 08:52:12PM +0800, Qian Yun wrote:
The following patch works.
Do we need to compare PATHNAME_-DEVICE as well
(returns "C" in this case) in 'isSystemDirec
atchpad II File Name Functions
-isSystemDirectory dir == EVERY(function CHAR_=,$spadroot,dir)
+isSystemDirectory file ==
+ p1 := BUTLAST PATHNAME_-DIRECTORY file
+ p2 := PATHNAME_-DIRECTORY pad_directory_name $spadroot
+ p1 = p2
On 5/13/24 19:52, Qian Yun wrote:
Yes, make 'updateCategoryTabl
his originates and how to fix it.
- Qian
On 5/13/24 19:05, Waldek Hebisch wrote:
On Mon, May 13, 2024 at 06:32:10PM +0800, Qian Yun wrote:
I modified i-coerce.boot, then in FRICASsys,
)read i-coerce
)lisp (defun GLESSEQP (X Y) (BREAK))
series(sin x)
The above has no problem in Linux, but f
, Qian Yun wrote:
Some other updates:
This happens for Clozure CL as well.
This does not happen for fricas0, either compile-mode or
interpret-mode.
Very strange indeed.
I'll compare call stack to interpreter later.
On Linux I can do the following and the example still works:
1) Disable
I build with CCL on windows again today, and find that my
previous fix d2d7e978d3de17cdadb184ee7c08deed182116fe
is not enough:
I think it needs to have the :win32 feature at compile time,
otherwise the reader macro will discard unused branch
when compiling |trim_directory_name|.
So I moved the
, Qian Yun wrote:
The *.daase generated on linux and windows are *exactly* the same
(except for the timestamp, of course).
Thanks, so that was bad guess.
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubs
The *.daase generated on linux and windows are *exactly* the same
(except for the timestamp, of course).
The corresponding fricas0 changes is here, is this expected?
https://github.com/oldk1331/fricas0-repo/commit/74b1193cfcf2f33909f8bad55785c14cf9e02cd8.patch
BTW, can you explain a bit more
.
At first glance change to i-resolv.boot is most likely to produce
effect below. OTOH it should do the same thing an all systems...
Le ven. 10 mai 2024 à 15:32, Qian Yun a écrit :
The recent commit "Simplify and fix ordering predicate"
causes regression on windows only, strange.
The recent commit "Simplify and fix ordering predicate"
causes regression on windows only, strange.
The failed test is in series3.input:
testcase "crashes coercing power series (#122, #136)"
a := series(sin(x))
testTrue("(a*1.0; true)")
testTrue("(1.0*a; true)")
Interpreter can't find proper
I've updated
https://github.com/oldk1331/fricas/commits/new-ps-book/
to
https://github.com/oldk1331/fricas/commit/d88925e40c7aa14c776d7b2c99d1fc8483a57d27
This enables build of the book with pdflatex.
Together with previous commit "build with ps image",
these two commits removes almost 113K
For the reference book built with 1.3.10 release,
I believe the following 3 buttons are no longer available:
"Related operations" Figure 14.14 (page 874)
"generalize" Figure 14.19 (page 883)
"all domains" Figure 14.20 (page 883)
- Qian
--
You received this message because you are subscribed
dek Hebisch wrote:
On Mon, May 06, 2024 at 08:29:44PM +0800, Qian Yun wrote:
In page 242 of book.pdf (from 1.3.10 release), the "write" under
item "viewWriteDefault" is not correctly colored: only a quote is
colored as red.
The definition from fricas.sty is:
\New
On 5/7/24 22:08, Dima Pasechnik wrote:
sorry, typo, I meant
ps2eps knot3.ps
Thanks, I didn't know about this ps2eps tool.
It does convert knot3.ps to a proper eps format.
knot3.ps (and a few other vector images) will be removed very soon,
because we'll be able to generate them
On 5/7/24 21:45, Dima Pasechnik wrote:
On Tue, May 7, 2024 at 12:51 PM Qian Yun wrote:
Some decisions need to be made in order to build book with pdflatex.
1. src/doc/ps/ images.
These are hyperdoc images. They are in ps format, but actually are
bitmap images. pdflatex can't handle ps
Some decisions need to be made in order to build book with pdflatex.
1. src/doc/ps/ images.
These are hyperdoc images. They are in ps format, but actually are
bitmap images. pdflatex can't handle ps format directly, so I
suggest to convert them into png format.
2. If the answer to previous
Does this error persist if you redo the build by
cd src/doc; make clean; make book.pdf ?
If it persists, can you examine tmp/ug07.spool to see if there's
error related with the generation of this image.
- Qian
On 5/7/24 01:05, Ralf Hemmecke wrote:
This time the following error shows. And
In page 242 of book.pdf (from 1.3.10 release), the "write" under
item "viewWriteDefault" is not correctly colored: only a quote is
colored as red.
The definition from fricas.sty is:
\NewDocumentCommand{\spadfunFrom}{v v}{\spadfun`#1`}
Looks like the "`" is colored here. But this doesn't
I have not met the races in graphics, but Ralf, Waldek and
I have all met the races in sman:
Namely, when building the book, sometimes there's a few lines
missing at the beginning or at the end of the tex file.
The tex file comes from spool file, which is the piped output
of "fricas" script.
On 5/6/24 13:35, Grégory Vanuxem wrote:
Hello Qian,
Le sam. 4 mai 2024 à 09:58, Qian Yun a écrit :
On 5/4/24 15:30, Grégory Vanuxem wrote:
As a matter of fact, use of FLINT in FriCAS:
My experience with FLINT is that is uses dense representation
for univariate polynomial
On 5/5/24 00:09, Waldek Hebisch wrote:
On Sat, May 04, 2024 at 11:13:14PM +0800, Qian Yun wrote:
On 5/4/24 22:01, Ralf Hemmecke wrote:
Anyway, by building with -j1 I got your branch compiled with a view3D
still running with 100% cpu usage after the build had successfully
finished.
I've
On 5/4/24 22:01, Ralf Hemmecke wrote:
Anyway, by building with -j1 I got your branch compiled with a view3D
still running with 100% cpu usage after the build had successfully
finished.
I've never met this before.
Looking at the book is a pleasure now. Qian, you really did a great job.
That's probably caused by tmp/ug07.input.
It doesn't hang here, but I do find that there are remaining processes
like viewman and view3D.
The problem is that there are multiple unclosed viewports.
The following fixup patch should solve that: by adding 5 images to
the book (section 7.1.9 and
On 5/2/24 20:51, Ralf Hemmecke wrote:
Another solution might be to add some ioHook to the "output" function.
I haven't actually looked into that.
I believe this is the correct path to go.
The documentation of "output$OutputPackage" explicitly says this
function displays its argument to
I found this by accident, when comparing trunk book against
1.3.10 book.
In section 8.5.3 (page 316), there were 6 solutions.
(1) -> radicalSolve([3*x^3+y+1,y^2-4],[x,y])
(1) [[x = - 1, y = 2], [x = - 1, y = 2]]
Git bisect points to 50f391bc.
This raises the question that how can
On 5/4/24 15:30, Grégory Vanuxem wrote:
As a matter of fact, use of FLINT in FriCAS:
My experience with FLINT is that is uses dense representation
for univariate polynomial.
That representation makes it fast for multiplication (when polynomials
are dense).
But I think very spare
On 5/4/24 12:43, Grégory Vanuxem wrote:
Hello,
I have found 'devaluate' in some Spad files and it can be handy. Some
domains are parameterized and it is not possible, or at least I don't
know how to do it, to use ' is ' instead of ' has ' (Domain vs.
Category) for them:
if R is Foo then
I have committed all related patches, the patch in this thread is
the last one.
I have updated it a little bit to improve the build process and
fixed the pictures in section 10.5.
https://github.com/oldk1331/fricas/commit/e34fadc066ee34b4b6a56ceadfa3284934166999
So your changes should be based
I guess by adding this new signature, it will cause problems for
type conferencing in compiler/interpreter.
There will be much more possibilities to consider.
IIRC, there's already performance issues when compiling expressions
with lots of "/", for example when solving radical roots for
degree
In book section 6.19, the Pascal's triangle is not displayed.
It seems that "output" function displays stuff that are not
enclosed by ioHook.
Ralf, are you aware of this issue, and any ideas to fix it?
- Qian
--
You received this message because you are subscribed to the Google Groups "FriCAS
Currently, draw(x,x=0..10,unit==[1.0,2.0])
does not show units by default, you have to click the control
panel button or use 'units(%,1,"on")'.
I think that by specifying "unit" options in "draw", the intention
is to show units.
This is also the case in some of the graphs in reference book,
for
For "filecopy", it's absurd to do IO char by char.
For "|waitForViewport|", this is left over of the previous
"obey" -> "|run_shell_command|" change. Also avoid spawning
lot's of threads.
- Qian
diff --git a/src/graph/Gdraws/Gfun.c b/src/graph/Gdraws/Gfun.c
index 292f8b3b..2ec625c3 100644
This patch will make the font of title bigger than the axes label
(X/Y/Z) and units in PS image output.
This will make the default output more suitable for the book.
Unfortunately the font size is not customizable at SPAD level.
BTW, I checked the original book, most images are without title.
On 4/26/24 18:23, Qian Yun wrote:
On 4/26/24 06:00, Waldek Hebisch wrote:
There is some problem with this. On my machine I got faulty
'TEXTFILE.tex', it contained '\begin{noOutputXtc}' but no
matching end part, causing documentaion build failure.
This does not always happen
On 4/19/24 22:01, Waldek Hebisch wrote:
On Fri, Apr 19, 2024 at 12:42:19AM -0700, 'Nasser M. Abbasi' via FriCAS -
computer algebra system wrote:
FYI,
This is update for the final summer 2024 edition of CAS integration tests
about the issue Fricas giving zero for non zero integrand.
There
On 4/26/24 06:00, Waldek Hebisch wrote:
There is some problem with this. On my machine I got faulty
'TEXTFILE.tex', it contained '\begin{noOutputXtc}' but no
matching end part, causing documentaion build failure.
This does not always happen, and sometimes happen to other
tmp/*tex file.
e.com/d/msgid/fricas-devel/3d4c161e-12ff-4bc3-8d82-7d0ed05f6d68%40gmail.com.
From 46b2e034148674eb05834d8a642d337b1162b897 Mon Sep 17 00:00:00 2001
From: Qian Yun
Date: Thu, 25 Apr 2024 21:27:43 +0800
Subject: [PATCH] generate book with ps image instead of bitmap image
---
src/doc/Ma
This is the final piece of my fixes to PS output.
As discussed in previous thread, this patch enables title to
be shown in PS format output.
But I did not add a option to enable/disable the drawing of
frame over viewWindow and titleWindow. First, this feature
does not exist for the screen
Unlike the 3D case, where "GDrawPoint" is only limited involved,
in 2D case, "GFillArc" and "GDrawLine" are more widely used,
and even are used to draw the X11 interface itself.
So to avoid a bigger change and breakage, I duplicated code
to add new function "GColorFillArc" and "GColorLine".
Currently, when using "write" to write out a viewport, we have
"image.bm", "image.xpm", but also "fricas2D.ps", "fricas3D.ps".
This patch makes PS output to have unified name "image.ps".
This is more consistent and easier for follow up Makefile treatment.
Note that in the view2D/view3D control
The patch deals with the beginning stage, transferring data
from fricas to view2/3D, that code deals with the ending stage,
writing data from view2/3D to disk.
Also the problem raised by "THEMOS" is mitigated by the "Fix" part.
But!!! The mitigation was invalided by my "OBEY"->"|run_program|"
I did not notice that "xvfb" is preinstall in the Linux CI
environment and thus the viewports have always been build
in the past.
Now after this patch, I can see the build time on Linux CI
(2 cores) has been dropped from 6m20s to 5m40s, about 10%.
And we can observe if this patch causes
There is https://github.com/oldk1331/fricas0,
where fricas exists in the form of pure lisp,
but it is not in the sense of a "traditional lisp library"
by ASDF or DEFPACKAGE.
I can look into this direction.
- Qian
On 4/20/24 17:47, Dima Pasechnik wrote:
How does one do this?
(with ECL or
Currently fricas-readline is not installed to ./target/*/bin/.
I find it useful to debug with readline support:
cd target/x86_64-linux-gnu
FRICAS=. ./bin/fricas -rl
Because readline's history feature is really convenient when
you need to input the same things over and over again during
Also the calculation of rgb and print of "setrgbcolor"
should be made into a separate function, because the
2D PS output will need this as well.
- Qian
On 4/19/24 19:10, Qian Yun wrote:
I'd like to also include the following in this patch.
You will notice that the ps output has a st
On 4/19/24 20:41, Waldek Hebisch wrote:
Long ago I looked at communication protocol between various
processes that we use and my conclusion was that it is
inherently racy: there are parallel chanels of communication
and both ends assume that data comes in right order. I added
a little piece
You can notice a "pause" when you draw a picture like:
(1) -> draw(x,x=1..2)
Compiling function %C with type DoubleFloat -> DoubleFloat
Graph data being transmitted to the viewport manager...
FriCAS2D data being transmitted to the viewport manager...
<<<>>>
(1)
oat)((int)(psShadeMax-0.3*psShadeMax)-1)*psShadeMul,dFlag);
+GSetForeground(GC9991, psWhite, dFlag);
quadMesh[0].x = 0; quadMesh[0].y = 0;
quadMesh[1].x = graphWindowAttrib.width+2;
quadMesh[1].y = 0;
On 4/18/24 17:57, Qian Yun wrote:
Currently we get mono color in postscr
On 4/16/24 22:38, Waldek Hebisch wrote:
Just a silly question: have you looked why the image is so big?
Your new image is 6.7M and bigger than scanned version (4.3M).
Old knot3.ps is 77k lines giving 1.1M size. At first glance
adding color to this could double or maybe triple the size.
.pdf
Currently we get mono color in postscript output of "smooth" style
3D drawings.
That's caused by "GSetForeground" before "GDrawPoint".
"GSetForeground" can only set gray scale.
Luckily the all four usage of "GDrawPoint" are all for the purpose
of generating "smooth" style image. So this change
20:47, Qian Yun wrote:
(I have not tried to implement the following idea in FriCAS.)
I have always liked the idea presented in SICM (sister book
of SICP) Structure and Interpretation of Classical Mechanics:
https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/9579
vp := draw(x*y,x=0..1,y=0..1,style=="smooth")
write(vp, "t1", "postscript")
Then check "t1.VIEW/fricas3D.ps", you'll see only axes there.
After this patch, there will be black and white image. (this is
another bug.)
However, if you save the image by clicking buttons in
the control panel, you
This "title" thing is more complex than I thought.
For vp:=draw(x,x=0..1); write(vp,"pic", FORMAT)
When FORMAT is:
"pixmap" or "bitmap":
generates 400x400 image, title is the same as screen output
"image":
generates 300x324 image, title is 24 pixel higher than screen output
"postscript":
On 4/17/24 08:18, Waldek Hebisch wrote:
On average a "shade" style picture takes around 50-200KB and
a "smooth" style picture takes 200-400KB depending on the complexity
of the picture.
I admit that for me "shade" style looks better than "smooth".
For knot3 I'm OK with both "shade" and
On 4/16/24 22:38, Waldek Hebisch wrote:
On Tue, Apr 16, 2024 at 06:11:56PM +0800, Qian Yun wrote:
I can now generate all images from sources listed in appendix.
Good.
Although only src/doc/ps/knot3.ps is currentlly used in chapter 7.
We can delete this 70k line ps file from repo now
(I have not tried to implement the following idea in FriCAS.)
I have always liked the idea presented in SICM (sister book
of SICP) Structure and Interpretation of Classical Mechanics:
https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/9579/sicm_edition_2.zip/chapter001.html
Currently we have image.bm, image.xpm for bitmap image,
but for PS image, we have fricas2D.ps and fricas3D.ps.
I suggest to use "image.ps" instead, opinions?
- Qian
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To
It is definitely possible to control the inclusion, but that means
adding another global variable. Because it also affects the size of
BoundingBox.
Since this "title and frame" is not there for the past decades,
I think we can start freshly by choosing "title inside
viewWindow and no frame"?
-
By default, there's no "title" in PostScript output.
Simply enable "Gdraws_drawFrame" in src/graph/Gdraws/Gfun.c
will give you "title" back, along with "frame" (thin lines)
around titleWindow and viewWindow.
That's a discrepancy with the xpm format.
Also the position of "title" in PS format is
e:
On Fri, Apr 12, 2024 at 06:25:26PM +0800, Qian Yun wrote:
We have discussed this before, namely the default dynamic-space-size
is not enough during build.
Recently there is a github issue hitting by this on freebsd.
I get hit by this issue a few times as well, because the default
"./confi
it into a separate function, because it will be
used in both Gdraws_setDimension and PSCreateFile.
Second patch is to adjust the position of BoundingBox.
- Qian
On 4/13/24 21:14, Waldek Hebisch wrote:
On Sat, Apr 13, 2024 at 05:25:17PM +0800, Qian Yun wrote:
One of the problems of postscript
One of the problems of postscript files generated by "draw" is that
it is not proper "embedded postscript file", aka "eps".
When trying to include such image files in latex document, there are
huge padding around image.
The problem is caused by "BoundingBox". We have "BoundingBox" in
generated
we exit fricas.
I have no further findings so far.
- Qian
On 4/10/24 21:36, Waldek Hebisch wrote:
On Wed, Apr 10, 2024 at 06:00:26PM +0800, Qian Yun wrote:
I was using 1.3.10 release, no problem. Trunk version has this problem.
Bisect to commit 1936e863, "Rename 'OBEY' to '|run_shell_command|'
We have discussed this before, namely the default dynamic-space-size
is not enough during build.
Recently there is a github issue hitting by this on freebsd.
I get hit by this issue a few times as well, because the default
"./configure" no longer works and sometimes I forget to use
'./configure
I was using 1.3.10 release, no problem. Trunk version has this problem.
Bisect to commit 1936e863, "Rename 'OBEY' to '|run_shell_command|' and
implement with '|run_program|'".
This can be fixed by adding ":input t" to "sb-ext:run-program",
but I can not explain why.
diff --git
When I start HyperDoc with ')hd', it automatically closes when
I quit FriCAS with ')q'.
- Qian
On 4/10/24 00:42, Grégory Vanuxem wrote:
Hello,
See email object.
I would like to be able to only use HyperDoc when I want, and,
usually, not at startup time. The problem is if I use the ')hd'
This patch changes all remaining "import" to "import from".
The removed lines are mostly "import from Record(...)".
Should we also modify "parse_Import" from "s-parser.boot"
so that it gives error on "import XXX"?
- Qian
--
You received this message because you are subscribed to the Google
This fix is a subset of this commit:
https://github.com/GabrielDosReis/open-axiom/commit/c18ddc965ea2ac28a2c32e99dc2ac90c946a7aee
- Qian
diff --git a/src/hyper/extent2.c b/src/hyper/extent2.c
index b0b4443f..524312d0 100644
--- a/src/hyper/extent2.c
+++ b/src/hyper/extent2.c
@@ -554,7 +554,7
"init_special_db_data" is defined but not called in recent commit.
- Qian
--
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
Fix documentation from ')help edit', and running ')edit'
without arguments.
- Qian
diff --git a/src/doc/htex/ug16.htex b/src/doc/htex/ug16.htex
index 98b7dd44..d5a67a43 100644
--- a/src/doc/htex/ug16.htex
+++ b/src/doc/htex/ug16.htex
@@ -870,17 +870,15 @@ Thus
will place you in an editor
On 4/7/24 08:21, Waldek Hebisch wrote:
I admit that my long term plan is somewhat different: to do
substantial developements at Spad level. That means for example
I agree with this long term goal.
better file handling on Spad level. Of course, there is question
how much time Spad plan
OK, just build successfully with Aldor without this function.
Will commit later.
- Qian
On 4/6/24 10:06, Waldek Hebisch wrote:
On Sat, Apr 06, 2024 at 09:40:59AM +0800, Qian Yun wrote:
Seems like function "asList" in as.boot is not used anywhere?
Yes, looks so.
Can it
I'd like to improve "dbReadLines" from br-search.boot
into the following:
read_text_stream stream ==
if stream then
[read_line stream while not EOFP stream]
read_text_file filename ==
handle_input_file(filename, function read_text_stream, [])
It's more correct (closes
Seems like function "asList" in as.boot is not used anywhere?
Can it be removed then?
- Qian
--
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
There is a line breaking feature in "writeInputLines":
it tries to break input lines to less than 72 chars,
see variable "breakChars".
This feature never worked. Following patch fixes it,
however I wonder if this "feature" is worth keeping.
- Qian
diff --git a/src/interp/i-syscmd.boot
On 4/3/24 02:08, Waldek Hebisch wrote:
On Tue, Apr 02, 2024 at 07:51:53PM +0800, Qian Yun wrote:
It is caused by commit 68a3e8ee in 2023-Feb-9, the removal of
"makePathname" in "histInputFileName".
So the fix is the following. Please review it before I do the
commit
It is caused by commit 68a3e8ee in 2023-Feb-9, the removal of
"makePathname" in "histInputFileName".
So the fix is the following. Please review it before I do the
commit.
- Qian
diff --git a/src/interp/i-syscmd.boot b/src/interp/i-syscmd.boot
index 8e337d59..37c0e6ea 100644
---
1 - 100 of 597 matches
Mail list logo
