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

Groups > comp.lang.c > #94447 > unrolled thread

Most important aspect of any compiler (C or otherwise)

Back to article view | Back to comp.lang.c

Contents

  Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-04 11:02 -0700
    Re: Most important aspect of any compiler (C or otherwise) John Gordon <gordon@panix.com> - 2016-10-04 19:00 +0000
      Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-04 12:08 -0700
        Re: Most important aspect of any compiler (C or otherwise) jacobnavia <jacob@jacob.remcomp.fr> - 2016-10-04 21:56 +0200
          Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-04 13:06 -0700
        Re: Most important aspect of any compiler (C or otherwise) BartC <bc@freeuk.com> - 2016-10-04 21:29 +0100
          Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-04 13:46 -0700
            Re: Most important aspect of any compiler (C or otherwise) BartC <bc@freeuk.com> - 2016-10-05 00:30 +0100
              Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-04 16:58 -0700
                Re: Most important aspect of any compiler (C or otherwise) gazelle@shell.xmission.com (Kenny McCormack) - 2016-10-05 01:07 +0000
              Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-05 08:07 -0700
                Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-05 11:51 -0700
                  Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-05 14:08 -0700
                    Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-05 14:25 -0700
                      Re: Most important aspect of any compiler (C or otherwise) "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-10-05 18:03 -0700
                        Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-05 18:13 -0700
                          Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 19:08 -0700
                            Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-05 19:18 -0700
                              Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 19:31 -0700
                                Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-05 19:43 -0700
                        Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-05 22:22 -0400
                        Re: Most important aspect of any compiler (C or otherwise) jacobnavia <jacob@jacob.remcomp.fr> - 2016-10-06 09:56 +0200
                          Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-06 04:54 -0700
                            Re: Most important aspect of any compiler (C or otherwise) mark.bluemel@gmail.com - 2016-10-06 05:06 -0700
                              Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-06 05:27 -0700
                                Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-06 05:32 -0700
            Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-04 19:12 -0700
        Re: Most important aspect of any compiler (C or otherwise) Ian Collins <ian-news@hotmail.com> - 2016-10-05 13:42 +1300
          Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-05 04:53 -0700
            Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 05:04 -0700
              Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-05 05:12 -0700
    Re: Most important aspect of any compiler (C or otherwise) Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2016-10-07 15:02 -0700
      Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-07 16:17 -0700
        Re: Most important aspect of any compiler (C or otherwise) luser droog <luser.droog@gmail.com> - 2016-10-07 18:11 -0700
          Re: Most important aspect of any compiler (C or otherwise) James Kuyper <jameskuyper@verizon.net> - 2016-10-07 23:53 -0400
            Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-08 01:12 -0700
              Re: Most important aspect of any compiler (C or otherwise) jameskuyper@verizon.net - 2016-10-08 08:05 -0700
                Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-08 10:15 -0700
            Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-08 02:17 -0700
              Re: Most important aspect of any compiler (C or otherwise) gazelle@shell.xmission.com (Kenny McCormack) - 2016-10-08 11:02 +0000
                Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-08 05:14 -0700
                Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-08 12:20 -0700
                  Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-08 15:31 -0700
                    Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-08 15:58 -0700
                      Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-08 17:46 -0700
              Re: Most important aspect of any compiler (C or otherwise) jameskuyper@verizon.net - 2016-10-08 08:09 -0700
            Re: Most important aspect of any compiler (C or otherwise) Keith Thompson <kst-u@mib.org> - 2016-10-08 14:49 -0700
              Re: Most important aspect of any compiler (C or otherwise) "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-09 11:12 -0400
        Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-07 21:15 -0400
          Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-08 01:02 -0700
            Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-08 06:04 -0400
              Re: Most important aspect of any compiler (C or otherwise) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 11:45 +0100
                Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-08 16:57 -0400
                  Re: Most important aspect of any compiler (C or otherwise) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-09 01:25 +0100
                    Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-08 21:29 -0400
              Re: Most important aspect of any compiler (C or otherwise) jameskuyper@verizon.net - 2016-10-08 07:49 -0700
                Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-08 08:04 -0700
                Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-08 16:58 -0400
                  Re: Most important aspect of any compiler (C or otherwise) jameskuyper@verizon.net - 2016-10-08 14:42 -0700
                    Re: Most important aspect of any compiler (C or otherwise) Keith Thompson <kst-u@mib.org> - 2016-10-08 15:08 -0700
                    Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-08 19:27 -0400
                      Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-08 16:37 -0700
                        Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-08 21:30 -0400
      Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-07 18:31 -0700

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

