From Newsgroup: comp.lang.ada

On 2024-02-18 01:00, Lawrence D'Oliveiro wrote:

On Sat, 17 Feb 2024 14:36:46 +0100, DrPi wrote:

My usage is a bit special. The writing process writes a bunch of data in
a memory buffer then requests this buffer to be transferred to another
process by way of WM_COPYDATA.

I thought Windows had pipes.

It does,
We use it for out IPC in both Linux and Windows.
Works very well.
We use named pipes - where each process knows its name through
via env-var
At start they create a named pipe with that name

We use anonymous pipes for client communication
--
/Björn

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 2024-02-18 11:06, Simon Wright wrote:

OK if the participants all have the same endianness. We used XDR (and
the translation cost is nil if the host is big-endian, as PowerPCs are;
all the critical machines were PowerPC).

I always override stream attributes and use portable formats. E.g. some chained code for integers. Sign + exponent + normalized mantissa for
floats, again chained. That is all. There is no need in XDR, JSON, ASN.1
or other data representation mess. They are just worthless overhead.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Sun, 18 Feb 2024 11:06:16 +0100, Dmitry A. Kazakov wrote:

On 2024-02-18 01:00, Lawrence D'Oliveiro wrote:

On Sat, 17 Feb 2024 14:36:46 +0100, DrPi wrote:

My usage is a bit special. The writing process writes a bunch of data in >>> a memory buffer then requests this buffer to be transferred to another
process by way of WM_COPYDATA.

I thought Windows had pipes.

Yes it has, but very rarely used though much better designed than UNIX pipes.

So why don’t programmers use it?

In general Windows has much richer and better API regarding interprocess communication than Linux.

So why is it that Windows programs tend to avoid running multiple processes?

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Sun, 18 Feb 2024 12:36:54 +0100, Björn Lundin wrote:

On 2024-02-18 01:00, Lawrence D'Oliveiro wrote:

On Sat, 17 Feb 2024 14:36:46 +0100, DrPi wrote:

My usage is a bit special. The writing process writes a bunch of data in >>> a memory buffer then requests this buffer to be transferred to another
process by way of WM_COPYDATA.

I thought Windows had pipes.

It does,
We use it for out IPC in both Linux and Windows.
Works very well.

Why doesn’t the OP use them, then?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Sun, 18 Feb 2024 14:02:32 +0100, Dmitry A. Kazakov wrote:

There is no need in XDR, JSON, ASN.1
or other data representation mess. They are just worthless overhead.

Most languages nowadays have JSON libraries readily available. That is a
very easy format to use for passing structured data between processes.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 2024-02-18 21:58, Lawrence D'Oliveiro wrote:

On Sun, 18 Feb 2024 14:02:32 +0100, Dmitry A. Kazakov wrote:

There is no need in XDR, JSON, ASN.1
or other data representation mess. They are just worthless overhead.

Most languages nowadays have JSON libraries readily available. That is a
very easy format to use for passing structured data between processes.

It is easy to jump down the stairwell too. Though I would not recommend
such course of action...
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 2024-02-18 21:56, Lawrence D'Oliveiro wrote:

On Sun, 18 Feb 2024 11:06:16 +0100, Dmitry A. Kazakov wrote:

On 2024-02-18 01:00, Lawrence D'Oliveiro wrote:

On Sat, 17 Feb 2024 14:36:46 +0100, DrPi wrote:

My usage is a bit special. The writing process writes a bunch of data in >>>> a memory buffer then requests this buffer to be transferred to another >>>> process by way of WM_COPYDATA.

I thought Windows had pipes.

Yes it has, but very rarely used though much better designed than UNIX
pipes.

So why don’t programmers use it?

There is no need in that. At least initially UNIX had a distinct
philosophy. Its essence was that if a mouse had three buttons, there
must have been three processes, one for each button. Any so minuscule
task was split into even lesser subtasks connected through pipes. I
remember a C compiler that had 5 passes and took forever to compile hello-world. I wonder if anybody still actively uses that messy style of piping awk, grep, sed so typical for early UNIX users.

In general Windows has much richer and better API regarding interprocess
communication than Linux.

So why is it that Windows programs tend to avoid running multiple processes?

Because there is no need in multiple processes most of the time. Windows
has a different philosophy and services which preclude the process orgy
so characteristic to UNIX. For example, Windows has and collects many resources when a process dies. So you do not need a process monitoring
file locks, because there is no any. Instead you would deploy a global
mutex collected automatically. I do not say that Windows has few
processes. It is bloated beyond any reason.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Sun, 18 Feb 2024 23:10:07 +0100, Dmitry A. Kazakov wrote:

On 2024-02-18 21:58, Lawrence D'Oliveiro wrote:

On Sun, 18 Feb 2024 14:02:32 +0100, Dmitry A. Kazakov wrote:

There is no need in XDR, JSON, ASN.1 or other data representation
mess. They are just worthless overhead.

Most languages nowadays have JSON libraries readily available. That is
a very easy format to use for passing structured data between
processes.

It is easy to jump down the stairwell too. Though I would not recommend
such course of action...

Fun fact: you can prove any argument just by coming up with a suitably spurious analogy. For example, your argument is wrong, just by virtue of
the fact that cats land on their feet.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Sun, 18 Feb 2024 23:10:10 +0100, Dmitry A. Kazakov wrote:

On 2024-02-18 21:56, Lawrence D'Oliveiro wrote:

On Sun, 18 Feb 2024 11:06:16 +0100, Dmitry A. Kazakov wrote:

On 2024-02-18 01:00, Lawrence D'Oliveiro wrote:

I thought Windows had pipes.

Yes it has, but very rarely used though much better designed than UNIX
pipes.

So why don’t programmers use it?

There is no need in that.

It would be so much simpler to use the OS-provided facility, than having
to resort to this complicated library which is trying to wrap a stream interface around shared-memory buffers.

At least, it would be in POSIX. No doubt the Windows API makes it more complicated ...

In general Windows has much richer and better API regarding
interprocess communication than Linux.

So why is it that Windows programs tend to avoid running multiple
processes?

Because there is no need in multiple processes most of the time. Windows
has a different philosophy and services which preclude the process orgy
so characteristic to UNIX. For example, Windows has and collects many resources when a process dies. So you do not need a process monitoring
file locks, because there is no any.

Windows is the one that keeps files locked, *nix systems typically do not.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 2024-02-19 00:44, Lawrence D'Oliveiro wrote:

On Sun, 18 Feb 2024 23:10:07 +0100, Dmitry A. Kazakov wrote:

On 2024-02-18 21:58, Lawrence D'Oliveiro wrote:

On Sun, 18 Feb 2024 14:02:32 +0100, Dmitry A. Kazakov wrote:

There is no need in XDR, JSON, ASN.1 or other data representation
mess. They are just worthless overhead.

Most languages nowadays have JSON libraries readily available. That is
a very easy format to use for passing structured data between
processes.

It is easy to jump down the stairwell too. Though I would not recommend
such course of action...

Fun fact: you can prove any argument just by coming up with a suitably spurious analogy. For example, your argument is wrong, just by virtue of
the fact that cats land on their feet.

No. There is no argument as you provided none. You did not say why JSON
is needed. You said there are libraries. Yes, there are, the Simple
Components provides a JSON parser:

http://www.dmitry-kazakov.de/ada/components.htm#13.10

So what? The purpose is support of legacy protocols and interfacing
other languages. For an Ada program JSON has no use.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 2024-02-19 00:47, Lawrence D'Oliveiro wrote:

On Sun, 18 Feb 2024 23:10:10 +0100, Dmitry A. Kazakov wrote:

In general Windows has much richer and better API regarding
interprocess communication than Linux.

So why is it that Windows programs tend to avoid running multiple
processes?

Because there is no need in multiple processes most of the time. Windows
has a different philosophy and services which preclude the process orgy
so characteristic to UNIX. For example, Windows has and collects many
resources when a process dies. So you do not need a process monitoring
file locks, because there is no any.

Windows is the one that keeps files locked, *nix systems typically do not.

Not Windows, It is the applications that have GUI died and files still
open. If you want UNIX behavior open all files for shared I/O.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 2024-02-18 21:56, Lawrence D'Oliveiro wrote:

So why is it that Windows programs tend to avoid running multiple processes?

Perhaps on win create_process is much heavier than threading compared to
unix. My suspicion only though.


MS SQL-server use it for IPC.
--
/Björn

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 2024-02-19 10:24, Björn Lundin wrote:

On 2024-02-18 21:56, Lawrence D'Oliveiro wrote:

So why is it that Windows programs tend to avoid running multiple
processes?

Perhaps on win create_process is much heavier than threading compared to unix. My suspicion only though.

MS SQL-server use it for IPC.

Firefox starts a process for each tab! The next stop is placing each one
in a docker ... and, of course, HTTP for communication...

The Holly Grail of modern computing is to use each available bit and
each CPU tick for doing exactly nothing! (:-))
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 2024-02-18 21:57, Lawrence D'Oliveiro wrote:

On Sun, 18 Feb 2024 12:36:54 +0100, Björn Lundin wrote:

On 2024-02-18 01:00, Lawrence D'Oliveiro wrote:

On Sat, 17 Feb 2024 14:36:46 +0100, DrPi wrote:

My usage is a bit special. The writing process writes a bunch of data in >>>> a memory buffer then requests this buffer to be transferred to another >>>> process by way of WM_COPYDATA.

I thought Windows had pipes.

It does,
We use it for out IPC in both Linux and Windows.
Works very well.

Why doesn’t the OP use them, then?

I have no idea,

You can see them with
powershell -command [System.IO.Directory]::GetFiles(\"\\.\pipe\")
--
/Björn

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 19/02/2024 14:59, Björn Lundin wrote:

On 2024-02-18 21:57, Lawrence D'Oliveiro wrote:

On Sun, 18 Feb 2024 12:36:54 +0100, Björn Lundin wrote:

On 2024-02-18 01:00, Lawrence D'Oliveiro wrote:

On Sat, 17 Feb 2024 14:36:46 +0100, DrPi wrote:

My usage is a bit special. The writing process writes a bunch of
data in
a memory buffer then requests this buffer to be transferred to another >>>>> process by way of WM_COPYDATA.

I thought Windows had pipes.

It does,
We use it for out IPC in both Linux and Windows.
Works very well.

Why doesn’t the OP use them, then?

I have no idea,

You can see them with
powershell -command [System.IO.Directory]::GetFiles(\"\\.\pipe\")

Don't feed the troll
--
Chris

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Mon, 19 Feb 2024 09:32:42 +0100, Dmitry A. Kazakov wrote:

You did not say why JSON is needed.

Because it’s such a convenient meta-format, and its text basis helps with debugging. Its popularity aids interoperability with code bases in other languages, support by existing tools, and so on and so on.

If you didn’t know all that, you’ve been living under a coconut shell, as we say in the old country ...
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Mon, 19 Feb 2024 10:46:27 +0100, Dmitry A. Kazakov wrote:

Firefox starts a process for each tab!

All the web browsers do nowadays. That’s the only way to maximize
isolation of potentially hostile websites.

Does that hurt performance on Windows more than it does on Linux?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Mon, 19 Feb 2024 09:39:45 +0100, Dmitry A. Kazakov wrote:

Not Windows, It is the applications that have GUI died and files still
open.

Files do not stay open after the processes that have them open terminate
under Linux.

Windows does seem to cling to the old VMS model of keeping things locked
down, no matter how much trouble that causes ...

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 2024-02-20 01:41, Lawrence D'Oliveiro wrote:

On Mon, 19 Feb 2024 09:32:42 +0100, Dmitry A. Kazakov wrote:

You did not say why JSON is needed.

Because it’s such a convenient meta-format,

Meta of what? How is it convenient for streaming objects? Begin with
access type. Proceed with time stamps.

and its text basis helps with
debugging.

There is nothing to debug in implementation of stream attributes. Nor it
is helpful to debug communication logic issues because the format is
*data representation* one. It represents *data*, not objects, not
states. All vital information about the logic and state is not there. It
is in the context. This is the main reason why *all* data representation formats are useless garbage even when binary.

Text basis helps to produce 100 to 1 overhead in payload which directly translates into latency, network and CPU load, storage space, packet overflows, variable-length packets where it should have been fixed,
chunked transfers, dynamic memory allocation and mess that makes a
64-core CPU to perform like an i286.

It is absolutely useless, you cannot read, browse, search real-life
gigabytes long communication logs without customized tools.

Driving a car, heating the house, browsing Internet I do not care about
the logs. The damn thing must work.

Its popularity aids interoperability with code bases in other
languages,

A requirement does not aid anything. It is just a requirement. JSON
would not aid you in dealing with X.509 certificates. They are in ASN.1.

support by existing tools, and so on and so on.

Lemming's argument. Everybody's jumping I am jumping too.

If you didn’t know all that, you’ve been living under a coconut shell, as we say in the old country ...

I am pretty much aware of data representation formats. Moreover, as you
may have noticed I implemented lots of them. Not because it is fun, but because communication protocols is my job.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Tue, 20 Feb 2024 09:55:30 +0100, Dmitry A. Kazakov wrote:

On 2024-02-20 01:41, Lawrence D'Oliveiro wrote:

On Mon, 19 Feb 2024 09:32:42 +0100, Dmitry A. Kazakov wrote:

You did not say why JSON is needed.

Because it’s such a convenient meta-format,

Meta of what?

You don’t understand the concept of “meta-formats”? Maybe you prefer “format family” or “format superclass”. Does that help make things clearer? It is something easily specialized to become an application-
specific format, with less effort than creating the specific format from scratch.

An earlier example is XML. Also IFF on the Commodore-Amiga, from the
1980s.

Does that help?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 2024-02-20 20:37, Lawrence D'Oliveiro wrote:

On Tue, 20 Feb 2024 09:55:30 +0100, Dmitry A. Kazakov wrote:

On 2024-02-20 01:41, Lawrence D'Oliveiro wrote:

On Mon, 19 Feb 2024 09:32:42 +0100, Dmitry A. Kazakov wrote:

You did not say why JSON is needed.

Because it’s such a convenient meta-format,

Meta of what?

You don’t understand the concept of “meta-formats”?

Nope. The meaning of the word "meta" is having an object made out of
entities operating some other objects. E.g. meta-language vs object
language, metadata (data about data), logical inference vs logical
predicates.

Meta-format must represent formats rather than data. JSON is not that
thing. It is just a [bad] data representation format.

Maybe you prefer
“format family” or “format superclass”. Does that help make things clearer?

No. I don't care about classifications of poorly designed formats. JSON
is not a format family and a family of formats is not a meta-format.

It is something easily specialized to become an application-
specific format, with less effort than creating the specific format from scratch.

It is always the same format. JSON's inability to describe any
constraints does not make it *specialized*. The burden of checks is
moved to the application, the format is same. All such stupid thinks
only add overhead, additional points of failure and make designing
reasonable recovery logic impossible.

[ It keeps me wonder. The coding theory exists more than hundred years.
People are inventing square wheels made of cabbage leaves instead of
taking some short course... ]

An earlier example is XML. Also IFF on the Commodore-Amiga, from the
1980s.

You can go back as far as to Hollerith specifications... (:-))
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Tue, 20 Feb 2024 21:45:46 +0100, Dmitry A. Kazakov wrote:

The burden of checks is moved to the application, the format is same.

Isn’t that how all formats are implemented?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 2024-02-20 23:32, Lawrence D'Oliveiro wrote:

On Tue, 20 Feb 2024 21:45:46 +0100, Dmitry A. Kazakov wrote:

The burden of checks is moved to the application, the format is same.

Isn’t that how all formats are implemented?

There is a difference in semantics of checks. The checks below and above
the OSI level of the format are outside the scope of format. One thing
is to check a string against a database of client names and another to
check its length or validity of UTF-8 encoding.

Do you check ASCII characters? No, because they are densely encoded. If error-correction etc is needed it is added below.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Wed, 21 Feb 2024 08:43:13 +0100, Dmitry A. Kazakov wrote:

On 2024-02-20 23:32, Lawrence D'Oliveiro wrote:

On Tue, 20 Feb 2024 21:45:46 +0100, Dmitry A. Kazakov wrote:

The burden of checks is moved to the application, the format is same.

Isn’t that how all formats are implemented?

There is a difference in semantics of checks.

Think of a stream of bytes as the ultimate meta-format. All extra layout
on top of that is “moved to the application”, as you say. But it just takes more work starting from such a low level; starting from a higher
point, like JSON, reduces that work.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 2024-02-21 20:44, Lawrence D'Oliveiro wrote:

On Wed, 21 Feb 2024 08:43:13 +0100, Dmitry A. Kazakov wrote:

On 2024-02-20 23:32, Lawrence D'Oliveiro wrote:

On Tue, 20 Feb 2024 21:45:46 +0100, Dmitry A. Kazakov wrote:

The burden of checks is moved to the application, the format is same.

Isn’t that how all formats are implemented?

There is a difference in semantics of checks.

Think of a stream of bytes as the ultimate meta-format.

Of course not. It is not a format it is a transport layer.
[ BTW, it is not bytes, it is octets actually ]

All extra layout
on top of that is “moved to the application”, as you say. But it just takes more work starting from such a low level; starting from a higher
point, like JSON, reduces that work.

Not at all. Implementation of serialization/deserialization on top of
JSON is exponentially harder than on top of an octet stream. Alone specification of handling missing, superfluous, wrongly typed fields is
a huge work before a single line of code is written. Furthermore,

1. JSON is unable to represent basic data, like time stamps. These must
be encoded as strings accompanied with parsing and checks. Compare that
with encoding as octets.

2. JSON is not extensible in any sense. You cannot add new syntax
elements to JSON.

3. There is no any abstraction by which you could reuse JSON encoding.
I.e. this element is like that element. Repeat this by number of times specified by that.

4. Nor JSON supports extensions objects. Compare it with Ada's extension aggregates:

http://ada-auth.org/standards/rm12_w_tc1/html/RM-4-3-2.html#I2535

5. JSON cannot specify constraints, like value ranges, precision,
variable record fields, array bounds.

6. JSON has no means of reflection. Talking about "metas", there is no
way to convey a JSON description of an object (rather than instance =
data) to another node. Both sides must know each other prior to
communication. I don't say that dynamic binding is a good idea for communication for for tall claims made and all immense overhead involved...

JSON is an extremely crude primitive hobbyish idea a lazy undergraduate
in horticulture might have about a communication protocol... (:-))
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Thu, 22 Feb 2024 09:54:07 +0100, Dmitry A. Kazakov wrote:

On 2024-02-21 20:44, Lawrence D'Oliveiro wrote:

Think of a stream of bytes as the ultimate meta-format.

Of course not. It is not a format it is a transport layer.
[ BTW, it is not bytes, it is octets actually ]

We normally work with bytes here. And your “transport layer” is what gets the bytes from one place to another. So my point still stands: the
bytestream is the ultimate lowest-level meta-format.

Implementation of serialization/deserialization on top of
JSON is exponentially harder than on top of an octet stream.

We already have libraries for doing that, at least for byte streams.
That’s why it’s so much easier to build on top of those, rather than going back to bytes every time.

As for octets--I guess you’re on your own.

Alone specification of handling missing, superfluous, wrongly typed
fields is a huge work before a single line of code is written.

All the code for that already exists, in most if not all common languages.

5. JSON cannot specify constraints, like value ranges, precision,
variable record fields, array bounds.

Those are specific to the format you are building on top of the meta-
format.

6. JSON has no means of reflection.

Again, this is specific to the format. For an example of how you can do
this, see Varlink <https://varlink.org/>.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-296040725-1711364112=:4107996
Content-Type: text/plain; CHARSET=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <3fd1f87c-3552-ff1b-c414-f5a19e9f9e7a@insomnia247.nl>

Lawrence D'Oliveiro wrote:
"On Thu, 22 Feb 2024 09:54:07 +0100, Dmitry A. Kazakov wrote:
[. . .]

