Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux > #70437 > unrolled thread

Any Unicode Experts?

Back to article view | Back to alt.os.linux

Contents

  Any Unicode Experts? FR <fr@random.info> - 2021-08-06 14:39 +0000
    Re: Any Unicode Experts? FR <fr@random.info> - 2021-08-06 15:01 +0000
      Re: Any Unicode Experts? Snit Michael Glasser <frelwizzen@gmail.com> - 2021-08-06 08:10 -0700
    US-ASCII is a subset of the set of Unicode code points. Jeff-Relf.Me  @. - 2021-08-06 08:15 -0700
      Re: US-ASCII is a subset of the set of Unicode code points. "R.Wieser" <address@not.available> - 2021-08-06 17:36 +0200
        Re: US-ASCII is a subset of the set of Unicode code points. FR <fr@random.info> - 2021-08-06 15:49 +0000
          Re: US-ASCII is a subset of the set of Unicode code points. "R.Wieser" <address@not.available> - 2021-08-06 18:48 +0200
          Re: US-ASCII is a subset of the set of Unicode code points. FR <fr@random.info> - 2021-08-06 17:57 +0000
    Re: Any Unicode Experts? Eli the Bearded <*@eli.users.panix.com> - 2021-08-06 20:27 +0000
      Re: Any Unicode Experts? The Natural Philosopher <tnp@invalid.invalid> - 2021-08-07 09:36 +0100
        Re: Any Unicode Experts? Eli the Bearded <*@eli.users.panix.com> - 2021-08-08 04:32 +0000
          Re: Any Unicode Experts? rbowman <bowman@montana.com> - 2021-08-07 22:50 -0600
            Re: Any Unicode Experts? jak <nospam@please.ty> - 2021-08-08 20:32 +0200
              Re: Any Unicode Experts? rbowman <bowman@montana.com> - 2021-08-08 18:00 -0600
                "while(1);" borks Visual Studio. Jeff-Relf.Me  @. - 2021-08-08 18:11 -0700
                  Re: "while(1);" borks Visual Studio. rbowman <bowman@montana.com> - 2021-08-08 22:19 -0600
                    Re: "while(1);" borks Visual Studio. Ann Glaser <frelwizzen@gmail.com> - 2021-08-09 14:57 -0700
                    Re: "while(1);" borks Visual Studio. Soviet_Mario <SovietMario@CCCP.MIR> - 2021-08-16 16:06 +0200
                      Re: "while(1);" borks Visual Studio. HHI <frelwizzen@gmail.com> - 2021-08-17 11:42 -0700
                      Re: "while(1);" borks Visual Studio. STALKING_TARGET_27 <frelwizzen@gmail.com> - 2021-08-19 16:20 -0700
                  Re: "while(1);" borks Visual Studio. jak <nospam@please.ty> - 2021-08-10 18:02 +0200
                    while(malloc(666)); Jeff-Relf.Me  @. - 2021-08-10 09:28 -0700
                      Re: while(malloc(666)); jak <nospam@please.ty> - 2021-08-10 18:39 +0200
                Re: Any Unicode Experts? jak <nospam@please.ty> - 2021-08-09 07:28 +0200
                  Re: Any Unicode Experts? rbowman <bowman@montana.com> - 2021-08-09 07:56 -0600
                    Re: Any Unicode Experts? jak <nospam@please.ty> - 2021-08-10 10:33 +0200
                      Re: Any Unicode Experts? The Natural Philosopher <tnp@invalid.invalid> - 2021-08-10 12:49 +0100
                        Re: Any Unicode Experts? jak <nospam@please.ty> - 2021-08-10 15:26 +0200
                          Re: Any Unicode Experts? vallor <vallor@cultnix.org> - 2021-08-10 13:43 +0000
                      Re: Any Unicode Experts? rbowman <bowman@montana.com> - 2021-08-10 21:12 -0600
                        Re: Any Unicode Experts? The Natural Philosopher <tnp@invalid.invalid> - 2021-08-11 12:25 +0100
                          Re: Any Unicode Experts? Steve Carroll <frelwizzen@gmail.com> - 2021-08-12 09:54 -0700
                            Re: Any Unicode Experts? Steve Carroll <frelwizzen@gmail.com> - 2021-08-14 10:58 -0700
                        Re: Any Unicode Experts? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-08-11 16:52 +0000
                          Re: Any Unicode Experts? jak <nospam@please.ty> - 2021-08-11 20:19 +0200
                            Re: Any Unicode Experts? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-08-12 16:37 +0000
                              Re: Any Unicode Experts? jak <nospam@please.ty> - 2021-08-12 20:32 +0200
                                Re: Any Unicode Experts? rbowman <bowman@montana.com> - 2021-08-12 20:40 -0600
                                  Re: Any Unicode Experts? Steven Petruzzellis - fretwizen <frelwizzen@gmail.com> - 2021-08-14 11:14 -0700
                                    Re: Any Unicode Experts? Steven Carroll <frelwizzen@gmail.com> - 2021-08-15 05:19 -0700
                              Re: Any Unicode Experts? STALKING_TARGET_79 <frelwizzen@gmail.com> - 2021-08-13 15:09 -0700
                    Re: Any Unicode Experts? Andreas Kohlbach <ank@spamfence.net> - 2021-08-10 16:11 -0400
        Re: Any Unicode Experts? STALKING_TARGET_53 <frelwizzen@gmail.com> - 2021-08-08 14:40 -0700

