tack-devel — Discussion for developers of the ACK.

[Tack-devel] OT (Re: ACK_HOME and em_path)

[<u-...@ae...>]

On Thu, Mar 07, 2019 at 05:24:37PM +0100, David Given wrote:
> /opt vs /usr/local has been a long-standing holy war --- there's really
> very little in it. There both intended for add-on packages not supplied
> with the system. I grew up with /usr/local, so that's the one I picked.
> Anyone building distributable binaries will customise the setting anyway.
> 
> When you say 'other platforms', which ones do you mean? AFAIK OSX, Cygwin
> and Haiku all use /usr/local, or close-enough.

OT for the list and this thread, but all those "holy wars" about
"where stuff should be placed on every machine" were/are a result of
a misconception.

It is the hardcoded paths which make the exact placement "critical".

As soon as one distingushes between

1. "having the stuff" (any path is good enough)
2. "running the stuff" (what we need is a reference in the PATH or menus
   or alike, I call this "inlaying")
3. "letting the program know where to find what it needs" (which
   is to give it environment variables or alike, instead of hardwiring
   this into the binaries)

then it becomes apparent that the "administrative syncronization of paths
everywhere" is an artificial (and of course not solvable :) problem,
created by the intention to hardwire the references instead of letting
them be specified as-needed.

Rune

Re: [Tack-devel] ACK_HOME and em_path

[Carl E. C. <cec...@ya...>]

Greetings,
                   Actually I am more confused after your answer! If I 
build ACK for the MS-DOS target, what would be the value of EM_DIR in 
this case? C:/ack ? On Windows, it would really depend, there is a 
standard location, but it could be anywhere else. In all cases, i will 
keep as proposed and my comment does not change anything.

Regarding the install paths, i see that the new installation paths are 
different than the ones provided in the original ACK installation 
guide... and also different than the recommendation from the linux 
foundation.

The linux foundation recommends /opt/<package> with the different 
standard subdirectories under it... but maybe this is for binary 
installs only, and it does not apply to other UNIX flavors?
The issue with the new directory structure which I have seen is hardly 
portable to other platforms except UNIX like systems... i see lib/ack 
and share/ack.

Sorry for all this trouble and questions...
Carl




