Re: [fricas-devel] FriCAS on Windows
I tried this patch, it works. (BTW, there are other minor issues when building FriCAS in mingw. We can do this release without fixing them, I'll try to fix them in next release.) On 1/30/19 10:17 PM, Waldek Hebisch wrote: > We discussed here that out of the box FriCAS build fails no > newest MinGW due to 'mkdir'. Attached is patch that tries to > fix this. > > If I get confirmation (say to Friday) that the patch helps I > will include it in the new release. Othewise I will release > without it. > -- 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 post to this group, send email to fricas-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/1f270e8e-281b-6ac2-0945-0c1fb8965b34%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [fricas-devel] Bug?
On Wed, Jan 30, 2019 at 5:58 AM oldk1331 wrote: > > On 1/30/19 5:13 PM, Ralf Hemmecke wrote: > ... > > In fact, it keeps confusing me. > > > > In Aldor, if write something like > > > > foo: % == [1, empty()] > > bar(): % == [1, empty()] > > > > then in the use of bar() I would expect a new allocation every time > > bar() is used. But not so for foo. In Aldor bar is a function but foo is > > a constant (no function call). > > I think "foo" and "bar" are the same: the empty parentheses can be omitted. > They are both functions with no arguments. > > The thing matters is that "1" is declared as: > > 1 : constant -> % > > That makes sure function body of "1" is called only once. > > So in > > foo1 : () -> % > foo2 : constant -> % > > the function body of "foo1" will run many times and the function body of > "foo2" > will run only once. I didn't know this distinction before... > Thank you! I think this distinction is clear and important. -- 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 post to this group, send email to fricas-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAC6x94T4eufFtLdfVgSACjABVhW4WPNza2dDtpwFrAgqC%2BEySQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[fricas-devel] FriCAS on Windows
We discussed here that out of the box FriCAS build fails no
newest MinGW due to 'mkdir'. Attached is patch that tries to
fix this.
If I get confirmation (say to Friday) that the patch helps I
will include it in the new release. Othewise I will release
without it.
--
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 post to this group, send email to fricas-devel@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/E1goqg5-0004bk-AB%40hera.math.uni.wroc.pl.
For more options, visit https://groups.google.com/d/optout.
Index: config/fricas_c_macros.h.in
===
--- config/fricas_c_macros.h.in (revision 2550)
+++ config/fricas_c_macros.h.in (working copy)
@@ -121,6 +121,9 @@
/* Define to 1 if you have the header file. */
#undef HAVE_SYS_WAIT_H
+/* Host has two arg mkdir */
+#undef HAVE_TWO_ARG_MKDIR
+
/* Define to 1 if you have the header file. */
#undef HAVE_UNISTD_H
Index: configure.ac
===
--- configure.ac(revision 2550)
+++ configure.ac(working copy)
@@ -550,6 +550,13 @@
],
[AC_DEFINE([HAVE_EPIPE], [1], [Host has EPIPE])],[])
+AC_TRY_COMPILE([
+#include
+#include
+ ], [
+int code = mkdir ("./foo", (S_IRWXU | S_IRWXO | S_IRWXG));
+ ],
+ [AC_DEFINE([HAVE_TWO_ARG_MKDIR], [1], [Host has two arg mkdir])], [])
if test x$fricas_host_has_socket != xyes; then \
AC_MSG_ERROR([FriCAS needs support for sockets.])
Index: src/lib/cfuns-c.c
===
--- src/lib/cfuns-c.c (revision 2550)
+++ src/lib/cfuns-c.c (working copy)
@@ -110,7 +110,7 @@
int
makedir(char *path)
{
-#ifdef S_IRWXO
+#ifdef HAVE_TWO_ARG_MKDIR
return ( mkdir (path,(S_IRWXU | S_IRWXO | S_IRWXG)) );
#else
return ( mkdir (path) );
Re: [fricas-devel] Bug?
On 1/30/19 5:13 PM, Ralf Hemmecke wrote: > On 1/30/19 2:36 AM, oldk1331 wrote: >> Yes, this is a bug introduced during my cleanup of Factored domain. > > Thanks for fixing it so quickly. > >> Now to think about it, if we really want to avoid extra allocation, >> a better approach is to use local variable: >> >> __one := [1, empty()] >> 1 == __one > > Honestly, it would surprise me if that works. In fact, I believe in > Aldor that would even lead to a subtle bug. The Aldor compiler reorders > == and := assignments. == assignments always come first. Maybe Peter > Broadbery can say more about it. > > Have you checked whether in FriCAS > > 1 == [1, empty()] > > i.e., the current situation, really leads to allocation of a new record > each time 1 is used? Hmm, I checked, I was wrong. Each usage of "1" doesn't leads to a new allocation. > In fact, it keeps confusing me. > > In Aldor, if write something like > > foo: % == [1, empty()] > bar(): % == [1, empty()] > > then in the use of bar() I would expect a new allocation every time > bar() is used. But not so for foo. In Aldor bar is a function but foo is > a constant (no function call). I think "foo" and "bar" are the same: the empty parentheses can be omitted. They are both functions with no arguments. The thing matters is that "1" is declared as: 1 : constant -> % That makes sure function body of "1" is called only once. So in foo1 : () -> % foo2 : constant -> % the function body of "foo1" will run many times and the function body of "foo2" will run only once. I didn't know this distinction before... > I were happy it that would be the same in FriCAS, but 1 in FriCAS is > ONE() and not really a constant. :-( > > 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 post to this group, send email to fricas-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAGBJN91BZYsLRS70nD9giji%3DSurUgxXOYobJ1hcDtAMd9fDwJg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [fricas-devel] Bug?
On 1/30/19 2:36 AM, oldk1331 wrote: > Yes, this is a bug introduced during my cleanup of Factored domain. Thanks for fixing it so quickly. > Now to think about it, if we really want to avoid extra allocation, > a better approach is to use local variable: > > __one := [1, empty()] > 1 == __one Honestly, it would surprise me if that works. In fact, I believe in Aldor that would even lead to a subtle bug. The Aldor compiler reorders == and := assignments. == assignments always come first. Maybe Peter Broadbery can say more about it. Have you checked whether in FriCAS 1 == [1, empty()] i.e., the current situation, really leads to allocation of a new record each time 1 is used? In fact, it keeps confusing me. In Aldor, if write something like foo: % == [1, empty()] bar(): % == [1, empty()] then in the use of bar() I would expect a new allocation every time bar() is used. But not so for foo. In Aldor bar is a function but foo is a constant (no function call). I were happy it that would be the same in FriCAS, but 1 in FriCAS is ONE() and not really a constant. :-( 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 post to this group, send email to fricas-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/6f685bc3-12ac-1b79-792c-3f8c3f051a18%40hemmecke.org. For more options, visit https://groups.google.com/d/optout.