Page 1 of 3  [1] 2 3  Next page →

#70437 — Any Unicode Experts?

ASCII is dead as it should be.  It goes back to the telegraph era
(i.e. Morse code).  The first 32 bytes (except EOL, LF, and CR)
of ASCII are transmission control codes that are no longer relevant.

ASCII has been incorporated first into ISO-8859-1 and now into
UTF-8, which is (or should be) the global standard.

But what happened to the first 32 bytes of UTF-8?  Obviously
LF and CR are still there, but have the former control codes
been replaced by other, and more meaningful, code points?

As far as I know, the first 32 bytes (except CR and LF) are
just dead space.  Is this correct?

[toc] | [next] | [standalone]

#70438

On Fri, 06 Aug 2021 14:51:25 +0000, Lew Pitcher wrote:

> On Fri, 06 Aug 2021 14:39:50 +0000, FR wrote:
> 
> [opinions ellided]
> 
>> But what happened to the first 32 bytes of UTF-8?  Obviously
>> LF and CR are still there, but have the former control codes
>> been replaced by other, and more meaningful, code points?
> 
> See  https://www.unicode.org/charts/PDF/U0000.pdf
> Also https://www.unicode.org/charts/PDF/U0080.pdf
> 
>> As far as I know, the first 32 bytes (except CR and LF) are
>> just dead space.  Is this correct?
> 
> Not in the least.
>

A comprehensive answer is here:

https://www.aivosto.com/articles/control-characters.html

To preserve the integrity of conversions and interchange,
the control codes remain.

However, the semantics of the control codes are reserved
to applications.

So the control codes are in a kind of limbo.  They have
only an application-specific meaning but in the absence
of an application they are to be interpreted according
to  ISO/IEC 6429:1992. (Unicode 9.0 p. 822)

[toc] | [prev] | [next] | [standalone]

#70439

On Friday, August 6, 2021 at 8:01:54 AM UTC-7, FR wrote:
> On Fri, 06 Aug 2021 14:51:25 +0000, Lew Pitcher wrote: 
> 
> > On Fri, 06 Aug 2021 14:39:50 +0000, FR wrote: 
> > 
> > [opinions ellided]
> > 
> >> But what happened to the first 32 bytes of UTF-8? Obviously 
> >> LF and CR are still there, but have the former control codes 
> >> been replaced by other, and more meaningful, code points? 
> >
> > See https://www.unicode.org/charts/PDF/U0000.pdf 
> > Also https://www.unicode.org/charts/PDF/U0080.pdf
> > 
> >> As far as I know, the first 32 bytes (except CR and LF) are 
> >> just dead space. Is this correct? 
> >
> > Not in the least. 
> > 
> 
> A comprehensive answer is here: 
> 
> https://www.aivosto.com/articles/control-characters.html 
> 
> To preserve the integrity of conversions and interchange, 
> the control codes remain. 
> 
> However, the semantics of the control codes are reserved 
> to applications. 
> 
> So the control codes are in a kind of limbo. They have 
> only an application-specific meaning but in the absence 
> of an application they are to be interpreted according 
> to ISO/IEC 6429:1992. (Unicode 9.0 p. 822)


He lies that he uses macOS, while of course he never installed it to get 
any real work done and really tried it. 

What it looks like is the least of your problems and is no big deal, especially 
if it's FOSS. Lots of posters persist in replying to Sigmond. Frankly I 
don't chide Apd for being annoyed but I can't get why he comes here with 
Sigmond here. Apd is better at discussions as is common in a formal forum 
and support environments bother him too much. The bulk of the people in 
this group do scripting either as entertainment or as a job, so I think 
it unlikely anyone here consider automation to be "impossible". Just look 
at the effort Apd once again had to spend to get Sigmond able to pull messages 
from a usenet server via CLI. Apd once again, took abuse from Sigmond, instead 
of a great thanks, sign of indebtedness, response - that I think Apd was 
owed for the trouble and time he spent on the issue. In fact Sigmond's lies 
got bigger. So needless to say I regret not attacking Sigmond. While I am 
sure he approved of it, being nice to him made things worse. Usenet is a 
self-governing concordat based on the belief in good character. 


--
Do not click this link!!!
https://www.bing.com/search?q=Steve+Petruzzellis%3A+narcissistic+bigot
Dustin Cook the Fraud

[toc] | [prev] | [next] | [standalone]

#70440 — US-ASCII is a subset of the set of Unicode code points.

Fabian Russell:
> As far as I know, the first 32 [ code points ] (except CR and LF)
> are just dead space.  Is this correct ?