On 2019-03-07 23:02, David Given wrote:
> Filesystem layouts are pretty standard, actually, so precompiled 
> binaries will be built to use /usr/{share,lib} or 
> /usr/local/{share,lib} depending on whether the binaries are supplied 
> by the distribution or third-party. (Or {share,libexec} for the BSDs.
>
>
> On Thu, 7 Mar 2019 at 15:52 Carl Eric Codere <cec...@ya... 
> <mailto:cec...@ya...>> wrote:
>
>     Greetings,
>                      Ok to keep as backup, it makes sense, on the
>     other hand, for those systems where prebuilt binaries will be
>     provided, this constant will not be very useful...
>
>
>     Carl
>
>     On 2019-03-07 21:28, David Given wrote:
>>     We do still need the hard-coded path as a fall back --- we can't
>>     require end users to set an environment variable just to run a
>>     normal binary. I think we're going to need to keep em_path.h to
>>     configure this.
>>
>>     On Thu, 7 Mar 2019 at 12:16 Carl Eric Codere via Tack-devel
>>     <tac...@li...
>>     <mailto:tac...@li...>> wrote:
>>
>>         Greetings,
>>                         Ok! Message well received... simply using
>>         ACK_HOME with no magic tricks then!!
>>
>>         Carl
>>
>>
>>
>>         -------- Original message --------
>>         From: u-...@ae... <mailto:u-...@ae...>
>>         Date: 2019/03/07 16:49 (GMT+08:00)
>>         To: Carl Eric Codere <cec...@ya...
>>         <mailto:cec...@ya...>>
>>         Cc: tac...@li...
>>         <mailto:tac...@li...>
>>         Subject: Re: [Tack-devel] ACK_HOME and em_path
>>
>>         Hello Carl Erik,
>>
>>         On Thu, Mar 07, 2019 at 01:10:06AM +0000, Carl Eric Codere
>>         via Tack-devel wrote:
>>         > Greetings,
>>         >               Is it ok if eventually em_path.h is
>>         completely removed and is replaced by something that is
>>         checked at runtime instead of compile time? I do feel that
>>         doing this at compile time gives a bit of a limit on moving
>>         the install directory.
>>         >
>>         > For TMP_DIR, getenv() is used instead, this one is a
>>         no-brainer, and I already implemented it in the ANSI C porting.
>>         >
>>         > Now for EM_DIR, I propose the following:
>>         > * ACK_HOME environment variable would need to be set for it
>>         be used and should point to ACK install directory.
>>
>>         Consequently using a dedicated environment variable is good.
>>
>>         > Now the additional question, let us assume ACK_HOME is not
>>         set, do we simply fail, or do we try to check additional
>>         things, like the following:
>>         > ** If argv[0] contains a path, from there find and set
>>         ACK_HOME by deducing the installation path?
>>         > ** If argv[0] contains no path, search the PATH environment
>>         variable for the executable and from there deduce the
>>         installation path?
>>
>>         IMO (basically any) implicit heuristic search is harmful.
>>
>>         It makes un-/underconfigured installs deceptively look
>>         "right" and
>>         leads to headaches when things assumed to "magically just
>>         work" subtly
>>         work not exactly as one expected.
>>
>>         Neither argv[0] nor PATH are reliable pointers to the
>>         actually needed
>>         resources, nor the path to the running executable, even when
>>         it could be
>>         reliably found out on some platform.
>>
>>         Nor should they be assumed/constrained to be set up for such use,
>>         because they also are under other unrelated constraints and
>>         carry or may
>>         carry other important functions as well.
>>
>>         In other words, compiler development and system
>>         administration are
>>         different domains, it is highly unreliable to make
>>         assumptions across
>>         their borders.
>>
>>         As a matter of fact, I have to go out of my way to prevent
>>         possible harm
>>         from gcc's resource guesses from its argv[0].
>>
>>         Please do not make ack act in such fashion.
>>
>>         Rune
>>
>>         _______________________________________________
>>         Tack-devel mailing list
>>         Tac...@li...
>>         <mailto:Tac...@li...>
>>         https://lists.sourceforge.net/lists/listinfo/tack-devel
>>
>

Re: [Tack-devel] ACK_HOME and em_path

[<u-...@ae...>]

On Thu, Mar 07, 2019 at 04:02:58PM +0100, David Given wrote:
> Filesystem layouts are pretty standard, actually, so precompiled binaries
> will be built to use /usr/{share,lib} or /usr/local/{share,lib} depending
> on whether the binaries are supplied by the distribution or third-party.
> (Or {share,libexec} for the BSDs.

1. Isn't it just the compiler driver program which needs a specific setup?
It seems even respect environment vars like ACKDIR (looking at ack-5.5).

2. It is totally straightforward to keep all the stuff in a single
file tree and let people put the tree where they like.

Who is thought to be the consumer of precompiled binaries?

Setting an environment variable is not a big challenge for
an aspiring C developer, or is it?

This would drop the requirement for the recipient to be a superuser
(superuser can as well set up an environment variable, even for
all the users, or put a two-line bourne shell wrapper into
the PATH in use on the machine).

What needs fixing?

Rune

Re: [Tack-devel] ACK_HOME and em_path

[Carl E. C. <cec...@ya...>]

Greetings,
                 Thanks for clearing this point of, i did not grow up in 
UNIX environments... so i was not sure on this one.

As i said in a previous email, i have some crazy ideas, but the other 
platforms for ACK that I immediately see on top of the linux, BSD, MacOS 
are of course native Windows, MS-DOS and maybe AmigaOS.. And I see from 
the code I have looked up to now, it would be possible ... as long as 
addressable code space is more than 64K...

Because of technical limitations on some of those platforms, i would not 
actually build ACK on those platforms, but more cross compile to have 
ACK available for those platforms... I do feel it is possible...  But of 
course its a very long way off before this can be achieved .... :)

Carl



On 2019-03-08 00:24, David Given wrote:
> /opt vs /usr/local has been a long-standing holy war --- there's 
> really very little in it. There both intended for add-on packages not 
> supplied with the system. I grew up with /usr/local, so that's the one 
> I picked. Anyone building distributable binaries will customise the 
> setting anyway.
>
> When you say 'other platforms', which ones do you mean? AFAIK OSX, 
> Cygwin and Haiku all use /usr/local, or close-enough.
>
>
> On Thu, 7 Mar 2019 at 17:18 Carl Eric Codere <cec...@ya... 
> <mailto:cec...@ya...>> wrote:
>
>
>     Greetings,
>     ����������������� Actually I am
>     more confused after your answer! If I build ACK for the MS-DOS
>     target, what would be the value of EM_DIR in this case? C:/ack ?
>     On Windows, it would really depend, there is a standard location,
>     but it could be anywhere else. In all cases, i will keep as
>     proposed and my comment does not change anything.
>
>     Regarding the install paths, i see that the new installation paths
>     are different than the ones provided in the original ACK
>     installation guide... and also different than the recommendation
>     from the linux foundation.
>
>     The linux foundation recommends /opt/<package> with the different
>     standard subdirectories under it... but maybe this is for binary
>     installs only, and it does not apply to other UNIX flavors?
>     The issue with the new directory structure which I have seen is
>     hardly portable to other platforms except UNIX like systems... i
>     see lib/ack and share/ack.
>
>     Sorry for all this trouble and questions...
>     Carl
>
>
>
>
>
>     On 2019-03-07 23:02, David Given wrote:
>>     Filesystem layouts are pretty standard, actually, so precompiled
>>     binaries will be built to use /usr/{share,lib} or
>>     /usr/local/{share,lib} depending on whether the binaries are
>>     supplied by the distribution or third-party. (Or {share,libexec}
>>     for the BSDs.
>>
>>
>>     On Thu, 7 Mar 2019 at 15:52 Carl Eric Codere <cec...@ya...
>>     <mailto:cec...@ya...>> wrote:
>>
>>         Greetings,
>>         ���������������� Ok to keep
>>         as backup, it makes sense, on the other hand, for those
>>         systems where prebuilt binaries will be provided, this
>>         constant will not be very useful...
>>
>>
>>
>>         Carl
>>
>>         On 2019-03-07 21:28, David Given wrote:
>>
>>>         We do still need the hard-coded path as a fall back --- we
>>>         can't require end users to set an environment variable just
>>>         to run a normal binary. I think we're going to need to keep
>>>         em_path.h to configure this.
>>>
>>>         On Thu, 7 Mar 2019 at 12:16 Carl Eric Codere via Tack-devel
>>>         <tac...@li...
>>>         <mailto:tac...@li...>> wrote:
>>
>>>             Greetings,
>>>             � � � � � � � � Ok! Message well
>>>             received... simply using ACK_HOME with no magic tricks
>>>             then!!
>>>
>>>             Carl
>>>
>>>
>>>
>>>
>>>             -------- Original message --------
>>>             From: u-...@ae... <mailto:u-...@ae...>
>>>             Date: 2019/03/07 16:49 (GMT+08:00)
>>>             To: Carl Eric Codere <cec...@ya...
>>>             <mailto:cec...@ya...>>
>>>             Cc: tac...@li...
>>>             <mailto:tac...@li...>
>>>             Subject: Re: [Tack-devel] ACK_HOME and em_path
>>>
>>>             Hello Carl Erik,
>>>
>>>             On Thu, Mar 07, 2019 at 01:10:06AM +0000, Carl Eric
>>>             Codere via Tack-devel wrote:
>>>             > Greetings,
>>>
>>>             > ������������� Is it ok if
>>>             eventually em_path.h is completely removed and is
>>>             replaced by something that is checked at runtime instead
>>>             of compile time? I do feel that doing this at compile
>>>             time gives a bit of a limit on moving the install directory.
>>>
>>>
>>>             >
>>>             > For TMP_DIR, getenv() is used instead, this one is a
>>>             no-brainer, and I already implemented it in the ANSI C
>>>             porting.
>>>             >
>>>             > Now for EM_DIR, I propose the following:
>>>             > * ACK_HOME environment variable would need to be set
>>>             for it be used and should point to ACK install directory.
>>>
>>>             Consequently using a dedicated environment variable is good.
>>>
>>>             > Now the additional question, let us assume ACK_HOME is
>>>             not set, do we simply fail, or do we try to check
>>>             additional things, like the following:
>>>             > ** If argv[0] contains a path, from there find and set
>>>             ACK_HOME by deducing the installation path?
>>>             > ** If argv[0] contains no path, search the PATH
>>>             environment variable for the executable and from there
>>>             deduce the installation path?
>>>
>>>             IMO (basically any) implicit heuristic search is harmful.
>>>
>>>             It makes un-/underconfigured installs deceptively look
>>>             "right" and
>>>             leads to headaches when things assumed to "magically
>>>             just work" subtly
>>>             work not exactly as one expected.
>>>
>>>             Neither argv[0] nor PATH are reliable pointers to the
>>>             actually needed
>>>             resources, nor the path to the running executable, even
>>>             when it could be
>>>             reliably found out on some platform.
>>>
>>>             Nor should they be assumed/constrained to be set up for
>>>             such use,
>>>             because they also are under other unrelated constraints
>>>             and carry or may
>>>             carry other important functions as well.
>>>
>>>             In other words, compiler development and system
>>>             administration are
>>>             different domains, it is highly unreliable to make
>>>             assumptions across
>>>             their borders.
>>>
>>>             As a matter of fact, I have to go out of my way to
>>>             prevent possible harm
>>>             from gcc's resource guesses from its argv[0].
>>>
>>>             Please do not make ack act in such fashion.
>>>
>>>             Rune
>>>
>>>             _______________________________________________
>>>             Tack-devel mailing list
>>>             Tac...@li...
>>>             <mailto:Tac...@li...>
>>>             https://lists.sourceforge.net/lists/listinfo/tack-devel
>>>

Re: [Tack-devel] ACK_HOME and em_path

[David G. <dg...@co...>]

/opt vs /usr/local has been a long-standing holy war --- there's really
very little in it. There both intended for add-on packages not supplied
with the system. I grew up with /usr/local, so that's the one I picked.
Anyone building distributable binaries will customise the setting anyway.

When you say 'other platforms', which ones do you mean? AFAIK OSX, Cygwin
and Haiku all use /usr/local, or close-enough.


On Thu, 7 Mar 2019 at 17:18 Carl Eric Codere <cec...@ya...> wrote:

>
> Greetings,
> ����������������� Actually I am more
> confused after your answer! If I build ACK for the MS-DOS target, what
> would be the value of EM_DIR in this case? C:/ack ? On Windows, it would
> really depend, there is a standard location, but it could be anywhere else.
> In all cases, i will keep as proposed and my comment does not change
> anything.
>
> Regarding the install paths, i see that the new installation paths are
> different than the ones provided in the original ACK installation guide...
> and also different than the recommendation from the linux foundation.
>
> The linux foundation recommends /opt/<package> with the different standard
> subdirectories under it... but maybe this is for binary installs only, and
> it does not apply to other UNIX flavors?
> The issue with the new directory structure which I have seen is hardly
> portable to other platforms except UNIX like systems... i see lib/ack and
> share/ack.
>
> Sorry for all this trouble and questions...
> Carl
>
>
>
>
>
> On 2019-03-07 23:02, David Given wrote:
>
> Filesystem layouts are pretty standard, actually, so precompiled binaries
> will be built to use /usr/{share,lib} or /usr/local/{share,lib} depending
> on whether the binaries are supplied by the distribution or third-party.
> (Or {share,libexec} for the BSDs.
>
>
> On Thu, 7 Mar 2019 at 15:52 Carl Eric Codere <cec...@ya...> wrote:
>
> Greetings,
>> ���������������� Ok to keep as backup, it
>> makes sense, on the other hand, for those systems where prebuilt binaries
>> will be provided, this constant will not be very useful...
>>
>
>>
>> Carl
>>
>> On 2019-03-07 21:28, David Given wrote:
>>
> We do still need the hard-coded path as a fall back --- we can't require
>> end users to set an environment variable just to run a normal binary. I
>> think we're going to need to keep em_path.h to configure this.
>>
>> On Thu, 7 Mar 2019 at 12:16 Carl Eric Codere via Tack-devel <
>> tac...@li...> wrote:
>>
>> Greetings,
>>> � � � � � � � � Ok! Message well received... simply
>>> using ACK_HOME with no magic tricks then!!
>>>
>>> Carl
>>>
>>
>>>
>>>
>>> -------- Original message --------
>>> From: u-...@ae...
>>> Date: 2019/03/07 16:49 (GMT+08:00)
>>> To: Carl Eric Codere <cec...@ya...>
>>> Cc: tac...@li...
>>> Subject: Re: [Tack-devel] ACK_HOME and em_path
>>>
>>> Hello Carl Erik,
>>>
>>> On Thu, Mar 07, 2019 at 01:10:06AM +0000, Carl Eric Codere via
>>> Tack-devel wrote:
>>> > Greetings,
>>>
>> > ������������� Is it ok if eventually
>>> em_path.h is completely removed and is replaced by something that is
>>> checked at runtime instead of compile time? I do feel that doing this at
>>> compile time gives a bit of a limit on moving the install directory.
>>>
>>
>>> >
>>> > For TMP_DIR, getenv() is used instead, this one is a no-brainer, and I
>>> already implemented it in the ANSI C porting.
>>> >
>>> > Now for EM_DIR, I propose the following:
>>> > * ACK_HOME environment variable would need to be set for it be used
>>> and should point to ACK install directory.
>>>
>>> Consequently using a dedicated environment variable is good.
>>>
>>> > Now the additional question, let us assume ACK_HOME is not set, do we
>>> simply fail, or do we try to check additional things, like the following:
>>> > ** If argv[0] contains a path, from there find and set ACK_HOME by
>>> deducing the installation path?
>>> > ** If argv[0] contains no path, search the PATH environment variable
>>> for the executable and from there deduce the installation path?
>>>
>>> IMO (basically any) implicit heuristic search is harmful.
>>>
>>> It makes un-/underconfigured installs deceptively look "right" and
>>> leads to headaches when things assumed to "magically just work" subtly
>>> work not exactly as one expected.
>>>
>>> Neither argv[0] nor PATH are reliable pointers to the actually needed
>>> resources, nor the path to the running executable, even when it could be
>>> reliably found out on some platform.
>>>
>>> Nor should they be assumed/constrained to be set up for such use,
>>> because they also are under other unrelated constraints and carry or may
>>> carry other important functions as well.
>>>
>>> In other words, compiler development and system administration are
>>> different domains, it is highly unreliable to make assumptions across
>>> their borders.
>>>
>>> As a matter of fact, I have to go out of my way to prevent possible harm
>>> from gcc's resource guesses from its argv[0].
>>>
>>> Please do not make ack act in such fashion.
>>>
>>> Rune
>>>
>>> _______________________________________________
>>> Tack-devel mailing list
>>> Tac...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tack-devel
>>>
>>

Re: [Tack-devel] ACK_HOME and em_path

[<u-...@ae...>]

On Thu, Mar 07, 2019 at 02:28:30PM +0100, David Given wrote:
> We do still need the hard-coded path as a fall back --- we can't require
> end users to set an environment variable just to run a normal binary. I
> think we're going to need to keep em_path.h to configure this.
> 
> On Thu, 7 Mar 2019 at 12:16 Carl Eric Codere via Tack-devel <
> tac...@li...> wrote:
> 
> > Greetings,
> >                 Ok! Message well received... simply using ACK_HOME with no
> > magic tricks then!!

Thanks Carl!

OTOH I have to agree with David, hardcoding a path where an application
looks for its resources is a traditional practice, a necessary fallback
when a dedicated variable is not available.

This is of course different from silently falling back on the hardcoded
paths if a resource is not found via a _set_ variable. The latter
would make it uncertain whether the intention to use a specific
instance succeded or not.

Regards,
Rune

Re: [Tack-devel] ACK_HOME and em_path

[Carl E. C. <cec...@ya...>]

Greetings,
                    To make a compromise, knowing that this could lead 
to errors on certain systems... I propose the following after the 
fallback, or something similar:

    ...
#ifndef EM_DIR
     fatal();
#else
     return EM_DIR;
#endif


By the way, where this kind of common utility API that is specific to 
ACK be placed in? system? I am not sure if we have a location for this 
kind of common routines for ACK?

Ok for you all?
Carl


On 2019-03-07 22:52, Carl Eric Codere via Tack-devel wrote:
> Greetings,
>                  Ok to keep as backup, it makes sense, on the other 
> hand, for those systems where prebuilt binaries will be provided, this 
> constant will not be very useful...
>
>
> Carl
>
> On 2019-03-07 21:28, David Given wrote:
>> We do still need the hard-coded path as a fall back --- we can't 
>> require end users to set an environment variable just to run a normal 
>> binary. I think we're going to need to keep em_path.h to configure this.
>>
>> On Thu, 7 Mar 2019 at 12:16 Carl Eric Codere via Tack-devel 
>> <tac...@li... 
>> <mailto:tac...@li...>> wrote:
>>
>>     Greetings,
>>                     Ok! Message well received... simply using
>>     ACK_HOME with no magic tricks then!!
>>
>>     Carl
>>
>>
>>
>>     -------- Original message --------
>>     From: u-...@ae... <mailto:u-...@ae...>
>>     Date: 2019/03/07 16:49 (GMT+08:00)
>>     To: Carl Eric Codere <cec...@ya... <mailto:cec...@ya...>>
>>     Cc: tac...@li...
>>     <mailto:tac...@li...>
>>     Subject: Re: [Tack-devel] ACK_HOME and em_path
>>
>>     Hello Carl Erik,
>>
>>     On Thu, Mar 07, 2019 at 01:10:06AM +0000, Carl Eric Codere via
>>     Tack-devel wrote:
>>     > Greetings,
>>     >               Is it ok if eventually em_path.h is completely
>>     removed and is replaced by something that is checked at runtime
>>     instead of compile time? I do feel that doing this at compile
>>     time gives a bit of a limit on moving the install directory.
>>     >
>>     > For TMP_DIR, getenv() is used instead, this one is a
>>     no-brainer, and I already implemented it in the ANSI C porting.
>>     >
>>     > Now for EM_DIR, I propose the following:
>>     > * ACK_HOME environment variable would need to be set for it be
>>     used and should point to ACK install directory.
>>
>>     Consequently using a dedicated environment variable is good.
>>
>>     > Now the additional question, let us assume ACK_HOME is not set,
>>     do we simply fail, or do we try to check additional things, like
>>     the following:
>>     > ** If argv[0] contains a path, from there find and set ACK_HOME
>>     by deducing the installation path?
>>     > ** If argv[0] contains no path, search the PATH environment
>>     variable for the executable and from there deduce the
>>     installation path?
>>
>>     IMO (basically any) implicit heuristic search is harmful.
>>
>>     It makes un-/underconfigured installs deceptively look "right" and
>>     leads to headaches when things assumed to "magically just work"
>>     subtly
>>     work not exactly as one expected.
>>
>>     Neither argv[0] nor PATH are reliable pointers to the actually needed
>>     resources, nor the path to the running executable, even when it
>>     could be
>>     reliably found out on some platform.
>>
>>     Nor should they be assumed/constrained to be set up for such use,
>>     because they also are under other unrelated constraints and carry
>>     or may
>>     carry other important functions as well.
>>
>>     In other words, compiler development and system administration are
>>     different domains, it is highly unreliable to make assumptions across
>>     their borders.
>>
>>     As a matter of fact, I have to go out of my way to prevent
>>     possible harm
>>     from gcc's resource guesses from its argv[0].
>>
>>     Please do not make ack act in such fashion.
>>
>>     Rune
>>
>>     _______________________________________________
>>     Tack-devel mailing list
>>     Tac...@li...
>>     <mailto:Tac...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/tack-devel
>>
>
>
>
>
>
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel

Re: [Tack-devel] ACK_HOME and em_path

[David G. <dg...@co...>]

Filesystem layouts are pretty standard, actually, so precompiled binaries
will be built to use /usr/{share,lib} or /usr/local/{share,lib} depending
on whether the binaries are supplied by the distribution or third-party.
(Or {share,libexec} for the BSDs.


On Thu, 7 Mar 2019 at 15:52 Carl Eric Codere <cec...@ya...> wrote:

> Greetings,
>                  Ok to keep as backup, it makes sense, on the other hand,
> for those systems where prebuilt binaries will be provided, this constant
> will not be very useful...
>
>
> Carl
>
> On 2019-03-07 21:28, David Given wrote:
>
> We do still need the hard-coded path as a fall back --- we can't require
> end users to set an environment variable just to run a normal binary. I
> think we're going to need to keep em_path.h to configure this.
>
> On Thu, 7 Mar 2019 at 12:16 Carl Eric Codere via Tack-devel <
> tac...@li...> wrote:
>
>> Greetings,
>>                 Ok! Message well received... simply using ACK_HOME with
>> no magic tricks then!!
>>
>> Carl
>>
>>
>>
>> -------- Original message --------
>> From: u-...@ae...
>> Date: 2019/03/07 16:49 (GMT+08:00)
>> To: Carl Eric Codere <cec...@ya...>
>> Cc: tac...@li...
>> Subject: Re: [Tack-devel] ACK_HOME and em_path
>>
>> Hello Carl Erik,
>>
>> On Thu, Mar 07, 2019 at 01:10:06AM +0000, Carl Eric Codere via Tack-devel
>> wrote:
>> > Greetings,
>> >               Is it ok if eventually em_path.h is completely removed
>> and is replaced by something that is checked at runtime instead of compile
>> time? I do feel that doing this at compile time gives a bit of a limit on
>> moving the install directory.
>> >
>> > For TMP_DIR, getenv() is used instead, this one is a no-brainer, and I
>> already implemented it in the ANSI C porting.
>> >
>> > Now for EM_DIR, I propose the following:
>> > * ACK_HOME environment variable would need to be set for it be used and
>> should point to ACK install directory.
>>
>> Consequently using a dedicated environment variable is good.
>>
>> > Now the additional question, let us assume ACK_HOME is not set, do we
>> simply fail, or do we try to check additional things, like the following:
>> > ** If argv[0] contains a path, from there find and set ACK_HOME by
>> deducing the installation path?
>> > ** If argv[0] contains no path, search the PATH environment variable
>> for the executable and from there deduce the installation path?
>>
>> IMO (basically any) implicit heuristic search is harmful.
>>
>> It makes un-/underconfigured installs deceptively look "right" and
>> leads to headaches when things assumed to "magically just work" subtly
>> work not exactly as one expected.
>>
>> Neither argv[0] nor PATH are reliable pointers to the actually needed
>> resources, nor the path to the running executable, even when it could be
>> reliably found out on some platform.
>>
>> Nor should they be assumed/constrained to be set up for such use,
>> because they also are under other unrelated constraints and carry or may
>> carry other important functions as well.
>>
>> In other words, compiler development and system administration are
>> different domains, it is highly unreliable to make assumptions across
>> their borders.
>>
>> As a matter of fact, I have to go out of my way to prevent possible harm
>> from gcc's resource guesses from its argv[0].
>>
>> Please do not make ack act in such fashion.
>>
>> Rune
>>
>> _______________________________________________
>> Tack-devel mailing list
>> Tac...@li...
>> https://lists.sourceforge.net/lists/listinfo/tack-devel
>>
>
>

Re: [Tack-devel] ACK_HOME and em_path

[Carl E. C. <cec...@ya...>]

Greetings,
                  Ok to keep as backup, it makes sense, on the other 
hand, for those systems where prebuilt binaries will be provided, this 
constant will not be very useful...


Carl

On 2019-03-07 21:28, David Given wrote:
> We do still need the hard-coded path as a fall back --- we can't 
> require end users to set an environment variable just to run a normal 
> binary. I think we're going to need to keep em_path.h to configure this.
>
> On Thu, 7 Mar 2019 at 12:16 Carl Eric Codere via Tack-devel 
> <tac...@li... 
> <mailto:tac...@li...>> wrote:
>
>     Greetings,
>                     Ok! Message well received... simply using ACK_HOME
>     with no magic tricks then!!
>
>     Carl
>
>
>
>     -------- Original message --------
>     From: u-...@ae... <mailto:u-...@ae...>
>     Date: 2019/03/07 16:49 (GMT+08:00)
>     To: Carl Eric Codere <cec...@ya... <mailto:cec...@ya...>>
>     Cc: tac...@li...
>     <mailto:tac...@li...>
>     Subject: Re: [Tack-devel] ACK_HOME and em_path
>
>     Hello Carl Erik,
>
>     On Thu, Mar 07, 2019 at 01:10:06AM +0000, Carl Eric Codere via
>     Tack-devel wrote:
>     > Greetings,
>     >               Is it ok if eventually em_path.h is completely
>     removed and is replaced by something that is checked at runtime
>     instead of compile time? I do feel that doing this at compile time
>     gives a bit of a limit on moving the install directory.
>     >
>     > For TMP_DIR, getenv() is used instead, this one is a no-brainer,
>     and I already implemented it in the ANSI C porting.
>     >
>     > Now for EM_DIR, I propose the following:
>     > * ACK_HOME environment variable would need to be set for it be
>     used and should point to ACK install directory.
>
>     Consequently using a dedicated environment variable is good.
>
>     > Now the additional question, let us assume ACK_HOME is not set,
>     do we simply fail, or do we try to check additional things, like
>     the following:
>     > ** If argv[0] contains a path, from there find and set ACK_HOME
>     by deducing the installation path?
>     > ** If argv[0] contains no path, search the PATH environment
>     variable for the executable and from there deduce the installation
>     path?
>
>     IMO (basically any) implicit heuristic search is harmful.
>
>     It makes un-/underconfigured installs deceptively look "right" and
>     leads to headaches when things assumed to "magically just work" subtly
>     work not exactly as one expected.
>
>     Neither argv[0] nor PATH are reliable pointers to the actually needed
>     resources, nor the path to the running executable, even when it
>     could be
>     reliably found out on some platform.
>
>     Nor should they be assumed/constrained to be set up for such use,
>     because they also are under other unrelated constraints and carry
>     or may
>     carry other important functions as well.
>
>     In other words, compiler development and system administration are
>     different domains, it is highly unreliable to make assumptions across
>     their borders.
>
>     As a matter of fact, I have to go out of my way to prevent
>     possible harm
>     from gcc's resource guesses from its argv[0].
>
>     Please do not make ack act in such fashion.
>
>     Rune
>
>     _______________________________________________
>     Tack-devel mailing list
>     Tac...@li...
>     <mailto:Tac...@li...>
>     https://lists.sourceforge.net/lists/listinfo/tack-devel
>

Re: [Tack-devel] ACK_HOME and em_path

[David G. <dg...@co...>]

We do still need the hard-coded path as a fall back --- we can't require
end users to set an environment variable just to run a normal binary. I
think we're going to need to keep em_path.h to configure this.

On Thu, 7 Mar 2019 at 12:16 Carl Eric Codere via Tack-devel <
tac...@li...> wrote:

> Greetings,
>                 Ok! Message well received... simply using ACK_HOME with no
> magic tricks then!!
>
> Carl
>
>
>
> -------- Original message --------
> From: u-...@ae...
> Date: 2019/03/07 16:49 (GMT+08:00)
> To: Carl Eric Codere <cec...@ya...>
> Cc: tac...@li...
> Subject: Re: [Tack-devel] ACK_HOME and em_path
>
> Hello Carl Erik,
>
> On Thu, Mar 07, 2019 at 01:10:06AM +0000, Carl Eric Codere via Tack-devel
> wrote:
> > Greetings,
> >               Is it ok if eventually em_path.h is completely removed and
> is replaced by something that is checked at runtime instead of compile
> time? I do feel that doing this at compile time gives a bit of a limit on
> moving the install directory.
> >
> > For TMP_DIR, getenv() is used instead, this one is a no-brainer, and I
> already implemented it in the ANSI C porting.
> >
> > Now for EM_DIR, I propose the following:
> > * ACK_HOME environment variable would need to be set for it be used and
> should point to ACK install directory.
>
> Consequently using a dedicated environment variable is good.
>
> > Now the additional question, let us assume ACK_HOME is not set, do we
> simply fail, or do we try to check additional things, like the following:
> > ** If argv[0] contains a path, from there find and set ACK_HOME by
> deducing the installation path?
> > ** If argv[0] contains no path, search the PATH environment variable for
> the executable and from there deduce the installation path?
>
> IMO (basically any) implicit heuristic search is harmful.
>
> It makes un-/underconfigured installs deceptively look "right" and
> leads to headaches when things assumed to "magically just work" subtly
> work not exactly as one expected.
>
> Neither argv[0] nor PATH are reliable pointers to the actually needed
> resources, nor the path to the running executable, even when it could be
> reliably found out on some platform.
>
> Nor should they be assumed/constrained to be set up for such use,
> because they also are under other unrelated constraints and carry or may
> carry other important functions as well.
>
> In other words, compiler development and system administration are
> different domains, it is highly unreliable to make assumptions across
> their borders.
>
> As a matter of fact, I have to go out of my way to prevent possible harm
> from gcc's resource guesses from its argv[0].
>
> Please do not make ack act in such fashion.
>
> Rune
>
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel
>

Re: [Tack-devel] ACK_HOME and em_path

[Carl E. C. <cec...@ya...>]

Greetings,
                Ok! Message well received... simply using ACK_HOME with no magic tricks then!!

Carl



-------- Original message --------
From: u-...@ae... 
Date: 2019/03/07  16:49  (GMT+08:00) 
To: Carl Eric Codere <cec...@ya...> 
Cc: tac...@li... 
Subject: Re: [Tack-devel] ACK_HOME and em_path 

Hello Carl Erik,

On Thu, Mar 07, 2019 at 01:10:06AM +0000, Carl Eric Codere via Tack-devel wrote:
> Greetings,
>               Is it ok if eventually em_path.h is completely removed and is replaced by something that is checked at runtime instead of compile time? I do feel that doing this at compile time gives a bit of a limit on moving the install directory.
> 
> For TMP_DIR, getenv() is used instead, this one is a no-brainer, and I already implemented it in the ANSI C porting.
> 
> Now for EM_DIR, I propose the following:
> * ACK_HOME environment variable would need to be set for it be used and should point to ACK install directory.

Consequently using a dedicated environment variable is good.

> Now the additional question, let us assume ACK_HOME is not set, do we simply fail, or do we try to check additional things, like the following:
> ** If argv[0] contains a path, from there find and set ACK_HOME by deducing the installation path?
> ** If argv[0] contains no path, search the PATH environment variable for the executable and from there deduce the installation path?

IMO (basically any) implicit heuristic search is harmful.

It makes un-/underconfigured installs deceptively look "right" and
leads to headaches when things assumed to "magically just work" subtly
work not exactly as one expected.

Neither argv[0] nor PATH are reliable pointers to the actually needed
resources, nor the path to the running executable, even when it could be
reliably found out on some platform.

Nor should they be assumed/constrained to be set up for such use,
because they also are under other unrelated constraints and carry or may
carry other important functions as well.

In other words, compiler development and system administration are
different domains, it is highly unreliable to make assumptions across
their borders.

As a matter of fact, I have to go out of my way to prevent possible harm
from gcc's resource guesses from its argv[0].

Please do not make ack act in such fashion.

Rune

Re: [Tack-devel] ACK_HOME and em_path

[<u-...@ae...>]

Hello Carl Erik,

On Thu, Mar 07, 2019 at 01:10:06AM +0000, Carl Eric Codere via Tack-devel wrote:
> Greetings,
>               Is it ok if eventually em_path.h is completely removed and is replaced by something that is checked at runtime instead of compile time? I do feel that doing this at compile time gives a bit of a limit on moving the install directory.
> 
> For TMP_DIR, getenv() is used instead, this one is a no-brainer, and I already implemented it in the ANSI C porting.
> 
> Now for EM_DIR, I propose the following:
> * ACK_HOME environment variable would need to be set for it be used and should point to ACK install directory.

Consequently using a dedicated environment variable is good.

> Now the additional question, let us assume ACK_HOME is not set, do we simply fail, or do we try to check additional things, like the following:
> ** If argv[0] contains a path, from there find and set ACK_HOME by deducing the installation path?
> ** If argv[0] contains no path, search the PATH environment variable for the executable and from there deduce the installation path?

IMO (basically any) implicit heuristic search is harmful.

It makes un-/underconfigured installs deceptively look "right" and
leads to headaches when things assumed to "magically just work" subtly
work not exactly as one expected.

Neither argv[0] nor PATH are reliable pointers to the actually needed
resources, nor the path to the running executable, even when it could be
reliably found out on some platform.

Nor should they be assumed/constrained to be set up for such use,
because they also are under other unrelated constraints and carry or may
carry other important functions as well.

In other words, compiler development and system administration are
different domains, it is highly unreliable to make assumptions across
their borders.

As a matter of fact, I have to go out of my way to prevent possible harm
from gcc's resource guesses from its argv[0].

Please do not make ack act in such fashion.

Rune

[Tack-devel] ACK_HOME and em_path

[Carl E. C. <cec...@ya...>]

Greetings,
              Is it ok if eventually em_path.h is completely removed and is replaced by something that is checked at runtime instead of compile time? I do feel that doing this at compile time gives a bit of a limit on moving the install directory.

For TMP_DIR, getenv() is used instead, this one is a no-brainer, and I already implemented it in the ANSI C porting.

Now for EM_DIR, I propose the following:
* ACK_HOME environment variable would need to be set for it be used and should point to ACK install directory.
Now the additional question, let us assume ACK_HOME is not set, do we simply fail, or do we try to check additional things, like the following:
** If argv[0] contains a path, from there find and set ACK_HOME by deducing the installation path?
** If argv[0] contains no path, search the PATH environment variable for the executable and from there deduce the installation path?

I would of course adapt the current Makefile to migrate and not break anything today, where INSDIR = ACK_HOME if available for example.
Any opinions?
Carl

[Tack-devel] It keeps growing and growing and growing

[Digital P. <yos...@ma...>]

Share   Forward 
Click if you cannot see this message properly



Hey, have you seen Digital Payday yet?

 

>>>Just Sign Up<<<< , choose the banners that you like, 



And watch as your account balance grows and grows and grows 



As the banners keep bringing revenue, 24/7.



This isn’t trading, this isn’t risky like buying bitcoin, 



This is the safest and easiest way to make money online,



The exact same method that Facebook and Google use.



Choose ads, get paid. It’s like owning digital real estate



<<SIGN UP HERE>>



Easiest money you’ll ever make.



Once you see how it works, you’ll understand.

 Digital Payday Team



 Sender:Digital Payday. Sender's address: Old town rd, London. . Zipcode: WL 12876.
Unsubscribe from mailing list
If you suspect this message as a spam, Please inform us.

This message was sent using Sendmsg - 24/Sender

Re: [Tack-devel] Update on porting effort

[<u-...@ae...>]

> On Sat, 16 Feb 2019 at 14:14 <u-...@ae...> wrote:
> > unfortunately I anticipate some drawbacks.
 ...
> > The other is a loss of the presently sufficient constrained interface.
> >
> > When someone would have to adapt Ack to a new constrained environment,
> > one would have a challenge to find out which Posix/libc subset needs
> > to be ported there.

In practice, the developers are to assume the availability of all standard
features, unless you explicitly document a certain subset to be used.
Are you planning to define such a subset?

On Sat, Feb 16, 2019 at 03:31:32PM +0100, David Given wrote:
> Yup, that's exactly what I mean. Lose the library completely and use Posix
> interfaces throughout. On systems which need it, we can just typedef FILE
> to an int and then implement fread() as a tiny wrapper around read().
> 
> (We should probably have this anyway as a libc option. It looks like the
> ACK is mostly used for real for very small systems; I'm currently doing a
> tonne of work on the 8080 backend for Fuzix, and I get persistent bug
> reports from some working with CP/M that the stdio is just too big.)
> 
> This is equivalent to what the system library currently does --- except
> without the conceptual overhead of having to deal with an extra API with
> its own semantic quirks. Carl's reaction above on seeing File* is exactly
> what I'm trying to avoid here.

In one or another way, "system" or "libc", this ought to be documented
for the developers, which interfaces the compiler is to use.
See my question about a chosen subset above.

>  Provided we make a reasonable effort to use
> a minimal subset of the APIs available, there's little work here and a lot
> of win.
> 
> Code is cheap; understanding is expensive. Making the code easier to
> understand makes it easier to work with, and therefore there's more
> likelihood that people will understand what's going on (which we
> desperately need; a lot of the code is very opaque).

(What do you mean by saying that code is cheap?)
I agree with the rest of the paragraph, but the additional complexity of
the tiny "system" API reflects one of the desirable properties of the
code, to be as portable as feasible. The cost for this looks reasonable
to me.

> Plus, on systems which *don't* need the small library, we get stdio file
> buffering for free and faster compiles.

I believe I understand your motivation but still your arguments do not address
the issue of replacing a small API ("system") with a much, much larger one
(Posix/libc).

It is the larger API which will need to be available on all systems,
including the most limited ones, as soon as the compiler will depend on
that larger API.

The necessary effort is remarkably different regarding porting the
"system" library compared to adding Posix/libc compatibility
to a new environment.

Adding the latter is a very good thing, but can be prohibitively expensive,
especially if some features will have to be present for the sake of the
compiler and not otherwise.

The decision is of course yours. Hope that sharing my view helps
in some way.

Thanks for your work on Ack!

Rune

Re: [Tack-devel] Update on porting effort

[Carl E. C. <cec...@ya...>]

 Greetings,               Thanks for the clarification, and am happy you share the goal to make it work on small systems, I will try to see if i can eventually (very far from it), make it work on low-end systems and keep the .text segment to 64k.
Ok,  I had started to replace File* by FILE*, but it is too big of a change to do it in one shot, I will try to first commit the changes I made to have proper function prototyping in the ANSI C compiler and its dependencies... once this is done, I will move to the next step of cleaning up the usage of system and getting rid of File*.
Carl

    On Saturday, February 16, 2019, 6:54:44 PM GMT+8, David Given <dg...@co...> wrote:  
 
 Being able to build the ACK on small systems is definitely valuable, and we should keep it. That said, the current configuration can't do it and people aren't currently building it for these platforms. (Apart from anything else everything's built with the BigPars settings. See https://github.com/davidgiven/ack/blob/default/lang/cem/cemcom.ansi/BigPars vs SmallPars.) I'm quite sure that mcg won't work on these systems.
That said, I'm not sure that using a custom system library's the right way to do this. These days C is much more standard than it was back then and the need for custom wrappers to make sure that, e.g., realloc with NULL works properly isn't necessary. A lot of the stuff in system is equivalent to the standard Posix calls, or is unused completely (sys_lock --- in fact, I see that function's not even built!).
What I'd propose as a compromise is:
- if a system function is a trivial reimplementation of Posix, replace it with the Posix version.- do replace File* with FILE*. If it turns out to be too expensive later, we can replace the buffered stdio with an unbuffered implementation equivalent to the one in system, but using the standard interfaces.- don't start calling printf() where we don't need it. One of the things on the to-do list is to make printf cheaper, somehow (I have a few ideas), but let's not tempt fate. 

This way we should end up with standard interfaces, which makes things easier to work on and maintain, but still allow the small systems.

PS. I use cscope to search for symbols in the ACK tree. It's great. Do 'cscope -Rq' and then enter a function name in the box.
On Fri, 15 Feb 2019 at 07:49 Carl Eric Codere via Tack-devel <tac...@li...> wrote:

 Greetings,                 Thank you for the clarifications, it makes me understand the initial objectives.

I guess its a question for the current maintainers now:
In that case, I propose to keep system, and maybe at least in the current version have system use stdio as it is already doing now, clean it up a bit, expand it as necessary, and then when we need to support compiling on low end machines we just need to adapt system and not everything?

Is it also in the long term objectives of ACK development to run the compiler on older systems that are maybe within a minimal threshold? Not only as targets, but also as hosts? I would nice, no, not sure it its possible though?
 
Thanks again,
Carl


    On Thursday, February 14, 2019, 4:15:28 p.m. GMT+8, Jacobs, C.J.H. <c.j...@vu...> wrote:  
 
 Hi,

back when we developed ACK, we were worried about code size (in particular, the resulting size of binaries).
We needed to have versions of the compiler running in 16-bit address space (OK, we had separate instruction and data spaces),
but that meant that the compiler binary code had to fit in 64K, on systems that did not support shared libraries and such.
Using stdio would make that virtually impossible, because even back then, that would add 8-16K to the binary size (I don’t
remember exactly, but it was a lot). This is the reason that the ACK compiler front-ends don’t use printf, sprintf, FILE, etc.,
or anything that internally uses those.

Best wishes,

Ceriel Jacobs

> On 13 Feb 2019, at 16:25, Carl Eric Codere via Tack-devel <tac...@li...> wrote:
> 
> Greetings,
> ����������������� I am trying to be careful on the ansification process so i don't break anything, so I am carefully reviewing my changes before doing a commit in my branch, I have some questions, because i am probably missing some understanding.
> 
> * Why is the alloc library relying on the system library in NoMem(void) ? Can we simply not call fprintf(stderr.. ) and exit(EXIT_FAILURE) instead? It would make it more portable and less interdependent of other libraries, no?
> * Why is the print library relying on the system library for its I/O, same question as before, we could just replace File* by standard FILE* ?
> 
> The only reasons i could foresee are
> *� that this was done before ISO C90 and was not portable at the time? 
> *� when printing you may want to actually write somewhere else by implementing your own sys_xxx function.
> *� any others?
> 
> What is the objective of the system library?
> I thought it would contain API calls that are not fully portable, for example POSIX API's that we should "emulate" for each platform, or ISO C routines that must be overriden because of broken implementations in some libraries (tmpfile() and tmpnam() in Visual C++ come to mind)? other examples:
> * get file modification time.
> * create temp file
> But I see sys_write and sys_open ... I am ok to keep them, but it should not be a FILE* instead? 
> Should it also not also add some common API's gettmpdir() that could are used in different utilities, maybe instead it needs to be reimplemented?
> 
> Sorry for all those questions, but it is very difficult for me to understand the spirit of the above...
> 
> Thanks in advance,
> Carl
> 
> 
> 
> 
> 
> 
> 
> 
> On 2019-02-08 00:57, Carl Eric Codere via Tack-devel wrote:
>> On 2019-02-07 07:37, David Given wrote:
>>> Thanks very much --- that all sounds great!
>>> 
>>> Please, though, send lots of small PRs as you go rather than one big one. It's vastly easier to review and reduces the risk of stuff you're doing crossing stuff I'm doing. For example, I recently ANSIfied the Pascal and Basic compiler myself (although pretty crudely, just to make the warnings go away).
>>> 
>>> [...]
>> Ohoh.. you did those already? Ok, i will double check your changes and try to merge them with mine. While ansifying i try to follow the guidelines of the university of Michigan on C include files. Hope this is ok� (umich.edu/~eecs381/handouts/CHeaderFileGuidelines.pdf). 
>> 
>> I will try to push something soon, maybe by small batches... 
>>> ** Move the docs to the header file when they exist in the function 
>>> definition.
>>> 
>>> ...for anything other than public functions (i.e. stuff in public headers in modules/), it's best left next to the definition. This is because these usually describe the implementation, not the specification.
>>> �
>>> ** One-line sentence overview of function when I can do it.
>>> 
>>> Very valuable.
>>> �
>>> * Adapt to have internal prototypes and add STATIC to functions used 
>>> internally to a module.
>>> 
>>> Any reason not to simply use 'static'?
>> Actually you are right, but it is quite messy here, i saw that for the ANSI C compiler on LINT code they used a PRIVATE define while in pascal it was a STATIC define, better directly stick with the static as you proposed everywhere right? 
>> 
>>> �
>>> * Add CMake and use cmake to build portable scripts:
>>> ** Create sed scripts so no more shell requirement
>>> ** Create awk scripts so no more shell requirement.
>>> 
>>> I don't think CMake will cut it with the ACK --- it's too complex. In particular, the ACK needs the same module to be compiled multiple times with different settings, and I've found very few build systems that can handle that. (I so, so badly want to use bazel for this.)
>>> �
>> Actually, up to now i have had no issue.... BUT you are right, that I might get stuck when I am at building ACK... i will probably see what can be done, but my objective was to remove all references to bash shell scripts... and replace them with basic POSIX compliant tools...
>> 
>>> I have only ported the pascal and basic compilers now and since ack is 
>>> not compiled, I am testing by hand, but i see some issues:
>>> 
>>> There is a test suite, which is run automatically by the main build system. It's not a terribly complete test suite, but it does exist.
>>> �
>>> * The pascal compiler generates a� PRO pseudoinstruction without the 
>>> size, since its only 1 pass, so the old code generator chokes, because 
>>> it expects it, I have questions on this:�
>>> ** Do other compilers do this also? Will ncg also choke if the PRO does 
>>> not have the locals parameters?
>>> 
>>> The compiler output is always run through em_opt before being passed to a code generator, which among other things will add the parameter to PRO. You don't need to worry about it being missing in the code generator.
>> Ahhh.. ok, then after I have finished compiling the ANSI C compiler, i will go with porting that so i can test a bit and then start doing some pull requests... Thanks, that clarifies a lot.
>>> 
>>> BTW: Regarding the em documentation, I would like to update it (I see 
>>> mistakes in the specification), just wondering should it be converted to 
>>> something else than troff, or ok like that? Latex? Asciidoc? etc...� I 
>>> will not change anything on the format for now... just want an opinion 
>>> on this.
>>> 
>>> I'd very much like to keep the existing documentation, even though it's a mess. In my experience it's been surprisingly accurate; what errors did you find? Also, bear in mind that the code generators are significantly more relaxed about things like alignment than the spec actually decrees; I had to do a lot of fixing before the int interpreter would run some of the compiler output...
>>> 
>> Agreed, i can keep troff, just need to brush up on it i guess. Actually its not big mistake, more an omission, in the EM report, i could not find at least in what i read how a single byte value is encoded, maybe i missed it? And in the EM PDF i have, the annex gives information on em encodings which do not seem to fit with what is actually encoded in compact form... unless its something different? 
>> 
>> Carl
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Tack-devel mailing list
>> 
>> Tac...@li...
>> https://lists.sourceforge.net/lists/listinfo/tack-devel
> 
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel

  _______________________________________________
Tack-devel mailing list
Tac...@li...
https://lists.sourceforge.net/lists/listinfo/tack-devel

  

Re: [Tack-devel] Update on porting effort

[Carl E. C. <cec...@ya...>]

 Greetings,               Ok, I do understand your point of view and I have no issue with it, but I have several questions related to it once again.. sorry for the bother.
Do we agree that we should avoid POSIX calls in the C layer, and stick with ANSI C if possible (might not be possible in certain cases), right? 
Now a real use case:* I have replaced in LLgen mkstemp() by tmpnam() it is now fully ANSI, even though it has known race conditions, something acceptable for this project, right?* But you might already know tmpnam() is completely broken in Visual C++ and simply cannot be used.
In that case, for Visual C++ how do you solve it, or other ANSI C libraries which has such issues... how you fix it? The solution i made is to add TMPNAM wrapper as a function in machdep.c and then if necessary in the future, add platform specific parts for those broken libc API's there directly... Not sure if this is the correct approach though.
On the other hand, if POSIX calls are required, then we need to implement them on the platforms that are missing them, this is what you are saying? Using the semantics of the real POSIX API instead of a wrapper, so the "system" library would actually emulate the POSIX calls?
And for low-end platforms, we simply have libc simply call as directly as possible the kernel, by doing typedef's, etc, right, making it minimal, right?
Just trying to understand... Carl




    On Saturday, February 16, 2019, 10:32:08 PM GMT+8, David Given <dg...@co...> wrote:  
 
 Yup, that's exactly what I mean. Lose the library completely and use Posix interfaces throughout. On systems which need it, we can just typedef FILE to an int and then implement fread() as a tiny wrapper around read().
(We should probably have this anyway as a libc option. It looks like the ACK is mostly used for real for very small systems; I'm currently doing a tonne of work on the 8080 backend for Fuzix, and I get persistent bug reports from some working with CP/M that the stdio is just too big.)
This is equivalent to what the system library currently does --- except without the conceptual overhead of having to deal with an extra API with its own semantic quirks. Carl's reaction above on seeing File* is exactly what I'm trying to avoid here. Provided we make a reasonable effort to use a minimal subset of the APIs available, there's little work here and a lot of win.
Code is cheap; understanding is expensive. Making the code easier to understand makes it easier to work with, and therefore there's more likelihood that people will understand what's going on (which we desperately need; a lot of the code is very opaque).
Plus, on systems which don't need the small library, we get stdio file buffering for free and faster compiles.

On Sat, 16 Feb 2019 at 14:14 <u-...@ae...> wrote:

On Sat, Feb 16, 2019 at 11:54:31AM +0100, David Given wrote:
> Being able to build the ACK on small systems is definitely valuable, and we
> should keep it.

Appreciated.

> That said, I'm not sure that using a custom system library's the right way
> to do this. These days C is much more standard than it was back then and
> the need for custom wrappers to make sure that, e.g., realloc with NULL
> works properly isn't necessary. A lot of the stuff in system is equivalent
> to the standard Posix calls, or is unused completely (sys_lock --- in fact,
> I see that function's not even built!).
> 
> What I'd propose as a compromise is:
> 
> - if a system function is a trivial reimplementation of Posix, replace it
> with the Posix version.
> - *do* replace File* with FILE*. If it turns out to be too expensive later,
> we can replace the buffered stdio with an unbuffered implementation
> equivalent to the one in system, but using the standard interfaces.

I am not sure I am fully following you (any code accidentally
dereferencing *File would break with *FILE because FILE is opaque,
but this might be a non-issue here), assume that you intend to replace
references to the "system" library entries everywhere with corresponding
Posix and stdio equivalents, dropping the library out of existence,
or possibly keeping some entry points not falling under the cases above (?)

If this is a correct interpretation, I do not like to sound negative,
but unfortunately I anticipate some drawbacks.

One is to have to make changes in many files, this implies some
additional work and a risk for subtle breakage.

The other is a loss of the presently sufficient constrained interface.

When someone would have to adapt Ack to a new constrained environment,
one would have a challenge to find out which Posix/libc subset needs
to be ported there.

At that time the necessary set of operation will probably become larger
that today, if more Posix/libc calls will be introduced in different
parts of the code.

It is hard to expect that an Ack developer would always have in mind to
double check whether a certain Posix / C library call is already being
used or not.

> This way we should end up with standard interfaces, which makes things
> easier to work on and maintain, but still allow the small systems.

This particular interface is small (17 entry points?) and the implementation
takes 449 lines in *.[hc] and 324 lines of nroff in the man page.
An implementation of a minimal standard-compatible unbuffered
stdio would probably take at least about the same amount of LOC even if
the man page would become redundant (?).

To get some idea, I checked with avr-libc:
(buffered stdio, so take it with a large grain of salt, but anyway)
The docs say: "only a limited subset of standard IO is implemented"

The non-formatted i/o stdio code:
avr-libc-2.0.0/libc/stdio$ ls *.c | grep -v printf | grep -v scanf | xargs wc | tail -1
 1067  5812 39654 total

Everything in stdio:
avr-libc-2.0.0/libc/stdio$ wc * | tail -1
 4998  23588 160132 total

Rune


_______________________________________________
Tack-devel mailing list
Tac...@li...
https://lists.sourceforge.net/lists/listinfo/tack-devel
  

Re: [Tack-devel] Update on porting effort

[David G. <dg...@co...>]

Yup, that's exactly what I mean. Lose the library completely and use Posix
interfaces throughout. On systems which need it, we can just typedef FILE
to an int and then implement fread() as a tiny wrapper around read().

(We should probably have this anyway as a libc option. It looks like the
ACK is mostly used for real for very small systems; I'm currently doing a
tonne of work on the 8080 backend for Fuzix, and I get persistent bug
reports from some working with CP/M that the stdio is just too big.)

This is equivalent to what the system library currently does --- except
without the conceptual overhead of having to deal with an extra API with
its own semantic quirks. Carl's reaction above on seeing File* is exactly
what I'm trying to avoid here. Provided we make a reasonable effort to use
a minimal subset of the APIs available, there's little work here and a lot
of win.

Code is cheap; understanding is expensive. Making the code easier to
understand makes it easier to work with, and therefore there's more
likelihood that people will understand what's going on (which we
desperately need; a lot of the code is very opaque).

Plus, on systems which *don't* need the small library, we get stdio file
buffering for free and faster compiles.

On Sat, 16 Feb 2019 at 14:14 <u-...@ae...> wrote:

> On Sat, Feb 16, 2019 at 11:54:31AM +0100, David Given wrote:
> > Being able to build the ACK on small systems is definitely valuable, and
> we
> > should keep it.
>
> Appreciated.
>
> > That said, I'm not sure that using a custom system library's the right
> way
> > to do this. These days C is much more standard than it was back then and
> > the need for custom wrappers to make sure that, e.g., realloc with NULL
> > works properly isn't necessary. A lot of the stuff in system is
> equivalent
> > to the standard Posix calls, or is unused completely (sys_lock --- in
> fact,
> > I see that function's not even built!).
> >
> > What I'd propose as a compromise is:
> >
> > - if a system function is a trivial reimplementation of Posix, replace it
> > with the Posix version.
> > - *do* replace File* with FILE*. If it turns out to be too expensive
> later,
> > we can replace the buffered stdio with an unbuffered implementation
> > equivalent to the one in system, but using the standard interfaces.
>
> I am not sure I am fully following you (any code accidentally
> dereferencing *File would break with *FILE because FILE is opaque,
> but this might be a non-issue here), assume that you intend to replace
> references to the "system" library entries everywhere with corresponding
> Posix and stdio equivalents, dropping the library out of existence,
> or possibly keeping some entry points not falling under the cases above (?)
>
> If this is a correct interpretation, I do not like to sound negative,
> but unfortunately I anticipate some drawbacks.
>
> One is to have to make changes in many files, this implies some
> additional work and a risk for subtle breakage.
>
> The other is a loss of the presently sufficient constrained interface.
>
> When someone would have to adapt Ack to a new constrained environment,
> one would have a challenge to find out which Posix/libc subset needs
> to be ported there.
>
> At that time the necessary set of operation will probably become larger
> that today, if more Posix/libc calls will be introduced in different
> parts of the code.
>
> It is hard to expect that an Ack developer would always have in mind to
> double check whether a certain Posix / C library call is already being
> used or not.
>
> > This way we should end up with standard interfaces, which makes things
> > easier to work on and maintain, but still allow the small systems.
>
> This particular interface is small (17 entry points?) and the
> implementation
> takes 449 lines in *.[hc] and 324 lines of nroff in the man page.
> An implementation of a minimal standard-compatible unbuffered
> stdio would probably take at least about the same amount of LOC even if
> the man page would become redundant (?).
>
> To get some idea, I checked with avr-libc:
> (buffered stdio, so take it with a large grain of salt, but anyway)
> The docs say: "only a limited subset of standard IO is implemented"
>
> The non-formatted i/o stdio code:
> avr-libc-2.0.0/libc/stdio$ ls *.c | grep -v printf | grep -v scanf | xargs
> wc | tail -1
>  1067  5812 39654 total
>
> Everything in stdio:
> avr-libc-2.0.0/libc/stdio$ wc * | tail -1
>  4998  23588 160132 total
>
> Rune
>
>

Re: [Tack-devel] Update on porting effort

[<u-...@ae...>]

On Sat, Feb 16, 2019 at 11:54:31AM +0100, David Given wrote:
> Being able to build the ACK on small systems is definitely valuable, and we
> should keep it.

Appreciated.

> That said, I'm not sure that using a custom system library's the right way
> to do this. These days C is much more standard than it was back then and
> the need for custom wrappers to make sure that, e.g., realloc with NULL
> works properly isn't necessary. A lot of the stuff in system is equivalent
> to the standard Posix calls, or is unused completely (sys_lock --- in fact,
> I see that function's not even built!).
> 
> What I'd propose as a compromise is:
> 
> - if a system function is a trivial reimplementation of Posix, replace it
> with the Posix version.
> - *do* replace File* with FILE*. If it turns out to be too expensive later,
> we can replace the buffered stdio with an unbuffered implementation
> equivalent to the one in system, but using the standard interfaces.

I am not sure I am fully following you (any code accidentally
dereferencing *File would break with *FILE because FILE is opaque,
but this might be a non-issue here), assume that you intend to replace
references to the "system" library entries everywhere with corresponding
Posix and stdio equivalents, dropping the library out of existence,
or possibly keeping some entry points not falling under the cases above (?)

If this is a correct interpretation, I do not like to sound negative,
but unfortunately I anticipate some drawbacks.

One is to have to make changes in many files, this implies some
additional work and a risk for subtle breakage.

The other is a loss of the presently sufficient constrained interface.

When someone would have to adapt Ack to a new constrained environment,
one would have a challenge to find out which Posix/libc subset needs
to be ported there.

At that time the necessary set of operation will probably become larger
that today, if more Posix/libc calls will be introduced in different
parts of the code.

It is hard to expect that an Ack developer would always have in mind to
double check whether a certain Posix / C library call is already being
used or not.

> This way we should end up with standard interfaces, which makes things
> easier to work on and maintain, but still allow the small systems.

This particular interface is small (17 entry points?) and the implementation
takes 449 lines in *.[hc] and 324 lines of nroff in the man page.
An implementation of a minimal standard-compatible unbuffered
stdio would probably take at least about the same amount of LOC even if
the man page would become redundant (?).

To get some idea, I checked with avr-libc:
(buffered stdio, so take it with a large grain of salt, but anyway)
The docs say: "only a limited subset of standard IO is implemented"

The non-formatted i/o stdio code:
avr-libc-2.0.0/libc/stdio$ ls *.c | grep -v printf | grep -v scanf | xargs wc | tail -1
 1067  5812 39654 total

Everything in stdio:
avr-libc-2.0.0/libc/stdio$ wc * | tail -1
 4998  23588 160132 total

Rune

Re: [Tack-devel] Update on porting effort

[David G. <dg...@co...>]

Being able to build the ACK on small systems is definitely valuable, and we
should keep it. That said, the current configuration can't do it and people
aren't currently building it for these platforms. (Apart from anything else
everything's built with the BigPars settings. See
https://github.com/davidgiven/ack/blob/default/lang/cem/cemcom.ansi/BigPars vs
SmallPars.) I'm quite sure that mcg won't work on these systems.

That said, I'm not sure that using a custom system library's the right way
to do this. These days C is much more standard than it was back then and
the need for custom wrappers to make sure that, e.g., realloc with NULL
works properly isn't necessary. A lot of the stuff in system is equivalent
to the standard Posix calls, or is unused completely (sys_lock --- in fact,
I see that function's not even built!).

What I'd propose as a compromise is:

- if a system function is a trivial reimplementation of Posix, replace it
with the Posix version.
- *do* replace File* with FILE*. If it turns out to be too expensive later,
we can replace the buffered stdio with an unbuffered implementation
equivalent to the one in system, but using the standard interfaces.
- *don't* start calling printf() where we don't need it. One of the things
on the to-do list is to make printf cheaper, somehow (I have a few ideas),
but let's not tempt fate.

This way we should end up with standard interfaces, which makes things
easier to work on and maintain, but still allow the small systems.

PS. I use cscope to search for symbols in the ACK tree. It's great. Do
'cscope -Rq' and then enter a function name in the box.

On Fri, 15 Feb 2019 at 07:49 Carl Eric Codere via Tack-devel <
tac...@li...> wrote:

> Greetings,
>                  Thank you for the clarifications, it makes me understand
> the initial objectives.
>
> I guess its a question for the current maintainers now:
>
> In that case, I propose to keep system, and maybe at least in the current
> version have system use stdio as it is already doing now, clean it up a
> bit, expand it as necessary, and then when we need to support compiling on
> low end machines we just need to adapt system and not everything?
>
> Is it also in the long term objectives of ACK development to run the
> compiler on older systems that are maybe within a minimal threshold? Not
> only as targets, but also as hosts? I would nice, no, not sure it its
> possible though?
>
> Thanks again,
> Carl
>
>
> On Thursday, February 14, 2019, 4:15:28 p.m. GMT+8, Jacobs, C.J.H. <
> c.j...@vu...> wrote:
>
>
> Hi,
>
> back when we developed ACK, we were worried about code size (in
> particular, the resulting size of binaries).
> We needed to have versions of the compiler running in 16-bit address space
> (OK, we had separate instruction and data spaces),
> but that meant that the compiler binary code had to fit in 64K, on systems
> that did not support shared libraries and such.
> Using stdio would make that virtually impossible, because even back then,
> that would add 8-16K to the binary size (I don’t
> remember exactly, but it was a lot). This is the reason that the ACK
> compiler front-ends don’t use printf, sprintf, FILE, etc.,
> or anything that internally uses those.
>
> Best wishes,
>
> Ceriel Jacobs
>
> > On 13 Feb 2019, at 16:25, Carl Eric Codere via Tack-devel <
> tac...@li...> wrote:
> >
> > Greetings,
> > ����������������� I am trying to be
> careful on the ansification process so i don't break anything, so I am
> carefully reviewing my changes before doing a commit in my branch, I have
> some questions, because i am probably missing some understanding.
> >
> > * Why is the alloc library relying on the system library in NoMem(void)
> ? Can we simply not call fprintf(stderr.. ) and exit(EXIT_FAILURE) instead?
> It would make it more portable and less interdependent of other libraries,
> no?
> > * Why is the print library relying on the system library for its I/O,
> same question as before, we could just replace File* by standard FILE* ?
> >
> > The only reasons i could foresee are
> > *� that this was done before ISO C90 and was not portable at the time?
> > *� when printing you may want to actually write somewhere else by
> implementing your own sys_xxx function.
> > *� any others?
> >
> > What is the objective of the system library?
> > I thought it would contain API calls that are not fully portable, for
> example POSIX API's that we should "emulate" for each platform, or ISO C
> routines that must be overriden because of broken implementations in some
> libraries (tmpfile() and tmpnam() in Visual C++ come to mind)? other
> examples:
> > * get file modification time.
> > * create temp file
> > But I see sys_write and sys_open ... I am ok to keep them, but it should
> not be a FILE* instead?
> > Should it also not also add some common API's gettmpdir() that could are
> used in different utilities, maybe instead it needs to be reimplemented?
> >
> > Sorry for all those questions, but it is very difficult for me to
> understand the spirit of the above...
> >
> > Thanks in advance,
> > Carl
> >
> >
> >
> >
> >
> >
> >
> >
> > On 2019-02-08 00:57, Carl Eric Codere via Tack-devel wrote:
> >> On 2019-02-07 07:37, David Given wrote:
> >>> Thanks very much --- that all sounds great!
> >>>
> >>> Please, though, send lots of small PRs as you go rather than one big
> one. It's vastly easier to review and reduces the risk of stuff you're
> doing crossing stuff I'm doing. For example, I recently ANSIfied the Pascal
> and Basic compiler myself (although pretty crudely, just to make the
> warnings go away).
> >>>
> >>> [...]
> >> Ohoh.. you did those already? Ok, i will double check your changes and
> try to merge them with mine. While ansifying i try to follow the guidelines
> of the university of Michigan on C include files. Hope this is ok� (
> umich.edu/~eecs381/handouts/CHeaderFileGuidelines.pdf).
> >>
> >> I will try to push something soon, maybe by small batches...
> >>> ** Move the docs to the header file when they exist in the function
> >>> definition.
> >>>
> >>> ...for anything other than public functions (i.e. stuff in public
> headers in modules/), it's best left next to the definition. This is
> because these usually describe the implementation, not the specification.
> >>> �
> >>> ** One-line sentence overview of function when I can do it.
> >>>
> >>> Very valuable.
> >>> �
> >>> * Adapt to have internal prototypes and add STATIC to functions used
> >>> internally to a module.
> >>>
> >>> Any reason not to simply use 'static'?
> >> Actually you are right, but it is quite messy here, i saw that for the
> ANSI C compiler on LINT code they used a PRIVATE define while in pascal it
> was a STATIC define, better directly stick with the static as you proposed
> everywhere right?
> >>
> >>> �
> >>> * Add CMake and use cmake to build portable scripts:
> >>> ** Create sed scripts so no more shell requirement
> >>> ** Create awk scripts so no more shell requirement.
> >>>
> >>> I don't think CMake will cut it with the ACK --- it's too complex. In
> particular, the ACK needs the same module to be compiled multiple times
> with different settings, and I've found very few build systems that can
> handle that. (I so, so badly want to use bazel for this.)
> >>> �
> >> Actually, up to now i have had no issue.... BUT you are right, that I
> might get stuck when I am at building ACK... i will probably see what can
> be done, but my objective was to remove all references to bash shell
> scripts... and replace them with basic POSIX compliant tools...
> >>
> >>> I have only ported the pascal and basic compilers now and since ack is
> >>> not compiled, I am testing by hand, but i see some issues:
> >>>
> >>> There is a test suite, which is run automatically by the main build
> system. It's not a terribly complete test suite, but it does exist.
> >>> �
> >>> * The pascal compiler generates a� PRO pseudoinstruction without the
> >>> size, since its only 1 pass, so the old code generator chokes, because
> >>> it expects it, I have questions on this:�
> >>> ** Do other compilers do this also? Will ncg also choke if the PRO
> does
> >>> not have the locals parameters?
> >>>
> >>> The compiler output is always run through em_opt before being passed
> to a code generator, which among other things will add the parameter to
> PRO. You don't need to worry about it being missing in the code generator.
> >> Ahhh.. ok, then after I have finished compiling the ANSI C compiler, i
> will go with porting that so i can test a bit and then start doing some
> pull requests... Thanks, that clarifies a lot.
> >>>
> >>> BTW: Regarding the em documentation, I would like to update it (I see
> >>> mistakes in the specification), just wondering should it be converted
> to
> >>> something else than troff, or ok like that? Latex? Asciidoc? etc...�
> I
> >>> will not change anything on the format for now... just want an opinion
> >>> on this.
> >>>
> >>> I'd very much like to keep the existing documentation, even though
> it's a mess. In my experience it's been surprisingly accurate; what errors
> did you find? Also, bear in mind that the code generators are significantly
> more relaxed about things like alignment than the spec actually decrees; I
> had to do a lot of fixing before the int interpreter would run some of the
> compiler output...
> >>>
> >> Agreed, i can keep troff, just need to brush up on it i guess. Actually
> its not big mistake, more an omission, in the EM report, i could not find
> at least in what i read how a single byte value is encoded, maybe i missed
> it? And in the EM PDF i have, the annex gives information on em encodings
> which do not seem to fit with what is actually encoded in compact form...
> unless its something different?
> >>
> >> Carl
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Tack-devel mailing list
> >>
> >> Tac...@li...
> >> https://lists.sourceforge.net/lists/listinfo/tack-devel
>
> >
> > _______________________________________________
> > Tack-devel mailing list
> > Tac...@li...
> > https://lists.sourceforge.net/lists/listinfo/tack-devel
>
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel
>

Re: [Tack-devel] Update on porting effort

[<u-...@ae...>]

On Fri, Feb 15, 2019 at 06:08:54AM +0000, Carl Eric Codere via Tack-devel wrote:
> I guess its a question for the current maintainers now:
> In that case, I propose to keep system, and maybe at least in the current version have system use stdio as it is already doing now, clean it up a bit, expand it as necessary, and then when we need to support compiling on low end machines we just need to adapt system and not everything?
> 
> Is it also in the long term objectives of ACK development to run the compiler on older systems that are maybe within a minimal threshold? Not only as targets, but also as hosts? I would nice, no, not sure it its possible though?

I only qualify as a current maintainer for my Linux ackpack port, but
here follows my opinion:

Ack has its specific and not easily replaceable value of being capable
to run on constrained systems.

Of course, if other virtues (which motivate people to contribute to ack
at all?) conflict with this one, it is up to the benevolent dictator to
make a choice.

As long as such a virtue conflict is not present, I suggest to avoid
enforcing solutions heavier than ack actually needs.

The same applies to the choice of the build tools. Complex build tools
make self-hosting on constrained platforms impossible. This also
negatively affects reproducibility.

Nothing wrong with using advanced tools for the actual development and
debugging, where you change random places in the code and wish to rebuild
correctly, i.e. reflecting all build dependencies, and also very fast.

But a distribution IMHO should be always accompanied by a straightforward
script, taking paths to the needed resources explicitly (no fancy guessing),
to linearly and fully compile the software, by minimal tools. That's what
an integrator needs.

(hopefully the script would be made in a lightweight and easily available
language like Bourne shell using minimal Posix tools; not GNU make,
bash, perl, python with specific modules or alike)

Otherwise besides the usual dependency hell (not much in the case of ack)
one is faced by a deeper hell of the build tools (impossible to build
without a hardware at least 10-100-1000 times more powerful than ack needs
and without relying on 10-100-1000 times more lines of code? no, thanks! :)

Regards,
Rune

Re: [Tack-devel] Update on porting effort

[Carl E. C. <cec...@ya...>]

 Greetings,                 Thank you for the clarifications, it makes me understand the initial objectives.

I guess its a question for the current maintainers now:
In that case, I propose to keep system, and maybe at least in the current version have system use stdio as it is already doing now, clean it up a bit, expand it as necessary, and then when we need to support compiling on low end machines we just need to adapt system and not everything?

Is it also in the long term objectives of ACK development to run the compiler on older systems that are maybe within a minimal threshold? Not only as targets, but also as hosts? I would nice, no, not sure it its possible though?
 
Thanks again,
Carl


    On Thursday, February 14, 2019, 4:15:28 p.m. GMT+8, Jacobs, C.J.H. <c.j...@vu...> wrote:  
 
 Hi,

back when we developed ACK, we were worried about code size (in particular, the resulting size of binaries).
We needed to have versions of the compiler running in 16-bit address space (OK, we had separate instruction and data spaces),
but that meant that the compiler binary code had to fit in 64K, on systems that did not support shared libraries and such.
Using stdio would make that virtually impossible, because even back then, that would add 8-16K to the binary size (I don’t
remember exactly, but it was a lot). This is the reason that the ACK compiler front-ends don’t use printf, sprintf, FILE, etc.,
or anything that internally uses those.

Best wishes,

Ceriel Jacobs

> On 13 Feb 2019, at 16:25, Carl Eric Codere via Tack-devel <tac...@li...> wrote:
> 
> Greetings,
> ����������������� I am trying to be careful on the ansification process so i don't break anything, so I am carefully reviewing my changes before doing a commit in my branch, I have some questions, because i am probably missing some understanding.
> 
> * Why is the alloc library relying on the system library in NoMem(void) ? Can we simply not call fprintf(stderr.. ) and exit(EXIT_FAILURE) instead? It would make it more portable and less interdependent of other libraries, no?
> * Why is the print library relying on the system library for its I/O, same question as before, we could just replace File* by standard FILE* ?
> 
> The only reasons i could foresee are
> *� that this was done before ISO C90 and was not portable at the time? 
> *� when printing you may want to actually write somewhere else by implementing your own sys_xxx function.
> *� any others?
> 
> What is the objective of the system library?
> I thought it would contain API calls that are not fully portable, for example POSIX API's that we should "emulate" for each platform, or ISO C routines that must be overriden because of broken implementations in some libraries (tmpfile() and tmpnam() in Visual C++ come to mind)? other examples:
> * get file modification time.
> * create temp file
> But I see sys_write and sys_open ... I am ok to keep them, but it should not be a FILE* instead? 
> Should it also not also add some common API's gettmpdir() that could are used in different utilities, maybe instead it needs to be reimplemented?
> 
> Sorry for all those questions, but it is very difficult for me to understand the spirit of the above...
> 
> Thanks in advance,
> Carl
> 
> 
> 
> 
> 
> 
> 
> 
> On 2019-02-08 00:57, Carl Eric Codere via Tack-devel wrote:
>> On 2019-02-07 07:37, David Given wrote:
>>> Thanks very much --- that all sounds great!
>>> 
>>> Please, though, send lots of small PRs as you go rather than one big one. It's vastly easier to review and reduces the risk of stuff you're doing crossing stuff I'm doing. For example, I recently ANSIfied the Pascal and Basic compiler myself (although pretty crudely, just to make the warnings go away).
>>> 
>>> [...]
>> Ohoh.. you did those already? Ok, i will double check your changes and try to merge them with mine. While ansifying i try to follow the guidelines of the university of Michigan on C include files. Hope this is ok� (umich.edu/~eecs381/handouts/CHeaderFileGuidelines.pdf). 
>> 
>> I will try to push something soon, maybe by small batches... 
>>> ** Move the docs to the header file when they exist in the function 
>>> definition.
>>> 
>>> ...for anything other than public functions (i.e. stuff in public headers in modules/), it's best left next to the definition. This is because these usually describe the implementation, not the specification.
>>> �
>>> ** One-line sentence overview of function when I can do it.
>>> 
>>> Very valuable.
>>> �
>>> * Adapt to have internal prototypes and add STATIC to functions used 
>>> internally to a module.
>>> 
>>> Any reason not to simply use 'static'?
>> Actually you are right, but it is quite messy here, i saw that for the ANSI C compiler on LINT code they used a PRIVATE define while in pascal it was a STATIC define, better directly stick with the static as you proposed everywhere right? 
>> 
>>> �
>>> * Add CMake and use cmake to build portable scripts:
>>> ** Create sed scripts so no more shell requirement
>>> ** Create awk scripts so no more shell requirement.
>>> 
>>> I don't think CMake will cut it with the ACK --- it's too complex. In particular, the ACK needs the same module to be compiled multiple times with different settings, and I've found very few build systems that can handle that. (I so, so badly want to use bazel for this.)
>>> �
>> Actually, up to now i have had no issue.... BUT you are right, that I might get stuck when I am at building ACK... i will probably see what can be done, but my objective was to remove all references to bash shell scripts... and replace them with basic POSIX compliant tools...
>> 
>>> I have only ported the pascal and basic compilers now and since ack is 
>>> not compiled, I am testing by hand, but i see some issues:
>>> 
>>> There is a test suite, which is run automatically by the main build system. It's not a terribly complete test suite, but it does exist.
>>> �
>>> * The pascal compiler generates a� PRO pseudoinstruction without the 
>>> size, since its only 1 pass, so the old code generator chokes, because 
>>> it expects it, I have questions on this:�
>>> ** Do other compilers do this also? Will ncg also choke if the PRO does 
>>> not have the locals parameters?
>>> 
>>> The compiler output is always run through em_opt before being passed to a code generator, which among other things will add the parameter to PRO. You don't need to worry about it being missing in the code generator.
>> Ahhh.. ok, then after I have finished compiling the ANSI C compiler, i will go with porting that so i can test a bit and then start doing some pull requests... Thanks, that clarifies a lot.
>>> 
>>> BTW: Regarding the em documentation, I would like to update it (I see 
>>> mistakes in the specification), just wondering should it be converted to 
>>> something else than troff, or ok like that? Latex? Asciidoc? etc...� I 
>>> will not change anything on the format for now... just want an opinion 
>>> on this.
>>> 
>>> I'd very much like to keep the existing documentation, even though it's a mess. In my experience it's been surprisingly accurate; what errors did you find? Also, bear in mind that the code generators are significantly more relaxed about things like alignment than the spec actually decrees; I had to do a lot of fixing before the int interpreter would run some of the compiler output...
>>> 
>> Agreed, i can keep troff, just need to brush up on it i guess. Actually its not big mistake, more an omission, in the EM report, i could not find at least in what i read how a single byte value is encoded, maybe i missed it? And in the EM PDF i have, the annex gives information on em encodings which do not seem to fit with what is actually encoded in compact form... unless its something different? 
>> 
>> Carl
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Tack-devel mailing list
>> 
>> Tac...@li...
>> https://lists.sourceforge.net/lists/listinfo/tack-devel
> 
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel

  

Re: [Tack-devel] Update on porting effort

[<u-...@ae...>]

On Thu, Feb 14, 2019 at 08:15:25AM +0000, Jacobs, C.J.H. via Tack-devel wrote:
> back when we developed ACK, we were worried about code size (in particular, the resulting size of binaries).
> We needed to have versions of the compiler running in 16-bit address space (OK, we had separate instruction and data spaces),
> but that meant that the compiler binary code had to fit in 64K, on systems that did not support shared libraries and such.
> Using stdio would make that virtually impossible, because even back then, that would add 8-16K to the binary size (I don’t
> remember exactly, but it was a lot). This is the reason that the ACK compiler front-ends don’t use printf, sprintf, FILE, etc.,
> or anything that internally uses those.

Hello Ceriel,

Thanks for the explanation.

I hope this compactness does not have to be sacrificed for the ansification.

It would be certainly exciting to have a version (as ack-4 was, or
possibly even the ack-5-derived minix ackpack?) capable of self-hosting on
16-bit platforms, not necessarily only on retrostyle pdp11-lookalikes but
why not on, say, risc-v rv16*? Run under Fuzix?

IMHO as long as there is a compact i/o library sufficient for the compiler
I would rather keep it - you never know when somebody would need to run
the compiler or its derivative on a constrained platform.

Rune

Re: [Tack-devel] Update on porting effort

[Jacobs, C.J.H. <c.j...@vu...>]

Hi,

back when we developed ACK, we were worried about code size (in particular, the resulting size of binaries).
We needed to have versions of the compiler running in 16-bit address space (OK, we had separate instruction and data spaces),
but that meant that the compiler binary code had to fit in 64K, on systems that did not support shared libraries and such.
Using stdio would make that virtually impossible, because even back then, that would add 8-16K to the binary size (I don’t
remember exactly, but it was a lot). This is the reason that the ACK compiler front-ends don’t use printf, sprintf, FILE, etc.,
or anything that internally uses those.

Best wishes,

Ceriel Jacobs

> On 13 Feb 2019, at 16:25, Carl Eric Codere via Tack-devel <tac...@li...> wrote:
> 
> Greetings,
> ����������������� I am trying to be careful on the ansification process so i don't break anything, so I am carefully reviewing my changes before doing a commit in my branch, I have some questions, because i am probably missing some understanding.
> 
> * Why is the alloc library relying on the system library in NoMem(void) ? Can we simply not call fprintf(stderr.. ) and exit(EXIT_FAILURE) instead? It would make it more portable and less interdependent of other libraries, no?
> * Why is the print library relying on the system library for its I/O, same question as before, we could just replace File* by standard FILE* ?
> 
> The only reasons i could foresee are
> *� that this was done before ISO C90 and was not portable at the time? 
> *� when printing you may want to actually write somewhere else by implementing your own sys_xxx function.
> *� any others?
> 
> What is the objective of the system library?
> I thought it would contain API calls that are not fully portable, for example POSIX API's that we should "emulate" for each platform, or ISO C routines that must be overriden because of broken implementations in some libraries (tmpfile() and tmpnam() in Visual C++ come to mind)? other examples:
> * get file modification time.
> * create temp file
> But I see sys_write and sys_open ... I am ok to keep them, but it should not be a FILE* instead? 
> Should it also not also add some common API's gettmpdir() that could are used in different utilities, maybe instead it needs to be reimplemented?
> 
> Sorry for all those questions, but it is very difficult for me to understand the spirit of the above...
> 
> Thanks in advance,
> Carl
> 
> 
> 
> 
> 
> 
> 
> 
> On 2019-02-08 00:57, Carl Eric Codere via Tack-devel wrote:
>> On 2019-02-07 07:37, David Given wrote:
>>> Thanks very much --- that all sounds great!
>>> 
>>> Please, though, send lots of small PRs as you go rather than one big one. It's vastly easier to review and reduces the risk of stuff you're doing crossing stuff I'm doing. For example, I recently ANSIfied the Pascal and Basic compiler myself (although pretty crudely, just to make the warnings go away).
>>> 
>>> [...]
>> Ohoh.. you did those already? Ok, i will double check your changes and try to merge them with mine. While ansifying i try to follow the guidelines of the university of Michigan on C include files. Hope this is ok� (umich.edu/~eecs381/handouts/CHeaderFileGuidelines.pdf). 
>> 
>> I will try to push something soon, maybe by small batches... 
>>> ** Move the docs to the header file when they exist in the function 
>>> definition.
>>> 
>>> ...for anything other than public functions (i.e. stuff in public headers in modules/), it's best left next to the definition. This is because these usually describe the implementation, not the specification.
>>> �
>>> ** One-line sentence overview of function when I can do it.
>>> 
>>> Very valuable.
>>> �
>>> * Adapt to have internal prototypes and add STATIC to functions used 
>>> internally to a module.
>>> 
>>> Any reason not to simply use 'static'?
>> Actually you are right, but it is quite messy here, i saw that for the ANSI C compiler on LINT code they used a PRIVATE define while in pascal it was a STATIC define, better directly stick with the static as you proposed everywhere right? 
>> 
>>> �
>>> * Add CMake and use cmake to build portable scripts:
>>> ** Create sed scripts so no more shell requirement
>>> ** Create awk scripts so no more shell requirement.
>>> 
>>> I don't think CMake will cut it with the ACK --- it's too complex. In particular, the ACK needs the same module to be compiled multiple times with different settings, and I've found very few build systems that can handle that. (I so, so badly want to use bazel for this.)
>>> �
>> Actually, up to now i have had no issue.... BUT you are right, that I might get stuck when I am at building ACK... i will probably see what can be done, but my objective was to remove all references to bash shell scripts... and replace them with basic POSIX compliant tools...
>> 
>>> I have only ported the pascal and basic compilers now and since ack is 
>>> not compiled, I am testing by hand, but i see some issues:
>>> 
>>> There is a test suite, which is run automatically by the main build system. It's not a terribly complete test suite, but it does exist.
>>> �
>>> * The pascal compiler generates a� PRO pseudoinstruction without the 
>>> size, since its only 1 pass, so the old code generator chokes, because 
>>> it expects it, I have questions on this:�
>>> ** Do other compilers do this also? Will ncg also choke if the PRO does 
>>> not have the locals parameters?
>>> 
>>> The compiler output is always run through em_opt before being passed to a code generator, which among other things will add the parameter to PRO. You don't need to worry about it being missing in the code generator.
>> Ahhh.. ok, then after I have finished compiling the ANSI C compiler, i will go with porting that so i can test a bit and then start doing some pull requests... Thanks, that clarifies a lot.
>>> 
>>> BTW: Regarding the em documentation, I would like to update it (I see 
>>> mistakes in the specification), just wondering should it be converted to 
>>> something else than troff, or ok like that? Latex? Asciidoc? etc...� I 
>>> will not change anything on the format for now... just want an opinion 
>>> on this.
>>> 
>>> I'd very much like to keep the existing documentation, even though it's a mess. In my experience it's been surprisingly accurate; what errors did you find? Also, bear in mind that the code generators are significantly more relaxed about things like alignment than the spec actually decrees; I had to do a lot of fixing before the int interpreter would run some of the compiler output...
>>> 
>> Agreed, i can keep troff, just need to brush up on it i guess. Actually its not big mistake, more an omission, in the EM report, i could not find at least in what i read how a single byte value is encoded, maybe i missed it? And in the EM PDF i have, the annex gives information on em encodings which do not seem to fit with what is actually encoded in compact form... unless its something different? 
>> 
>> Carl
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Tack-devel mailing list
>> 
>> Tac...@li...
>> https://lists.sourceforge.net/lists/listinfo/tack-devel
> 
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel

Re: [Tack-devel] Update on porting effort

[Carl E. C. <cec...@ya...>]

Greetings,
                   I am trying to be careful on the ansification process 
so i don't break anything, so I am carefully reviewing my changes before 
doing a commit in my branch, I have some questions, because i am 
probably missing some understanding.

* Why is the alloc library relying on the system library in NoMem(void) 
? Can we simply not call fprintf(stderr.. ) and exit(EXIT_FAILURE) 
instead? It would make it more portable and less interdependent of other 
libraries, no?
* Why is the print library relying on the system library for its I/O, 
same question as before, we could just replace File* by standard FILE* ?

The only reasons i could foresee are
*  that this was done before ISO C90 and was not portable at the time?
*  when printing you may want to actually write somewhere else by 
implementing your own sys_xxx function.
*  any others?

What is the objective of the system library?
I thought it would contain API calls that are not fully portable, for 
example POSIX API's that we should "emulate" for each platform, or ISO C 
routines that must be overriden because of broken implementations in 
some libraries (tmpfile() and tmpnam() in Visual C++ come to mind)? 
other examples:
* get file modification time.
* create temp file
But I see sys_write and sys_open ... I am ok to keep them, but it should 
not be a FILE* instead?
Should it also not also add some common API's gettmpdir() that could are 
used in different utilities, maybe instead it needs to be reimplemented?

Sorry for all those questions, but it is very difficult for me to 
understand the spirit of the above...

Thanks in advance,
Carl








On 2019-02-08 00:57, Carl Eric Codere via Tack-devel wrote:
> On 2019-02-07 07:37, David Given wrote:
>> Thanks very much --- that all sounds great!
>>
>> Please, though, send lots of small PRs as you go rather than one big 
>> one. It's vastly easier to review and reduces the risk of stuff 
>> you're doing crossing stuff I'm doing. For example, I recently 
>> ANSIfied the Pascal and Basic compiler myself (although pretty 
>> crudely, just to make the warnings go away).
>>
>> [...]
> Ohoh.. you did those already? Ok, i will double check your changes and 
> try to merge them with mine. While ansifying i try to follow the 
> guidelines of the university of Michigan on C include files. Hope this 
> is ok  (umich.edu/~eecs381/handouts/CHeaderFileGuidelines.pdf).
>
> I will try to push something soon, maybe by small batches...
>>
>>     ** Move the docs to the header file when they exist in the function
>>     definition.
>>
>>
>> ...for anything other than public functions (i.e. stuff in public 
>> headers in modules/), it's best left next to the definition. This is 
>> because these usually describe the /implementation/, not the 
>> specification.
>>
>>     ** One-line sentence overview of function when I can do it.
>>
>>
>> Very valuable.
>>
>>     * Adapt to have internal prototypes and add STATIC to functions used
>>     internally to a module.
>>
>>
>> Any reason not to simply use 'static'?
> Actually you are right, but it is quite messy here, i saw that for the 
> ANSI C compiler on LINT code they used a PRIVATE define while in 
> pascal it was a STATIC define, better directly stick with the static 
> as you proposed everywhere right?
>
>>     * Add CMake and use cmake to build portable scripts:
>>     ** Create sed scripts so no more shell requirement
>>     ** Create awk scripts so no more shell requirement.
>>
>>
>> I don't think CMake will cut it with the ACK --- it's too complex. In 
>> particular, the ACK needs the same module to be compiled multiple 
>> times with different settings, and I've found very few build systems 
>> that can handle that. (I so, so badly want to use bazel for this.)
> Actually, up to now i have had no issue.... BUT you are right, that I 
> might get stuck when I am at building ACK... i will probably see what 
> can be done, but my objective was to remove all references to bash 
> shell scripts... and replace them with basic POSIX compliant tools...
>
>>     I have only ported the pascal and basic compilers now and since
>>     ack is
>>     not compiled, I am testing by hand, but i see some issues:
>>
>>
>> There is a test suite, which is run automatically by the main build 
>> system. It's not a terribly complete test suite, but it does exist.
>>
>>     * The pascal compiler generates a  PRO pseudoinstruction without the
>>     size, since its only 1 pass, so the old code generator chokes,
>>     because
>>     it expects it, I have questions on this: 
>>
>>     ** Do other compilers do this also? Will ncg also choke if the
>>     PRO does
>>     not have the locals parameters?
>>
>>
>> The compiler output is always run through em_opt before being passed 
>> to a code generator, which among other things will add the parameter 
>> to PRO. You don't need to worry about it being missing in the code 
>> generator.
> Ahhh.. ok, then after I have finished compiling the ANSI C compiler, i 
> will go with porting that so i can test a bit and then start doing 
> some pull requests... Thanks, that clarifies a lot.
>>
>>     BTW: Regarding the em documentation, I would like to update it (I
>>     see
>>     mistakes in the specification), just wondering should it be
>>     converted to
>>     something else than troff, or ok like that? Latex? Asciidoc?
>>     etc...  I
>>     will not change anything on the format for now... just want an
>>     opinion
>>     on this.
>>
>>
>> I'd very much like to keep the existing documentation, even though 
>> it's a mess. In my experience it's been surprisingly accurate; what 
>> errors did you find? Also, bear in mind that the code generators are 
>> significantly more relaxed about things like alignment than the spec 
>> actually decrees; I had to do a lot of fixing before the int 
>> interpreter would run some of the compiler output...
>>
> Agreed, i can keep troff, just need to brush up on it i guess. 
> Actually its not big mistake, more an omission, in the EM report, i 
> could not find at least in what i read how a single byte value is 
> encoded, maybe i missed it? And in the EM PDF i have, the annex gives 
> information on em encodings which do not seem to fit with what is 
> actually encoded in compact form... unless its something different?
>
> Carl
>
>
>
>
>
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel