Re: [fricas-devel] Questions on FriCAS make
On Sat, Mar 20, 2021 at 12:37:47AM +0100, Ralf Hemmecke wrote: > > Concerning "low profile developers", > > I expect most of FriCAS developement to be done independently > > of "make". > :-( > > Why do you expect that? Because that is your development style or > because the build system is not smart enough to only compile the stuff > quickly that a developer changed? > > Thanks to Qian we have CI working at github, so how local development > happens is mostly to the taste of the developer. Still, it would be > better if the build system was clever enough to just do the right thing > when one (re-)types "make". 1) IME even in projects heavily geared toward "make" much of developement was independent of "make". Namely, it was running program under debugger, trying various tests and observing state. Only after collecting enough data it was possible to write code fixing a bug or implementing new functionality. 2) Our algebra build have to solve bootstrap problem. Due to this it is hard to avoid rebuilding whole algebra after seemingly trivial change. Developer should have reasonably good idea if change requires rebuilding other files. "make" sees only file date/time and with this must act conservatily and rebuild a lot. 3) Beside rebuild time, there is also problem of test data and command line history. "gdb" keeps some testing state (breakpoints, etc) and command line history and picks new new executable after change. Lisp works by loading changed code, which is nice but does not fit well with "make". By recompiling file that I work on I can keep my testing state in Lisp image and get reasonably fast developement cycle: most time is my thinking time, biggest delay is Spad compilation which for single file is usually short enough to not disturb thinking. From that point of view "make" (or ruther time spent running it) is a cost, which most projects must pay, but fortunately we do not have to. BTW: I suspect that Python folks also are less eager to run "make" (OTOH Python bytcode compilation means that make can be quite fast). -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20210320002145.GA35450%40math.uni.wroc.pl.
Re: [fricas-devel] Questions on FriCAS make
> Concerning "low profile developers", > I expect most of FriCAS developement to be done independently > of "make". :-( Why do you expect that? Because that is your development style or because the build system is not smart enough to only compile the stuff quickly that a developer changed? Thanks to Qian we have CI working at github, so how local development happens is mostly to the taste of the developer. Still, it would be better if the build system was clever enough to just do the right thing when one (re-)types "make". Ralf -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/4fa77193-8bad-2d28-2ec4-9e35138be5ae%40hemmecke.org.
Re: [fricas-devel] Questions on FriCAS make
On Fri, Mar 19, 2021 at 07:31:51PM +0100, riccardo.gu...@gmail.com wrote: > > 8) Are there any other important ``make`` targets that could be useful to a > user / low profile developer workflow? All "make" targets that I expect user to use are in INSTALL file: make make MAYBE_VIEWPORT=viewports make viewports make install There is also "make check", it is important but I expect (maybe wrongly) normal users to skip it. Then you have make all-input that I use for testing. Concerning "low profile developers", I expect most of FriCAS developement to be done independently of "make". So "make" targets are important only for final testing. Note that adding files in normally can be done by adding file names to appropriate lists of files in Makefile-s. Of course some people will want to modify Makefile-s, then you need to understand how "make" works and look at comments in Makefile-s. Concerning your other questions: "make" essentially is a programming language which exposed internals of program (that is Makefile) to the users. So the right question is not "what make will do if I do some weird command?" The right question is "how do I archive effect X?", where X is one of things normally done with "make". Note that many "make" targets are to support packagers and FriCAS tries to follow common practice there, in particular relevant parts of GNU coding standards. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20210319224520.GB24079%40math.uni.wroc.pl.
Re: [fricas-devel] Re: Questions on FriCAS make
On Fri, Mar 19, 2021 at 08:26:32PM +0100, riccardo.gu...@gmail.com wrote:
> PS Question 2 without some misprints (sorry!):
>
> 2) Questions on safe cleaning before a rebuild.
>
> Suppose that at time t0 I execute:
>
> cd $BuildDir && configure --prefix=$InstallDir "${SysOptions[@]}" && make &&
> sudo make install.
>
> Then at time t1 > t0 I want to rebuild (maybe the sources changed, maybe not)
> and I execute
>
> cd $BuildDir && configure --prefix=$InstallDir "${SysOptions[@]}" && make &&
> sudo make install
>
> 2.1 Will the second ``make`` properly delete all the previous fricas-related
> contents in $BuildDir or shall I manually delete them before?
I think there is some misconception in this question. Namely, "make"
is supposed to do _minimal_ recompilation/rebuild, avoiding
recompiling things that do not change (or possibly change in
inessential way (like date of file)). Of course "make" itself
does not know what is needed, so it must be told what to do
by giving it appropirate rules which roughly are of sort
"if date/time of file A has is newer than date/time of file B,
then run specifiled command". Those rules are collected in
Makefiles.
Assuming that our Makefiles work correctly there is no need
to delete anything produced by previous run of "make"
before next run. Having said this, various corner cases
there get very little testing so bugs are possible.
> 2.2 Will the second ``make install`` properly delete all the previous
> fricas-related contents in $InstallDIr or shall I manually delete them
> before?
Again, running "make install" multiple times is supposed to work.
> 2.3 May I omit ``configure --prefix=$InstallDir "${SysOptions[@]}`` (same
> parameters!) in the second build?
If you have the same parameters it is better to omit "configure"
part.
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/20210319221242.GA24079%40math.uni.wroc.pl.
Re: [fricas-devel] X11 and graphics
Thank you Bil for this feedback. > HyperDoc: almost every time I use FriCAS. I do often wish > that the HyperDoc interface looked more up to date. On the > other hand I do not much like to have to work online with > http://fricas.github.io Maybe I would use it more if it was > bundled into the FriCAS distribution somehow. Bundled with the distribution, I cannot promise. But what I can say is that when you compile FriCAS and say cd /path/to/build-dir/src/doc make localdoc it will produce that what is on fricas.github.io on your local machine. (even the book). And the links there are such that you (almost) never need the web. See https://github.com/fricas/fricas/blob/master/src/doc/Makefile.in#L75 Ralf -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/421fe42a-060c-9b60-c28d-dedeb3d38d8d%40hemmecke.org.
Re: [fricas-devel] X11 and graphics
On Fri, Mar 19, 2021 at 5:07 PM Ralf Hemmecke wrote: > > Actually, I would be interested in a poll that asks how many of > our users ever use the graphics facilities of FriCAS. A similar > poll for the use of HyperDoc would also be fine. > Someone here on the list who would answer these questions? > Graphics: almost 0. Even if it did look nice I probably would not use it often. Maybe that is just because of the kinds of things for which I use FriCAS. HyperDoc: almost every time I use FriCAS. I do often wish that the HyperDoc interface looked more up to date. On the other hand I do not much like to have to work online with http://fricas.github.io Maybe I would use it more if it was bundled into the FriCAS distribution somehow. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAC6x94SyJn2v9UcVBnKxABH0HJvFDW9z5mDmcTrzuHndceZppQ%40mail.gmail.com.
[fricas-devel] X11 and graphics
On 19.03.21 19:20, Waldek Hebisch wrote: > We need some graphic environment. Yes and all you say about stability of X11 might be true, but you must admit that with the graphics system of FriCAS you cannot really impress somebody. If you think otherwise than produce some nice examples that we can showcase on our website so that people see that FriCAS can also visualise nicely. If you like to keep the current graphics system that is fine. However, I do not think it is wise to stop other people from what they think is best for FriCAS. If someone develops a new graphics system in his/her fork of FriCAS and you do not take it, that's also OK. People will choose whatever helps to solve their problems. Since seemingly nobody is interested in developing a new graphics framework we should anyway not throw away the current stack. However, that does not mean that we cannot discuss a new way of handling graphics. Actually, I would be interested in a poll that asks how many of our users ever use the graphics facilities of FriCAS. A similar poll for the use of HyperDoc would also be fine. Someone here on the list who would answer these questions? Ralf -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ab01b13f-9ff8-e2f1-4f87-a2b550ca35ef%40hemmecke.org.
[fricas-devel] Re: Questions on FriCAS make
PS Question 2 without some misprints (sorry!):
2) Questions on safe cleaning before a rebuild.
Suppose that at time t0 I execute:
cd $BuildDir && configure --prefix=$InstallDir "${SysOptions[@]}" && make &&
sudo make install.
Then at time t1 > t0 I want to rebuild (maybe the sources changed, maybe not)
and I execute
cd $BuildDir && configure --prefix=$InstallDir "${SysOptions[@]}" && make &&
sudo make install
2.1 Will the second ``make`` properly delete all the previous fricas-related
contents in $BuildDir or shall I manually delete them before?
2.2 Will the second ``make install`` properly delete all the previous
fricas-related contents in $InstallDIr or shall I manually delete them before?
2.3 May I omit ``configure --prefix=$InstallDir "${SysOptions[@]}`` (same
parameters!) in the second build?
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/65f66176-094d-94d2-fbfe-6fb7f40eb1ef%40gmail.com.
[fricas-devel] Understanding series expansion performance
I am currently trying to see if I can accelerate my code around series
expansions. I really like that series are lazy in FriCAS, but I wonder
what impact multiple iterated operations on the series (or the underlying
stream), like integration etc. have. I would assume that up to memory
requirements that "save" all the performed operations, there should be no
performance penalty compared to a non-lazy evaluation.
Anyway, while testing I came up with this example, where some expression
is series expanded in two different ways.
)clear completely
)set mes tim on
x := taylor(x');
s1 := x^2 + cos(x) + x^8/ sqrt(x-1);
s2 := taylor(y^2 + cos(y) + y^8/ sqrt(y-1),y=0);
approximate(s1,450);
approximate(s2,450);
approximate(s1,450);
approximate(s2,450);
When running the code (see below) the first method of evaluation is three
times faster than the second. (A second evaluation runs in the same time
for both cases, probably because the results are cached, but that's not
relevant for me).
In my case I start with an Expression(Integer), so I (obviously) can only
use the second version from the ExpressionToUnivariatePowerSeries package.
But my idea is that maybe I can improve the performance if I understand
why the first method is so much faster.
I would have expected that the ExpressionToUnivariatePowerSeries package
does something like "subst(expression, x=series('x))", symbolically
speaking, but then it should be just as fast.
In principle I see two ways to do the series expansions: Compute the
expansion as a whole for the whole expression (for example by taking
derivatives for a Taylor series). Or do it for each function separately,
and use the Cauchy product to multiply the individual series together, or
add them, etc. For the first series expansion example this is clearly
done, but maybe not for ExpressionToUnivariatePowerSeries and this could
be the difference?
Thanks,
Tobias
running the code:
approximate(s1,450);
Type:
Expression(Integer)
Time: 0 (IN) + 2.20 (EV) + 0 (OT) = 2.20
sec
approximate(s2,450);
Type:
Expression(Integer)
Time: 0.00 (IN) + 6.12 (EV) + 0.00 (OT) = 6.13
sec
approximate(s1,450);
Type:
Expression(Integer)
Time: 0 (IN) + 1.36 (EV) + 0 (OT) = 1.36
sec
approximate(s2,450);
Type:
Expression(Integer)
Time: 0 (IN) + 1.37 (EV) + 0 (OT) = 1.37
sec
(
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/s3049r%24u6u%241%40ciao.gmane.io.
[fricas-devel] Questions on FriCAS make
Dear all
I have some simple (and non-urgent) questions on the use of toplevel make.
Thanks in advance for your time and sorry if the questions may look trivial to
you.
In the following I fix:
InstallDir=/path/to/install_dir
BuildDir=/path/to/build_dir
SysOptions= a bash array containing configure options NOT including --prefix
and other options setting the target paths/files.
0)
Is there a toplevel ``make help`` that explains its options and their semantics?
1) Does ``make`` implies ``make check``?
2) Questions on safe cleaning before a rebuild.
Suppose that at time t0 I execute:
cd $BuildDir && configure --prefix=$INSTALL "${SysOptions[@]}" && make && sudo
make install.
Then at time t1 > t0 I want to rebuild (maybe the sources changed, maybe not)
and I execute
cd $BuildDir && configure --prefix=$INSTALL "${SysOptions[@]}" && make && sudo
make install
1.1 Will the second ``make`` properly delete all the previous fricas-related
contents in $InstallDIr or shall I manually delete them before?
1.2 Will the second ``make install`` properly delete all the previous
fricas-related contents in $BuildDir or shall I manually delete them before?
1.3 May I omit ``configure --prefix=$INSTALL "${SysOptions[@]}`` (same
parameters!) in the second build?
3) From https://github.com/fricas/fricas/blob/master/Makenotes.tex#L59
``The build system is set up so that if [[make all]] just completed
then [[make install]] will not modify any file in the build directory,``
is this still correct?
4)
Does ``make`` implies ``make all``?
5) From https://github.com/fricas/fricas/blob/master/Makenotes.tex#L821
``
[[mostlyclean]] acts almost like [[clean]] except that it does not
delete some files that are time-consuming to make (if remaking is
not needed), e.g. [[libspad.a]] or [[lisp]].
[[clean]] deletes any file created by running [[make]].
``
is this still correct?
6) From https://github.com/fricas/fricas/blob/master/Makenotes.tex#L821
``
[[distclean]] cleans up the build directory to the point where it almost
reverts to the state of the build directory before the initial build.
In summary [[clean]] can be interpreted as a prerequisite of [[distclean]],
and [[mostlyclean]] a prerequisite of [[clean]].
``
I'm confused: if clean deletes all files created by make and is a prerequisite
of distclean, what actually does in addition distclean and what means
``almost`` in ``almost reverts to the state of the build directory before the
initial build.''?
7)
Does ``make`` implies ``make clean`` or maybe ``make distclean``?
Does ``make`` implies ``make distclean``?
8) Are there any other important ``make`` targets that could be useful to a
user / low profile developer workflow?
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/db01e9b3-38ae-76ed-08c8-ba5cb3b28ffa%40gmail.com.
Re: [fricas-devel] Re: changes to allow macOS packaging work again
On Fri, Mar 19, 2021 at 06:08:28PM +0100, Ralf Hemmecke wrote: > > It still makes some sense to offer version without X11 > > support, but we should make lack of X11 support clear > > in documentaion and probably point to alternatives supporting > > X11. > > I don't think that X11 will disappear too quickly, but still, we should > be prepared. Windows has no X, MacOS has no X, with Wayland coming, X > will not be the default in Ubuntu etc. > > In fact, I do not really see why FriCAS needs X. Of course supporting it > as long as it works, is OK, but I wouldn't want to invest much time into > it. We already have jfricas as a nice interface. Much of the stuff in > HyperDoc lives at fricas.github.io. The big problem is our graphics > engine. For that we would need someone that comes up with a connection > to some newer graphics framework so that X is no prerequisit anymore. We need some graphic environment. Simple fact of life is that up to now X11 was most stable environment. Namely, old 30 years old programs work as they used to work. Unfortunatly, this is not the case with newer things, my graphic code for "famework of the day" got broken in few years. And a lot of folks have similar experience. Let me add that retargetting our existing programs say to WinAPI would be rather easy (and would not require breaking X11 support), but nobody voluntereed to do the work. It seems that people prefer to work on new code, probably because in new code they can concentrate on core things and (at least at beginning ignore some system aspects and corner cases). But for long term interface it is exactly handling of system aspects and corner cases that determines viablility. Adapting tried code in very slowly evolving environment is much easier than coping with rapid breaking chages in "modern" systems. Another apect is performace: our X11 programs have by current standard very small resource requirements and high performace. Browsers (and web page code) tend to get slower faster than hardware get faster so for long time we can expect bad performance. BTW: Long time ago I was one of users of shared Sun workstations. There was X11 installed, but machines had only 4M of memory and X11 was quite slow on them. But I have found manuals of "suntools", clearly marked "obsolete". I peeked into manuals and tried the software. It had it quiks, but run with quite satisfactory performance. Form that time I started to appreciate advantages of "obsolete" software... -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20210319182054.GA8755%40math.uni.wroc.pl.
Re: [fricas-devel] Re: changes to allow macOS packaging work again
> It still makes some sense to offer version without X11 > support, but we should make lack of X11 support clear > in documentaion and probably point to alternatives supporting > X11. I don't think that X11 will disappear too quickly, but still, we should be prepared. Windows has no X, MacOS has no X, with Wayland coming, X will not be the default in Ubuntu etc. In fact, I do not really see why FriCAS needs X. Of course supporting it as long as it works, is OK, but I wouldn't want to invest much time into it. We already have jfricas as a nice interface. Much of the stuff in HyperDoc lives at fricas.github.io. The big problem is our graphics engine. For that we would need someone that comes up with a connection to some newer graphics framework so that X is no prerequisit anymore. Ralf -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/9faac6e3-c11d-6b3b-8ede-2267e45aa2d4%40hemmecke.org.
Re: [fricas-devel] Re: changes to allow macOS packaging work again
On Fri, Mar 19, 2021 at 11:25:12PM +0800, Qian Yun wrote: > At this stage I do not want to add support for X11/HyperDoc on macOS. > Not yet, maybe later, if a user puts such request. > > Can you agree with this? Maybe I am wrong, but my impression was: - FriCAS builds from sources on Mac OSX with X11 support - there are packaging systems on Mac which distribute FriCAS with X11 support So we are not talking about adding support. Rather, we do not want to break what is working. It is fine if you do not want to work with X11 (now or also in the future). However, the problem is to ensure that various efforts add. That is why I was asking about "Terminal.app": your earlier posts suggested that it introduces breakage... Another thing are versions for user. Namely, for testing it is fine to test without X11 (ATM in batch mode we can only test if X11 interface builds, but no more). However for users versions with X11 interface are much more preferable. It still makes some sense to offer version without X11 support, but we should make lack of X11 support clear in documentaion and probably point to alternatives supporting X11. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20210319161533.GA40803%40math.uni.wroc.pl.
[fricas-devel] Re: irc.freenode.net
> > There is a #fricas room at irc.freenode.net. > Does someone know who the channel op is? > /msg chanserv info #fricas [ChanServ] Information on #fricas: [ChanServ] Founder: freenode-placeholder-account [ChanServ] Registered : Nov 18 21:15:09 2012 (8y 17w 3d ago) [ChanServ] Last used : Dec 24 19:43:55 2014 (6y 12w 2d ago) seems to indicate that it no longer belongs to anyone. I think you can reclaim it by asking freenode staff. Either #freenode or /stats p, which shows "staffers" available for help. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/7469399d-d989-4c15-a33e-2eb72d60n%40googlegroups.com.
Re: [fricas-devel] Re: changes to allow macOS packaging work again
wow, https://www.xquartz.org/ just had a (pre)release, first in 5 years. I thought it is just gone. On Fri, 19 Mar 2021, 14:37 Waldek Hebisch, wrote: > On Fri, Mar 19, 2021 at 02:22:10PM +, Dima Pasechnik wrote: > > On Fri, Mar 19, 2021 at 2:21 PM Waldek Hebisch > wrote: > > > > > > On Fri, Mar 19, 2021 at 07:12:58PM +0800, Qian Yun wrote: > > > > This is all the changes I need in order to get a working > > > > macOS dmg package. > > > > > > Just asking: apparently you replace "xterm" by "Terminal.app", > > > what is the reason? > > > > macOS typically has no X11 nowdays, thus no xterm. > > AFAIK X11 was an optional component which could be installed. > I we want it installed for graphics and HyperDoc. > > -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/fricas-devel/20210319143752.GB32840%40math.uni.wroc.pl > . > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAAWYfq0zqwkN%2BtxtG7Fdaj7fmXn3d2mj902OUAYLVayNFB5v%2BQ%40mail.gmail.com.
Re: [fricas-devel] Re: changes to allow macOS packaging work again
On Fri, Mar 19, 2021 at 02:22:10PM +, Dima Pasechnik wrote: > On Fri, Mar 19, 2021 at 2:21 PM Waldek Hebisch > wrote: > > > > On Fri, Mar 19, 2021 at 07:12:58PM +0800, Qian Yun wrote: > > > This is all the changes I need in order to get a working > > > macOS dmg package. > > > > Just asking: apparently you replace "xterm" by "Terminal.app", > > what is the reason? > > macOS typically has no X11 nowdays, thus no xterm. AFAIK X11 was an optional component which could be installed. I we want it installed for graphics and HyperDoc. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20210319143752.GB32840%40math.uni.wroc.pl.
Re: [fricas-devel] Re: changes to allow macOS packaging work again
On Fri, Mar 19, 2021 at 2:21 PM Waldek Hebisch wrote: > > On Fri, Mar 19, 2021 at 07:12:58PM +0800, Qian Yun wrote: > > This is all the changes I need in order to get a working > > macOS dmg package. > > Just asking: apparently you replace "xterm" by "Terminal.app", > what is the reason? macOS typically has no X11 nowdays, thus no xterm. > > -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/fricas-devel/20210319142118.GA32840%40math.uni.wroc.pl. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAAWYfq0DuLuv7CS-bbtS6Re4jqZh_-8JXJob-D%3DFyHxPqbK9tA%40mail.gmail.com.
Re: [fricas-devel] Re: changes to allow macOS packaging work again
On Fri, Mar 19, 2021 at 07:12:58PM +0800, Qian Yun wrote: > This is all the changes I need in order to get a working > macOS dmg package. Just asking: apparently you replace "xterm" by "Terminal.app", what is the reason? -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20210319142118.GA32840%40math.uni.wroc.pl.
Re: [fricas-devel] A radical idea for a (future) FriCAS GUI
On Fri, Mar 19, 2021 at 11:02 AM Qian Yun wrote: > > Recently there is news about the release of Flutter 2.0, and Ubuntu > using it to build the future Ubuntu installer. > > I'm a little interested in it and take a deeper look. > > Short introduction, "Flutter is Google’s UI toolkit for building > beautiful, natively compiled applications for mobile, web, and > desktop from a single codebase." > > It is based on the Dart language. Frankly speaking, I like it somewhat. > Some of its language features are similar to SPAD, I would say. > Strong static typing with type deduction, its "abstract class" is a bit > like our "Category". It fits to my taste much better than JS. > > About Flutter, its design philosophy appeals to me as well. > The underlying operating systems only provide a canvas and > Flutter provides all the widgets to do the rendering. I'd stay away from Google's offerings, given how often they break/remove their stuff, etc (it probably also has a big Google "platform" bias, too). I'd choose something like elm (https://elm-lang.org/) instead. Yes, it compiles to JS and runs in a browser, but that's a plus, not a minus. Messing around with a gazillion different windowing enviroments is better left to other projects. Or just conentrate on jupyter kernel for fricas, and showing docs there. > > I'd say I would prefer to use Flutter than Qt (C++ or Python/JS binding) > to build the replacement of HyperDoc. Maybe I can make up my > mind and get a working demo before the end of this year (or next year), > for Linux/Windows/macOS/Web/Android/iOS. > > - 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 fricas-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/fricas-devel/f526fcf6-48b4-926d-a487-dbae1901ea1b%40gmail.com. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAAWYfq03dG5zj8x2mv1SVqq4wi0nksUAro_mxUNSCxqBCnq4dg%40mail.gmail.com.
[fricas-devel] Re: changes to allow macOS packaging work again
This is all the changes I need in order to get a working
macOS dmg package.
See attachment or
https://github.com/oldk1331/fricas/commit/71c511531475a1c754b555362bc14a4299ccba0c.patch
Binary at https://github.com/oldk1331/fricas/actions/runs/667643819
Comments are welcome.
- Qian
On 3/18/21 7:49 PM, Qian Yun wrote:
This is the change I made to get the macOS dmg working.
Not very elegant, but I wonder if there is a better way?
Comments are welcome. And macOS users can try/test the binary
at https://github.com/oldk1331/fricas/actions/runs/664218153
- Qian
https://github.com/fricas/fricas/commit/ed1f43ad1a7be891a6bbb050b055e2ff7f9f3ab8.patch
diff --git a/Makefile.in b/Makefile.in
index f50f0bde3..17af45595 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -133,9 +133,11 @@
echo exec_prefix='"$${FRICAS_PREFIX:-$(exec_prefix)}"' \
>> '${COMMAND}'.tmp
if test "$(fricas_lib)" != "$(libdir)" ; then \
- echo \
-
FRICAS='"$${exec_prefix}/$(fricas_lib)/fricas/target/$(target)"' \
- >> '${COMMAND}'.tmp ; \
+ if test $(uname -s) != "Darwin" ; then \
+ echo
FRICAS='"$${exec_prefix}/$(fricas_lib)/fricas/target/$(target)"' >>
'${COMMAND}'.tmp ; \
+ else \
+ echo FRICAS='"`dirname
$$0`/../$(fricas_lib)/fricas/target/$(target)"' >> '${COMMAND}'.tmp ; \
+ fi \
else \
echo FRICAS='"$(libdir)/fricas/target/$(target)"' \
>> '${COMMAND}'.tmp ; \
diff --git a/contrib/macos/FriCAS.c b/contrib/macos/FriCAS.c
index bf7f1470f..35c83deac 100644
--- a/contrib/macos/FriCAS.c
+++ b/contrib/macos/FriCAS.c
@@ -25,7 +25,7 @@
setenv("FRICAS_PREFIX", CFStringGetCStringPtr(path, encoding), 1);
- system("/usr/X11/bin/xterm"
- " -e \"${FRICAS_PREFIX}/bin/fricas\"");
+ system("open -a Terminal.app"
+ " \"${FRICAS_PREFIX}/usr/local/bin/fricas\"");
return 0;
}
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/a4e9c9bf-acc1-3d4f-370d-0eff1297f12f%40gmail.com.
>From 71c511531475a1c754b555362bc14a4299ccba0c Mon Sep 17 00:00:00 2001
From: Qian Yun
Date: Thu, 18 Mar 2021 18:30:06 +0800
Subject: [PATCH] Try to make macOS dmg package
---
.github/workflows/macOS.yml | 8 +---
Makefile.in | 18 +++---
contrib/macos/FriCAS.c | 4 ++--
3 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/.github/workflows/macOS.yml b/.github/workflows/macOS.yml
index 5fc6fdc15..08964ff64 100644
--- a/.github/workflows/macOS.yml
+++ b/.github/workflows/macOS.yml
@@ -21,9 +21,11 @@ jobs:
- name: make check
run: cd ../build && make check -j3
- name: Create artifact archives
- run: cd ../build && tar -cjf ../fricas/fricas-macOS-x86_64-binary-${{ github.sha }}.tbz2 target/
+ run: |
+cd ../build && make dist-osx-dmg
+mv FriCAS.dmg ../fricas/FriCAS-macOS-x86_64-${{ github.sha }}.dmg
- name: Upload macOS binary
uses: actions/upload-artifact@v2
with:
-name: fricas-macOS-x86_64-binary
-path: fricas-macOS-x86_64-binary-${{ github.sha }}.tbz2
+name: FriCAS-macOS-x86_64-binary
+path: FriCAS-macOS-x86_64-${{ github.sha }}.dmg
diff --git a/Makefile.in b/Makefile.in
index f50f0bde3..34ab6d0dd 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -133,9 +133,11 @@ install-src:
echo exec_prefix='"$${FRICAS_PREFIX:-$(exec_prefix)}"' \
>> '${COMMAND}'.tmp
if test "$(fricas_lib)" != "$(libdir)" ; then \
- echo \
- FRICAS='"$${exec_prefix}/$(fricas_lib)/fricas/target/$(target)"' \
- >> '${COMMAND}'.tmp ; \
+ if test $(uname -s) != "Darwin" ; then \
+ echo FRICAS='"$${exec_prefix}/$(fricas_lib)/fricas/target/$(target)"' >> '${COMMAND}'.tmp ; \
+ else \
+ echo FRICAS='"`dirname $$0`/../$(fricas_lib)/fricas/target/$(target)"' >> '${COMMAND}'.tmp ; \
+ fi \
else \
echo FRICAS='"$(libdir)/fricas/target/$(target)"' \
>> '${COMMAND}'.tmp ; \
@@ -247,5 +249,15 @@ ${DIST_TARBALL}: out-of-source-check lastBuildDate dist-help dist-lisp dist-doc
dist: ${DIST_TARBALL}
+dist-osx-dmg: out-of-source-check
+ -rm -rf FriCAS.app
+ ${MKDIR_P} FriCAS.app/Contents/{MacOS,Resources}
+ ${MAKE} DESTDIR=./FriCAS.app/Contents/Resources install-src
+ cp $(fricas_top_srcdir)/contrib/macos/Info.plist ./FriCAS.app/Contents/
+ cp $(fricas_top_srcdir)/contrib/macos/appIcon.icns ./FriCAS.app/Contents/Resources/
+ cc -framework CoreFoundation $(fricas_top_srcdir)/contrib/macos/FriCAS.c -o ./FriCAS.app/Contents/MacOS/FriCAS
+ -rm -f FriCAS.dmg
+ hdiutil create -srcfolder FriCAS.app FriCAS.dmg
+
clean-distdir:
-rm -rf ${distdir} ${DIST_TARBALL}
diff --git
[fricas-devel] A radical idea for a (future) FriCAS GUI
Recently there is news about the release of Flutter 2.0, and Ubuntu using it to build the future Ubuntu installer. I'm a little interested in it and take a deeper look. Short introduction, "Flutter is Google’s UI toolkit for building beautiful, natively compiled applications for mobile, web, and desktop from a single codebase." It is based on the Dart language. Frankly speaking, I like it somewhat. Some of its language features are similar to SPAD, I would say. Strong static typing with type deduction, its "abstract class" is a bit like our "Category". It fits to my taste much better than JS. About Flutter, its design philosophy appeals to me as well. The underlying operating systems only provide a canvas and Flutter provides all the widgets to do the rendering. I'd say I would prefer to use Flutter than Qt (C++ or Python/JS binding) to build the replacement of HyperDoc. Maybe I can make up my mind and get a working demo before the end of this year (or next year), for Linux/Windows/macOS/Web/Android/iOS. - 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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/f526fcf6-48b4-926d-a487-dbae1901ea1b%40gmail.com.
[fricas-devel] irc.freenode.net
There is a #fricas room at irc.freenode.net. Does someone know who the channel op is? Ralf -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/1df3df51-ee3b-6f40-a000-22f4731c5c01%40hemmecke.org.
