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
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
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
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,
>>&
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
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
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'
A very good point!
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
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
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
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
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
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
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
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"
I'm afraid that that help wanted list is severely defunct.
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
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
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
> 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
>
> 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.
`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 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
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?
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
> 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
> 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
So we are back to debating between many functions or (one or two)
functions. Anyone else care to weigh in?
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.
> 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 $(
Paul when you get a chance, could you let me know what you think about
using many prefix functions?
> 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
> 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
>
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
> 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
> - 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
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
I concur that string handling and comparison should be considered in a
separate discussion.
So let’s consider just integer comparison and arithmetic here?
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...
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.
> 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
Yes
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
> 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.
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 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
And I swear that's the last thing I want. :)
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.
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
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?
52 matches
Mail list logo