No, US-ASCII is a subset of the set of Unicode code points.

Unicode code points are 20 bits long, not 32.

typedef  wchar_t  wchar ;   typedef  char32_t  Uchar ;

//  UTF-16 requires a "Surrogate Pair" ( 2 wchars )
//  to encode one 20 bit UTF-32 (Uchar) code point.

Uchar _i32, i32 = U'⛏';   wchar  pCh[2];

#define  i32＞pCh( Ch, pCh )  hall( pCh[1] = 0, Ch >= 0x10000 ? *pCh = 0xd800 | Ch - 0x10000 >> 10, pCh[1] = 0xdc00 + ( Ch & 0x03FF ) : *pCh = Ch )

i32＞pCh( i32, pCh );

SurrogatePair = ( *pCh & 0xF800 ) == 0xD800 ;

_i32 = !SurrogatePair ? *pCh : 0x10000 + ( *pCh - 0xD800 << 10 ) + pCh[1] - 0xDC00 ;

[toc] | [prev] | [next] | [standalone]

#70441 — Re: US-ASCII is a subset of the set of Unicode code points.

Jeff,

>> As far as I know, the first 32 [ code points ] (except CR and LF)
>> are just dead space.  Is this correct ?
>
> No, US-ASCII is a subset of the set of Unicode code points.

Try to understand the question before you answer it.

@Fabian Russell:

> As far as I know, the first 32 [ code points ] (except CR and LF)
> are just dead space.  Is this correct ?

No.  All of those have definite meanings.   Just think of the BACKSPACE
(0x08), TAB (0x09), ESCape (0x1B) and BELL (0x07) characters.   One you
might never have heard of is ctrl-Z (0x1A), which, for old-style textfiles,
means that the file ends (even when it may contain some more
characters/garbage).

For a full list you could take a peek here : http://asciiset.com/

Granted, quite a few of the control-characters there you will never use.
They are still there if you need them though.

Regards,
Rudy Wieser

P.s.
Did you also think of the DEL (0x7F) character ?    Just as the BACKSPACE
character is used to delete the character left of the cursor, the DEL
character is ment to delete the character under the cursor.

[toc] | [prev] | [next] | [standalone]

#70442 — Re: US-ASCII is a subset of the set of Unicode code points.

On Fri, 06 Aug 2021 17:36:37 +0200, R.Wieser wrote:

> 
>> As far as I know, the first 32 [ code points ] (except CR and LF)
>> are just dead space.  Is this correct ?
> 
> No.  All of those have definite meanings.  
>

According to the link that I cited, in Unicode the meanings,
outside of an application, are not always the same as the original:


"Unicode specifies semantics for the following control characters:
 
ASCII control characters: 

HT and SP are considered whitespace.

LF, VT, FF and CR are considered whitespace, and also mandatory line breaks
in the line breaking algorithm.

FS, GS, RS and US are considered separators in the bi-directional algorithm."


Thus if I encounter an HT control code in some UTF-8 file
then I should process that code as whitespace.

But a specific application may choose to use the HT control
code for some other purpose.

[toc] | [prev] | [next] | [standalone]

#70443 — Re: US-ASCII is a subset of the set of Unicode code points.

FR,

> According to the link that I cited

..grumble ...  Jeff-Relf changed the subject and with it made it look, in my
chronological list, as if it was a new thread.  Only now I notice your "Any
Unicode Experts?" post.

Alas, although I do know a bit about ASCII, I never bothered to know much
about unicode.

> HT and SP are considered whitespace.
...
> Thus if I encounter an HT control code in some UTF-8
> file then I should process that code as whitespace.

That fully depends on what you mean with "processed".

For "scanning the string" purposes ?  Yes, you can handle both in the same
way (just like you may do with most most all of the other control
characters, possibly even including CR and LF [1] ).

For *displaying* purposes ?   Nope, both have a different effect.

[1] if you have access to a C{something} compiler you could take a peek at
how fscanf and printf deal with those control characters.   IIRC fscanf for
a value will ignore CR and LF (which is not always what you want...)

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#70444 — Re: US-ASCII is a subset of the set of Unicode code points.

On Fri, 06 Aug 2021 17:25:11 +0000, Charlie Gibbs wrote:

> On 2021-08-06, FR <fr@random.info> wrote:
> 
>> On Fri, 06 Aug 2021 17:36:37 +0200, R.Wieser wrote:
>>
> 
> To sum up, there is whitespace and there is whitespace.  The
> differences between the various characters may be subtle, but
> that doesn't mean that you should treat them all the same.
> Each has its own special use.
>

Whitespace can be independent of format. When doing a search, 
for example, a whitespace char is simply skipped over. 

Formatting is also something that is independent of a particular 
character set. Formatting is achieved by an application such 
as a word processor, type setter, etc. that would use its own 
internal codes and not that of the charset. 

Although the old ASCII format codes are still present in 
Unicode they, aside from EOL, should not be interpreted as such 
when processing a UTF-8 text file, for example. In Unicode 
their interpretation is ambiguous. Anyone composing with UTF-8 
would never use them. 

