On 08/03/2024 11:57, Michael S wrote:
> On Fri, 8 Mar 2024 08:25:13 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 07/03/2024 17:35, Kaz Kylheku wrote:
>>> On 2024-03-07, David Brown <david.brown@hesbynett.no> wrote:
>>>> On 06/03/2024 23:00, Michael S wrote:
>>>>> On Wed, 6 Mar 2024 12:28:59 +0000
>>>>> bart <bc@freeuk.com> wrote:
>>>>>
>>>>>>
>>>>>> "Rust uses a relatively unique memory management approach that
>>>>>> incorporates the idea of memory “ownership”. Basically, Rust
>>>>>> keeps track of who can read and write to memory. It knows when
>>>>>> the program is using memory and immediately frees the memory
>>>>>> once it is no longer needed. It enforces memory rules at compile
>>>>>> time, making it virtually impossible to have runtime memory
>>>>>> bugs.⁴ You do not need to manually keep track of memory. The
>>>>>> compiler takes care of it."
>>>>>>
>>>>>> This suggests the language automatically takes care of this.
>>>>>
>>>>> Takes care of what?
>>>>> AFAIK, heap fragmentation is as bad problem in Rust as it is in
>>>>> C/Pascal/Ada etc... In this aspect Rust is clearly inferior to
>>>>> GC-based languages like Java, C# or Go.
>>>>>
>>>> Garbage collection does not stop heap fragmentation. GC does, I
>>>> suppose, mean that you need much more memory and bigger heaps in
>>>> proportion to the amount of memory you actually need in the
>>>> program at any given time, and having larger heaps reduces
>>>> fragmentation (or at least reduces the consequences of it).
>>>
>>> Copying garbage collectors literally stop fragmentation.
>>
>> Yes, but garbage collectors that could be useable for C, C++, or
>> other efficient compiled languages are not "copying" garbage
>> collectors.
>>
>
> Go, C# and Java are all efficient compiled languages. For Go it was
> actually a major goal.

C# and Java are, AFAIUI, managed languages - they are byte-compiled and
run on a VM. (JIT compilation to machine code can be used for
acceleration, but that does not change the principles.) I don't know
about Go.

>
>>> Reachable
>>> objects are identified and moved to a memory partition where they
>>> are now adjacent. The vacated memory partition is then efficiently
>>> used to bump-allocate new objects.
>>>
>>
>> I think if you have a system with enough memory that copying garbage
>> collection (or other kinds of heap compaction during GC) is a
>> reasonable option, then it's unlikely that heap fragmentation is a
>> big problem in the first place. And you won't be running on a small
>> embedded system.
>>
>
> You sound like arguing for sake of arguing.

I am just trying to be clear about things. Different types of system,
and different types of task, have different challenges and different
solutions. (This seems obvious, but people often think they have "the"
solution to a particular issue.) In particular, in small embedded
systems with limited ram and no MMU, if you use dynamic memory of any
kind, then heap fragmentation is a serious risk. And a heap-compacting
garbage collection will not mitigate that risk.

There are a lot of GC algorithms, each with their pros and cons, and the
kind of languages and tasks for which they are suitable. If you have a
GC algorithm that works by copying all live data (then scraping
everything left over), then heap compaction is a natural byproduct.

But I think it is rare that heap compaction is an appropriate goal in
itself - it is a costly operation. It invalidates all pointers, which
means a lot of overhead and extra care in languages where pointers are
likely to be cached in registers or local variables on the stack. And
it will be tough on the cache as everything has to be copied and moved.
That pretty much rules it out for efficient compiled languages, at least
for the majority of their objects, and leaves it in the domain of
languages that can accept the performance hit.