#94447 — Most important aspect of any compiler (C or otherwise)

For me?  Barring the obvious things like functionality and error-free binary
code, it would have to be edit-and-continue.  And without equal.

I make so many continuous typing mistakes that are completely non-reflective
of what my thought processes are that it's absolutely amazing.  I think one
thing and something completely different comes out of my fingers.  This is
such a continuous ongoing aspect of my life, and there are so many times I
not only don't catch it, but I actually read it back correctly when proof-
reading.  It reminds me of the Monty Python skit, "Problem with words,
Thripshaw's Disease":

     Doctor:  "But recently you have been having this problem with your
              word order."
    Patient:  "Absolutely.  What makes it worse is that sometimes at the
               end of a sentence I'll come out with the wrong fusebox."
     Doctor:  "Fusebox?"
    Patient:  "And the thing about saying the wrong word is that a) I
               don't notice it, and b) sometimes orange water given
               bucket of plaster."

-----
As such, I view edit-and-continue as the single most desirable asset of
any software developer.  It is a fully primary area of focus for my CAlive
compiler and IDE.

Best regards,
Rick C. Hodgin

[toc] | [next] | [standalone]

#94449

In <20aae408-4b77-483a-bb84-d05f5240f415@googlegroups.com> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> For me?  Barring the obvious things like functionality and error-free binary
> code, it would have to be edit-and-continue.  And without equal.

So when the compiler encounters an error, it retains the compilation
artifacts (parse tree, symbol table, etc.) up to that point, and when the
user corrects the error it continues compiling where it left off?

What if the correction changed something that has already been compiled?

How much time can it possibly save?  Compilation is pretty fast, no?

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

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

#94451

On Tuesday, October 4, 2016 at 3:00:45 PM UTC-4, John Gordon wrote:
> In <20aae408-4b77-483a-bb84-d05f5240f415@googlegroups.com> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > For me?  Barring the obvious things like functionality and error-free binary
> > code, it would have to be edit-and-continue.  And without equal.
> 
> So when the compiler encounters an error, it retains the compilation
> artifacts (parse tree, symbol table, etc.) up to that point, and when the
> user corrects the error it continues compiling where it left off?
> 
> What if the correction changed something that has already been compiled?
> 
> How much time can it possibly save?  Compilation is pretty fast, no?

There are two approaches to the design.  Microsoft uses the top-down
recompilation which then looks for the deltas or diffs between the
generated binary images, and then updates things accordingly.  It often
breaks data or functions on the stack, or fails to compile completely
if you stray away.

The model I'm using for CAlive takes the approach of saving the full
compilation state.  Compilation is carried out continuously as things
are changed.  But in general, dependency trees are maintained and if
things which were dependent upon something that's changed has changed,
the entire related lines of source code are stricken and recompiled.

The last three passes of the compiler are static, and these apply the
deltas to the binary image and data, even auto-injecting stale members
during compilation to deal with things that have been actively deleted,
but remain in data or on the stack.

And a full recompile can be signaled at any time with a single command
or button click in the IDE.

And to satiate Ben's oft-comment at this point:  These are all the
planned operations.  They are not coded yet, but are almost completely
designed.  A few more aspects to find solutions to.

Best regards,
Rick C. Hodgin

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

#94455

Le 04/10/2016 à 21:08, Rick C. Hodgin a écrit :
> The model I'm using for CAlive takes the approach of saving the full
> compilation state.  Compilation is carried out continuously as things
> are changed.  But in general, dependency trees are maintained and if
> things which were dependent upon something that's changed has changed,
> the entire related lines of source code are stricken and recompiled.

