2023-05-26 22:01 from zelgomer
I've played with FORTH a little. Nothing significant, just enough to
see what it's all about. Ultimately decided that it's not for me,
mostly because I can't get past how cumbersome it is to write reentrant
code. I think there probably is a way to design a FORTH dialect that
Ideally you use the data stack and temporarily the return stack and write reentrant Forth by default, but you don't have to limit yourself to this. You can use locals for example, or if you only care about reentrancy in terms of multitasking then you have USER variables. Some other ways to solve this are through saving and restoring state (or a pointer to such state), which can be done automatically or explicitly.
I think the main difficulty with Forth is that it's so different. I have many years of experience in non-stack languages that I can't fall back on and only a year or two of writing small programs in Forth. Dealing with stacks is also not everyone's cup of tea...
2023-05-27 16:56 from zelgomer
I'll tell you another reason why I need to stay away from FORTH. I'm a
very indecisive person, and FORTH represents a bottomless pit of
freedom. The reason WHY I never did anything significant with it is
because I spent most of my time exploring "hey what if..."s. I've read
that it's a common joke among the community that most FORTHers spend
their time writing FORTHs rather than actually solving problems, and
this was definitely true for me.
Also why I don't need to be in the business of designing my own
languages or writing compilers. I have a notepad somewhere where I keep
track of ideas for "my C dialect," and probably at least half of them
are vague ideas that end with open-ended questions. "It should wash my
car! But should it do iton Sundays or on Wednesdays? Should it be
configurable? What would the syntax be?"
Yep, Forth is a bottomless pit of freedom and that's why I like it :)
It's funny but and also true that many Forthers spend all their time on their own Forth. I want to write my own Forth some time too but I'm not sure if I'll ever get around to it because Gforth is really good and I have other Forth projects to finish.
If you want a modern C then you may be interested in the Zig programming language.
if i remember right Gforth is ANSI complaint, so a good place to be if you dont want to roll your own.
And it compiles on nearly anything that runs Linux.
2023-05-24 20:31 from x4th
I was always paranoid about calculator battery running out during exams
so I brought in a second. I never used an RPN calculator but I'm sure I
would like it. You can program on them too right?
I just used a calculator with a solar cell.
In more recent days they have started allowing you to bring the whole computer in. I have the memory of a teacher telling us we were allowed to bring our computers to the exams and use any program to solve the questions as long as we could show we had writen them ourselves. He did this because he could not believe for the life of him any of us was any good coding two likes of bash together.
I showed up to the next exam with a lame old laptop and a bunch of scripts to solve typical problems. I aced the thing. It was a lot of fun.
2023-05-28 18:19 from darknetuser2023-05-24 20:31 from x4th
I was always paranoid about calculator battery running out during
examsso I brought in a second. I never used an RPN calculator but I'm sure
Iwould like it. You can program on them too right?
I just used a calculator with a solar cell.
In more recent days they have started allowing you to bring the whole
computer in. I have the memory of a teacher telling us we were allowed
to bring our computers to the exams and use any program to solve the
questions as long as we could show we had writen them ourselves. He did
this because he could not believe for the life of him any of us was any
good coding twolikes of bash together.
I showed up to the next exam with a lame old laptop and a bunch of
scripts to solve typical problems. I aced the thing. It was a lot of
fun.
These days the cheap calculators come with solar panels that aren't even connected to anything. I would hope the decent calculators actually have them connected.
Sounds like a good teacher. That's a really easy way to get students motivated. My business teacher did something similar, he allowed everyone to create a single page cheat sheet for his tests and only gave 5 minutes per test so you better have it organized properly so you can look up important information quickly. These cheat sheets would then also be useful for learning for the final exam.
All except two of our IT teachers were completely clueless... we had to correct them constantly on everything.
Then how do they work? Or do they just die after a few hours when the initial charge from the factory runs out, and that is it?
Fri Jun 02 2023 08:16:46 AM EDT from x4th
These days the cheap calculators come with solar panels that aren't even connected to anything.
2023-06-02 09:08 from Nurb432
Then how do they work? Or do they just die after a few hours when the
initial charge from the factory runs out, and that is it?Fri Jun 02 2023 08:16:46 AM EDT from x4th
These days the cheap calculators come with solar panels that aren't
even connected to anything.
I suspect they come with a battery and, once it runs out, it is over until you replace it.
its been a LONG time, but last solar one i had, the battery was sealed. ( thus the 'that is it' idea ) Sure you could tear it apart, cut it out, bla bla but the average person wont do that.
Sat Jun 03 2023 09:37:17 PM EDT from darknetuser2023-06-02 09:08 from Nurb432
Then how do they work? Or do they just die after a few hours when the
initial charge from the factory runs out, and that is it?
Fri Jun 02 2023 08:16:46 AM EDT from x4th
These days the cheap calculators come with solar panels that aren't
even connected to anything.
I suspect they come with a battery and, once it runs out, it is over until you replace it.
If you want a modern C then you may be interested in the Zig
programming language.
...for great justice.
These days the cheap calculators come with solar panels that aren't
even connected to anything. I would hope the decent calculators
actually have them connected.
I am amazed at how many USB battery banks are like that. They are perfectly chargeable the normal way but one side is covered in what looks like a solar cell but is actually just a paint job.
Damn chinese crap.
2023-06-05 22:27 from IGnatius T Foobar <ajc@citadel.org>If you want a modern C then you may be interested in the Zig
programming language.
...for great justice.
wow how did I miss that
I test mine ( when i get those rechargeable LED panel things ) First thing i do is drain it. then shove it in the sunlight.
Same for most anything like that, day 1 is testing. day 2 is send back if it fails any test. ( batteries, SD cards, whatever )
Mon Jun 05 2023 06:29:37 PM EDT from IGnatius T FoobarThese days the cheap calculators come with solar panels that aren't
even connected to anything. I would hope the decent calculators
actually have them connected.
I am amazed at how many USB battery banks are like that. They are perfectly chargeable the normal way but one side is covered in what looks like a solar cell but is actually just a paint job.
Damn chinese crap.
How do you do, fellow coders? Just looking to find what some of you think about something.
That is, of course, if anyone else is still writing in C at all. I write a lot in Python now and because I do a lot of infrastructure automation I'll probably have to learn Go at some point, but C is still my favorite. :)
Like most C programmers, I've spent trillions of hours building linked lists.
It remains the single most memory-efficient way to store an arbitrary amount of data in an elastic way. But last year I got tired of it, and built myself a lightweight array class [ https://code.citadel.org/citadel/citadel/-/blob/master/libcitadel/lib/array.c ] and I find myself using it pretty much all the time. About a hundred lines of code (including comments and blank lines) containing constructor, destructor, append, get_element_at, delete_element_at, length, and sort (using a compare callback) functions -- that's it.
Memory allocation is insanely naive: it keeps track of the number of items actually present in the array, and the number of items for which it has allocated memory. Whenever an append operation would cause the size of the array to exceed the size of the allocation, it simply doubles the allocation. This avoids the need to call realloc() for *every* append operation.
Am I insane for doing this? That style of allocation has never let me down in the past. I'm debugging a reoccurring segfault problem right now in some code that does three nested levels of linked lists, and it's abusing the allocator to the point where the allocator just tells me to go shit in my hat and aborts the program. I'm thinking of replacing all three linked lists with calls to my array class.
I'm also contemplating what this actually does to a running system, assuming a modern unix with virtual memory. If I allocate a bunch of memory but I don't zero it out, does it actually use any actual memory?
This depends on the kernel and runtime. With Windows, the memory is not allocated at all until you do something with your allocation. With FreeBSD, memory is allocated whether or not you use it.
Sat Jun 10 2023 12:32:10 EDT from IGnatius T Foobar
I'm also contemplating what this actually does to a running system, assuming a modern unix with virtual memory. If I allocate a bunch of memory but I don't zero it out, does it actually use any actual memory?
I dont do C or C++ but i would imagine its the same for Linux too.
"you asked for it, you get it.."
Sat Jun 10 2023 01:02:29 PM EDT from LadySerenaKittyWith FreeBSD, memory is allocated whether or not you use it.
With FreeBSD, memory is allocated whether or not you use it.
Define "allocated". I could see that meaning two separate things:
1. Virtual memory is assigned, but not mapped to physical memory until you access it
2. Virtual memory is assigned, mapped to physical memory, then gradually gets swapped out if you don't access it
Either one is ok on a system that swaps pages instead of entire processes, of course.
You get a physical spot in the capacitor bank.
Sat Jun 10 2023 14:47:42 EDT from IGnatius T FoobarWith FreeBSD, memory is allocated whether or not you use it.
Define "allocated". I could see that meaning two separate things:
1. Virtual memory is assigned, but not mapped to physical memory until you access it
2. Virtual memory is assigned, mapped to physical memory, then gradually gets swapped out if you don't access it
Either one is ok on a system that swaps pages instead of entire processes, of course.
Am I insane for doing this? That style of allocation has never let me
down in the past. I'm debugging a reoccurring segfault problem right
now in some code that does three nested levels of linked lists, and
it's abusing the allocator to the point where the allocator just tells
me to go shit in my hat and aborts the program. I'm thinking of
replacing all three linked lists with calls to my array class.
I'm also contemplating what this actually does to a running system,
assuming a modern unix with virtual memory. If I allocate a bunch of
memory but I don't zero it out, does it actually use any actual memory?
Are you insane for doing this? No. I do it quite frequently, and I see other C programmers I work with do it. And here's a tip: if your "grow" expression is "n = 1 + 2 * n" then you never need to handle the initial case when n is 0, and the value of n will always be some power of 2 - 1 (which I've always felt is probably nice because it leaves one entry available for the heap overhead, but this is just a warm fuzzy thing and doesn't actually have any meaningful impact on anything).
In Linux you can control this. By default, pages mapped to your virtual memory space aren't actually backed by real memory until you write to them. Linux, again by default, will also let you allocate more virtual memory than there is physical memory ("overcommit"). For this reason, you usually will never see malloc fail on Linux.
You can control these behaviors - whether or not it prefaults allocated memory, and whether it allows overcommitting and by how much - through the sysctl interface. I don't remember off the top of my head exactly what the options are called, but they're in there if you look.
mmap also has has a MAP_POPULATE option to prefault its mapped pages. But I assume we're talking about malloc and not mmap :)
In Linux you can control this. By default, pages mapped to your
virtual memory space aren't actually backed by real memory until you
write to them. Linux, again by default, will also let you allocate more
virtual memory than there is physical memory ("overcommit"). For this
reason, you usually will never see malloc fail on Linux.
That's what I had suspected, and I'm surprised to hear that FreeBSD does it differently. Unless, perhaps, our resident FreeBSD guru had too much catnip and made a mistake.
We know that malloc() is a library call rather than a system call; if it needs more memory for an allocation than it currently has available on the heap, it increases its data segment with a call to sbrk().
Over on the Linux side of things, I found this essay [ https://manybutfinite.com/post/how-the-kernel-manages-your-memory/ ] which says, among other things:
"A virtual memory area is like a contract between your program and the kernel.
You ask for something to be done (memory allocated, etc) and the kernel says 'sure' and it creates or updates the appropriate virtual memory area. But it does not actually honor the request right away; it waits until a page fault happens to do real work. The kernel is a lazy, deceitful sack of scum; this is the fundamental principle of virtual memory." It then goes on to describe what happens when a page fault occurs and it has to map some physical memory.
This suggests that a call to sbrk() will increase the size of the heap but does not actually allocate physical memory, and when the process tries to access an address in that space, a page fault is raised and then you get actual capacitors mapped to those pages.
I didn't begin using the double-the-allocation-whenever-you-need-more algorithm with that in mind, but it seems to work pretty well ... and hearing that zelgomer also does it suggests that it's one of those ideas that lots of people come up with independently. When I wrote my array class I briefly considered representing it as a linked list internally. I didn't do it that way because I figured the fewer calls to malloc() the better.