> Of course, heap fragmentation is relatively rare problem. But when you
> process 100s of 1000s of requests of significantly varying sizes for
> weeks without interruption then rare things happen with high
> probability :(

There are all sorts of techniques usable to optimise such systems.
Allocation pools for different sized blocks would be a typical strategy.

> In case of this particular Discord service, they appear to
> have a benefit of size of requests not varying significantly, so
> absence of heap compaction is not a major defect.
> BTW, I'd like to know if 3 years later they still have their Rust
> solution running.
>

On Fri, 8 Mar 2024 15:32:22 +0100
David Brown <david.brown@hesbynett.no> wrote:

> On 08/03/2024 11:57, Michael S wrote:
> > On Fri, 8 Mar 2024 08:25:13 +0100
> > David Brown <david.brown@hesbynett.no> wrote:
> >
> >> On 07/03/2024 17:35, Kaz Kylheku wrote:
> >>> On 2024-03-07, David Brown <david.brown@hesbynett.no> wrote:
> >>>> On 06/03/2024 23:00, Michael S wrote:
> >>>>> On Wed, 6 Mar 2024 12:28:59 +0000
> >>>>> bart <bc@freeuk.com> wrote:
> >>>>>
> >>>>>>
> >>>>>> "Rust uses a relatively unique memory management approach that
> >>>>>> incorporates the idea of memory “ownership”. Basically, Rust
> >>>>>> keeps track of who can read and write to memory. It knows when
> >>>>>> the program is using memory and immediately frees the memory
> >>>>>> once it is no longer needed. It enforces memory rules at
> >>>>>> compile time, making it virtually impossible to have runtime
> >>>>>> memory bugs.⁴ You do not need to manually keep track of
> >>>>>> memory. The compiler takes care of it."
> >>>>>>
> >>>>>> This suggests the language automatically takes care of this.
> >>>>>
> >>>>> Takes care of what?
> >>>>> AFAIK, heap fragmentation is as bad problem in Rust as it is in
> >>>>> C/Pascal/Ada etc... In this aspect Rust is clearly inferior to
> >>>>> GC-based languages like Java, C# or Go.
> >>>>>
> >>>> Garbage collection does not stop heap fragmentation. GC does, I
> >>>> suppose, mean that you need much more memory and bigger heaps in
> >>>> proportion to the amount of memory you actually need in the
> >>>> program at any given time, and having larger heaps reduces
> >>>> fragmentation (or at least reduces the consequences of it).
> >>>
> >>> Copying garbage collectors literally stop fragmentation.
> >>
> >> Yes, but garbage collectors that could be useable for C, C++, or
> >> other efficient compiled languages are not "copying" garbage
> >> collectors.
> >>
> >
> > Go, C# and Java are all efficient compiled languages. For Go it was
> > actually a major goal.
>
> C# and Java are, AFAIUI, managed languages - they are byte-compiled
> and run on a VM. (JIT compilation to machine code can be used for
> acceleration, but that does not change the principles.) I don't know
> about Go.
>

C# was Jitted originally and was even interpretted on on very small
implementation that don't seem to be supported any longer. Today it is
mostly AoTed, which in simpler language means "compiled". There are
options in dev tools whhether to compile to native code on to
platform-independent. I would think that most people compile to native.

Java-on-Android which, I would guess, is majority on Java written in
the world, is like 95% AoTed + 5% JITtted. Is used to be 100% AoTed in
few versions of Android, but by now JIT is reintroduced as an option,
not for portability, but for profile-guided optimization
opportinities it allows. If I am not mistaken, direct interpretaions of
Davlik non-byte-code was never supported on Android.

Java-outside-Android? I don't know what is current stated. Would think
that Oracle's JVMs intetended for desktop/la[top/server are also
either JITted or AoTed, not interpreted.

Go is compiled to native, most often via LLVM, but there exists gcc
option as well.

On 08/03/2024 14:07, David Brown wrote:
> On 08/03/2024 13:41, Paavo Helde wrote:
>> 07.03.2024 17:36 David Brown kirjutas:
>>>
>>> CPython does use garbage collection, as far as I know.
>>>
>>
>> AFAIK CPython uses reference counting, i.e. basically the same as C++
>> std::shared_ptr (except that it does not need to be thread-safe).
>
> Yes, that is my understanding too.  (I could be wrong here, so don't
> rely on anything I write!)  But the way it is used is still a type of
> garbage collection.  When an object no longer has any "live" references,
> it is put in a list, and on the next GC it will get cleared up (and call
> the asynchronous destructor, __del__, for the object).

Is that how CPython works? I can't quite see the point of saving up all
the deallocations so that they are all done as a batch. It's extra
overhead, and will cause those latency spikes that was the problem here.

In my own reference count scheme, when the count reaches zero, the
memory is freed immediately.

I also tend to have most allocations being of either 16 or 32 bytes, so
reuse is easy. It is only individual data items (a long string or long
array) that might have an arbitrary length that needs to be in
contiguous memory.

Most strings however have an average length of well below 16 characters
in my programs, so use a 16-byte allocation.

I don't know the allocation pattern in that Discard app, but Michael S
suggested they might not be lots of arbitrary-size objects.

On 08/03/2024 16:15, bart wrote:
> On 08/03/2024 14:07, David Brown wrote:
>> On 08/03/2024 13:41, Paavo Helde wrote:
>>> 07.03.2024 17:36 David Brown kirjutas:
>>>>
>>>> CPython does use garbage collection, as far as I know.
>>>>
>>>
>>> AFAIK CPython uses reference counting, i.e. basically the same as C++
>>> std::shared_ptr (except that it does not need to be thread-safe).
>>
>> Yes, that is my understanding too.  (I could be wrong here, so don't
>> rely on anything I write!)  But the way it is used is still a type of
>> garbage collection.  When an object no longer has any "live"
>> references, it is put in a list, and on the next GC it will get
>> cleared up (and call the asynchronous destructor, __del__, for the
>> object).
>
> Is that how CPython works? I can't quite see the point of saving up all
> the deallocations so that they are all done as a batch. It's extra
> overhead, and will cause those latency spikes that was the problem here.

I believe the GC runs are done very regularly (if there is something in
the clean-up list), so there is not much build-up and not much extra
latency.

>
> In my own reference count scheme, when the count reaches zero, the
> memory is freed immediately.

That's synchronous deallocation. It's a perfectly good strategy, of
course. There are pros and cons of both methods.

>
> I also tend to have most allocations being of either 16 or 32 bytes, so
> reuse is easy. It is only individual data items (a long string or long
> array) that might have an arbitrary length that needs to be in
> contiguous memory.
>
> Most strings however have an average length of well below 16 characters
> in my programs, so use a 16-byte allocation.
>
> I don't know the allocation pattern in that Discard app, but Michael S
> suggested they might not be lots of arbitrary-size objects.
>

On 03/08/2024 06:07 AM, David Brown wrote:
> On 08/03/2024 13:41, Paavo Helde wrote:
>> 07.03.2024 17:36 David Brown kirjutas:
>>>
>>> CPython does use garbage collection, as far as I know.
>>>
>>
>> AFAIK CPython uses reference counting, i.e. basically the same as C++
>> std::shared_ptr (except that it does not need to be thread-safe).
>
> Yes, that is my understanding too. (I could be wrong here, so don't
> rely on anything I write!) But the way it is used is still a type of
> garbage collection. When an object no longer has any "live" references,
> it is put in a list, and on the next GC it will get cleared up (and call
> the asynchronous destructor, __del__, for the object).
>
> A similar method is sometimes used in C++ for objects that are
> time-consuming to destruct. You have a "tidy up later" container that
> holds shared pointers. Each time you make a new object that will have
> asynchronous destruction, you use a shared_ptr for the access and put a
> copy of that pointer in the tidy-up container. A low priority
> background thread checks this list on occasion - any pointers with only
> one reference can be cleared up in the context of this separate thread.
>
>>
>> With reference counting one only knows how many pointers there are to
>> a given heap block, but not where they are, so heap compaction would
>> not be straightforward.
>>
>> Python also has zillions of extensions written in C or C++ (all of AI
>> related work for example), so having e.g. heap compaction of Python
>> objects only might not be worth of it.
>>
>

Wondering about mark-and-sweep or abstractly
whatever means that detects references, vis-a-vis,
reference counting and reference registration and
this kind of thing, sort of is for making the automatic
cleanup along the lines of stack-unwinding.

Like how C++ works on stack objects, ....

Then, that makes de-allocation part of the routine,
and adds reference-counts to objects, but it would
be pretty safe, ..., and the GC would never interrupt
the entire runtime.

One might figure that any time an lvalue is assigned
an rvalue, the rvalue's refcount increments and any
previous assigned revalue's refcount decrements,
then anything that goes out of scope it's rvalue
is assigned null, its un-assigned rvalue refcount decrements,
that any refcount decremented to zero results deletion.

Isn't that smart-pointers?

https://en.wikipedia.org/wiki/Smart_pointer

Maybe the big code cop should say "you should use smart pointers".

I think smart pointers should usually be the way of things,
any kind of pointer, then with, you know, detach() or what,
manual management.

I suppose it's nice that syntactic sugar just does that,
or, that the runtime makes a best effort sort of
inference, while, it would be nice if when an object's
purpose is fulfilled, that it can be canned and it results
freeing itself.

Static analysis and "safe programming"
is an option in any deterministic language, ...,
given "defined behavior" of the runtime, of course.

How about "ban USB and PXE" and
"proxy-defeating DNS", "read-only
runtime", "computer literacy suprise quiz".

The idea of memory pools and freelists and
arenas and slabs and dedicated allocations
for objects of types and the declaration at
definition-time of the expected lifetime and
ownership of objects, gets into a lot of ways
to have both efficiency and dedication by design.

Shadow stack, NX bit, shared register protection,
Orange Book, journaling, link-layer?

A usual behavior of Java crashing is leaving
the entire heap in a heap-dump file, ....

These days a usual sort of approach is, like,
the old "trust but verify", static analysis and
all, figuring that type-safety first is the greatest
possible boon to correctness, then that
memory-management would better be a
sort of "if you could just explicitly close your
resources when you're done then maybe
have a mark-and-sweep on the side, and
mark lifetime resources as so, then anything
left would be waste".

I'm a big fan of C/C++ coders and it's nice
to know about Java which I think is great
and I mostly think in it, vis-a-vis,
Go and JavaScript and similar event loops,
like Windows, or the Pythonic or something like
that, there's something to be said for that
Haskell is probably cooler than me, these
days I'm looking at the language specs and
the opcode instructions as from assembler
languages with regards to "modular modules
with well-defined modules and modularity".

Figuring "modular modules" and "scope the globals".

On 3/6/2024 2:18 PM, Chris M. Thomasson wrote:
> On 3/6/2024 2:43 AM, David Brown wrote:
[...]

This is a fun one:

// pseudo code...
_______________________
node*
node_pop()
{ // try per-thread lifo

// try shared distributed lifo

// try global region

// if all of those failed, return nullptr
}

void
node_push(
node* n
) {
// if n came from our per-thread, try to push it into it...

// if n came from another thread, try to push it into its thread...

// if all of those failed, push into shared distributed lifo
} _______________________

The fun part is this scheme can be realized as long as a node is at
least the size of a pointer. That is the required overhead wrt the size
of a node.

On 03/06/2024 12:13 PM, David Brown wrote:
> On 06/03/2024 20:50, Kaz Kylheku wrote:
>> On 2024-03-06, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>> On 3/6/24 09:18, Michael S wrote:
>>>> On Wed, 6 Mar 2024 13:50:16 +0000
>>>> bart <bc@freeuk.com> wrote:
>>> ...
>>>>> Whoever wrote this short Wikipedia article on it got confused too as
>>>>> it uses both Ada and ADA:
>>>>>
>>>>> https://simple.wikipedia.org/wiki/Ada_(programming_language)
>>>>>
>>>>> (The example program also includes 'Ada' as some package name. Since
>>>>> it is case-insensitive, 'ADA' would also work.)
>>>>>
>>>>
>>>> Your link is to "simple Wikipedia". I don't know what it is
>>>> exactly, but it does not appear as authoritative as real Wikipedia
>>>
>>> Notice that in your following link, "en" appears at the beginning to
>>> indicate the use of English. "simple" at the beginning of the above link
>>> serves the same purpose. "Simple English" is it's own language, closely
>>> related to standard English.
>>
>> Where is Simple English spoken? Is there some geographic area where
>> native speakers concentrate?
>>
>
> It is meant to be simpler text, written in simpler language. The target
> audience will include younger people, people with dyslexia or other
> reading difficulties, learners of English, people with lower levels of
> education, people with limited intelligence or learning impediments, or
> simply people whose eyes glaze over when faced with long texts on the
> main Wikipedia pages.
>
>

Yet, why?

There's "Simplified Technical English", which is a same
sort of idea, with the idea that manuals and instructions
be clear and unambiguous.

https://en.wikipedia.org/wiki/Simplified_Technical_English

Heh, it's like in the old days, when people would get
manuals, and be amused as it were by the expression.

What I'd like to know about is who keeps dialing
the "harmonization" efforts, which really must
give grouse to the "harmonisation" spellers,
when good old-fashioned words "spelt" their own way,
which of course is archaic "spelled".

It reminds me of "Math Blaster" and "Typing Games",
vis-a-vis, "the spelling bee", and for that matter,
of course, weekly spelling quizzes all through
elementary school.

I'm so old the only games we had were how to
compute and how to spell.

And Tooth Invaders. Just kidding I had 50+ floppies
for my Commodore64. Like GI Joe and Beachhead II.

But we didn't get promoted in school if we
didn't pass our spelling tests.

(We couldn't even have dangling prepositions
or sentence fragments like the above.)

We had a class in school we couldn't even pass
until we could type thirty words a minute.

The Simplified Technical English though is a good idea,
it's used in technical manuals and instructions, widely.

Really, whever harmonization dials away a word,
I'm like, hey, I'm using that word.

There's something to be said for a, "source parser",
the idea being a, multi-pass parser of sorts, with
any number of, forms, so that it results, parsing
languages sort of opportunistically, and results,
sort of lifting, sections, of source, into regions
of syntax, so that as syntaxes get all commingled,
that all the syntax and grammar definitions get piled
together, where it sort of results then for comments
and quoting, and, usual ideas of brackets, and comma,
for joiners and separators and groupers and splitters,
observing mostly usually the parenthetical and indentation,
for all sorts of languages, into, a pretty common sort of
form.

So, what is there, "Simplified Compilation Source",
basically reflecting, "if it's source somehow it
parses, if being ambiguous among languages then
in editions of each or according to the source
locale", these kinds of things....

For a long time I've been thinking about "modular
and composable parsers", with mostly the usual
goal of relating productions in grammar to source
locations, that one figures it would be a most usual
sort of study, to result, all the proliferation of
little languages, get all parsed, then for the great
facility of "term re-write rules" and "term-graph
re-write rules", or "re-write systems", or for
extracting signatures, identifiers, and logic,
for any kind of language.

I think everybody reading this has a most usual
sort of exposure to the theory of parsing as after
Backus-Naur format, vis-a-vis syntax diagrams or
railroad diagrams, and Chomsky hierarchy, and lexers
and parsers and the interpreted and all these kinds
of things, but I don't know a sort of wide-open
framework that parses any kinds of sources and
happens to also re-write itself to any sort of target,
parsing any source language in any source language.

Did I miss the memo?

What I got into was defining languages in terms
of comments and quoting, and, brackets and commas,
and, space and line, in terms of, sequence and alternation,
for basically that all the source is loaded or mapped into
memory, then instead of an abstract syntax tree or sorts,
results an abstract syntax sequence of sorts, those "lifted"
over the source text for its location, then that any sort
of lexicalizing and syntax and grammar, all get put together
as modules and any one just enumerates or makes equivalent
whatever kind of source it is, then according to the
language, results usual sorts constructs and productions,
for functional and procedural languages, and data,
and, you know, language.

Tesniere, Tesniere is the great complement to Chomsky,
where after Chomsky is like, "this finite state machine
builds models of productions in minimal resources", to,
something like, "Simplified Compilation Source", parser,
"this algorithm works in fixed or linear resources in
up to factorial time and parses anything, and unparsed
sections are their source text, and iterating the data
structure or any segment iterates the source under it
that it's lifted over".

See, look at that, "lifted over", I would get a bad
mark for that. Of course that's since been relaxed,
figuring it's natural to dangle and OK to continue.
And so on.

So anyways as long as we're talking about all the usual
languages, uh, is that all "Common Source Language"?

CS language?

So, for something like, "Common Compilation Components",
figuring all sorts usual functional and procedural
productions sort of have a usual form and thusly
can be a great fabric of re-write rules, or targetting,
basically is for making common-enough productions and
the algorithm be multi-pass as necessary, to result
a usual sort of workbench for languages of the source.

Kaz Kylheku wrote:

> On 2024-03-07, Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> wrote:
>> The bugreporting system for the software does not allow anonymous
>> reports.
>
> Use a fake identity?
>

I'd really quite prefer it if they'd just allow people to email in bug
reports.

>> I cannot use another newsreader.
>
> How so? What is the difference between you and people who use other
> newsreaders? Is it genetic or environmental? Nature or nurture?
>

I looked at all the newsreaders and concluded that this is the only one
worth using.

>> Changing my signature is not an option.
>
> Getting rid of a garbage signature that nobody can read is not an
> option?

Yes.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site

Richard Harnden wrote:

> I think Hawk│ is either woke
or entitled.

No, i just have principles that i stick to. (Besides, i'm much further
left than anyone who is “woke”.)

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
Indefinite edition!

Ben wrote:

> On Thu, 7 Mar 2024 06:48:19 -0000 (UTC), Blue-Maned_Hawk wrote:
>
>> Ben Bacarisse wrote:
>>
>>> Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
>>> <cut>
>>>
>>> Since you are clearly happy to post using UTF-8, can I urge you to fix
>>> your sig so that it comes out looking right?
>>
>> Since it is my newsreader that is corrupting it, it is the fault of the
>> newsreader,
>
> I don't think that's the case. Here is a test post using the same
> newsreader and something that is probably close to what you want in your
> sig. (Yours is too messed up for me to work out exactly what you want
> it to look like.)
>

It does not happen immediately; instead, the signature that the software
saves gets more and more corrupted each time the software is opened.

>> and therefore not within my jurisdiction of a problem to fix.
>
> Pan is open source. You may not have the skills to fix it, but doing so
> is in your jurisdiction (though I may have not understood what you mean
> by that).

It is written in CXX and their contribution system does not accept emailed
patches.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
Help, i accidentally built a shelf!

Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
> Ben wrote:
>> On Thu, 7 Mar 2024 06:48:19 -0000 (UTC), Blue-Maned_Hawk wrote:
>>> Ben Bacarisse wrote:
>>>> Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
>>>> <cut>
>>>>
>>>> Since you are clearly happy to post using UTF-8, can I urge you to fix
>>>> your sig so that it comes out looking right?
>>>
>>> Since it is my newsreader that is corrupting it, it is the fault of the
>>> newsreader,
>>
>> I don't think that's the case. Here is a test post using the same
>> newsreader and something that is probably close to what you want in your
>> sig. (Yours is too messed up for me to work out exactly what you want
>> it to look like.)
>
> It does not happen immediately; instead, the signature that the software
> saves gets more and more corrupted each time the software is opened.

Is it saved in a file? Can you not restore that file from a clean copy?

Is it possible that your locale settings are causing your newsreader to
misbehave?

Though I'm not sure why I'm trying to help you to solve a problem when
you seem so determined not to do anything about it.

Elsewhere in this thread:

> No, i just have principles that i stick to.

If your principles require you to inflict garbage on the rest of us, you
should reexamine them.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Sat, 9 Mar 2024 06:27:44 -0000 (UTC), Blue-Maned_Hawk wrote:

> Ben wrote:
>
>> On Thu, 7 Mar 2024 06:48:19 -0000 (UTC), Blue-Maned_Hawk wrote:
>>
>>> Ben Bacarisse wrote:
>>>
>>>> Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
>>>> <cut>
>>>>
>>>> Since you are clearly happy to post using UTF-8, can I urge you to
>>>> fix your sig so that it comes out looking right?
>>>
>>> Since it is my newsreader that is corrupting it, it is the fault of
>>> the newsreader,
>>
>> I don't think that's the case. Here is a test post using the same
>> newsreader and something that is probably close to what you want in
>> your sig. (Yours is too messed up for me to work out exactly what you
>> want it to look like.)
>>
>>
> It does not happen immediately; instead, the signature that the software
> saves gets more and more corrupted each time the software is opened.

Do you mean the problem is not with Pan after all? "The software" is
deliberately vague and I don't know why Pan would be saving the signature
file. It just reads it as far as I can tell.

--
/blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr.

On 09/03/2024 10:40, Ben wrote:
> [working sig]

Since you have utf8/ipa working, I don't suppose you could say how to
pronounce your surname? I know I get it wrong. I'm pretty sure I don't
even get close.

Thanks.

Keith Thompson wrote:

> Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
>> Ben wrote:
>>> On Thu, 7 Mar 2024 06:48:19 -0000 (UTC), Blue-Maned_Hawk wrote:
>>>> Ben Bacarisse wrote:
>>>>> Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
>>>>> <cut>
>>>>>
>>>>> Since you are clearly happy to post using UTF-8, can I urge you to
>>>>> fix your sig so that it comes out looking right?
>>>>
>>>> Since it is my newsreader that is corrupting it, it is the fault of
>>>> the newsreader,
>>>
>>> I don't think that's the case. Here is a test post using the same
>>> newsreader and something that is probably close to what you want in
>>> your sig. (Yours is too messed up for me to work out exactly what you
>>> want it to look like.)
>>
>> It does not happen immediately; instead, the signature that the
>> software saves gets more and more corrupted each time the software is
>> opened.
>
> Is it saved in a file? Can you not restore that file from a clean copy?

I would need to do that every time i open the software. It seems to be
saved in an XML file at ‘~/.pan2/posting.xml’ that explicitly states that
its encoding is UTF-8, so i don't know why the software keeps reëncoding
it into something completely different and then reading it back as UTF-8.

> Is it possible that your locale settings are causing your newsreader to
> misbehave?

I looked through various settings and found nothing that i could change to
fix the problem.

>> No, i just have principles that i stick to.
>
> If your principles require you to inflict garbage on the rest of us, you
> should reexamine them.

They do not.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site

Ben wrote:

> On Sat, 9 Mar 2024 06:27:44 -0000 (UTC), Blue-Maned_Hawk wrote:
>
>> Ben wrote:
>>
>>> On Thu, 7 Mar 2024 06:48:19 -0000 (UTC), Blue-Maned_Hawk wrote:
>>>
>>>> Ben Bacarisse wrote:
>>>>
>>>>> Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
>>>>> <cut>
>>>>>
>>>>> Since you are clearly happy to post using UTF-8, can I urge you to
>>>>> fix your sig so that it comes out looking right?
>>>>
>>>> Since it is my newsreader that is corrupting it, it is the fault of
>>>> the newsreader,
>>>
>>> I don't think that's the case. Here is a test post using the same
>>> newsreader and something that is probably close to what you want in
>>> your sig. (Yours is too messed up for me to work out exactly what you
>>> want it to look like.)

I should have replied to this bit earlier: it intentionally does not use
the polebar character because the spaces required on each side of each
would make the first line not fit the standard format.

>>>
>>>
>> It does not happen immediately; instead, the signature that the
>> software saves gets more and more corrupted each time the software is
>> opened.
>
> Do you mean the problem is not with Pan after all? "The software" is
> deliberately vague and I don't know why Pan would be saving the
> signature file. It just reads it as far as I can tell.

No, the problem is definitely with Pan. I don't know why it would be
saving the signature file either, but it is.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
a

On 08/03/2024 22:23, Chris M. Thomasson wrote:
> On 3/6/2024 2:18 PM, Chris M. Thomasson wrote:
>> On 3/6/2024 2:43 AM, David Brown wrote:
> [...]
>
> This is a fun one:
>
> // pseudo code...
> _______________________
> node*
> node_pop()
> {
>     // try per-thread lifo
>
>     // try shared distributed lifo
>
>     // try global region
>
>     // if all of those failed, return nullptr
> }
>

Just to be clear here - if this is in a safety-critical system, and your
allocation system returns nullptr, people die. That is why you don't
use this kind of thing for important tasks.

On 09/03/2024 12:25, Blue-Maned_Hawk wrote:
> Ben wrote:
>
>> On Sat, 9 Mar 2024 06:27:44 -0000 (UTC), Blue-Maned_Hawk wrote:
>>
>>> Ben wrote:
>>>
>>>> On Thu, 7 Mar 2024 06:48:19 -0000 (UTC), Blue-Maned_Hawk wrote:
>>>>
>>>>> Ben Bacarisse wrote:
>>>>>
>>>>>> Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
>>>>>> <cut>
>>>>>>
>>>>>> Since you are clearly happy to post using UTF-8, can I urge you to
>>>>>> fix your sig so that it comes out looking right?
>>>>>
>>>>> Since it is my newsreader that is corrupting it, it is the fault of
>>>>> the newsreader,
>>>>
>>>> I don't think that's the case. Here is a test post using the same
>>>> newsreader and something that is probably close to what you want in
>>>> your sig. (Yours is too messed up for me to work out exactly what you
>>>> want it to look like.)
>
> I should have replied to this bit earlier: it intentionally does not use
> the polebar character because the spaces required on each side of each
> would make the first line not fit the standard format.

Polebar? You mean pipe?

You are being anal about kerning, but you are happy to post with a sig
that no one can read and doesn't format correctly.

>
>>>>
>>>>
>>> It does not happen immediately; instead, the signature that the
>>> software saves gets more and more corrupted each time the software is
>>> opened.
>>
>> Do you mean the problem is not with Pan after all? "The software" is
>> deliberately vague and I don't know why Pan would be saving the
>> signature file. It just reads it as far as I can tell.
>
> No, the problem is definitely with Pan. I don't know why it would be
> saving the signature file either, but it is.
>

I think Ben has shown that it doesn't.

On Sat, 9 Mar 2024 10:40:07 -0000 (UTC), Ben <ben.usenet@bsb.me.uk> wrote
in <ushea7$28prq$2@dont-email.me>:

> On Sat, 9 Mar 2024 06:27:44 -0000 (UTC), Blue-Maned_Hawk wrote:
>
>> Ben wrote:
>>
>>> On Thu, 7 Mar 2024 06:48:19 -0000 (UTC), Blue-Maned_Hawk wrote:
>>>
>>>> Ben Bacarisse wrote:
>>>>
>>>>> Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
>>>>> <cut>
>>>>>
>>>>> Since you are clearly happy to post using UTF-8, can I urge you to
>>>>> fix your sig so that it comes out looking right?
>>>>
>>>> Since it is my newsreader that is corrupting it, it is the fault of
>>>> the newsreader,
>>>
>>> I don't think that's the case. Here is a test post using the same
>>> newsreader and something that is probably close to what you want in
>>> your sig. (Yours is too messed up for me to work out exactly what you
>>> want it to look like.)
>>>
>>>
>> It does not happen immediately; instead, the signature that the
>> software saves gets more and more corrupted each time the software is
>> opened.
>
> Do you mean the problem is not with Pan after all? "The software" is
> deliberately vague and I don't know why Pan would be saving the
> signature file. It just reads it as far as I can tell.
>
> --
> /blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr.

Perhaps he is using a "Text" type signature, instead of a "Text File"
type signature?

(Would love to discuss it, but in news.software.readers.)

ObC:

Gradually being dragged into the new millenium, where I'm
comfortable with the following:

char something[] = "writable string initializer";

And gcc has -fsanitize=address -- a lovely thing to behold
if it fires off.

Meanwhile, saw someone in another group write:

char * something;
something = strdup("writable string etc.");
if( something == NULL ) { etc. }

But that won't work if --std=c99, does work for g99 and c2x.
The (Linux) man page says:
/* Since glibc 2.12: */ _POSIX_C_SOURCE >= 200809L

I asked Google about it being a POSIX extension
added at that late date, and it gave me an answer
about the C standard:

"C9X London meeting update"
https://groups.google.com/g/comp.std.c/c/pMaEU_8Rb7w
_ _ _ _ _
2. strsep and strdup are not being added. strsep() is out because
not enough people wanted it to vote it in; strdup() lost on the
grounds that it would be the *ONLY* function other than *alloc()
in the entire library whose return could be sanely passed to free(),
and this is surprising.
_ _ _ _ _

Also: <https://stackoverflow.com/questions/32944390/what-is-the-rationale-
for-not-including-strdup-in-the-c-standard>

Anyway, pointed out that they can just use an initializer, something
about which I was clued in by a friendly person in this very group.

--
-v

On Sat, 9 Mar 2024 12:21:48 -0000 (UTC), Blue-Maned_Hawk
<bluemanedhawk@invalid.invalid> wrote in
<pan$2dd7c$14ee35e9$af2801e3$81014785@invalid.invalid>:

> It seems to be saved in an XML file at ‘~/.pan2/posting.xml’

That's your problem. Here is your answer:

Create a separate sig file with your UTF-8 text.

Then go into your posting profile and change the sig type from "text"
to "text file". (It's a drop-down menu.) Then, select the sig
file as your sig file.

This would have been better discussed in news.software.readers,
not comp.lang.c.

> I looked through various settings and found nothing that i could change
> to fix the problem.

I'm biting my tongue.

fu2: news.software.readers.

news.software.readers Discussing software for reading network news
(Usenet).

--
-v

On Sat, 9 Mar 2024 13:19:07 -0000 (UTC)
vallor <vallor@cultnix.org> wrote:
> Meanwhile, saw someone in another group write:
>
> char * something;
> something = strdup("writable string etc.");
> if( something == NULL ) { etc. }
>
> But that won't work if --std=c99, does work for g99 and c2x.
> The (Linux) man page says:
> /* Since glibc 2.12: */ _POSIX_C_SOURCE >= 200809L
>
> I asked Google about it being a POSIX extension
> added at that late date, and it gave me an answer
> about the C standard:
>
> "C9X London meeting update"
> https://groups.google.com/g/comp.std.c/c/pMaEU_8Rb7w
> _ _ _ _ _
> 2. strsep and strdup are not being added. strsep() is out because
> not enough people wanted it to vote it in; strdup() lost on the
> grounds that it would be the *ONLY* function other than *alloc()
> in the entire library whose return could be sanely passed to free(),
> and this is surprising.

The design of strsep() is poor. The reasoning for not adding strdup()
doesn't make any sense to me.

On 3/9/2024 4:25 AM, David Brown wrote:
> On 08/03/2024 22:23, Chris M. Thomasson wrote:
>> On 3/6/2024 2:18 PM, Chris M. Thomasson wrote:
>>> On 3/6/2024 2:43 AM, David Brown wrote:
>> [...]
>>
>> This is a fun one:
>>
>> // pseudo code...
>> _______________________
>> node*
>> node_pop()
>> {
>>      // try per-thread lifo
>>
>>      // try shared distributed lifo
>>
>>      // try global region
>>
>>      // if all of those failed, return nullptr
>> }
>>
>
> Just to be clear here - if this is in a safety-critical system, and your
> allocation system returns nullptr, people die.  That is why you don't
> use this kind of thing for important tasks.
>
>

In this scenario, nullptr returned means the main region allocator is
out of memory. So, pool things up where this never occurs.

On 3/9/2024 2:16 PM, Chris M. Thomasson wrote:
> On 3/9/2024 4:25 AM, David Brown wrote:
>> On 08/03/2024 22:23, Chris M. Thomasson wrote:
>>> On 3/6/2024 2:18 PM, Chris M. Thomasson wrote:
>>>> On 3/6/2024 2:43 AM, David Brown wrote:
>>> [...]
>>>
>>> This is a fun one:
>>>
>>> // pseudo code...
>>> _______________________
>>> node*
>>> node_pop()
>>> {
>>>      // try per-thread lifo
>>>
>>>      // try shared distributed lifo
>>>
>>>      // try global region
>>>
>>>      // if all of those failed, return nullptr
>>> }
>>>
>>
>> Just to be clear here - if this is in a safety-critical system, and
>> your allocation system returns nullptr, people die.  That is why you
>> don't use this kind of thing for important tasks.
>>
>>
>
> In this scenario, nullptr returned means the main region allocator is
> out of memory. So, pool things up where this never occurs.
>

You know how to do it! I know you do.

vallor wrote:

> Create a separate sig file with your UTF-8 text.
>
> Then go into your posting profile and change the sig type from "text"
> to "text file". (It's a drop-down menu.) Then, select the sig file as
> your sig file.

Fuck. Thank you!

--
Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
TEST

Richard Harnden wrote:

> On 09/03/2024 12:25, Blue-Maned_Hawk wrote:
>> Ben wrote:
>>
>>> On Sat, 9 Mar 2024 06:27:44 -0000 (UTC), Blue-Maned_Hawk wrote:
>>>
>>>> Ben wrote:
>>>>
>>>>> On Thu, 7 Mar 2024 06:48:19 -0000 (UTC), Blue-Maned_Hawk wrote:
>>>>>
>>>>>> Ben Bacarisse wrote:
>>>>>>
>>>>>>> Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
>>>>>>> <cut>
>>>>>>>
>>>>>>> Since you are clearly happy to post using UTF-8, can I urge you to
>>>>>>> fix your sig so that it comes out looking right?
>>>>>>
>>>>>> Since it is my newsreader that is corrupting it, it is the fault of
>>>>>> the newsreader,
>>>>>
>>>>> I don't think that's the case. Here is a test post using the same
>>>>> newsreader and something that is probably close to what you want in
>>>>> your sig. (Yours is too messed up for me to work out exactly what
>>>>> you want it to look like.)
>>
>> I should have replied to this bit earlier: it intentionally does not
>> use the polebar character because the spaces required on each side of
>> each would make the first line not fit the standard format.
>
> Polebar? You mean pipe?
>
> You are being anal about kerning, but you are happy to post with a sig
> that no one can read and doesn't format correctly.
>

The kerning 'round the polebar would have been my own fault instead of the
fault of the software.

>>
>>>>>
>>>> It does not happen immediately; instead, the signature that the
>>>> software saves gets more and more corrupted each time the software is
>>>> opened.
>>>
>>> Do you mean the problem is not with Pan after all? "The software" is
>>> deliberately vague and I don't know why Pan would be saving the
>>> signature file. It just reads it as far as I can tell.
>>
>> No, the problem is definitely with Pan. I don't know why it would be
>> saving the signature file either, but it is.
>>
>>
> I think Ben has shown that it doesn't.

Well, that clearly isn't true.

--
Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
“Ding me.” “No!”

Richard Harnden <richard.nospam@gmail.invalid> writes:

> On 09/03/2024 12:25, Blue-Maned_Hawk wrote:
>> Ben wrote:
....
>>>>> On Thu, 7 Mar 2024 06:48:19 -0000 (UTC), Blue-Maned_Hawk wrote:
>>>> It does not happen immediately; instead, the signature that the
>>>> software saves gets more and more corrupted each time the software is
>>>> opened.
>>>
>>> Do you mean the problem is not with Pan after all? "The software" is
>>> deliberately vague and I don't know why Pan would be saving the
>>> signature file. It just reads it as far as I can tell.
>>
>> No, the problem is definitely with Pan. I don't know why it would be
>> saving the signature file either, but it is.
>
> I think Ben has shown that it doesn't.

I think BMH is not using a sig file. The bottom line is that pan can do
what BMH wants, but he's doing something that does not work.
Unfortunately his explanation is unhelpful because his sig (as posted)
is not getting "more and more corrupted" so it's not at all clear what
he's seeing.

I've tried /not/ using a sig file and that also seems to work. The
posting.xml configuration file /is/ written every time pan closes, but
it appears not to be getting corrupted.

--
Ben.