In paper, everything runs, is very clear, etc. Since CAlive is vaporware 
and you do not seem to know what you are talking about, I have some 
doubts about even the feasibility of what you are saying you will do.

I have the feeling that you start this discussions vaguely on topic to 
mask the fact that you post religious crap all over the place.

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

#94456

On Tuesday, October 4, 2016 at 3:56:56 PM UTC-4, jacobnavia wrote:
> Le 04/10/2016 à 21:08, Rick C. Hodgin a écrit :
> > The model I'm using for CAlive takes the approach of saving the full
> > compilation state.  Compilation is carried out continuously as things
> > are changed.  But in general, dependency trees are maintained and if
> > things which were dependent upon something that's changed has changed,
> > the entire related lines of source code are stricken and recompiled.
> 
> In paper, everything runs, is very clear, etc. Since CAlive is vaporware 
> and you do not seem to know what you are talking about, I have some 
> doubts about even the feasibility of what you are saying you will do.
> 
> I have the feeling that you start this discussions vaguely on topic to 
> mask the fact that you post religious crap all over the place.

CAlive already has a lot of its code developed for VFrP and VJr, two
xbase languages that are also incomplete, but possess a large base of
development (over 100K lines between the two of them, plus their other
supporting apps).  And, I've spent a great deal of time offline going
over how to handle the processing of all of the features I've added to
CAlive.  I have nearly every one of them sorted out, but there are a
few that I'm still trying to figure out the best way to incorporate
them into the overall RDC (Rapid Development Compiler) framework I'm
creating, which is not just this CAlive compiler, but is the vehicle
which will make CAlive exist, and also many other languages (prayerfully)
exist as well.

My goals in software design are comprehensive.  I am targeting a 25-year
plan for my life.  I'm 47 today.  I began on the project 4 years ago.  I
have 21 years left to complete all of the things I want to complete.  I
will work on it as much as I'm able, and whatever remains I'll leave for
my posterity to continue.

As for the "religious" posts, I have no hidden agenda, Jacob.  When I
post something about Jesus it's because it's appropriate to do so.  There
are people in this forum (and the other forums I post into) who will never
go to a church, never visit a religious forum.  They are valuable people
too, and I will make sure that when I stand before the Lord someday I will
be able to look Him in the eye and say, "Yes, Lord, I told them as best as
I was able."

This particular thread was started today because I have spent at least an
hour correcting my many typing mistakes on source code I've developed.
Some days are worse than others, and today's been pretty bad.  It causes
me frustration when it keeps happening over and over on the most simple
things.  I long for an edit-and-continue compiler in the language I'm
currently working in (Microsoft Visual FoxPro), which is why I began
writing VFrP and VJr, both open source alternatives for FoxPro and other
xbase languages.

Best regards,
Rick C. Hodgin

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

#94457

On 04/10/2016 20:08, Rick C. Hodgin wrote:
> On Tuesday, October 4, 2016 at 3:00:45 PM UTC-4, John Gordon wrote:
>> In <20aae408-4b77-483a-bb84-d05f5240f415@googlegroups.com> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>
>>> For me?  Barring the obvious things like functionality and error-free binary
>>> code, it would have to be edit-and-continue.  And without equal.
>>
>> So when the compiler encounters an error, it retains the compilation
>> artifacts (parse tree, symbol table, etc.) up to that point, and when the
>> user corrects the error it continues compiling where it left off?
>>
>> What if the correction changed something that has already been compiled?
>>
>> How much time can it possibly save?  Compilation is pretty fast, no?
>
> There are two approaches to the design.  Microsoft uses the top-down
> recompilation which then looks for the deltas or diffs between the
> generated binary images, and then updates things accordingly.  It often
> breaks data or functions on the stack, or fails to compile completely
> if you stray away.

Microsoft Visual Studio, if that's what you're using, is a massive 1.5 
million *file* application. Files, not lines!

Maybe you need something along those lines for an application that could 
otherwise take *hours* to rebuild.

It might well however have taken them considerably more than 21 man years.

