On 11/08/2023 11:50, Kalevi Kolttonen wrote:
> Bart <bc@freeuk.com> wrote:
>>>> So I had to tell it the C files. I can't do *.c, as
>>>> there are 259 other .c files in the folder.
>
> Not related to C programming, but someone might find
> this fascinating: When one of my colleagues died some years
> ago, his Unix home directory had to be examined in order to
> find work related files there.
>
> The top-level directory contained over 10 000 (yes,
> *ten thousand*) unrelated files and there were
> practically no subdirectories.

The Firefox browser on an old PC always seemed very busy when running,
the hard drive was always buzzing.

It turned out that the limit to the number of temporary files it could
create was disabled. By the time I found this out, it had a single
folder with 3.5 million files.

Deleting them took 14 hours.

All the folders I create are specific to one project, but I rarely use
subfolders unless there's a real need, for example to segregate large
inputs.

Kaz Kylheku <864-117-4973@kylheku.com> writes:
>On 2023-08-11, Spiros Bousbouras <spibou@gmail.com> wrote:
>> On Thu, 10 Aug 2023 16:15:32 -0000 (UTC)
>> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>> What we could have is that an executable just dynamically links to
>>> functions in these libraries, and the system automatically finds them at
>>> load time, without the executable having to specify which libraries.
>>
>> And how is your scheme different than how it already works in the Unix
>> world ?
>
>How it differs is that the executable has to nominate the specific
>libraries by indicating the library, which came in via the -l option,
>and then look for specific symbols from specific libraries that it has
>attached.
>
>Under the hood, the semantics is much like dlopen() of specific
>liraries to obtain a handle and then doing dlsym(handle, "name")
>to look for specific names from specific libs.
>
>Imagine it could specify just symbols, without specifying where
>they come from; that's a big difference.

Would this not require that no symbol be present in more than
one library, i.e. that there is a single symbol namespace across the
entire system?

That would seem to be a non-starter.

