Lazarus

Miscellaneous => Other => Topic started by: balazsszekely on November 23, 2022, 07:26:21 pm

Title: IRC channel
Post by: balazsszekely on November 23, 2022, 07:26:21 pm
@Joanna
Quote
I miss the old days in irc when many people were talking about pascal. Most people seem to have disappeared from there. Maybe they died of old age? I don’t know  :o
:) again? Please stop infesting the forum with posts about IRC, you already hijacked several threads. It should be pretty obvious by now that people don't want to participate in IRC discussions for various reasons. Why do you keep insisting?

PS: If you still want to talk about IRC, please start a separate thread next time.

Title: Re: IRC channel
Post by: Thaddy on November 23, 2022, 07:31:31 pm
What's wrong with current IRC?
OK, it is old school, but that does not matter.
@Joanna
Let's write a secure IRC chat. We don't need "The Donald" to start our own.
Getmem is atm not invited for dinner.
Title: Re: IRC channel
Post by: Martin_fr on November 23, 2022, 08:18:48 pm
This thread was split off https://forum.lazarus.freepascal.org/index.php/topic,61276.msg461070.html#msg461070

The last thing we need to do is divide people up by age. I didn’t take the survey for that reason.

The important question is WHY did most schools stop teaching pascal ??and how to reverse this trend?

As if the lack of universities and employers supporting pascal isn’t enough, outside of this forum people are constantly attacking and trying to discredit pascal. It’s a rare thing to meet someone new who uses Pascal.


I miss the old days in irc when many people were talking about pascal. Most people seem to have disappeared from there. Maybe they died of old age? I don’t know  :o

A word of clarification
Personally, I deem the above post perfectly reasonable within the bounds of the original thread. However, the potential (and in my experience likely) subsequent discussion (picking on that single last line of the post) breaks those bounds
Title: Re: IRC channel
Post by: balazsszekely on November 23, 2022, 09:00:31 pm
Just to prove my point...
Please take a look at the following thread: https://forum.lazarus.freepascal.org/index.php/topic,60989.0.html and the seemingly innocent reply #7. Then watch how the whole thread degenerate mostly into a futile IRC discussion.
Title: Re: IRC channel
Post by: KodeZwerg on November 23, 2022, 10:09:58 pm
It was fun to read both threads  :D
Title: Re: IRC channel
Post by: Martin_fr on November 24, 2022, 12:16:02 am
Just to prove my point...
It's exactly what I said => "in my experience likely".
Context: Looking at the post for this thread, just expressing a sentiment does not derail a thread. It requires answers (Oh and yes, they will come: "in my experience likely").



The sentiment was not entirely offtopic. Several people in the thread had made references to the past (when Pascal was taught, etc). So has IRC added to the popularity? Was there a different set of mind?
It also was only a minor part of the overall post.



Btw, we are derailing this thread now....

So for those who want to reply on IRC, let's go back to that.
Title: Re: IRC channel
Post by: Joanna on November 24, 2022, 01:18:14 am
Hi sorry for causing so much trouble.  O:-)
I kind of think of pascal programming and chatting about it in irc to be one activity. Yes I understand that it’s possible to use pascal or irc independently of eachother but it’s hard not to notice that the use of both is discouraged outside of this forum.
I now believe that freenode was destroyed on purpose to get rid of irc usage. Around 45000 people were lost and never made it to Libera.
Libera is not freenode. A lot changed for the worse after the move. People moderating some of the popular channels were replaced by people who allow all sorts of things that they shouldn’t. I believe that some of Libera staff have been meddling  with how people operate their channels.

I apologize if my promotion of irc annoys some people but this is the only good source of pascal programmers that I know of and I have a fading hope that some who don’t know about irc would want to come talk there.

Title: Re: IRC channel
Post by: alpine on November 24, 2022, 10:33:06 am
I apologize if my promotion of irc annoys some people but this is the only good source of pascal programmers that I know of and I have a fading hope that some who don’t know about irc would want to come talk there.

Apologies for my ignorant question, I'm not an IRC user, but what is the actual story? For me, technically there is no big difference between IRC channels and, e.g. Discord channels, but obliviously there is a big background behind this freenode/libera thing.
AFAIK an "Unofficial FreePascal" Discord server exists - can it be used for the same purpose?
Title: Re: IRC channel
Post by: Bogen85 on November 24, 2022, 10:37:13 am
AFAIK an "Unofficial FreePascal" Discord server exists - can it be used for the same purpose?

It exists, and the community there is fairly active, and lots of beginners to pascal come regularly and get help.

There are several long time pascal users there, and they are able to provide a lot of help to those that need it.
Title: Re: IRC channel
Post by: Bogen85 on November 24, 2022, 10:43:50 am
Apologies for my ignorant question, I'm not an IRC user, but what is the actual story? For me, technically there is no big difference between IRC channels and, e.g. Discord channels, but obliviously there is a big background behind this freenode/libera thing.

Some prefer a richer text environment, for sharing code snippets/examples without having to reply on other gist/paste sites. Being able to use markdown code formatting and go back and edit your code is beneficial to many.
Title: Re: IRC channel
Post by: alpine on November 24, 2022, 10:54:08 am
Apologies for my ignorant question, I'm not an IRC user, but what is the actual story? For me, technically there is no big difference between IRC channels and, e.g. Discord channels, but obliviously there is a big background behind this freenode/libera thing.

Some prefer a richer text environment, for sharing code snippets/examples without having to reply on other gist/paste sites. Being able to use markdown code formatting and go back and edit your code is beneficial to many.
Yeah, that is probably another point in the favor of the Discord channels. As I said, I'm not an IRC user and don't know it's deficiencies.
Title: Re: IRC channel
Post by: KodeZwerg on November 24, 2022, 11:09:21 am
Since an Image can tell more than a thousand words, I quickly made one to show you a little discord workflow.
Title: Re: IRC channel
Post by: alpine on November 24, 2022, 11:16:45 am
Since an Image can tell more than a thousand words, I quickly made one to show you a little discord workflow.

Even more that the Discord is promoted as the "gamers choice" - I can recall how I got interested in the programming a long time ago - after wondering how the games I like to play were made actually.
Title: Re: IRC channel
Post by: Joanna on November 24, 2022, 12:45:12 pm
Hi y.ivanov
There are several major differences between Irc and other similar purpose social media platforms

0. Irc doesn’t require a phone number or email address in order to go there and talk. It’s up to the channel owners whether unregistered users can join a channel. it’s also possible for channel ops to waive registration requirements.

1. Irc lets you choose or create whatever client you want. Discord and others force you to use Their proprietary Spyware client Which collects and monetizes your data as a business model.

2. Irc gives the people who use it more control and can have a chance of a good user interface if you choose/create a good client. Discord has a horrible user interface and doesn’t resize very well. It was impossible to ignore people in discord last time I checked. It informs you everytime they talk.

3. Irc uses low bandwidth and has no voice chat photos and other nonsense. Discord uses a lot of computer resources and I’ve had it max our my cpu before.

4. Discord saves offline chats irc requires you to always be online or use a bouncer or other resources that record things you missed including channel logs.
I don’t see the point of never missing chatter in a chat channel it’s exhausting to try to catch up. it’s better to use forums for asynchronous communication they are much better organized.

5. Irc doesn’t have voice chat and people can’t show you photos you don’t want to see in the channel everything is done by links to share things like photos or text instead of cluttering channel with them.

IRC was the original chat platform long before all the others. There is nothing wrong with it at all as long as you have good people in your channel who are reasonably active.
Title: Re: IRC channel
Post by: KodeZwerg on November 24, 2022, 01:18:16 pm
0. Irc doesn’t require a phone number or email address in order to go there and talk. It’s up to the channel owners whether unregistered users can join a channel. it’s also possible for channel ops to waive registration requirements.
To avoid spam-bots/trolls on discord, I do like that things must have an unique ID.

1. Irc lets you choose or create whatever client you want. Discord and others force you to use Their proprietary Spyware client Which collects and monetizes your data as a business model.
You can use Discord client or whatever Webbrowser is installed on your system = a more easy way to getting started you can not have with whatever your device is.

2. Irc gives the people who use it more control and can have a chance of a good user interface if you choose/create a good client. Discord has a horrible user interface and doesn’t resize very well. It was impossible to ignore people in discord last time I checked. It informs you everytime they talk.
Since I never had that issue (i can very easy mute persons or whole "channels")

3. Irc uses low bandwidth and has no voice chat photos and other nonsense. Discord uses a lot of computer resources and I’ve had it max our my cpu before.
Bandwidth depend on how many servers you joined and if you let them auto-update or like i, servers do nothing until i tell.
Max CPU?? I assume you was using some alpha kind of client.

4. Discord saves offline chats irc requires you to always be online or use a bouncer or other resources that record things you missed including channel logs.
I don’t see the point of never missing chatter in a chat channel it’s exhausting to try to catch up. it’s better to use forums for asynchronous communication they are much better organized.
Discord helps me to save energy, I do not need 24/7 to have something running to really get "all" messages and what I read or skip depend on me.
Last time I checked IRC/bouncers, it told me something like "you need to be registered for at least XX month...."

5. Irc doesn’t have voice chat and people can’t show you photos you don’t want to see in the channel everything is done by links to share things like photos or text instead of cluttering channel with them.
(De)-Activate image support is done by one easy setting, what I try to say is, when you hate multimedia and want to save bandwidth, just turn it off  O:-)
The possibility to quick share some image/video or going into a voice chat I do never want to miss again.

Why I use Discord and not IRC? Watch above image and you understand. Feel free to attach a screenshot of IRC to have something we can compare.
Anyway, this should not be a discussion about what is better or worse, both have their right in existence.
Title: Re: IRC channel
Post by: KodeZwerg on November 24, 2022, 01:36:45 pm
Discord uses a lot of computer resources and I’ve had it max our my cpu before.
I just show you my current running Discord CPU usage. Its like 98% less than what you try to tell.
Title: Re: IRC channel
Post by: Joanna on November 24, 2022, 01:46:44 pm
Hi KodeZwerg
I remember you in Irc back in 2019. It’s a shame you stopped coming.

There are ways to whitelist desirable people in irc and give them access to a channel. IRC gives the channel ops more control of channels than discord .

There is no shortage of trolls and spam bots in irc trying to herd us to other platforms where we can be monetized but there are ways to stop them.

I tried discord back when it first came out and hated it. It wouldn’t even let me control the appearance of the client. The client and web browser discord look equally horrible.  Discord wasn’t  designed to work on small monitors and doesn’t resize well.

I know you love discord but do you ever wonder why discord provides a free chat client without advertisements? How do they pay all the salaries of employees do you think? It’s a for profit company doing data mining on people who use it.

I’m not asking you do give up discord but you could also use irc too whenever you are around.
Title: Re: IRC channel
Post by: Joanna on November 24, 2022, 01:49:44 pm
I think it was some bug that made it max out my client. I was clicking around in the voice chats. I’m curious does discord demand a phone number now?
Title: Re: IRC channel
Post by: KodeZwerg on November 24, 2022, 02:05:47 pm
I think it was some bug that made it max out my client. I was clicking around in the voice chats. I’m curious does discord demand a phone number now?
Okay, I admit, when I click like crazy fast over all servers I am on, of course the CPU gets more heated up (25% would be max for updating stuff)
Running voice/video chat(s) will be than of course do some more additional payload your device.
When using client, a number is a must. Via Webbrowser you can also go anon online but most discord servers only accept registered users (your phone number) and very serious running servers wants you to do 2 step authentication (you need to transmit a code send to your email / phone or other 3rd party authentification app)
Title: Re: IRC channel
Post by: KodeZwerg on November 24, 2022, 02:58:27 pm
Hi KodeZwerg
I remember you in Irc back in 2019. It’s a shame you stopped coming.
It was fun while I was there, agreed  :-*

Discord wasn’t  designed to work on small monitors and doesn’t resize well.
I actual can not really comment that since I use at my workstation a very large display and on my little mobile it scale wonderful.

I know you love discord but do you ever wonder why discord provides a free chat client without advertisements? How do they pay all the salaries of employees do you think? It’s a for profit company doing data mining on people who use it.

I’m not asking you do give up discord but you could also use irc too whenever you are around.
Love would be the wrong word, discord has more comfort to me.
No, I do not think about such, I just stupid use  %)
Also I do not think about what is happening with code that I share on this forum, I just enjoy using it  O:-)
I might pop up one day again on IRC, nobody knows what the future brings us  :P


I apology to everybody for that Discord vs IRC text and will stop now talking about   :-X
Title: Re: IRC channel
Post by: Joanna on November 24, 2022, 03:04:02 pm
Quote
When using client, a number is a must. Via Webbrowser you can also go anon online but most discord servers only accept registered users (your phone number) and very serious running servers wants you to do 2 step authentication (you need to transmit a code send to your email / phone or other 3rd party authentification app)

That sounds horrible,  well it only reenforces my data mining theory. I want nothing to do with two factor authentication just to have a chat about pascal. People should not have to buy a cell phone and subscription just to be allowed to chat about pascal or anything else for that matter. When people have your cell phone number they can track everything you do potentially. That is completely unacceptable.  Can you even have a cell phone without government ID if not that is even worse. Government being the gate keeper of your being allowed onto social media is a slippery slope which leads nowhere good.
Title: Re: IRC channel
Post by: Joanna on November 24, 2022, 03:09:27 pm
I hope to see you again in irc. I remember when you suggested putting const on all my non changing parameters and it gave me a lot to do.
Title: Re: IRC channel
Post by: Martin_fr on November 24, 2022, 03:39:06 pm
And going off topic again (sorry)...

I remember when you suggested putting const on all my non changing parameters and it gave me a lot to do.

Which btw, you don't blindly want to apply to managed types (ansistring, dyn array). They do save some time for those cases. But they can also lead to crashes, or unexpected results.

Code: Pascal  [Select][+][-]
  1. program Project1;
  2. {$mode objfpc}{$H+}
  3. uses SysUtils;
  4.  
  5. var s: Ansistring;
  6.  
  7. procedure Foo(const arg: Ansistring);
  8. begin
  9.   s := copy(inttostr(random(10)+10), 1, 1);
  10.   writeln(arg);
  11. end;
  12.  
  13. begin
  14.   s := copy(inttostr(random(10)+30), 1, 2);
  15.   writeln(s);
  16.   Foo(s);
  17.   readln;
  18. end.
  19.  

Depending on the settings you compile that with, it is highly likely that "writeln(arg);" does not print the same value as "writeln(s);" did (even so, you might expect it too).
In rare cases it may crash.

Note the "copy(inttostr..." that is needed so the compiler does not eval at compile time.
Title: Re: IRC channel
Post by: Joanna on November 25, 2022, 01:23:45 am
Hi Martin, I used the const for mostly simple things that were not supposed to change. I am not sure how the executable code is different with or without the const in parameter.

That was an interesting example. The const parameter probably keeps it from being changed inside of the procedure but of course since the const parameter references the variable that was changed it would have new value. This is probably why global variables should be avoided.
Title: Re: IRC channel
Post by: Martin_fr on November 25, 2022, 01:33:38 am
See here: https://forum.lazarus.freepascal.org/index.php/topic,41857.msg291278.html#msg291278