Unicode does have many unambiguous formatting characters such as 
U+2028, line separator, and U+2029, paragraph separator, but, not 
being an expert in Unicode, I wouldn't know how or where to use them. 

Unicode is supposed to provide the symbols but not the formatting 
instructions. Some languages might require special codes for a 
proper construction, but this is not the same as formatting. 

[toc] | [prev] | [next] | [standalone]

#70447

(Follow-up to comp.os.linux.advocacy ignored.)

In comp.os.linux.misc, FR  <fr@random.info> wrote:
> ASCII is dead as it should be.  It goes back to the telegraph era
> (i.e. Morse code).  The first 32 bytes (except EOL, LF, and CR)
> of ASCII are transmission control codes that are no longer relevant.
...
> As far as I know, the first 32 bytes (except CR and LF) are
> just dead space.  Is this correct?

No, absolutely not.

Null and horizontal tab get a lot of use still. Vertical tab and
form feed get a little. Arguably escape and backspace get used (eg
terminal control sequences). Whatever the status of the rest vis-a-vis
newly composed documents, their meanings remain unchanged for historical
documents.

Unicode, covering Linear A (U+10600 to U+1077F, in use from 1800 to 1450
BC) to Signwriting (U+1D800 to U+1DAAF, a generalized notation for
writing down sign languages) aims to include modern and historical
content. Just because you should not expect to generate new content
with start of heading (SOH) or end transmission block (ETB), doesn't
mean those characters are dead space.

Elijah
------
has a soft spot for ␗ U+0017

[toc] | [prev] | [next] | [standalone]

#70463

On 06/08/2021 21:27, Eli the Bearded wrote:
> (Follow-up to comp.os.linux.advocacy ignored.)
> 
> In comp.os.linux.misc, FR  <fr@random.info> wrote:
>> ASCII is dead as it should be.  It goes back to the telegraph era
>> (i.e. Morse code).  The first 32 bytes (except EOL, LF, and CR)
>> of ASCII are transmission control codes that are no longer relevant.
> ...
>> As far as I know, the first 32 bytes (except CR and LF) are
>> just dead space.  Is this correct?
> 
> No, absolutely not.
> 
> Null and horizontal tab get a lot of use still. Vertical tab and
> form feed get a little. Arguably escape and backspace get used (eg
> terminal control sequences). Whatever the status of the rest vis-a-vis
> newly composed documents, their meanings remain unchanged for historical
> documents.
> 
Ctrl-Z and Ctrl-C and Ctrl-V have a lot of use too

> Unicode, covering Linear A (U+10600 to U+1077F, in use from 1800 to 1450
> BC) to Signwriting (U+1D800 to U+1DAAF, a generalized notation for
> writing down sign languages) aims to include modern and historical
> content. Just because you should not expect to generate new content
> with start of heading (SOH) or end transmission block (ETB), doesn't
> mean those characters are dead space.
> 
Indeed not. They are handy as with all 'out of band' text characters as 
control characters on communications streams that could conceivably be 
useful again sometime in the future

> Elijah
> ------
> has a soft spot for ␗ U+0017
> 


-- 
Future generations will wonder in bemused amazement that the early 
twenty-first century’s developed world went into hysterical panic over a 
globally average temperature increase of a few tenths of a degree, and, 
on the basis of gross exaggerations of highly uncertain computer 
projections combined into implausible chains of inference, proceeded to 
contemplate a rollback of the industrial age.

Richard Lindzen

[toc] | [prev] | [next] | [standalone]

#70497

In comp.os.linux.misc, The Natural Philosopher  <tnp@invalid.invalid> wrote:
> On 06/08/2021 21:27, Eli the Bearded wrote:
> > Null and horizontal tab get a lot of use still. Vertical tab and
> > form feed get a little. Arguably escape and backspace get used (eg
> > terminal control sequences). Whatever the status of the rest vis-a-vis
> > newly composed documents, their meanings remain unchanged for historical
> > documents.
> Ctrl-Z and Ctrl-C and Ctrl-V have a lot of use too

I type those, and others like ctrl-W, ctrl-U, ctrl-F, ctrl-B, ctrl-D,
ctrl-R, etc, reasonably often, but I don't encounter them in files,
unlike the ones I named. (I have checked-in files at github with embedded
terminal control sequences.) So those _feel_ different. The stty
settings are just defaults, and can be changed. There's nothing special
about the characters. The ones I use in vi, not in stty, are are not
changable, but are based on mnemonics instead of ASCII meaning. I use
ctrl-F for "forward page" not for ACK.

The stty ones:
    intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
    eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
    rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O;

Of those that have settings, only discard do I not use. Stop, I use, but
usually by accident and then I have to start again. I'd like that one to
default to undef, but I log in to too many computers per day to bother
trying to manually set it. Reprint, escape next (lnext), and quit I use
fairly rarely, but when I need them there's no substitute.