> The model I'm using for CAlive takes the approach of saving the full
> compilation state.  Compilation is carried out continuously as things
> are changed.  But in general, dependency trees are maintained and if
> things which were dependent upon something that's changed has changed,
> the entire related lines of source code are stricken and recompiled.

I used a completely different approach decades ago when developing 
applications. Most user-level commands and features were implemented as 
independent scripts. Scripts could be edited, compiled, run and re-run 
from within the application, without needing to restart the app or go 
through the same series of steps necessary to set up the data. If it 
went wrong, I was still in the application.

But this is much, much simpler than what I think you're trying to do, 
which I believe is some restart at the statement level rather than module.

-- 
Bartc

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

#94458

On Tuesday, October 4, 2016 at 4:29:12 PM UTC-4, Bart wrote:
> On 04/10/2016 20:08, Rick C. Hodgin wrote:
> > On Tuesday, October 4, 2016 at 3:00:45 PM UTC-4, John Gordon wrote:
> >> In <20aae408-4b77-483a-bb84-d05f5240f415@googlegroups.com> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >>
> >>> For me?  Barring the obvious things like functionality and error-free binary
> >>> code, it would have to be edit-and-continue.  And without equal.
> >>
> >> So when the compiler encounters an error, it retains the compilation
> >> artifacts (parse tree, symbol table, etc.) up to that point, and when the
> >> user corrects the error it continues compiling where it left off?
> >>
> >> What if the correction changed something that has already been compiled?
> >>
> >> How much time can it possibly save?  Compilation is pretty fast, no?
> >
> > There are two approaches to the design.  Microsoft uses the top-down
> > recompilation which then looks for the deltas or diffs between the
> > generated binary images, and then updates things accordingly.  It often
> > breaks data or functions on the stack, or fails to compile completely
> > if you stray away.
> 
> Microsoft Visual Studio, if that's what you're using, is a massive 1.5 
> million *file* application. Files, not lines!

Visual Studio is a full IDE with a lot more features than I intend for my
IDE.  It has SQL query abilities, editors for GUI components, etc.  I
will offer those types of features via extensions that people can add.

> Maybe you need something along those lines for an application that could 
> otherwise take *hours* to rebuild.

The largest application I have compiles in about 10 seconds in Visual
Studio, and about the same in GCC.

I don't need all of the functionality of Visual Studio.  The main features
I use are the general IDE ability to redefine the workspace as required,
the Code Definition window (invaluable), and the refactoring abilities it
has, and those it can feed into add-on programs like Visual Assist X by
Whole Tomato (worth its weight in gold).

> It might well however have taken them considerably more than 21 man years.

No doubt.

> > The model I'm using for CAlive takes the approach of saving the full
> > compilation state.  Compilation is carried out continuously as things
> > are changed.  But in general, dependency trees are maintained and if
> > things which were dependent upon something that's changed has changed,
> > the entire related lines of source code are stricken and recompiled.
> 
> I used a completely different approach decades ago when developing 
> applications. Most user-level commands and features were implemented as 
> independent scripts. Scripts could be edited, compiled, run and re-run 
> from within the application, without needing to restart the app or go 
> through the same series of steps necessary to set up the data. If it 
> went wrong, I was still in the application.

I've thought a lot about how to implement what I call LiveCode (edit-and-
continue).  I concluded that I want the ability to connect to a running
binary image that's been deployed on a user machine, to be able to remote
into that binary image, apply the appropriate program database, and allow
full editing as it is.  But the goals of having an end-user application
is speed and efficiency.  As such, support for the binary image must exist
through the entire compiler stack, including optimizations.

It's a tall order.  I'm giving it my best and it's undoubtedly less than
I could do along with others helping me.  It has always been my intention
to have others helping me, but so far no one's come on board to help.  A
few inquiries, a few promises, but nothing's come to fruition yet.

> But this is much, much simpler than what I think you're trying to do, 
> which I believe is some restart at the statement level rather than module.