A few other notes (those are compiler internals, that can change in future)
- const for integer may not do anything at all (other than giving you an error if you try to write to the param
- const allows large records to be passed as pointer to the callers data (since the data is not going to be changed / neither in the param, nor via a global var, nor otherwise)
  This saves copying the memory of the record
- const for strings (and dyn array / all managed ref counted types), allows to "not increase the ref count". That does save time. But it also means that other code doesn't know you have a copy of the string (and so if the string is modified, its memory can be reallocated and the param is invalid after that)


And your conclusion is (nearly) spot on
Quote
but of course since the const parameter references the variable that was changed it would have new value.
Since ansistrings are already pointers to the text, the param would be a copy of the pointer. So that copy in the param would not change. But the text to which is pointed was changed (it was moved elsewhere in mem).

Basically your ansistring was downgraded to pchar in the parameter.
Title: Re: IRC channel
Post by: Joanna on November 25, 2022, 02:36:38 am
The idea of using const to avoid copying the record seems good.
Although it seems slightly misleading being able to send a const record in which the fields inside the record can change?. I haven’t tried with records but object fields can change.
I’m curious if there is a way to prevent fields inside objects or records from changing in that situation..
Title: Re: IRC channel
Post by: Martin_fr on November 25, 2022, 05:24:54 am
The idea of using const to avoid copying the record seems good.
Although it seems slightly misleading being able to send a const record in which the fields inside the record can change?. I haven’t tried with records but object fields can change.
I’m curious if there is a way to prevent fields inside objects or records from changing in that situation..

"object" => You mean instance of a "type TFoo = class" ? (Because there is "type TFoo = object" which is more record like).

Instances are accessed via a pointer. So const only stops you from assigning another instance.

Code: Pascal  [Select][+][-]
  1. type TFoo = class F1: integer; end;
  2. var a,b: TFoo;
  3. begin
  4.   a := TFoo.Create; // allocates mem for the instance, assigns a pointer to the mem to a
  5.   b := a; // assigns the pointer to b (a and b point to the same data)
  6.   b.F1 := 3; // also affects a.F1
  7.  

Code: Pascal  [Select][+][-]
  1. procedure bar(c: TFoo);
  2. begin
  3.   c.F1 := 11; // affects the callers instance too / only the pointer is passed in c - it points to the same memory
  4.   c := TFoo.create; // does not affect the caller // new memory, and pointer goes into c
  5. end;
  6.  
  7. procedure xyz(var c: TFoo);
  8. begin
  9.   c.F1 := 11; // affects the callers instance too // affects the data pointed to // does not affect the pointer in c
  10.   c := TFoo.create; // does ALSO affect the caller // because "c" is var. So modifying "c" also modifies the caller
  11. end;
  12.  
  13. procedure xyz(const c: TFoo);
  14. begin
  15.   c.F1 := 11; // affects the callers instance too // does not affect the pointer in c
  16.   c := TFoo.create; // ERROR: attempts to affect the pointer in "c"
  17. end;
  18.  
  19.  
  20. var a: TFoo;
  21. begin
  22.   bar(a);
  23.   xyz(a);
  24.  


Title: Re: IRC channel
Post by: trev on November 25, 2022, 07:43:59 am
Quote
When using client, a number is a must. Via Webbrowser you can also go anon online but most discord servers only accept registered users (your phone number) and very serious running servers wants you to do 2 step authentication (you need to transmit a code send to your email / phone or other 3rd party authentification app)

That sounds horrible,  well it only reenforces my data mining theory. I want nothing to do with two factor authentication just to have a chat about pascal. People should not have to buy a cell phone and subscription just to be allowed to chat about pascal or anything else for that matter. When people have your cell phone number they can track everything you do potentially. That is completely unacceptable.  Can you even have a cell phone without government ID if not that is even worse. Government being the gate keeper of your being allowed onto social media is a slippery slope which leads nowhere good.

FWIW, I occasionally use Discord for an MMORPG and I've never provided anything other than a special purpose unique disposable email address with which to logon. Certainly no phone number or any other personally identifying information. ISTR they did check the email address could be verified by sending me a link which is fair enough.

Discord can data mine that all they want but they won't get anything from it :)
Title: Re: IRC channel
Post by: PierceNg on November 25, 2022, 08:02:25 am
FWIW, I occasionally use Discord for an MMORPG and I've never provided anything other than a special purpose unique disposable email address with which to logon. Certainly no phone number or any other personally identifying information. ISTR they did check the email address could be verified by sending me a link which is fair enough.

For at least a year if not longer, Discord did require mobile phone number to register. They wouldn't come right out to say that they want your phone number though. Instead, upon registering and verifying email, when trying to login, Discord kept telling "We've detected something out of the ordinary going on. To continue using Discord, we will need you to verify your account." And the single option presented is to verify by phone. They must've climbed down from this position since recently I could register using just email address.
Title: Re: IRC channel
Post by: Joanna on November 25, 2022, 02:46:58 pm
Hi trev and pierceng
When governments and businesses start to tighten the noose they do it slowly. They kind of get people used to worse and worse demands gradually because people assume that things will stay as they are but things never stay as they are they always get worse.

Just because it’s currently possible to get by with a fake email doesn’t mean that someday you won’t need to have full government biometric ID and not be on a “naughty “ list to be able to use email.

I’ve seen how things transition from not much requiring government approval to just about everything requiring government approval. I’m not trying to vilify the government or big corporations , it’s people who thoughtlessly cooperate that are to blame.

Yes it’s true if enough people refuse to cooperate they would back down and get rid of restrictions but unfortunately people just keep cooperating when it’s really not in their best interest because “everyone else is doing it”

This I why I’m so desperate to save IRC. IRC is one if the few places left where people can get together and talk online with the channel owners being in control instead of a for profit corporation. It’s up to the irc channel  operator to decide what restrictions if any are on channel access. Sure it’s possible to demand people provide phone numbers and call them up everyday but it’s just as possible to create some secret obscure channel and meet there with no restrictions at all or have a public channel where strangers must be registered but friends are whitelisted and can always enter. You can have password protected channels that don’t require any registration also.
Title: Re: IRC channel
Post by: Joanna on November 25, 2022, 03:07:14 pm
Hi Martin
That is some interesting stuff. I vaguely remember being told a long time ago that a parameter without a var would be a copy that could be changed in the body of the procedure but would not be permanent. But var would affect what was being sent directly. The option of the const parameter was never mentioned in beginning pascal class.

Code: Pascal  [Select][+][-]
  1.  procedure bar(c: TFoo);
  2. begin
  3.   c.F1 := 11; // affects the callers instance too / only the pointer is passed in c - it points to the same memory
  4.   c := TFoo.create; // does not affect the caller // new memory, and pointer goes into c
  5. end;
  6.  
  7. procedure xyz(var c: TFoo);
  8. begin
  9.   c.F1 := 11; // affects the callers instance too // affects the data pointed to // does not affect the pointer in c
  10.   c := TFoo.create; // does ALSO affect the caller // because "c" is var. So modifying "c" also modifies the caller
  11. end;

In the last example  it seems it seems like you are detaching the pointer  from c and assigning it to a new location possibly leaving the allocated memory it was pointing to stranded. Does modern pascal have a way to prevent stranded memory that can no longer be accessed? It seems like a memory leak could happen.

Also I’m really not sure how classes are different from objects they both seem to allow the bundling of methods and data. I’m assuming that more can be done with classes. I’ve also noticed that sender is tobject .
Title: Re: IRC channel
Post by: Martin_fr on November 25, 2022, 03:30:27 pm
"var" is a functional change - It allows to modify the callers value.
"const" is a mere optimization - The programmer tells the compiler, that it can optimize under the assumption that the value wont change (including the callers value)

"record" => memory allocated on the stack (except for global vars). If you leave the procedure the memory is freed (result:record is passed by the caller)
"class" => memory is allocated on the heap (like "new(PMyRecord);" where "PMyRecord = ^TMyRecord")

"type TFoo = object ... end" => an advanced record with some (limited) inheritance

"var a: MyRecord" => a contains the entire record (all the fields). "b:=a" will copy all the fields.
"var a: TMyClass" => a contains the pointer to the memory. "a := b" only copies the pointer.

For a class the value of the variable is the pointer only. That means passing it as const requires just  the pointer to be const. Passing it as "var" affects the pointer.



MyClass.Create is like allocmem (or like "New(PFoo)"). You must ensure yourself that the mem is freed. And also take care that any copies of pointer to that mem are not used after the mem was freed.
Title: Re: IRC channel
Post by: Чебурашка on November 25, 2022, 03:45:44 pm
Code: Pascal  [Select][+][-]
  1.  procedure bar(c: TFoo);
  2. begin
  3.   c.F1 := 11; // affects the callers instance too / only the pointer is passed in c - it points to the same memory
  4.   c := TFoo.create; // does not affect the caller // new memory, and pointer goes into c [MEMORY LEAK IN THE LOCAL MEMORY]
  5. end;
  6.  
  7. procedure xyz(var c: TFoo);
  8. begin
  9.   c.F1 := 11; // affects the callers instance too // affects the data pointed to // does not affect the pointer in c
  10.   c := TFoo.create; // does ALSO affect the caller // because "c" is var. So modifying "c" also modifies the caller [THIS MAKES A MEMORY LEAK TO THE INCOMING MEMORY]
  11. end;

In the last example  it seems it seems like you are detaching the pointer  from c and assigning it to a new location possibly leaving the allocated memory it was pointing to stranded. Does modern pascal have a way to prevent stranded memory that can no longer be accessed? It seems like a memory leak could happen.

Also I’m really not sure how classes are different from objects they both seem to allow the bundling of methods and data. I’m assuming that more can be done with classes. I’ve also noticed that sender is tobject .
Title: Re: IRC channel
Post by: Martin_fr on November 25, 2022, 04:27:54 pm
I’ve also noticed that sender is tobject .
TObject is a class.

But the naming is partly messy.

In modern pascal the word (but not keyword) "object" is usually used for "instance of a class". That is the result of "TFooClass.create();"

However we also have the keyword "object" (aka old-style object), which also describes an object. Just a completely different one.
That keyword "object" is rarely used today (since there are advanced records).
There are still differences... Note that those old objects also come with some pitfalls if you use them with inheritance....
(So don't bother about them, just be aware that they exist and therefore the English word "object" is ambiguous)

"keyword object" => the variable (like with a record) does contain all the fields. No memory needs to be allocated (other than that which already is in the variable), and there is no pointer.
So you don't need to "create an instance" (well one could say, you do that by declaring the variable...).

Title: Re: IRC channel
Post by: KodeZwerg on November 25, 2022, 04:39:33 pm
That keyword "object" is rarely used today (since there are advanced records).
...hmmm... I think I use that "rarely old keyword" in every of my classes when I set up custom event handlers...
And I could lay my hand in fire that everyone that uses OOP do the same, custom or via https://lazarus-ccr.sourceforge.io/docs/rtl/classes/tnotifyevent.html (https://lazarus-ccr.sourceforge.io/docs/rtl/classes/tnotifyevent.html).
Title: Re: IRC channel
Post by: Martin_fr on November 25, 2022, 04:53:54 pm
That keyword "object" is rarely used today (since there are advanced records).
...hmmm... I think I use that "rarely old keyword" in every of my classes when I set up custom event handlers...
And I could lay my hand in fire that everyone that uses OOP do the same, custom or via https://lazarus-ccr.sourceforge.io/docs/rtl/classes/tnotifyevent.html (https://lazarus-ccr.sourceforge.io/docs/rtl/classes/tnotifyevent.html).
Ahhh, yes but no-ish...

"of object" - well yes that is also "object" as keyword.

And yes, originally this (likely) refers to the "type TFoo = object ... end;".
Because indeed a procedure/function from such an old style object can be assigned to an "of object".

Then again, "of object" now also comprises the procedures/functions of a class. (And is more often associated with that, than with the old style object)


The issue is that "class" and instances thereof are objects. But they are not the type "object". The word object is ambiguous.
Title: Re: IRC channel
Post by: KodeZwerg on November 25, 2022, 05:10:56 pm
The issue is that "class" and instances thereof are objects. But they are not the type "object". The word object is ambiguous.
Agreed  :-*
Title: Re: IRC channel
Post by: Joanna on November 25, 2022, 11:41:48 pm
I remember there are two different units classes and objects if I remember correctly that contain things called objects and irs easy to get them mixed up.  declaration in uses section gives one priority. I first discovered objects in turbo pascal I’m guessing those were the old style objects. I really don’t like the naming of “advanced records “ to me a record should contain data and nothing else. I’m not even sure how to declare or use an advanced record.
Title: Re: IRC channel
Post by: PascalDragon on November 27, 2022, 10:35:18 pm
I’m not even sure how to declare or use an advanced record.

Enable the modeswitch AdvancedRecords and then simply add methods to records like you do for class or object types.
Title: Re: IRC channel
Post by: Joanna on November 28, 2022, 12:18:26 am
Quote
Enable the modeswitch AdvancedRecords and then simply add methods to records like you do for class or object types.

Is there a reason to use an advanced record instead of an object? What are the advantages over using object?
Title: Re: IRC channel
Post by: Handoko on November 28, 2022, 02:13:25 am
Is there a reason to use an advanced record instead of an object? What are the advantages over using object?
It's already discussed in detail a while ago. You can search the forum if you want to learn more.
Title: Re: IRC channel
Post by: 440bx on November 28, 2022, 02:28:47 am
Is there a reason to use an advanced record instead of an object? What are the advantages over using object?
In a nutshell, an advanced record does _not_ have _any_ polymorphic calls. which means the compiler knows at compile time, which code will be executed when one of its "method"s is invoked.  IOW, there are no indirect or indexed calls to its functions/procedures/methods.

Of course, that advantage comes at the expense of some "disadvantages", for instance, an advanced record cannot inherit from anything nor can it be inherited by something else (which depending your viewpoint, may or may not be a good thing.)

Advanced records are the seed of OOP.  Add a virtual method table and you get objects (or classes), inheritance, polymorphism and another bunch of "goodies" (or not so "goodies" depending on your viewpoint.)

Title: Re: IRC channel
Post by: Joanna on November 29, 2022, 02:21:28 am
Quote
In a nutshell, an advanced record does _not_ have _any_ polymorphic calls. which means the compiler knows at compile time, which code will be executed when one of its "method"s is invoked.  IOW, there are no indirect or indexed calls to its functions/procedures/methods.

Thanks for clarifying. That would be useful for more simple things.
Do objects inherit advanced records? Besides not allowing virtual methods and inheritance, do the advanced records take less resources than a comparable object with same structure ?
Title: Re: IRC channel
Post by: 440bx on November 29, 2022, 03:37:07 am
Thanks for clarifying. That would be useful for more simple things.
You're welcome.  Advanced records are a good choice when 1. you don't need polymorphism, 2. you don't need them to inherit from something and 3. there is no need for something else (object or class) to inherit from them (since an advanced record cannot be inherited from.)  An advanced record is basically a normal record that in addition to listing fields also has a list of functions and procedures that have access (can use) the fields as well as a set of visibility specifiers and possibly a list of properties but, functionally, it pretty much is the same as a record that is restricted to be used by the list of functions, procedures, properties it declares in its body.   Other than the syntactic sugar advanced records provide (properties being the "sweetest" part), anything an advanced record can do can be done with a plain record.


Do objects inherit advanced records?
No but, _conceptually_ an "object" (not a class) can be thought of as the combination of an advanced record and a virtual method table (a VMT, whose existence is what enables inheritance and polymorphism.)

A class is very similar to an object in that it also has a VMT but, unlike an object, a class is always allocated on the heap whereas, both, an object or an advanced record can be allocated _either_ on the heap or, unlike classes, on the stack too.

The fact that a class is always allocated on the heap is what allows the compiler to hide that a class is a pointer (it dereferences the pointer automatically, therefore the programmer doesn't have to type "^" to access the class' fields.)

Besides not allowing virtual methods and inheritance, do the advanced records take less resources than a comparable object with same structure ?
Yes, because an advanced record does _not_ have a VMT, therefore it always uses less memory than an "equivalent" object or class.  That said, in most cases, the additional memory that is taken by the VMT isn't something that is worth losing any sleep over.

Objects were a bit of a problem when stacks were limited to 64K.  Initially, a class was pretty much an object that was always allocated on the heap (which did not have the 64K limit) and, because it was always allocated on the heap, the compiler could hide the fact that the class variable is a pointer by doing automatic dereferencing.  As time went by, classes gained features while objects were left behind (I believe Delphi has deprecated objects but, I could be wrong about that.)

Given that in today's machine, there really is no limit to how large a stack can be, memory is no longer an issue for the old objects.

HTH.
Title: Re: IRC channel
Post by: Martin_fr on November 29, 2022, 09:11:37 am
Quote
In a nutshell, an advanced record does _not_ have _any_ polymorphic calls. which means the compiler knows at compile time, which code will be executed when one of its "method"s is invoked.  IOW, there are no indirect or indexed calls to its functions/procedures/methods.

Thanks for clarifying. That would be useful for more simple things.
Do objects inherit advanced records? Besides not allowing virtual methods and inheritance, do the advanced records take less resources than a comparable object with same structure ?

If an old style object does not have a constructor, nor any methods marked "virtual" then the same is true. (I need to check when/if/how the constructor influences this).


Yes, because an advanced record does _not_ have a VMT, therefore it always uses less memory than an "equivalent" object or class.  That said, in most cases, the additional memory that is taken by the VMT isn't something that is worth losing any sleep over.

Old style objects afaik only get a VMT, if they have virtual methods.


Title: Re: IRC channel
Post by: Joanna on November 29, 2022, 01:20:17 pm
Quote
Old style objects afaik only get a VMT, if they have virtual methods.

That makes sense.  It’s interesting how function calls take stack space but dynamically allocated variables take heap space maybe because the function calls are considered to be more temporary?  I don’t know much about hardware I’m curious about how heap space is implemented compared to stack space? Is stack space RAM?
Title: Re: IRC channel
Post by: 440bx on November 29, 2022, 02:47:36 pm
Old style objects afaik only get a VMT, if they have virtual methods.
Correct.  I should have mentioned that.



It’s interesting how function calls take stack space but dynamically allocated variables take heap space maybe because the function calls are considered to be more temporary? 
The amount of memory used will be the same whether the object is allocated on the stack or the heap because the size of the VMT and the fields that make up the object are independent of where in memory they reside.

The important difference is that if an object resides on the stack then, when the function/procedure/method where it was declared returns then the object "disappears" because the stack pointer is reset to whereever it was before that function/procedure/method was invoked.  If the object resides in the heap then returning from the function/procedure/method has no effect on the existence of the object because heap allocations are not affected by the value  of the stack pointer.


I don’t know much about hardware I’m curious about how heap space is implemented compared to stack space? Is stack space RAM?
Both, heap and stack are plain, standard RAM.  The difference between the two is how they are _managed_.  They are managed _very_ differently.

if you want to learn how things really work then learning a little bit of Assembly language is the way to go.  A set of well known and good tutorials are those of Iczelion, google "iczelion tutorials", note: his tutorials are a bit all over the place on the net because it looks like he no longer hosts them himself.  Learning at least the basics of Assembly language programming will significantly enhance your programming skills and knowledge.  There is a lot to learn but, it's worth the effort.

HTH.
Title: Re: IRC channel
Post by: Joanna on November 29, 2022, 04:08:00 pm
I always thought that there is more memory available on the heap than the stack. Maybe because a “heap” of stuff seems gigantic and a stack seems reasonably small.

Most of my encounters with assembly language are when Lazarus opens it for me to show where the problem occurred. I’ve never really understood it well but it looks interesting.  :D
Title: Re: IRC channel
Post by: 440bx on November 29, 2022, 04:42:54 pm
I always thought that there is more memory available on the heap than the stack. Maybe because a “heap” of stuff seems gigantic and a stack seems reasonably small.
One of the common differences between a heap and a stack is that, normally, the maximum size of a stack is preset at load time whereas a heap can theoretically grow until there is no more address space available.
Title: Re: IRC channel
Post by: Joanna on November 30, 2022, 03:06:41 pm
I’m going to guess that the assembly language that showed in Lazarus was for the stack because it had jmp commands. Does assembly for heap use jump commands at all. It seems like access to heap memory is more random than the stack which follows a certain path then backtracks back to where it started.
Title: Re: IRC channel
Post by: ccrause on November 30, 2022, 04:41:34 pm
I’m going to guess that the assembly language that showed in Lazarus was for the stack because it had jmp commands.

The jmp (https://en.wikipedia.org/wiki/JMP_(x86_instruction)#:~:text=In%20the%20x86%20assembly%20language,by%20changing%20the%20program%20counter.) instruction has to do with code execution flow, not memory access.  I assume you are referring to the x86 instruction set.

A random discussion (https://stackoverflow.com/questions/22091434/how-assembly-accesses-stores-variables-on-the-stack) on how variables are accessed on the stack (example is in C, but similar principles are used by FPC).
Title: Re: IRC channel
Post by: alpine on November 30, 2022, 06:03:21 pm
I’m going to guess that the assembly language that showed in Lazarus was for the stack because it had jmp commands. Does assembly for heap use jump commands at all. It seems like access to heap memory is more random than the stack which follows a certain path then backtracks back to where it started.

Simply speaking, the stack is a data structure which can be manipulated with the help of only two methods: PUSH(X) and POP(X).
It follows the LIFO principle (i.e. Last-In-First-Out) what  means that the value of X you pushed last will be pulled by the next pop.

The thing is that the most processors (but not all), have special instructions for doing that, commonly named PUSH and POP. They work with a dedicated register called SP (stack pointer) which points somewhere in RAM. When you push something, the SP decrements and the value goes written at that location. Resp. when you pop - the value where the SP points will be fetched and the SP will be incremented.

This is very convenient when you want to call a subroutine - the PC (program counter) is a register holding the next instruction for the execution by the processor. Calling a subroutine, CALL Sub is actually PUSH PC i.e. save the program counter onto the stack, then JMP Sub i.e. jump to the address of the subroutine. Subroutines normally ends with a RET instruction which is actually POP PC i.e. get the value from the top of the stack and put it into the PC (program counter). That way the processor will resume execution at the point following the CALL Sub instruction.

That same mechanism is used to transfer the subroutine actual parameters along with the return address, e.g. if you call a procedure foo(1,2,3) then the compiler will generate something like:
Code: Text  [Select][+][-]
  1.  PUSH 1 ; First parameter pushed
  2.  PUSH 2 ; Second parameter pushed
  3.  PUSH 3 ; Third
  4.  CALL foo ; Actual call
(this is a very simplified representation, of course)

Then into the procedure itself, the formal parameters can be accessed as: return address - SP[0], Third parameter - SP[1], Second - SP[2], First - SP[3]. This is why when you modify a parameter it doesn't affect the actual variable given at the call - you actually work with a copy of it allocated on the stack (by pushing its value).

After the procedure finishes, the stack must be cleaned up from the formal parameters, this is done different in different languages (also in FPC, depending on the calling mechanism (https://www.freepascal.org/docs-html/prog/progse22.html)) but the idea is to increment the stack pointer with the same amount as it was decremented at the time after the parameters were pushed. In the example, the inverse of three pushes can be POP AX, POP AX, POP AX - three pops into a scratch register:
Code: Text  [Select][+][-]
  1.  PUSH 1 ; First parameter pushed
  2.  PUSH 2 ; Second parameter pushed
  3.  PUSH 3 ; Third
  4.  CALL foo ; Actual call
  5.  POP AX ; Pop the third parameter
  6.  POP AX ; Pop the second
  7.  POP AX ; Pop the first
  8.  ...
(again, this is a pseudo-code, the actual assembly will differ)

As 440bx said, the stack area (where the SP points) is usually pre-allocated and it is of some predefined size. If you call subroutines with a huge parameters (usually big static arrays) the stack will soon overflow, i.e. the SP will go beyond the boundaries of the pre-allocated RAM chunk.
The same is valid for the local variables of the subroutine - they're also allocated into the stack by manipulating the stack pointer at the time of the call.

All that stack allocation/deallocation is made automatically for you by the FPC compiler. The heap, at the other hand, is different - the allocation is made by you and it is your responsibility to reclaim the memory when it is not needed. When you need some memory then you call GetMem, when you want to free it - FreeMem. When you want a new instance of some class, then you call X:=TSomeClass.Create, when you're done with it, you call X.Free.

The exceptions of that pattern are so called "managed types" - the dynamic arrays and the String type. They also reside at the heap but the compiler takes care for that.

Title: Re: IRC channel
Post by: 440bx on November 30, 2022, 07:06:44 pm
@Joanna,

You got good replies, one of them particularly comprehensive :)

Basically, if you haven't been exposed to how a computer works (CPU, memory, I/O, etc), there are some things that will be difficult to understand.

Becoming really good in Assembly programming is a time consuming task because the programmer is responsible for every detail (unlike when using a compiler like FPC that does a lot for you automatically) but, a basic idea can be had in a reasonable amount of time.

Here are a couple of tutorials you may find useful (picked those because they are quite short):

https://www.tutorialspoint.com/assembly_programming/assembly_tutorial.pdf
https://www.cs.dartmouth.edu/~sergey/cs258/tiny-guide-to-x86-assembly.pdf

after reading those you'll still be quite far from being proficient in Assembly language but, they are  reasonable places to start to understand the most basic concepts (which will always be good for you to know.)

Disclaimer: I only had a very cursory look at both documents.  All I can say is, they seem ok and cover the basics, nothing beyond that.

HTH.


Title: Re: IRC channel
Post by: Handoko on November 30, 2022, 09:24:37 pm
 :o Are you kidding, someone want to learn Assembly?

I has this code, written when I was 14 if I remember correctly:

Code: Text  [Select][+][-]
  1. ; PROCEDURE TULIS (W, B, K : BYTE; S : STRING);
  2. PUSH  DS
  3. PUSH  SS
  4. POP   DS
  5. MOV   BX, SP
  6. MOV   AX, 0050
  7. MUL   BYTE PTR [BX+0A]
  8. MOV   CX, [BX+08]
  9. XOR   CH, CH
  10. ADD   AX, CX
  11. ADD   AX, AX
  12. MOV   DX, B800
  13. MOV   ES, DX
  14. MOV   DI, AX
  15. MOV   AH, [BX+0C]
  16. LDS   SI, [BX+04]
  17. XOR   CH, CH
  18. MOV   CL, [SI]
  19. CMP   CL, 0
  20. JZ    130
  21. INC   SI
  22. CLD
  23. LODSB
  24. STOSW
  25. LOOP  012C
  26. POP   DS
  27. RET   000A

Not exactly, but you can get similarly result by re-writting the code in Pascal:

Code: Pascal  [Select][+][-]
  1. GotoXY(K, B);
  2. TextColor(W);
  3. Write(S);

My first computer was 8088, very slow. And I only got Turbo Basic. I knew TB can import obj files, so for performance reason I wrote the Assembler codes using DEBUG.COM and saved them to obj files. Then I could get much better performance using TB to write text-based and simple graphics games.

TB built-in functions were slow, BIOS functions were not fast enough. So I had to use Assembly to write functions to map the data directly to the hardware memory.

Luckily I later got Turbo Pascal, version 5 if I remember correctly. Then I never touch Assembly anymore because:
- Pascal is many times faster than BASICA, QBasic, QB, TB, etc
- Pascal allow direct port and memory access

But for nostalgic reason, I keep all the codes I wrote in the past.

Anyways, if anyone wants to learn computer hardware programming, I recommend this book, I had it and it really helped me understand how pc works:
https://www.amazon.in/Peter-Norton-Programmers-Personal-Computer/dp/1556151314 (https://www.amazon.in/Peter-Norton-Programmers-Personal-Computer/dp/1556151314)
Title: Re: IRC channel
Post by: 440bx on November 30, 2022, 11:34:08 pm
:o Are you kidding, someone want to learn Assembly?
I suggested she (Joanna) learn some Assembly language in order to have a better understanding of how a computer and a compiler works.

Knowing at least some assembly language programming is still a very useful and valuable skill.  Of course, I would not recommend writing an entire program in Assembly anymore but, for understanding how the hardware and some software works, it's quite appropriate.
Title: Re: IRC channel
Post by: d.ioannidis on November 30, 2022, 11:47:09 pm
Hi,

:o Are you kidding, someone want to learn Assembly?
< snip >

yeap me :-X ( ... no kidding  :D )

I started, a little while ago, to learn AVR assembly for fun :-[  see here (https://forum.lazarus.freepascal.org/index.php/topic,61302.msg461266.html#msg461266) ...

regards,
Title: Re: IRC channel
Post by: Joanna on December 01, 2022, 12:58:31 am
Thanks Everyone for all the useful information.
I’m going to try to read some of those tutorials in assembly. Maybe if the assembler (which I only see when my program has something wrong with it) will not look like jibberish any and give useful hints on what’s wrong. :D
Title: Re: IRC channel
Post by: Seenkao on December 01, 2022, 04:23:08 am
:o Are you kidding, someone want to learn Assembly?
Я изучаю. )))
При чём я стараюсь сопоставить между собой несколько ассемблеров. Для более точного понимания, как происходит работа в той или иной архитектуре.
Здесь можно посмотреть код. (код 456123) x86/x86_64/ARM/ARM64 (https://disk.yandex.ru/d/oBK-BHew7hKFkQ) Единственная проблема, что это пока только на яндекс диске. Позже буду выкладывать на GitHub. Когда материала будет побольше.  :-[

Google translate:
I'm studying. )))
At what I try to compare several assemblers with each other. For a better understanding. how it works in a particular architecture.
Here you can see the code. (code 456123) x86/x86_64/ARM/ARM64 (https://disk.yandex.ru/d/oBK-BHew7hKFkQ) The only problem is that it's only on Yandex disk so far. I'll post it on GitHub later. When there is more material. :-[
Title: Re: IRC channel
Post by: Joanna on December 02, 2022, 01:05:52 pm
I just thought of another question.. is assembly language standardized or are there all sorts of different dialects of assembly language?
Title: Re: IRC channel
Post by: KodeZwerg on December 02, 2022, 01:16:26 pm
I just thought of another question.. is assembly language standardized or are there all sorts of different dialects of assembly language?
Theres a basic set that works on all CPUs and CPU specific ones. And what code does can be OS dependent.
Title: Re: IRC channel
Post by: Bogen85 on December 02, 2022, 01:32:04 pm
I just thought of another question.. is assembly language standardized or are there all sorts of different dialects of assembly language?

Even for x86_64 and i686 (well, all 32 bit and 64 bit  AMD/Intel) there are multiple variants.
AT&T syntax, used by GCC.
Intel syntax.
Nasm.
Fasm.
Yasm.
And likely variants used by MSVC (Microsoft's C compiler), and also others I'm not aware of.
Though for those variants the syntax is mostly the same.

But that is just for AMD/Intel 32/64 processors commonly used on laptops/desktops/servers.

ARM processors are completely different instruction sets, and you have 32/64 bit variants with them, so different assembly language.
MIPS 32/64, different as well.
PowerPC 32/64, different as well.

Of course that is just the tip of the iceberg as far as all the instruction sets in common use.

There is no way you can have a standard assembly language across different instructions sets.
While the syntax may be similar, the mnemonics and operands are specific to the instruction set.

FPC targets aarch64, arm, avr, i386, i8086, jvm, m68k, mips, mipsel, powerpc, powerpc64, sparc, x86_64 (and others), and while there may some overlap between closely related architectures, those are all going to different assembly languages.
Title: Re: IRC channel
Post by: alpine on December 02, 2022, 02:25:15 pm
I just thought of another question.. is assembly language standardized or are there all sorts of different dialects of assembly language?

As the others commented out, it is not standardized in any way and, you may assume that the different processors have also different instruction sets.

But IMO it is not what matters most, what matters is the actual knowledge of how the processor works in general - aka the architecture (of which the instruction set is an integral part  ::) )

For example, my explanation in reply #51 is valid for so called "Princeton architecture" and not so much for some exemplars of the "Harvard architecture". Since the former very much prevails over the latter, it actually isn't worth it pursuing alternative explanations.

Learning assembly language nowadays can be justified only by a purpose to gain enough understanding of the architectural principles, especially from the people intending to use high-level languages as Pascal. Coding in assembly should be considered only in extreme cases, by compiler experts or people who wants to squeeze the last tiny bits of performance (often it is more reasonable to revise your algorithm than to resort to assembly for the latter).

What I think is that maybe instead of learning assembly, a wiki article will be of great help for a novice. An article explaining the calling mechanisms, stack, heap, managed types, etc. Most of the members here are experts and tend to neglect such an (obvious) things at the expense of others, more trendy.

Title: Re: IRC channel
Post by: Kays on December 02, 2022, 02:37:09 pm
I have been following the discussion a while. I wonder, is this (https://forum.lazarus.freepascal.org/index.php/topic,61328.0.html) the lRC channel? Yohoo! Hellooohoohoo, I’m on lRC! 58008. Interdimensional Rogue Community (https://en.uncyclopedia.co/wiki/IRC) rulez!
Title: Re: IRC channel
Post by: Aruna on December 02, 2022, 02:39:38 pm
I just thought of another question.. is assembly language standardized or are there all sorts of different dialects of assembly language?

That is best answered by asking this question first. Does assembly language depend on the CPU?

Assembly language (or Assembler) is a compiled, low-level computer language. It is processor-dependent since it basically translates
the Assembler's mnemonics directly into the commands a particular CPU understands, on a one-to-one basis. These Assembler mnemonics are the instruction set for that processor.

Assembly languages cannot be standardized because each type of computer has a different instruction set and, therefore, a different assembly language.
Title: Re: IRC channel
Post by: Martin_fr on December 02, 2022, 02:56:38 pm
I wouldn't go to deep into assembler.  Each CPU type has there own.
- Intel/AMD
- Apple M1
- various arm...
....

For the stack, you need:

call / ret
which is the kinda origin.
call will push the return address, ret will pop it.

And you want to know what a "stack frame" is.


One step back, and without asm.

Look at the heap - your "unorganized" ram.
It's just a continuous memory, like a set of boxes you can store stuff in.

And the problem is fragmentation:
- you allocate 3 times 10 boxes
- you no longer need the middle block of 10 boxes, you free it, now you have a gap
You can use that gap for anything up to 10 blocks. But not for 11 blocks.

In consequence, if you allocated all your memory in chunks of 10 blocks, and you freed every second such block, then you have thousands of free blocks, yet you can't allocate a consecutive block of 11.

And, if you deal with heap, the mem-manager must keep track of all those blocks.



A stack is continuous.
It is allocated up to a certain address.

If you need to push on it (or generic allocate space), you take that space at the very top (the side with the "certain address") of the stack (no gaps introduced).
If you need a further block, you allocate it again in the same manner.
=> Now you simply can't free the first block before you freed the 2nd.

Example (here I will allocate by increasing / on Intel the stack works downwards, but that doesn't change the concept):
- Your stack start at $0100000
- Your stack pointer (the marker up to were it is allocated) is at the same address $0100000 => the stack is empty
- You allocate $10 bytes, your stack pointer goes to $0100010 ($10 diff to the "stack start")
- You allocate another  $20 bytes, your stack pointer goes to $0100030 ($10 + $20 diff to the "stack start")

Now you can see, you can't free the first $10 bytes, unless you freed the $20 too. Because you can't decrease the stackpointer to $0100000 without freeing the $20 too.
And if you decreased it by $10 from $0100030 to $0100020 you would free half of the $20 instead of the $10 block.

And that is the concept. It makes management easier.


Now as I said, one big use is the return address.

There is also pop/push to add/remove. (obviously the last pushed must be popped first FIFO)

***
And there are stack frames.

if you enter a procedure that has locals, it may need $80 bytes for the locals (all fixed size).

Lets say the stackpointer was at $0100500
- The procedure takes the current $0100500 and stores it as frame base.
- it allocates $80 bytes => stack pointer to $0100580
  Remember those can only be freed if all subsequent allocs have been freed too.
  Nested/called procedures may alloc stack => but will also free it when the return
  And when this function will return, it will be able to free its chunk.
- And this block of memory is now this functions stack frame. The function remembers the address $0100500 independent of the stackpointer (on Inter CPU there is a register for that RSP stack-base / but it's not mandatory to use)

Obviously a dynamic array can't go into this stackframe, because the size of the frame is constant. If you have a local dyn array that is ok, because it is just the pointer. And the data goes on the heap.

Records are fixed size, and can go on the stack-frame

"objects" (instance of class") are NOT fixed size. They could be of an inherited class with more fields. So therefore they are a pointer, and must go on the heap.

"objects" old style are fixed size. And with inheritance that is trouble / and an entire topic of it's own / and a "just keep away from it..."



And thats it.

You avoid fragmentation and managing fragments....

Now you can decide, if you still need asm.


On Intel stacks increase downwards.

So if it starts an $0100000 and you alloc $10 the pointer goes to $00FFFF0 (and your allocated me is from $00FFFF0 to $0100000  / doesn't matter, unless you do asm, or otherwise hack into the stack)






Title: Re: IRC channel
Post by: Martin_fr on December 02, 2022, 03:04:27 pm
In terms of "where is a variable" / how code accesses it.

** If you have a global var "int64"
Allocated at compile time.

During compilation the compiler will allocate a fixed address (in the data segment, which is a pre-allocated part of the heap)
Accessing the var, just generates code
 "load data from fixed address xxxx"

** If you have a local var "int64"
During compilation the compiler will allocate an address by fixed offset in the stack frame.
E.g. 2nd var in the frame may be at framebase+8

Accessing the var, just generates code
 "load data from value-in-frame-base-register + offset xxxx"

** Field in an instance on the heap
This object (of class) can be a global or local.
The object is the address.

In case of a local, the compiler will allocate the space for the address at an offset on the stack base
Accessing then is 2 steps
 "load ADDRESS from value-in-frame-base-register + offset xxxx"
 "load data from ADDRESS + offset for field"




Title: Re: IRC channel
Post by: 440bx on December 02, 2022, 03:19:58 pm
As a number of members have already either mentioned or implied, the purpose of learning Assembler (for a particular CPU) isn't to write entire programs in Assembler.

The main reasons to learn assembly these days, is to _understand_ how a CPU works and to have precise control over it whenever it is needed.  There are times when compilers, even C/C++, do not provide the necessary facilities to exert the necessary control, in those cases Assembly is the solution.

While assembly language is not standardized, CPUs share quite a few characteristics and once you understand how one of them works, most of the concepts carry to others.  The implementation details (which are hardwired in the chip) will usually change but the concepts are readily identifiable.

I believe that if an intermediate level programmer spends a couple of weeks learning the basics of Assembly language programming, that will give him/her a significantly better understanding of how compilers and O/Ss work.    Of course, with just a couple of weeks, you barely knocked on the door but, it's enough to gain basic knowledge about very important concepts.

If you're inclined to learn more, once you've acquired some basic Assembly language skills, read the manufacturer's CPU documentation.  Intel and AMD have published extensive documentation about their processors that ranges from the basics to what you need to know to write a fully capable O/S for them.  Be forewarned, that documentation is more often than not dry as a bone (IOW, definitely not tutorials.) That said, it is quite readable.

Lastly, without getting your hands dirty, you can ask lots and lots of questions but, seeing how all the answers come together to make a coherent whole requires some practice in Assembly.

My recommendation is: do spend a week or two learning the basics of Assembly.  You'll be glad you did.

HTH.
Title: Re: IRC channel
Post by: Seenkao on December 02, 2022, 03:33:21 pm
Coding in assembly should be considered only in extreme cases, by compiler experts or people who wants to squeeze the last tiny bits of performance (often it is more reasonable to revise your algorithm than to resort to assembly for the latter).
По большей части я с вами согласен. Но, когда я делал функцию StrToInt на Паскале - компилятор FPC не полностью её оптимизировал. И когда я делал функцию StrToInt на ассемблере, то я получил намного более оптимизированный код. На Паскале, в данное время, мы не сможем получить подобный код. Я бы наверно сказал даже точнее, ни когда не сможем, если только в ассемблере не появятся какие-то новые функции.

Поэтому это всё зависит от кода, с которым мы работаем. Какой-то код FPC (Delphi, C/C++) сможет достаточно оптимизировать, а какой-то не сможет, как ни старайся. Но программируя только на FPC (Delphi, C/C++), мы этого не сможем  узнать.

Google translate:
For the most part, I agree with you. But, when I made the StrToInt function in Pascal, the FPC compiler did not fully optimize it. And when I made the StrToInt function in assembler, I got a much more optimized code. In Pascal, at this time, we will not be able to get such a code. I would probably say even more precisely, we will never be able to, unless some new functions appear in the assembler.

So it all depends on the code we're working with. Some FPC code (Delphi, C / C ++) will be able to optimize enough, and some will not be able to, no matter how hard you try. But using only FPC (Delphi, C/C++), we won't be able to find out.

I wouldn't go to deep into assembler.
Думаю, выбор должен сделать сам программист.  :)

Eng:
I think the choice should be made by the programmer himself.  :)
Title: Re: IRC channel
Post by: lainz on December 02, 2022, 11:07:03 pm
I like how posts are not following the "IRC channel" theme. Including myself.
Title: Re: IRC channel
Post by: KodeZwerg on December 02, 2022, 11:22:16 pm
I like how posts are not following the "IRC channel" theme. Including myself.
Moderator also  >:D O:-)

From complain about that a person take over a thread, small discord vs irc and look where we are now, assembler yay, again take over with one thing after another, @GetMem :-[
Title: Re: IRC channel
Post by: Bogen85 on December 03, 2022, 12:22:48 am
I like how posts are not following the "IRC channel" theme. Including myself.

Well, this topic largely arose because of someone's desire to use IRC to get FPC/Lazarus help because it is free form and unstructured, and does not need to be formal like the forums.

So this topic thread is being treated as such. A desire to get help, but little desire to follow a structure, and the expectation that others will accommodate.

However, to be most useful forum threads really need to be on topic so that others can do web searches on particular issues and find them in related forum Topic threads.

Others want the forum to be useful. Not only for others to get help, but also as a place to refer back to for questions they may have asked or participated in, so they can search the forums to recall what they had seen before.

IRC lacks all this structure. So even though help can be obtained in an IRC like medium, it is not really useful to refer to back to.

So a lot has to repeated again and again. So for many, they want to stick to forums, as they find IRC to in general not be good time management.

I find the forums far more useful to get help. I can and do bookmark specific Forum posts and replies to refer back to later. So I don't have to keep asking others in chat for information I already had obtained.

In looking for help in the forums I've found answers dating back 10+ years.

Even if I had 10 years worth of IRC logs, sifting and searching them would be verify difficult to find what I'm looking for. Forum posts and replies are expected to be organized in order to be the most usefu.

So this thread even though it has visited several subjects could  "on topic" in the sense it is trying convey the feeling of the conversations in an IRC channel...
Title: Re: IRC channel
Post by: Joanna on December 04, 2022, 01:24:34 am
I have been following the discussion a while. I wonder, is this (https://forum.lazarus.freepascal.org/index.php/topic,61328.0.html) the lRC channel? Yohoo! Hellooohoohoo, I’m on lRC! 58008. Interdimensional Rogue Community (https://en.uncyclopedia.co/wiki/IRC) rulez!
That is a rather satirical commentary in irc. In reality it’s not quite so exciting. The majority of accounts in irc are lurkers who never talk. The experience of being in irc depends upon who is participating in the channel. IRC does have a lot of technical people as well as posers who don’t fare so well when asked technical questions. Some channels have trolls join them for the purpose of discrediting and discouraging usage of whatever the channel is about. There are also are professional influencers who come to irc to promote political agendas. I wish more people who do pascal programming would be active in irc.

 If you are curious about irc why not come try it out on Libera?

Quote
IRC lacks all this structure. So even though help can be obtained in an IRC like medium, it is not really useful to refer to back to.

Irc is a text version of talking or storytelling It’s supposed to be fun, informative and social . Who cares if the same things are talked about more than once? Repetition Is a normal phenomenon and can be good for learning things. It’s ok to bounce around to different pascal related topics in irc or even chat about off topic things sometimes.
I certainly wouldn’t mind chatting about assembly language in irc but the forum allows people in different time zones to participate and that is good as well.  :D

As for assembly language being specific to hardware. Does this apply to the assembly language that pops up in Lazarus? If I’m on different computer would that assembly language be different?  I don’t suppose that there is a way to make assembly language cross platform?

Quote
when I made the StrToInt function in Pascal, the FPC compiler did not fully optimize it. And when I made the StrToInt function in assembler, I got a much more optimized code. In Pascal, at this time, we will not be able to get such a code.
Is there a way to improve the fpc compiler to be as fast for that as assembly language maybe?

Also regarding the problem mentioned about the memory becoming fragmented at runtime how is the memory manager implemented to defragment the heap? Does it slow things down a lot when used?
Title: Re: IRC channel
Post by: Martin_fr on December 04, 2022, 03:11:09 am
As for assembly language being specific to hardware. Does this apply to the assembly language that pops up in Lazarus? If I’m on different computer would that assembly language be different?  I don’t suppose that there is a way to make assembly language cross platform?

Each CPU (type) has it's own assembly language (well, see below)

AMD and INTEL desktop CPU share the same.
Apple M1 is different.
ARM / AVR are different
....


Assembly is the human representation of the "machine code" that is executed by the cpu.
So each CPU (type) has a set of machine code.

The human representation can vary.

For example for the Intel/AMD code there are actually 2 common representations.
They both have the same set of commands, but different names, different symbols for the same thing.

Google: intel vs at&t syntax
Title: Re: IRC channel
Post by: 440bx on December 04, 2022, 04:01:27 am
Irc is a text version of talking or storytelling It’s supposed to be fun, informative and social .
real time "chatty" mediums have those characteristics but, for topics that are often centered on problem solving, a static thread of text messages (such as this forum) is usually a much better medium because the progression to the "solution" or best answer isn't simply lost.  Here anyone can go back to the beginning or any other message of interest and see the progression towards the current state.   For anything that is inherently technical, that is a very desirable characteristic.

As for assembly language being specific to hardware. Does this apply to the assembly language that pops up in Lazarus?
Yes but, as @Martin_fr pointed out, the syntax may differ.

If I’m on different computer would that assembly language be different?
Yes, it would because the instructions implemented by two different processors will usually differ and sometimes the differences are _very_ large.

I don’t suppose that there is a way to make assembly language cross platform?
True assembly language ? ... the answer is NO.    That said, C is generally considered a "high level assembler" and it is very portable but C, unlike assembly, does _not_  give the programmer the ability to choose which registers are going to be used to implement an instruction or series of instructions.

Also regarding the problem mentioned about the memory becoming fragmented at runtime how is the memory manager implemented to defragment the heap? Does it slow things down a lot when used?
The slowdown will depend on the level of fragmentation and greatly depend on the algorithms used to manage it.

The best way of managing fragmentation is to _avoid_ it.  Once fragmentation is significant enough to be a concern, it will already be a PITA.

Avoiding fragmentation means, do your own memory management (which is not hard to do at all - if you've learned how to do it, it's like riding a bicycle, you won't even need to use your hands.)

HTH.
Title: Re: IRC channel
Post by: Bogen85 on December 04, 2022, 04:12:36 am
As for assembly language being specific to hardware. Does this apply to the assembly language that pops up in Lazarus? If I’m on different computer would that assembly language be different?  I don’t suppose that there is a way to make assembly language cross platform?

If on a different processor architecture it would be different.

No, it can't be made cross platform. That would be impossible.

See https://godbolt.org/

They only have one architecture there for Pascal (X86-64).

So on the left select Ada, as that example is the closest to Pascal.

And on the right select the architecture (ARM, ARM64, MIPS, MIPS64, POWER, POWER64, POWER64LE, RISCV64, S390X, SPARC, SPARC64, X86-64)

Instruction set architectures are designed by different companies and individuals. There is no standard that architectures must follow as far as the resulting assembly languages.

While there might be some similarities, there is no way to represent all of them in a common format.
They have different instructions, modes, registers, status bits, etc. (some are stack based and not purely register based, and other differences).

Any attempt to make a cross platform output in some common format would make it very difficult for anyone familiar a particular architecture because the designers of that architecture unlikely have published anything for their instruction set according to some common standard, especially when said common standard does not exist.

For more differences between architectures see: https://en.wikipedia.org/wiki/Comparison_of_instruction_set_architectures
Title: Re: IRC channel
Post by: PierceNg on December 04, 2022, 06:42:15 am
Another way to learn this stuff is to read some books. Here's one: Bertrand Meyer's Introduction to Theory of Programming Languages: full ebook now freely available (https://bertrandmeyer.com/2022/09/28/introduction-theory-programming-languages-full-book-now-freely-available/)
Title: Re: IRC channel
Post by: Seenkao on December 04, 2022, 09:12:54 am
I don’t suppose that there is a way to make assembly language cross platform?
Я не думаю, что вам стоит настолько глубоко в ассемблер. Потому что это уже не совсем ассемблер.
Вы можете заглянуть сюда для ознакомления. (https://flatassembler.net/docs.php?article=fasmg)
Я не совсем понимаю, почему многие считают, что ассемблер не может быть кроссплатформенным.

google translate:
I don't think you should go that deep into assembler. Because it's not exactly assembler anymore.
You can look here for a review. (https://flatassembler.net/docs.php?article=fasmg)
I do not quite understand why many people think that assembler cannot be cross-platform.

Quote

Is there a way to improve the fpc compiler to be as fast for that as assembly language maybe?
Ускорить можно, догнать полностью нельзя.  Но и ускорением надо заниматься. Но на данное время ни кто не занимается. ARM-ассемблер не оптимизирован практически ни на сколько. Указанные проблемы, указанные на багтрекере, связанные с улучшенной компиляцией кода, на данное время не решаются.
Я просто надеюсь, что они хотя бы начали подумывать об улучшении компиляции кода!
Но, думаю, там и без этого проблем хватает.
Лично я влезать внутрь кода FPC не очень хочу. Особенно не зная где и что искать. Мне проще самому написать нужные ассемблерные вставки.
Поэтому, будем ждать. Разница в компиляции между FPC 3.0.4 и FPC 3.2.0 достаточная, чтоб увидеть, что прогресс есть.

Google translate:
You can speed up, but you can't catch up completely. But you also need to accelerate. But for now, no one is doing it. ARM assembler is not optimized in any way. The indicated problems, indicated on the bug tracker, related to improved code compilation, are not solved at this time.
I just hope they at least started thinking about improving code compilation!
But I think there are enough problems without it.
Personally, I don't really want to get into the FPC code. Especially not knowing where and what to look for. It's easier for me to write the necessary assembler inserts myself.
Therefore, we will wait. The compilation difference between FPC 3.0.4 and FPC 3.2.0 is enough to see that there is progress.
Title: Re: IRC channel
Post by: Joanna on December 06, 2022, 12:22:09 am
Quote
real time "chatty" mediums have those characteristics but, for topics that are often centered on problem solving, a static thread of text messages (such as this forum) is usually a much better medium because the progression to the "solution" or best answer isn't simply lost. 
It isn’t about comparing forums to IRC. of course forums have the advantage of being more organized and people online on different dates and times can have a conversation.

IRC has advantages over forums because it’s more likely to learn things you were not expecting to in irc because people happen to be talking about it. Things learned in this way can be useful later. Also as I said before, irc is better for asking about things you know nothing about than forums where people expect you to know the correct terminology for the question you are asking. Irc is more for people interested in a topic who like to talk. Although people with pascal problems do come to irc it is not necessary to have an actual problem to talk about pascal in irc.

As for the discussion of avoiding memory fragmentation with good memory management, how would that be done besides only allocating variables once. I am in the habit of deallocating things as soon as they are out of view and recreating them if needed. Would I eventually use up all the memory?
Title: Re: IRC channel
Post by: Martin_fr on December 06, 2022, 12:49:29 am
As for the discussion of avoiding memory fragmentation with good memory management, how would that be done besides only allocating variables once. I am in the habit of deallocating things as soon as they are out of view and recreating them if needed. Would I eventually use up all the memory?

For your average app => the mem manager does a good enough job. However if you run a server app, expected to run 24/7 all year round, then you may want to take steps.

Though of course some desktop apps may also need it. The memory manager may be good to deal with it, but if you have an app that consumes a lot of memory and you have to add a few percent for ongoing fragmentation, then you may just cross the critical line.

I am not an expert on it - and if you google it, there will probably a lot more.

One effective measure, that is relatively easy done, is to use your own pools for specific data.  (Note that many mem mgr will do that for small chunks already).
If you often instantiate (and then free) a specific class (i.e. all instances have the exact same size). You could allocate a pool of memory fitting 100 such instances.
There be no fragmentation build up, since any gap is guaranteed to be filled by the next alloc (remember: same size => the next alloc will be a perfect fit)

Or pre-allocate chunks of pre-defined sizes for certain task. So you can return the entire chunk when you are done.
You can run that work in a different process => then it wont affect your main processes memory.

Work with as little dynamic alloc as possible.
I wouldn't think about that, unless it's mission critical server software.
Or for embedded and other systems with strictly limit memory.

Title: Re: IRC channel
Post by: 440bx on December 06, 2022, 02:39:53 am
As for the discussion of avoiding memory fragmentation with good memory management, how would that be done besides only allocating variables once. I am in the habit of deallocating things as soon as they are out of view and recreating them if needed. Would I eventually use up all the memory?
Fragmentation occurs because there is a significant variation in the lifetimes of the various entities allocated in a single large global pool (usually a heap.)

One of the first rules to follow to avoid fragmentation is to create separate pools for distinct types of data that usually have similar lifetimes (group by data type which often have similar lifetimes.)  It is not possible to give universal rules because the various pools required are determined by the nature of the problem being solved. 

In Windows, there are two features that greatly simplify memory management. 

One is the ability to create individual, extensible heaps. Those are excellent to keep large numbers of relatively small and heterogenous relatively short lived data that must be accessible in more than one function.  Once the data is no longer needed, the _entire_ heap is destroyed, no piecemeal deletions (which in addition to causing fragmentation are also, the main contributors to memory leaks.)  As a bonus, if the heaps are created in such a way that they are guaranteed to be accessed by only one thread at a time then, they don't need to use a synchronization object which makes allocations and deallocations faster.

The other feature which greatly simplifies memory management in any demand paged O/S (such as Windows and most O/Ss today) is the ability to allocate large blocks of memory but, have the O/S allocate/commit the memory _only_ when it is actually needed/used.  For instance, in 64 bit Windows, a programmer can allocate "n" blocks of 1 GB (that's gigabytes) of memory and after the allocation is done the _total_ amount of memory allocated/used will be "n" x 4 _kilobytes_, the rest will only be allocated by the O/S if and when the program reads/writes to an address in the range.    You can verify that's how much is allocated by Windows using either Process Hacker 2 or Process Explorer (look at the working set size)  For the sake of example, if "n" is 16, the _total_ amount of memory Windows will set aside to cover the 16 blocks of 1 GB each will be a "whopping" 64 kilobytes (16 * 4kb.)

In the above case, it is quite common to see code that only reserves the range then has an _unnecessary_ explicit exception handler to reserve commit more as needed.  The exception handler is unnecessary because because any demand paged O/S does the allocation automatically and only when needed if the memory is also committed in addition to reserved.    The problem is that, it is commonly (and erroneously) believed that if the memory is committed then it will also be entirely allocated during the call that makes the allocation (it does not, most O/Ss will only allocate one page.)

As a bonus, when using virtual memory, the programmer can create multiple regions within a range.  by marking some regions as inaccessible before and after an accessible one, a programmer can more easily test for overruns and errant pointers.

Lastly, it's unlikely that there is another feature that has more potential to simplify code than custom memory management (not to mention making the code faster.)

HTH.
Title: Re: IRC channel
Post by: Joanna on December 08, 2022, 04:45:36 pm
Thanks for the explanation. I’m not sure how to create pools from inside pascal code or is it set somewhere else? If the memory does get too fragmented it seems like it could be de fragmented similar to how a disk is defragmented? Which I assume would involve copying things to temporary locations and then writing them more compactly?
Title: Re: IRC channel
Post by: KodeZwerg on December 08, 2022, 04:56:56 pm
You should not deal with memory at all, that does do the memory manager for you.
Title: Re: IRC channel
Post by: 440bx on December 08, 2022, 05:54:32 pm
Thanks for the explanation.
You're welcome but, the problem is that just about any explanation will be deficient in some way because correct memory management is dependent on the situation.   All that can be accurately exposed are the methods but, their correct application depends on, as previously stated, the situation at hand.

I’m not sure how to create pools from inside pascal code or is it set somewhere else?
TTBOMK, there is no mechanism in Pascal, including FPC, to create separate/independent pools of memory.  In Windows those can be created using HeapCreate, HeapDestroy, VirtualAlloc(Ex), VirtualFree for Heaps and Virtual memory respectively.  I know that Linux offers similar functions for Virtual memory management but, I don't know if it offers creation and destruction of heaps.

If the memory does get too fragmented it seems like it could be de fragmented similar to how a disk is defragmented?
Yes, it is similar but, not quite the same.  The difference is mostly based on the fact that on a disk there is an atomic allocation size (usually the cluster, which in Windows is usually 4K), a file can be made of a linked list of clusters.  The file is considered fragmented when the clusters aren't contiguous. 

In memory, particularly heaps, the problem is different.  Free heap blocks, unlike a disk cluster, can vary greatly in size which causes problems when attempting to reuse them: either they may be too small, therefore unusable, or too large which, if used for a smaller structure, means some of the memory is simply wasted.

Which I assume would involve copying things to temporary locations and then writing them more compactly?
there are lots of problems associated with attempting to defragment memory.  It's rarely worth the time or the code.



You should not deal with memory at all, that does do the memory manager for you.
I disagree.  Good memory management is one of the major factors in writing a program that is resource efficient and responsive.  Languages and "systems" (read VMs) that automate memory management for the programmer run into limitations that are a direct result of the "convenience".
Title: Re: IRC channel
Post by: Martin_fr on December 08, 2022, 06:09:49 pm
You should not deal with memory at all, that does do the memory manager for you.

+1 for 99% of cases in Desktop apps...

Thanks for the explanation. I’m not sure how to create pools from inside pascal code or is it set somewhere else? If the memory does get too fragmented it seems like it could be de fragmented similar to how a disk is defragmented? Which I assume would involve copying things to temporary locations and then writing them more compactly?

No, you can't defragment it. (Well not in any practical sense).

If you code allocated some memory for whatever reason, it could have any amount of pointers to it. You can't move that memory, unless you can at the same time update every single of those pointers. So only the code that has the pointers, can "ask if re-allocation would help". But there may be many different bits of code having that pointer, and they would all have to do that together.... => so practically impossible.



The how to manage stuff yourself .... There are many ways. They also often cross over into performance optimization...

Like the earlier mention (by 44bx) of allocating dedicated pages. This can also reduce swapping (if cleverly done).

Examples:

Lists have "capacity", so you pre-allocate what you need, rather than increasing usage in small bits.
So you never have to free those small bits, and you don't create gaps by doing so.

Classes have "newinstance" in which you can allocate the memory.
So if you have a class of which you frequently create and destroy instances, and you know the max you ever have created is 1000, then you allocate the memory for those 1000. You kind of handle that as an array of mem_chunks_with_size_of_the_instance.
This pre-allocated mem, will of course have at times gaps. But due to all chunks (free/gap and used) have the same size, those gaps can always be used. That pre-alloc mem will always be able to hold those 1000 instances.
Of course instead you could create 1000 instance once, and then re-use them without destroying them.
The key is, that you pre-determine the maximum you will ever need.

So the perfect app (for non fragmentation) will never grow allocations (neither in size, nor count).
Determine at the start what you need, allocate it once, and be done with allocating => and then there wont be fragmentation.

From memory / last time I looked at it: "NGINX" does that.
It allocates a fixed amount of "connection" objects. If they are used up, it will refuse new incoming connections.
The sys-admin can configure that amount, before starting the nginx server.
The limit is fine, because normal operation of a webserver should be that if a connection is established, the server is busy (using cpu) computing the response. Since the server has limited amount of CPU (even if indirect by forwarding to other servers, the capacity of which is also fixed), it will only be able to compute so much. So there is no point of accepting new connection, if it is clear that it will be on hold for an excessively too long time. Such connections may as well be refused straight away. And hence the maximum of objects required can be pre-calculated.

On the other hand "Apache" at least version 1, would solve any memory issue by simply restarting each child process at regular intervals. Since each process has its own virtual address space, this solves any mem problem (fragmentation, leaks, ...). It is an expensive operation though.

Title: Re: IRC channel
Post by: Joanna on December 09, 2022, 01:17:51 am
Quote
You can't move that memory, unless you can at the same time update every single of those pointers.
That’s interesting I didn’t think about the pointers being fixed addresses.
If I allocate and deallocate the same 5 classes whose size doesn’t change, will they stay at the same addresses in memory each time?
Title: Re: IRC channel
Post by: 440bx on December 09, 2022, 02:22:15 am
That’s interesting I didn’t think about the pointers being fixed addresses.
If I allocate and deallocate the same 5 classes whose size doesn’t change, will they stay at the same addresses in memory each time?
_maybe_ BUT, you most definitely should _not_ rely on that in any way.

Title: Re: IRC channel
Post by: KodeZwerg on December 09, 2022, 02:55:12 am
You should not deal with memory at all, that does do the memory manager for you.
I disagree.  Good memory management is one of the major factors in writing a program that is resource efficient and responsive.  Languages and "systems" (read VMs) that automate memory management for the programmer run into limitations that are a direct result of the "convenience".
Can you give me an example where you was in need to "defragment" memory? Just to be sure, we are now talking about RAM in this IRC channel thread, right?
Title: Re: IRC channel
Post by: 440bx on December 09, 2022, 03:49:38 am
Can you give me an example where you was in need to "defragment" memory? Just to be sure, we are now talking about RAM in this IRC channel thread, right?
Fragmentation is a symptom of, let's call it, poor memory management and, one of the ways that memory is managed poorly is when a program relies heavily on a single pool of memory (usually the default process heap.)

You could rightfully ask ... what's the problem in relying on a single heap for all memory allocations ? ... fair question.  One of the problems that makes testing and debugging more difficult is that a heap is like an alphabet soup of memory allocations, i.e, all data types are all found in the same bucket in a sequence that can easily have no correlation with the order in which they have been allocated.   This makes it very difficult to visualize what the code did and what it should do next.

Compare that situation, which is the common situation when using a single heap, with that of an application that either, creates dedicated heaps or allocates blocks of virtual memory for specific data types.  IOW, one memory pool per data type.  Among the many advantages are: there is only one data type, that means, no need to mentally identify and separate different structures.  It is common for the structures to be in the order in which they were allocated (except if the program mixes deletes with allocations - which is something that should be avoided.)  Since the bucket (heap) was created by the code, there is a usually a pointer to that bucket that can be used in an external memory viewer to visually verify that everything is as expected as the code is running (unlike when using debugger for the same purpose, a custom heap is always in scope, therefore always inspectable.)

Memory fragmentation in today's O/Ss results in memory being wasted.  Wasting memory is not desirable but considering how much memory is available these days, unless the waste is above 20 percent, I personally wouldn't worry about it.  What I do "worry" about is that "alphabet soup" effect a single memory pool has on data and how much harder it makes testing and program verification (and ensuring there are no memory leaks, among other things.)

To see how bad memory fragmentation can be and the problems it creates, the 16 bit version of Windows is ideal for that.  In that version of Windows, many of the memory allocation routines returned a "handle" to memory, that handle was actually a pointer to a pointer.  the reason it did that is because in 16 bit, fragmentation often got really bad and by returning a pointer to a pointer that allowed the O/S to move memory around, which meant updating the first level pointer but, that wasn't a problem because the application/program wasn't using those pointers, it was using handles which meant that, to have access to the memory block it need to first call APIs such as GloblalLock or GlobalFix.  Memory management in 16 bit Windows was a _mess_ and, that mess was almost entirely due to the fragmentation of a dedicated "generic" memory pool (i.e, a heap.)

Fortunately, things aren't nearly that bad in 32 bit (thank paging  for that) but, having a single memory bucket for all memory management is, let's say, "less than ideal", one of the problems is fragmentation (which results in wasted memory) but, IMO, worse, is all the complications it causes in the _human_ visualization and tracking of data which has a direct impact on program correctness and verification (and performance but, that is a secondary concern.)


Title: Re: IRC channel
Post by: Martin_fr on December 09, 2022, 04:00:11 am
Just to be sure, we are now talking about RAM in this IRC channel thread, right?

You mean, yet another topic? But the thread is called "IRC channel". So we do what one would do on an IRC channel. We chat about this, that and everything else...  ;)
Title: Re: IRC channel
Post by: Bogen85 on December 09, 2022, 04:13:25 am
Just to be sure, we are now talking about RAM in this IRC channel thread, right?

I already answered this.  ::)
https://forum.lazarus.freepascal.org/index.php/topic,61328.msg462496.html#msg462496

That’s interesting I didn’t think about the pointers being fixed addresses.
If I allocate and deallocate the same 5 classes whose size doesn’t change, will they stay at the same addresses in memory each time?
_maybe_ BUT, you most definitely should _not_ rely on that in any way.

It is very rare for the majority of programs that are either interactive or otherwise don't have predictable timing and order of inputs to follow repeatable consistent memory allocation patterns.

Take this program for example (Not the most efficient, but it demonstrates what is going on, and that is only reason I wrote it, to explain what is being discussed)

Code: Pascal  [Select][+][-]
  1. {$mode objfpc}{$H+}
  2. program ClassMemLoc;
  3.  
  4. uses sysutils;
  5.  
  6. type ABCpointers = array [1..25] of pointer;
  7.  
  8. var
  9.   n: integer = 0;
  10.   abc_pointers: ABCpointers;
  11.  
  12. type
  13.  
  14.   BooClass = class
  15.   private
  16.     id: integer;
  17.     tag: string;
  18.   public
  19.     constructor create(const _tag: string);
  20.     destructor destroy; override;
  21.   end;
  22.  
  23.   BooPointers = array of BooClass;
  24.  
  25. procedure track_init;
  26.   var i: integer;
  27.   begin
  28.     for i := low(abc_pointers) to high(abc_pointers) do abc_pointers[i] := nil;
  29.   end;
  30.  
  31. function track(const boo: pointer): string;
  32.   var i: integer;
  33.   begin
  34.     for i := low(abc_pointers) to high(abc_pointers) do begin
  35.       if (abc_pointers[i] = nil) or (abc_pointers[i] = boo) then begin
  36.         abc_pointers[i] := boo;
  37.         case i of
  38.           1: exit(' (pointer  1)');
  39.           2: exit(' (pointer  2)');
  40.           3: exit(' (pointer  3)');
  41.           4: exit(' (pointer  4)');
  42.           5: exit(' (pointer  5)');
  43.           6: exit(' (pointer  6)');
  44.           7: exit(' (pointer  7)');
  45.           8: exit(' (pointer  8)');
  46.           9: exit(' (pointer  9)');
  47.          10: exit(' (pointer 10)');
  48.          11: exit(' (pointer 11)');
  49.          12: exit(' (pointer 12)');
  50.          13: exit(' (pointer 13)');
  51.          14: exit(' (pointer 14)');
  52.          15: exit(' (pointer 15)');
  53.          16: exit(' (pointer 16)');
  54.          17: exit(' (pointer 17)');
  55.          18: exit(' (pointer 18)');
  56.          19: exit(' (pointer 19)');
  57.          20: exit(' (pointer 20)');
  58.          21: exit(' (pointer 21)');
  59.          22: exit(' (pointer 22)');
  60.          23: exit(' (pointer 23)');
  61.          24: exit(' (pointer 24)');
  62.          25: exit(' (pointer 25)');
  63.         end;
  64.       end;
  65.     end;
  66.     result := ' (untracked)';
  67.   end;
  68.  
  69. constructor BooClass.create(const _tag: string);
  70.   begin
  71.     tag := _tag;
  72.     inc(n);
  73.     id := n;
  74.     writeln(format('Boo Create: %s %02d %p %s', [tag, id, pointer(self), track(pointer(self))]));
  75.   end;
  76.  
  77. destructor BooClass.destroy;
  78.   begin
  79.     writeln(format('    Boo Destroy: %s %02d %p %s', [tag, id, pointer(self), track(pointer(self))]));
  80.     inherited;
  81.   end;
  82.  
  83. var
  84.   i : integer;
  85.   a,b,c,d: BooClass;
  86.   bp: BooPointers;
  87.  
  88.   function newBoo(const tag: string): BooClass;
  89.     begin
  90.       result := BooClass.create(tag);
  91.     end;
  92.  
  93. begin
  94.   track_init;
  95.   for i := 1 to 20 do begin
  96.     a := newBoo('a');
  97.     b := newBoo('b');
  98.     c := newBoo('c');
  99.     d := newBoo('d');
  100.     writeln;
  101.     a.free;
  102.     b.free;
  103.     c.free;
  104.     writeln;
  105.     insert(d, bp, length(bp));
  106.   end;
  107.   writeln('free all d');
  108.   for i := low(bp) to high(bp) do begin
  109.     bp[i].free;
  110.   end;
  111. end.
  112.  

Code: Text  [Select][+][-]
  1. $ fpc classmemloc.pas
  2. Free Pascal Compiler version 3.2.2 [2022/08/17] for x86_64
  3. Copyright (c) 1993-2021 by Florian Klaempfl and others
  4. Target OS: Linux for x86-64
  5. Compiling classmemloc.pas
  6. classmemloc.pas(105,26) Warning: Variable "bp" of a managed type does not seem to be initialized
  7. Linking classmemloc
  8. 111 lines compiled, 0.2 sec
  9. 1 warning(s) issued
  10.  

And when run:

Code: Text  [Select][+][-]
  1. Boo Create: a  1 00007FC2EF24C060  (pointer  1)
  2. Boo Create: b  2 00007FC2EF24C080  (pointer  2)
  3. Boo Create: c  3 00007FC2EF24C0A0  (pointer  3)
  4. Boo Create: d  4 00007FC2EF24C0C0  (pointer  4)
  5.  
  6.     Boo Destroy: a  1 00007FC2EF24C060  (pointer  1)
  7.     Boo Destroy: b  2 00007FC2EF24C080  (pointer  2)
  8.     Boo Destroy: c  3 00007FC2EF24C0A0  (pointer  3)
  9.  
  10. Boo Create: a  5 00007FC2EF24C080  (pointer  2)
  11. Boo Create: b  6 00007FC2EF24C060  (pointer  1)
  12. Boo Create: c  7 00007FC2EF24C0E0  (pointer  5)
  13. Boo Create: d  8 00007FC2EF24C100  (pointer  6)
  14.  
  15.     Boo Destroy: a  5 00007FC2EF24C080  (pointer  2)
  16.     Boo Destroy: b  6 00007FC2EF24C060  (pointer  1)
  17.     Boo Destroy: c  7 00007FC2EF24C0E0  (pointer  5)
  18.  
  19. Boo Create: a  9 00007FC2EF24C0A0  (pointer  3)
  20. Boo Create: b 10 00007FC2EF24C0E0  (pointer  5)
  21. Boo Create: c 11 00007FC2EF24C060  (pointer  1)
  22. Boo Create: d 12 00007FC2EF24C080  (pointer  2)
  23.  
  24.     Boo Destroy: a  9 00007FC2EF24C0A0  (pointer  3)
  25.     Boo Destroy: b 10 00007FC2EF24C0E0  (pointer  5)
  26.     Boo Destroy: c 11 00007FC2EF24C060  (pointer  1)
  27.  
  28. Boo Create: a 13 00007FC2EF24C060  (pointer  1)
  29. Boo Create: b 14 00007FC2EF24C0E0  (pointer  5)
  30. Boo Create: c 15 00007FC2EF24C0A0  (pointer  3)
  31. Boo Create: d 16 00007FC2EF24C120  (pointer  7)
  32.  
  33.     Boo Destroy: a 13 00007FC2EF24C060  (pointer  1)
  34.     Boo Destroy: b 14 00007FC2EF24C0E0  (pointer  5)
  35.     Boo Destroy: c 15 00007FC2EF24C0A0  (pointer  3)
  36.  
  37. Boo Create: a 17 00007FC2EF24C0A0  (pointer  3)
  38. Boo Create: b 18 00007FC2EF24C0E0  (pointer  5)
  39. Boo Create: c 19 00007FC2EF24C060  (pointer  1)
  40. Boo Create: d 20 00007FC2EF24C140  (pointer  8)
  41.  
  42.     Boo Destroy: a 17 00007FC2EF24C0A0  (pointer  3)
  43.     Boo Destroy: b 18 00007FC2EF24C0E0  (pointer  5)
  44.     Boo Destroy: c 19 00007FC2EF24C060  (pointer  1)
  45.  
  46. Boo Create: a 21 00007FC2EF24C060  (pointer  1)
  47. Boo Create: b 22 00007FC2EF24C0E0  (pointer  5)
  48. Boo Create: c 23 00007FC2EF24C0A0  (pointer  3)
  49. Boo Create: d 24 00007FC2EF24C160  (pointer  9)
  50.  
  51.     Boo Destroy: a 21 00007FC2EF24C060  (pointer  1)
  52.     Boo Destroy: b 22 00007FC2EF24C0E0  (pointer  5)
  53.     Boo Destroy: c 23 00007FC2EF24C0A0  (pointer  3)
  54.  
  55. Boo Create: a 25 00007FC2EF24C0A0  (pointer  3)
  56. Boo Create: b 26 00007FC2EF24C0E0  (pointer  5)
  57. Boo Create: c 27 00007FC2EF24C060  (pointer  1)
  58. Boo Create: d 28 00007FC2EF24C180  (pointer 10)
  59.  
  60.     Boo Destroy: a 25 00007FC2EF24C0A0  (pointer  3)
  61.     Boo Destroy: b 26 00007FC2EF24C0E0  (pointer  5)
  62.     Boo Destroy: c 27 00007FC2EF24C060  (pointer  1)
  63.  
  64. Boo Create: a 29 00007FC2EF24C060  (pointer  1)
  65. Boo Create: b 30 00007FC2EF24C0E0  (pointer  5)
  66. Boo Create: c 31 00007FC2EF24C0A0  (pointer  3)
  67. Boo Create: d 32 00007FC2EF24C1A0  (pointer 11)
  68.  
  69.     Boo Destroy: a 29 00007FC2EF24C060  (pointer  1)
  70.     Boo Destroy: b 30 00007FC2EF24C0E0  (pointer  5)
  71.     Boo Destroy: c 31 00007FC2EF24C0A0  (pointer  3)
  72.  
  73. Boo Create: a 33 00007FC2EF24C0A0  (pointer  3)
  74. Boo Create: b 34 00007FC2EF24C0E0  (pointer  5)
  75. Boo Create: c 35 00007FC2EF24C060  (pointer  1)
  76. Boo Create: d 36 00007FC2EF24C1C0  (pointer 12)
  77.  
  78.     Boo Destroy: a 33 00007FC2EF24C0A0  (pointer  3)
  79.     Boo Destroy: b 34 00007FC2EF24C0E0  (pointer  5)
  80.     Boo Destroy: c 35 00007FC2EF24C060  (pointer  1)
  81.  
  82. Boo Create: a 37 00007FC2EF24C060  (pointer  1)
  83. Boo Create: b 38 00007FC2EF24C0E0  (pointer  5)
  84. Boo Create: c 39 00007FC2EF24C0A0  (pointer  3)
  85. Boo Create: d 40 00007FC2EF24C1E0  (pointer 13)
  86.  
  87.     Boo Destroy: a 37 00007FC2EF24C060  (pointer  1)
  88.     Boo Destroy: b 38 00007FC2EF24C0E0  (pointer  5)
  89.     Boo Destroy: c 39 00007FC2EF24C0A0  (pointer  3)
  90.  
  91. Boo Create: a 41 00007FC2EF24C0A0  (pointer  3)
  92. Boo Create: b 42 00007FC2EF24C0E0  (pointer  5)
  93. Boo Create: c 43 00007FC2EF24C060  (pointer  1)
  94. Boo Create: d 44 00007FC2EF24C200  (pointer 14)
  95.  
  96.     Boo Destroy: a 41 00007FC2EF24C0A0  (pointer  3)
  97.     Boo Destroy: b 42 00007FC2EF24C0E0  (pointer  5)
  98.     Boo Destroy: c 43 00007FC2EF24C060  (pointer  1)
  99.  
  100. Boo Create: a 45 00007FC2EF24C060  (pointer  1)
  101. Boo Create: b 46 00007FC2EF24C0E0  (pointer  5)
  102. Boo Create: c 47 00007FC2EF24C0A0  (pointer  3)
  103. Boo Create: d 48 00007FC2EF24C220  (pointer 15)
  104.  
  105.     Boo Destroy: a 45 00007FC2EF24C060  (pointer  1)
  106.     Boo Destroy: b 46 00007FC2EF24C0E0  (pointer  5)
  107.     Boo Destroy: c 47 00007FC2EF24C0A0  (pointer  3)
  108.  
  109. Boo Create: a 49 00007FC2EF24C0A0  (pointer  3)
  110. Boo Create: b 50 00007FC2EF24C0E0  (pointer  5)
  111. Boo Create: c 51 00007FC2EF24C060  (pointer  1)
  112. Boo Create: d 52 00007FC2EF24C240  (pointer 16)
  113.  
  114.     Boo Destroy: a 49 00007FC2EF24C0A0  (pointer  3)
  115.     Boo Destroy: b 50 00007FC2EF24C0E0  (pointer  5)
  116.     Boo Destroy: c 51 00007FC2EF24C060  (pointer  1)
  117.  
  118. Boo Create: a 53 00007FC2EF24C060  (pointer  1)
  119. Boo Create: b 54 00007FC2EF24C0E0  (pointer  5)
  120. Boo Create: c 55 00007FC2EF24C0A0  (pointer  3)
  121. Boo Create: d 56 00007FC2EF24C260  (pointer 17)
  122.  
  123.     Boo Destroy: a 53 00007FC2EF24C060  (pointer  1)
  124.     Boo Destroy: b 54 00007FC2EF24C0E0  (pointer  5)
  125.     Boo Destroy: c 55 00007FC2EF24C0A0  (pointer  3)
  126.  
  127. Boo Create: a 57 00007FC2EF24C0A0  (pointer  3)
  128. Boo Create: b 58 00007FC2EF24C0E0  (pointer  5)
  129. Boo Create: c 59 00007FC2EF24C060  (pointer  1)
  130. Boo Create: d 60 00007FC2EF24C280  (pointer 18)
  131.  
  132.     Boo Destroy: a 57 00007FC2EF24C0A0  (pointer  3)
  133.     Boo Destroy: b 58 00007FC2EF24C0E0  (pointer  5)
  134.     Boo Destroy: c 59 00007FC2EF24C060  (pointer  1)
  135.  
  136. Boo Create: a 61 00007FC2EF24C060  (pointer  1)
  137. Boo Create: b 62 00007FC2EF24C0E0  (pointer  5)
  138. Boo Create: c 63 00007FC2EF24C0A0  (pointer  3)
  139. Boo Create: d 64 00007FC2EF24C2A0  (pointer 19)
  140.  
  141.     Boo Destroy: a 61 00007FC2EF24C060  (pointer  1)
  142.     Boo Destroy: b 62 00007FC2EF24C0E0  (pointer  5)
  143.     Boo Destroy: c 63 00007FC2EF24C0A0  (pointer  3)
  144.  
  145. Boo Create: a 65 00007FC2EF24C0A0  (pointer  3)
  146. Boo Create: b 66 00007FC2EF24C0E0  (pointer  5)
  147. Boo Create: c 67 00007FC2EF24C060  (pointer  1)
  148. Boo Create: d 68 00007FC2EF24C2C0  (pointer 20)
  149.  
  150.     Boo Destroy: a 65 00007FC2EF24C0A0  (pointer  3)
  151.     Boo Destroy: b 66 00007FC2EF24C0E0  (pointer  5)
  152.     Boo Destroy: c 67 00007FC2EF24C060  (pointer  1)
  153.  
  154. Boo Create: a 69 00007FC2EF24C060  (pointer  1)
  155. Boo Create: b 70 00007FC2EF24C0E0  (pointer  5)
  156. Boo Create: c 71 00007FC2EF24C0A0  (pointer  3)
  157. Boo Create: d 72 00007FC2EF24C2E0  (pointer 21)
  158.  
  159.     Boo Destroy: a 69 00007FC2EF24C060  (pointer  1)
  160.     Boo Destroy: b 70 00007FC2EF24C0E0  (pointer  5)
  161.     Boo Destroy: c 71 00007FC2EF24C0A0  (pointer  3)
  162.  
  163. Boo Create: a 73 00007FC2EF24C0A0  (pointer  3)
  164. Boo Create: b 74 00007FC2EF24C0E0  (pointer  5)
  165. Boo Create: c 75 00007FC2EF24C060  (pointer  1)
  166. Boo Create: d 76 00007FC2EF24C300  (pointer 22)
  167.  
  168.     Boo Destroy: a 73 00007FC2EF24C0A0  (pointer  3)
  169.     Boo Destroy: b 74 00007FC2EF24C0E0  (pointer  5)
  170.     Boo Destroy: c 75 00007FC2EF24C060  (pointer  1)
  171.  
  172. Boo Create: a 77 00007FC2EF24C060  (pointer  1)
  173. Boo Create: b 78 00007FC2EF24C0E0  (pointer  5)
  174. Boo Create: c 79 00007FC2EF24C0A0  (pointer  3)
  175. Boo Create: d 80 00007FC2EF24C320  (pointer 23)
  176.  
  177.     Boo Destroy: a 77 00007FC2EF24C060  (pointer  1)
  178.     Boo Destroy: b 78 00007FC2EF24C0E0  (pointer  5)
  179.     Boo Destroy: c 79 00007FC2EF24C0A0  (pointer  3)
  180.  
  181. free all d
  182.     Boo Destroy: d  4 00007FC2EF24C0C0  (pointer  4)
  183.     Boo Destroy: d  8 00007FC2EF24C100  (pointer  6)
  184.     Boo Destroy: d 12 00007FC2EF24C080  (pointer  2)
  185.     Boo Destroy: d 16 00007FC2EF24C120  (pointer  7)
  186.     Boo Destroy: d 20 00007FC2EF24C140  (pointer  8)
  187.     Boo Destroy: d 24 00007FC2EF24C160  (pointer  9)
  188.     Boo Destroy: d 28 00007FC2EF24C180  (pointer 10)
  189.     Boo Destroy: d 32 00007FC2EF24C1A0  (pointer 11)
  190.     Boo Destroy: d 36 00007FC2EF24C1C0  (pointer 12)
  191.     Boo Destroy: d 40 00007FC2EF24C1E0  (pointer 13)
  192.     Boo Destroy: d 44 00007FC2EF24C200  (pointer 14)
  193.     Boo Destroy: d 48 00007FC2EF24C220  (pointer 15)
  194.     Boo Destroy: d 52 00007FC2EF24C240  (pointer 16)
  195.     Boo Destroy: d 56 00007FC2EF24C260  (pointer 17)
  196.     Boo Destroy: d 60 00007FC2EF24C280  (pointer 18)
  197.     Boo Destroy: d 64 00007FC2EF24C2A0  (pointer 19)
  198.     Boo Destroy: d 68 00007FC2EF24C2C0  (pointer 20)
  199.     Boo Destroy: d 72 00007FC2EF24C2E0  (pointer 21)
  200.     Boo Destroy: d 76 00007FC2EF24C300  (pointer 22)
  201.     Boo Destroy: d 80 00007FC2EF24C320  (pointer 23)
  202.  

It takes a few iterations for a, b, c to fall into a predictable pattern, but they eventually do.
But this is a contrived example, as one can't actually predict the input order and timing in most programs.
It this case the input is from a loop, and what is being allocated is always the same size, so it is obviously a predictable pattern as to what allocations are requested.

Even so, one can't rely on the allocater falling into this predicable pattern.
The 1, 5, 3 and 3, 5, 1 patterns for a, b, c are what ended up being predicable patterns, but the allocater could have assigned those to d, with may result in no predictable pattern.

Title: Re: IRC channel
Post by: Martin_fr on December 09, 2022, 04:14:15 am
Memory fragmentation in today's O/Ss results in memory being wasted.

Only in today's OS? I though it was a timeless phenomenon, that having memory in a state in which it can't be used meant it was wasted....
Title: Re: IRC channel
Post by: Martin_fr on December 09, 2022, 04:42:32 am
Can you give me an example where you was in need to "defragment" memory? Just to be sure, we are now talking about RAM in this IRC channel thread, right?

The question wasn't directed at me, but heck I'll add some response to it anyway.

Say you are writing a firewall (for a server on the net). And you are required to deliver for 6 or 7 nines availability. That means your app must run continuously for the entire year, ideally for many years without ever being restarted.
You may also be bound to limited hardware. Most firewalls (if they have there own hardware) probably don't come with 100GB of RAM. So you don't even want to have "just 10%" of the RAM stuck in fragmentation.

One benefit of pre-allocating - if you recall my nginx - example: The software knows it has 1000 objects. It has a counter what is used, if it has 0 left, you know exactly when and where the error needs to be handled. There is no "AllocMem" somewhere deeply nested in a subroutine. No need to return that "out of mem" error all the way up to the top level caller.
(Though the benefit on the error handling is a side effect, and you can reach that independent of dealing with fragmentation)

I grant you, that is a pretty special case (and likely a lot of firewalls have some dynamic alloc going on).

And well, I would think that there are lots of programmers (including experienced ones) who don't really know about mem fragmentation (and no, I don't mean JavarScript users / Programmers in a language that has "AllocMem" and "FreeMem").
And of those who know, very few have ever really a reason to think about it.




Title: Re: IRC channel
Post by: 440bx on December 09, 2022, 05:18:46 am
Memory fragmentation in today's O/Ss results in memory being wasted.

Only in today's OS? I though it was a timeless phenomenon, that having memory in a state in which it can't be used meant it was wasted....
Yes, you are absolutely right.  What I meant to emphasize is that in today's O/Ss fragmentation only results in memory being wasted. In previous O/Ss, particularly 16 bit O/Ss, fragmentation could very well result in the program no longer being able to allocate memory.  Getting to that point with a 32 bit or 64 bit O/S is a lot harder and unlikely (particularly in a 64 bit O/S.)
Title: Re: IRC channel
Post by: KodeZwerg on December 09, 2022, 11:54:54 am
I appreciate your answers! @440bx @bogen85 @martin_fr  O:-)
Title: Re: IRC channel
Post by: alpine on December 09, 2022, 01:52:05 pm
I’m not sure how to create pools from inside pascal code or is it set somewhere else?
TTBOMK, there is no mechanism in Pascal, including FPC, to create separate/independent pools of memory.  In Windows those can be created using HeapCreate, HeapDestroy, VirtualAlloc(Ex), VirtualFree for Heaps and Virtual memory respectively.  I know that Linux offers similar functions for Virtual memory management but, I don't know if it offers creation and destruction of heaps.
Actually, there is a way in FPC (also in Delphi) to write your own heap manager. That is the way the fastmm, heaptrc and cmem units were written.
The current FPC heap manager do implement pools at least for a small memory blocks. So and cmem (through msvcrt/clib).
I realized that only when I wrote my own (application specific) MM with extensible pooling and found that it's not giving me the performance benefit I've expected compared to the standard and cmem ones.

If the memory does get too fragmented it seems like it could be de fragmented similar to how a disk is defragmented?
Yes, it is similar but, not quite the same.  The difference is mostly based on the fact that on a disk there is an atomic allocation size (usually the cluster, which in Windows is usually 4K), a file can be made of a linked list of clusters.  The file is considered fragmented when the clusters aren't contiguous. 

In memory, particularly heaps, the problem is different.  Free heap blocks, unlike a disk cluster, can vary greatly in size which causes problems when attempting to reuse them: either they may be too small, therefore unusable, or too large which, if used for a smaller structure, means some of the memory is simply wasted.
With a recent CPU's incorporating VM support hardware and capable of address linearization, the task should be not very different than disk/cluster de-fragmentation. To what extent this is implemented in the operating system and whether this simply pushes the problem to another level is a separate matter. There are known allocation patterns which makes Windows to extend the process commit size beyond the limits.
Title: Re: IRC channel
Post by: 440bx on December 09, 2022, 04:02:10 pm
Actually, there is a way in FPC (also in Delphi) to write your own heap manager.
writing your own heap manager is a very different thing than being able to create multiple heaps which is what I was referring to.  As I stated previously, TTBOMK, FPC does not offer that capability.

With a recent CPU's incorporating VM support hardware and capable of address linearization, the task should be not very different than disk/cluster de-fragmentation.
VM support or otherwise, it is very different.  When the heap receives a request for "n" kilobytes, say for the sake of argument 12kb, a heap _must_ provide a _contiguous_ 12kb whereas a request for the same amount of storage on disk can be filled with 3 clusters of 4kb each.  A heap does _not_ have that luxury.
Title: Re: IRC channel
Post by: PascalDragon on December 09, 2022, 04:56:28 pm
If the memory does get too fragmented it seems like it could be de fragmented similar to how a disk is defragmented?
Yes, it is similar but, not quite the same.  The difference is mostly based on the fact that on a disk there is an atomic allocation size (usually the cluster, which in Windows is usually 4K), a file can be made of a linked list of clusters.  The file is considered fragmented when the clusters aren't contiguous. 

In memory, particularly heaps, the problem is different.  Free heap blocks, unlike a disk cluster, can vary greatly in size which causes problems when attempting to reuse them: either they may be too small, therefore unusable, or too large which, if used for a smaller structure, means some of the memory is simply wasted.
With a recent CPU's incorporating VM support hardware and capable of address linearization, the task should be not very different than disk/cluster de-fragmentation. To what extent this is implemented in the operating system and whether this simply pushes the problem to another level is a separate matter. There are known allocation patterns which makes Windows to extend the process commit size beyond the limits.

You can't defragment the virtual address space as that would need to change the pointers that are stored e.g. in the stack or where ever. You can defragment your own heap only with deallocated areas by combining them again or whatever depending on your heap management algorithm.
Title: Re: IRC channel
Post by: alpine on December 10, 2022, 01:03:47 pm
You can't defragment the virtual address space as that would need to change the pointers that are stored e.g. in the stack or where ever. You can defragment your own heap only with deallocated areas by combining them again or whatever depending on your heap management algorithm.
My point was that, theoretically by using MMU, the fragmentation could be avoided by redirecting/merging physical RAM pages in the address translation table (which could be seen as additional redirection, like handles in GlobalLock). But since the MMU is managed exclusively by the operating system, this is almost impractical unless one is working with the bare metal.
Title: Re: IRC channel
Post by: Joanna on December 11, 2022, 12:44:19 pm
The idea of using handles that point to pointers to memory locations seems  like a good idea. It seems like being able to defragment memory is very important for programs expected to run for a long time without stopping.

The logic of defrafmenting memory seems like it would be fairly simple kind of like defragmenting people in a theatre by making them all scoot over and remove gaps
Title: Re: IRC channel
Post by: 440bx on December 11, 2022, 01:23:06 pm
The idea of using handles that point to pointers to memory locations seems  like a good idea.
It's one of those ideas that seems good at the beginning but, time reveals it's not such a "good idea" in the long run.  The problem is, the program cannot access any memory block without first locking the handle which is what returns a pointer to the memory block.  Locking the handle has the effect of telling the O/S that, that memory block cannot be moved.    Without the program's cooperation, the O/S will usually not be able to achieve a reasonably decent level of defragmentation.  With program cooperation, the O/S should be able to defragment the memory BUT, the problem then becomes the amount of time the defragmentation may take and, timing it in such a way that it doesn't significantly affect its smooth operation.

It seems like being able to defragment memory is very important for programs expected to run for a long time without stopping.
What's really important is to _avoid_ fragmentation to an extent where it becomes a problem.  Once it has become a problem, there is no solution that is free of potentially very undesirable consequences.

The logic of defrafmenting memory seems like it would be fairly simple kind of like defragmenting people in a theatre by making them all scoot over and remove gaps
It's very different than having people scoot over to remove gaps because, in the case of people in a theater there isn't "anyone" keeping track  and _depending_ on where each person is seated (i.e, having a pointer to the person that needs to be updated if and when the person moves.)

It's usually quite easy to _avoid_ fragmentation, it only requires a little bit of upfront thinking about the program's design.
Title: Re: IRC channel
Post by: Bogen85 on December 11, 2022, 01:26:59 pm
The idea of using handles that point to pointers to memory locations seems  like a good idea. It seems like being able to defragment memory is very important for programs expected to run for a long time without stopping.

The logic of defrafmenting memory seems like it would be fairly simple kind of like defragmenting people in a theatre by making them all scoot over and remove gaps

But at a higher level, how does this translate into use by by the data structures and current live stack frames that are using the pointers?

You move memory blocks around in a processor level multi-threaded application everything using those blocks is going to crash.

The handles would then have to essentially be indirect pointers (so regular code is not getting actual pointers any more). Even with them being indirect, there would need to be synchronization to make sure sure nothing is using a live pointer. So something like a stop the world garbage collection sweep. Then on top of that, the handles are now essentially data structures, and what is going to defragment them?

You can't defragment the virtual address space as that would need to change the pointers that are stored e.g. in the stack or where ever. You can defragment your own heap only with deallocated areas by combining them again or whatever depending on your heap management algorithm.
My point was that, theoretically by using MMU, the fragmentation could be avoided by redirecting/merging physical RAM pages in the address translation table (which could be seen as additional redirection, like handles in GlobalLock). But since the MMU is managed exclusively by the operating system, this is almost impractical unless one is working with the bare metal.

If we talking about de-fragmenting at an MMU level, on processor level multi-threading that is still likely going to be stop the world for the process using the region be de-fragmented.


Then there is page size thrown into the mix, and OS level memory allocation and freeing being both expensive time wise (on OSes where crossing the syscall boundry is expensive).
This bug report highlights the page size issue.
https://bugzilla.redhat.com/show_bug.cgi?id=2001569
Quote
Description of problem: At the moment the aarch64 kernel builds of RHEL8 assume a 64kB pagesize, which works fine most of the time. However when trying to run in a  virtualized environment on Apple M1 devices via Parallels Desktop it is not possible to boot RHEL8 because the M1 chips only support 4kB & 16kB pagesizes. Ubuntu and Debian are compatible with Parallels on these devices, so it should be possible for RHEL as well.

On Linux at least (and would likely apply to other *nix like the common BSDs) Because allocation at syscall level is both expensive and not fine grained (you can't just allocate 32 bytes for a string data structure, you need to allocate at least the page size, be that 4K, 16K, or 64K as being discussed in the above bug report) then most language runtime do there own heap management, so the individual pointers to data structures are not mapped at the logical address to physical address MMU translation layer.

As such, the run-times do their own pool management, and often allocation much larger memory pools than what was requested, and don't give those pools back to operating system right away (which is expensive) when data is freed, as they make the memory blocks within those pools available to other parts or your program.

Most of the memory fragmentation being discussed here I'm assuming is taking place at the language runtime level. And de-fragmenting at that level is using logical addresses, not physical addresses.
And just using "handles" everywhere is not a simple solution to the problem, as I discussed at the beginning of this reply.



Title: Re: IRC channel
Post by: Bogen85 on December 11, 2022, 01:28:26 pm
The idea of using handles that point to pointers to memory locations seems  like a good idea.
It's one of those ideas that seems good at the beginning but, time reveals it's not such a "good idea" in the long run.  The problem is, the program cannot access any memory block without first locking the handle which is what returns a pointer to the memory block.  Locking the handle has the effect of telling the O/S that, that memory block cannot be moved.    Without the program's cooperation, the O/S will usually not be able to achieve a reasonably decent level of defragmentation.  With program cooperation, the O/S should be able to defragment the memory BUT, the problem then becomes the amount of time the defragmentation may take and, timing it in such a way that it doesn't significantly affect its smooth operation.

It seems like being able to defragment memory is very important for programs expected to run for a long time without stopping.
What's really important is to _avoid_ fragmentation to an extent where it becomes a problem.  Once it has become a problem, there is no solution that is free of potentially very undesirable consequences.

The logic of defrafmenting memory seems like it would be fairly simple kind of like defragmenting people in a theatre by making them all scoot over and remove gaps
It's very different than having people scoot over to remove gaps because, in the case of people in a theater there isn't "anyone" keeping track  and _depending_ on where each person is seated (i.e, having a pointer to the person that needs to be updated if and when the person moves.)

It's usually quite easy to _avoid_ fragmentation, it only requires a little bit of upfront thinking about the program's design.

You beat me to it and answered more succinctly, thanks!

Title: Re: IRC channel
Post by: alpine on December 11, 2022, 01:36:04 pm
The idea of using handles that point to pointers to memory locations seems  like a good idea. It seems like being able to defragment memory is very important for programs expected to run for a long time without stopping.
It is indeed important.

Bit IMO it is much simpler to pre-allocate memory chunks, put them in a list (aka "pool") and then take it from there when needed and put them back into the pool for latter reuse.

The logic of defrafmenting memory seems like it would be fairly simple kind of like defragmenting people in a theatre by making them all scoot over and remove gaps
Yes, but such a 'house keeping' is a time consuming and introduces unpredictability with regard to the response time, etc. It is better simply to avoid fragmentation instead of dealing with it.

Edit:

@Bogen85
You're pretty fast, I'll need a bit to reaching you.

I think we got too far with that MMU thing, it is clear that the managers are that way for a reason. May be we should point to a more practical patterns for the Joanna questions, e.g. pools, not using dynarrays, etc.

Anyway, putting walls of text is not quite IRC'ish :)
Title: Re: IRC channel
Post by: Bogen85 on December 11, 2022, 01:39:31 pm
The idea of using handles that point to pointers to memory locations seems  like a good idea. It seems like being able to defragment memory is very important for programs expected to run for a long time without stopping.

The logic of defrafmenting memory seems like it would be fairly simple kind of like defragmenting people in a theatre by making them all scoot over and remove gaps

But at a higher level, how does this translate into use by by the data structures and current live stack frames that are using the pointers?

You move memory blocks around in a processor level multi-threaded application everything using those blocks is going to crash.

The handles would then have to essentially be indirect pointers (so regular code is not getting actual pointers any more). Even with them being indirect, there would need to be synchronization to make sure sure nothing is using a live pointer. So something like a stop the world garbage collection sweep. Then on top of that, the handles are now essentially data structures, and what is going to defragment them?
...

On the stack frame issue, that might make this kind of de-fragmentation impossible. (maybe not impossible in theory, but in practice).

Is your de-fragmenteger going to stop the world, unwind every stack frame looking for where the actual memory addresses were extracted and used, and patch the addresses in the frame?

Many processors don't have the support for indirect memory for pointers, so indirect always access could not be enforced.

Also:

Is it going to analyze and patch all CPU level caches for the threads involved to do the same?
Is it going to inspect any swapped out to disk (or to compressed ram disks, aka ZRAM) memory for processes do the same?

All the above makes it horribly complex and very prone to error if not done perfectly.
Title: Re: IRC channel
Post by: PascalDragon on December 11, 2022, 09:40:58 pm
You can't defragment the virtual address space as that would need to change the pointers that are stored e.g. in the stack or where ever. You can defragment your own heap only with deallocated areas by combining them again or whatever depending on your heap management algorithm.
My point was that, theoretically by using MMU, the fragmentation could be avoided by redirecting/merging physical RAM pages in the address translation table (which could be seen as additional redirection, like handles in GlobalLock). But since the MMU is managed exclusively by the operating system, this is almost impractical unless one is working with the bare metal.

Again: that doesn't solve the fragmentation of the virtual address space, which is what your application sees. It already doesn't matter where the physical pages are located, the OS will simply pick the next best free physical memory page for the allocation of a virtual page.
Title: Re: IRC channel
Post by: Joanna on December 12, 2022, 08:38:21 am
Memory indeed is a complex issue. I’m not sure what the history of computer design was that led to the memory becoming so easy to fragment. Stack memory seems so elegant in comparison but that won’t work for randomly allocated/ deallocated things.

Another idea which has probably already been tried is how about marking  addresses  with their size as reusable when finished with them and then when something new is needed just reuse existing piece of memory that is the same size?  This might be ok when there is not too much size variation..
I have no idea how this would be implemented though.

I used to think that freeing things as soon as they weren’t needed would be more efficient for using less memory but after this discussion I’m no longer so sure
Title: Re: IRC channel
Post by: 440bx on December 12, 2022, 09:03:19 am
Another idea which has probably already been tried is how about marking  addresses  with their size as reusable when finished with them and then when something new is needed just reuse existing piece of memory that is the same size?  This might be ok when there is not too much size variation..
I have no idea how this would be implemented though.
That's what the Windows Heap manager does and it imposes some overhead (which is always undesirable.)  The heap manager keeps track of a linked list of freed blocks sorted by size along with 4 pointers into the linked list where each guarantees the size of a free block being greater than or equal to some value (that's how Win9x did it - see Matt Pietrek's Windows Programming Secrets - the management algorithms have been improved in the NT branch of Windows but, the management concepts are still the same.)

The "problem" is, no matter how efficient and fast the management algorithms may be, they still add time to every allocation and deallocation.  The additional time can become a real problem for a multi-threaded program because heap management is inherently single threaded which means time will grow in proportion to contention. 

That's one of the many advantages of doing your own memory management.  Allocations are still single threaded but they usually consist of incrementing a single pointer value which is very fast and quite often, it is possible to structure the problem in such a way as giving each thread it's own block of memory, that way, there is no contention, no fragmentation and speed to burn.  Great stuff :)

I used to think that freeing things as soon as they weren’t needed would be more efficient for using less memory but after this discussion I’m no longer so sure
Actually, the majority of the problems come into existence when allocations and deallocations are mixed.  A reasonably decent solution is, create a heap, put all the data you need in there, don't delete/free anything, once you don't need the data, simply destroy the heap.  That way allocations will be fast because there are no chains of "free space" to search and, if the heap is dedicated to a single thread, it can be told not to use a synchronization object. 

Of course, doing your own memory management requires some work on your part but, in real programs, the benefits greatly outweigh the convenience of "automatic management" (what the compiler does for you.)
Title: Re: IRC channel
Post by: alpine on December 12, 2022, 09:39:31 am
Memory indeed is a complex issue. I’m not sure what the history of computer design was that led to the memory becoming so easy to fragment. Stack memory seems so elegant in comparison but that won’t work for randomly allocated/ deallocated things.
Yes, it is, without a doubt it can be quite complicated.

But all depends on what specific kind of application you're working on. Most of the time there is no need to bother much. But it is always good to have a good insight what is going on behind the scenes. Unfortunately, some of the good things about the OOP contribute in that fragmentation phenomena - namely the container objects grows their size in a logarithmic way, the object instances are always dynamically allocated, the managed objects such as dynarrays and strings are heap based. But there are workarounds if you need to.

Another idea which has probably already been tried is how about marking  addresses  with their size as reusable when finished with them and then when something new is needed just reuse existing piece of memory that is the same size?  This might be ok when there is not too much size variation..
I have no idea how this would be implemented though.
The existing heap manager is doing a decent "pooling" for you, at least for the small chunks. It is really a quite good at that (I had mentioned it before (https://forum.lazarus.freepascal.org/index.php/topic,61328.msg463126.html#msg463126)). But if you're writing a high-availability application it requires very, very careful  planning.

I used to think that freeing things as soon as they weren’t needed would be more efficient for using less memory but after this discussion I’m no longer so sure
That is always a good approach, and it has also additional benefits (https://en.wikipedia.org/wiki/Resource_acquisition_is_initialization#Benefits) e.g. reduces the possibility of leaks, deadlocks, etc.
Title: Re: IRC channel
Post by: Joanna on December 12, 2022, 12:45:29 pm
I do tend to use classes a lot some of which contain strings. I am curious if I change the length of a string stored in the field of a class does that change the amount of memory being used? I think shortstring is limited to 255 chars but string has no fixed length ,so how much memory would be used? Just enough to store it in its current length? Supposed you have a a tmemo and paste a lot of text into it? What happens With memory? Does pasting text allocate memory? Or suppose you create a class containing a tmemo and retrieve the text from an inifile. The class needs less memory before the text is loaded? I’m curious how it all works. If you create another class before loading text to memo it seems like the memory Pertaining to different classes could be intertwined.

I’ve never done a multithreaded application. What are the circumstances which require multiple threads is it for being able to respond to different events while something else is working?
I vaguely remember a command that could be put into a loop to respond to messages . I can’t remember what it was...
Title: Re: IRC channel
Post by: Marc on December 12, 2022, 02:05:08 pm
A string (not a short string) is just a pointer to a piece of memory, which is managed by fpc. The memory of your class doesn't change by this, since your class has just a pointer to it.

If you have a TMemo, and you paste text to it, nothing happens to your class, there is even no memory allocated by fpc/lcl. The text is part of the textwidget your os/window manager provides.
The moment you use the text property of a TMemo, the text is retrieved from that widget, by first allocating a string of enough length, and then ask the widget to copy the text into it. 
This text doesn't change the amount of memory your class needs, but it does change the amout of (heap) memory your application has allocated.

Marc
Title: Re: IRC channel
Post by: alpine on December 12, 2022, 02:40:58 pm
I do tend to use classes a lot some of which contain strings. I am curious if I change the length of a string stored in the field of a class does that change the amount of memory being used? I think shortstring is limited to 255 chars but string has no fixed length ,so how much memory would be used? Just enough to store it in its current length? Supposed you have a a tmemo and paste a lot of text into it? What happens With memory? Does pasting text allocate memory? Or suppose you create a class containing a tmemo and retrieve the text from an inifile. The class needs less memory before the text is loaded? I’m curious how it all works. If you create another class before loading text to memo it seems like the memory Pertaining to different classes could be intertwined.
Short strings (those with the square brackets [] at the end) are fully contained into the declared variable/record/class. From the memory perspective, string[N] can be viewed as array[0..N] of char with zero index being used as the current string length. They are just handled a bit differently than arrays by the compiler (you can concatenate them with + for example). On the other hand, strings declared without square brackets are actually pointers to an internal structure in heap, which holds the contents together with the code-page, current length, reference counter. In the trivial case when the string is empty ('') the pointer is just Nil. They are "managed",  i.e. the compiler internally allocates/reallocates/de-allocates them according to the operations applied. They have copy-on-write (https://en.wikipedia.org/wiki/Copy-on-write) semantics.

Using shortstrings have no implications on heap, at least until you explicitly start to allocate memory via pointers for those strings. But they're copied in their entirety when passed as an argument or returned back from a function.

You can intermix both string types in source but that actually it will lead to more heap operations, since the compiler will automatically convert one type to another using temporaries.
If you're using a library with a functions and/or properties defined as a string (without []), the LCL is such a library, you can't do much about it. But since LCL is for UI, it is not expected the application to work for an indefinite amount of time i.e. it will be closed, restarted, etc. For example web browsers put each tab in a separate process in order to restart them if needed, without affecting the other tabs.

I’ve never done a multithreaded application. What are the circumstances which require multiple threads is it for being able to respond to different events while something else is working?
I vaguely remember a command that could be put into a loop to respond to messages . I can’t remember what it was...
Multithreading is a vast subject which has also close relationships with the memory management, but IMO it shouldn't be involved into the discussion, it will be too much for now.

Edit: A word about the classes: they have a virtual class method newinstance and a virtual method FreeInstance which allocates, resp. de-allocates the instance in heap. They can be overridden in order to implement different means of allocation for each class when needed, i.e. to make pools or use a pre-allocated chunks or whatever convenient.
Title: Re: IRC channel
Post by: Joanna on December 13, 2022, 12:45:44 pm
That Is interesting how pascal handles strings of indetermined length as a pointer to memory in such a way as  to keep allocating more memory as the string is appended to. I’ve heard that other languages are not so smart with string management and have overflows?
It also seems like a program with a lot of strings that come and go could get easily fragmented in memory.

Quote
But since LCL is for UI, it is not expected the application to work for an indefinite amount of time i.e. it will be closed, restarted, etc.
While that might be true in most cases I think that gui programs should be designed to run indefinitely. Restarting things is annoying and sometimes loses data.
Title: Re: IRC channel
Post by: Marc on December 13, 2022, 02:06:17 pm
A good memory manager can handle fragmentation pretty well.
We run D6 services with a lot of IO and string manipulation 24/7 at work. The old D6 manager can't handle that and suffers from fragmentation after several 1M+ operations. Replacing that by FastMM (D7+ standard manager) solves it and has no problem.

Strings are allocated with some extra room, so adding one character won't require a new allocation.

Marc
Title: Re: IRC channel
Post by: alpine on December 13, 2022, 03:04:14 pm
That Is interesting how pascal handles strings of indetermined length as a pointer to memory in such a way as  to keep allocating more memory as the string is appended to. I’ve heard that other languages are not so smart with string management and have overflows?
It also seems like a program with a lot of strings that come and go could get easily fragmented in memory.
Not so easily as some measures were taken already to mitigate the effect. I already pointed out that the current FPC heap manager do pooling and as Marc noted, the strings allocation is made accordingly. 

Quote
But since LCL is for UI, it is not expected the application to work for an indefinite amount of time i.e. it will be closed, restarted, etc.
While that might be true in most cases I think that gui programs should be designed to run indefinitely. Restarting things is annoying and sometimes loses data.
I did not mean that they should be restarted every hour or two, rather only when necessary and it can be done in a way that is not so obvious, e.g. for maintenance, for updating, for improving the service, archiving data, you name it.
Title: Re: IRC channel
Post by: Joanna on December 14, 2022, 03:13:23 am
Strings are allocated with some extra room, so adding one character won't require a new allocation.
I’m curious if shortstring reserves a full 255 bytes even if what is being stored is only 3 letter string.
I suppose this is why the ability to define shorter strings like string [5] exists.
Also I wonder is there are any differences in the way unicode strings are stored in memory compared to ascii Strings.
Title: Re: IRC channel
Post by: Bogen85 on December 14, 2022, 04:03:49 am
Strings are allocated with some extra room, so adding one character won't require a new allocation.
I’m curious if shortstring reserves a full 255 bytes even if what is being stored is only 3 letter string.
I suppose this is why the ability to define shorter strings like string [5] exists.
Also I wonder is there are any differences in the way unicode strings are stored in memory compared to ascii Strings.

https://wiki.freepascal.org/Shortstring

A Short string is always going to be 256 bytes.
First field is the length.

Title: Re: IRC channel
Post by: Bogen85 on December 14, 2022, 04:22:48 am
Strings are allocated with some extra room, so adding one character won't require a new allocation.
I’m curious if shortstring reserves a full 255 bytes even if what is being stored is only 3 letter string.
I suppose this is why the ability to define shorter strings like string [5] exists.
Also I wonder is there are any differences in the way unicode strings are stored in memory compared to ascii Strings.

https://wiki.freepascal.org/Ansistring
https://wiki.freepascal.org/Unicodestring

See definition of both.
Definition of AnsiString shows the layout in memory.

Dynamically allocated...
The are managed types.  Where the pointer points, when memory is allocated and freed is not something the programmer has to deal with.


Title: Re: IRC channel
Post by: Bogen85 on December 14, 2022, 04:30:51 am
I’m curious if shortstring reserves a full 255 bytes even if what is being stored is only 3 letter string.
I suppose this is why the ability to define shorter strings like string [5] exists.
Also I wonder is there are any differences in the way unicode strings are stored in memory compared to ascii Strings.

I still fail to grasp why for simple questions like these it seems you want or expect others to look up the answers for you, when you could have just as easily looked them up yourself.

Maybe that is not your intent (that you expect others to look things up up for you), but it sure comes across that way.
Title: Re: IRC channel
Post by: Handoko on December 14, 2022, 05:00:55 am
A Short string is always going to be 256 bytes.

Not fully correct.

Try this code:

Code: Pascal  [Select][+][-]
  1. procedure TForm1.Button1Click(Sender: TObject);
  2. Type
  3.   TName = string[10];
  4. var
  5.   Names: array[1..1000] of TName;
  6. begin
  7.   ShowMessage(SizeOf(Names).ToString);
  8. end;

The size of a shortstring can range from 1 byte to 256 bytes.
Read more:
https://wiki.freepascal.org/Character_and_string_types#ShortString
Title: Re: IRC channel
Post by: Bogen85 on December 14, 2022, 06:41:55 am
A Short string is always going to be 256 bytes.

Not fully correct.

Interesting. But one can't do
Quote
shortstring[10];

This only works when string is shortstring?

Not for {$H+} when string is ansistring? Let me see...

This compiles:
Code: Pascal  [Select][+][-]
  1. program shorts;
  2.  
  3. {$mode objfpc}
  4. {$H+}
  5.  
  6. procedure main;
  7. Type
  8.   TName = shortstring;
  9. var
  10.   Names: array[1..1000] of TName;
  11. begin
  12.   writeln(SizeOf(Names));
  13. end;
  14.  
  15. begin
  16.   main;
  17. end.
  18.  

Code: Text  [Select][+][-]
  1. $ fpc shorts
  2. Free Pascal Compiler version 3.2.2 [2022/08/17] for x86_64
  3. Copyright (c) 1993-2021 by Florian Klaempfl and others
  4. Target OS: Linux for x86-64
  5. Compiling shorts.pas
  6. Linking shorts
  7. 17 lines compiled, 0.1 sec
  8.  
  9. $ ./shorts
  10. 256000
  11.  

This does not compile:

Code: Pascal  [Select][+][-]
  1. program shorts;
  2.  
  3. {$mode objfpc}
  4. {$H+}
  5.  
  6. procedure main;
  7. Type
  8.   TName = shortstring[100];
  9. var
  10.   Names: array[1..1000] of TName;
  11. begin
  12.   writeln(SizeOf(Names));
  13. end;
  14.  
  15. begin
  16.   main;
  17. end.
  18.  

Code: Text  [Select][+][-]
  1. Free Pascal Compiler version 3.2.2 [2022/08/17] for x86_64
  2. Copyright (c) 1993-2021 by Florian Klaempfl and others
  3. Target OS: Linux for x86-64
  4. Compiling shorts.pas
  5. shorts.pas(8,27) Error: Error in type definition
  6. shorts.pas(10,28) Error: Illegal expression
  7. shorts.pas(18) Fatal: There were 2 errors compiling module, stopping
  8. Fatal: Compilation aborted
  9. Error: /usr/bin/ppcx64 returned an error exitcode
  10.  


This does compile and run:
Code: Pascal  [Select][+][-]
  1. program shorts;
  2.  
  3. {$mode objfpc}
  4. {$H+}
  5.  
  6. procedure main;
  7. Type
  8. {$H-}
  9.   TName = string[100];
  10. {$H+}
  11. var
  12.   Names: array[1..1000] of TName;
  13. begin
  14.   writeln(SizeOf(Names));
  15. end;
  16.  
  17. begin
  18.   main;
  19. end.
  20.  


Code: Text  [Select][+][-]
  1.  
  2. $ fpc shorts
  3. Free Pascal Compiler version 3.2.2 [2022/08/17] for x86_64
  4. Copyright (c) 1993-2021 by Florian Klaempfl and others
  5. Target OS: Linux for x86-64
  6. Compiling shorts.pas
  7. Linking shorts
  8. 19 lines compiled, 0.1 sec
  9.  
  10. $ ./shorts
  11. 101000
  12.  

Hmm.... What kind of string is that?

Code: Pascal  [Select][+][-]
  1. program shorts;
  2.  
  3. {$mode objfpc}
  4. {$H+}
  5.  
  6. procedure main;
  7. Type
  8. {$H-}
  9.   TName0 = string[100];
  10. {$H+}
  11.   TName1 = string[100];
  12.   TName2 = shortstring;
  13.   TName3 = string;
  14. var
  15.   Names0: array[1..1000] of TName0;
  16.   Names1: array[1..1000] of TName1;
  17.   Names2: array[1..1000] of TName2;
  18.   Names3: array[1..1000] of TName3;
  19. begin
  20.   writeln(SizeOf(Names0), ' ', GetTypeKind(TName0));
  21.   writeln(SizeOf(Names1), ' ', GetTypeKind(TName1));
  22.   writeln(SizeOf(Names2), ' ', GetTypeKind(TName2));
  23.   writeln(SizeOf(Names3), ' ', GetTypeKind(TName3));
  24. end;
  25.  
  26. begin
  27.   main;
  28. end.
  29.  

Code: Text  [Select][+][-]
  1. $ fpc shorts
  2. Free Pascal Compiler version 3.2.2 [2022/08/17] for x86_64
  3. Copyright (c) 1993-2021 by Florian Klaempfl and others
  4. Target OS: Linux for x86-64
  5. Compiling shorts.pas
  6. Linking shorts
  7. 28 lines compiled, 0.1 sec
  8.  
  9. $ ./shorts
  10. 101000 tkSString
  11. 101000 tkSString
  12. 256000 tkSString
  13. 8000 tkAString
  14.  

And yeah, I know the 101 is 100 + 1 for the size.

So a sized string is a shortstring, even if string is ansistring...

But shortstring is always 256 bytes unless sized.

One can't do a sized string over 255...

Code: Pascal  [Select][+][-]
  1. program shorts;
  2.  
  3. {$mode objfpc}
  4. {$H+}
  5.  
  6. procedure main;
  7. Type
  8. {$H-}
  9.   TName0 = string[100];
  10. {$H+}
  11.   TName1 = string[1000];
  12.   TName2 = shortstring;
  13.   TName3 = string;
  14. var
  15.   Names0: array[1..1000] of TName0;
  16.   Names1: array[1..1000] of TName1;
  17.   Names2: array[1..1000] of TName2;
  18.   Names3: array[1..1000] of TName3;
  19. begin
  20.   writeln(SizeOf(Names0), ' ', GetTypeKind(TName0));
  21.   writeln(SizeOf(Names1), ' ', GetTypeKind(TName1));
  22.   writeln(SizeOf(Names2), ' ', GetTypeKind(TName2));
  23.   writeln(SizeOf(Names3), ' ', GetTypeKind(TName3));
  24. end;
  25.  
  26. begin
  27.   main;
  28. end.
  29.  

Code: Text  [Select][+][-]
  1. $ fpc shorts
  2. Free Pascal Compiler version 3.2.2 [2022/08/17] for x86_64
  3. Copyright (c) 1993-2021 by Florian Klaempfl and others
  4. Target OS: Linux for x86-64
  5. Compiling shorts.pas
  6. shorts.pas(11,23) Error: string length must be a value from 1 to 255
  7. shorts.pas(29) Fatal: There were 1 errors compiling module, stopping
  8. Fatal: Compilation aborted
  9. Error: /usr/bin/ppcx64 returned an error exitcode
  10.  

And to verify that the string type switching is working...

Code: Pascal  [Select][+][-]
  1. program shorts;
  2.  
  3. {$mode objfpc}
  4. {$H+}
  5.  
  6. procedure main;
  7. Type
  8. {$H-}
  9.   TName0 = string[100];
  10. {$H+}
  11.   TName1 = string[100];
  12.   TName2 = shortstring;
  13.   TName3 = string;
  14. {$H-}
  15.   TName4 = string;
  16. {$H+}
  17. var
  18.   Names0: array[1..1000] of TName0;
  19.   Names1: array[1..1000] of TName1;
  20.   Names2: array[1..1000] of TName2;
  21.   Names3: array[1..1000] of TName3;
  22.   Names4: array[1..1000] of TName4;
  23. begin
  24.   writeln(SizeOf(Names0), ' ', GetTypeKind(TName0));
  25.   writeln(SizeOf(Names1), ' ', GetTypeKind(TName1));
  26.   writeln(SizeOf(Names2), ' ', GetTypeKind(TName2));
  27.   writeln(SizeOf(Names3), ' ', GetTypeKind(TName3));
  28.   writeln(SizeOf(Names4), ' ', GetTypeKind(TName4));
  29. end;
  30.  
  31. begin
  32.   main;
  33. end.
  34.  

Code: Text  [Select][+][-]
  1. $ fpc shorts
  2. Free Pascal Compiler version 3.2.2 [2022/08/17] for x86_64
  3. Copyright (c) 1993-2021 by Florian Klaempfl and others
  4. Target OS: Linux for x86-64
  5. Compiling shorts.pas
  6. Linking shorts
  7. 33 lines compiled, 0.1 sec
  8.  
  9. $ ./shorts
  10. 101000 tkSString
  11. 101000 tkSString
  12. 256000 tkSString
  13. 8000 tkAString
  14. 256000 tkSString
  15.  

The thing is, one can still store UTF-8 in short strings, so the size limit can be confusing.

Code: Pascal  [Select][+][-]
  1. program shorts8;
  2.  
  3. {$mode objfpc}
  4. {$H+}
  5.  
  6. var
  7.   s8 : string[10];
  8.  
  9. begin
  10.   s8 := '123';
  11.   writeln(s8, ' ', length(s8));
  12.  
  13.   s8 := 'íéä123';
  14.   writeln(s8, ' ', length(s8));
  15.  
  16.   s8 := 'íéä123ó';
  17.   writeln(s8, ' ', length(s8));
  18. end.
  19.  

Code: Text  [Select][+][-]
  1. $ fpc shorts8
  2. Free Pascal Compiler version 3.2.2 [2022/08/17] for x86_64
  3. Copyright (c) 1993-2021 by Florian Klaempfl and others
  4. Target OS: Linux for x86-64
  5. Compiling shorts8.pas
  6. shorts8.pas(16,6) Warning: String literal has more characters than short string length
  7. Linking shorts8
  8. 18 lines compiled, 0.1 sec
  9. 1 warning(s) issued
  10.  
  11. $ ./shorts8
  12. 123 3
  13. íéä123 9
  14. íéä123�10
  15.  

Title: Re: IRC channel
Post by: Bogen85 on December 14, 2022, 06:56:32 am
At least for what I do, unless it is an embedded or some other constrained system, I likely would not use shortstring for anything.

OK... For sized records that get written out in a binary format...

But typically I'd just write out a json file, so ansistring would be just fine.

I'd rather just use ansistring so I don't have to worry about size, especially if non-ASCII UTF-8 characters are being used.
Title: Re: IRC channel
Post by: Martin_fr on December 14, 2022, 02:57:09 pm
https://wiki.freepascal.org/Shortstring

A Short string is always going to be 256 bytes.

I still fail to grasp why for simple questions like these it seems you want or expect others to look up the answers for you, when you could have just as easily looked them up yourself.

Interesting. But one can't do
Quote
shortstring[10];

This only works when string is shortstring?

And https://wiki.freepascal.org/Shortstring which gives the answer:
Quote
Its length is defined as: ShortString = String[255];

Shortstring already has a length set. It is a type defined as "String[255]"
So, no you can't do "shortstring[10]"

Something about a the woods and trees... Something about "in plain sight"... ;)
Title: Re: IRC channel
Post by: Bogen85 on December 14, 2022, 03:06:34 pm
I still fail to grasp why for simple questions like these it seems you want or expect others to look up the answers for you, when you could have just as easily looked them up yourself.

But the answer is not always simple, so my reaction there was not necessarily all that nice... (as to how me being corrected and my subsequent discovery played out...)

Interesting. But one can't do
Quote
shortstring[10];

This only works when string is shortstring?

And https://wiki.freepascal.org/Shortstring which gives the answer:
Quote
Its length is defined as: ShortString = String[255];

Shortstring already has a length set. It is a type defined as "String[255]"
So, no you can't do "shortstring[10]"

Something about a the woods and trees... Something about "in plain sight"... ;)

One often has to do a bit more digging (or climbing to the tops of the trees) to get the whole picture...

Yeah.... So, does tkSString refer to short string or sized string?

And yes, I'm being a bit pedantic here...
Title: Re: IRC channel
Post by: Martin_fr on December 14, 2022, 03:30:05 pm
The thing is, one can still store UTF-8 in short strings, so the size limit can be confusing.

The size-specifier in "string[n]" always gives the size in "char", where "char" is the Pascal type "char" which is 1 byte in size.
The Pascal size "char" is not the same with what a human may perceive as a char (in Unicode, or multi-byte ASCII).

In the same way length, setlength, copy, and the index on any string (short, long, wide) is based an the relevant Pascal types.
That is "char" for short, ansi, unicode string. And that is widechar for widestring. ...

And just to be clear "widechar" is not the same as (what is perceived as a) Unicode char.
In Utf16 some Unicode-Codepoints ("Chars") are represented as surrogates. That takes two code-units. I.e. two widechar.

And in Unicode (independent of the transfer encoding) there are plenty of chars (human perceived chars) that are represented by several codepoints (using combining codepoints). The also need several char or widechar.


The term "char" is a very loose descriptor....

char can be
- Pascal type char (usually holding a Unicode transfer encoding Code-Unit.)
- Unicode codepoint (i.e. independent of transfer encoding / just U####). Potentially even a stand alone combining codepoint).
- Human perceived token (usually a Unicode entity with/without combining codepoints / but not necessarily limited to that)
- In rare (and even more loose) context to describe a Glyph. Where a glyph can represent one or more Unicode entities.

This list is just meant as example... It is neither complete nor correct => as in exceptions can probably be found to any of the statements. Which is to expected for a term ("char") that can be (and has been) used for nearly anything.
Title: Re: IRC channel
Post by: Martin_fr on December 14, 2022, 03:44:11 pm
Yeah.... So, does tkSString refer to short string or sized string?

And yes, I'm being a bit pedantic here...

Not sure where tkSString comes from (not bothered to search if it mentioned in any of the docs  :P ). Sounds like compile sources.

Anyway, there is
- the keyword "string"
- a Shortstring (not the defined type, but the general concept: any type defined as a Shortstring)
- "shortstring" the predefined type

a Shortstring always is fixed size.
The keyword does not have a size.


If ( {$H-} ) the keyword stand alone (on the right hand site of a type or var definition)
Code: Pascal  [Select][+][-]
  1. type TFoo = string;
  2. var TBar: string;

Then it is a shorthand for "string[255]". So the resulting a Shortstring type is sized.
(And obviously with {$H+} this changes....)


If the keyword is followed by a size "string[n]" then the size is "n"

"size" refers to the amount of (pascal type ) char, that can be hold. SizeOf will return more, since the length byte is part of the size too.

Title: Re: IRC channel
Post by: Martin_fr on December 14, 2022, 03:48:39 pm
Not sure where tkSString comes from (not bothered to search if it mentioned in any of the docs  :P ). Sounds like compile sources.

My bad... (should have searched at least this topic...)

From your previous (super long) post (of which I only cherry picked). But then yes, in some way from the compiler. More accurate from RTTI.

So, I would think: tkSString is what I just described as a Shortstring
Title: Re: IRC channel
Post by: Bogen85 on December 15, 2022, 03:00:14 am
Ok... Since this is the IRC channel thread, I'll hijack it back to the original subject...

From the "Who are the Pascal lovers..." topic...

Quote
Because they might be using some program they like that is written in Lazarus or free pascal, and they are trying to work with the maintainers of said program (or some other pascal programmer that could help). They might not have the kind of attitudes of free pascal you want. However, they are trying to improve an existing tool they find a lot of value in.
If that is the case they need to find the people who actually created the application before complaining about it.
Actually we have had trolls/{people who think we are their servants} come to both platforms with some program written in pascal/ delphi repeatedly demanding that we fix it right away. This is just another style of trolling whether it’s intentional or not. I’m sure everyone remembers the troll demanding to compile a program with windows dependencies in linux not so long ago.

Fake help requests often ensnare what few good people are still active and wastes their time and frustrates them, making them less likely to try to help in future. We have had a troll that kept coming to irc with different accounts asking the same exact question should he use oop. No matter what people said he would manage to turn it into an argument, filling the chat with drivel and annoying people who didn’t understand that he was a troll.

There is maybe the scenerio where someone Who hates Pascal has been hired to translate legacy pascal code to another language. We have no obligation to help someone who is being paid to get rid of pascal, it’s in our best interests to go in the opposite direction. People who hate pascal poison the chat with their negativity. We have no obligations to be punching bags for everyone who is unhappy that pascal still exists.

Another possibility is someone has some fancy old code they want to redo using pascal thats great but this also means that they need to know pascal language!!

I often try to help people who don’t know pascal by giving them link to good online book on pascal. Not a single one has ever thanked me nor read the book. Do you want to know why? Because they are not interested in using pascal, they are there to troll.

My reply to this forthcoming...

However, a lot of good stuff has been discussed in here, and I have learned some things...
Title: Re: IRC channel
Post by: Bogen85 on December 15, 2022, 03:02:34 am
From my experience being on IRC with you Joanna you ban people who had no reason to be banned.

You also accused two others at least to be trolls (and that is documented in these forum) and they were determined not to be trolls, yet you still continued to insist they were.

Recently you banned one individual claiming he was someone else. (And that someone else is clearly not a troll).

If you still believe that someone else is a troll (you know who I am referring to), then please, put him on trial here in the forum like you did with the other two you falsely accused and put on trial here in the forum. If that individual is really as bad as you say he is, then others on this forum need to hear your side on why you think he is so terrible for the Free Pascal Community.

And on the one you claimed to be this someone else, he has gone to the unofficial free pascal discord (he could never get on to #fpc on Libera because you kept kicking him, as he never even got on the channel to say anything). He has received a lot of help for his programs there. He has actual programs he is working on, and needs help, and has received help. (From me and also from other individuals on this forum that help out other users).

If you still believe him to be a troll, then please, put him on trial here in this forum as well.

I know what I'm saying might come across as being harsh.

I'm simply being honest.

I would likely still be active on #fpc on Libera if were not for your intolerance and attacks on those you don't understand.

And for those that might wonder why I'm not PM'ing Joanna concerning this, I have done so a lot already, and have also privately chatted with her on IRC concerning this going back a very long time.

I won't take it as a personal affront at all if moderators remove this reply. I'm just saying what needs to be said
Title: Re: IRC channel
Post by: Joanna on December 15, 2022, 04:41:30 am
As Bogen85 has so amply Illustrated there is another facet of trouble trolls cause.. thanks to trolls an otherwise friendly relationship i had with Bogen85 has been completely destroyed because he has chosen to to side with people who are trying to cause trouble. This is another technique of wrecking communities by causing infighting . Bogen85 I’m so sorry that you have been tricked. You have made a bad choice of who to trust.

The person you are talking about is named tony stone.shortly before I banned him he had viciously slandered me in the #fpc channel and tried to get a Libera staff member to remove the +r registered only requirement for channel. 

I have never trusted tony stone and was disappointed to see him attack me in channel. To his credit he did seem to be familiar with Lazarus but seemed to just fool around bouncing from one thing to another. I don’t buy his cover story about being an air conditioning technician. He liked to tell heartwarming stories about his kids doing pascal. I don’t know if they are true.
 He sometimes  said things that were inciting violence like an undercover cop would, like “I’m going to Kill those people if they do such and such.. I have been talking to him for years and know him in ways that Bogen85 does not.

Before the incident with tony there had been a staff member of the Linux channel named sauvin who came to troll the fpc channel. He used a temporary nick like furor to trick the channel logs. He was literally cussing at us and people were complaining to me so I banned him.Then he pmed me and continued trolling.

After this all sorts of accounts belonging to people who do not seem to belong in channel have been showing up. Some of the accounts were created at Libera server launch.

The trolls making their scores of backups accounts really interfered with legit users registering on Libera. As a result we lost Jamie from irc because he got frustrated with not being able to register. Jamie taught me so much about pascal and helped so many people. The fpc channel will never be the same again without him.

Bogen85 if you had not deleted my messages in your temper tantrum you would have seen my explanation of who ...
EDITED MY MODERATOR - see note below - for protection of other IRC members - Martin_fr


I sincerely hope that you and tony stone can write some amazing code together. I can’t wait to see it  :D

One thing I’d like to Mention about trends in irc. It seems like the trolls strike when a channel has gotten very active and full of friendly discussions and getting better. After I talked Bogen85 into returning to irc he enlivened the fpc channel quite a bit. Then the trolls attacked and put an end to that.
Title: Re: IRC channel
Post by: KodeZwerg on December 15, 2022, 07:07:18 am
Ban is really the last I personal would do and I am moderator not just on 1 big Pascal related discord server  :-X
18+ (xxx content) or racism lead to instant ban when I have duty, that I will never allow.  >:D
Having small fights like trolls (small kids) are doing, well "timeout" or "kick" to make them calm if they not listen to us moderators.  O:-)

About your private problems, that should not be talked about on a public board.
Sometimes it is good to speak about such in a group chat, maybe with a mediator, that is just my humble opinion.
But I guess on that case everything is too late by re-reading all this.  :'(
Title: Re: IRC channel
Post by: 440bx on December 15, 2022, 07:52:23 am
I suppose everything goes in an IRC channel, therefore...

A nugget of truth that will be on topic for the forum is that, while I've learned a fair number of languages through the years, for complex programming on PCs Pascal is by far my favorite.  For plain (read simple) business applications (usually on big or "medium" iron), COBOL is by far my favorite (I am yet to see another programming language that can hold a candle to COBOL's formatting abilities), it's also the language who has the most features I miss in Pascal.

There is only one other thing I am as passionate about as I am about programming and that is, soccer.  Between FPC, the Lazarus IDE and the world cup... it doesn't get any better than this :)
Title: Re: IRC channel
Post by: Joanna on December 15, 2022, 10:00:48 am
Quote
Did I by chance make a comment about killing someone who would hurt my kids?  Someone possibly hurting them in ways we have had off topic discussions about maybe concerning forced vaccinations and removal of my kids from school?     
Yes that’s right your plan was to send your kids to school and then kill the people at the school if they vaccinated the kids when you weren’t there. I didn’t see the logic of such a plan and suggested home schooling.

When I first met you you just appeared one day out of nowhere and were very enthusiastic about Lazarus and then you asked to screen share which raised a huge red flag. You have always been rather hyper and disrespectful but to your credit you seemed to use Lazarus. Your behavior in irc was unacceptable and I will never share a chat channel with you again. Yes your behavior was logged. If anyone cares to check.

Quote
You banned my uncle right after he registered to get in the channel.  He is still learning Pascal without your IRC channel.
Who was your uncle? It is Interesting that you suddenly have an “uncle” interested in pascal.

To fill in the details earlier about what happened in irc it turned out that sauvin the troll from the linux channel is buddy buddy with some of the Libera staff so the staff started trying to interfere with the channel moderation.
Bogen85 you were right about Libera staff being woke, one of them started talking talking to me in that lingo they use for lgbt inclusive stuff. I was shocked.

Here is another pro tip on trolls.. sometimes they work in pairs arguing or creating a consensus. Tony stone is very good at praising Lazarus to try to gain our confidence, but is he doing any serious projects or just fooling around? Talk is cheap. He claims to love Lazarus yet wants to make Irc channel More accessible to trolls.

While I was offline, tony Stone who had not been too active in the channel For a long time suddenly was telling all sorts of lies and pretending to be “angry“ about how the channel needed to be more accessible to unregistered accounts.
The #lazarus channel requires no registration and is easy to access but is rather inactive because people who want help are impatient and leave before anyone can respond usually. Trolls also visit the #lazarus  channel and babble about nonsense.

Quote
There is only one other thing I am as passionate about as I am about programming and that is, soccer.  Between FPC, the Lazarus IDE and the world cup... it doesn't get any better than this :)
I wish we had more people like you in irc instead of lurkers and trolls but if you are too busy I guess it can’t be helped.

Quote
Ban is really the last I personal would do and I am moderator not just on 1 big Pascal related discord server  :-X
18+ (xxx content) or racism lead to instant ban when I have duty, that I will never allow.  >:D
Having small fights like trolls (small kids) are doing, well "timeout" or "kick" to make them calm if they not listen to us moderators.  O:-)
After awhile you will realize that trolls can’t help themselves and can always come back. Banning only slows them down a little ...
The concept of timeouts is one approach the op of #programming used to do that on freenode when people started arguing about politics. It’s very labor intensive and kind of humiliating for people on receiving end. To be honest I don’t want to deal with people that need to be disciplined I want to be in a channel where members mutually respect eachother.
Title: Re: IRC channel
Post by: Bogen85 on December 15, 2022, 11:45:57 am
Tony Stone never tricked me, he is just being sarcastic in response to Joanna.

As far as Joanna's claims on individuals I've somehow "sided with", well, I'll stand on the side of reality, and with other contributing hero members in this forum who are also active elsewhere who are also siding with reality.

But even what I've saying in this reply is likely to personal for a forum like this.

I'm passionate about Programming, Pascal, especially Free Pascal. Otherwise I would not have said what I did in my recent posts in the "Who are the Pascal lovers..." topic thread and in my recent calling out of Joanna on this thread for pouring water on sparks of interest in Free Pascal and Lazarus from others just because she does not understand them.

And then Joanna is constantly complaining about the dwindling IRC channels she is active. Which are my observation is primarily due her lack of understanding of where people from other programming backgrounds or cultures (where they actually grew up) and as a result she is intolerant of them.

Joanna, you are very passionate about Pascal. But not everyone who is interested in Pascal (even if that is just get help with it) shares your same "Pascal is end all be all of programming languages and should be the only you are using across the board at work, for hobby, etc, if you want to participate in any Pascal related forum or chat" views.

Because of the intolerance and due to your constant attacks on those you don't understand is what has led up to what is transpiring now in this thread.
Title: Re: IRC channel
Post by: Bogen85 on December 15, 2022, 11:54:24 am
You know... I have had my IRC client connected for years and years.  Maybe I shall just see what lies in the logs?

This is one of the reasons I prefer forums (public record) to IRC. And I see no need need to expose my own IRC logs to others, as I could have easily modified them.

And chat platforms (where apart from private messing) all logs are persistent on the server for those on that chat forum.

All group conversations being on the "public record" is good. Even if that "public record" is only for those that register on said forum or chat server.

Sticking to the forums and platforms with "public records" is a very good thing, as it helps prevents thing degenerating to the point where we have gotten to here.
Title: Re: IRC channel
Post by: Bogen85 on December 15, 2022, 01:03:00 pm
After I talked Bogen85 into returning to irc he enlivened the fpc channel quite a bit.

Thanks for those kind words!

Title: Re: IRC channel
Post by: Martin_fr on December 15, 2022, 01:31:30 pm
ADMIN NOTE

No problem with the discussion so far. All well behaved (at least from what I gleaned while having a quick read through).

I would however advice to be careful with more personal/private bits of information. Even if they are about yourself. As they get "sucked" into the discussion, they get unwittingly extended bit by bit.
If anyone considers any such info (even if self published) to better be removed, please contact me (In case it needs to be edited out from quotes). I will at my digression act on it.
To be clear, this is about privacy concerns only.
Title: Re: IRC channel
Post by: Joanna on December 15, 2022, 02:30:38 pm
Bogen85 no offense but being a moderator is a very different skill set than programming which you are good at.

Tony stone for your information it isn’t “my channel” it’s the official irc support channel for the fpc project which I am managing on behalf of nickysn who is Happy with how I do things. When someone speaks in this channel, they are representing the entire fpc community and for this reason It’s best to favor quality over quantity when it comes to members.

I had no choice but to ban you because of your destructive behavior in the channel. Yet you have the audacity to continue to attack our official irc channel which represents the fpc project by calling it a “failed channel”
The channel is still in use and all people genuinely interested in using the pascal language are welcome to come join us.

I invite everyone reading this {excerpt the trolls} to come to irc and visit our channel and introduce yourselves.it will be fun. I know a lot of us are in different time zones and might arrive at different times but if we all get a critical mass of people we can revive the channels to their former glory when interesting pascal conversations with different people were happening everyday.

Irc is not obsolete but it is under attack by interests that want to move us to platforms that monetize our data, censor and spy on us. Freenode was Bought and destroyed on purpose to get people to stop using irc most likely.

Ironically Irc has trolls that hate irc and want to make the irc experience as miserable as possible For the people who remain there but don’t worry trolls won’t last long in any channel I manage. ;)
Title: Re: IRC channel
Post by: Martin_fr on December 15, 2022, 03:11:06 pm
Notes about the moderation above
Bogen85 if you had not deleted my messages in your temper tantrum you would have seen my explanation of who

This post contained reference (including background on employment) about several people (but particular one person) from the IRC channel (identified by their nicks). One person in question contacted me, to have their data removed.

The post lined out some other participants on the IRC channel may have influenced opinions of others. (Who told lies to whom, who may have spied on whom, ...).

From what I can conclude it was a response to this.
If you still believe that someone else is a troll (you know who I am referring to), then please, put him on trial here in the forum

As that person however does not wish to be "put on trial" here, and the information is otherwise only relevant (and also only meaningful) to the above quoted parties, I decided to remove the information as requested.





Title: Re: IRC channel
Post by: Joanna on December 15, 2022, 03:38:08 pm
For those interested in trying out irc this guide might help a bit.
https://libera.chat/guides/
Title: Re: IRC channel
Post by: Bogen85 on December 15, 2022, 06:38:58 pm
Notes about the moderation above
Bogen85 if you had not deleted my messages in your temper tantrum you would have seen my explanation of who

This post contained reference (including background on employment) about several people (but particular one person) from the IRC channel (identified by their nicks). One person in question contacted me, to have their data removed.

The post lined out some other participants on the IRC channel may have influenced opinions of others. (Who told lies to whom, who may have spied on whom, ...).

From what I can conclude it was a response to this.
If you still believe that someone else is a troll (you know who I am referring to), then please, put him on trial here in the forum

As that person however does not wish to be "put on trial" here, and the information is otherwise only relevant (and also only meaningful) to the above quoted parties, I decided to remove the information as requested.

Thanks Martin.

This falls on me.

I meant that rhetorically, the "put on trial" part, but I was I not 100% clear that I meant it that way, so in retrospect I should likely have not said it.

Either it needs to be said it or does not need to be said, something should not be said if one is not completely OK with what the consequences from those words will be.

Mea culpa.
Title: Re: IRC channel
Post by: Joanna on December 15, 2022, 11:36:03 pm
Nobody needs to be put on trial. The irc channels have official channel logs. I forgot where the website for them is.

In any case Irc is supposed to be a fun place to meet likeminded people to chat about topics of common interest.

An irc experience is determined by what the people in the channel do. At the present time most irc channels are predominately lurkers. I would like to change that to something better but I cannot do it alone.
TinyPortal © 2005-2018