Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On Friday, 18 August 2023 at 15:44:21 UTC+1, David Brown wrote:\>
>>But if you wanted Python as a scripting language in your
>> PC application, you'd have Python DLL's (and probably not bother
>> compiling them yourself at all), whereas Lua is small enough that you
>> might choose to build it directly with your application instead.
>>
>Exactly. Weight matters. Lua is embeddable as scripting language whilst
>Python is not.

I might argue that a bit. We have a mode in our product that supports
python as a scripting language. Our product is built as a shared object
and can be linked into python at runtime using the python C++ shim provided
by the swig package. Or it can be linked with a small interpreter of our
own.

https://www.swig.org/tutorial.html

There are some performance implications, because python isn't very
thread friendly, but it generally works. We use it as a unit test
framework.

On 18/08/2023 17:21, Malcolm McLean wrote:
> On Friday, 18 August 2023 at 15:44:21 UTC+1, David Brown wrote:\>
>> But if you wanted Python as a scripting language in your
>> PC application, you'd have Python DLL's (and probably not bother
>> compiling them yourself at all), whereas Lua is small enough that you
>> might choose to build it directly with your application instead.
>>
> Exactly. Weight matters. Lua is embeddable as scripting language whilst
> Python is not.

Python is regularly used as an embedded scripting language. But the
implementation of the embedded is normally done by DLL's or other
separately compiled dynamic libraries or executables. To the user of
the main application, however, it is an embedded scripting language.

>>
>> It's the same with speed. Unless you are competing in some benchmark
>> competition, then speed is not helpful as an overriding concern. If
>> something is fast enough, it is fast enough - faster will then not be
>> better
>>
> it's very important for us because we write interactive tools to deal with
> vector artwork. The more artwork the artists can throw at us whilst
> keeping the tool smooth and responsive, the more they will use it.

Execution speed is still not your only overriding concern. I believe
you are working in the games industry. If it is nearing Christmas, and
you tell your boss "give me two more months and I can get another 2%
faster", the answer will be "no". There are /always/ balances.

But gaming is an area where speed is definitely very important.

On Friday, 18 August 2023 at 16:11:35 UTC+1, David Brown wrote:
> On 18/08/2023 16:48, bart c wrote:
> > On Friday, 18 August 2023 at 14:33:08 UTC+1, David Brown wrote:
> >> On 17/08/2023 18:16, Bart wrote:
>
> >>> This is an analogy I have used before regarding LLVM, which is a backend
> >>> for language implementations. It is quite large and complex.
> >>>
> >>> Once I needed a side-gate for my house. I made it myself, and ended up
> >>> with a 6' high wooden gate, of just the right size.
> >>>
> >>> Now if I'd gone to the LLVM shop as a solution, the gate would have been
> >>> 9 miles high - if I could ever figure it out.
> >>>
> >> As analogies go, that's a particularly silly one.
> >
> > LLVM in concept is simple: feed it some IL (or it calls it IR), and it turns it into a runnable binary. The actuality is very different.
> >
> > I created my own similar product in 2021, which was a 0.2MB binary. The downloads needs to get started with LLVM are some 2.3GB. That's how you get from 6 feet to 9 miles. But the biggest obstacle is the sheer complexity, with 100 /sets/ of documentation.
> >
> Doesn't the quantity of documentation in llvm give you a hint that
> perhaps your product is /not/ similar?

The point of using LLVM is similar to that of targetting C:

* You don't want the bother of writing the backend of a compiler

* You want portability by not generating different code for x64/arm, Linux/Windows etc

* You want to take advantage of optimisation

You don't however need that amount of documentation to use C; so C is far simpler.

An IL would be a much simpler language than C.

For the IL I use (based on a stack-based VM), a portable interpreter can be written in 0.1MB. A program to turn it into native code would be 0.2MB per target.

The task is just not complex. Unless you want code that is optimised, but it might be a magnitude bigger task to get it good enough; it won't be several magnitudes bigger.

On Friday, 18 August 2023 at 15:44:21 UTC+1, David Brown wrote:
> On 17/08/2023 20:51, Bart wrote:

> > I'm working on something like that right now. A much smaller, more
> > dynamic, more easily embeddable version of my current scripting language.
> >
> > Totally futile of course. But it is my choice. Making things small,
> > compact, simple and fast isn't that easy.
> >
> The futility or not depends on your aims, what you try to do with it,
> and how you market it.
>
> If you make a simple little language then go to the Lua forums and tell
> everyone how crap and bloated Lua is, then your effort is futile.
>
> If you make a decent little language with documentation, examples and
> information, gather users and feedback (and listen to that feedback),
> and build it as a community and a new alternative as an embeddable
> scripting language with enthusiasts using it, maintaining it, improving
> it, and supporting it, then that would be fantastic. I'd be happy to
> consider it for my own use - and certainly happy for your achievement.

No one would be interested in any scripting language I created.

Modern scripting languages bristle with advanced features and disregard fundamental ones, while mine are the opposite.

As for Lua, while the EXE is the same size as my Q interpreter, the latter has more capability of the kind I find useful (eg. built-in FFI, bignums, record types, bit arrays, but this is not the place to go into it).

>
I know you are capable of taking the second path here. I worry, based
> on years of Usenet posting, that you will take the first path.
>
> There is a third option - you do this just as a hobby for your own
> interests and enjoyment, and understand its limitations, and that's
> great too.

Q can give Python a run for its money too in features and in speed. However this is not a conventional project since I'm responsible for 100% of the language, of the implementation, of the implementation language, /its/ implementation, of the ultra-simple and near-instant build process it uses.

It's quite an achievement ...

> It's only futile when you build yourself a tree-house and tell people
> it's better than the Empire State Building, and that you are fighting
> against bloated and inefficient houses.

.... but I'm not allowed to boast about it because people like you will always cut me down to size.

Because something that's big complex, successful, used by lots of people and that requires labyrinthine makefiles to build *must* be better. Even when it lacks fundamental features and is slow.

That's like saying I can't cook myself a decent meal in my own kitchen; it can't possibly be as good as something mass-produced in a factory with industrial-scale machinery and consumed by a million people.

