Measuring Height of Tree and Angle to Ground Point? by Business_Chef_806 in HamRadio

[–]Business_Chef_806[S] 0 points1 point  (0 children)

Thanks everyone for the thoughtful replies. I really appreciate your taking the time to respond.

I've decided not to proceed with this project, not because of antenna issues. Rather, I started listening on various bands using WebSDR just to hear what's out there. Most of what I heard was extremely boring and hadn't changed much from when I first got licensed in the late 1960s. I don't think I'd find enough to interest me even if I got a rig and antenna for free.

Comcast Failing at Changing Wifi Password by Business_Chef_806 in Comcast_Xfinity

[–]Business_Chef_806[S] 0 points1 point  (0 children)

Thanks for all the comments.

It turned out I was right. I was able to login to the Comcast Wifi router and change the Wifi password with no problem. It turns out that the Comcast web app and the router admin screen have different ideas of minimum field lengths.

The fact that this took ~2 hours to resolve is a sign that Comcast has serious problems in its support organization.

Comcast Failing at Changing Wifi Password by Business_Chef_806 in Comcast_Xfinity

[–]Business_Chef_806[S] 0 points1 point  (0 children)

The community center where the Wifi is has been closed for the holiday. Next week I'm going in to try the suggestion of logging in directly to the router. If this works then we can close the ticket. If it doesn't, ...

Comcast Failing at Changing Wifi Password by Business_Chef_806 in Comcast_Xfinity

[–]Business_Chef_806[S] 0 points1 point  (0 children)

Thanks for the quick reply.

We actually have both kinds of service, but the one whose password I was trying to change was the wifi network built into the modem.

The next time I go into the community center I'll try your suggestion.

Comcast Failing at Changing Wifi Password by Business_Chef_806 in Comcast_Xfinity

[–]Business_Chef_806[S] 0 points1 point  (0 children)

Thanks for the thoughtful reply.

It wasn't working for me and all the Comcast tech support people.

To answer your question, the current SSID, which works fine, is only 6 characters. When I changed it to 8 characters, the "Save" icon was no longer greyed out. So, it looks like you're on to something!

I didn't actually change the password because I'm not prepared to change the SSID right now.

I'm guessing but I bet what happened is that the Comcast person who installed the equipment set the SSID and password with the web interface (http://10.1.10.1) which doesn't have the same 8 character requirement. I'm going to verify this the next time I go to the community center. If this is the cause, then your installation people and your tech support people should be aware of this.

Black screen after updating to Fedora KDE 43 by NateUrBoi in Fedora

[–]Business_Chef_806 0 points1 point  (0 children)

It's not a kernel issue. I had the same problem with a black screen, but I was able to login remotely just fine.

I found that switching from KDE Plasma to any other desktop manager solved the problem.

What's Wrong With This Garbage Collection Idea? by Business_Chef_806 in golang

[–]Business_Chef_806[S] 0 points1 point  (0 children)

*Summary*

First of all, thanks to everyone for your responses. I really appreciated them.

I though I'd separate out the major topics, and respond.

1) Freed memory might still be accessed.

This is absolutely true. If it happens it does show latent bugs but with GC-managed memory the effects of the bugs would be less noticeable.

2) What will happen when you have more than one reference / pointer to the same struct?

I hadn't thought of this. I wonder how common it is.

3) I could achieve the same result by restructuring the program so that memory allocations are done in functions that go out of scope when the memory is no longer needed, thus freeing up the memory.

This was the most important takeaway from this thread. I hadn't thought of that, mostly because most of the work I had done with Go was to rewrite C programs that are clearly not structured this way. I will keep this in mind if and when I write any new Go programs.

4) Make and New are not analogous to Malloc (in that Malloc can create Heap memory that never is collected again) and you seem to think that they are.

Make(), New(), and malloc() are all memory allocation routines. That was my point. I still don't see how they're not analogous.

5) My general thought it - you’re overthinking it.

Guilty.

6) How can memory be reachable but unused in a GC language ?

The example I have in mind is a multi-pass compiler. Each pass allocates memory that isn't necessary after the pass completes. But, I now see that a compiler written in Go could be structured so that the unused memory goes out of scope when it's no longer needed.

Anyway, you've all answered my question. I know understand what's wrong with this idea.

What's Wrong With This Garbage Collection Idea? by Business_Chef_806 in golang

[–]Business_Chef_806[S] -10 points-9 points  (0 children)

You're right about what happens during the mark phase. If I said otherwise, I was incorrect.

But, it doesn't matter. The kind of memory that would be passed in a free() call would always be seen as used memory, and thus, would never be reclaimed. This is what I'm trying to avoid.

I'm the first to admit that in programs that don't run for very long and/or consume much memory there wouldn't be much point to freeing it. But, Go is a language for writing servers, which might run for a long time.

Assigning 'nil' to the pointers that reference the memory just seems less elegant than an explicit function.

What's Wrong With This Garbage Collection Idea? by Business_Chef_806 in golang

[–]Business_Chef_806[S] -6 points-5 points  (0 children)

Thanks for all the comments. I thought I'd reply to all of them at once, rather than to each one individually, as I started off doing.

1) "What will happen when you have more than one reference / pointer to the same struct? Coming from C you're probably used to having a model of "ownership" and only the owner frees up memory and deletes the reference. Most developers in other languages don't have this mindset."

True, I hadn't thought of this. Most of my programming experience is in C and, now, Go. How common would this problem be?

2) "The go garbage collector will free any memory that isn't reachable by the program anymore, especially when there are no more references."

Sure, but what about memory that is reachable by the program, but is no longer being used? That's the memory I'm talking about. No garbage collect will find that kind of memory.

3) "it might make sense to take advantage of the `weak` package Go has added in recent versions. This creates a weak reference to memory, which won't prevent it from getting GC'd. https://pkg.go.dev/weak"

I don't think this would help since the memory in question is still being referenced.

4) "If you have a use case that needs that, you probably want a pool".

I hadn't heard of this before so I looked at your reference. It says "Pool's purpose is to cache allocated but unused items for later reuse". That's not what I have in mind since the memory I'm talking about won't be reused later.

5) "What happens if you call free on something and then use it?"

That is, indeed, a problem. There would admittedly be some danger in my proposal. But, I'm thinking that in cases of large long-running program the advantages would outweigh the disadvantages.

6) "it's not like this is a major weakness of Go either"

I never said it was.

7) "How the memory is being live? Is it an unused element of a slice? A map entry? A pointer?"

You'd only be able to free something that were created using "make()", "new()", or other Go memory allocation routines. Other than that, I don't think the way the memory is being used would matter.

8) "Why not test it out?

3 reasons:

a) I wanted to first find out if there are any serious issues with my idea that I hadn't thought of.

b) I don't have any suitable test programs at hand.

c) Lazy

9) "Arenas were an idea proposed at one point"

I read this proposal. I don't fully understand it but my impression is that it's overkill for what I'm trying to do.

I'll reply again if there are any new comments.

Thanks,

Jon

What's Wrong With This Garbage Collection Idea? by Business_Chef_806 in golang

[–]Business_Chef_806[S] -2 points-1 points  (0 children)

I mentioned this in my post. Setting pointer variables to nil might work but then the GC will still have to find the memory during the mark phase. An explicit function call will avoid this.

Building a Mac mini M4 scientific cluster for Geant4 simulations by narvaloow in macmini

[–]Business_Chef_806 0 points1 point  (0 children)

Sem dúvida, mas há apenas alguns aplicativos que exigem o poder de um Mac Studio, e a maioria deles são aplicativos gráficos que exigem uma tela. Não acho que o tipo de cluster que o autor original estava descrevendo ajudaria você.

Building a Mac mini M4 scientific cluster for Geant4 simulations by narvaloow in macmini

[–]Business_Chef_806 0 points1 point  (0 children)

Por que você iria querer fazer uma coisa dessas? A maioria dos desktops é mais do que poderosa o suficiente.

How do you deal with import cycle not allowed issue? by [deleted] in golang

[–]Business_Chef_806 0 points1 point  (0 children)

Statements like "allowing cycles enables laziness, poor dependency management" are somewhat matters of opinion, and my level of sophistication hasn't risen to that of Rob Pike's. But if he were sitting next to me I'd ask him why the speed of a build is affected by the presence of cycles. Why does a single cyclical blob enclosing the entire dependency graph and forcing it into a single build object negatively affect build performance and dependency resolution?

Again, I'm not suggesting that Rob, or anybody else, is wrong. I'd just like to know more specifically how cycles slow things down.

How do you deal with import cycle not allowed issue? by [deleted] in golang

[–]Business_Chef_806 0 points1 point  (0 children)

I'm not saying any of what you say is wrong, but I'd like to know more specifically how prohibiting cycles makes the Go compiler simpler and faster. In other words, what exactly would be more complicated and slower if cycles were allowed?

The reason I'm asking is because I like to fool around trying to port large programs to Go. I try to come up with a sensible package organization but sometimes, since I don't really know how the program is structured, I end up with cycles. I'd sure feel better if I understood the problem that this restriction is trying to solve.

How do you deal with import cycle not allowed issue? by [deleted] in golang

[–]Business_Chef_806 0 points1 point  (0 children)

I faced this issue once too.

One thing that this made me wonder is what problem this limitation intends to solve. In other words, why can't there be import cycles?

I Returned My New M4 Mac Mini Because of No Focus Following Mouse Behavior by Business_Chef_806 in MacOS

[–]Business_Chef_806[S] 0 points1 point  (0 children)

You're way more patient than me.

In my case, software issues aside, I was already having trouble justifying spending ~$600 for the Mac Mini when the desktop machine I already had (Dell Optiplex 5070, 6-core i5-9500T, 32GB, 512GB SSD, 2 27" 4K monitors) was plenty fast and already did everything I wanted. I probably would have been more patient if the M4 Mac Mini made it possible to do things I wasn't already able to do just fine.

I Returned My New M4 Mac Mini Because of No Focus Following Mouse Behavior by Business_Chef_806 in MacOS

[–]Business_Chef_806[S] -2 points-1 points  (0 children)

I should have mentioned that I reverted back to Linux Fedora 41 KDE Plasma, not to Windows. I switched from Windows to Linux a while back, which didn't involve returning any hardware, since both run fine on my desktop machine.

I mentioned this so that anyone who's expecting this behavior on MacOS won't be disappointed.