Thanks, I applied the patch and compiled FriCAS to see its result.
You are right, it is working.
The thing confused me is that, this is double compilation.
First, the SPAD compiler complies *.spad to *.lsp with this macro.
Then, when *.lsp are read and compiled, this macro works at compile
On Tue, Mar 09, 2021 at 12:31:34AM +0800, oldk1331 wrote:
> But this macro only expands to this function call, it does not do
> computation at compile time.
>
No. Macro is executed at compile time and result used as expansion.
Most of our macros use "`" (backtick) to delay evaliation and
just
But this macro only expands to this function call, it does not do
computation at compile time.
On Tue, Mar 9, 2021, 12:20 AM Waldek Hebisch
wrote:
> On Mon, Mar 08, 2021 at 11:00:22PM +0800, Qian Yun wrote:
> > This patch tested OK, and I only have one small question:
> >
> > Why define the
On Mon, Mar 08, 2021 at 11:00:22PM +0800, Qian Yun wrote:
> This patch tested OK, and I only have one small question:
>
> Why define the macro 'mk_DF' instead of using 'make_DF' function?
Macro will always run at compile time, even in dumb compiler.
Function may be delayed to runtime, at least
This patch tested OK, and I only have one small question:
Why define the macro 'mk_DF' instead of using 'make_DF' function?
- Qian
On 3/8/21 6:10 AM, Waldek Hebisch wrote:
On Sun, Mar 07, 2021 at 05:32:11PM +0100, Waldek Hebisch wrote:
I will look if I can quickly change Spad compiler to
On Sun, Mar 07, 2021 at 05:32:11PM +0100, Waldek Hebisch wrote:
>
> I will look if I can quickly change Spad compiler to produce
> something that causes no trouble to sbcl. If chaging Spad
> compiler requires too much work, I would go with string
> version.
I have now a patch that seem to work
On Sat, Mar 06, 2021 at 01:14:32PM +0100, Ralf Hemmecke wrote:
> > Well, writing integers as strings is not really satisfactory
> > solution. OTOH, given how problematic TMFORM is we may have
> > no better way...
>
> OK, we don't need integers as strings, we can also use the utf8
> character
> Well, writing integers as strings is not really satisfactory
> solution. OTOH, given how problematic TMFORM is we may have
> no better way...
OK, we don't need integers as strings, we can also use the utf8
character itself. See attachment for a second attempt.
The texmacs.input file is
On Fri, Mar 05, 2021 at 09:41:57PM +0100, Ralf Hemmecke wrote:
> On 05.03.21 14:25, Waldek Hebisch wrote:
> > On Thu, Mar 04, 2021 at 05:02:41PM +0100, Ralf Hemmecke wrote:
> Third, is it a bug that compile TMFORM requires so much RAM?
> We should look into it to see if RAM usage can be
On 05.03.21 14:25, Waldek Hebisch wrote:
> On Thu, Mar 04, 2021 at 05:02:41PM +0100, Ralf Hemmecke wrote:
Third, is it a bug that compile TMFORM requires so much RAM?
We should look into it to see if RAM usage can be reduced.
>>>
>>> AFAICS RAM usage during compilation of TMFORM is
On Thu, Mar 04, 2021 at 05:02:41PM +0100, Ralf Hemmecke wrote:
> >> Third, is it a bug that compile TMFORM requires so much RAM?
> >> We should look into it to see if RAM usage can be reduced.
> >
> > AFAICS RAM usage during compilation of TMFORM is really sbcl
> > bug. It seem that the problem
>> Third, is it a bug that compile TMFORM requires so much RAM?
>> We should look into it to see if RAM usage can be reduced.
>
> AFAICS RAM usage during compilation of TMFORM is really sbcl
> bug. It seem that the problem is the same as AWAIC.
> Namely, we need to initialise a table and at Lisp
On Thu, Mar 04, 2021 at 11:59:23PM +0800, Qian Yun wrote:
>
> > IIUC Windows has "shortcuts" which are supposed to act like
> > Unix symbolic links. Maybe it is enough to create a
> > shortcut?
> >
>
> You mean create "shortcuts"/symbolic links of SBCL installation
> directory? That's still a
IIUC Windows has "shortcuts" which are supposed to act like
Unix symbolic links. Maybe it is enough to create a
shortcut?
You mean create "shortcuts"/symbolic links of SBCL installation
directory? That's still a workaround, isn't it?
Anyway, this problem is not that important, we can
On Thu, Mar 04, 2021 at 06:46:14PM +0800, Qian Yun wrote:
> Another tricky bug on Windows is that, we can't compile TMFORM
> with default heap size, so we need to pass "--dynamic-space-size 4096".
>
> That is not a problem on Linux, but on Windows, it's complicated.
>
> First, by default, SBCL
Another tricky bug on Windows is that, we can't compile TMFORM
with default heap size, so we need to pass "--dynamic-space-size 4096".
That is not a problem on Linux, but on Windows, it's complicated.
First, by default, SBCL installation path contains spaces.
("C:\Program Files\Steel Bank
16 matches
Mail list logo