CAlive allows something I call Horizontal Debugging, which allows you to
even step into an expression, through individual components.  So, CAlive
has to maintain context information about where to restart for the inner
parts of an expression, as well as lines.

It's a comprehensive project.  Everyone I've shown the details to in person
so far tell me I'm crazy.  But, it's the goal I have and it's what's upon
my heart.  It's been there since the early 90s.  I've worked on various
parts at various times since then, but as I matured and began to look at
the larger "life's meaning" questions, I began to look into the philosophy
of what I was trying to do.  I stepped back and considered the project in
the overall scheme of things, and not just as a tool, but as an offering
unto the Lord, unto mankind, one given over to helping other people and
making their lives better, rather than doing it for money.  It's an outward
expression of the love I feel inside from the relationship I have with my
Lord and Savior, which is also why I haven't found anyone to come on board
and help me yet ... because I note that point in my source code, mention it
in emails, and wear it outwardly in the things I do.  People recognize that
for what it is and stay away, always to my pain.

I don't imagine it will always be like this.  Either the end-time events
will make it impossible to continue to develop due to life's hardships at
that time, or the rapture will take place, or other people will ultimately
at some point see the value in helping me and then come on board to do just
that, also helping themselves and other people as well.

I keep longing for that day when developer #2 comes on board to help out
on an ongoing basis.  So far, I've had a couple nibbles, but other than that
it's just me and the crickets ongoing, and let me tell you that four years
of that kind of not only isolation in development, but to have people keep
telling you over and over what a ludicrous idea it is, or how I'll never be
able to complete it, or how I odn't have the skills to complete it, it is
really quite a continuous pounding to endure when all you possess within is
the desire to give people the absolute best of what you have, coupled to
the absolute best of what they have, as a collaborative effort given over
to make other people's lives better (and also my own of course, as I think
these tools will be wonderful when completed).

There's only one reason I am able to keep going.  I've tried many times to
quit, and literally every time I've gotten to the point where I'm ready to
walk away, that very day something would come which encouraged me anew.
I've actually stood there at times with my mouth hanging open in disbelief
at how it's all happened.

I'm resolved now to continue on so long as I can.  But, I can also tell
that as I'm getting older I'm not able to think as clearly as I used to,
or go as deep as I used to, or work for as long on a problem as I used to.
I'm losing my edge and things just take longer now.  But, it's all part
of it.  Whereas things used to come to me so easily, now they're harder.
I have to really want it now, whereas before it was just given to me and
I ran with it.

Best regards,
Rick C. Hodgin

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

#94460

On 04/10/2016 21:46, Rick C. Hodgin wrote:
> On Tuesday, October 4, 2016 at 4:29:12 PM UTC-4, Bart wrote:

>> But this is much, much simpler than what I think you're trying to do,
>> which I believe is some restart at the statement level rather than module.
>
> CAlive allows something I call Horizontal Debugging, which allows you to
> even step into an expression, through individual components.  So, CAlive
> has to maintain context information about where to restart for the inner
> parts of an expression, as well as lines.

In that case you'd probably find it a lot easier to run an interpreter 
on your code while debugging, rather than trying to do it on binary 
native code.

> It's a comprehensive project.

> I keep longing for that day when developer #2 comes on board to help out
> on an ongoing basis.  So far, I've had a couple nibbles, but other than that
> it's just me and the crickets ongoing, and let me tell you that four years
> of that kind of not only isolation in development

I've worked in isolation since around 1980, other than contacts with 
clients. I found it a novelty recently to see youtube videos with people 
actually discussing programming stuff out loud!

> There's only one reason I am able to keep going.  I've tried many times to
> quit, and literally every time I've gotten to the point where I'm ready to
> walk away,

I've had that too - why not let someone else take over the headache of 
creating these languages, and supporting the implementations and 
provided large numbers of libraries. And yet...

But I just think of the stuff I do as a diversion. Like other people do 
sudoku or build things in their sheds. (It's also cool when people see 
me doing stuff on a laptop when travelling, yet there is no WiFi. What 
can I possibly be doing!)

Just don't let it take over your life.

-- 
Bartc

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

#94461

Bartc wrote:
> Rick C. Hodgin wrote:
> > It's a comprehensive project.
> >
> > I keep longing for that day when developer #2 comes on board to help out
> > on an ongoing basis. So far, I've had a couple nibbles, but other than that
> > it's just me and the crickets ongoing, and let me tell you that four years
> > of that kind of not only isolation in development
>
> I've worked in isolation since around 1980, other than contacts
> with clients.

I'm trying to create a God-fearing GNU / Linux alternative with hardware
support as well, including CPUs, motherboards, peripheral hardware, and
even manufacturing at some late point.  It is a full hardware and software
stack created in direct response to the teachings of Jesus Christ, in giving
unto others rather than hoarding behind copyrights and patents.
It is a labor of love applied in this industry, something I would like
to see happen in all industries that are of benefit.  It's part of the Village Freedom Project, of freeing us from traditional
models of "seek gain for self," to instead apply the teachings of Jesus Christ
of "seek gain for others, and in so doing also gain for yourself, through
their gain."

It is not something I can do alone, nor do I want to.  I have good ideas, a direct
philosophical vision, a strong drive, and a solid and growing knowledge and
understanding of what's required in all disciplines for my project to
succeed.

People can benefit from what I have to offer, and the One from / for whom
I'm offering it.  By following the teachings of Jesus Christ, everybody gains
maximally.  That is my goal, and it is not mine alone.  Many people just don't
realize yet that they also have that goal.

Best regards,
Rick C. Hodgin

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

#94463

In article <8a439a6c-5a61-43dd-9fe9-0d2dd0587514@googlegroups.com>,
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
...
>I'm trying to create a God-fearing GNU / Linux alternative with
>hardware support as well, including CPUs, motherboards, peripheral
>hardware, and even manufacturing at some late point. It is a full
>hardware and software stack created in direct response to the teachings
>of Jesus Christ, in giving unto others rather than hoarding behind
>copyrights and patents. It is a labor of love applied in this industry,
>something I would like to see happen in all industries that are of
>benefit. It's part of the Village Freedom Project, of freeing us from
>traditional models of "seek gain for self," to instead apply the
>teachings of Jesus Christ of "seek gain for others, and in so doing
>also gain for yourself, through their gain."

Somebody needs to get back on their meds....

>It is not something I can do alone, nor do I want to. I have good
>ideas, a direct philosophical vision, a strong drive, and a solid
>and growing knowledge and understanding of what's required in all
>disciplines for my project to succeed.

Screwball.

>People can benefit from what I have to offer, and the One from / for
>whom I'm offering it. By following the teachings of Jesus Christ,
>everybody gains maximally. That is my goal, and it is not mine alone.
>Many people just don't realize yet that they also have that goal.

Off Topic.

>Best regards,
>Rick C. Hodgin

More than a few screws loose.


-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain in
compliance with said RFCs, the actual sig can be found at the following web address:
	http://www.xmission.com/~gazelle/Sigs/RoyDeLoon

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

#94482

On Tuesday, October 4, 2016 at 6:31:08 PM UTC-5, Bart wrote:
> > CAlive allows something I call Horizontal Debugging, which allows you to
> > even step into an expression, through individual components.  So, CAlive
> > has to maintain context information about where to restart for the inner
> > parts of an expression, as well as lines.
> 
> In that case you'd probably find it a lot easier to run an interpreter 
> on your code while debugging, rather than trying to do it on binary 
> native code.

While Visual Studio can do amazing things with edit-and-continue even in C
code that makes heavy use of macros, there are many cases where code cannot
be edited without abandoning execution.  In languages like Forth where a
programmer manipulates code objects rather than merely editing a source
file, the system can maintain a clear relationship between the code and the
execution state, but in languages which are designed on an "edit source and
then compile" model things can get murky.  No matter how brilliant an IDE
may be at handling edit-and-continue features, there will be cases where it
is not possible to make a necessary change without restarting the program.

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

#94489

On Wednesday, October 5, 2016 at 11:09:38 AM UTC-4, supe...@casperkitty.com wrote:
> On Tuesday, October 4, 2016 at 6:31:08 PM UTC-5, Bart wrote:
> > > CAlive allows something I call Horizontal Debugging, which allows you to
> > > even step into an expression, through individual components.  So, CAlive
> > > has to maintain context information about where to restart for the inner
> > > parts of an expression, as well as lines.
> > 
> > In that case you'd probably find it a lot easier to run an interpreter 
> > on your code while debugging, rather than trying to do it on binary 
> > native code.
> 
> While Visual Studio can do amazing things with edit-and-continue even in C
> code that makes heavy use of macros, there are many cases where code cannot
> be edited without abandoning execution.  In languages like Forth where a
> programmer manipulates code objects rather than merely editing a source
> file, the system can maintain a clear relationship between the code and the
> execution state, but in languages which are designed on an "edit source and
> then compile" model things can get murky.  No matter how brilliant an IDE
> may be at handling edit-and-continue features, there will be cases where it
> is not possible to make a necessary change without restarting the program.

Outside of express hardware state changes, or express external API interface
connections, that's not true, Mr. Supercat.  All software changes can be made
to update everything related to its ABI appropriately.

My literal goal with RDC and LiveCode is to be able to create a blank
project, create a single myapp.ca file, begin with the code:

    int main(int argc, char* argv[])
    {
        return 0;
    }

Compile it, single-step into it, and then continue typing to build some
equivalent of something like the entire LibreOffice suite without every
stopping execution.  So long as it's just software, and you have the
source code and are running a CAlive compiled version for every loaded
DLL, it should all work.

Now, that's the goal and the plan.  We'll soon see if I can actually do
it.

Best regards,
Rick C. Hodgin

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

#94498

On Wednesday, October 5, 2016 at 1:52:19 PM UTC-5, Rick C. Hodgin wrote:
> On Wednesday, October 5, 2016 at 11:09:38 AM UTC-4, supercat wrote:
> > While Visual Studio can do amazing things with edit-and-continue even in C
> > code that makes heavy use of macros, there are many cases where code cannot
> > be edited without abandoning execution.  In languages like Forth where a
> > programmer manipulates code objects rather than merely editing a source
> > file, the system can maintain a clear relationship between the code and the
> > execution state, but in languages which are designed on an "edit source and
> > then compile" model things can get murky.  No matter how brilliant an IDE
> > may be at handling edit-and-continue features, there will be cases where it
> > is not possible to make a necessary change without restarting the program.
> 
> Outside of express hardware state changes, or express external API interface
> connections, that's not true, Mr. Supercat.  All software changes can be made
> to update everything related to its ABI appropriately.

That's only true if an implementation can track everything having to do
with where objects and pointers come from.  Given:

    struct foo { int arr[4]; int y; };
    struct foo bar;

What should happen if a pointer to bar.y is passed to a function, code is
stopped within that function, and array "arr" is changed to 5 elements?

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

#94499

Supercat wrote:
> What should happen if a pointer to bar.y is passed to a function,
> code is stopped within that function, and array "arr" is changed to 5 elements?

The location of all data is known.  Pointers can be examined to see
what they point into in ABI_stale, to see how things are translated
into ABI_new, and a series of data change ops are created, including
updating pointer values.

Everything in the ABI is known.  It's a natural and resolvable projection
from the logical image into the physical.

Best regards,
Rick C. Hodgin

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

#94504

On 10/5/2016 2:25 PM, Rick C. Hodgin wrote:
> Supercat wrote:
>> What should happen if a pointer to bar.y is passed to a function,
>> code is stopped within that function, and array "arr" is changed to 5 elements?
>
> The location of all data is known.  Pointers can be examined to see
> what they point into in ABI_stale, to see how things are translated
> into ABI_new, and a series of data change ops are created, including
> updating pointer values.
>
> Everything in the ABI is known.  It's a natural and resolvable projection
> from the logical image into the physical.

When do you think your compiler might be is a state that can allow for a 
beta test?

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

#94505