I guess it I was to produce a tool that took the C sources of CPython and produced a working set of .exe/.dll files in one second, using a 10-line script, that wouldn't cut any ice either. You will be constantly looking at ways to belittle it. Because it can't be /that/ simple to build software, it just can't, dammit!

(I don't have such a tool and have no plans for one. I can't remember if I tried bcc on CPython, but there were likely insurmountable obstacles before you could get anywhere near compiling a .c file. I can't really cook either.)

On 8/18/2023 5:55 AM, David Brown wrote:
> On 18/08/2023 04:13, Keith Thompson wrote:
>> bart c <bart4858@gmail.com> writes:
>>> On Friday, 18 August 2023 at 01:47:11 UTC+1, Keith Thompson wrote:
>> [...]
>>>> [...]
>>>>> Answer honestly: if 'make' had required an explicit filename from the
>>>>> start (probably it wouldn't have needed '-f'), would anyone have cared
>>>>> about having to type it?
>>>> Having to type it? No. Having to figure out what arbitrary name the
>>>> author chose? Yes.
>>>
>>> Yeah. Figuring out what the executable is called in order to run it
>>> afterwards must be a problem too.
>>
>> Executables have to have unique names.  Makefiles don't.
>>
>> [...]
>>
>>> Honestly these are ridiculous excuses.The quibble you have is that
>>> when you type the name of a program that has a big and important task
>>> to do, and usually do that just once, that you have to tell it the
>>> name of a file?
>>
>> I'm not making excuses.  I'm offering explanations.
>>
>> Those of us who actually use, and sometimes create, Makefiles rarely
>> have any reason to name them something other than "Makefile".  Do you
>> not understand that?  Do you think we're all lying about it?  Why would
>> we bother?
>>
>> The make command already has an option to use a name other than than
>> "Makefile".  You apparently advocate making it mandatory, which would
>> require uncounted users to alter the way they work.  What exactly would
>> be the advantage of that?
>
> Note that it is very simple to make it mandatory for any given project
> (or jumble of projects thrown together in one directory) - simply do not
> have a makefile called "makefile" (or "Makefile"), and have a selection
> of different ".mk" files instead.  So if Bart wants that, "make" already
> supports it.
>
>>
>> Do you want to put files for all your projects in a single directory,
>> with a distinct makefile for each?  You can do that.
>>
>>> However do you manage to run even a text editor?
>>
>> Be serious.
>>
>

Have you ever forgot to use a tab in a makefile?

On 8/18/2023 2:34 PM, Chris M. Thomasson wrote:
> On 8/18/2023 5:55 AM, David Brown wrote:
>> On 18/08/2023 04:13, Keith Thompson wrote:
>>> bart c <bart4858@gmail.com> writes:
>>>> On Friday, 18 August 2023 at 01:47:11 UTC+1, Keith Thompson wrote:
>>> [...]
>>>>> [...]
>>>>>> Answer honestly: if 'make' had required an explicit filename from the
>>>>>> start (probably it wouldn't have needed '-f'), would anyone have
>>>>>> cared
>>>>>> about having to type it?
>>>>> Having to type it? No. Having to figure out what arbitrary name the
>>>>> author chose? Yes.
>>>>
>>>> Yeah. Figuring out what the executable is called in order to run it
>>>> afterwards must be a problem too.
>>>
>>> Executables have to have unique names.  Makefiles don't.
>>>
>>> [...]
>>>
>>>> Honestly these are ridiculous excuses.The quibble you have is that
>>>> when you type the name of a program that has a big and important task
>>>> to do, and usually do that just once, that you have to tell it the
>>>> name of a file?
>>>
>>> I'm not making excuses.  I'm offering explanations.
>>>
>>> Those of us who actually use, and sometimes create, Makefiles rarely
>>> have any reason to name them something other than "Makefile".  Do you
>>> not understand that?  Do you think we're all lying about it?  Why would
>>> we bother?
>>>
>>> The make command already has an option to use a name other than than
>>> "Makefile".  You apparently advocate making it mandatory, which would
>>> require uncounted users to alter the way they work.  What exactly would
>>> be the advantage of that?
>>
>> Note that it is very simple to make it mandatory for any given project
>> (or jumble of projects thrown together in one directory) - simply do
>> not have a makefile called "makefile" (or "Makefile"), and have a
>> selection of different ".mk" files instead.  So if Bart wants that,
>> "make" already supports it.
>>
>>>
>>> Do you want to put files for all your projects in a single directory,
>>> with a distinct makefile for each?  You can do that.
>>>
>>>> However do you manage to run even a text editor?
>>>
>>> Be serious.
>>>
>>
>
> Have you ever forgot to use a tab in a makefile?

I remember many years ago, where I forgot to use a tab in a makefile and
the damn thing would not work.

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
[...]
> Have you ever forgot to use a tab in a makefile?

Yes, I have. I quickly found and corrected the error.

As I recall, the original author of make acknowledged requiring tab
characters was a mistake. It's hardly a fatal flaw.

If you're using GNU make, you can use something like ".RECIPEPREFIX = >"
to avoid the problem.

I'm curious just what point you're trying to make.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 8/18/2023 3:19 PM, Keith Thompson wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> [...]
>> Have you ever forgot to use a tab in a makefile?
>
> Yes, I have. I quickly found and corrected the error.
>
> As I recall, the original author of make acknowledged requiring tab
> characters was a mistake. It's hardly a fatal flaw.
>
> If you're using GNU make, you can use something like ".RECIPEPREFIX = >"
> to avoid the problem.
>
> I'm curious just what point you're trying to make.
>

My point is: Been there done that. I learned from my mistake, and make
is fine with me. Fair enough?

On 8/13/2023 7:44 PM, Kenny McCormack wrote:
> In article <8fb22829-9b5e-4108-a513-df3b72391405n@googlegroups.com>,
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> ...
>>> DOS/Windows (and Mac similarly) has *never* shipped with any sort of
>>> development environment, so arguing that it doesn't have "make" is kind of
>>> pointless.
>
> I may actually have mis-spoken here. DOS did originally come with GWBASIC,
> so you could, at least write and run programs back then.
>
> Whether BASIC (of any stripe) counts as a development environment is, of
> course, open to debate...
>
> Does modern Windows come with VB.NET ready-to-go, or do you have to
> download it?
>

Download MSVC Express; get it working; then make sure to download:

https://vcpkg.io

Not that terribly "bad", so to speak.

A fairly decent number of libs to choose from. They will be compiled,
so, they do not all install in the blink of an eye, so to speak.

The integrate into MSVC. Iirc, they even work over on Linux via:

https://code.visualstudio.com/docs/setup/linux

On 8/18/2023 8:58 AM, bart c wrote:
> On Friday, 18 August 2023 at 16:11:35 UTC+1, David Brown wrote:
>> On 18/08/2023 16:48, bart c wrote:
>>> On Friday, 18 August 2023 at 14:33:08 UTC+1, David Brown wrote:
>>>> On 17/08/2023 18:16, Bart wrote:
>>
>>>>> This is an analogy I have used before regarding LLVM, which is a backend
>>>>> for language implementations. It is quite large and complex.
>>>>>
>>>>> Once I needed a side-gate for my house. I made it myself, and ended up
>>>>> with a 6' high wooden gate, of just the right size.
>>>>>
>>>>> Now if I'd gone to the LLVM shop as a solution, the gate would have been
>>>>> 9 miles high - if I could ever figure it out.
>>>>>
>>>> As analogies go, that's a particularly silly one.
>>>
>>> LLVM in concept is simple: feed it some IL (or it calls it IR), and it turns it into a runnable binary. The actuality is very different.
>>>
>>> I created my own similar product in 2021, which was a 0.2MB binary. The downloads needs to get started with LLVM are some 2.3GB. That's how you get from 6 feet to 9 miles. But the biggest obstacle is the sheer complexity, with 100 /sets/ of documentation.
>>>
>> Doesn't the quantity of documentation in llvm give you a hint that
>> perhaps your product is /not/ similar?
>
> The point of using LLVM is similar to that of targetting C:
>
> * You don't want the bother of writing the backend of a compiler
>
> * You want portability by not generating different code for x64/arm, Linux/Windows etc
>
> * You want to take advantage of optimisation
>
> You don't however need that amount of documentation to use C; so C is far simpler.
>
> An IL would be a much simpler language than C.
>
> For the IL I use (based on a stack-based VM), a portable interpreter can be written in 0.1MB. A program to turn it into native code would be 0.2MB per target.
>
> The task is just not complex. Unless you want code that is optimised, but it might be a magnitude bigger task to get it good enough; it won't be several magnitudes bigger.
>
>

Fwiw, remember when you told me that my experimental C cipher code did
not compile in Tiny C. Then, we worked together and it did end up
compiling? Remember that thread?

Bart <bc@freeuk.com> writes:

> On 17/08/2023 21:26, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 17/08/2023 02:56, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>
>>>>> I just say it like it is.
>>>>
>>>> You say it like you see it (as do I). To consider that as "like it is"
>>>> takes more self confidence than I can muster.
>>>
>>> Make seems to mostly use a local file called 'makefile' for its primary
>>> data. Certainly that's what it will use if no alternate is provided.
>>>
>>> That's like 'it is'.
>>
>> But, as you know perfectly well, that is not the remark you were
>> claiming to have stated as it is. The claim -- to be just saying it as
>> it is -- was in relation to quite a rude remark about me (and others).
>>
>
> You said this:
>
>> oh dear, I typed the above before reading this, but I'll post the
>> explanation anyway...
>
> I called that a snide remark. Is that what you mean by 'rude'?

No. (And why is that snide? You had made a sarcastic remark that
seemed to render my effort in explaining my position redundant. I was
just remarking that I would not have posted if I'd seen your sarcasm
first.)

Anyway, can you not go up the thread and see what it was you were saying
"as it is"? It was this:

| Yes, some of these programs do look like the early efforts of a beginning
| programmer. Decades later, people (even you) try to rationalise their
| behaviour.
| | I just say it like it is.

People (me included) are not trying to rationalising something that
looks like the efforts of a beginner. It's dismissive, to the point of
rudeness, to claim that people you disagree with were merely doing that.
I wouldn't post at all if you were always likely to consider my remarks
as nothing but rationalising basic errors.

> I take it you don't have a personal opinion about 'make'? You would have
> written it in the same way? But you'd rather write ad hominem remarks
> instead.

Again with the spin! Where does this impulse to attack imagined
positions that no one has taken come from? (I've asked before if you
have some background in politics, but you never say one way or the
other.) To be clear: (a) I do have a personal opinion about make, but I
don't think anyone would be interested in it. (b) I would not have
written it in the same way. (c) If you object to anything personal I've
said I will gladly apologise. You and I see programming like chalk and
cheese but I don't want to get personal about it.

> You have a habit of dissecting and analysing every chance turn of phrase I
> use. That seems to be more important to you, being able to attack me, than
> the presumably less interesting topic of where 'make' takes its input from
> and whether that was a good way or bad.

I explained my position on that quite calmly until I read your sarcastic
mocking of the design. That's not technical criticism, that's just PR
spin. And even then, all I said is that I would have replied had I seen
the sarcasm first.

--
Ben.

bart c <bart4858@gmail.com> writes:

> On Friday, 18 August 2023 at 02:49:38 UTC+1, Kaz Kylheku wrote:
>> On 2023-08-17, Bart <b...@freeuk.com> wrote:
>> > Answer honestly: if 'make' had required an explicit filename from the
>> > start (probably it wouldn't have needed '-f'), would anyone have cared
>> > about having to type it?
>> Yes. You.
>
> So, nobody who actually uses it.

You can't infer that from the one answer.

> Yet the way it does work is absolutely indispensible and could not
> possibly be done any other way

Again, no one has said anything approaching that ridiculous straw man.

> (like every other C misfeature).

"Other"? Make's use of a default file is not a C feature.

> That is, you want to be able to type:
>
> X
>
> and not:
>
> X Y

No, I want to type

make
make tests
make install
make clean
make mylib.a

depending on what I'm doing rather than

make makefile
make makefile tests
make makefile install
make makefile clean
make makefile mylib.a

What's more, tab completion in my shell works with make's targets, but I
don't think that's at all easy to do if the makefile has to be named in
the same command.

> like nearly every other command line program.

> Yet being able to do
>
> X Y
>
> instead of:
>
> X Y.Z
>
> on those other programs is anathema.

Well (if you are talking about having to say gcc prog.c rather than gcc
prog) there are advantages, and none of them have anything to do with
how much one has to type. After all, command completion means I rarely
type a file name explcitly anyway.

The main advantage is that there's no need to specify and remember all
the rules. Does gcc always add .c? Will it add .c if I type gcc
prog.s? Must I avoid any dots in the basename? What happens when
several names appear on the command line?

> So either 'X Y' is too much to type, or `X Y' is not enough! Even
> though you will be using the latter case more often.

No. I don't think anyone cares about how much one types (I don't)
provided there is some point to it. It's annoying to be forced to type
something redundant every time, whereas it's potentially confusing to
have gcc pick default extensions.

> It's fascinating watching psychology and group-think at work.

As usual, you've invented a position (it'a all about the typing) and
argued about that instead of taking on board the actualt comments that
people have made.

--
Ben.

On Saturday, 19 August 2023 at 01:21:58 UTC+1, Ben Bacarisse wrote:
> bart c <bart...@gmail.com> writes:

> > That is, you want to be able to type:
> >
> > X
> >
> > and not:
> >
> > X Y
> No, I want to type
>
> make
> make tests
> make install
> make clean
> make mylib.a

I'm not familiar with how make is used. Do you routinely have to invoke it five times in succession? Maybe that's a deeper problem with it, but as I said I don't use it.
> depending on what I'm doing rather than
>
> make makefile
> make makefile tests
> make makefile install
> make makefile clean
> make makefile mylib.a

And this actually tells me that the main input is identical in all cases; I'd been wondering what was being done with mylib.a. But whatever it is, the same makefile that does all the other stuff contains some formula for 'mylib.a'?

In practice I doubt you would type this five times as normally you'd do line recall then change the last bit. You can also choose to give it a shorter name than 'makefile'!

> What's more, tab completion in my shell works with make's targets, but I
> don't think that's at all easy to do if the makefile has to be named in
> the same command.
> > like nearly every other command line program.
>
> > Yet being able to do
> >
> > X Y
> >
> > instead of:
> >
> > X Y.Z
> >
> > on those other programs is anathema.
> Well (if you are talking about having to say gcc prog.c rather than gcc
> prog) there are advantages, and none of them have anything to do with
> how much one has to type. After all, command completion means I rarely
> type a file name explcitly anyway.

If my C test folder, I had 23 files that started with 'hello'. Although they are stepped through in alphabetical order on Windows and .c is near the top, you still have to tentatively keep pressing tab, then you go too far and need shift-tab .. it is quicker just to type the extension! Better however not to have to bother.

> The main advantage is that there's no need to specify and remember all
> the rules. Does gcc always add .c? Will it add .c if I type gcc
> prog.s? Must I avoid any dots in the basename? What happens when
> several names appear on the command line?

gcc is a bad example to follow since it does too much on the command line and performs multiple functions. So it easy to argue that, because it handles 58 different file types (I've no idea), singling one out to use a default is senseless.

But with a simpler product whose primary input files are C source files, then a default .c extension makes a lot of sense.

The rules on Windows can be simple: if there is no extension (no dot in the name), then a default extension is added. It's harder with a Linux file system because files "abc" and "abc." are distinct; how to do apply a default extension to "abc" when that could be a valid filename?

However on Windows and various other OSes before that over decades, it hasn't really given any problems.

> > So either 'X Y' is too much to type, or `X Y' is not enough! Even
> > though you will be using the latter case more often.
> No. I don't think anyone cares about how much one types (I don't)
> provided there is some point to it. It's annoying to be forced to type
> something redundant every time, whereas it's potentially confusing to
> have gcc pick default extensions.

Exactly. I consider the '.c -oprog' in 'gcc prog.c -oprog' to be redundant. Note that on Windows, it will apply the .exe extension to that output.

> > It's fascinating watching psychology and group-think at work.
> As usual, you've invented a position (it'a all about the typing) and
> argued about that instead of taking on board the actual comments that
> people have made.

The typing is part of it. Using the same default file in this case seem to me to be fragile. Remember the Github Lua with the missing makefile? I didn't know there were supposed to be two, and assume that one called 'makefile' was /the/ makefile. Or someone could simply be in the wrong folder.

On 18/08/2023 23:34, Chris M. Thomasson wrote:

>
> Have you ever forgot to use a tab in a makefile?

I don't think so, because I use tabs generally for spacing. (Some
people prefer spaces, others tabs.) But I /have/ had an editor convert
tabs to spaces, or spaces to tabs, on saving a makefile - and that
really does screw things up.

I doubt if there is anyone that considers the distinction between tabs
and spaces in makefiles to be a good idea. That includes the original
author of make.

scott@slp53.sl.home (Scott Lurndal) writes:
> Michael S <already5chosen@yahoo.com> writes:
>>On Wednesday, August 16, 2023 at 1:52:46=E2=80=AFPM UTC+3, David Brown wrot=
>>e:
>>> Certainly embedding it within other applications is a major purpose of=20
>>> the language, yes. It is becoming more mature as a stand-alone=20
>>> language, with more libraries, but it is very popular for adding to=20
>>> other programs. As you say, Lua is a common choice for scripting in=20
>>> games. I used it myself as a scripting language in an embedded program,=
>>=20
>>> many moons ago.
>>
>>Did it work?
>>I mean, not an easy technical part of embedding an interpreter.
>>Did the "human" part work? Did people that were supposed to write
>>scripts bothered to learn the language and to start writing?
>
> We also have some stand-alone[*] software that runs on our CPUs
> that uses an embedded lua interpreter. Users have had no problems
> with it at all.
>
> [*] in this context, bare-metal sans OS.

The crypto subsystems on a bunch of ARM SoCs from multiple vendors (TI &
Freescale at least) are written in Lua too, and have been for well over
a decade.

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

On Saturday, 19 August 2023 at 12:22:42 UTC+1, Phil Carmody wrote:
> sc...@slp53.sl.home (Scott Lurndal) writes:
> > Michael S <already...@yahoo.com> writes:
> >>On Wednesday, August 16, 2023 at 1:52:46=E2=80=AFPM UTC+3, David Brown wrot=
> >>e:
> >>> Certainly embedding it within other applications is a major purpose of=20
> >>> the language, yes. It is becoming more mature as a stand-alone=20
> >>> language, with more libraries, but it is very popular for adding to=20
> >>> other programs. As you say, Lua is a common choice for scripting in=20
> >>> games. I used it myself as a scripting language in an embedded program,=
> >>=20
> >>> many moons ago.
> >>
> >>Did it work?
> >>I mean, not an easy technical part of embedding an interpreter.
> >>Did the "human" part work? Did people that were supposed to write
> >>scripts bothered to learn the language and to start writing?
> >
> > We also have some stand-alone[*] software that runs on our CPUs
> > that uses an embedded lua interpreter. Users have had no problems
> > with it at all.
> >
> > [*] in this context, bare-metal sans OS.
>
> The crypto subsystems on a bunch of ARM SoCs from multiple vendors (TI &
> Freescale at least) are written in Lua too, and have been for well over
> a decade.

That's interesting. One of the limitations of Lua was that it didn't have proper integer type, it used a 64-bit float.

Integer values could only be represented exactly up to 2**52 or so. However recent versions of Lua (not LuaJIT) have acquired a proper 64-bit integer type; presumably it was needed. That was well within the last decade.

(LuaJIT does not have it.)

On 19/08/2023 03:36, bart c wrote:
> On Saturday, 19 August 2023 at 01:21:58 UTC+1, Ben Bacarisse wrote:
>> bart c <bart...@gmail.com> writes:
>
>>> That is, you want to be able to type:
>>>
>>> X
>>>
>>> and not:
>>>
>>> X Y
>> No, I want to type
>>
>> make
>> make tests
>> make install
>> make clean
>> make mylib.a
>
> I'm not familiar with how make is used. Do you routinely have to invoke it five times in succession? Maybe that's a deeper problem with it, but as I said I don't use it.
>

So you are not familiar with make, yet you feel qualified to tell those
who /do/ use it how terrible it is? Is it any wonder people question
your judgements?

Perhaps it is just your unfamiliarity with common development practices,
but I expect everyone else understood that Ben's list there had implied
"or" between the lines - he can type any or all of such commands, as and
when he feels it is appropriate as he works. It's quite unusual to make
multiple targets one after the other like that (other than perhaps
something like "make && make install" or "make clean && make all"). The
great thing about dependencies and a tool like make is that you
generally only need to specify a single target, and make will build all
the parts needed to get there.

>> depending on what I'm doing rather than
>>
>> make makefile
>> make makefile tests
>> make makefile install
>> make makefile clean
>> make makefile mylib.a
>
> And this actually tells me that the main input is identical in all cases; I'd been wondering what was being done with mylib.a. But whatever it is, the same makefile that does all the other stuff contains some formula for 'mylib.a'?
>

The same makefile will contain rules for how to build all the targets, yes.

> In practice I doubt you would type this five times as normally you'd do line recall then change the last bit. You can also choose to give it a shorter name than 'makefile'!
>

In practice, he would not run a series of different make targets like
that, as explained above. And since make uses "makefile" as the default
name, that's far better than using a short, cryptic name for the makefile.

>> What's more, tab completion in my shell works with make's targets, but I
>> don't think that's at all easy to do if the makefile has to be named in
>> the same command.
>>> like nearly every other command line program.
>>
>>> Yet being able to do
>>>
>>> X Y
>>>
>>> instead of:
>>>
>>> X Y.Z
>>>
>>> on those other programs is anathema.
>> Well (if you are talking about having to say gcc prog.c rather than gcc
>> prog) there are advantages, and none of them have anything to do with
>> how much one has to type. After all, command completion means I rarely
>> type a file name explcitly anyway.
>
> If my C test folder, I had 23 files that started with 'hello'.

And there's your problem.

> Although they are stepped through in alphabetical order on Windows and .c is near the top, you still have to tentatively keep pressing tab, then you go too far and need shift-tab .. it is quicker just to type the extension! Better however not to have to bother.

The inadequacies of Window's primitive form of tab completion is not a
flaw in gcc. Either use a better shell (they are alternatives available
for Windows - and I gather Powershell is less bad here), or avoid making
your life harder by picking filenames that don't all start with "hello".

>
>
>> The main advantage is that there's no need to specify and remember all
>> the rules. Does gcc always add .c? Will it add .c if I type gcc
>> prog.s? Must I avoid any dots in the basename? What happens when
>> several names appear on the command line?
>
> gcc is a bad example to follow since it does too much on the command line and performs multiple functions. So it easy to argue that, because it handles 58 different file types (I've no idea), singling one out to use a default is senseless.
>

Ah, gcc is bad because it does so much more than your toy compiler?

> But with a simpler product whose primary input files are C source files, then a default .c extension makes a lot of sense.
>

I've used other compilers that are pure C compilers (they have all been
Windows-only or DOS-only, not *nix tools). They expected a full
filename - it just makes things so much easier and consistent. There is
rarely any significant benefit in a default extension for an input file.

> The rules on Windows can be simple: if there is no extension (no dot in the name), then a default extension is added.

Windows has no such rule - programs do their own thing.

When /saving/ files, it is common to add a default extension if the file
extension is entirely obvious - that's another matter, and can save a
few keystrokes.

And then Windows has the utterly insane idea of hiding file extensions
by default in its gui tools. This trick has been a godsend to malware
writers, who can name their files "readme.txt.exe" or "Nude
pictures.jpg.exe", so that people think they are safe to open. And it
is a nightmare for anyone using their machine for development, because
now your files "hello.c", "hello.h", "hello.o", "hello.exe", "hello.txt"
are listed as "hello" five times.

The idiocies of Windows are, of course, no relevance to make or gcc -
but don't tout Windows or Windows conventions as though they were good
examples of developer-friendly practices!

> It's harder with a Linux file system because files "abc" and "abc." are distinct; how to do apply a default extension to "abc" when that could be a valid filename?
>

Why would you want to?

On real systems, the type of a file is determined primarily by what the
file contains, not some three-letter relic from the 1980's. Filename
extensions should be for the convenience of the /user/ - not something
for a tool to get flustered about just because I happen to call a file
"program_ver.1.02.c".

> However on Windows and various other OSes before that over decades, it hasn't really given any problems.
>
>>> So either 'X Y' is too much to type, or `X Y' is not enough! Even
>>> though you will be using the latter case more often.
>> No. I don't think anyone cares about how much one types (I don't)
>> provided there is some point to it. It's annoying to be forced to type
>> something redundant every time, whereas it's potentially confusing to
>> have gcc pick default extensions.
>
> Exactly. I consider the '.c -oprog' in 'gcc prog.c -oprog' to be redundant. Note that on Windows, it will apply the .exe extension to that output.

For the limited little world you live in, it might happen to be
redundant for you. Since no one but you uses your tools, you have no
comparison. Accept that the rest of the world can have different opinions.

>
>
>>> It's fascinating watching psychology and group-think at work.
>> As usual, you've invented a position (it'a all about the typing) and
>> argued about that instead of taking on board the actual comments that
>> people have made.
>
> The typing is part of it. Using the same default file in this case seem to me to be fragile.

Well, I for one will give that thought all the weight it deserves in
light of your extensive experience with the tool.

> Remember the Github Lua with the missing makefile? I didn't know there were supposed to be two, and assume that one called 'makefile' was /the/ makefile. Or someone could simply be in the wrong folder.
>

Again, your experience will be given due consideration.

On 18/08/2023 17:58, bart c wrote:
> On Friday, 18 August 2023 at 16:11:35 UTC+1, David Brown wrote:
>> On 18/08/2023 16:48, bart c wrote:
>>> On Friday, 18 August 2023 at 14:33:08 UTC+1, David Brown wrote:
>>>> On 17/08/2023 18:16, Bart wrote:
>>
>>>>> This is an analogy I have used before regarding LLVM, which is a backend
>>>>> for language implementations. It is quite large and complex.
>>>>>
>>>>> Once I needed a side-gate for my house. I made it myself, and ended up
>>>>> with a 6' high wooden gate, of just the right size.
>>>>>
>>>>> Now if I'd gone to the LLVM shop as a solution, the gate would have been
>>>>> 9 miles high - if I could ever figure it out.
>>>>>
>>>> As analogies go, that's a particularly silly one.
>>>
>>> LLVM in concept is simple: feed it some IL (or it calls it IR), and it turns it into a runnable binary. The actuality is very different.
>>>
>>> I created my own similar product in 2021, which was a 0.2MB binary. The downloads needs to get started with LLVM are some 2.3GB. That's how you get from 6 feet to 9 miles. But the biggest obstacle is the sheer complexity, with 100 /sets/ of documentation.
>>>
>> Doesn't the quantity of documentation in llvm give you a hint that
>> perhaps your product is /not/ similar?
>
> The point of using LLVM is similar to that of targetting C:
>
> * You don't want the bother of writing the backend of a compiler
>
> * You want portability by not generating different code for x64/arm, Linux/Windows etc
>
> * You want to take advantage of optimisation

I know what llvm is, and why people use it.

Your products are a world apart, even if you too have made something
vaguely similar to a small part of the llvm project.

>
> You don't however need that amount of documentation to use C; so C is far simpler.
>
> An IL would be a much simpler language than C.
>
> For the IL I use (based on a stack-based VM), a portable interpreter can be written in 0.1MB. A program to turn it into native code would be 0.2MB per target.
>
> The task is just not complex. Unless you want code that is optimised, but it might be a magnitude bigger task to get it good enough; it won't be several magnitudes bigger.
>
>

On Saturday, 19 August 2023 at 12:51:42 UTC+1, David Brown wrote:
> On 19/08/2023 03:36, bart c wrote:
> > On Saturday, 19 August 2023 at 01:21:58 UTC+1, Ben Bacarisse wrote:
> >> bart c <bart...@gmail.com> writes:
> >
> >>> That is, you want to be able to type:
> >>>
> >>> X
> >>>
> >>> and not:
> >>>
> >>> X Y
> >> No, I want to type
> >>
> >> make
> >> make tests
> >> make install
> >> make clean
> >> make mylib.a
> >
> > I'm not familiar with how make is used. Do you routinely have to invoke it five times in succession? Maybe that's a deeper problem with it, but as I said I don't use it.
> >
> So you are not familiar with make, yet you feel qualified to tell those
> who /do/ use it how terrible it is? Is it any wonder people question
> your judgements?

Call it the equivalent of a 'code smell'.

> Perhaps it is just your unfamiliarity with common development practices,
> but I expect everyone else understood that Ben's list there had implied
> "or" between the lines - he can type any or all of such commands, as and
> when he feels it is appropriate as he works. It's quite unusual to make
> multiple targets one after the other like that (other than perhaps
> something like "make && make install" or "make clean && make all"). The
> great thing about dependencies and a tool like make is that you
> generally only need to specify a single target, and make will build all
> the parts needed to get there.

I use a toy IDE. Once you load a project file, then the command line interface allows simple commands like:

c compile (either whole program, or module for C)
l (link, C only)
r (run)
g (go, just do whatever is needed to run the program)

It has a working context. The way 'make' works is a crude way of creating such a context, from command line. For my taste, it's too crude. It makes my 1980s style IDE look sophisticated.

> > Although they are stepped through in alphabetical order on Windows and ..c is near the top, you still have to tentatively keep pressing tab, then you go too far and need shift-tab .. it is quicker just to type the extension! Better however not to have to bother.
> The inadequacies of Window's primitive form of tab completion is not a
> flaw in gcc.

I found Linux tab completion unusable.

> > gcc is a bad example to follow since it does too much on the command line and performs multiple functions. So it easy to argue that, because it handles 58 different file types (I've no idea), singling one out to use a default is senseless.
> >
> Ah, gcc is bad because it does so much more than your toy compiler?

It's a Swiss Army knife; it does everything. You don't have a streamlined way of using it for one task.

I thought Linux was famous for being a collection of tools that each had one simple job? Then you chained them together. gcc breaks that.

> > But with a simpler product whose primary input files are C source files, then a default .c extension makes a lot of sense.
> >
> I've used other compilers that are pure C compilers (they have all been
> Windows-only or DOS-only, not *nix tools). They expected a full
> filename - it just makes things so much easier and consistent.

Yes, I said this. The 1000 times I have to invole Lua on a like name, I've had to type 'lua' twice: 'lua prog.lua'. Redundancy.

Maybe I can use a null extension? I don't know. I do know that I don't want a bunch of files of mixed languages all having no extension! I WANT extensions, but I shouldn't need to type them for a dedicated tool that only works with that extension anyway.

There is
> rarely any significant benefit in a default extension for an input file.
> > The rules on Windows can be simple: if there is no extension (no dot in the name), then a default extension is added.
> Windows has no such rule - programs do their own thing.
>
> When /saving/ files, it is common to add a default extension if the file
> extension is entirely obvious - that's another matter, and can save a
> few keystrokes.

You're making excuses for gcc! I reinstalled gcc 10.3.0 to try this:

gcc -shared -obignum bignum.c

What is the obvious extension here? I expected bignum.dll, it produces bignum.exe.

My bcc product worked like this:

bcc -dll bignum

it produced bignum.dll. It's not rocket science.

> And then Windows has the utterly insane idea of hiding file extensions
> by default in its gui tools.

I agree, that was a stupid idea. I avoid using GUI though mostly for other reasons: they are too fiddly.

> The idiocies of Windows are, of course, no relevance to make or gcc -
> but don't tout Windows or Windows conventions as though they were good
> examples of developer-friendly practices!

An executable called abc.def can be run by typing abc.def.

One called ghi.jkl.exe can be running by typing either ghi.jkl or ghi.jkl.exe. The rules seem to work well, even with embedded periods, unless you try and have a file called ghi.exe.exe and there is also one called ghi.exe (I haven't tried it).

But it means executables can HAVE extensions, which is highly desirable, but you rarely have to type 'gcc.exe' for example. On Linux you /would/ have to type gcc.exe.

> > It's harder with a Linux file system because files "abc" and "abc." are distinct; how to do apply a default extension to "abc" when that could be a valid filename?
> >
> Why would you want to?

Ask the user. There was a huge thread about being able to use - or -? as a filename, so why not both abc and abc.? Note this was on Linux.

> > Remember the Github Lua with the missing makefile? I didn't know there were supposed to be two, and assume that one called 'makefile' was /the/ makefile. Or someone could simply be in the wrong folder.
> >
> Again, your experience will be given due consideration.

I tinkered with make on and off for decades. It never went well. It never bought me anything extra for my own stuff.

On Saturday, 19 August 2023 at 12:56:50 UTC+1, David Brown wrote:
> On 18/08/2023 17:58, bart c wrote:
> > On Friday, 18 August 2023 at 16:11:35 UTC+1, David Brown wrote:
> >> On 18/08/2023 16:48, bart c wrote:
> >>> On Friday, 18 August 2023 at 14:33:08 UTC+1, David Brown wrote:
> >>>> On 17/08/2023 18:16, Bart wrote:
> >>
> >>>>> This is an analogy I have used before regarding LLVM, which is a backend
> >>>>> for language implementations. It is quite large and complex.
> >>>>>
> >>>>> Once I needed a side-gate for my house. I made it myself, and ended up
> >>>>> with a 6' high wooden gate, of just the right size.
> >>>>>
> >>>>> Now if I'd gone to the LLVM shop as a solution, the gate would have been
> >>>>> 9 miles high - if I could ever figure it out.
> >>>>>
> >>>> As analogies go, that's a particularly silly one.
> >>>
> >>> LLVM in concept is simple: feed it some IL (or it calls it IR), and it turns it into a runnable binary. The actuality is very different.
> >>>
> >>> I created my own similar product in 2021, which was a 0.2MB binary. The downloads needs to get started with LLVM are some 2.3GB. That's how you get from 6 feet to 9 miles. But the biggest obstacle is the sheer complexity, with 100 /sets/ of documentation.
> >>>
> >> Doesn't the quantity of documentation in llvm give you a hint that
> >> perhaps your product is /not/ similar?
> >
> > The point of using LLVM is similar to that of targetting C:
> >
> > * You don't want the bother of writing the backend of a compiler
> >
> > * You want portability by not generating different code for x64/arm, Linux/Windows etc
> >
> > * You want to take advantage of optimisation
> I know what llvm is, and why people use it.
>
> Your products are a world apart, even if you too have made something
> vaguely similar to a small part of the llvm project.

My product takes a program in an intermediate language, and runs it or turns it into an executable for a specific target T.

How is that different from the LLVM solution with option -O0 for the same target?

An installation of everything needed to use my product from C, for example, would be 1/10000th of the size of the LLVM binary downloads, which I believe is not all that is needed either.

It's a similar difference to tcc.exe versus whatever massive collection of binaries that Clang uses (and which, I believe, still needs MS tools to work).

Of course Clang is much more sophisticated: it generates errors and warnings in light-grey text, the same colour as my console background, so that they're invisible! Classy. gcc at least sets also the background, but doesn't restore it afterwards. Sloppy.

On 18/08/2023 19:49, bart c wrote:
> On Friday, 18 August 2023 at 15:44:21 UTC+1, David Brown wrote:

>> There is a third option - you do this just as a hobby for your own
>> interests and enjoyment, and understand its limitations, and
>> that's great too.
>
> Q can give Python a run for its money too in features and in speed.

/That/ is why you get ridiculed. I don't doubt that Q is fast. I /do/
doubt that it is remotely comparable to Python in features.

> However this is not a conventional project since I'm responsible for
> 100% of the language, of the implementation, of the implementation
> language, /its/ implementation, of the ultra-simple and near-instant
> build process it uses.
>
> It's quite an achievement ...

It certainly is an achievement. (I have always said that about your
compilers, languages, and other tools.)

So why do you feel the need to ridicule it and bring laughter upon it by
making ridiculous claims?

When I got my green belt in Judo, it was quite an achievement - a rare
one for a fifty-year-old. But if I had posted about it in sports.boxing
(note that Judo has no connection with boxing) and claimed I could give
Claude van Damme (whose speciality is in completely different martial
arts) a run for his money in a fight, what sort of praise do you think
I'd get? If I said that Judo bouts can be over in ten or fifteen
seconds, therefore boxing matches lasting 45 minutes are inefficient and
slow, would people take me seriously?

Your tools and languages /are/ achievements of note - celebrate them for
what they are, and stop playing the clown by claiming they are something
that they are not.

>
>
>> It's only futile when you build yourself a tree-house and tell
>> people it's better than the Empire State Building, and that you are
>> fighting against bloated and inefficient houses.
>
> ... but I'm not allowed to boast about it because people like you
> will always cut me down to size.
>

You /do/ need to be cut down to size.

You have made neat little niche tools that do exactly what /you/ want
them to do for /your/ needs. That's great (and that was not sarcasm).

But your tools are not what other people want or need. They do not
compare to real languages and serious tools. They are not better, they
are not even similar - they can, at best, do a small number of the tasks
handled by major languages and tools, and they can, at best, beat them
on a small number of minor metrics.

So if you were to post saying you'd made a nice little bytecode
interpreter for a small IL/IR, suitable for some kinds of simple
scripting, I might say that's great. When you then say your tool is
practically the same as llvm and the llvm developers are clearly
incompetent and inefficient, /then/ you get the negative feedback.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>bart c <bart4858@gmail.com> writes:
>

>>
>> on those other programs is anathema.
>
>Well (if you are talking about having to say gcc prog.c rather than gcc
>prog) there are advantages, and none of them have anything to do with
>how much one has to type. After all, command completion means I rarely
>type a file name explcitly anyway.
>

It's worth repeating that 'gcc' is a driver program, not a compiler.

So:

$ gcc -c -o a.o a.s

is a perfectly legal and viable way to invoke the assembler.

$ gcc -o a a.o

is a perfectly legal and viable way to invoke the linker.

On 19/08/2023 13:39, bart c wrote:
> That's interesting. One of the limitations of Lua was that it didn't have proper integer type, it used a 64-bit float.
>

Lua is configurable, and can support different types. When I embedded
in a 32-bit microcontroller program, I use 32-bit integers as the number
type.

On Saturday, 19 August 2023 at 14:17:15 UTC+1, David Brown wrote:
> On 18/08/2023 19:49, bart c wrote:
> > On Friday, 18 August 2023 at 15:44:21 UTC+1, David Brown wrote:
>
> >> There is a third option - you do this just as a hobby for your own
> >> interests and enjoyment, and understand its limitations, and
> >> that's great too.
> >
> > Q can give Python a run for its money too in features and in speed.

> /That/ is why you get ridiculed. I don't doubt that Q is fast. I /do/
> doubt that it is remotely comparable to Python in features.

There are some features I value: https://github.com/sal55/langs/blob/master/qbasics.md

No doubt Python has many more /advanced/ features which I can't understand and wouldn't use, but it has lots of basic stuff missing.

> It certainly is an achievement. (I have always said that about your
> compilers, languages, and other tools.)
>
> So why do you feel the need to ridicule it and bring laughter upon it by
> making ridiculous claims?
>
>
> When I got my green belt in Judo, it was quite an achievement - a rare
> one for a fifty-year-old.

Did you make a living out of it as I did via my languages?

> You /do/ need to be cut down to size.
>
> You have made neat little niche tools that do exactly what /you/ want
> them to do for /your/ needs. That's great (and that was not sarcasm).
>
> But your tools are not what other people want or need.

How do you know what other people or need?

> They do not compare to real languages and serious tools.

I started creating embedded scripting languages for my commercial apps in the late 80s.

People here have talked about using embedded languages in their programs.

I was doing that over 30 years ago. I also designed and implemented the languages used. I designed and implemented the languages used to write those applications and interpreters. Those add-on languages were used by a variety of OEMs to create add-on products to my applications, which were also internationalised to Dutch, German and French languages.

I also wrote the user manuals (and produced them by writing runoff-like scripts, processing them on the application itself, and sending the output as PostScript).

So, what I did wasn't a real language or a real tool? Well, people paid real money for it!

(BTW the nearest competitor to our product was AutoCAD. Their scripting language was based around Lisp.)

> They are not better, they
> are not even similar - they can, at best, do a small number of the tasks
> handled by major languages and tools, and they can, at best, beat them
> on a small number of minor metrics.
>
>
> So if you were to post saying you'd made a nice little bytecode
> interpreter for a small IL/IR, suitable for some kinds of simple
> scripting, I might say that's great. When you then say your tool is
> practically the same as llvm and the llvm developers are clearly
> incompetent and inefficient, /then/ you get the negative feedback.

And I asked you what was the difference between getting the task done by my product, and the same task via LLVM. You haven't answered that.

I've already acknowleged that it can generate faster code. What else that is a positive difference?

If somebody writes a compiler for X that uses intermediate C and incorporates a Tcc backend, what difference will they see from a version that instead incorporates gcc or Clang? Apart from the obvious one of the latter being 2 magnitudes bigger and 1-2 magnitudes slower.

Similarly, what difference will they see between one using an LLVM backend, versus one using, say, QBE? (https://c9x.me/compile/doc/llvm.html).

BTW I haven't said the LLVM developers are incompetent. It's a remarkable product. But for what it does, it's ridiculously big and complicated. It could do with a reboot that eliminates a lot of the cruft. A few years ago somebody reported a build-time for the LLVM binaries which was an estimated 6-12 hours on my then machine; that is crazy.

On Saturday, 19 August 2023 at 15:43:02 UTC+1, Scott Lurndal wrote:
> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> >bart c <bart...@gmail.com> writes:
> >
>
> >>
> >> on those other programs is anathema.
> >
> >Well (if you are talking about having to say gcc prog.c rather than gcc
> >prog) there are advantages, and none of them have anything to do with
> >how much one has to type. After all, command completion means I rarely
> >type a file name explcitly anyway.
> >
> It's worth repeating that 'gcc' is a driver program, not a compiler.
>
> So:
>
> $ gcc -c -o a.o a.s
>
> is a perfectly legal and viable way to invoke the assembler.
>
> $ gcc -o a a.o
>
> is a perfectly legal and viable way to invoke the linker.

You can run the assembler directly using 'as', and the linker using 'ld'.

So how do you directly invoke the actual C compiler?