Oh, wait, you're thinking of Windows short cuts. I don't think they are
meant to map to a character _ever_. Those are just key press events
caught by the OS / program, same as command keys in Macs.

Ctrl-C for Copy I think exists because Command-C for copy first existed.
Neither has anything to do with the ASCII control character ETX.

> Indeed not. They are handy as with all 'out of band' text characters as 
> control characters on communications streams that could conceivably be 
> useful again sometime in the future

I like tab separated values more than comma separated values, because
with rare exceptions[*], tabs in text can be converted to spaces without
loss of meaning, so I can have a separator that never needs quoting. But
using ASCII RS (ctrl-^) for it's intended purpose as a record separator
just feels obsolent and wrong to me, even if it is even less likely to
appear in the sort of things I put into TSV files.

[*] And the sorts of things that do need raw tabs, like Makefiles, I
    don't put in TSV files.

Elijah
------
in two minutes of testing could not get ^O (discard) to do anything

[toc] | [prev] | [next] | [standalone]

#70498

On 08/07/2021 10:32 PM, Eli the Bearded wrote:
> Ctrl-C for Copy I think exists because Command-C for copy first existed.
> Neither has anything to do with the ASCII control character ETX.

I'm probably wrong but I think WordStar had an influence.

[toc] | [prev] | [next] | [standalone]

#70506

Il 08/08/2021 06:50, rbowman ha scritto:
> On 08/07/2021 10:32 PM, Eli the Bearded wrote:
>> Ctrl-C for Copy I think exists because Command-C for copy first existed.
>> Neither has anything to do with the ASCII control character ETX.
> 
> I'm probably wrong but I think WordStar had an influence.

I don't think so. These are the old commands for wordstar: 
https://sfwriter.com/wordstar-command-summary.pdf
In my memory the first Ctrl-X/Ctrl-C/Ctrl-V shortcuts I saw with the
first full-screen commands in ms-dos 3.1: explorer.exe and qbasic.exe.
Explorer was very similar to the Windows version but in semi-graphics
(video in text mode and windows drawn with ascii-extended fonts). These
programs finally allowed to use the mouse making the old shortcuts
difficult to use (Shift-Del/Ctrl-Ins/Shift-Ins) with the left hand
(to keep the right hand on the mouse), however the old shortcuts also
work today and often even with programs that suppress the new shortcuts.

cheers

[toc] | [prev] | [next] | [standalone]

#70510

On 08/08/2021 12:32 PM, jak wrote:
> Il 08/08/2021 06:50, rbowman ha scritto:
>> On 08/07/2021 10:32 PM, Eli the Bearded wrote:
>>> Ctrl-C for Copy I think exists because Command-C for copy first existed.
>>> Neither has anything to do with the ASCII control character ETX.
>>
>> I'm probably wrong but I think WordStar had an influence.
>
> I don't think so. These are the old commands for wordstar:
> https://sfwriter.com/wordstar-command-summary.pdf
> In my memory the first Ctrl-X/Ctrl-C/Ctrl-V shortcuts I saw with the
> first full-screen commands in ms-dos 3.1: explorer.exe and qbasic.exe.
> Explorer was very similar to the Windows version but in semi-graphics
> (video in text mode and windows drawn with ascii-extended fonts). These
> programs finally allowed to use the mouse making the old shortcuts
> difficult to use (Shift-Del/Ctrl-Ins/Shift-Ins) with the left hand
> (to keep the right hand on the mouse), however the old shortcuts also
> work today and often even with programs that suppress the new shortcuts.
>
> cheers

Brief had those key bindings but by '85 it wasn't clear who was copying 
who. That was the only programming editor I ever paid money for. Borland 
bought it and buried it.

I'm not a power user of the VS editor but 35 years later it seems to 
lack the features of Brief.

[toc] | [prev] | [next] | [standalone]

#70512 — "while(1);" borks Visual Studio.

Bowman:
> I'm not a power user of the VS editor but 
> 35 years later it seems to lack the features of Brief.

My macros & extensions to Visual Studio 2019:  http://Jeff-Relf.Me/Macros.HTM

In Visual Studio, I'm editing a small, recently opened text file.
AutoRecover is turned off.

For that, it's consuming 1.8 gigabytes of RAM, and growing rapidly;
occasionally, it drops back down to "just" 1.2 gigabytes.

Just now, it disappeared from the task manager altogether,
showing up again only after ReStarting the task manager.

Every time I debug my app, memory usage goes up, 
briefly topping 2 gigabytes, _after_ exiting the app/debugger.
Hmmm... it's a memory leak, apparently.

I ReStarted Visual Studio, now it's consuming 186 megabytes,
no more memory leaking.

"while(1);" borks Visual Studio, apparently.

[toc] | [prev] | [next] | [standalone]

#70513 — Re: "while(1);" borks Visual Studio.

