Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Special link-list algorithm help
117 views
Skip to first unread message
Rick C. Hodgin
Jul 5, 2018, 9:40:03 PM7/5/18
to
I have a two-way link-list that traverses a long chain (10s to 100s of
thousands of nodes). The final chain that's prepared is made up of
things that are comprised of sub-parts.
Initially I start out with something like this:
_ _ _ _ _
|a|--|b|--|c|--|d|-- ... --|z|
It's a node that's in the range of a..z (26 nodes let's say for this
example). I have a control structure that indicates where it starts
and stops:
struct SControl
{
SNode *beg; // First node, points to a
SNode *end; // Last node, points to z
};
In normal processing, need to process other things which produce new
node chains, and then inject them into the original a..z node chain,
making that chain longer. It can be visualized like this:
_ _ _ _ _
|a|--|b|-+ +-|c|--|d|-- ... --|z|
| |
+-----+ +-----+
| _ _ _ |
+-|1|--|2|--|3|-+
So the 1..3 nodes were injected into the a..z chain, making the whole
chain longer. This is no problem and I have code which does this
nicely.
However, when I add these new nodes I maintain information about the
injection, resulting in two SControl structs which are populated as
such (pseudo-code):
SControl nodes[2] =
{
{ a, z }, // First part starts a, ends z
{ 1, 3 } // Second part starts 1, ends 3
};
From here, I continue processing which may consume/inject nodes here
and there, and I need a good way to maintain the beg and end members
throughout as they are processed. If node |1| was consumed, then
the beg member would need to move to |2|. If |3| was consumed, the
end member would need to move to |2|, and so on. If a new |4| node
was added after |3|, then the end member needs to move to |4|, and
so on. And if 1..3 are all deleted, then its nodes[] entry needs to
be set to NULL on both pointers, with |b| being again directly linked
to |c|.
However, during my processing, I am not maintaining information that
is relative to the loaded SControl structure. I simply traverse the
chain node-by-node as I go through it.
The only solutions I can think of are to (1) add a callback function
to my delete_node() function which calls a function designed to scan
through nodes[] to see if the node being deleted touches any of the
beg or end members indicated, or (2) to add a new member to each SNode
struct which is a pointer to the parent SControl it relates to. (1)
is doable and is my algorithm of choice at present, and (2) seems like
it would waste memory but be faster.
Does anybody have better suggestion or an alternate algorithm?
Thank you in advance.
--
Rick C. Hodgin
thousands of nodes). The final chain that's prepared is made up of
things that are comprised of sub-parts.
Initially I start out with something like this:
_ _ _ _ _
|a|--|b|--|c|--|d|-- ... --|z|
It's a node that's in the range of a..z (26 nodes let's say for this
example). I have a control structure that indicates where it starts
and stops:
struct SControl
{
SNode *beg; // First node, points to a
SNode *end; // Last node, points to z
};
In normal processing, need to process other things which produce new
node chains, and then inject them into the original a..z node chain,
making that chain longer. It can be visualized like this:
_ _ _ _ _
|a|--|b|-+ +-|c|--|d|-- ... --|z|
| |
+-----+ +-----+
| _ _ _ |
+-|1|--|2|--|3|-+
So the 1..3 nodes were injected into the a..z chain, making the whole
chain longer. This is no problem and I have code which does this
nicely.
However, when I add these new nodes I maintain information about the
injection, resulting in two SControl structs which are populated as
such (pseudo-code):
SControl nodes[2] =
{
{ a, z }, // First part starts a, ends z
{ 1, 3 } // Second part starts 1, ends 3
};
From here, I continue processing which may consume/inject nodes here
and there, and I need a good way to maintain the beg and end members
throughout as they are processed. If node |1| was consumed, then
the beg member would need to move to |2|. If |3| was consumed, the
end member would need to move to |2|, and so on. If a new |4| node
was added after |3|, then the end member needs to move to |4|, and
so on. And if 1..3 are all deleted, then its nodes[] entry needs to
be set to NULL on both pointers, with |b| being again directly linked
to |c|.
However, during my processing, I am not maintaining information that
is relative to the loaded SControl structure. I simply traverse the
chain node-by-node as I go through it.
The only solutions I can think of are to (1) add a callback function
to my delete_node() function which calls a function designed to scan
through nodes[] to see if the node being deleted touches any of the
beg or end members indicated, or (2) to add a new member to each SNode
struct which is a pointer to the parent SControl it relates to. (1)
is doable and is my algorithm of choice at present, and (2) seems like
it would waste memory but be faster.
Does anybody have better suggestion or an alternate algorithm?
Thank you in advance.
--
Rick C. Hodgin
Siri Cruise
Jul 5, 2018, 10:55:40 PM7/5/18
to
In article <phmh9a$514$1...@dont-email.me>,
If you're doing this to impose a tree on the list, why not use a tree?
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
I'm saving up to buy the Donald a blue stone This post / \
from Metebelis 3. All praise the Great Don! insults Islam. Mohammed
"Rick C. Hodgin" <rick.c...@gmail.com> wrote:
> However, when I add these new nodes I maintain information about the
> injection, resulting in two SControl structs which are populated as
> such (pseudo-code):
>
> SControl nodes[2] =
> {
> { a, z }, // First part starts a, ends z
> { 1, 3 } // Second part starts 1, ends 3
> };
Why? If this is what is causing you problems, reconsider if you need it.
> However, when I add these new nodes I maintain information about the
> injection, resulting in two SControl structs which are populated as
> such (pseudo-code):
>
> SControl nodes[2] =
> {
> { a, z }, // First part starts a, ends z
> { 1, 3 } // Second part starts 1, ends 3
> };
If you're doing this to impose a tree on the list, why not use a tree?
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
I'm saving up to buy the Donald a blue stone This post / \
from Metebelis 3. All praise the Great Don! insults Islam. Mohammed
Scott
Jul 6, 2018, 1:04:14 AM7/6/18
to
On Thu, 5 Jul 2018 21:39:52 -0400, "Rick C. Hodgin"
<rick.c...@gmail.com> wrote:
>I have a two-way link-list that traverses a long chain (10s to 100s of
>thousands of nodes). The final chain that's prepared is made up of
>things that are comprised of sub-parts.
<rick.c...@gmail.com> wrote:
>I have a two-way link-list that traverses a long chain (10s to 100s of
>thousands of nodes). The final chain that's prepared is made up of
>things that are comprised of sub-parts.
> SControl nodes[2] =
> {
> { a, z }, // First part starts a, ends z
> { 1, 3 } // Second part starts 1, ends 3
> };
>
> From here, I continue processing which may consume/inject nodes here
>and there, and I need a good way to maintain the beg and end members
>throughout as they are processed. If node |1| was consumed, then
>the beg member would need to move to |2|. If |3| was consumed, the
>end member would need to move to |2|, and so on. If a new |4| node
>was added after |3|, then the end member needs to move to |4|, and
>so on. And if 1..3 are all deleted, then its nodes[] entry needs to
>be set to NULL on both pointers, with |b| being again directly linked
>to |c|.
>
>However, during my processing, I am not maintaining information that
>is relative to the loaded SControl structure. I simply traverse the
>chain node-by-node as I go through it.
...
> {
> { a, z }, // First part starts a, ends z
> { 1, 3 } // Second part starts 1, ends 3
> };
>
> From here, I continue processing which may consume/inject nodes here
>and there, and I need a good way to maintain the beg and end members
>throughout as they are processed. If node |1| was consumed, then
>the beg member would need to move to |2|. If |3| was consumed, the
>end member would need to move to |2|, and so on. If a new |4| node
>was added after |3|, then the end member needs to move to |4|, and
>so on. And if 1..3 are all deleted, then its nodes[] entry needs to
>be set to NULL on both pointers, with |b| being again directly linked
>to |c|.
>
>However, during my processing, I am not maintaining information that
>is relative to the loaded SControl structure. I simply traverse the
>chain node-by-node as I go through it.
>Does anybody have better suggestion or an alternate algorithm?
Most of the time, if adding or removing linked list nodes involves
scanning the list, it means you're not really understanding how to use
a linked list.
That said, it seems to me that your data structure is really a list of
lists. In your example, you'd begin with a list of one list [A-Z], and
end up with a list of three lists [A-B], [1-3] and [C-Z]. Keeping
track of all the endpoints is automatic and inherent to the data
structure, with no cruft.
Rosario19
Jul 6, 2018, 5:53:37 AM7/6/18
to
On Thu, 5 Jul 2018 21:39:52 -0400, "Rick C. Hodgin" wrote:
>I have a two-way link-list that traverses a long chain (10s to 100s of
>thousands of nodes). The final chain that's prepared is made up of
>things that are comprised of sub-parts.
>
>Initially I start out with something like this:
> _ _ _ _ _
> |a|--|b|--|c|--|d|-- ... --|z|
>
>It's a node that's in the range of a..z (26 nodes let's say for this
>example). I have a control structure that indicates where it starts
>and stops:
>
> struct SControl
> {
> SNode *beg; // First node, points to a
> SNode *end; // Last node, points to z
> };
>
>In normal processing, need to process other things which produce new
>node chains, and then inject them into the original a..z node chain,
>making that chain longer. It can be visualized like this:
> _ _ _ _ _
> |a|--|b|-+ +-|c|--|d|-- ... --|z|
> | |
> +-----+ +-----+
> | _ _ _ |
> +-|1|--|2|--|3|-+
for me you have to have at last one pointer to the first node of the
>I have a two-way link-list that traverses a long chain (10s to 100s of
>thousands of nodes). The final chain that's prepared is made up of
>things that are comprised of sub-parts.
>
>Initially I start out with something like this:
> _ _ _ _ _
> |a|--|b|--|c|--|d|-- ... --|z|
>
>It's a node that's in the range of a..z (26 nodes let's say for this
>example). I have a control structure that indicates where it starts
>and stops:
>
> struct SControl
> {
> SNode *beg; // First node, points to a
> SNode *end; // Last node, points to z
> };
>
>In normal processing, need to process other things which produce new
>node chains, and then inject them into the original a..z node chain,
>making that chain longer. It can be visualized like this:
> _ _ _ _ _
> |a|--|b|-+ +-|c|--|d|-- ... --|z|
> | |
> +-----+ +-----+
> | _ _ _ |
> +-|1|--|2|--|3|-+
list so the situation is
pointerStart->|a|--|b|-+ +-|c|--|d|-- ... --|z|
| |
+-----+ +-----+
| _ _ _ |
+-|1|--|2|--|3|-+
and when add some sub node pointerStart can change
+-----+ +-----+
| _ _ _ |
+-|1|--|2|--|3|-+
example
pointerStart->+ |a|-|b|-|c|--|d|-- ... --|z|
| |
| +-----+-----+
| _ _ _ |
+-|1|--|2|--|3|-+
if double linked list for find the node |z| it would be enougt
+-|1|--|2|--|3|-+
node |1| (or in general the first node or the node pointerStart point
to) has its prec pointer point to |z| the last
but possible i remember wrong... what i remember of my linker list
is that each linked list and each node of it has one value, one
signature that identify the list ( i don't remember why i put the
extra space, possibly for not make easy using some data trhu some
pointer for corrupt all the list)
linkedList a;
a would be
u32* pointeStart
u32 size
u32 randomValueIdentifyTheList
but possible i not understand
Richard Damon
Jul 6, 2018, 1:21:10 PM7/6/18
to
change to object B then there needs to be some way to find object B
given object A. It helps to have those changes to object A be localized
(so the code to initiate the update to B is also localized).
Your comment that you are not maintaining the information in SControl
says that something is not being done right.
If the SControl information is fundamental to the list operation, then
it should be part of it, and the maintenance of it part of the primitives.
If the SControl information is an addon, then the list operations
wouldn't have that information, but all accesses to the list should be
through an API layer that uses the basic list operations but adds the
needed updates to the SControl structures.
In C++, you could make this SControl based list derive from the basic
linked list, and use virtual functions to do this API redirect, allowing
much of the code to not need to know the distinction. This is harder to
do is C.
Rick C. Hodgin
Jul 6, 2018, 1:35:34 PM7/6/18
to
It is setup to be as the structure and pseudo-code initialization data
above indicates. I have the initial list from a..z, and as portions
are added, such as the 1..3 portion, the SControl list expands to hold
all start/end nodes for each portion of the link list
> If the SControl information is fundamental to the list operation, then
> it should be part of it, and the maintenance of it part of the primitives.
> If the SControl information is an addon, then the list operations
> wouldn't have that information, but all accesses to the list should be
> through an API layer that uses the basic list operations but adds the
> needed updates to the SControl structures.
> In C++, you could make this SControl based list derive from the basic
> linked list, and use virtual functions to do this API redirect, allowing
> much of the code to not need to know the distinction. This is harder to
> do is C.
considered using C++ for this code, but my goals are toward CAlive, and
whereas I will support some features of C++ in CAlive, I will not support
them all, nor even 1/3rd of them. As such, I stick closer to C until I
am able to later boostrap my code in my language, and expand it as the
needs arise.
--
Rick C. Hodgin
Bart
Jul 6, 2018, 3:17:51 PM7/6/18
to
On 06/07/2018 18:35, Rick C. Hodgin wrote:
> On 7/6/2018 1:20 PM, Richard Damon wrote:
>> Your comment that you are not maintaining the information in SControl
>> says that something is not being done right.
>
> Oh, I thought I did make it clear above that I am maintaining SControl.
> It is setup to be as the structure and pseudo-code initialization data
> above indicates. I have the initial list from a..z, and as portions
> are added, such as the 1..3 portion, the SControl list expands to hold
> all start/end nodes for each portion of the link list
Are there only two levels of list? So you can't have this:
> On 7/6/2018 1:20 PM, Richard Damon wrote:
>> Your comment that you are not maintaining the information in SControl
>> says that something is not being done right.
>
> Oh, I thought I did make it clear above that I am maintaining SControl.
> It is setup to be as the structure and pseudo-code initialization data
> above indicates. I have the initial list from a..z, and as portions
> are added, such as the 1..3 portion, the SControl list expands to hold
> all start/end nodes for each portion of the link list
A B C D
1 2 3
x y
Is it possible for two second level lists to meet? Like this:
A B C D
1 2 3 x y
Can a second level list be before the first top-level item or after the
last? Like this:
A B C D or: A B C D
1 2 3 1 2 3
Can items from the top level list be deleted to result in any of those
situations?
Will there always be one top level portion, and 0 to N second level
lists? Can the top level list be empty? Can it become empty while there
are still second level lists?
Is the control structure also a linked list? Is the first entry always
the bounds of the top level list, and any subsequent ones always the
second level?
How is the insertion point specified; would it be {B,C} for my top
example (so always with two elements), or after {B} or before {C}?
If a second level span is deleted, does its entry disappear in the
control structure? (Here whether it is a linked list is important; if
not, then any back pointers into it will be problematical if the list
needs to close up.)
Sorry these are just random questions but you need to know the answers
before attempting any coding and I think we're all somewhat in the dark.
So a more rigorous specification might be in order.
--
bart
Rick C. Hodgin
Jul 6, 2018, 3:28:44 PM7/6/18
to
On 7/6/2018 3:17 PM, Bart wrote:
> On 06/07/2018 18:35, Rick C. Hodgin wrote:
>> On 7/6/2018 1:20 PM, Richard Damon wrote:
>
>>> Your comment that you are not maintaining the information in SControl
>>> says that something is not being done right.
>>
>> Oh, I thought I did make it clear above that I am maintaining SControl.
>> It is setup to be as the structure and pseudo-code initialization data
>> above indicates. I have the initial list from a..z, and as portions
>> are added, such as the 1..3 portion, the SControl list expands to hold
>> all start/end nodes for each portion of the link list
>
> Are there only two levels of list?
There are no levels. It is a continuous list that is at the same level.
> On 06/07/2018 18:35, Rick C. Hodgin wrote:
>> On 7/6/2018 1:20 PM, Richard Damon wrote:
>
>>> Your comment that you are not maintaining the information in SControl
>>> says that something is not being done right.
>>
>> Oh, I thought I did make it clear above that I am maintaining SControl.
>> It is setup to be as the structure and pseudo-code initialization data
>> above indicates. I have the initial list from a..z, and as portions
>> are added, such as the 1..3 portion, the SControl list expands to hold
>> all start/end nodes for each portion of the link list
>
> Are there only two levels of list?
> So you can't have this:
>
> A B C D
> 1 2 3
> x y
>
> Is it possible for two second level lists to meet? Like this:
>
> A B C D
> 1 2 3 x y
>
> Can a second level list be before the first top-level item or after the last?
> Like this:
>
> A B C D or: A B C D
> 1 2 3 1 2 3
>
> Can items from the top level list be deleted to result in any of those
> situations?
A B C .. X Y Z chain.
> Will there always be one top level portion, and 0 to N second level lists?
> Can the top level list be empty? Can it become empty while there are still
> second level lists?
>
> Is the control structure also a linked list? Is the first entry always the
> bounds of the top level list, and any subsequent ones always the second level?
is an array that expands up/down as needed. It basically contains
these members:
struct SBuilder
{
char* buffer;
int populated_length;
int allocated_length;
};
When allocated, populated_length is 0, allocated_length is some pre-
defined size (like 4KB). Each SControl structure is 8 bytes, for
example. So it continues up to reach 4KB before it re-allocates and
expands its size.
So, to answer succinctly: they are sequential in a buffer.
> How is the insertion point specified; would it be {B,C} for my top example
> (so always with two elements), or after {B} or before {C}?
chain 1..2..3 exists, and it is inserted between b and c, meaning
it could be injected after b, or before c.
> If a second level span is deleted, does its entry disappear in the control
> structure? (Here whether it is a linked list is important; if not, then any
> back pointers into it will be problematical if the list needs to close up.)
>
> Sorry these are just random questions but you need to know the answers before
> attempting any coding and I think we're all somewhat in the dark.
>
> So a more rigorous specification might be in order.
it has pointers to the start and end of each chain, and those chains
can be inserted anywhere in the middle of the list. And after they
are inserted, any of them can be deleted, or have others inserted,
before or after, any other node.
--
Rick C. Hodgin
Bart
Jul 6, 2018, 4:22:16 PM7/6/18
to
On 06/07/2018 20:28, Rick C. Hodgin wrote:
> On 7/6/2018 3:17 PM, Bart wrote:
>> On 06/07/2018 18:35, Rick C. Hodgin wrote:
>>> On 7/6/2018 1:20 PM, Richard Damon wrote:
>>
>>>> Your comment that you are not maintaining the information in SControl
>>>> says that something is not being done right.
>>>
>>> Oh, I thought I did make it clear above that I am maintaining SControl.
>>> It is setup to be as the structure and pseudo-code initialization data
>>> above indicates. I have the initial list from a..z, and as portions
>>> are added, such as the 1..3 portion, the SControl list expands to hold
>>> all start/end nodes for each portion of the link list
>>
>> Are there only two levels of list?
>
> There are no levels. It is a continuous list that is at the same level.
So you insert {1 2 3} between B and C in {A B C D} to result in:
> On 7/6/2018 3:17 PM, Bart wrote:
>> On 06/07/2018 18:35, Rick C. Hodgin wrote:
>>> On 7/6/2018 1:20 PM, Richard Damon wrote:
>>
>>>> Your comment that you are not maintaining the information in SControl
>>>> says that something is not being done right.
>>>
>>> Oh, I thought I did make it clear above that I am maintaining SControl.
>>> It is setup to be as the structure and pseudo-code initialization data
>>> above indicates. I have the initial list from a..z, and as portions
>>> are added, such as the 1..3 portion, the SControl list expands to hold
>>> all start/end nodes for each portion of the link list
>>
>> Are there only two levels of list?
>
> There are no levels. It is a continuous list that is at the same level.
A B 1 2 3 C D
This is just ordinary linked list processing where you insert or delete
single items or insert sequences.
But you have a separate structure that keeps tabs on certain
subsequences in that list (like the injected {1 2 3} sequence, but
noting the start and end item (as {1, 3} for this example), as well as
the original starting sequence {A,D}.
And you want to keep that structure up to date as a subsequences change.
Adding extra stuff in the middle is not a problem (if allowed), but
removing one of the end items (or the only item if subsequence is only
one element long) means an update in the other structure.
It sounds like you would rather not add extra links to each node to
point into an entry in that structure but that seems the most sensible
to me.
This can be done with a link in each node of an insertion (but a long
insertion can mean 1000s of updates). Or possible a link on the start
item only, but this means that if deleted an item in the middle, you
have to search for the start node.
--
bart
Anton Shepelev
Jul 6, 2018, 4:24:07 PM7/6/18
to
Rick C. Hodgin:
Can you maintain hash-tables of all the 'beg' and 'end'
members and
a. at deletion check whether the node being deleted is
the beginning or the end of some chain,
b. at insertion check whether the node before the one
inserted is the end of some chain and the node after
the one inserted is the beginning of some chain?
That should work in O(1) time.
--
() ascii ribbon campaign -- against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
members and
a. at deletion check whether the node being deleted is
the beginning or the end of some chain,
b. at insertion check whether the node before the one
inserted is the end of some chain and the node after
the one inserted is the beginning of some chain?
That should work in O(1) time.
--
() ascii ribbon campaign -- against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
Rick C. Hodgin
Jul 6, 2018, 4:30:37 PM7/6/18
to
On 7/6/2018 4:22 PM, Bart wrote:
> On 06/07/2018 20:28, Rick C. Hodgin wrote:
>> On 7/6/2018 3:17 PM, Bart wrote:
>>> On 06/07/2018 18:35, Rick C. Hodgin wrote:
>>>> On 7/6/2018 1:20 PM, Richard Damon wrote:
>>>
>>>>> Your comment that you are not maintaining the information in SControl
>>>>> says that something is not being done right.
>>>>
>>>> Oh, I thought I did make it clear above that I am maintaining SControl.
>>>> It is setup to be as the structure and pseudo-code initialization data
>>>> above indicates. I have the initial list from a..z, and as portions
>>>> are added, such as the 1..3 portion, the SControl list expands to hold
>>>> all start/end nodes for each portion of the link list
>>>
>>> Are there only two levels of list?
>>
>> There are no levels. It is a continuous list that is at the same level.
>
> So you insert {1 2 3} between B and C in {A B C D} to result in:
>
> A B 1 2 3 C D
>
> This is just ordinary linked list processing where you insert or delete
> single items or insert sequences.
>
> But you have a separate structure that keeps tabs on certain subsequences in
> that list (like the injected {1 2 3} sequence, but noting the start and end
> item (as {1, 3} for this example), as well as the original starting sequence
> {A,D}.
Correct.
> On 06/07/2018 20:28, Rick C. Hodgin wrote:
>> On 7/6/2018 3:17 PM, Bart wrote:
>>> On 06/07/2018 18:35, Rick C. Hodgin wrote:
>>>> On 7/6/2018 1:20 PM, Richard Damon wrote:
>>>
>>>>> Your comment that you are not maintaining the information in SControl
>>>>> says that something is not being done right.
>>>>
>>>> Oh, I thought I did make it clear above that I am maintaining SControl.
>>>> It is setup to be as the structure and pseudo-code initialization data
>>>> above indicates. I have the initial list from a..z, and as portions
>>>> are added, such as the 1..3 portion, the SControl list expands to hold
>>>> all start/end nodes for each portion of the link list
>>>
>>> Are there only two levels of list?
>>
>> There are no levels. It is a continuous list that is at the same level.
>
> So you insert {1 2 3} between B and C in {A B C D} to result in:
>
> A B 1 2 3 C D
>
> This is just ordinary linked list processing where you insert or delete
> single items or insert sequences.
>
> But you have a separate structure that keeps tabs on certain subsequences in
> that list (like the injected {1 2 3} sequence, but noting the start and end
> item (as {1, 3} for this example), as well as the original starting sequence
> {A,D}.
> And you want to keep that structure up to date as a subsequences change.
> Adding extra stuff in the middle is not a problem (if allowed), but removing
> one of the end items (or the only item if subsequence is only one element
> long) means an update in the other structure.
> It sounds like you would rather not add extra links to each node to point
> into an entry in that structure but that seems the most sensible to me.
about it.
> This can be done with a link in each node of an insertion (but a long
> insertion can mean 1000s of updates). Or possible a link on the start item
> only, but this means that if deleted an item in the middle, you have to
> search for the start node.
--
Rick C. Hodgin
Richard Damon
Jul 6, 2018, 6:38:20 PM7/6/18
to
>>> However, during my processing, I am not maintaining information that
>>> is relative to the loaded SControl structure. I simply traverse the
>>> chain node-by-node as I go through it.
If keeping these structures up to date is part of your requirements,
>>> is relative to the loaded SControl structure. I simply traverse the
>>> chain node-by-node as I go through it.
then you need to maintain them. This should be part of your basic
design, not something you try to 'bolt on' at the end. (And late changes
of this type can be costly is development and/or processing time).
>
>> If the SControl information is fundamental to the list operation, then
>> it should be part of it, and the maintenance of it part of the
>> primitives.
>
> Agreed. This is my current solution the (1) solution above.
the SControl is considered an addon, and the basic list routines are
providing hooks for a higher level set of controls.
Your (2), putting a pointer to the SControls (you need plural, probably
through a form of linked list) that started it would be one way to build
it in, and likely the fastest. Cheaper on memory but more costly on time
would be to have a list of the SControl structures available, and scan
them every time you delete a node.
>
>> If the SControl information is an addon, then the list operations
>> wouldn't have that information, but all accesses to the list should be
>> through an API layer that uses the basic list operations but adds the
>> needed updates to the SControl structures.
>
> ..
>
>> In C++, you could make this SControl based list derive from the basic
>> linked list, and use virtual functions to do this API redirect, allowing
>> much of the code to not need to know the distinction. This is harder to
>> do is C.
>
> I appreciate the consideration, thought, and advice, Richard. I have
> considered using C++ for this code, but my goals are toward CAlive, and
> whereas I will support some features of C++ in CAlive, I will not support
> them all, nor even 1/3rd of them. As such, I stick closer to C until I
> am able to later boostrap my code in my language, and expand it as the
> needs arise.
>
comp.lang.c++, while C++ derived from C, the 'C++ way' to do things is
very often very different from the 'C Way' to do things.
Chris M. Thomasson
Jul 6, 2018, 6:51:33 PM7/6/18
to
On 7/5/2018 6:39 PM, Rick C. Hodgin wrote:
> I have a two-way link-list that traverses a long chain (10s to 100s of
> thousands of nodes). The final chain that's prepared is made up of
> things that are comprised of sub-parts.
>
> Initially I start out with something like this:
> _ _ _ _ _
> |a|--|b|--|c|--|d|-- ... --|z|
>
> It's a node that's in the range of a..z (26 nodes let's say for this
> example). I have a control structure that indicates where it starts
> and stops:
>
> struct SControl
> {
> SNode *beg; // First node, points to a
> SNode *end; // Last node, points to z
> };
>
> In normal processing, need to process other things which produce new
> node chains, and then inject them into the original a..z node chain,
> making that chain longer. It can be visualized like this:
> _ _ _ _ _
> |a|--|b|-+ +-|c|--|d|-- ... --|z|
> | |
> +-----+ +-----+
> | _ _ _ |
> +-|1|--|2|--|3|-+
Fwiw, one hackish way to identify a user node from a SControl node would
> I have a two-way link-list that traverses a long chain (10s to 100s of
> thousands of nodes). The final chain that's prepared is made up of
> things that are comprised of sub-parts.
>
> Initially I start out with something like this:
> _ _ _ _ _
> |a|--|b|--|c|--|d|-- ... --|z|
>
> It's a node that's in the range of a..z (26 nodes let's say for this
> example). I have a control structure that indicates where it starts
> and stops:
>
> struct SControl
> {
> SNode *beg; // First node, points to a
> SNode *end; // Last node, points to z
> };
>
> In normal processing, need to process other things which produce new
> node chains, and then inject them into the original a..z node chain,
> making that chain longer. It can be visualized like this:
> _ _ _ _ _
> |a|--|b|-+ +-|c|--|d|-- ... --|z|
> | |
> +-----+ +-----+
> | _ _ _ |
> +-|1|--|2|--|3|-+
be to steal a low order bit and use it as a tag.
a -> b c -> d -> ... -> z
| ^
v |
cs(b->1) cs(3->c)
| ^
v |
1 -> 2 -> 3
b would have a control structure that made it point to 1 -> 2 -> 3
3 would have a control structure that made it point to c -> d -> ... -> z.
Check the stolen bit in the pointer value to tell normal nodes to ones
with control structures. b and 3 would have this bit set. All others
would not.
Still not exactly sure why a double linked list would not work out here.
One can easily inject multiple nodes at once anywhere in a doubly linked
list.
The stolen bits trick can allow for multiple different data structures
to exist in the same overall data-structure. It tells us what type the
pointer is pointing too.
Richard Damon
Jul 6, 2018, 7:24:46 PM7/6/18
to
you mean by double linked list (a has a pointer to b, and b has a back
pointer to a).
What it seems that Rick wants is to have saved "sub lists" on the main
list so that he can either navigate the whole list a-b-1-2-3-c-d-e-...
or he could navigate the sub list of 1-2-3 by calling up the SControl
structure for the list (start at beg, and go till you have visited end).
Chris M. Thomasson
Jul 6, 2018, 7:46:43 PM7/6/18
to
Chris M. Thomasson
Jul 6, 2018, 7:48:56 PM7/6/18
to
write rarely type of scenario? Do you think it could scale to a
situation where there are a lot of sustained writes?
Rick C. Hodgin
Jul 6, 2018, 9:10:14 PM7/6/18
to
On Friday, July 6, 2018 at 6:38:20 PM UTC-4, Richard Damon wrote:
> On 7/6/18 10:35 AM, Rick C. Hodgin wrote:
> > Oh, I thought I did make it clear above that I am maintaining SControl.
> > It is setup to be as the structure and pseudo-code initialization data
> > above indicates. I have the initial list from a..z, and as portions
> > are added, such as the 1..3 portion, the SControl list expands to hold
> > all start/end nodes for each portion of the link list
>
> My comment was about your statement that:
> >>> However, during my processing, I am not maintaining information that
> >>> is relative to the loaded SControl structure. I simply traverse the
> >>> chain node-by-node as I go through it.
Got it.
> On 7/6/18 10:35 AM, Rick C. Hodgin wrote:
> > Oh, I thought I did make it clear above that I am maintaining SControl.
> > It is setup to be as the structure and pseudo-code initialization data
> > above indicates. I have the initial list from a..z, and as portions
> > are added, such as the 1..3 portion, the SControl list expands to hold
> > all start/end nodes for each portion of the link list
>
> My comment was about your statement that:
> >>> However, during my processing, I am not maintaining information that
> >>> is relative to the loaded SControl structure. I simply traverse the
> >>> chain node-by-node as I go through it.
I meant I do not have an SControl* member on each node, but only
in the one central SControl structure, so I'm not retaining the
reference without a lookup.
--
Rick C. Hodgin
Rick C. Hodgin
Jul 6, 2018, 9:20:47 PM7/6/18
to
On Friday, July 6, 2018 at 7:48:56 PM UTC-4, Chris M. Thomasson wrote:
> What type of operations would you use this for? Perhaps a read mostly,
> write rarely type of scenario? Do you think it could scale to a
> situation where there are a lot of sustained writes?
Various parts of a compiler. Picture a source file with #include
> What type of operations would you use this for? Perhaps a read mostly,
> write rarely type of scenario? Do you think it could scale to a
> situation where there are a lot of sustained writes?
files. You can load the one file, lex everything, assign keywords,
begin parsing, encounter an #include file, repeat the process on it,
then load that loaded + lexed + tokenized chain into the original
chain after the #include line, etc.
SControl maintains every loaded #include file, and its full token
range start to end, and the source code is one continuous expression
from top to bottom.
--
Rick C. Hodgin
Rick C. Hodgin
Jul 6, 2018, 9:23:25 PM7/6/18
to
require the lookup each time.
What does O(1) mean?
--
Rick C. Hodgin
Chris M. Thomasson
Jul 7, 2018, 12:05:41 AM7/7/18
to
Chris M. Thomasson
Jul 7, 2018, 12:06:23 AM7/7/18
to
Chris M. Thomasson
Jul 7, 2018, 12:09:51 AM7/7/18
to
Bart
Jul 7, 2018, 5:40:08 AM7/7/18
to
elsewhere?
And will the list elements be actual tokens?
Because it seems an elaborate way of handling it. When would you delete
tokens that have already long since been parsed? (And false #if/#elif
blocks already dealt with.)
Also, if the list represents a flattening of all tokens in source code
that includes #includes, then that structure can not only be deeply
nested, but the same header, and the same tokens, can occur multiple
times. I think recursively too.
--
bart
Rick C. Hodgin
Jul 7, 2018, 7:03:24 AM7/7/18
to
On 7/7/2018 5:39 AM, Bart wrote:
> On 07/07/2018 02:20, Rick C. Hodgin wrote:
>> On Friday, July 6, 2018 at 7:48:56 PM UTC-4, Chris M. Thomasson wrote:
>>> What type of operations would you use this for? Perhaps a read mostly,
>>> write rarely type of scenario? Do you think it could scale to a
>>> situation where there are a lot of sustained writes?
>>
>> Various parts of a compiler. Picture a source file with #include
>> files. You can load the one file, lex everything, assign keywords,
>> begin parsing, encounter an #include file, repeat the process on it,
>> then load that loaded + lexed + tokenized chain into the original
>> chain after the #include line, etc.
>>
>> SControl maintains every loaded #include file, and its full token
>> range start to end, and the source code is one continuous expression
>> from top to bottom.
>
> Is this an actual compiler, or that header-file reducer you mentioned elsewhere?
Actual compiler.
> On 07/07/2018 02:20, Rick C. Hodgin wrote:
>> On Friday, July 6, 2018 at 7:48:56 PM UTC-4, Chris M. Thomasson wrote:
>>> What type of operations would you use this for? Perhaps a read mostly,
>>> write rarely type of scenario? Do you think it could scale to a
>>> situation where there are a lot of sustained writes?
>>
>> Various parts of a compiler. Picture a source file with #include
>> files. You can load the one file, lex everything, assign keywords,
>> begin parsing, encounter an #include file, repeat the process on it,
>> then load that loaded + lexed + tokenized chain into the original
>> chain after the #include line, etc.
>>
>> SControl maintains every loaded #include file, and its full token
>> range start to end, and the source code is one continuous expression
>> from top to bottom.
>
> Is this an actual compiler, or that header-file reducer you mentioned elsewhere?
> And will the list elements be actual tokens?
a = b + c;
[a][whitespace][=][ws][b][ws][+][ws][c][;]
The whitespaces are removed, leaving:
[a][=][b][+][c][;]
The expression is reduced to its footprint by the semicolon terminator:
[a][=][b][+][c]
> Because it seems an elaborate way of handling it. When would you delete
> tokens that have already long since been parsed? (And false #if/#elif blocks
> already dealt with.)
chain which then auto-injects things to make it work functionally.
Suppose you have:
float a; // 32-bit floating point
double b, c; // 64-bit floating point
set_values(&b, &c);
a = b + c;
In order to get this to work, you have to change the operation (ops)
order to something usable:
step 1: add b,c
step 2: round to 32-bit float, saturate if need be
step 3: store a
So your actual expression "a = b + c;" becomes something more like:
a = saturate_f64_to_f32(b + c);
So you wind up injecting operations in your tokens:
[a][=][saturate_f64_to_f32][(][b][+][c][)]
Then you have physical operation steps:
01: [load b to left]
02: [load c to right]
03: [add]
04: [store result to t0]
05: [push t0 to stack]
06: [call saturate_f64_to_f32]
07: [store return value to t1]
08: [load t1]
09: [store t1 to a]
10: [store t1 to t2]
Tokens can then be deleted from the ops chain after they're consumed.
After step 4, [b][+][c] are replaced with [t0], reducing the expression
to:
[a][=][saturate_f64_to_f32][(][t0][)]
After step 7, [saturate_f64_to_f32][(][t0][)] are replaced with [t]:
[a][=][t1]
After step 9, the final expression [t2] is the last result, and all
processing of that expression is completed:
[t2]
-----
In this way, everything in source code is lexed and parsed as is, and
places where things need to be injected or deleted they are able. The
common expression parsing engine injects auto-fixups for type needs,
auto-injects functions like saturate_f64_to_f32() for CAlive's needs,
and so on.
These are all done with internal codes for the operations taking place,
and are not done with source code. The only source code references
which remain are for named tokens. The rest are all symbolic.
> Also, if the list represents a flattening of all tokens in source code that
> includes #includes, then that structure can not only be deeply nested, but
> the same header, and the same tokens, can occur multiple times. I think
> recursively too.
a new meaning. Since CAlive does not require forward-declarations,
when you use #include it will only load a source file one time, and
it keeps track of what's been loaded so that it only loads it one time.
The expression here:
#include <something.h>
Which is:
[#include][<][something.h][>]
And it's converted to this after loading, or after a subsequent reference
to it when it's already been loaded:
[#include_loaded][<][something.h][>]
So even if it loads or not, it marks it as being loaded and that line
is completed.
Then, to meet the needs where source files actually need to be included
in compilation more than one place, I introduce #reinclude:
#reinclude "myfile.h"
This will load the source file as is multiple times, wherever refer-
enced. And, when you compile in -c90 or -c99 mode, it will work as
it does in C, wrapping each #include to a #reinclude internally.
-----
In CAlive, because forward-declarations are not a requirement, every-
thing for the compilation is loaded, including those things which branch
into unused #ifdef..#endif blocks. They are then parsed in subsequent
passes, and are ultimately deleted if they are unused.
And again, in -c90 or -c99 mode, it works as it does today. My goals
are to get CAlive mode working in total, and then go back and add in
the constraints and relaxations C requires. I do not expect to have
full -c90 or -c99 support until probably 2022 because it is a low
priority for me. My true goals are to draw people away from C and C++
and get them using CAlive for their future projects.
--
Rick C. Hodgin
Bart
Jul 7, 2018, 6:10:07 PM7/7/18
to
On 07/07/2018 12:03, Rick C. Hodgin wrote:
> On 7/7/2018 5:39 AM, Bart wrote:
>> Because it seems an elaborate way of handling it. When would you
>> delete tokens that have already long since been parsed? (And false
>> #if/#elif blocks already dealt with.)
>
> Most of them are not actually deleted, but migrated into an operations
> chain which then auto-injects things to make it work functionally.
> Suppose you have:
>
> float a; // 32-bit floating point
> double b, c; // 64-bit floating point
>
> set_values(&b, &c);
> a = b + c;
>
> In order to get this to work, you have to change the operation (ops)
> order to something usable:
>
> step 1: add b,c
> step 2: round to 32-bit float, saturate if need be
> step 3: store a
>
> So your actual expression "a = b + c;" becomes something more like:
>
> a = saturate_f64_to_f32(b + c);
>
> So you wind up injecting operations in your tokens:
>
> [a][=][saturate_f64_to_f32][(][b][+][c][)]
I'm not sure if this is how it's normally done. That is, by doing
> On 7/7/2018 5:39 AM, Bart wrote:
>> Because it seems an elaborate way of handling it. When would you
>> delete tokens that have already long since been parsed? (And false
>> #if/#elif blocks already dealt with.)
>
> Most of them are not actually deleted, but migrated into an operations
> chain which then auto-injects things to make it work functionally.
> Suppose you have:
>
> float a; // 32-bit floating point
> double b, c; // 64-bit floating point
>
> set_values(&b, &c);
> a = b + c;
>
> In order to get this to work, you have to change the operation (ops)
> order to something usable:
>
> step 1: add b,c
> step 2: round to 32-bit float, saturate if need be
> step 3: store a
>
> So your actual expression "a = b + c;" becomes something more like:
>
> a = saturate_f64_to_f32(b + c);
>
> So you wind up injecting operations in your tokens:
>
> [a][=][saturate_f64_to_f32][(][b][+][c][)]
everything at the level of a linear series of tokens.
Usually a parser reads a stream of tokens, and outputs a tree
representing the static structure of the program. At this point tokens
can be discarded and are of no further interest.
Certainly you wouldn't retain tokens for parentheses which only exist in
source code.
Source code of 'a=(b+c)*d' could result in a structure which might be
displayed like this:
Assign
a
Mul
Add
b
c
d
The entries for a,b,c,d nodes contain references back to a symbol table
which is the other major data structure. But notice: no parentheses. And
the structure specifies how it is to be evaluated rather than having to
deduce it from a token sequence.
Eventually this is flattened again to some sort of generated code. Going
straight from linear tokens to linear code might be done in a simpler
translator, but you still wouldn't bother reorganising token sequences.
(That only happens when dealing with C's macro expansion.)
> Then, to meet the needs where source files actually need to be included
> in compilation more than one place, I introduce #reinclude:
>
> #reinclude "myfile.h"
>
> This will load the source file as is multiple times, wherever refer-
> enced. And, when you compile in -c90 or -c99 mode, it will work as
> it does in C, wrapping each #include to a #reinclude internally.
>
> -----
> In CAlive, because forward-declarations are not a requirement, every-
> thing for the compilation is loaded, including those things which branch
> into unused #ifdef..#endif blocks. They are then parsed in subsequent
> passes, and are ultimately deleted if they are unused.
instead of having actual modules? I notice this post is in the C++ group
and that language is rapidly heading that way. I think you need to be
ahead of the game.
> And again, in -c90 or -c99 mode, it works as it does today. My goals
> are to get CAlive mode working in total, and then go back and add in
> the constraints and relaxations C requires. I do not expect to have
> full -c90 or -c99 support until probably 2022 because it is a low
> priority for me.
write it amongst the same source code as the new language. Why would
anyone want to when they have a sparkling new language to use?
Apart from which I can see endless problems, the prime one being
stifling development of the new language.
--
bart
Rick C. Hodgin
Jul 7, 2018, 8:15:21 PM7/7/18
to
They serve as an expression to resolve down to the form. So in
your example "a=(b+c)*d" here it would be:
a = (b + c) * d; // Inside parenthesis first
a = t0 * d; // Multiply
a = t1; // Store
t2; // Final result, discarded if not used
> Source code of 'a=(b+c)*d' could result in a structure which might be
> displayed like this:
>
> Assign
> a
> Mul
> Add
> b
> c
> d
a tree-like way, but I have changed that plan for this one I have
now. I have additional reasons for doing this as well, which
relate to the ability to step into an expression (when not in
assembly mode), and the ability to set a breakpoint on a portion
of the expression. By doing them in stages like this, and storing
temporary values, there are new features in debugging which are
exposed. And, those temporary values can be removed for the final
release (optimized) build.
> The entries for a,b,c,d nodes contain references back to a symbol table which
> is the other major data structure. But notice: no parentheses. And the
> structure specifies how it is to be evaluated rather than having to deduce it
> from a token sequence.
>
> Eventually this is flattened again to some sort of generated code. Going
> straight from linear tokens to linear code might be done in a simpler
> translator, but you still wouldn't bother reorganising token sequences. (That
> only happens when dealing with C's macro expansion.)
levels. I handle levels using an order of precedence for the expression,
but it's not done in the same way, but it accomplishes the same goal.
>> Then, to meet the needs where source files actually need to be included
>> in compilation more than one place, I introduce #reinclude:
>>
>> #reinclude "myfile.h"
>>
>> This will load the source file as is multiple times, wherever refer-
>> enced. And, when you compile in -c90 or -c99 mode, it will work as
>> it does in C, wrapping each #include to a #reinclude internally.
>>
>> -----
>> In CAlive, because forward-declarations are not a requirement, every-
>> thing for the compilation is loaded, including those things which branch
>> into unused #ifdef..#endif blocks. They are then parsed in subsequent
>> passes, and are ultimately deleted if they are unused.
>
> For a new language are you really perpetuating C's #include file headers
> instead of having actual modules? I notice this post is in the C++ group and
> that language is rapidly heading that way. I think you need to be ahead of
> the game.
intention whatsoever to abandon that legacy development and debugging
effort.
>> And again, in -c90 or -c99 mode, it works as it does today. My goals
>> are to get CAlive mode working in total, and then go back and add in
>> the constraints and relaxations C requires. I do not expect to have
>> full -c90 or -c99 support until probably 2022 because it is a low
>> priority for me.
>
> Forget c90 and c99 support in your own language. That is, being able to write
> it amongst the same source code as the new language. Why would anyone want to
> when they have a sparkling new language to use?
new CAlive code added to an existing C source file compiled with -c90
or -c99. It allows them to step forward, while maintaining the portions
from the past which work and have no need to be re-written or altered.
> Apart from which I can see endless problems, the prime one being stifling
> development of the new language.
--
Rick C. Hodgin
Bart
Jul 8, 2018, 6:33:21 AM7/8/18
to
On 08/07/2018 01:15, Rick C. Hodgin wrote:
> On 7/7/2018 6:09 PM, Bart wrote:
>> For a new language are you really perpetuating C's #include file
>> headers instead of having actual modules? I notice this post is in the
>> C++ group and that language is rapidly heading that way. I think you
>> need to be ahead of the game.
>
> I am. There is a huge source code base written in C, and I have no
> intention whatsoever to abandon that legacy development and debugging
> effort.
Why should that huge code base be abandoned? A new language can still
> On 7/7/2018 6:09 PM, Bart wrote:
>> For a new language are you really perpetuating C's #include file
>> headers instead of having actual modules? I notice this post is in the
>> C++ group and that language is rapidly heading that way. I think you
>> need to be ahead of the game.
>
> I am. There is a huge source code base written in C, and I have no
> intention whatsoever to abandon that legacy development and debugging
> effort.
using existing C code in the form of separately compiled object files
and archives and shared libraries.
What you might need however is for your language to either understand
the header files that describe the interface to those libraries, or to
have a tool that converts them into your language's syntax.
>> Apart from which I can see endless problems, the prime one being
>> stifling development of the new language.
>
> Don't use it. CAlive sounds like it's not for you.
away! C++ is still suffering from the problems of being built on top of C.
--
bart
Rick C. Hodgin
Jul 8, 2018, 10:35:29 AM7/8/18
to
endless problems, Bart.
You don't know enough about my project, it's goals, its purposes, the
intricacies and nuances I have in mind to bring it to fruition, what
part of a larger component/vision I have for this one language in the
larger thing. You presume to know things you don't know, and you fill
in the gaps with thoughts founded on assumptions rather than facts and
hard data.
If you want to educate yourself on CAlive, feel free to do so. The
Google Group exists. But you are right now making assumptions based
on an incomplete picture of both my long-term goals and my publicly
stated intentions revealed to date.
You're essentially answering a matter before your know all the facts.
My goals are comprehensive. RDC/CAlive is one component of a larger
vision that includes new hardware, a new operating system, a complete
new computer experience. If you would take time to learn about this
vision you would probably want to come on board and help out because
I have as my fundamental goal at all points empowering people to be
more and do more without legal hindrances, teaching them in the process
how to do the same in the areas of life they have interest in.
--
Rick C. Hodgin
Bart
Jul 8, 2018, 11:52:42 AM7/8/18
to
On 08/07/2018 15:35, Rick C. Hodgin wrote:
> On 7/8/2018 6:33 AM, Bart wrote:
>> On 08/07/2018 01:15, Rick C. Hodgin wrote:
>>> Don't use it. CAlive sounds like it's not for you.
>> Suggesting people don't use the language won't make the problems go
>> away! C++ is still suffering from the problems of being built on top
>> of C.
>
> I disagree with your fundamental assumption / claim that there will be
> endless problems, Bart.
>
> You don't know enough about my project, it's goals, its purposes, the
> intricacies and nuances I have in mind to bring it to fruition, what
> part of a larger component/vision I have for this one language in the
> larger thing. You presume to know things you don't know, and you fill
> in the gaps with thoughts founded on assumptions rather than facts and
> hard data.
I know that going to the effort of creating a new, incompatible language
> On 7/8/2018 6:33 AM, Bart wrote:
>> On 08/07/2018 01:15, Rick C. Hodgin wrote:
>>> Don't use it. CAlive sounds like it's not for you.
>> Suggesting people don't use the language won't make the problems go
>> away! C++ is still suffering from the problems of being built on top
>> of C.
>
> I disagree with your fundamental assumption / claim that there will be
> endless problems, Bart.
>
> You don't know enough about my project, it's goals, its purposes, the
> intricacies and nuances I have in mind to bring it to fruition, what
> part of a larger component/vision I have for this one language in the
> larger thing. You presume to know things you don't know, and you fill
> in the gaps with thoughts founded on assumptions rather than facts and
> hard data.
(in that new features won't work with C or C++ compilers) while
maintaining all the worst features of C and all its quirks seems a
strange decision to say the least.
--
bart
Rick C. Hodgin
Jul 8, 2018, 12:12:51 PM7/8/18
to
--
Rick C. Hodgin
Bart
Jul 8, 2018, 2:42:24 PM7/8/18
to
On 08/07/2018 17:37, Stefan Ram wrote:
> Bart <b...@freeuk.com> writes:
> Sorry, but when I read something like this ...
>
> I have to implement it (the code is written in BAD STYLE,
> not making proper use of modern auto pointers, not having
> proper exception-safe memory management, not properly
> handling errors in the input, having lines longer than 72
> chars, and such, I stopped working on it as soon as I had
> achieved the wanted output; I have to do the laundry,
> actually.)
> struct tree
> { ::std::string tag; tree * car; tree * cdr;
> tree(): tag{}, car{ nullptr }, cdr{ nullptr } {}
> tree( tree & other ): tag{ other.tag }, car{ other.car }, cdr{ other.cdr } {}
......
And when I see complicated stuff like the above I often have an urge to
rewrite it as plain code.
Since yours is rather limited (single-character terms, no error
checking, only "=", "*" and "+" etc), mine is the same.
My code is below, but it's NOT C++; it's some dynamic code. Normally I'd
use a link to foreign code but I couldn't be bothered.
This has a 50% higher line count than the C++, but the character count
is about half. And it should also be much easier to follow (entry point
is 'start' function).
(Note this uses a 'printexpr' routine, but it could also just do
'println expr' which would output '(Assign,a,(Mul,(Add,b,c),d))' without
any special code.)
-----------------------------------------------------
var symbol
proc start=
lex("a=(b+c)*d")
expr:=readassign()
printexpr(expr)
end
proc lex(?s)=
static var source, slen, currpos
if s.isdef then
source:=s
slen:=s.len
currpos:=0
lex()
return
fi
symbol:=(currpos>=slen |""|source[++currpos])
end
function readterm=
if symbol="(" then
lex()
p:=readmul()
lex()
return p
fi
name:=symbol
lex()
return name
end
function readadd=
p:=readterm()
while symbol="+" do
lex()
p:=("Add",p,readterm())
od
return p
end
function readmul=
p:=readadd()
while symbol="*" do
lex()
p:=("Mul",p,readadd())
od
return p
end
function readassign=
p:=readmul()
while symbol="=" do
lex()
p:=("Assign",p,readmul())
od
return p
end
proc printexpr(expr,indent="")=
if expr.islist then
println indent,,expr[1]
printexpr(expr[2],indent+" ")
printexpr(expr[3],indent+" ")
else
println indent,,expr
fi
end
-----------------------------------------------------
Output:
Assign
a
Mul
Add
b
c
d
--
bart
> Bart <b...@freeuk.com> writes:
> Sorry, but when I read something like this ...
>
> I have to implement it (the code is written in BAD STYLE,
> not making proper use of modern auto pointers, not having
> proper exception-safe memory management, not properly
> handling errors in the input, having lines longer than 72
> chars, and such, I stopped working on it as soon as I had
> achieved the wanted output; I have to do the laundry,
> actually.)
> struct tree
> { ::std::string tag; tree * car; tree * cdr;
> tree(): tag{}, car{ nullptr }, cdr{ nullptr } {}
> tree( tree & other ): tag{ other.tag }, car{ other.car }, cdr{ other.cdr } {}
......
And when I see complicated stuff like the above I often have an urge to
rewrite it as plain code.
Since yours is rather limited (single-character terms, no error
checking, only "=", "*" and "+" etc), mine is the same.
My code is below, but it's NOT C++; it's some dynamic code. Normally I'd
use a link to foreign code but I couldn't be bothered.
This has a 50% higher line count than the C++, but the character count
is about half. And it should also be much easier to follow (entry point
is 'start' function).
(Note this uses a 'printexpr' routine, but it could also just do
'println expr' which would output '(Assign,a,(Mul,(Add,b,c),d))' without
any special code.)
-----------------------------------------------------
var symbol
proc start=
lex("a=(b+c)*d")
expr:=readassign()
printexpr(expr)
end
proc lex(?s)=
static var source, slen, currpos
if s.isdef then
source:=s
slen:=s.len
currpos:=0
lex()
return
fi
symbol:=(currpos>=slen |""|source[++currpos])
end
function readterm=
if symbol="(" then
lex()
p:=readmul()
lex()
return p
fi
name:=symbol
lex()
return name
end
function readadd=
p:=readterm()
while symbol="+" do
lex()
p:=("Add",p,readterm())
od
return p
end
function readmul=
p:=readadd()
while symbol="*" do
lex()
p:=("Mul",p,readadd())
od
return p
end
function readassign=
p:=readmul()
while symbol="=" do
lex()
p:=("Assign",p,readmul())
od
return p
end
proc printexpr(expr,indent="")=
if expr.islist then
println indent,,expr[1]
printexpr(expr[2],indent+" ")
printexpr(expr[3],indent+" ")
else
println indent,,expr
fi
end
-----------------------------------------------------
Output:
Assign
a
Mul
Add
b
c
d
bart
Bart
Jul 8, 2018, 3:02:47 PM7/8/18
to
On 08/07/2018 19:42, Bart wrote:
> On 08/07/2018 17:37, Stefan Ram wrote:
>> Bart <b...@freeuk.com> writes:
>
>> Sorry, but when I read something like this ...
>>
>> I have to implement it (the code is written in BAD STYLE,
>> not making proper use of modern auto pointers, not having
>> proper exception-safe memory management, not properly
>> handling errors in the input, having lines longer than 72
>> chars, and such, I stopped working on it as soon as I had
>> achieved the wanted output; I have to do the laundry,
>> actually.)
>
>> struct tree
>> { ::std::string tag; tree * car; tree * cdr;
>> tree(): tag{}, car{ nullptr }, cdr{ nullptr } {}
>> tree( tree & other ): tag{ other.tag }, car{ other.car }, cdr{
>> other.cdr } {}
> ......
>
> And when I see complicated stuff like the above I often have an urge to
> rewrite it as plain code.
>
> Since yours is rather limited (single-character terms, no error
> checking, only "=", "*" and "+" etc), mine is the same.
(If someone is following that code, the precedences of add and multiply
> On 08/07/2018 17:37, Stefan Ram wrote:
>> Bart <b...@freeuk.com> writes:
>
>> Sorry, but when I read something like this ...
>>
>> I have to implement it (the code is written in BAD STYLE,
>> not making proper use of modern auto pointers, not having
>> proper exception-safe memory management, not properly
>> handling errors in the input, having lines longer than 72
>> chars, and such, I stopped working on it as soon as I had
>> achieved the wanted output; I have to do the laundry,
>> actually.)
>
>> struct tree
>> { ::std::string tag; tree * car; tree * cdr;
>> tree(): tag{}, car{ nullptr }, cdr{ nullptr } {}
>> tree( tree & other ): tag{ other.tag }, car{ other.car }, cdr{
>> other.cdr } {}
> ......
>
> And when I see complicated stuff like the above I often have an urge to
> rewrite it as plain code.
>
> Since yours is rather limited (single-character terms, no error
> checking, only "=", "*" and "+" etc), mine is the same.
are reversed. (It doesn't affect the test input which uses parentheses.)
I don't normally write this style of expression parsing so that's my
excuse. Usually operator precedences are table-driven not syntax-driven.)
--
bart
Chris M. Thomasson
Jul 8, 2018, 4:55:54 PM7/8/18
to
start coding for it.
Kenny McCormack
Jul 8, 2018, 5:39:54 PM7/8/18
to
In article <phttog$uhs$2...@dont-email.me>,
Chris M. Thomasson <invalid_chr...@invalid.invalid> wrote:
...
in its conception, that to ever actually implement it, much less release it
to any member of the general public, would ruin it.
This is actually not an entirely uncommon phenomenon, where an idea is so
good that its keepers cannot let it get out, lest it be soiled by the
outside world. The outside world is, after all, a very dirty place.
--
Elect a clown, expect a circus.
Chris M. Thomasson <invalid_chr...@invalid.invalid> wrote:
...
>> I wish you great success on your language, Bart.
>>
>
>I want to see an early stage of CAlive online. That way, we can actually
>start coding for it.
I think that CAlive is one of those ideas that is so perfect, so immaculate
>>
>
>I want to see an early stage of CAlive online. That way, we can actually
>start coding for it.
in its conception, that to ever actually implement it, much less release it
to any member of the general public, would ruin it.
This is actually not an entirely uncommon phenomenon, where an idea is so
good that its keepers cannot let it get out, lest it be soiled by the
outside world. The outside world is, after all, a very dirty place.
--
Elect a clown, expect a circus.
Rick C. Hodgin
Jul 8, 2018, 7:47:30 PM7/8/18
to
On 7/8/2018 5:39 PM, Kenny McCormack wrote:
> In article <phttog$uhs$2...@dont-email.me>,
> Chris M. Thomasson <invalid_chr...@invalid.invalid> wrote:
> ...
>>> I wish you great success on your language, Bart.
>>
>> I want to see an early stage of CAlive online. That way, we can actually
>> start coding for it.
To Chris: CAlive will be released on or about Christmas 2019 (James
> In article <phttog$uhs$2...@dont-email.me>,
> Chris M. Thomasson <invalid_chr...@invalid.invalid> wrote:
> ...
>>> I wish you great success on your language, Bart.
>>
>> I want to see an early stage of CAlive online. That way, we can actually
>> start coding for it.
4:15 "Lord willing").
> I think that CAlive is one of those ideas that is so perfect, so immaculate
> in its conception, that to ever actually implement it, much less release it
> to any member of the general public, would ruin it.
>
> This is actually not an entirely uncommon phenomenon, where an idea is so
> good that its keepers cannot let it get out, lest it be soiled by the
> outside world. The outside world is, after all, a very dirty place.
I do not want to develop CAlive alone. I keep asking for help. When
God sends someone else, we together will make CAlive better than I'm
able to make it on my own. Until then, I'm giving the best I have to
give from within.
--
Rick C. Hodgin
Chris M. Thomasson
Jul 8, 2018, 11:13:36 PM7/8/18
to
On 7/8/2018 4:47 PM, Rick C. Hodgin wrote:
> On 7/8/2018 5:39 PM, Kenny McCormack wrote:
>> In article <phttog$uhs$2...@dont-email.me>,
>> Chris M. Thomasson <invalid_chr...@invalid.invalid> wrote:
>> ...
>>>> I wish you great success on your language, Bart.
>>>
>>> I want to see an early stage of CAlive online. That way, we can actually
>>> start coding for it.
>
> To Chris: CAlive will be released on or about Christmas 2019 (James
> 4:15 "Lord willing").
Nice to hear. Would that be for the beta?
> On 7/8/2018 5:39 PM, Kenny McCormack wrote:
>> In article <phttog$uhs$2...@dont-email.me>,
>> Chris M. Thomasson <invalid_chr...@invalid.invalid> wrote:
>> ...
>>>> I wish you great success on your language, Bart.
>>>
>>> I want to see an early stage of CAlive online. That way, we can actually
>>> start coding for it.
>
> To Chris: CAlive will be released on or about Christmas 2019 (James
> 4:15 "Lord willing").
Rick C. Hodgin
Jul 9, 2018, 7:56:52 AM7/9/18
to
On 7/8/2018 11:13 PM, Chris M. Thomasson wrote:
> On 7/8/2018 4:47 PM, Rick C. Hodgin wrote:
>> To Chris: CAlive will be released on or about Christmas 2019 (James
>> 4:15 "Lord willing").
>
> Nice to hear. Would that be for the beta?
We shall see, yes?. I could suffer an injury between now and then and
> On 7/8/2018 4:47 PM, Rick C. Hodgin wrote:
>> To Chris: CAlive will be released on or about Christmas 2019 (James
>> 4:15 "Lord willing").
>
> Nice to hear. Would that be for the beta?
not get it completed. I could have some full on inspiration which causes
me to get it completed by Easter 2019. You never know.
My plans are (James 4:15) to have it ready for prime time in the
initial release, to produce production-ready code and allow developers
to start running CAlive apps at that time, to contribute bug reports,
to give ideas and extensions for how things could bet tweaked.
I have mentioned this before, I plan a 1.0 release, and expect a 1.1
release to follow shortly after to fix bugs I was unaware of, then
1.2, 1.3, etc.
My internal goal/mindset is the 2.0 version will be the one I use to
do development on my own operating system, so that will probably be
mid-2020 I shift my development away from RDC/CAlive/Visual FreePro,
Jr., and move toward my kernel. I'd like to have it functional by
2023, and then to turn my attention toward my CPU and have it taped
out by design and working in an FPGA by 2025.
It's all goals and plans though. We shall see what tomorrow holds.
-----
I proceed with this mindset (this is my heart as I go forward):
https://www.biblegateway.com/passage/?search=James+4%3A13-15&version=KJV,NIV
13 Go to now, ye that say, To day or to morrow we will go into
such a city, and continue there a year, and buy and sell,
and get gain:
14 Whereas ye know not what shall be on the morrow. For what
is your life? It is even a vapour, that appeareth for a
little time, and then vanisheth away.
15 For that ye ought to say, If the Lord will, we shall live,
and do this, or that.
Any and all of "my plans" will only succeed if it is part of His
will. I am not a self-made man. I am a component of His creation,
and a minor cog at that. Things must align per His plans, or none
of what I plan will come to fruition.
--
Rick C. Hodgin
Chris M. Thomasson
Jul 10, 2018, 1:49:36 AM7/10/18
to
right? Well, that would be nice. Then, we can start experimenting with
some of your additions in CAlive mode, so to speak. Perhaps help you
work out some bugs, if any. :^)
Perhaps something like:
https://forum.pellesc.de/index.php?topic=7311.0
(when you get some time: please read all!)
A main interest of mine: So far, this is the only c11 compiler that can
handle some of the C11 atomics. If you can get a full blown working C11
impl wrt threading _and_ atomics, I would be very interested. Thanks.
Rick C. Hodgin
Jul 10, 2018, 2:13:15 AM7/10/18
to
On 7/10/2018 1:49 AM, Chris M. Thomasson wrote:
> I would try [CAlive] out. The fact that it can compile existing c99 code right?
Syntatically it should compile C99 code, but it may produce different
results in corner cases because CAlive, by default, handles automatic
upsizing of undersized operands to compute a true result, and then
sign-saturates it to the target, etc.
I eventually plan true c90 and c99 support for CAlive where it is as
they are exactly, with very close to 100% compatibility. But, that's
a few more years off.
--
Rick C. Hodgin
> I would try [CAlive] out. The fact that it can compile existing c99 code right?
Syntatically it should compile C99 code, but it may produce different
results in corner cases because CAlive, by default, handles automatic
upsizing of undersized operands to compute a true result, and then
sign-saturates it to the target, etc.
I eventually plan true c90 and c99 support for CAlive where it is as
they are exactly, with very close to 100% compatibility. But, that's
a few more years off.
--
Rick C. Hodgin
Mr Flibble
Jul 10, 2018, 5:57:10 PM7/10/18
to
goals you had and he accomplished them in his mind's eye. Now he just
randomly shouts at dust motes.
https://en.wikipedia.org/wiki/TempleOS
Please take your medication. When you are better spend your time on more
useful endeavours.
/Flibble
--
"Suppose it’s all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I’d say, bone cancer in children? What’s that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It’s not right, it’s utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That’s what I would say."
Chris M. Thomasson
Jul 10, 2018, 6:22:55 PM7/10/18
to
https://www.reddit.com/user/TempleOSV413
There seems to be some strange white power and pedophile crap in there.
Very weird! I wonder if Rick has conversed with this "thing"?
Chris M. Thomasson
Jul 10, 2018, 6:25:03 PM7/10/18
to
more dark and weird. I don't even want to quote anything in that pile of
whack job garbage! ;^o
>
> Very weird! I wonder if Rick has conversed with this "thing"?
Chris M. Thomasson
Jul 10, 2018, 6:29:57 PM7/10/18
to
https://www.reddit.com/r/programming/comments/5s7wu4/templeos_red_sea_file_system_and_block_chains/
Here is one of his comments, with a terrible word censored in q-bert speak:
___________________________
I had fat32 at first and made redsea second by design.
I am shrewd. I do not fight the last war like a zombie ni%%$#.
Actually it was because FAT32 was patented and I could not use a fat
table. They kept pestering me about FAT32 being patented, so I made my
own just in case. God planned the development of TempleOS. It is divine
intellect.
___________________________
Just a bunch of crap associated with TempleOS. This is Terry. Seems like
a very odd demented thing.
Keith Thompson
Jul 10, 2018, 7:03:29 PM7/10/18
to
"Chris M. Thomasson" <invalid_chr...@invalid.invalid> writes:
[BIG SNIP]
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[BIG SNIP]
> Unfortunately, I just read it a bit more carefully, and things got even
> more dark and weird. I don't even want to quote anything in that pile of
> whack job garbage! ;^o
>
>>
>> Very weird! I wonder if Rick has conversed with this "thing"?
>
> Wow.
WHY. ARE. YOU. POSTING. ABOUT. THIS. HERE???
> more dark and weird. I don't even want to quote anything in that pile of
> whack job garbage! ;^o
>
>>
>> Very weird! I wonder if Rick has conversed with this "thing"?
>
> Wow.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Anton Shepelev
Jul 11, 2018, 5:57:48 AM7/11/18
to
Chris M. Thomasson:
> Just a bunch of crap associated with TempleOS.
> This is Terry. Seems like a very odd demented thing.
The OS in very interesting regardless of the author:
http://www.codersnotes.com/notes/a-constructive-look-at-templeos/
--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
> Just a bunch of crap associated with TempleOS.
> This is Terry. Seems like a very odd demented thing.
http://www.codersnotes.com/notes/a-constructive-look-at-templeos/
--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
Rick C. Hodgin
Jul 11, 2018, 8:48:11 AM7/11/18
to
On 7/10/2018 5:56 PM, Mr Flibble wrote:
> Too late mate: Terry A. Davis has beaten you to it. He had all the same
> goals you had
His goals are similar in some areas, but different overall.
> Too late mate: Terry A. Davis has beaten you to it. He had all the same
> goals you had
I communicated with Terry many years ago before TempleOS was called by
that name. It was an interesting design departure from traditional OS
designs. He introduced me to the concept of char being the default
type to be unnatural, and that it should've been unsigned char. I had
never thought of that before, but the moment he said it I agreed. :-)
> and he accomplished them in his mind's eye. Now he just
> randomly shouts at dust motes.
and maladies. He takes medication, and he has a plethora of mental
issues. He also cites hearing responses directly from God in several
areas, many of which contradict things taught in the Bible.
My heart goes out to him.
> https://en.wikipedia.org/wiki/TempleOS
>
> Please take your medication. When you are better spend your time on more
> useful endeavours.
Leigh.
--
Rick C. Hodgin
Rick C. Hodgin
Jul 11, 2018, 8:49:53 AM7/11/18
to
On 7/11/2018 5:57 AM, Anton Shepelev wrote:
> Chris M. Thomasson:
>> Just a bunch of crap associated with TempleOS.
>> This is Terry. Seems like a very odd demented thing.
>
> The OS in very interesting regardless of the author:
> http://www.codersnotes.com/notes/a-constructive-look-at-templeos/
A channel I watch on YouTube did a video on it a few months back:
> Chris M. Thomasson:
>> Just a bunch of crap associated with TempleOS.
>> This is Terry. Seems like a very odd demented thing.
>
> The OS in very interesting regardless of the author:
> http://www.codersnotes.com/notes/a-constructive-look-at-templeos/
Shine OS a better Temple OS
https://www.youtube.com/watch?v=qsunFPbQDYc
--
Rick C. Hodgin
Chris M. Thomasson
Jul 11, 2018, 4:28:40 PM7/11/18
to
On 7/11/2018 2:57 AM, Anton Shepelev wrote:
> Chris M. Thomasson:
>
>> Just a bunch of crap associated with TempleOS.
>> This is Terry. Seems like a very odd demented thing.
>
> The OS in very interesting regardless of the author:
> http://www.codersnotes.com/notes/a-constructive-look-at-templeos/
>
Agreed. One part I do not quite understand is why the author seemed to
> Chris M. Thomasson:
>
>> Just a bunch of crap associated with TempleOS.
>> This is Terry. Seems like a very odd demented thing.
>
> The OS in very interesting regardless of the author:
> http://www.codersnotes.com/notes/a-constructive-look-at-templeos/
>
stick artificial limitations in the OS. Something about not making it
attractive for mass use wrt "prevent commercialization and corruption."
Here is another quote from:
from:
https://www.reddit.com/r/programming/comments/5s7wu4/templeos_red_sea_file_system_and_block_chains
"
[...]
I am intentionally crippling this operating system, making it a toy with
the wisdom that this will prevent commercialization and corruption.
[...]
"
That aside for a moment, I like the custom file system: RedSea. It is
interesting...
Another quote:
"
[...]
Doing whole file operations is the TempleOS way of doing thinks. It is
the simplest and, ironically, the fastest. It is obnoxious in the
characteristic way that TempleOS is obnoxious, flaunting massive modern
resources in a way that makes old programmers protest.
Doing whole file operations will sabotage efforts to change the 640x480
resolution and violate the ban on multimedia. When doing large,
whole-file operations, immediately memory fragmentation is a serious
problem, but not so for allocations in the range under a Meg (with
occasional larger ones).
[...]
"
TempleOS is _obnoxious_ is just strange to me. Well, at least he seems
to support FAT32. Iirc, I read that TempleOS can use FAT32 and/or RedSea?
Rick C. Hodgin
Jul 14, 2018, 12:21:26 PM7/14/18
to
On 7/14/2018 11:40 AM, Stefan Ram wrote:
> - uses modern auto pointers,
> - has a non-recursive tree destructor,
> - and all lines have less than 72 characters.
>
> main.cpp
> [snip]
Owe! My eyes! :-)
--
Rick C. Hodgin
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>> the code is written in BAD STYLE, not making proper use of
>> modern auto pointers, not having
>
> The new version of the code
>> the code is written in BAD STYLE, not making proper use of
>> modern auto pointers, not having
>
> - uses modern auto pointers,
> - has a non-recursive tree destructor,
> - and all lines have less than 72 characters.
>
> main.cpp
> [snip]
Owe! My eyes! :-)
--
Rick C. Hodgin
0 new messages