Chris M. Thomasson wrote:
> When do you think your compiler might be is a state that can
> allow for a beta test?

I intend to be using it (James 4:15) around the 2018/2019 switchover,
so I would say early/mid-2018 for beta versions.  I'd like to have Supercat
add fully compliant C90 and C99 support in 2019/2020.

Best regards,
Rick C. Hodgin

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

#94507

On Thursday, October 6, 2016 at 2:15:40 AM UTC+1, Rick C. Hodgin wrote:
> Chris M. Thomasson wrote:
> > When do you think your compiler might be is a state that can
> > allow for a beta test?
> 
> I intend to be using it (James 4:15) around the 2018/2019 switchover,
> so I would say early/mid-2018 for beta versions.  I'd like to have
> Supercat add fully compliant C90 and C99 support in 2019/2020.
> 
We moved to Agile recently. Whilst it's still to early to say how it 
will work, it seems to be much better. What used to happen was that
we'd agree on a deadline "comfortably off", which turned out to be
pure fantasy. Now we have micro-deadlines, and add a bit of 
functionality in each week-long sprint.

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

#94508

Malcolm McLean wrote:
> We moved to Agile recently. Whilst it's still to early to say how
> it will work, it seems to be much better. What used to happen
> was that we'd agree on a deadline "comfortably off",
> which turned out to be pure fantasy. Now we have micro-deadlines,
> and add a bit of functionality in each week-long sprint.

I do not expect to be working alone forever.  This effort I'm in
pursuit of has value, and at some point other Christians will come
on board and we together will complete the entirety of the project,
not just the compiler.

For now it's just me.  I have to maintain the big picture vision and
pursue it.  I'm able to work on the code outside of other constraints
only.  It's slow going, and seems to go in spurts as by example over
time.

Best regards,
Rick C. Hodgin

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

#94511

On Thursday, October 6, 2016 at 3:20:22 AM UTC+1, Rick C. Hodgin wrote:
> Malcolm McLean wrote:
> > We moved to Agile recently. Whilst it's still to early to say how
> > it will work, it seems to be much better. What used to happen
> > was that we'd agree on a deadline "comfortably off",
> > which turned out to be pure fantasy. Now we have micro-deadlines,
> > and add a bit of functionality in each week-long sprint.
> 
> I do not expect to be working alone forever.  This effort I'm in
> pursuit of has value, and at some point other Christians will come
> on board and we together will complete the entirety of the project,
> not just the compiler.
> 
> For now it's just me.  I have to maintain the big picture vision and
> pursue it.  I'm able to work on the code outside of other constraints
> only.  It's slow going, and seems to go in spurts as by example over
> time.
> 
I know.
If you have a big picture goal, on a timescale of over a year, you
may achieve it you may not. If you've got a little goal, on a  
timescale of a week or two weeks, again you may achieve or or you
may not. But the consequences of failure are different. If you
can't achieve a week's goal in a week, maybe you can achieve it in
three weeks. That's something and nothing in itself, but if it's
always happening then that tells you that you are over-ambitious
and the year overall deadline is actually going to be about three
years (which might well make the whole project unrealistic). If
you can't achieve week's deadline in three weeks then that particular
feature maybe you don't have the skills to implement at all, so it
must be dropped or you must find someone who can tell you how to
set about it.

(I found this with the binary image library. I wanted to out it into
a better state for distribution. In fact documenting each component
took far longer than I expected. But it's being done bit by bit,
incrementally.)

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

#94514

Ron Reedy, co-founder of Peregrine Semiconductor, said that
he's discovered that almost every project will take 3x as long as
expected.  He actually thinks it's pi times as long. :-)

My goals include other people helping me.  And I'll continue on in
my big picture goals until I complete the project alone, or I get help
from others, or I'm called out of this world.

My current goal is to have my assembler completed by the end
of this year, and my kernel assembling in it correctly.  I'm currently
about a month behind, but I had work that needed done around
the house in the summer / fall months.

Best regards,
Rick C. Hodgin

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

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

Back to top | Article view | comp.lang.c

csiph-web