On 08/08/2021 07:11 PM, Jeff-Relf.Me@. wrote:
> Bowman:
>> I'm not a power user of the VS editor but
>> 35 years later it seems to lack the features of Brief.
>
> My macros & extensions to Visual Studio 2019:  http://Jeff-Relf.Me/Macros.HTM
>
> In Visual Studio, I'm editing a small, recently opened text file.
> AutoRecover is turned off.
>
> For that, it's consuming 1.8 gigabytes of RAM, and growing rapidly;
> occasionally, it drops back down to "just" 1.2 gigabytes.
>
> Just now, it disappeared from the task manager altogether,
> showing up again only after ReStarting the task manager.
>
> Every time I debug my app, memory usage goes up,
> briefly topping 2 gigabytes, _after_ exiting the app/debugger.
> Hmmm... it's a memory leak, apparently.
>
> I ReStarted Visual Studio, now it's consuming 186 megabytes,
> no more memory leaking.
>
> "while(1);" borks Visual Studio, apparently.
>

It would tend to do that. Even a more complex while statement that 
doesn't have any natural points where it will block will try for 100% of 
the cpu. At least now it only ties up one core.

[toc] | [prev] | [next] | [standalone]

#70527 — Re: "while(1);" borks Visual Studio.

On Sunday, August 8, 2021 at 9:19:17 PM UTC-7, rbowman wrote:
> On 08/08/2021 07:11 PM, Jeff-Relf.Me@. wrote: 
> > Bowman: 
> >> I'm not a power user of the VS editor but 
> >> 35 years later it seems to lack the features of Brief. 
> > 
> > My macros & extensions to Visual Studio 2019: http://Jeff-Relf.Me/Macros.HTM 
> > 
> > In Visual Studio, I'm editing a small, recently opened text file. 
> > AutoRecover is turned off. 
> > 
> > For that, it's consuming 1.8 gigabytes of RAM, and growing rapidly; 
> > occasionally, it drops back down to "just" 1.2 gigabytes. 
> > 
> > Just now, it disappeared from the task manager altogether, 
> > showing up again only after ReStarting the task manager. 
> > 
> > Every time I debug my app, memory usage goes up, 
> > briefly topping 2 gigabytes, _after_ exiting the app/debugger. 
> > Hmmm... it's a memory leak, apparently. 
> > 
> > I ReStarted Visual Studio, now it's consuming 186 megabytes, 
> > no more memory leaking. 
> > 
> > "while(1);" borks Visual Studio, apparently. 
> >
> It would tend to do that. Even a more complex while statement that 
> doesn't have any natural points where it will block will try for 100% of 
> the cpu. At least now it only ties up one core.


You do realize that the massive floods ending up in multiple groups started 
out as a joke about hacking Google. 

A persistent, acute, posting itch, despite nothing to say - fundamentally 
slippery Mac-using tarts, and vigorously-greased ram, scared stiff by loud 
music for his own private requirements. Just look at the effort Gremlin 
once again had to spend to get Shadow able to pull messages from an IRC 
server via scripting. Gremlin once again, took abuse from Shadow, instead 
of a great thanks, sign of indebtedness, response - that I know Gremlin 
was owed for the trouble and time he spent on the issue. The advocates insist 
searching for a suggestion for a FOSS application is attacking. No-one gets 
it, I barely understand it. 

--
I Left My Husband & Daughter At Home And THIS happened!
https://www.youtube.com/watch?v=0ZNxaaKD7-c
https://www.google.com/search?q=steve+carroll%3A+narcissistic+bigot
Steve 'Narcissistic Bigot' Petruzzellis

[toc] | [prev] | [next] | [standalone]

#70644 — Re: "while(1);" borks Visual Studio.

Il 09/08/21 06:19, rbowman ha scritto:
> On 08/08/2021 07:11 PM, Jeff-Relf.Me@. wrote:
>> Bowman:
>>> I'm not a power user of the VS editor but
>>> 35 years later it seems to lack the features of Brief.
>>
>> My macros & extensions to Visual Studio 2019:  
>> http://Jeff-Relf.Me/Macros.HTM
>>
>> In Visual Studio, I'm editing a small, recently opened 
>> text file.
>> AutoRecover is turned off.
>>
>> For that, it's consuming 1.8 gigabytes of RAM, and growing 
>> rapidly;
>> occasionally, it drops back down to "just" 1.2 gigabytes.
>>
>> Just now, it disappeared from the task manager altogether,
>> showing up again only after ReStarting the task manager.
>>
>> Every time I debug my app, memory usage goes up,
>> briefly topping 2 gigabytes, _after_ exiting the 
>> app/debugger.
>> Hmmm... it's a memory leak, apparently.
>>
>> I ReStarted Visual Studio, now it's consuming 186 megabytes,
>> no more memory leaking.
>>
>> "while(1);" borks Visual Studio, apparently.
>>
> 
> It would tend to do that. Even a more complex while 
> statement that doesn't have any natural points where it will 
> block will try for 100% of the cpu. At least now it only 
> ties up one core.

It is not selfevident to me why an infinite loop should be 
supposed to eat up RAM ...
CPU time maybe yes, but why high RAM consumption ?

