review request pr#93, pr#96

[Qian Yun]

I don't know if these 2 patches reached Waldek's mailbox or otherwise.

(BTW, lynx can browse through https://github.com/fricas/fricas/pulls
to see open PRs.)

They were submitted 10 days ago and I hope to get reviews.

https://github.com/fricas/fricas/pull/93
https://github.com/fricas/fricas/pull/96

For Paul's PR#96, I have verified his patch fixes the bug.

- Qian

[Waldek Hebisch]

On Wed, Jun 29, 2022 at 10:00:21PM +0800, Qian Yun wrote:
> I don't know if these 2 patches reached Waldek's mailbox or otherwise.
>
> (BTW, lynx can browse through https://github.com/fricas/fricas/pulls
> to see open PRs.)
>
> They were submitted 10 days ago and I hope to get reviews.
>
> https://github.com/fricas/fricas/pull/93

93 looks OK. ICARD has many problems so I was thinking if
we should do some major fixup or just merge this one.
But it is probably better just to merge this fix.

> https://github.com/fricas/fricas/pull/96
>
> For Paul's PR#96, I have verified his patch fixes the bug.

Hmm, AFAICS 96 is from you. I wrote the following in comment
section, but github apparently sent it to black hole:

I admit that it is not clear for me why you want this. At least
some of places that you want to modify comunicate with C code.
And in C code all we have is FRICAS environment variable
(we definitely do not have access to Lisp '$spadroot').

IIUC you wrote that passing environment variables on Mac OS is
tricky. Having some fallback is reasonable, but preferably
this fallback should be in one place, at top of process tree.
And once fallback is established it should be propagated
down via environment. My feeling is that in longer term
is is better to learn how to propagate environment variables
on Mac OS. Otherwise, we risk that hacks which are reasonable
as "point" solution spread out to many places creating
hard to maintain mess.
--
Waldek Hebisch

[oldk1331]

On 6/29/22 23:05, Waldek Hebisch wrote:
> On Wed, Jun 29, 2022 at 10:00:21PM +0800, Qian Yun wrote:
>> I don't know if these 2 patches reached Waldek's mailbox or otherwise.
>>
>> (BTW, lynx can browse through https://github.com/fricas/fricas/pulls
>> to see open PRs.)
>>
>> They were submitted 10 days ago and I hope to get reviews.
>>
>> https://github.com/fricas/fricas/pull/93
>
> 93 looks OK. ICARD has many problems so I was thinking if
> we should do some major fixup or just merge this one.
> But it is probably better just to merge this fix.
>
>> https://github.com/fricas/fricas/pull/96
>>
>> For Paul's PR#96, I have verified his patch fixes the bug.
>
> Hmm, AFAICS 96 is from you. I wrote the following in comment
> section, but github apparently sent it to black hole:

Could you consider forwarding github replies to this list
in the future?

> I admit that it is not clear for me why you want this. At least
> some of places that you want to modify comunicate with C code.
> And in C code all we have is FRICAS environment variable
> (we definitely do not have access to Lisp '$spadroot').
>
> IIUC you wrote that passing environment variables on Mac OS is
> tricky. Having some fallback is reasonable, but preferably
> this fallback should be in one place, at top of process tree.
> And once fallback is established it should be propagated
> down via environment. My feeling is that in longer term
> is is better to learn how to propagate environment variables
> on Mac OS. Otherwise, we risk that hacks which are reasonable
> as "point" solution spread out to many places creating
> hard to maintain mess.

The macOS environment variable passing issue is solved.

- Qian

[Ralf Hemmecke]

> Could you consider forwarding github replies to this list
> in the future?

I don't understand. In my case github sends me a mail to my mailbox. I
can simply reply to that mail and it ends up in the github message queue
of the particular discussion.

Ralf

[Waldek Hebisch]

On Wed, Jun 29, 2022 at 11:20:33PM +0800, oldk1331 wrote:
> On 6/29/22 23:05, Waldek Hebisch wrote:
> > On Wed, Jun 29, 2022 at 10:00:21PM +0800, Qian Yun wrote:
> >> I don't know if these 2 patches reached Waldek's mailbox or otherwise.
> >>
> >> (BTW, lynx can browse through https://github.com/fricas/fricas/pulls
> >> to see open PRs.)
> >>
> >> They were submitted 10 days ago and I hope to get reviews.
> >>
> >> https://github.com/fricas/fricas/pull/93
> >
> > 93 looks OK. ICARD has many problems so I was thinking if
> > we should do some major fixup or just merge this one.
> > But it is probably better just to merge this fix.
> >
> >> https://github.com/fricas/fricas/pull/96
> >>
> >> For Paul's PR#96, I have verified his patch fixes the bug.
> >
> > Hmm, AFAICS 96 is from you. I wrote the following in comment
> > section, but github apparently sent it to black hole:
>
> Could you consider forwarding github replies to this list
> in the future?

That is a bit problematic, those are separate email accounts.

> > I admit that it is not clear for me why you want this. At least
> > some of places that you want to modify comunicate with C code.
> > And in C code all we have is FRICAS environment variable
> > (we definitely do not have access to Lisp '$spadroot').
> >
> > IIUC you wrote that passing environment variables on Mac OS is
> > tricky. Having some fallback is reasonable, but preferably
> > this fallback should be in one place, at top of process tree.
> > And once fallback is established it should be propagated
> > down via environment. My feeling is that in longer term
> > is is better to learn how to propagate environment variables
> > on Mac OS. Otherwise, we risk that hacks which are reasonable
> > as "point" solution spread out to many places creating
> > hard to maintain mess.
>
> The macOS environment variable passing issue is solved.

In such case I think it is preferable to limit hacks with
$spadroot and mostly use FRICAS environment variable.
AFAICS orignal purpose of $spadroot was to allow some
limited testing/use without setting envirionment. It
still helps with testing so I prefer to keep it, but
in normal use we should depend on FRICAS being set.

--
Waldek Hebisch

[oldk1331]

Recently at least two of Waldek's reply to github is missing --
aka didn't show up on the web interface. Consider he probably
only sent two dozens recently, the percentage is high.

Maybe we can have a github Bot to channel the communication,
I'll take a look at it.

- Qian