Re: Compilation error with GCC
Jouke is the MVP on response time! On Sun, Dec 19, 2021 at 8:05 PM Jouke Witteveen wrote: > I believe what you are seeing is reported here: > https://savannah.gnu.org/bugs/?60798 > > The patches "file #52422" and "file #52428" should resolve your issues. > > Regards, > - Jouke > > On Sun, Dec 19, 2021 at 7:55 PM Mohammad Akhlaghi > wrote: > > > > So sorry, there was a typo in my last mail: > > > > As the previously attached file shows, I was built Make over commit > > 'e62f4cf9a2eaf7' (Sun Nov 28 14:17:55 2021 -0500). > > > > Cheers, > > Mohammad > > > > On 12/19/21 19:49, Mohammad Akhlaghi wrote: > > > Dear GNU Make maintainers, > > > > > > I just cloned Make (with the 'master' branch on commit c5d4b7b2f260c) > > > and bootstrapped it with Gnulib (on commit 64f5221ef20ba) on Arch > > > GNU/Linux and with GCC 11.1.0 and Glibc 2.33. > > > > > > The configuration went nicely, however, during the compilation it > > > crashed with the attached error. > > > > > > Please let me know if any further information is necessary. > > > > > > Thank you, > > > Mohammad > > > > > > >
Re: Make language
L O L On Tue, Oct 12, 2021 at 7:31 PM Kevin R. Bulgrien < kev...@systemsdesignusa.com> wrote: > Sviđa mi se! > > -- > Kevin R. Bulgrien > > - Original Message - > > From: "Dmitry Goncharov via Bug reports and discussion for GNU make" < > bug-make@gnu.org> > > To: "Bartol Hrg" > > Cc: bug-make@gnu.org > > Sent: Tuesday, October 12, 2021 12:25:05 PM > > Subject: Re: Make language > > > > On Tue, Oct 12, 2021 at 10:38 AM Bartol Hrg > > wrote: > > > > > > Greetings > > > > > > I installed make 3.81 for Windows > > > > > > It's in d*mn Croatian! > > > > > > Now, I don't know if you noticed, but I speak English. > > > > > > I'm really displeased and agitated. > > > > > > Best regards > > > B. Helium > > > > Dobar dan. > > Vaš pošta je na Engleskom jeziku. > > Ne znam jeste li primijetili, ali govorim Hrvatski. > > Stvarno sam nezadovoljna i uznemirena. > > > > Iskreno, Dmitry > >
Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison
Also perhaps the more general mathematical function On Mon, Sep 13, 2021 at 10:04 PM Randall S. Becker wrote: > On September 13, 2021 2:40 PM, Jouke Witteveen wrote: > >On Fri, Jul 16, 2021 at 2:04 PM Jouke Witteveen > wrote: > >> > >> Numbers can come from $(words ...), automatic variables such as > >> $(MAKELEVEL), from environment variables, or from shell output such as > >> through $(shell expr ...). The $(compare ...) function allows > >> conditional evaluation controlled by numerical variables. > >> > >> * NEWS: Announce this feature. > >> * doc/make.texi (Functions for Conditionals): Document 'compare'. > >> * src/function.c (func_compare): Create the 'compare' built-in function. > >> * tests/scripts/functions/compare: Test the 'compare' built-in function. > >> --- > >> > >> This is a cleaned-up and documented version of a proposal submitted a > >> year ago. The interface was conceived by Edward Welbourne and myself. > >> Personally, I would not introduce mathematical operators to make, but > >> given that numbers are a thing and they do pop up in variables, a > >> comparison function makes sense to me. > >> > >> Thanks for considering! > >> - Jouke > > > >I would still be interested in seeing this patch series I sent two months > ago considered. I am not in a rush: this is just a friendly reminder. > > I am interested in this series as well, although something more general > might also be interesting, like a general version compare function like > $(compare 1.6.1 1.6.100), and that also take into account character-based > versioning, like $(compare A10.88 B20.94). > > -Randall > > >
Re: Makefile Error
It looks like there is no recipe for a target named 'flash'. I see that there are several other Makefiles being included which may be intended to provide a 'flash' target. One include is on line 313: -include $(COMPONENT_PROJECT_VARS) because of the leading '-', if this include fails, it will do so silently. Since I don't see any other include failure messages in the Make output, this include directive could be the culprit. On Fri, Jun 25, 2021 at 12:35 AM Vignesh Chandrasekaran wrote: > > Hi Pete, > > Thanks for the reply, attached as requested. > > Best Regards, > Vignesh > > > On Fri, Jun 25, 2021 at 3:31 PM Pete Dietl wrote: >> >> Would need to see project.mk >> >> On Fri, Jun 25, 2021 at 12:16 AM Vignesh Chandrasekaran >> wrote: >>> >>> Dear Sir/Madam, >>> >>> I was recently trying to use make to compile my code and flash it into an >>> ESP32 chip when I ran into an error (please see attachment). >>> >>> I have attached the makefile for your reference as well. When I went to the >>> online forum, it seems that a lot of other Windows users face this issue as >>> well. >>> >>> Hope that you can advise me on any fixes possible, thank you very much! >>> >>> Best Regards, >>> Vignesh
Re: Makefile Error
Would need to see project.mk On Fri, Jun 25, 2021 at 12:16 AM Vignesh Chandrasekaran < vignesh.2...@gmail.com> wrote: > Dear Sir/Madam, > > I was recently trying to use make to compile my code and flash it into an > ESP32 chip when I ran into an error (please see attachment). > > I have attached the makefile for your reference as well. When I went to > the online forum, it seems that a lot of other Windows users face this > issue as well. > > Hope that you can advise me on any fixes possible, thank you very much! > > Best Regards, > Vignesh >
Re: Implement make --all-targets-matching-regexp
Yes but the Perl option is not good enough when there are dynamically generated targets or when there are includes. On Fri, Apr 2, 2021 at 6:01 AM 積丹尼 Dan Jacobson wrote: > >>>>> "PD" == Pete Dietl writes: > PD> Perhaps a better option would be to make an option to list all > PD> targets. > > That would just be e.g., > perl -nwle 'print for /^\w+:/g;' > > PD> Then one can grep to select ones in any which way. > > Well OK, I guess all this won't be needing make to add such features then. >
Re: Implement make --all-targets-matching-regexp
Perhaps a better option would be to make an option to list all targets. Then one can grep to select ones in any which way. On Thu, Apr 1, 2021 at 11:52 PM 積丹尼 Dan Jacobson wrote: > > Let's take Makefile: > > alzu:; echo $@ > Blibco:; echo $@ > Norfowitz; echo $@ > nillsburg; echo $@ > > Well let's say we want to run all the capital letter items. > We could use > $ make Blibco Norfowitz > but that isn't as smart as > $ make --all-targets-matching-regexp '^[A-Z].*' #Or instead these kinds or > regexps: > $ make --all-targets-matching-regexp '[A-Z]*' > > GNU Make 4.3 >
Re: [PATCH] More correctly describe the scope of variables
A very good point!
src/job.c patch
From: Pete Dietl Date: Thu, 31 Dec 2020 15:55:19 -0800 Subject: [PATCH] * src/job.c: add third argument to find_in_given_path function call. Gnulib added a third argument to this function on 2020-12-14 --- src/job.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/job.c b/src/job.c index d6e28d3..861527b 100644 --- a/src/job.c +++ b/src/job.c @@ -2391,7 +2391,7 @@ child_execute_job (struct childbase *child, int good_stdin, char **argv) } } -cmd = (char *)find_in_given_path (argv[0], p, 0); +cmd = (char *)find_in_given_path (argv[0], p, 0, NULL); } if (!cmd) -- 2.25.1
Re: [PATCH] More correctly describe the scope of variables
So if you imagine each function call as creating a new environment, an
environment being a dictionary of key value pairs that stores variables we
define locally AND a “parent pointer” to another environment, then we can
define lexical vs dynamic scoping as follows:
Lexical: the parent pointer in a new environment points not one up the
function call stack, but to the environment in which the function was
defined.
Dynamic: the parent pointer in a new environment points to the previous
function call in the stack.
Then we have local vs global scope. Local means the variable is stored in
the current environment. Global means that we go all the way up the
environments until we get to the top and place the variable there.
Some languages let you explicitly choose to put a variable in the global
scope or the local scope.
Take Bash for instance, it is dynamically scoped, but has global and local
variables. For example:
bar() {
echo "a is '$a'"
}
foo() {
local a=''
bar
}
foo
echo "a is '$a'"
This will output:
a is ''
a is ''
This is because Bash is dynamically scoped, but explicitly not globally in
this case.
Compare to:
bar() {
echo "a is '$a'"
}
foo() {
a=''
bar
}
foo
echo "a is '$a'"
This will output:
a is ''
a is ''
This is because by default Bash puts variables into the global scope. When
one does this, one cannot tell whether or not the language is dynamically
or lexically scoped. But Bash allows us to tell since it has a notion of
local vs global variables.
Now for Make, there are no semantics for telling whether or not it is
lexically or dynamically scoped. This is because previously the only local
variables were the function arguments. Since these arguments are always
named the same thing, even if the language were dynamically scoped,
successive function calls would create new function argument variables
which shadow the previous ones. If you try to use eval to create functions
or variables on the fly, it works but both are added to the global scope.
So, perhaps you could say that make had globally scoped variables only. But
now it also has local variables. The question is, with the introduction of
the let function, is it using dynamic or lexical scoping? I think it's
clear that it is creating local variables (or bindings), but the important
thing to know is if it is dynamic or lexical.
On Fri, Dec 25, 2020 at 10:00 AM Jouke Witteveen
wrote:
> * NEWS: Use "local" instead of the incorrect "lexically-scoped".
> * doc/make.texi: Refer to let/foreach variables as local variables.
> ---
> This is an erratum on the addition of $(let ...). During an early review
> of $(let ...), thutt cautioned that it did not implement "full semantic
> scoping" [sic]. While I did not understand fully what they meant by
> that, I countered that it was not intended to determine a scope based on
> for example which file a definition of a rule occurred in, but simply by
> the parentheses delimiting the let expression. Only in that sense was it
> lexical scoping. Technically, make variables are dynamically scoped.
>
> This patch replaces "lexically scoped" not by "dynamically scoped", but
> by "local", since that is the whole point after all. It also includes
> variables with local scope (from let and foreach) in several other
> places where variables are discussed, and makes explicit that variables
> in make are dynamically scoped.
>
> NEWS | 4 ++--
> doc/make.texi | 21 +++--
> 2 files changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index 5d71488..5356260 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -35,8 +35,8 @@
> https://sv.gnu.org/bugs/index.php?group=make_id=111_release_id=109
>The configure script should verify the compiler has these features.
>
> * New feature: The $(let ...) function
> - This function allows user-defined functions to provide a
> lexically-scoped
> - set of variables: values can be assigned to these variables from within
> the
> + This function allows user-defined functions to define a set of local
> + variables: values can be assigned to these variables from within the
>user-defined function and they will not impact global variable
> assignments.
>Implementation provided by Jouke Witteveen
>
> diff --git a/doc/make.texi b/doc/make.texi
> index fe64ec2..d7891c9 100644
> --- a/doc/make.texi
> +++ b/doc/make.texi
> @@ -276,7 +276,7 @@ Functions for Transforming Text
> * Text Functions:: General-purpose text manipulation
> functions.
> * File Name Functions:: Functions for manipulating file names.
> * Conditional Functions:: Functions that implement conditions.
> -* Let Function::Lexically scoped variables.
> +* Let Function::Local variables.
> * Foreach Function::Repeat some text with controlled
> variation.
> * File Function:: Write text to a file.
> * Call Function:: Expand a
Re: [PATCH 2/2 V2] * doc/make.texi: Document the let function
This whole section is called “Functions for Transforming Text,” but is this really an accurate title anymore? Maybe we should just rename it to “Functions.” Also, I ran ‘’make html”, but it doesn’t look like it does on he website. Does anyone know how I can build the docs to look like the website locally?
Re: Form feeds in source code
Alright I concede. As long as people are getting use out of them and they are not vestigial, then they have reason to stay of course. On Fri, Sep 18, 2020 at 2:57 PM Eli Zaretskii wrote: > > From: Pete Dietl > > Date: Fri, 18 Sep 2020 14:33:58 -0500 > > Cc: bug-make , Edward Welbourne < > edward.welbou...@qt.io>, p...@mad-scientist.net > > > > Would it also be a reasonable request then to add in vim markers for > custom folding or indentation/formatting > > directives? > > Why not? > > > Also, the space between form feeds sometimes goes well beyond a typical > terminal screen. For instance in > > variable.c, there is one at line 178 and the next is on line 301 and > then at 448. Those are probably not > > particularly useful for anyone (correct me if I'm wrong). > > The "page" doesn't have to fit on a screen. Those markers serve as > page delimiters, where each "page" covers one of the subjects covered > by the entire file. So these markers are for easy movement between > these parts of the file, not for displaying them in their entirety on > the screen. > > Think about chapters in a text document -- these markers separate > such "chapters", and Emacs offers commands to move to the Nth next or > previous "chapter". >
Re: Form feeds in source code
I was not intending to offend anyone. I literally meant that emacs is an editor among many. Would it also be a reasonable request then to add in vim markers for custom folding or indentation/formatting directives? Also, the space between form feeds sometimes goes well beyond a typical terminal screen. For instance in variable.c, there is one at line 178 and the next is on line 301 and then at 448. Those are probably not particularly useful for anyone (correct me if I'm wrong). I suppose the alternative to removing them is instead to add more of them to properly segment the files for logical viewing. On Fri, Sep 18, 2020 at 2:19 PM Eli Zaretskii wrote: > > From: Pete Dietl > > > Date: Fri, 18 Sep 2020 11:27:18 -0500 > > > Cc: "p...@mad-scientist.net" , > > > bug-make > > > > > > I think keeping them in for the sake of one editor is not a good reason. > I think they make the code look messy > > > and dated, personally. > > > > With all due respect, Emacs is not just "one editor". > > > > I second the request to not delete these page markers. > >
Re: Form feeds in source code
I think keeping them in for the sake of one editor is not a good reason. I think they make the code look messy and dated, personally. On Fri, Sep 18, 2020 at 11:24 AM Edward Welbourne wrote: > On Fri, 2020-09-18 at 10:59 -0500, Pete Dietl wrote: > > >> Why are there so many form feeds in the source? > > > > Paul Smith (18 September 2020 18:12) replied: > > > That was the style that Roland used when the code was written: form > > > feeds were used inside a source file to separate major functions. > > > > > > I guess it hails from a time when it wasn't that unusual to print out > > > your code to physical paper, on a printer, and read it that way. Then > > > it would be nice to have a major function start at the top of the > > > page. > > > > In emacs, at least, the editor provides easy commands to jump to the > > start or end of the present "page" - i.e. the last or next form-feed - > > and this can be a great convenience for moving through a file, jumping > > to the start of a *logical* page, rather than paging down by whatever > > screen-full your present screen-size gives you. I, for one, find such > > markers useful in emacs. > > > > They are harmless, let them be ! > > > > Eddy. > >
Re: Form feeds in source code
So I’m free to submit a patch to delete these? :)
On Fri, Sep 18, 2020 at 11:12 AM Blake McBride wrote:
> In the old days, with limited memory, editors would only read a file up to
> the formfeed. The programmer would edit the text up to the formfeed and
> then read in the next block (up to the next formfeed). This way the whole
> file need not be in memory at once. Compilers ignore it. Obviously they
> can be eliminated now.
>
> Blake McBride
>
>
>
>
>
> On Fri, Sep 18, 2020 at 11:08 AM Pete Dietl wrote:
>
>> Why are there so many form feeds in the source?
>>
>> Running this from the root of the Make repo:
>>
>> cd src && grep -c $'\f' *.[ch] | grep -v ':0$' | sort -t : -k 2 -n -r |
>> awk -F : 'BEGIN {printf "%-15s Number of form feeds\n", "File"; print
>> "" } {printf "%-15s %2d\n", $1, $2}'
>>
>> Results in:
>>
>> FileNumber of form feeds
>>
>> variable.c 17
>> read.c 15
>> misc.c 12
>> job.c 11
>> function.c 10
>> dir.c 10
>> remake.c 9
>> main.c 8
>> file.c 8
>> expand.c 6
>> commands.c 6
>> vpath.c 5
>> rule.c 5
>> output.c 5
>> getopt.c 4
>> arscan.c 4
>> remote-stub.c3
>> remote-cstms.c 3
>> ar.c 3
>> implicit.c 2
>> getopt1.c2
>> version.c1
>> makeint.h1
>> hash.h 1
>> default.c1
>>
>>
>>
>
>
Form feeds in source code
Why are there so many form feeds in the source?
Running this from the root of the Make repo:
cd src && grep -c $'\f' *.[ch] | grep -v ':0$' | sort -t : -k 2 -n -r | awk
-F : 'BEGIN {printf "%-15s Number of form feeds\n", "File"; print
"" } {printf "%-15s %2d\n", $1, $2}'
Results in:
FileNumber of form feeds
variable.c 17
read.c 15
misc.c 12
job.c 11
function.c 10
dir.c 10
remake.c 9
main.c 8
file.c 8
expand.c 6
commands.c 6
vpath.c 5
rule.c 5
output.c 5
getopt.c 4
arscan.c 4
remote-stub.c3
remote-cstms.c 3
ar.c 3
implicit.c 2
getopt1.c2
version.c1
makeint.h1
hash.h 1
default.c1
Re: Help wanted from 2003
I'm afraid that that help wanted list is severely defunct.
Re: math expressions (was: Re: Tail call elimination)
Upon taking a look at gnulib, I found that they have arithmetic wrap functions which guarantee wrapping. We can use these functions to guarantee that overflow will just wrap around. Let's leave the shift operators out for now. comp is for complement. ~ In most scheme implementations, providing only one operand to the arithmetic functions just returns that argument, aside from subtraction, which negates the argument. Once again I am aiming for the single argument syntax of $(math ...) Interestingly, in Guile, (+) and (*) return 1, but (/) and (-) return errors about invalid number of arguments. Personally, I think no operands should result in an error. Thoughts?
Re: math expressions (was: Re: Tail call elimination)
Any suggestions or comments? On Wed, May 27, 2020 at 1:47 PM Pete Dietl wrote: > > A few questions. > > Technically, the C standard allows for machines which don't use 2's > complement. > So should we consider our LONG_MIN to be -2^63 + 1? > > Also, signed arithmetic overflow is undefined behavior, so should we also > indicate that we have undefined behavior or should we use some > function that reliably detects and > wraps signed arithmetic? > > Bit shifting to the right with signed integers is undefined behavior > too. Usually this is an arithmetic shift, > but it's not guaranteed. Should we try to guarantee this with some > function or should we leave this as undefined behavior? > > Before I make my proposal, what do you think of supporting the > following operators: > +, -, /, *, not, and, or, comp, <<, >> > > Should the logical operators have english names or should they be C > symbols like !, &, |, ~ ?
Re: math expressions (was: Re: Tail call elimination)
A few questions. Technically, the C standard allows for machines which don't use 2's complement. So should we consider our LONG_MIN to be -2^63 + 1? Also, signed arithmetic overflow is undefined behavior, so should we also indicate that we have undefined behavior or should we use some function that reliably detects and wraps signed arithmetic? Bit shifting to the right with signed integers is undefined behavior too. Usually this is an arithmetic shift, but it's not guaranteed. Should we try to guarantee this with some function or should we leave this as undefined behavior? Before I make my proposal, what do you think of supporting the following operators: +, -, /, *, not, and, or, comp, <<, >> Should the logical operators have english names or should they be C symbols like !, &, |, ~ ?
Re: math expressions (was: Re: Tail call elimination)
> This really annoys me and keeps me on the fence about gnulib, and > prevents me from completely switching (for example, moving to modern > glob/fnmatch). I've only pulled in some relatively simple elements so > far. > > So... I'm not sure which way to fall on that. Apparently gnulib requires > at least a freestanding C99 compiler which is responsible for providing ``. So we can just use int64_t.
Re: math expressions (was: Re: Tail call elimination)
> I believe the form being considered is: > > $(math OPERATOR,LIST) I am still partial to `$(math ...)` with only one argument. > The only one I'm not sure about is overflow. That will need some > thought. Gnulib contains a comprehensive set of macros to deal with > overflow, in various ways. My initial thought was to simply leave it implementation defined, like C does for signed integers.
Re: math expressions (was: Re: Tail call elimination)
`long long` was not introduced until c99, neither was `stdint.h`, but perhaps gnulib can help us out here. On Mon, May 25, 2020 at 3:44 PM Pete Dietl wrote: > > > I was not even considering specifying the base of the the resulting > > expansion. I was assuming it would always be base 10. I don't have > > any good way to specify the output form. > > > > I was only considering the parsing of input (constant) values: whether > > we wanted to support 0xfff, 0o777, 0b111 as well as base 10. I don't > > want to support "traditional" octal values that start with plain 0... I > > believe that's always been a bad idea and it's especially bad in the > > context of makefiles where values are all strings right up until the > > moment they're parsed. > > I definitely agree with 0x 0o 0b. > > As for converting between bases, that could always be a separate > function like `$(convert-base number,radix)` where radix is one of: 2, > 8, 10, or 16
Re: math expressions (was: Re: Tail call elimination)
> I was not even considering specifying the base of the the resulting > expansion. I was assuming it would always be base 10. I don't have > any good way to specify the output form. > > I was only considering the parsing of input (constant) values: whether > we wanted to support 0xfff, 0o777, 0b111 as well as base 10. I don't > want to support "traditional" octal values that start with plain 0... I > believe that's always been a bad idea and it's especially bad in the > context of makefiles where values are all strings right up until the > moment they're parsed. I definitely agree with 0x 0o 0b. As for converting between bases, that could always be a separate function like `$(convert-base number,radix)` where radix is one of: 2, 8, 10, or 16
Re: math expressions (was: Re: Tail call elimination)
Question about 64-bit, what happens when compiling make for a 32-bit system? I don’t think c90 has `stdint.h`... maybe there’s something in gnulib. Anyway, would we want to support 64 bit integers even on 32-bit platforms?
Building Documentation
Does anyone have advice on how to build the web documentation? I tried running `make gendocs` but I get errors like: cvs -d :pserver:anonym...@cvs.sv.gnu.org:/web/www co 'www/server/standards' cvs [checkout aborted]: connect to cvs.sv.gnu.org(209.51.188.81):2401 failed: Connection refused
Re: math expressions (was: Re: Tail call elimination)
> I think, as I mentioned before, that someone (I guess that's you :)) > should write up an actual proposal (maybe, for example, the start of a > new manual section) that can be examined and commented on. Endless > streams of mailing list responses quickly give diminishing returns. My > experience is that it's much easier to come to conclusions when there > is a concrete plan to start from. Challenge accepted! What is the best form to choose... maybe creating a branch of the source and adding a new manual page there that anyone can render? > I do want to reiterate something I mentioned initially: any effort of > this size will require copyright assignment to the FSF / GNU project. > Please be sure you are OK with that. Getting that in motion earlier > will avoid delays at the end. Where can I find more information about this? And where do I do it? > We can always use evaluation so you could just implement the basics > first and get grouping via evaluation for free, then add explicit > grouping as a next step if you want. Yes incremental changes sound good. Would you recommend first trying to agree on a proposal and then attempt some implementation? Or to do these things together?
Re: math expressions (was: Re: Tail call elimination)
> I understand what Tim is saying but I still prefer to have a single > function. I want to reduce the "namespace leakage" for these > capabilities. If we decide to add more operations to this in the > future I don't want it colliding with something else we want to do. > > However, sometimes it's hard to see exactly how something will look > until we actually see it. Hm so does that imply that we're still on the fence? What can we do to resolve this? Take a poll? You're the benevolent dictator right Paul? :) > > I propose the following (a variation of example 2): > > > > $(math + 5 (/ (* (/ (* 2 9) (+ 7 5 4)) (* 1024 1024)) 19)) > > If we want to support grouping directly we're still requiring the > function to be recursive. If we use make expansion to provide grouping > the function doesn't need to be recursive (of course, we get recursion > implicitly because of make's expansion). By recursive do you mean the implementation of $(math) in the make source is recursive? I only prefer my suggestion because it removes a lot of dollar signs and `insert name of function here` repetition. It you need more convincing, one could argue that parsing it directly would likely lead to a more efficient implementation -- we would have the opportunity to implement this as an iterative process; either by loops or tail-call recursion. But I'll reiterate that my motivation is a more concise syntax.
Re: Tail call elimination
So we are back to debating between many functions or (one or two) functions. Anyone else care to weigh in?
Re: Tail call elimination
As for a name for $(cond), we could call it $(alu ...) And put arithmetic and logical operations in it :) I don’t like using $(cond) Because because I sort of want to option to implement cond like in Scheme.
Re: Tail call elimination
> 5 + (2 * 9 / (7 + 5 + 4)) * (1024 * 1024) / 19 > > becomes: > > $(math +, 5 $(math /, $(math *, $(math /, $(math *, 2 9) $(math +, 7 5 4)) > $(math *, 1024 1024)) 19)) > > versus: > > $(op + 5 $(op / $(op * $(op / $(op * 2 9) $(op + 7 5 4)) $(op * 1024 1024)) > 19)) > > or: > > $(+ 5 $(/ $(* $(/ $(* 2 9) $(+ 7 5 4)) $(* 1024 1024)) 19)) I propose the following (a variation of example 2): $(math + 5 (/ (* (/ (* 2 9) (+ 7 5 4)) (* 1024 1024)) 19)) This would involve doing our own parsing of the argument, however this should be trivial since we are using prefix notation. same with cond.
Re: Tail call elimination
Paul when you get a chance, could you let me know what you think about using many prefix functions?
Re: Tail call elimination
> Both a Lisp-like prefix syntax and a Forth/RPN-like postfix syntax are > concise and easy to implement. Infix semantics are messy, because they > require special "order of operations" logic to resolve ambiguities, and > there is no universal standard for that. Oh I completely agree. I think that the prefix syntax could take the most advantage of existing Make code and would be consistent with the existing Make function syntax.
Re: Tail call elimination
> No, I don't agree with that. Trying to change the base make parser > like that would be a major source of issues. Yeah that is what I surmised. > > > Grouping: do we try to implement expression grouping with () (e.g., > > > $(expr (1 + 1) * 4) or is it good enough to just say people need to > > > nest expr functions: $(expr $(expr 1 + 1) * 4)? > > > > I think nesting `expr` is too noisy. > > We need to find a good balance between implementation complexity and > "noisy use". of course > no one is going to be implementing MATLAB in a makefile. never say never :p > My point is, it's not necessary for this to have the most beautiful, > streamlined syntax because it will appear only in a few places, and in > relatively simple contexts. If it's easier to fall back on make's > existing expansion facilities than to implement grouping, we should > fall back. Yeah I am agreeable with the idea. But we could both get what we want with a more concise syntax with much less effort if we implement prefix operators. As you exampled: > This would mean: $(+ 5 $(* 7 2 3) 9) --> 56 > However, it does mean we have to implement a lot of little functions > (one for each operator) rather than one function that can do all the > things. > > Maybe that's still a good tradeoff. With any one familiar with LISP-like languages using prefix operations should feel natural. I also argue that anyone who has composed make functions already understands using prefix-style functions, so it shouldn't be too foreign, I am in favor or using many prefix functions.
Re: Tail call elimination
On Tue, May 19, 2020 at 11:13 AM Paul Smith wrote: > > No, I don't like this. Perhaps addition is sufficient for your use- > case but others may need multiplication or division and I certainly > don't want to start adding 10 different explicit funtions like "add", > "mult", etc. I prefer a single mathematical expression function. I concur with this. > Name: I'm using expr here just for convenience. Is there a better > name? Other than `expr`, maybe `math` or `arith`, but I think at least some people will be familiar with `expr`. Another option would be to introduce some new syntax like $(()), but that might break existing Makefiles and would probably be more work, though it looks cleaner IMO. > Whitespace: do we have to put whitespace around every operator, like > expr(1), or is the function smart enough to understand $(expr 1+1+4)? I think we should go for C-like parsing where the whitespace is insignificant. > Grouping: do we try to implement expression grouping with () (e.g., > $(expr (1 + 1) * 4) or is it good enough to just say people need to > nest expr functions: $(expr $(expr 1 + 1) * 4)? I think nesting `expr` is too noisy. > Precedence: do we try to implement standard mathematical precedence > (multiplication/division before addition/subtraction) or do we just > evaluate left to right and require explicit grouping? It would > definitely be a source of ongoing user confusion to not follow normal > precedence rules, but supporting it would make the implementation more > complex. We should definitely implement the proper precedence. Follow the rules for c? https://en.cppreference.com/w/c/language/operator_precedence I took a programming languages class at University and my professor wrote all of the material for it. Specifically, notes on implementing recursive-descent parsers (hereinafter "RDP") for an interpreted language (which I believe is the type of parsing Make uses). I plan on using this page http://beastie.cs.ua.edu/proglan/expgram.html as a reference for how to accomplish left associativity and the correct presence in a RDP. > Increment/decrement: do we try to implement += / -= and/or ++ --? It > would be something like the symbol on the left would be interpreted as > a variable name, so $(expr foo += 5) would add 5 to the variable foo > (and expand to the new value of $(foo)). If we support ++/-- do we > support both pre- and post- operators? This isn't needed in places > where you can just say "foo = $(expr $(foo) + 5)", but allowing > assignment within an expression could be very helpful. It could be > done anyway with: $(eval foo := $(expr $(foo) + 5))$(foo) ... is it > worthwhile to add syntactic sugar for this? yes assignments as expressions is valuable to make things more readable I think. > If we support increment/decrement do we go farther and support variable > interpolation a la shell $((...)), where a symbol is assumed to be the > value of the variable (that is, $(expr foo + 10) is equivalent to > $(expr $(foo) + 10)? I wouldn't bother implementing this by itself but > it becomes a question if increment/decrement needs it anyway. I don't have a preference on this. Allowing the behavior of $(()) is useful for cutting down on any noisy/messy/extraneous symbols in the argument to $(expr)
Re: math expressions (was: Re: Tail call elimination)
> If anyone can provide any use case where >64bit math is needed in a > makefile I'll be interested to hear about it. Yeah fair enough :) Then we can always build in support since the size addition to the Make binary will be trivially changed. > > * negate > > * absolute value > > * exponentiate > > Maybe. My argument for these is that they are pretty easy to implement. > > Bit Manipulation: > > -- > > * and > > * or > > * xor > > * complement > > * left shift > > * right shift > > Maybe. I have a hard time coming up with uses for these, other than > possibly the shift operators (but multiplication/division can be used > instead). Yeah I was thinking the use case could be a little obscure, but maybe for some sort of version parsing where bits are strangely encoded. But again I'd say that it's pretty easy to implement. > Again, the questions in my email yesterday need to be addressed. I totally missed that email somehow. I'll address it in another email. > Mult-base support: should we support only base 10 integer constants in > expressions, or also hex/octal constants? I vote for decimal, hex, and binary. Octal if you really want it.
Re: Tail call elimination
> - major added dependency (Make needs to be widely portable, and it is > often part of a boot-strapping procedure. The core functionality needs to > be trim. Heavy lifting needs to be separable.) The shared library for libgmp does not have dependencies on anything besides libc, so libgmp only adds one direct dependency and no indirect dependencies. If so desired, like with Guile integration, we could relegate $(expr) as a compile-time option. GMP also compiles for windows. > - slow (native int32 is much faster) I think the performance concern is misplaced. Compared to the time required to do all of the interpreting and string parsing that we already have to do, I doubt that there would be any appreciable performance benefit to using native types. Especially given the very likely usage of $(expr), which is some calculations before processing the targets, which is what really takes significant time. > - massive YAGNI (Make is a build system, not a general-purpose computing > platform) I argue that it already became very much more general purpose when $(call) was added. Earlier email threads have suggested uses for this added function.
Re: Tail call elimination
I really like the idea of using GMP to do the math. Does it make sense to restrict ourselves to integer only? Probably, but just a thought. Could always introduce it later. Yes there is the question of use case and YAGNI, but there's also the case of why artificially restrict the abilities of $(expr). Assuming we at least do GMP with integers, I want to know the operators that we should support. I propose: Arithmetic Functions: --- * add * subtract * multiply * divide * negate * absolute value * exponentiate Bit Manipulation: -- * and * or * xor * complement * left shift * right shift Comparison Functions: -- * > * >= * < * <= * == If this looks ok then I can proceed with making a proposal document. I can format it to resemble a Make documentation page.
Re: string comparison operators (was: Re: Tail call elimination)
I concur that string handling and comparison should be considered in a separate discussion. So let’s consider just integer comparison and arithmetic here?
Re: Tail call elimination
Also, I think an advantage of an $(expr) command is that we can have it return an empty string on false, whereas with shell we have to transform the output conditionally based on whether we are performing arithmetic or comparison...
Re: Tail call elimination
Speaking of > return value of a call to $(shell) is available in $(.SHELLSTATUS). I think it would be a nice addition to have some global setting where any failed $(shell ) command automatically fails Make.
Re: Tail call elimination
> Each of these has an obvious 'output', which is not the case for > something like a comparison operator. This is also an objection > against $(eq) and $(not), which are hidden behind the EXPERIMENTAL > compilation flag. I think the convection is that an empty string is false while a non-empty string is true. > Otherwise, POSIX prescribes an expr command, so with: > expr = $(shell expr '$1') > you can already do $(call expr,2 * 3 + 5). Ooh I didn't know about that. That seems like a good alternative.
Re: Tail call elimination
Yes
Re: Tail call elimination
Yeah I was thinking something like: VERSION := 1.3.0 OLD_VERSION := 1.2.0 EMPTY := SPACE := $(EMPTY) $(EMPTY) ver_is_less_than = $(strip \ $(let \ ( \ (major1 $(word 1,$(subst .,$(SPACE),$1))) \ (minor1 $(word 2, ...)) ... \ ) \ $(if $(expr $(major1) <= $(major2) \ 1, \ $(if $(expr $(minor1) < $(minor2) ...)) ifneq ($(call ver_is_less,$(VERSION),$(OLD_VERSION)),) ... endif
Re: Tail call elimination
> It should not be necessary for the use-cases of make I assert that arithmetic functionality does have use-cases in Make. Beyond building, I use Make for packaging my software and running tests. I often find that it would be useful to perform version comparisons and other simple packaging things. I sometimes get into scenarios in more complex Makefiles where I want to perform sanity checks on versions that users pass in via environmental variables and the like.
Re: Mailing List Conventions
Any suggestions? On Wed, May 13, 2020 at 4:05 PM Pete Dietl wrote: > I am new to using mailing lists in general and I want to use it properly. > Is there is a document somewhere that explains the conventions of using it. > Like how conversations are grouped together and what context I should > provide when replying to someone? > > Other questions: > * What is the convention for quoting other people? > * Is there a convention for using HTML vs plaintext? > * Do you always reply to the person replying to you and to the entire > mailing list? > > I apologize if this is common knowledge for most. :p > I know that common mail clients do magic grouping and hiding for you. >
Mailing List Conventions
I am new to using mailing lists in general and I want to use it properly. Is there is a document somewhere that explains the conventions of using it. Like how conversations are grouped together and what context I should provide when replying to someone? Other questions: * What is the convention for quoting other people? * Is there a convention for using HTML vs plaintext? * Do you always reply to the person replying to you and to the entire mailing list? I apologize if this is common knowledge for most. :p I know that common mail clients do magic grouping and hiding for you.
Re: Tail call elimination
And I swear that's the last thing I want. :)
Re: Tail call elimination
Indeed I understand these concerns. So the consensus seems to be that I may go ahead and attempt to implement this. Other than the (let) and tail call optimization, I would like to know your thoughts about adding something like $(expr ) to evaluate integer expressions and comparisons.
Tail call elimination
What do you all think about me attempting to implementing tail call elimination for recursive make functions? This combined with the proposed (let) construct would be rather powerful. I did the first 10 exercises in Advent of Code 2019 in Make. but ran into problems with blowing the stack from recursion.
Let construct
Hey there. I just wanted to touch base about the status of the proposal of a (let) construct. I think it’ll be a very useful feature and want to see it make progress. :) I’m willing to help with it if need be.
Getting started with contributions
Does anyone have any suggestions for bugs to work on or fix? I want to get started contributing if I can. Once I pick something, how are changes proposed? Via patch sets?