Recursion of calls to procedures consumes RAM (even if on 
many compilers that don't let grow limitlessly automatic 
memory, but the stack has a maximum size and then the 
overflow kills badly the process : the stack overlaps and 
collide with read only data, with "code", with areas 
belonging to other processes, seg-faulting, etc).

To produce similar leaks, I think (I'm just saying an 
opinion, not a truth) some conditions might operate :

an infinite recursion of calls to procedures that have a 
very limited (or negligible) stack signature (i.g. no 
parameters passed, maybe not even a return value) and 
internally performing some heavy "dynamic allocation, i.g. 
by specialized constructors or else).

also routines that works on objects encapsulating arrays 
that assume to pass By Value (not by pointer or reference), 
when called in nested mode, will need to copy large amount 
of data, in dynamic ram.

Or even some mis-written or generated "destructors" that 
don't clean-up properly dynamically allocated objects (i.g. 
bad string allocators in programming manipulating a lot of 
rw strings). Or both.
A memory leak can have a lot of fathers and mothers. But, 
imho, not a simple infinite loop in itself.


If i think sth like this

String A = "";
while (1)
     A &= "x";

the memory usage would explode, sure, depending on the 
placement of the chained string A ....





-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#70666 — Re: "while(1);" borks Visual Studio.

On Monday, August 16, 2021 at 7:06:44 AM UTC-7, Soviet_Mario wrote:
> Il 09/08/21 06:19, rbowman ha scritto:
> > On 08/08/2021 07:11 PM, Jeff-Relf.Me@. wrote: 
> >> Bowman: 
> >>> I'm not a power user of the VS editor but 
> >>> 35 years later it seems to lack the features of Brief. 
> >> 
> >> My macros & extensions to Visual Studio 2019: 
> >> http://Jeff-Relf.Me/Macros.HTM 
> >> 
> >> In Visual Studio, I'm editing a small, recently opened 
> >> text file. 
> >> AutoRecover is turned off. 
> >> 
> >> For that, it's consuming 1.8 gigabytes of RAM, and growing 
> >> rapidly; 
> >> occasionally, it drops back down to "just" 1.2 gigabytes. 
> >> 
> >> Just now, it disappeared from the task manager altogether, 
> >> showing up again only after ReStarting the task manager. 
> >> 
> >> Every time I debug my app, memory usage goes up, 
> >> briefly topping 2 gigabytes, _after_ exiting the 
> >> app/debugger. 
> >> Hmmm... it's a memory leak, apparently. 
> >> 
> >> I ReStarted Visual Studio, now it's consuming 186 megabytes, 
> >> no more memory leaking. 
> >> 
> >> "while(1);" borks Visual Studio, apparently. 
> >> 
> > 
> > It would tend to do that. Even a more complex while 
> > statement that doesn't have any natural points where it will 
> > block will try for 100% of the cpu. At least now it only 
> > ties up one core.
> It is not selfevident to me why an infinite loop should be 
> supposed to eat up RAM ... 
> CPU time maybe yes, but why high RAM consumption ? 
> 
> Recursion of calls to procedures consumes RAM (even if on 
> many compilers that don't let grow limitlessly automatic 
> memory, but the stack has a maximum size and then the 
> overflow kills badly the process : the stack overlaps and 
> collide with read only data, with "code", with areas 
> belonging to other processes, seg-faulting, etc). 
> 
> To produce similar leaks, I think (I'm just saying an 
> opinion, not a truth) some conditions might operate : 
> 
> an infinite recursion of calls to procedures that have a 
> very limited (or negligible) stack signature (i.g. no 
> parameters passed, maybe not even a return value) and 
> internally performing some heavy "dynamic allocation, i.g. 
> by specialized constructors or else). 
> 
> also routines that works on objects encapsulating arrays 
> that assume to pass By Value (not by pointer or reference), 
> when called in nested mode, will need to copy large amount 
> of data, in dynamic ram. 
> 
> Or even some mis-written or generated "destructors" that 
> don't clean-up properly dynamically allocated objects (i.g. 
> bad string allocators in programming manipulating a lot of 
> rw strings). Or both. 
> A memory leak can have a lot of fathers and mothers. But, 
> imho, not a simple infinite loop in itself. 
> 
> 
> If i think sth like this 
> 
> String A = ""; 
> while (1) 
> A &= "x"; 
> 
> the memory usage would explode, sure, depending on the 
> placement of the chained string A .... 
> 
> 
> 
> 
> 
> -- 
> 1) Resistere, resistere, resistere. 
> 2) Se tutti pagano le tasse, le tasse le pagano tutti 
> Soviet_Mario - (aka Gatto_Vizzato)


Open source is only cost effective if your time has no value. Those who 
groks our history knows it's not written in the sense Gregory Hall is 
thinking, and some of them are flat out manually written. Do you have 
a MCSE certification? 

I'm getting false positives in my kill filter. I'm guessing the pea-brained 
circus is in its brain damage mode again. Yawn. Same old brain-dead trolls. 