We normally work with bytes here. [. . .]
[. . .] So my point still stands: the
bytestream is the ultimate lowest-level meta-format."

Dear Mister Lawrence D'Oliveiro,

Bit and std_ulogic and electron are at lower levels.

"> Alone specification of handling missing, superfluous, wrongly typed

fields is a huge work before a single line of code is written.

All the code for that already exists, in most if not all common=20
languages."

BNF is better than all common languages.

With best regards.
Niocl=C3=A1s=C3=A1n Caile=C3=A1n Glost=C3=A9ir --8323329-296040725-1711364112=:4107996--
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Mon, 25 Mar 2024 12:07:47 +0100, Nioclásán Caileán Glostéir wrote:

BNF is better than all common languages.

Go look up “Van Wijngaarden grammars”.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

Dmitry A. Kazakov wrote:

Firefox starts a process for each tab!

All the web browsers do nowadays. That’s the only way to maximize >isolation of potentially hostile websites.

That sand boxing is because they're written in C. If they were written in
Ada then the original design would be preferrable that uses far less
memory.
--
Regards, Kc
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Tue, 2 Apr 2024 00:21:34 -0000 (UTC), Kevin Chadwick wrote:

Dmitry A. Kazakov wrote:

Firefox starts a process for each tab!

All the web browsers do nowadays. That’s the only way to maximize >>isolation of potentially hostile websites.

That sand boxing is because they're written in C. If they were written
in Ada then the original design would be preferrable that uses far less memory.

I wouldn’t use one characteristic as an excuse for not doing the other
thing as well.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

That sand boxing is because they're written in C. If they were written
in Ada then the original design would be preferrable that uses far less
memory.

I wouldn’t use one characteristic as an excuse for not doing the other >thing as well.

??

Are you just trolling? The js engine would need to be re-written in Ada as
well.
--
Regards, Kc
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-897235389-1712173438=:987682
Content-Type: text/plain; format=flowed; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE

Dear all,

He is not a troll.

With kind regards.
P=C3=B3l Niocl=C3=A1=C5=BF Caile=C3=A1n Glo=C5=BFt=C3=A9ir --8323329-897235389-1712173438=:987682--
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 03/04/2024 20:43, Pól Niocláſ Caileán Gloſtéir wrote:

Dear all,

He is not a troll.

With kind regards.
Pól Niocláſ Caileán Gloſtéir

Really?
--
Chris

--- Synchronet 3.20a-Linux NewsLink 1.114