On Thu, Jan 04, 2024 at 08:28:45AM +0800, Qian Yun wrote:
> Another batch of misc cleanups and fixes from last month.
>
> A short note on the change to "file-kind": its argument is
> string, could not be nil.
OK.
--
Waldek Hebisch
--
You received this message bec
Another batch of misc cleanups and fixes from last month.
A short note on the change to "file-kind": its argument is
string, could not be nil.
- Qian
diff --git a/contrib/load-fricas.lisp b/contrib/load-fricas.lisp
index 5959a8c7..52df2808 100644
--- a/contrib/load-fricas.lisp
+++ b/contrib/loa
On Sat, Nov 18, 2023 at 07:46:03PM +0800, Qian Yun wrote:
>
>
> On 11/18/23 19:32, Waldek Hebisch wrote:
> >
> > This really says nothing about 'extern' declarations on Lisp side.
> > And times have changed: old C had "implict int" rule governing
> > undeclared functions, but this rule for many
On 11/18/23 19:32, Waldek Hebisch wrote:
This really says nothing about 'extern' declarations on Lisp side.
And times have changed: old C had "implict int" rule governing
undeclared functions, but this rule for many years were considered
obsolete and now is gone from C standard. More importa
On Sat, Nov 18, 2023 at 12:15:11PM +0800, Qian Yun wrote:
>
>
> On 11/18/23 11:03, Waldek Hebisch wrote:
> > On Wed, Nov 15, 2023 at 06:00:26PM +0800, Qian Yun wrote:
> > > This is a relatively large misc cleanup, so I'd like a review before
> > > commit.
> >
> > Looks mostly good. But I have d
On 11/18/23 11:03, Waldek Hebisch wrote:
On Wed, Nov 15, 2023 at 06:00:26PM +0800, Qian Yun wrote:
This is a relatively large misc cleanup, so I'd like a review before
commit.
Looks mostly good. But I have doubts about two changes to
fricas-lisp.lisp. First, removing extern declaration of
On Wed, Nov 15, 2023 at 06:00:26PM +0800, Qian Yun wrote:
> This is a relatively large misc cleanup, so I'd like a review before
> commit.
Looks mostly good. But I have doubts about two changes to
fricas-lisp.lisp. First, removing extern declaration of 'sock_get_float'
looks dangerous. Namely,
This is a relatively large misc cleanup, so I'd like a review before
commit.
A question: shall we remove GCL_DIST related stuff in
src/scripts/mkdist.sh?
- Qian
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubscribe
On Fri, Jun 23, 2023 at 03:47:13PM +0800, Qian Yun wrote:
> Hi, I'd like to include this misc cleanups and typo fixes patch before
> release, please review.
Thanks, please go on.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Goog
Hi, I'd like to include this misc cleanups and typo fixes patch before
release, please review.
- Best,
- 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,
On Mon, Jun 11, 2018 at 8:17 AM, oldk1331 wrote:
>>> The grammar for 'reduce': "func"/[args]
>>> is not only very strange, but also not applicable in interpreter.
>>>
>>> I don't think it's worth the effort that compiler supports this grammar,
>>> because it should be easilly replaced by "reduce
>> The grammar for 'reduce': "func"/[args]
>> is not only very strange, but also not applicable in interpreter.
>>
>> I don't think it's worth the effort that compiler supports this grammar,
>> because it should be easilly replaced by "reduce(func, args)",
>> so I want to remove this grammar even
Ralf Hemmecke wrote:
>
> > ATM "func"/[args] notation has one big advantage: it does not create
> > an intermediate list. So it is more efficient than 'reduce(func, args)'
> > variant. Supporting it in compiler in a sense is almost trivial:
> > most of code is present anyway to support '[i for i
> ATM "func"/[args] notation has one big advantage: it does not create
> an intermediate list. So it is more efficient than 'reduce(func, args)'
> variant. Supporting it in compiler in a sense is almost trivial:
> most of code is present anyway to support '[i for i in l]' construct.
The syntax
oldk1331 wrote:
>
> >>
> >> Replace '"append"/' with 'concat'
> >>
> >> https://github.com/oldk1331/fricas/commit/f4909fd49add27b006db4e11476e9071a58ab680.patch
> >
> > Why?
> >
> >> Use 'gcd/lcm' instead of 'reduce'
> >>
> >> https://github.com/oldk1331/fricas/commit/39b4c422e77d0d8e75ba87c310f60
>>
>> Replace '"append"/' with 'concat'
>>
>> https://github.com/oldk1331/fricas/commit/f4909fd49add27b006db4e11476e9071a58ab680.patch
>
> Why?
>
>> Use 'gcd/lcm' instead of 'reduce'
>>
>> https://github.com/oldk1331/fricas/commit/39b4c422e77d0d8e75ba87c310f60758e298a9b6.patch
>
> Again why?
>
> --
>
> Misc cleanups
>
> https://github.com/oldk1331/fricas/commit/c373da5ded4f7f85739093105664b165b89fff94.patch
>
Comments:
In 'iroot' the original code uses 'not' to limit number of
function calls, your change to '>=' adds extra call.
AFAICS 'smaller?' was used to keep this function as
similar
Misc cleanups
https://github.com/oldk1331/fricas/commit/c373da5ded4f7f85739093105664b165b89fff94.patch
Replace '"append"/' with 'concat'
https://github.com/oldk1331/fricas/commit/f4909fd49add27b006db4e11476e9071a58ab680.patch
Use 'gcd/lcm' instead of 'reduce'
https://github.com/oldk1331/fric
>
> --02a773056db405a2
> Content-Type: text/plain; charset="UTF-8"
>
> Please review this patch:
>
> https://github.com/oldk1331/fricas/commit/6d229ebee9fcf3010d2a045450e96daa29315714.patch
>
Looks good. But there is one problem: in 'rule.spad' you change
output form from symbol t
Please review this patch:
https://github.com/oldk1331/fricas/commit/6d229ebee9fcf3010d2a045450e96daa29315714.patch
All tests passed:
https://travis-ci.org/oldk1331/fricas/builds/387286568
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra sy
20 matches
Mail list logo