Sockboy: <XnsACC9F360B2F6CHT1@z9kfcl9n7KHDpF0eI.64L>
     -----
     Yea, I call bullshit on that. Driver media doesn't have a valid
     boot sector present. As a result, the machine wouldn't have
     refused to reboot because the disk was left behind.
     -----

A reasoned response would be for you to just note your error -- of course 
you were wrong to say "the machine would not have refused to reboot because 
the disk was left behind." That is in fact exactly what was happening.

And you were wrong to say I suggested this was true of machines other 
than the one being noted in Carroll's trolling. 

- 
Curious how these posts are made? www.youtube.com/watch?v=0ZNxaaKD7-c

[toc] | [prev] | [next] | [standalone]

#70684 — Re: "while(1);" borks Visual Studio.

On Monday, August 16, 2021 at 7:06:44 AM UTC-7, Soviet_Mario wrote:
> Il 09/08/21 06:19, rbowman ha scritto:
> > On 08/08/2021 07:11 PM, Jeff-Relf.Me@. wrote: 
> >> Bowman: 
> >>> I'm not a power user of the VS editor but 
> >>> 35 years later it seems to lack the features of Brief. 
> >> 
> >> My macros & extensions to Visual Studio 2019: 
> >> http://Jeff-Relf.Me/Macros.HTM 
> >> 
> >> In Visual Studio, I'm editing a small, recently opened 
> >> text file. 
> >> AutoRecover is turned off. 
> >> 
> >> For that, it's consuming 1.8 gigabytes of RAM, and growing 
> >> rapidly; 
> >> occasionally, it drops back down to "just" 1.2 gigabytes. 
> >> 
> >> Just now, it disappeared from the task manager altogether, 
> >> showing up again only after ReStarting the task manager. 
> >> 
> >> Every time I debug my app, memory usage goes up, 
> >> briefly topping 2 gigabytes, _after_ exiting the 
> >> app/debugger. 
> >> Hmmm... it's a memory leak, apparently. 
> >> 
> >> I ReStarted Visual Studio, now it's consuming 186 megabytes, 
> >> no more memory leaking. 
> >> 
> >> "while(1);" borks Visual Studio, apparently. 
> >> 
> > 
> > It would tend to do that. Even a more complex while 
> > statement that doesn't have any natural points where it will 
> > block will try for 100% of the cpu. At least now it only 
> > ties up one core.
> It is not selfevident to me why an infinite loop should be 
> supposed to eat up RAM ... 
> CPU time maybe yes, but why high RAM consumption ? 
> 
> Recursion of calls to procedures consumes RAM (even if on 
> many compilers that don't let grow limitlessly automatic 
> memory, but the stack has a maximum size and then the 
> overflow kills badly the process : the stack overlaps and 
> collide with read only data, with "code", with areas 
> belonging to other processes, seg-faulting, etc). 
> 
> To produce similar leaks, I think (I'm just saying an 
> opinion, not a truth) some conditions might operate : 
> 
> an infinite recursion of calls to procedures that have a 
> very limited (or negligible) stack signature (i.g. no 
> parameters passed, maybe not even a return value) and 
> internally performing some heavy "dynamic allocation, i.g. 
> by specialized constructors or else). 
> 
> also routines that works on objects encapsulating arrays 
> that assume to pass By Value (not by pointer or reference), 
> when called in nested mode, will need to copy large amount 
> of data, in dynamic ram. 
> 
> Or even some mis-written or generated "destructors" that 
> don't clean-up properly dynamically allocated objects (i.g. 
> bad string allocators in programming manipulating a lot of 
> rw strings). Or both. 
> A memory leak can have a lot of fathers and mothers. But, 
> imho, not a simple infinite loop in itself. 
> 
> 
> If i think sth like this 
> 
> String A = ""; 
> while (1) 
> A &= "x"; 
> 
> the memory usage would explode, sure, depending on the 
> placement of the chained string A .... 
> 
> 
> 
> 
> 
> -- 
> 1) Resistere, resistere, resistere. 
> 2) Se tutti pagano le tasse, le tasse le pagano tutti 
> Soviet_Mario - (aka Gatto_Vizzato)


I've been scanning a bit from some of those old threads he was previously 
running from. I noticed that many of those he'd go out of his way to again 
and again attack had broad high-tech knowledge. I did not find many who 
were also competent in the scripting side of things, or were also trained 
as an electrician along with various aspects of IT; with the degrees to 
back it all up, too. Kaspersky was initially written and scripted using 
a pirated copy of MonoDevelop, in ActionScript. 

At times, an inner world is more valuable than truth. I'm getting a lot 
of killed files. I'm guessing the troll is proving the advocates right 
again. Yawn. Same old brain-dead trolls. 

--
Top Six Ways Gregory Hall Trolls
https://www.bing.com/search?q=steve%20carroll%20narcissistic%20bigot
https://duckduckgo.com/?q=Dustin%20Cook%20functional%20illiterate%20fraud
Dustin Cook is a functional illiterate fraud

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | alt.os.linux

csiph-web