Bart <bc@freeuk.com> writes:
>On 11/08/2023 07:43, David Brown wrote:
> > On 09/08/2023 16:07, Bart wrote:
> >> On 09/08/2023 14:32, Richard Harnden wrote:
> >> > On 09/08/2023 13:32, Bart wrote:
> >> >> Yes, that is one reason that it is so complicated. You have to
>define
> >> >> set of dependences between modules (and you may need to do that
> >> >> manually, so it can be error prone).
> >> >
> >> > $ gcc -MM *.c
> >>
> >> I have a small, 3-file project (one of Chris's) comprising files
> >> cipher.c, sha2.c, hmac.c
> >>
> >> gcc -MM cipher.c outputs:
> >>
> >> cipher.o: cipher.c hmac.c sha2.h
> >>
> >> I need to do -MM cipher.c hmac.c sha2.c for it to show:
> >>
> >> cipher.o: cipher.c hmac.h sha2.h
> >> hmac.o: hmac.c hmac.h sha2.h
> >> sha2.o: sha2.c sha2.h
> >>
> >> So I had to tell it the C files. I can't do *.c, as there are 259
> >> other .c files in the folder.
> >>
> >
> > There's this wonderful organisation technique for files called
> > "directories". They even exist in Windows.
> >
> > Put the files of a project in a directory. Delete the junk. Then you
> > can find your files, and you can use "gcc -MM *.c". It even works if
> > you have multiple different programs - it simply generates dependency
> > information so you know which C files need re-compiled when headers are
> > changed.
> >
> > But of course when someone gives you help or answers your questions,
> > you'd rather complain more.
> >
>
>So you're telling people exactly what they're allowed to have in their
>folders and what they're not.

Perhaps it is time to simply stop responding to Bart when he continues
to make such silly statements.

piątek, 11 sierpnia 2023 o 02:58:49 UTC+2 fir napisał(a):
> piątek, 11 sierpnia 2023 o 02:30:18 UTC+2 Bart napisał(a):
> > On 11/08/2023 00:06, fir wrote:
> > > piątek, 11 sierpnia 2023 o 00:17:57 UTC+2 Bart napisał(a):
> > >> On 10/08/2023 22:44, fir wrote:
> > >>> czwartek, 10 sierpnia 2023 o 20:16:49 UTC+2 Kaz Kylheku napisał(a):
> > >>>>
> > >>>> DLLs are lacking in some technology like symbol versioning, linking
> > >>>> in any direction (DLL cannot attach to symbols exported by executable)
> > >>>> and such. Plus the use of clunky .lib files taht SO's don't require,
> > >>>> and __decl(dllexport) and other cruft. (That pragma mechanism by
> > >>>> which a source file indicates a needed DLL doesn't need a .lib file
> > >>>> though, IIRC).
> > >>>>
> > >>>
> > >>> i dont remember as to this exe, though i remember i was testing it and
> > >>> those relative usage - when i was writing more than one dll was making
> > >>> some problems to me.. i dont remember hovever if you cant call
> > functions in exe
> > >>> though - problem was rather that when you want to compile dll using
> > other dll you need to have the other build (becouse compilaton readed
> > binary dll to check if symbols exist even if
> > >>> linking is rruntime - this is in fact stupid but this is a
> > consequence of fact that when
> > >>> you link to a symbol compilers dont know in which of dlls you want
> > to0 link it is,
> > >>> and it need to put not only symbols but their parent module names
> > in output) ..
> > >>> it is mighty stupid bcouse you cant compile code that uses the dll
> > that you dont really get
> > >>> (unles there is some way providing this info on symbold what is the
> > name of the
> > >>> parent module of them, __declspec(dllimport) are not a problem though
> > >>>
> > >>> it should be some other extension too like
> > >>>
> > >>> __something "green fire.dll" //import module name for given symbols
> > >>> {
> > >>> __declspec(dllimport) int foo(int a);
> > >>> __declspec(dllimport) float xx;
> > >>> }
> > >>>
> > >>> but i dont know if there is something like that
> > >>>
> > >>>
> > >>> but besides in practice there are no problems with dlls at least
> > when i use it
> > >>> is a breat with butter
> > >>>
> > >>> dlls are very likeable and i tell not a first time that if someone
> > coded in c on windows he must
> > >>> learn dlls becouse dlls are sorta part of practical c..and its real
> > nice part (ofc it lacks types
> > >>> encoded and call conventions which would allow to just get rid of
> > headers - check my thread/post on it)
> > >>>
> > >>> probably it would allow even normal c to get rid of headers as pif
> > everything would just work without headers people just could not include
> > them and tha wouldnt break codes
> > >> How would that work? To use a function exported from a DLL, you will
> > >> need a function signature, perhaps a set of usertypes, enums and
> > #defines.
> > >>
> > >> All the stuff that normally is provided by a header.
> > >>
> > >> Where would that information come from?
> > >>
> > >> (My own idea was for an interface info to be embedded inside the DLL,
> > >> and accessed by calling a special exported function. For C, that could
> > >> just return a string containing the normal header code.
> > >>
> > >> But it would need cooperation from the people creating the DLL (who
> > >> could be writing in any language, not C).
> > >>
> > >> And from C compilers to delve inside DLL files (and at an early stage
> > >> long before linking). Since C compilers can't even shake off
> > >> anachronisms like -lm and a.out, I can't see that happening.)
> > >>
> > >>
> > >>
> > >> My idea was for my own private use
> > > doi
> > > lern how PE format works coz it is really important - not mucnh
> > pleasant to read but important as hell
> > You really don't need to disect a DLL file to extract some data from it..
> > A regular interface will do.
> >
> > For example, for a DLL that exports one function 'add()', add this extra
> > function:
> >
> > char* header = "int add(int, int);\n";
> > char* getheader(void) { return header;}
> >
> > and create a DLL like 'lib.dll'.
> >
> > Now, in the compiler that wants to import functions from lib.dll, use
> > code like this:
> >
> > #include <stdio.h>
> > #include <windows.h>
> >
> > int main(void) {
> > void* handle;
> > char* (*fnptr)(void);
> >
> > handle=LoadLibrary("lib.dll");
> > if (handle) {
> > fnptr=GetProcAddress(handle, "getheader");
> > if (fnptr)
> > printf("Header = %s\n", fnptr());
> > }
> > }
> >
> > Calling getheader() returns the same string as including a header file
> > like 'lib.h'.
> >
> > No need to be delving inside the PE format.
> >
> > Actually, as written, that 'header' variable is exported also, so you
> > can directly access that, but I prefer to do it via a function.
> >
> > And, PE is a terrible, terrible format. Only get into as last resort.
> you cannot return c code as it must be binary level description language agnostic,
> calling code is weird as it imo should be a normal format that you could open on other system then dll is run on
> adding a section is normal way and is no specially hard, it is to do in few days (first functioning draft of it, but that would be most work)

in fact i must (should) slightly revrite the code in org-asm that builds import section, and i should add one that creates export section too, so maybe i will post detail on this how hard this is or rather is not, its a matter of one evening of easy code (except that little stress that youre not sure if you know enough well the windows demand and if it will run, as you must belive in 'gossips; on it)

i will be writing it soon so i may probably post on it though today i feel mighty sick (health problems)

piątek, 11 sierpnia 2023 o 02:58:49 UTC+2 fir napisał(a):
> piątek, 11 sierpnia 2023 o 02:30:18 UTC+2 Bart napisał(a):
> >
> > Calling getheader() returns the same string as including a header file
> > like 'lib.h'.
> >
> > No need to be delving inside the PE format.
> >
> > Actually, as written, that 'header' variable is exported also, so you
> > can directly access that, but I prefer to do it via a function.
> >
> > And, PE is a terrible, terrible format. Only get into as last resort.
> you cannot return c code as it must be binary level description language agnostic,
> calling code is weird as it imo should be a normal format that you could open on other system then dll is run on
> adding a section is normal way and is no specially hard, it is to do in few days (first functioning draft of it, but that would be most work)

besides if you would make compilers calling modules code to obtain headers you could make that compiler runy any of your code, playing songs for example - that would be funny maybe but...

as i said it must be language agnostic type info do it canyt be header but some binary specification based on registered enumarations (conventions) accepted in binary abi world (see that post i wrote, it gives the description in more detail)

https://groups.google.com/g/comp.lang.c/c/Qniawhtoc7s

On Friday, August 11, 2023 at 4:33:47 PM UTC+3, Scott Lurndal wrote:
> Bart <b...@freeuk.com> writes:
> >On 11/08/2023 07:43, David Brown wrote:
> > > On 09/08/2023 16:07, Bart wrote:
> > >> On 09/08/2023 14:32, Richard Harnden wrote:
> > >> > On 09/08/2023 13:32, Bart wrote:
> > >> >> Yes, that is one reason that it is so complicated. You have to
> >define
> > >> >> set of dependences between modules (and you may need to do that
> > >> >> manually, so it can be error prone).
> > >> >
> > >> > $ gcc -MM *.c
> > >>
> > >> I have a small, 3-file project (one of Chris's) comprising files
> > >> cipher.c, sha2.c, hmac.c
> > >>
> > >> gcc -MM cipher.c outputs:
> > >>
> > >> cipher.o: cipher.c hmac.c sha2.h
> > >>
> > >> I need to do -MM cipher.c hmac.c sha2.c for it to show:
> > >>
> > >> cipher.o: cipher.c hmac.h sha2.h
> > >> hmac.o: hmac.c hmac.h sha2.h
> > >> sha2.o: sha2.c sha2.h
> > >>
> > >> So I had to tell it the C files. I can't do *.c, as there are 259
> > >> other .c files in the folder.
> > >>
> > >
> > > There's this wonderful organisation technique for files called
> > > "directories". They even exist in Windows.
> > >
> > > Put the files of a project in a directory. Delete the junk. Then you
> > > can find your files, and you can use "gcc -MM *.c". It even works if
> > > you have multiple different programs - it simply generates dependency
> > > information so you know which C files need re-compiled when headers are
> > > changed.
> > >
> > > But of course when someone gives you help or answers your questions,
> > > you'd rather complain more.
> > >
> >
> >So you're telling people exactly what they're allowed to have in their
> >folders and what they're not.
> Perhaps it is time to simply stop responding to Bart when he continues
> to make such silly statements.

On this particular issue I fully agree with Bart.

On 11/08/2023 14:32, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 11/08/2023 07:43, David Brown wrote:
>>> On 09/08/2023 16:07, Bart wrote:
>>>> On 09/08/2023 14:32, Richard Harnden wrote:
>>>> > On 09/08/2023 13:32, Bart wrote:
>>>> >> Yes, that is one reason that it is so complicated. You have to
>> define
>>>> >> set of dependences between modules (and you may need to do that
>>>> >> manually, so it can be error prone).
>>>> >
>>>> > $ gcc -MM *.c
>>>>
>>>> I have a small, 3-file project (one of Chris's) comprising files
>>>> cipher.c, sha2.c, hmac.c
>>>>
>>>> gcc -MM cipher.c outputs:
>>>>
>>>> cipher.o: cipher.c hmac.c sha2.h
>>>>
>>>> I need to do -MM cipher.c hmac.c sha2.c for it to show:
>>>>
>>>> cipher.o: cipher.c hmac.h sha2.h
>>>> hmac.o: hmac.c hmac.h sha2.h
>>>> sha2.o: sha2.c sha2.h
>>>>
>>>> So I had to tell it the C files. I can't do *.c, as there are 259
>>>> other .c files in the folder.
>>>>
>>>
>>> There's this wonderful organisation technique for files called
>>> "directories". They even exist in Windows.
>>>
>>> Put the files of a project in a directory. Delete the junk. Then you
>>> can find your files, and you can use "gcc -MM *.c". It even works if
>>> you have multiple different programs - it simply generates dependency
>>> information so you know which C files need re-compiled when headers are
>>> changed.
>>>
>>> But of course when someone gives you help or answers your questions,
>>> you'd rather complain more.
>>>
>>
>> So you're telling people exactly what they're allowed to have in their
>> folders and what they're not.
>
> Perhaps it is time to simply stop responding to Bart when he continues
> to make such silly statements.

What exactly is silly about it? Isn't that what is being said or not?

Perhaps it is time to stop forcing YOUR working practices down other
people's throats, and making out they are so superior.

piątek, 11 sierpnia 2023 o 16:28:55 UTC+2 fir napisał(a):
> > piątek, 11 sierpnia 2023 o 02:30:18 UTC+2 Bart napisał(a):
> > >
> > > Actually, as written, that 'header' variable is exported also, so you
> > > can directly access that, but I prefer to do it via a function.
> > >
the ide of kkeping this header as a string is not totally idiotic but its
not optimal (its c specific and thus sorta weird, but theorethically might b used as some additions of what things look like now - but sort athis way you could add whoel source to dll as a string too)

also to remember are efficincy things - i realized it maybe clearer writing
on this swuare complexity that breakc computer down even for 1000 objects, and also those newline counts by fgets that took 300 ms:

computers are still slow today.. reading 1 MB file or its part still takes about 1 ms
(as to rank and saing not precisisely ofc depending on machine but say so)
it is notable amount of time (as things stack)

square algorithms breaks (begin to break) computers runtime in range 1k - 5k simple objects linear breaks (begin to break ) computer in range 1M simple objects... so when talking about runtime and fluid working the machines are still slow...and if you would add that headers, even if ram dont matter so much today
the time is imo still bottleneck imo

still hope the rems would be faster maybe as it would be really nice to have 10x as fast as today - say 100 GB/s or 1 TB/s) at home (this /s is misleading ofc coz important is what you got a t milisecond not on second..so 100 GB/s is 100 MB/ms which is nice but not so much cosmic amount as for today)

piątek, 11 sierpnia 2023 o 16:47:48 UTC+2 fir napisał(a):
>
> square algorithms breaks (begin to break) computers runtime in range 1k - 5k simple objects linear breaks (begin to break ) computer in range 1M simple objects...

it also dependants what one means simple - if simple means pixel it 'began to
break' 1M or more but if soem means particles with more if logic etc or rasterized triangles (on CPU) it even began to break at 100k... (it then depends on machine as on old it may ba 100k on new it may be 600k)

so i mean those talk is some kind of methafor/estimation but i would say linear things began to break a 1M (or seometimes even less) today (strictly on my old machine it began to break at 100-150k)

On 11/08/2023 15:47, fir wrote:
> piątek, 11 sierpnia 2023 o 16:28:55 UTC+2 fir napisał(a):
>>> piątek, 11 sierpnia 2023 o 02:30:18 UTC+2 Bart napisał(a):
>>>>
>>>> Actually, as written, that 'header' variable is exported also, so you
>>>> can directly access that, but I prefer to do it via a function.
>>>>
> the ide of kkeping this header as a string is not totally idiotic but its
> not optimal (its c specific and thus sorta weird, but theorethically might b used as some additions of what things look like now - but sort athis way you could add whoel source to dll as a string too)
>
> also to remember are efficincy things - i realized it maybe clearer writing
> on this swuare complexity that breakc computer down even for 1000 objects, and also those newline counts by fgets that took 300 ms:
>
> computers are still slow today.. reading 1 MB file or its part still takes about 1 ms
> (as to rank and saing not precisisely ofc depending on machine but say so)
> it is notable amount of time (as things stack)
>
> square algorithms breaks (begin to break) computers runtime in range 1k - 5k simple objects linear breaks (begin to break ) computer in range 1M simple objects... so when talking about runtime and fluid working the machines are still slow...and if you would add that headers, even if ram dont matter so much today
> the time is imo still bottleneck imo
>
> still hope the rems would be faster maybe as it would be really nice to have 10x as fast as today - say 100 GB/s or 1 TB/s) at home (this /s is misleading ofc coz important is what you got a t milisecond not on second..so 100 GB/s is 100 MB/ms which is nice but not so much cosmic amount as for today)

Your comment I first replied to was talking about DLLs, and getting rid
of C headers.

I assumed that was about headers needed to access libraries present in
DLLs files.

If talking about a new language however, and headers in general, then of
course they can be eliminated.

I haven't used headers (ie. separate declarations of shared functions
etc) in my own languages for over a decade.

But still, if I want to use a DLL that /someone else has written/, I
need an interface to that library that I can then turn into bindings for
my language.

It is here, also, that binary, language-neutral, API information could
be added to and accessed from a DLL file in the manner I suggested for C
header info.

Then an explicit file of API declarations, in whatever language, is not
needed. Although something will be needed as docs so that you know how
to use the library.

piątek, 11 sierpnia 2023 o 17:13:22 UTC+2 Bart napisał(a):
> On 11/08/2023 15:47, fir wrote:
> > piątek, 11 sierpnia 2023 o 16:28:55 UTC+2 fir napisał(a):
> >>> piątek, 11 sierpnia 2023 o 02:30:18 UTC+2 Bart napisał(a):
> >>>>
> >>>> Actually, as written, that 'header' variable is exported also, so you
> >>>> can directly access that, but I prefer to do it via a function.
> >>>>
> > the ide of kkeping this header as a string is not totally idiotic but its
> > not optimal (its c specific and thus sorta weird, but theorethically might b used as some additions of what things look like now - but sort athis way you could add whoel source to dll as a string too)
> >
> > also to remember are efficincy things - i realized it maybe clearer writing
> > on this swuare complexity that breakc computer down even for 1000 objects, and also those newline counts by fgets that took 300 ms:
> >
> > computers are still slow today.. reading 1 MB file or its part still takes about 1 ms
> > (as to rank and saing not precisisely ofc depending on machine but say so)
> > it is notable amount of time (as things stack)
> >
> > square algorithms breaks (begin to break) computers runtime in range 1k - 5k simple objects linear breaks (begin to break ) computer in range 1M simple objects... so when talking about runtime and fluid working the machines are still slow...and if you would add that headers, even if ram dont matter so much today
> > the time is imo still bottleneck imo
> >
> > still hope the rems would be faster maybe as it would be really nice to have 10x as fast as today - say 100 GB/s or 1 TB/s) at home (this /s is misleading ofc coz important is what you got a t milisecond not on second..so 100 GB/s is 100 MB/ms which is nice but not so much cosmic amount as for today)
> Your comment I first replied to was talking about DLLs, and getting rid
> of C headers.
>
> I assumed that was about headers needed to access libraries present in
> DLLs files.
>
> If talking about a new language however, and headers in general, then of
> course they can be eliminated.
>
> I haven't used headers (ie. separate declarations of shared functions
> etc) in my own languages for over a decade.
>
> But still, if I want to use a DLL that /someone else has written/, I
> need an interface to that library that I can then turn into bindings for
> my language.
>
> It is here, also, that binary, language-neutral, API information could
> be added to and accessed from a DLL file in the manner I suggested for C
> header info.
>
> Then an explicit file of API declarations, in whatever language, is not
> needed. Although something will be needed as docs so that you know how
> to use the library.

i wouldnt say i say on new languages i just say on dll's as they are -
they just contain symbol names , and they at least should contain yet calling convention and at least input argument sizes or something but more better
argument list and its types and prefereably even names, and yet preferably even new type definitions encoded , and even more info

it cant be c declarations, it must be language agnostic - but is no problem tod efine this, you simoply need to define lists of namens and enums (liek list of enums with calling convention, list of enums for predefinde types, like int32 int64 float double (and things liek that) (if float is used in ABI at alla as i dont remember if it is not all doubles) etc

better realize it cant be c source header strings couse it cant, it must be binary, enum based convention

its hovever needed so its kinda obvious to say it will be defined and used, maybe i will define it myself when i will be shipping furia compiler more (i got only about half of it written and as i got other things to do it will take me yet at least few years assuming nothing much bad heppen at all)

piątek, 11 sierpnia 2023 o 17:28:41 UTC+2 fir napisał(a):
> piątek, 11 sierpnia 2023 o 17:13:22 UTC+2 Bart napisał(a):
> > On 11/08/2023 15:47, fir wrote:
> > > piątek, 11 sierpnia 2023 o 16:28:55 UTC+2 fir napisał(a):
> > >>> piątek, 11 sierpnia 2023 o 02:30:18 UTC+2 Bart napisał(a):
> > >>>>
> > >>>> Actually, as written, that 'header' variable is exported also, so you
> > >>>> can directly access that, but I prefer to do it via a function.
> > >>>>
> > > the ide of kkeping this header as a string is not totally idiotic but its
> > > not optimal (its c specific and thus sorta weird, but theorethically might b used as some additions of what things look like now - but sort athis way you could add whoel source to dll as a string too)
> > >
> > > also to remember are efficincy things - i realized it maybe clearer writing
> > > on this swuare complexity that breakc computer down even for 1000 objects, and also those newline counts by fgets that took 300 ms:
> > >
> > > computers are still slow today.. reading 1 MB file or its part still takes about 1 ms
> > > (as to rank and saing not precisisely ofc depending on machine but say so)
> > > it is notable amount of time (as things stack)
> > >
> > > square algorithms breaks (begin to break) computers runtime in range 1k - 5k simple objects linear breaks (begin to break ) computer in range 1M simple objects... so when talking about runtime and fluid working the machines are still slow...and if you would add that headers, even if ram dont matter so much today
> > > the time is imo still bottleneck imo
> > >
> > > still hope the rems would be faster maybe as it would be really nice to have 10x as fast as today - say 100 GB/s or 1 TB/s) at home (this /s is misleading ofc coz important is what you got a t milisecond not on second..so 100 GB/s is 100 MB/ms which is nice but not so much cosmic amount as for today)
> > Your comment I first replied to was talking about DLLs, and getting rid
> > of C headers.
> >
> > I assumed that was about headers needed to access libraries present in
> > DLLs files.
> >
> > If talking about a new language however, and headers in general, then of
> > course they can be eliminated.
> >
> > I haven't used headers (ie. separate declarations of shared functions
> > etc) in my own languages for over a decade.
> >
> > But still, if I want to use a DLL that /someone else has written/, I
> > need an interface to that library that I can then turn into bindings for
> > my language.
> >
> > It is here, also, that binary, language-neutral, API information could
> > be added to and accessed from a DLL file in the manner I suggested for C
> > header info.
> >
> > Then an explicit file of API declarations, in whatever language, is not
> > needed. Although something will be needed as docs so that you know how
> > to use the library.
> i wouldnt say i say on new languages i just say on dll's as they are -
> they just contain symbol names , and they at least should contain yet calling convention and at least input argument sizes or something but more better
> argument list and its types and prefereably even names, and yet preferably even new type definitions encoded , and even more info
>
> it cant be c declarations, it must be language agnostic - but is no problem tod efine this, you simoply need to define lists of namens and enums (liek list of enums with calling convention, list of enums for predefinde types, like int32 int64 float double (and things liek that) (if float is used in ABI at alla as i dont remember if it is not all doubles) etc
>

i think it could be also named "binary header block"

as it is kinde header buts its binary and dlls needs thet header block -
so its seen as header is stupid thing it needs to be something liek that in dlls, but on binary level, it also need to take some bytes - skipping it is kinda hard optimisation, but its needed for convenience of programmers and general information also decreasing amount of of errors etc

Michael S <already5chosen@yahoo.com> writes:
>On Friday, August 11, 2023 at 4:33:47=E2=80=AFPM UTC+3, Scott Lurndal wrote=
>:
>> Bart <b...@freeuk.com> writes:=20
>> >On 11/08/2023 07:43, David Brown wrote:=20
>> > > On 09/08/2023 16:07, Bart wrote:=20
>> > >> On 09/08/2023 14:32, Richard Harnden wrote:=20
>> > >> > On 09/08/2023 13:32, Bart wrote:=20
>> > >> >> Yes, that is one reason that it is so complicated. You have to=20
>> >define=20
>> > >> >> set of dependences between modules (and you may need to do that=
>=20
>> > >> >> manually, so it can be error prone).=20
>> > >> >=20
>> > >> > $ gcc -MM *.c=20
>> > >>=20
>> > >> I have a small, 3-file project (one of Chris's) comprising files=20
>> > >> cipher.c, sha2.c, hmac.c=20
>> > >>=20
>> > >> gcc -MM cipher.c outputs:=20
>> > >>=20
>> > >> cipher.o: cipher.c hmac.c sha2.h=20
>> > >>=20
>> > >> I need to do -MM cipher.c hmac.c sha2.c for it to show:=20
>> > >>=20
>> > >> cipher.o: cipher.c hmac.h sha2.h=20
>> > >> hmac.o: hmac.c hmac.h sha2.h=20
>> > >> sha2.o: sha2.c sha2.h=20
>> > >>=20
>> > >> So I had to tell it the C files. I can't do *.c, as there are 259=20
>> > >> other .c files in the folder.=20
>> > >>=20
>> > >=20
>> > > There's this wonderful organisation technique for files called=20
>> > > "directories". They even exist in Windows.=20
>> > >=20
>> > > Put the files of a project in a directory. Delete the junk. Then you=
>=20
>> > > can find your files, and you can use "gcc -MM *.c". It even works if=
>=20
>> > > you have multiple different programs - it simply generates dependency=
>=20
>> > > information so you know which C files need re-compiled when headers a=
>re=20
>> > > changed.=20
>> > >=20
>> > > But of course when someone gives you help or answers your questions,=
>=20
>> > > you'd rather complain more.=20
>> > >=20
>> >=20
>> >So you're telling people exactly what they're allowed to have in their=
>=20
>> >folders and what they're not.
>> Perhaps it is time to simply stop responding to Bart when he continues=20
>> to make such silly statements.
>
>On this particular issue I fully agree with Bart.

Nobody is telling Bart "exactly what they're allowed to have in their
folders". That's just nonsense.

Bart <bc@freeuk.com> writes:
>On 11/08/2023 14:32, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 11/08/2023 07:43, David Brown wrote:
>>>> On 09/08/2023 16:07, Bart wrote:
>>>>> On 09/08/2023 14:32, Richard Harnden wrote:
>>>>> > On 09/08/2023 13:32, Bart wrote:
>>>>> >> Yes, that is one reason that it is so complicated. You have to
>>> define
>>>>> >> set of dependences between modules (and you may need to do that
>>>>> >> manually, so it can be error prone).
>>>>> >
>>>>> > $ gcc -MM *.c
>>>>>
>>>>> I have a small, 3-file project (one of Chris's) comprising files
>>>>> cipher.c, sha2.c, hmac.c
>>>>>
>>>>> gcc -MM cipher.c outputs:
>>>>>
>>>>> cipher.o: cipher.c hmac.c sha2.h
>>>>>
>>>>> I need to do -MM cipher.c hmac.c sha2.c for it to show:
>>>>>
>>>>> cipher.o: cipher.c hmac.h sha2.h
>>>>> hmac.o: hmac.c hmac.h sha2.h
>>>>> sha2.o: sha2.c sha2.h
>>>>>
>>>>> So I had to tell it the C files. I can't do *.c, as there are 259
>>>>> other .c files in the folder.
>>>>>
>>>>
>>>> There's this wonderful organisation technique for files called
>>>> "directories". They even exist in Windows.
>>>>
>>>> Put the files of a project in a directory. Delete the junk. Then you
>>>> can find your files, and you can use "gcc -MM *.c". It even works if
>>>> you have multiple different programs - it simply generates dependency
>>>> information so you know which C files need re-compiled when headers are
>>>> changed.
>>>>
>>>> But of course when someone gives you help or answers your questions,
>>>> you'd rather complain more.
>>>>
>>>
>>> So you're telling people exactly what they're allowed to have in their
>>> folders and what they're not.
>>
>> Perhaps it is time to simply stop responding to Bart when he continues
>> to make such silly statements.
>
>What exactly is silly about it? Isn't that what is being said or not?

Nobody has told you what you're allowed to have in your directories.

piątek, 11 sierpnia 2023 o 17:38:03 UTC+2 fir napisał(a):
> >
> i think it could be also named "binary header block"
>
> as it is kinde header buts its binary and dlls needs thet header block -
> so its seen as header is stupid thing it needs to be something liek that in dlls, but on binary level, it also need to take some bytes - skipping it is kinda hard optimisation, but its needed for convenience of programmers and general information also decreasing amount of of errors etc

as far as i remembet in dlls there is also an option to skip list of names in dll
saving a space (say if dll kas few hunderds of symbols and each have on average 15 bytes it saves few kilobytes) and use calling by ordinals, i mean table
index - but fortunatelly most dlls dont use it afaik... as this would also be optimisation and obfuscation

thsi way i hope peopel would not skip binary header block too, having an option to delete header block and lefting only names or skiping both and lefting ordinals only

On 11/08/2023 16:39, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 11/08/2023 14:32, Scott Lurndal wrote:

>>> Perhaps it is time to simply stop responding to Bart when he continues
>>> to make such silly statements.
>>
>> What exactly is silly about it? Isn't that what is being said or not?
>
> Nobody has told you what you're allowed to have in your directories.
>

So I must have misunderstood these comments:

RH: Then you have too many unrelated things in that directory.

BC: That happens.

SL: No, it doesn't. Except, perhaps to you.

DB: Put the files of a project in a directory. Delete the junk.
[following a sarcastic remark]

Scott Lurndal <scott@slp53.sl.home> wrote:
> Nobody is telling Bart "exactly what they're allowed
> to have in their folders". That's just nonsense.

Agreed. It is total nonsense, because nobody has made
such claims.

This thread is so long that I may have lost track
already, but I suppose Bart does not want to
create subdirectories. Instead he has a single
directory, perhaps called "c" and all his not so
important small C programs get dumped there.

So his main directory contents probably look something
like this:

do-one-thing.c
do-another-thing.c
do-third-thing.c
[ and so on ]

I do not undestand why Bart cannot simply do:

mkdir do-one-thing do-another-thing do-third-thing
mv do-one-thing.c do-one-thing
mv do-another-thing.c do-another-thing
mv do-third-thing.c do-third-thing
[ and so on ]

So the directory hierarchy would be:

c/do-one-thing
c/do-another-thing
c/do-third-thing

and all the C programs would be contained in self-documenting
subdirectories.

For some unknown reason Bart wants to keep all the unrelated
C files in the one directory. Have I undestood this right?

br,
KK

piątek, 11 sierpnia 2023 o 16:47:48 UTC+2 fir napisał(a):
> piątek, 11 sierpnia 2023 o 16:28:55 UTC+2 fir napisał(a):
> > > piątek, 11 sierpnia 2023 o 02:30:18 UTC+2 Bart napisał(a):
> > > >
> > > > Actually, as written, that 'header' variable is exported also, so you
> > > > can directly access that, but I prefer to do it via a function.
> > > >
> the idea of keeping this header as a string is not totally idiotic but its
> not optimal (its c specific and thus sorta weird, but theorethically might be used as some additions of what things look like now - but sort athis way you could add whole source to dll as a string too)
>
i could also heep not only a source as a string but a whoel compiler inside, in todays times when dlls like about 1.5MB typically the full compiler + assembler would be in natural form 0.5 MB dll (full) but i think the compiler+assembler can be optimised for size to not take more than 200 KB still being in quality

Bart <bc@freeuk.com> writes:
>On 11/08/2023 16:39, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 11/08/2023 14:32, Scott Lurndal wrote:
>
>>>> Perhaps it is time to simply stop responding to Bart when he continues
>>>> to make such silly statements.
>>>
>>> What exactly is silly about it? Isn't that what is being said or not?
>>
>> Nobody has told you what you're allowed to have in your directories.
>>
>
>So I must have misunderstood these comments:

Yes, you did. As always.

>
>RH: Then you have too many unrelated things in that directory.
>
>BC: That happens.
>
>SL: No, it doesn't. Except, perhaps to you.
>
>DB: Put the files of a project in a directory. Delete the junk.

On 11/08/2023 17:53, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 11/08/2023 16:39, Scott Lurndal wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 11/08/2023 14:32, Scott Lurndal wrote:
>>
>>>>> Perhaps it is time to simply stop responding to Bart when he continues
>>>>> to make such silly statements.
>>>>
>>>> What exactly is silly about it? Isn't that what is being said or not?
>>>
>>> Nobody has told you what you're allowed to have in your directories.
>>>
>>
>> So I must have misunderstood these comments:
>
>
> Yes, you did. As always.

So what do they mean?

Can I still usefully do gcc -MM *.c if I ignore that advice?

>>
>> RH: Then you have too many unrelated things in that directory.
>>
>> BC: That happens.
>>
>> SL: No, it doesn't. Except, perhaps to you.
>>
>> DB: Put the files of a project in a directory. Delete the junk.

piątek, 11 sierpnia 2023 o 18:45:26 UTC+2 Kalevi Kolttonen napisał(a):
> Scott Lurndal <sc...@slp53.sl.home> wrote:
> > Nobody is telling Bart "exactly what they're allowed
> > to have in their folders". That's just nonsense.
> Agreed. It is total nonsense, because nobody has made
> such claims.
>
> This thread is so long that I may have lost track
> already, but I suppose Bart does not want to
> create subdirectories. Instead he has a single
> directory, perhaps called "c" and all his not so
> important small C programs get dumped there.
>
> So his main directory contents probably look something
> like this:
>
> do-one-thing.c
> do-another-thing.c
> do-third-thing.c
> [ and so on ]
>
> I do not undestand why Bart cannot simply do:
>
> mkdir do-one-thing do-another-thing do-third-thing
> mv do-one-thing.c do-one-thing
> mv do-another-thing.c do-another-thing
> mv do-third-thing.c do-third-thing
> [ and so on ]
>
> So the directory hierarchy would be:
>
> c/do-one-thing
> c/do-another-thing
> c/do-third-thing
>
> and all the C programs would be contained in self-documenting
> subdirectories.
>
> For some unknown reason Bart wants to keep all the unrelated
> C files in the one directory. Have I undestood this right?
>
> br,
> KK

bartc seem to be a fan of parctical simplicity and he is totally right in that aspect imo (not reading into that particular case as i got other things to do)
i hovever keep code in subdirectories, but even thiose subdirectories you could have tens..
this layer of managing source is overcomplicated as it should as it was already talked... im a fan of totakl commander and imo given.c source probably should compile to dll simply if you press enter on it, and compile to exe also if you press enter on it and it have "main" method

that should be a rule so no weird build system and trash

(this makes a problem you cant divide such c files on parts having large files
becouse if you would divide it couldnt compile unles having reference to its other parts (two-direction references, part should know the container) but there is
a way of dealing with this, else adding thsi reference or ignore or eventually
rename such included partswith other extension, or other way eventually also compile toi some .o partial format

On 11/08/2023 17:45, Kalevi Kolttonen wrote:
> Scott Lurndal <scott@slp53.sl.home> wrote:
>> Nobody is telling Bart "exactly what they're allowed
>> to have in their folders". That's just nonsense.
>
> Agreed. It is total nonsense, because nobody has made
> such claims.
>
> This thread is so long that I may have lost track
> already, but I suppose Bart does not want to
> create subdirectories. Instead he has a single
> directory, perhaps called "c" and all his not so
> important small C programs get dumped there.

Yes, exactly.

Actual applications get their own directory. But generally I don't use C
for those. I use my private language with a module system which can
discover all the modules of a project without needing to segregate
project-related files from anything else.

It mainly happens with C applications that have been downloaded, and
there, ones that have .c and .h files scattered over a dozen nested
directories are a complete PITA. Given that the supplied build process
on Windows rarely works so I end up doing the chasing around.

Of course, any C programs *I* supply are designed to be as easy to build
as `hello.c`. And on Windows that is achievable:

c:\qx>gcc qc.c -oqq
c:\qx>qq hello
Hello, World! 11-Aug-2023 18:24:54

qc.c is a 43Kloc C source file implementing an interpreter (transpiled
from non-C source code in 30+ modules).

On Linux, it would be something like this:

gcc qc.c -oqq -lm -ldl -fno-builtin
./qq hello

Now, please tell me what is the point of creating a subdirectory to
contain only the one file. Or indeed, what is the point of using 'make'
in this case.

All that's needed is a compiler, and the one source file; three as we
all know is a crowd.

> For some unknown reason Bart wants to keep all the unrelated
> C files in the one directory. Have I undestood this right?

I use folders to represent different projects. I don't take that
structuring to the extreme as many do. I've seen Github projects use a
dozen or two directories, each one has only one file, and the total,
initially imposing application turns out to be a 300-line toy program.

It's just 10 times harder to study, understand and build.

On 11/08/2023 18:15, Bart wrote:
> On 11/08/2023 17:53, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 11/08/2023 16:39, Scott Lurndal wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>> On 11/08/2023 14:32, Scott Lurndal wrote:
>>>
>>>>>> Perhaps it is time to simply stop responding to Bart when he
>>>>>> continues
>>>>>> to make such silly statements.
>>>>>
>>>>> What exactly is silly about it? Isn't that what is being said or not?
>>>>
>>>> Nobody has told you what you're allowed to have in your directories.
>>>>
>>>
>>> So I must have misunderstood these comments:
>>
>>
>> Yes, you did.  As always.
>
> So what do they mean?
>
> Can I still usefully do gcc -MM *.c if I ignore that advice?
>

BTW no one has commented on my own build scheme for C that I've
mentioned a few times.

So I have a program 'pidemo.c' which if I try and build it like this:

bcc pidemo

it reports some undefined functions. It needs a library which exists in
one or more extra .c files. Which ones? Well, why not let it discover
them for itself:

c:\c>bcc -auto pidemo
1 Compiling pidemo.c to pidemo.asm (Pass 1)
* 2 Compiling bignum.c to bignum.asm (Pass 2)
Assembling to pidemo.exe

So you can takes your 'gcc -MM *.c', which requires hygienically clean
directories, and shove it wherever the hell you like.

My demo was run inside that folder with 260 assorted 'junk' C files. Magic!

On 11/08/2023 14:32, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 11/08/2023 07:43, David Brown wrote:
>>> On 09/08/2023 16:07, Bart wrote:
>>>> On 09/08/2023 14:32, Richard Harnden wrote:
>>>> > On 09/08/2023 13:32, Bart wrote:
>>>> >> Yes, that is one reason that it is so complicated. You have to
>> define
>>>> >> set of dependences between modules (and you may need to do that
>>>> >> manually, so it can be error prone).
>>>> >
>>>> > $ gcc -MM *.c
>>>>
>>>> I have a small, 3-file project (one of Chris's) comprising files
>>>> cipher.c, sha2.c, hmac.c
>>>>
>>>> gcc -MM cipher.c outputs:
>>>>
>>>> cipher.o: cipher.c hmac.c sha2.h
>>>>
>>>> I need to do -MM cipher.c hmac.c sha2.c for it to show:
>>>>
>>>> cipher.o: cipher.c hmac.h sha2.h
>>>> hmac.o: hmac.c hmac.h sha2.h
>>>> sha2.o: sha2.c sha2.h
>>>>
>>>> So I had to tell it the C files. I can't do *.c, as there are 259
>>>> other .c files in the folder.
>>>>
>>>
>>> There's this wonderful organisation technique for files called
>>> "directories". They even exist in Windows.
>>>
>>> Put the files of a project in a directory. Delete the junk. Then you
>>> can find your files, and you can use "gcc -MM *.c". It even works if
>>> you have multiple different programs - it simply generates dependency
>>> information so you know which C files need re-compiled when headers are
>>> changed.
>>>
>>> But of course when someone gives you help or answers your questions,
>>> you'd rather complain more.
>>>
>>
>> So you're telling people exactly what they're allowed to have in their
>> folders and what they're not.
>
> Perhaps it is time to simply stop responding to Bart when he continues
> to make such silly statements.

I think he's being wrong on purpose. Or just for effect.

If I tar xvzf project-version.tgz,
I expect it to go into ./project-version

If I git clone project,
I expect it to go into ./project

To have everything end up in once directory takes effort.

On 2023-08-11, Scott Lurndal <scott@slp53.sl.home> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>On 2023-08-11, Spiros Bousbouras <spibou@gmail.com> wrote:
>>> On Thu, 10 Aug 2023 16:15:32 -0000 (UTC)
>>> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>>> What we could have is that an executable just dynamically links to
>>>> functions in these libraries, and the system automatically finds them at
>>>> load time, without the executable having to specify which libraries. >>>
>>> And how is your scheme different than how it already works in the Unix
>>> world ?
>>
>>How it differs is that the executable has to nominate the specific
>>libraries by indicating the library, which came in via the -l option,
>>and then look for specific symbols from specific libraries that it has
>>attached.
>>
>>Under the hood, the semantics is much like dlopen() of specific
>>liraries to obtain a handle and then doing dlsym(handle, "name")
>>to look for specific names from specific libs.
>>
>>Imagine it could specify just symbols, without specifying where
>>they come from; that's a big difference.
>
> Would this not require that no symbol be present in more than
> one library, i.e. that there is a single symbol namespace across the
> entire system?
>
> That would seem to be a non-starter.

I sort of addressed that in the parts that were snipped above.
We also have the problem that multiple versions of the same library
can exist (or multiple version nodes within the same library).

There would have to be some mechanism to bind the visible,
simple symbols to unique identities under the hood.

E.g the <stdio.h> header could have some magic so that
when you include it and call puts, a complex symbolic reference
is generated under the hood and imbued into the resulting
executable.

Insert other handwaving as necessary.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca