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.
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?
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 rec
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.
And I swear that's the last thing I want. :)
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 fo
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
> 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.
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
Yes
> 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 st
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.
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...
I concur that string handling and comparison should be considered in a
separate discussion.
So let’s consider just integer comparison and arithmetic here?
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 $(exp
> - 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 a
> 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
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 singl
> 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
>
> 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 tha
Paul when you get a chance, could you let me know what you think about
using many prefix functions?
> 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 $(
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.
So we are back to debating between many functions or (one or two)
functions. Anyone else care to weigh in?
> 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
> 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
> experienc
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
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?
> 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, 0b1
`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
> 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.
> 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
>
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 th
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, signe
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 o
I'm afraid that that help wanted list is severely defunct.
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"
ck (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 f
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 fo
s 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 th
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
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
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
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
A very good point!
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'
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 a
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
ested.
>
> 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,
>>&
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 suc
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
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
you all think.
>From 76db129404896c15440b405949b8c830e7ebb98f Mon Sep 17 00:00:00 2001
From: Pete Dietl
Date: Fri, 29 Nov 2024 03:57:06 -0800
Subject: [PATCH] Add arithmetic builtin functions
---
src/function.c | 401 -
1 file changed,
version of C that I may rely
on? The use of "_Generic" is a C11 thing. I can remove it if we want
to rely only on C99.
Should I write some unit or integration tests?
On Fri, Nov 29, 2024 at 7:34 AM Gisle Vanem wrote:
>
> Pete Dietl wrote:
>
> > Here I submit to you a pa
In commit `1dfd55ca`, the added comment in `maintMakefile` reads:
> # Also force comments to be preserved. This helps when using ccache, in
> # combination with GCC 7's implicit-fallthrough warning.
I am curious how this helps ccache. I tried running GCC with and without
the flags and it seems t
contribution this size we'll need copyright paperwork to be
> signed; let me know if you need my help with getting that started.
>
>
> On Fri, 2024-11-29 at 04:14 -0800, Pete Dietl wrote:
> > From 76db129404896c15440b405949b8c830e7ebb98f Mon Sep 17 00:00:00
> > 2001
> > F
Jouke,
Wed, 20 May 2020 13:42:11 -0400, Paul Smith wrote:
> > 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.
> No, I don't agree with that. Trying to change the base ma
@:
Variable names and their values are provided pairwise. "Letrec" strips
any leading whitespace from the expansion of each variable name
argument.
Here is a patch implementing the functionality:
>From 57727f01bbb88e57b13eaed7d4693f8c18a8aa58 Mon Sep 17 00:00:00 2001
From: Pete Dietl
Da
>From 4a6e84061fbf2180cf4efec45a215dd8af6481b1 Mon Sep 17 00:00:00 2001
From: Pete Dietl
Date: Mon, 9 Dec 2024 17:06:55 -0800
Subject: [PATCH] arith_tests
---
configure.ac| 34 ++
tests/config-flags.pm.in| 24 +++--
tests/scripts/functions
* Poke *
On Mon, Dec 9, 2024, 5:18 PM Pete Dietl wrote:
> I could also use some help with autotools and the Perl test scripts <
> I am a novice at both :) >
>
> Here is a bit of test code I came up with. Do you think this is
> necessary and or the right approach for testin
Jouke,
You need a recursive let if you want to be able to define inner functions,
like a helper function.
On Mon, Dec 30, 2024, 5:21 AM Jouke Witteveen wrote:
> Hi Pete,
>
> On Thu, Dec 26, 2024 at 7:44 AM Pete Dietl wrote:
> > I propose adding a "letrec" built
61 matches
Mail list logo
