Non-constant constant strings

[David Brown]

It's my experience. I haven't encountered any task I've done to date
that wasn't done faster when I could make immediate changes. YMMV.

You made it perfectly clear in an earlier post that you have virtually
now experience in embedded systems. That's fair enough - no one has
experience of everything. But since you have almost no idea about
embedded development, you sound foolish with statements like your claims
of 50x greater productivity.

I have done development at the opposite end of your scales - where
programs were burned into EPROM chips and mounted on a board for
testing. Being able to re-flash the program in system is certainly a
big step up for debugging productivity, but even there the factor is
closer to 2 or 3 than 50. And that is just for the debugging part of
the development, which is a small part of the process.

I am well aware of the benefits of modifying code while running, as I do
it with Python code on PC's. Like Lisp, as mentioned by another poster,
it is possible to do this in a consistent and safe manner, with
real-world code - unlike with C. It can be convenient, but it is not
"shocking", nor does it make a huge difference to development or debug time.

I have dyslexia and often make unexpected mistakes. They weren't due to
an error in thinking, but in the translation of my thoughts into the parts
that do the typing, or when I'm speaking to someone, by using the wrong
words. It's a reality that often sparks humor in face-to-face conversation
because I rarely catch me using the wrong words, because in my thinking I
was not using the wrong words.

Getting the wrong words on occasion is not dyslexia, nor is it a related
condition (though continuously failing to learn or remember correct
terms /can/ be related to dyslexia). But such conditions affect many
people to a greater or lesser degree - I don't find my mild dyslexia
affects my programming. My documentation would be "entertaining" if it
weren't for spell checkers, but I don't think it excuses bugs in my code.

David, I am a full-time professional software developer.

Let me further qualify and say that the processes I listed are typical
for a professional /embedded/ developer - there are many types of
software development, and the processes and balances are not the same.

However, I cannot imagine any serious development process which involves
/major/ amounts of fiddling around with changing live code, at least
with a language and system that is not designed for it. I can well see
that it can be useful on occasion - but nothing remotely like the
benefits you are claiming.

 

[Ben Bacarisse]

[...] In short, the
entirety of my goals are to give you something for free, expecting nothing
in return, that you may improve your life, and the lives of those around
you through my offering.

This seems implausible. How do you know what I (or others) want? If
you give me something I don't want it hardly improves my life. It may
even make it worse. At the very least you are squandering your time and
expertise if hardly anyone wants what you are building.

I don't want yet another low-level language based on C. I don't want
yet another non-portable OS written in assembler. How have you
determined that enough people want these things that it is even worth
your time doing it? I couldn't even find a description of why these
thing might be of any benefit at all -- but that could be just I missed
the documents describing the overall designs and their benefits.

I don't think you are being entirely honest with yourself about the
entirety of your goals. At least some of it is almost certainly that
you find it fun and entertaining.

[...] I have skills in these areas and it is
because they were given to me, not by professors or other developers teaching
me things,

Did you not acquire some new C skills in the last few days? It's not
much I know, but it seems rude to say that get so little from other
developers after coming here to fix a skill gap. There is a huge wealth
of knowledge about the things you are doing -- programming language and
OS design -- that you seem determined to cut yourself off from.

<snip>

 

[glen herrmannsfeldt]

On Saturday, January 25, 2014 3:44:28 AM UTC-5, Seebs wrote:
(snip)

I have notice that, too.

You convey something that's an obvious thing, Seebs. You say
that the inner workings of a CPU are different than its
exposed ISA. That's what's called "a given" or "a truism".
There's nothing we can do about that part of it. All we can
do is write for what has been exposed outwardly to us through
the ISA. That's what I'm doing. But even there, at that ISA
level (which is not the true and pure form of literal mechanical
interpretation of what occurs within the CPU itself) there is
great benefit and capability in processing data, far more so
than exists at higher level languages.

Often more important than what you know is what you know you
don't know. Many people have made suggestions based on experience,
which you often ignore or denigrate for no good reason.

I am sure that you know a lot about computers, but so do most
others who post here. You should try to understand the reasons
behind what others post before putting them down.

And the goal of any compiler author is to merge those two
together. You take the needs of the high level and translate
it into the needs of the low level, allowing the protocols of
the high level to be enforced by the mechanical representation
of the low level.

When I was an undergrad, I took the compiler course, as I had
always wanted to know more about compilers. I haven't actually
written any whole compiler since, but I know enough to read
compiler books and post to newsgroups.

This immediate response above is one that I considered posting
to you, FWIW. I came here with knowledge and expertise in
various areas to be subjected nonstop to an onslaught of
questioning and pointing out things that are nothing less
than truisms, as though you're pointing something out to
me that I either had not thought of, or you presume I don't
already know because I have not previously conveyed that
thought.

Well, pretty often you give negative replies, indicating you
either don't care or aren't interested in learning more.

You discount my years of study and devotion to this platform,
to computer programming in general, because I have not done so
in a formal manner, as by studying C technical specs, or using
the correct terminology.

Actually, people here are much nicer to you now than they would
have been 10 or so years ago.

I appreciate corroboration in areas, but the tone of many of
these posts (toward my compiler design) have not been
constructive or helpful, but rather come across to me as an
attempt to tear down my goals and plans as though I have not
thought the matter through, or am proceeding from so many
false premises that any further effort toward completing my
project, a project which will likely not ever affect any
of you one way or the other, are for naught.

Many of us have had projects over the years that we had thought
about, but not ever completed. When I was an undergrad, I thought
about writing my own PL/I compiler. I still haven't done it.
With what I know, and with the books I have, I could do it, but
it would take longer than the time I have available.

I thank you for your concern over me, Seebs. If you'd like to
carry on a dialogue whereby we can discuss the fullness
of my task, then that is fine. You can come on board and
help me complete my project. If not, then I am content
to part and say thank you for your assistance.

Well, it does affect us, as we read, think about, and post
replies. Yet you aren't intersted in the constructive ideas
that people post, such that they feel it is a waste of time to
even post them.

-- glen

 

[Seebs]

You convey something that's an obvious thing, Seebs. You say that the inner
workings of a CPU are different than its exposed ISA. That's what's called "a
given" or "a truism".

No, it's not.

If you look at a 486, the inner workings are fundamentally aligned with the
ISA. It really does have that set of registers. The instructions you send
to it are the instructions which actually execute and determine whether or
not data gets read from, or written to, memory.

If you look at a Pentium Pro, that is no longer true.

If you think it is a "truism", that means you don't understand what I was
telling you about modern CPUs.

-s

 

[Rick C. Hodgin]

No, it's not.

If you look at a 486, the inner workings are fundamentally aligned with the
ISA. It really does have that set of registers. The instructions you send
to it are the instructions which actually execute and determine whether or
not data gets read from, or written to, memory.

If you look at a Pentium Pro, that is no longer true.

Super-scalar, super-pipelined, out-of-order execution, the engine introduced
first with the Pentium Pro. Register renaming, colorization, why certain
optimizations work better on AMD or Intel chips than others, etc. Yes, I do
understand.

If you think it is a "truism", that means you don't understand what I was
telling you about modern CPUs.

I do know what I'm talking about, Seebs. And what you've said is a truism.
It's been known for nearly 20 years. And as I've said ... it's internal
stuff that, for all practical purposes, is of little concern outside of
highly optimized code generation. And if my product ever gets to the point
where it's performing so well that I'm worrying about code optimization,
then it will be very easy to add on at that point. Until then, I'd just
like to get it working.

Best regards,
Rick C. Hodgin

 

[Kaz Kylheku]

You convey something that's an obvious thing, Seebs. You say that the inner
workings of a CPU are different than its exposed ISA. That's what's called "a
given" or "a truism".

It isn't a given. On some architectures, usually early versions of
architectures, the ISA is a very close mirror to the structure of the actual
processor. This tends to happen early in the family history. Then the ISA is
maintained while the processor implementation diverges.

(What for? Because people wrote their programs in a low-level language and lost
the source code, or are using binary-only proprietary software, etc: reasons
having to do with the drawbacks of having programs in machine language form
without source code.)

Eventually things may diverge to the point that the ISA is purely emulated
in software.

(Also note that there is also the possiblity of source compatibility. E.g. you
can program an 8086 chip sub-optimally using 8080 assembly language.)

There's nothing we can do about that part of it.

Yes there is; we can change our attitude. We can check in to Assemblers
Anonymous and stop thinking about machine language.

we can do is write for what has been exposed outwardly to us through the ISA.
That's what I'm doing.

Would you keep doing that when the ISA level is run by Javascript?

But even there, at that ISA level (which is not the
true and pure form of literal mechanical interpretation of what occurs
within the CPU itself) there is great benefit and capability in processing
data, far more so than exists at higher level languages.

There is certainly a potential to do things that are impossible in some
higher level languages, or impossible without leaving well-defined
behavior.

If we want to, say, implement Lisp, we can do a much more accurate job if we
work in assembly language than C. For example, we can implement a
precisely-tracing garbage collector that works correctly with multiple threads,
and without ever leaving the boundaries of well-defined behavior, according to
the instruction set manual.

If you've written a few kilobytes of assembly code and do not yet have the
beginnings of some kind of a high level language poking out, you're doing it
wrong.

Suppose we have a working garbage collector and a library of some
assembly-language functions like "cons", "car" and "cdr". Why would we want to
keep calling these by loading registers and doing a subroutine jump, when we
can make the machine do that for us with an abstract, nested notation like
"(cons (cons (car z) nil) x)". Perhaps this can be interpreted at first, then
compiled later. We can write the compiler in that notation, and run that
compiler interpreted. Once it is running, it can compile itself ...

 

[Seebs]

Super-scalar, super-pipelined, out-of-order execution, the engine introduced
first with the Pentium Pro. Register renaming, colorization, why certain
optimizations work better on AMD or Intel chips than others, etc. Yes, I do
understand.
Okay...

I do know what I'm talking about, Seebs. And what you've said is a truism.
It's been known for nearly 20 years.

But it's not a truism. A truism would be a thing which was always true, and
there's a new chip introduced by Intel in the last year or so, x86
architecture, for which it is false. So it can't possibly be a truism. A
statement which is not always true cannot be reasonably considered
"obviously" true.

And as I've said ... it's internal
stuff that, for all practical purposes, is of little concern outside of
highly optimized code generation.

So what?

The point is that no amount of understanding of assembly is an understanding
of what is actually happening on the machine on a lot of modern CPUs. Your
claim that working at the assembly level results in knowing what's really
happening is patently false.

-s

 

[Rick C. Hodgin]

You made it perfectly clear in an earlier post that you have virtually
now experience in embedded systems. That's fair enough - no one has
experience of everything. But since you have almost no idea about
embedded development, you sound foolish with statements like your claims
of 50x greater productivity.

It wasn't an exact number. I was using "50x" as "an exceedingly greater
degree of productivity" because I know how I code and I have languages that
don't have edit-and-continue, and having to stop and fix things and restart,
it's a constant drain on productivity, and a simultaneous source of
frustration because I know that were edit-and-continue available it wouldn't
be like this.

I have done development at the opposite end of your scales - where
programs were burned into EPROM chips and mounted on a board for
testing. Being able to re-flash the program in system is certainly a
big step up for debugging productivity, but even there the factor is
closer to 2 or 3 than 50. And that is just for the debugging part of
the development, which is a small part of the process.

If you use an emulator, and are able to immediately update the code without
the physical hardware mechanics of flashing, you'll find your productivity
goes up even more. This is akin to edit-and-continue.

I am well aware of the benefits of modifying code while running, as I do
it with Python code on PC's. Like Lisp, as mentioned by another poster,
it is possible to do this in a consistent and safe manner, with
real-world code - unlike with C. It can be convenient, but it is not
"shocking", nor does it make a huge difference to development or debug
time.

It is in my development. And there are certain aspects I'm able to
completely develop within the debugger. In fact, I've made the claim on
my toolset's edit-and-continue abilities that my goals are a person
could launch my IDE, create a new project, and open the document with
nothing in it except the equivalent of void main(void) { }, and launch
the debugger with a breakpoint set on the empty main function, and then
code the entire project from there without ever leaving the debugger.

That's how edit-and-continue should operate. Total knowledge of the
system it's writing for. Total knowledge of the code. Total knowledge
of how to execute the diffs between compile changes ... in fact, instead
of mass compiles as is done today, a continuous line-by-line compiler
which even conveys errant code into the executable so that when it hits
those lines it triggers a debugger exception which will stop the code
so it can be corrected at runtime. And so on.

Getting the wrong words on occasion is not dyslexia, nor is it a related
condition

Read more: http://www.dyslexia.com/library/symptoms.htm

"Difficulty putting thoughts into words; speaks in halting
phrases; leaves sentences incomplete; stutters under stress;
mispronounces long words, or transposes phrases, words, and
syllables when speaking."

http://www.dyslexiamylife.org/signs_dsy.html

"Hesitant speech; difficulty finding appropriate words."

http://www.beatingdyslexia.com/dyslexia-symptoms.html

"Forgetting names of people or objects."

(though continuously failing to learn or remember correct
terms /can/ be related to dyslexia). But such conditions affect many
people to a greater or lesser degree - I don't find my mild dyslexia
affects my programming. My documentation would be "entertaining" if it
weren't for spell checkers, but I don't think it excuses bugs in my code.

Dyslexia research is continuing. In Indianapolis, Indiana there is the
Dyslexic Institute of Indianapolis that my wife is working closely with
because our son has dyslexia. It was because of her work with this
organization that I discovered I also have dyslexia.

A video my wife made for the organization:

My son, Alex, is there on the first slide, front row, all the way to
the left. My wife is up against the wooden fence at around 1:00.

Let me further qualify and say that the processes I listed are typical
for a professional /embedded/ developer - there are many types of
software development, and the processes and balances are not the same.

Agreed. All of them would be better served with immediate edit-and-continue
abilities. It is toward that future I am striving. I am not looking at
what is here today, but what is and must come. I actually have long term
goals of getting these toolsets working, and then moving to create my own
microprocessor, called Craetis, based on a design I began on Thanksgiving
Day in 1993, revised over the years to be closer to that which my OBED
virtual machine design is like, yet with several non-software components
removed, and several hardware components added. This design will include
the ideas I have for the multiple threads available for increasing the
throughput of serial code using parallelization.

However, I cannot imagine any serious development process which involves
/major/ amounts of fiddling around with changing live code, at least
with a language and system that is not designed for it. I can well see
that it can be useful on occasion - but nothing remotely like the
benefits you are claiming.

Because it doesn't often exist or happen today.

There was a time when the idea of having a pickup truck was insane. Hundreds
of pounds of refined steel. Expensive glass. Electricity. Specialized
components that couldn't be easily found. Gallons and gallons of refined
fuel. It would cost a fortune! And be so difficult to maintain! Compare
that to a horse you can feed grass and water ... it's a no brainer! Yet
how many people today consider horses to be superior to pickup trucks? Not
many. And that's because the infrastructure is now here, and it makes
sense to do things a certain way.

The same will be true when the ability to do live updates is readily
available. My plan is to introduce this ability through my compiler and
IDE for all applications written therein, and then later in my operating
systems. If you take the time to study how I designed the device driver
code for Exodus, then you'll see that such a design was already there in
that version. My plan was even to allow, at the system level, dozens of
simultaneously installed versions, even able to share algorithms between
versions if needed.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

But it's not a truism. A truism would be a thing which was always true, and
there's a new chip introduced by Intel in the last year or so, x86
architecture, for which it is false. So it can't possibly be a truism. A
statement which is not always true cannot be reasonably considered
"obviously" true.

When I interviewed Jerry Bautista and his team at Intel on the Terascale
project they revealed to me under NDA the nature of the next-gen cores they
were working with for Terascale 2. I have information on that design which
is why I am believing the future will be 64+ cores (and actually 128+ cores)
which are closer to literal hardware architecture, because there is massive
performance gains in parallelism over serial code, even if it's running at
super fast speeds. What's needed is a different way to handle serial code
in a parallel manner, and that's what my design does. It allows branches
of code to be taken and converted into formulas which then fill in the
missing pieces that are unknown in advance. It comes at the expense of
additional heat and power consumption, but it will produce faster executed
code because when the input variables are finally known as the result of
subsequent calculations, the values are plugged in and the correct equation's
needs are satisfied and computed, yet the bulk of the work was done in
advance.

Today, the x86 ISA branches on average every six instructions. With the
addition of predicates that could be reduced as well, and therein lies the
ability to execute both paths of predicates simultaneously through the
multi-thread serial execution engine so that when the predicate is known
it is simply used, and the other one discarded.

Intel already did a lot of this with Itanium. It served as input into the
idea.

So what?

So you're making a big deal about the levels of abstraction between the
outward-facing ISA, and the device's inner workings. We can't control any
of the inward stuff, and the only thing we've been given to direct the
inward stuff is the outward-facing ISA. It is at that place, the ISA and
all of its features, that we, the compiler authors, must live.

The point is that no amount of understanding of assembly is an understanding
of what is actually happening on the machine on a lot of modern CPUs. Your
claim that working at the assembly level results in knowing what's really
happening is patently false.

Still a flatly ridiculous statement. The physical mechanics may be different
than the ISA indicates, but the operations taking place are known through the
ISA's instruction's intent ... and that really is enough, Seebs. In addition,
it's all we have.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

[...] In short, the
entirety of my goals are to give you something for free, expecting nothing
in return, that you may improve your life, and the lives of those around
you through my offering.

This seems implausible. How do you know what I (or others) want? If
you give me something I don't want it hardly improves my life. It may
even make it worse. At the very least you are squandering your time and
expertise if hardly anyone wants what you are building.

I predict it will make almost no difference to the vast overwhelming majority
of software developers today. I am writing this as an offering for Jesus
Christ, and those people who come forward to use these tools will be those
who place greater value upon serving God in their lives than in erecting
invisible monopolistic fortresses around their work as by protecting the
source code behind closed source walls, or using the legal system to ensure
that people pay up before they use software lest they go to jail.

Everything the Liberty Software Foundation does will be completely free
forever (in money, and in source code). I have a Public Benefit License
which is almost a literal copy of the GPLv3, along with the philosophy of
the Repeat License which guarantees certain rights to anyone receiving and
using Liberty Software. You can read about these on my wiki:

http://www.visual-freepro.org/wiki/index.php/Main_Page#License

I don't want yet another low-level language based on C. I don't want
yet another non-portable OS written in assembler. How have you
determined that enough people want these things that it is even worth
your time doing it? I couldn't even find a description of why these
thing might be of any benefit at all -- but that could be just I missed
the documents describing the overall designs and their benefits.

I'm writing RDC to be a flexible engine to allow ANY software language to
be coded using its base facilities, which are those wrapped around the
specific and foundational concept of edit-and-continue, along with shared
source code. I am also writing Visual FreePro, a language which will
provide nearly 100% backward compatibility with Visual FoxPro, and is
similar in form to Visual Basic and .NET.

I don't think you are being entirely honest with yourself about the
entirety of your goals. At least some of it is almost certainly that
you find it fun and entertaining.

I've spent the last 18 months moving forward with this pursuit. I've put
it into my prayers every day asking the Lord to guide me. I maintain that
He gave me my skills, that He gave me this desire, that He gave me these
opportunities to learn and so on. And I truly desire from within my heart
to give back unto Him everything that He gave me. I would like to have for
myself and my family a place to live do my work, to have my child educated,
and to have food on the table. I have no grand aspirations beyond that.

In short: I desire to be a servant of Jesus Christ here upon this Earth,
trusting that He will provide for me for those things I need, and that I
will proceed along these lines of constructing this product and project
to the best of my abilities until He Himself closes the door on me. Until
that day comes, I will push on ... even if I'm the only one walking this
way, and even if everyone else is telling me the grandest mistakes I am
making in pursuing an offering along these lines, or that my skills are
insufficient, because regardless of what else I do that is actually right,
wrong, or indifferent, I am truly offering up the absolute best of that
which I possess. And if I need more than I have, I trust that God will
send it. And if not, then I trust that God will also take care of
whatever's required. And if it's not for me to do, then I will also be
content to be a welder, or whatever, for the rest of my days, so long as
I continue to have Him in my life.

[...] I have skills in these areas and it is
because they were given to me, not by professors or other
developers teaching me things,

Did you not acquire some new C skills in the last few days?

I learned the C spec words for some things that I already understood in
concept. And I will admit I did learn what puts() does, and strdup().
I've never used them before this thread. I also learned from Ian Collins
of the existence of the dbxtool and Solaris Studio 12.x suite, which is an
integrated NetBeans and C/C++/Java development environment that supports fix
and continue. However, I have not figured out how to get it installed on
Linux Mint 14 as it seems to only be available in an RPM Red Hat format
for Linux.

It's not much I know, but it seems rude to say that get so little
from other developers after coming here to fix a skill gap. There
is a huge wealth of knowledge about the things you are doing --
programming language and OS design -- that you seem determined to
cut yourself off from.

I was educated by Joe as to the concept of the compound literal, which I
already understood in concept (it was the very thing I was after), yet
did not know how to do it in C. So ... I learned the C construct to do
the thing I already understood in software design. And, in the process,
I was told by half a dozen or more people that what I was in pursuit of
was a bad solution to my problem.

I would say on the whole, I took a bit of a pounding in this thread, while
receiving some new information. Joe was very helpful and I am most
appreciative to him. And I believe I said that in a thread where I replied
to his solution after it was posted.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

Well, it does affect us, as we read, think about, and post
replies. Yet you aren't intersted in the constructive ideas
that people post, such that they feel it is a waste of time to
even post them.

I have spent a lot of years pursuing these ends I'm on about now. It began
back in the early 1990s when I began to learn more and more about assembly.
I began to realize that I had the skills necessary to create an operating
system. I began tinkering with different aspects of that design, but didn't
fully commit myself until 1996 when I began work on the q/Operating System,
later renamed Exodus because I wanted it to be a "mass departure from evil,"
which was Microsoft.

For several years using only a regular 133 MHz Pentium computer with 64 MB
of RAM, DOS 6.22, a set of tools including Microsoft's C Compiler 6.0,
Microsoft's Macro Assembler 6.11d, and CodeView 3 and CodeView 4, a
floppy disk, and a reset button, I worked to complete this project. I
designed my OS to use a VGA card and a Hercules Graphics Adapter monochrome
card, which I used in graphics mode to display my debugger in real-time.
And over the time I had several things happen: (1) I got it working. (2)
I encountered an increasing degree of resistance the closer I got to the
end, to the point where I could not go on any longer. And (3) the desire
to continue developing it never waned.

In 2002 I got married and my wife basically told me (paraphrased): "Choose,
Rick. The OS or me," because I was spending all of my time working on it.
I chose her, and the OS and everything related to it (my compiler, my
integrated device driver design, and so on) was shelved. Our son was born
and it's only been in the last few years (since 2009) that I've seriously
returned to personal software endeavors, and since July 2012 when I began
working on what is now the Village Freedom Project, encompassing the RDC
compiler, Visual FreePro (VFrP), and the Visual FreePro Virtual Machine
(VVM). And I've observed again, as I am getting closer and closer to having
the foundational design laid down to begin doing real work on my debugger,
the VVM, an the compiler, that more and more people are rising up to again
give me the same kind of resistance I had back in the early 2000s.

There is a difference this time, however. Now I am a believer in Jesus
Christ. Now I have the power of faith and of prayer. Now I know who the
enemy is and who I am in the Lord. These forces which rise against me are
not able to defeat me this time because my offering is no loner being made
for myself, but for God. And if God wants this to proceed, it cannot be
stopped. It will only be God Himself who puts an end to this project, by
placing a door before me that He closes, that no man can open.

I stand now with the strength of faith moving forward. I have the abilities
I possess, and I learn more from experience, intuition, and other sources
like Googling for something, to proceed. I have written to Christian
universities asking for help, I have posted on Christian Developer forums,
and I have gone to the Visual FoxPro websites asking people to come forward
and help me. There are several who look to help me debug the xbase portion
once it's up and running like Visual FoxPro is ... but not one person has
come forward so far to help me with the C/C++ code development portion. In
fact, the universities I wrote responded saying that they have no interest
in pursuing a clone of Visual FoxPro, or that they don't have any classes
which would be commensurate with the concepts of writing a new compiler, or
designing a new virtual machine, and so on.

I am alone on this project in terms of people helping me, but I have God's
army of angels, and my faith in Him on my side as well. The victory is
absolutely assured ... unless God has something else in mind for me.

Best regards,
Rick C. Hodgin

 

[Ian Collins]

If you use an emulator, and are able to immediately update the code without
the physical hardware mechanics of flashing, you'll find your productivity
goes up even more.

This is a common model for embedded development. The only time you need
to debug on the target is when target specific things go wrong.

This is akin to edit-and-continue.

Not really.

It is in my development. And there are certain aspects I'm able to
completely develop within the debugger.

It sounds like you style is better suited to interpreted languages than
to a compiled language such as C. I'm sure I'm not alone in considering
having to use a debugger as a failure of the development process...
Sure you can find bugs, but how can you automate testing?

That's how edit-and-continue should operate. Total knowledge of the
system it's writing for. Total knowledge of the code. Total knowledge
of how to execute the diffs between compile changes ... in fact, instead
of mass compiles as is done today, a continuous line-by-line compiler
which even conveys errant code into the executable so that when it hits
those lines it triggers a debugger exception which will stop the code
so it can be corrected at runtime. And so on.

IDEs can provide background compilation (Solaris Studio does),
highlighting errors as you edit. No need for a debugger.

 

[Rick C. Hodgin]

It sounds like you style is better suited to interpreted languages than
to a compiled language such as C. I'm sure I'm not alone in considering
having to use a debugger as a failure of the development process...

Yes. Many people write code like that. Ever since Visual Studio 98 and
edit-and-continue, I've never looked back. I do about 80% development in
the IDE outside of a running environment, and about 20% inside. It works
well.

Sure you can find bugs, but how can you automate testing?
<snip>

How do you automate testing today? You do it the same way.

IDEs can provide background compilation (Solaris Studio does),
highlighting errors as you edit. No need for a debugger.

The IDE will be fully integrated with the debugger in Visual FreePro, and
with the compiled language. The three will be one.

Best regards,
Rick C. Hodgin

 

[Ben Bacarisse]

The IDE will be fully integrated with the debugger in Visual FreePro, and
with the compiled language. The three will be one.

That sounds ominous. It usually means that the user can't choose which
editor to use, not which debugger, nor which build system. But this is
a new project so maybe you will avoid this pitfall.

 

[Rick C. Hodgin]

That sounds ominous. It usually means that the user can't choose which
editor to use, not which debugger, nor which build system. But this is
a new project so maybe you will avoid this pitfall.

I am creating an interface for an editor I have in mind called WideEdit,
which conveys several new concepts in editing. I am focusing my design
around a GUI because I can see the world moving forward into OpenGL
everywhere, and the GUI is only going to become more prevalent. The WideEdit
API will be published, and the source code of my version will be available.
People will be able to port their favorite editors to a compatible plugin,
but some features may not be supported.

I will have my own debugger, called Debi, which works with my ABI, the
compiler architecture and design, and is able to handle edit-and-continue
as I have designed it. The debugger will also be able to target the three
platforms I intend to support: x86, ARM, and my VVM's assembly language,
codenamed OBED.

It's a departure from many traditional models, but it is one that is
very flexible, and will allow a lot of 3rd party plugins should people
desire to contribute other languages and editors into the mix. Even
WideEdit itself allows for plugins so that its capabilities can be
expanded. In fact, the multiple edit abilities it possesses are exposed
through plugins.

Best regards,
Rick C. Hodgin

 

[Ian Collins]

What nonsense. A debugger is an integral part of any development
process.

A broken one... Try working without a debugger for a while and I'm sure
your design and code will improve. I do quite a bit of PHP and I've
never bothered to configure a debugger. There wasn't one when I
started, so I had to rethink how I developed my code.

 

[Rick C. Hodgin]

A broken one... Try working without a debugger for a while and I'm sure
your design and code will improve. I do quite a bit of PHP and I've
never bothered to configure a debugger. There wasn't one when I
started, so I had to rethink how I developed my code.

Linus Torvalds does all of his development without a debugger. Some
people do this. I cannot. I can get all of my logic working perfectly
pretty much all of the time when just writing code top-down, but only
about 98% of my code is perfect in syntax. I make little mistakes.
Sometimes odd mistakes. I usually understand what should be coded,
but I simply type things wrong sometimes, and don't catch them when
reading the code -- and sometimes I don't catch it at all until the
faulty results are there and I have to go back through. I usually find
something I had no intention of typing, and wasn't part of my thought
processes, but was something that simply came out wrong when I was
typing. That doesn't happen as often, but probably once every two
weeks.

Best regards,
Rick C. Hodgin

 

[Kenny McCormack]

It sounds like you style is better suited to interpreted languages than
to a compiled language such as C. I'm sure I'm not alone in considering
having to use a debugger as a failure of the development process...

[/QUOTE]

What nonsense. A debugger is an integral part of any development
process.

You certainly know by now (having been around this newsgroup for a few
years or so) that it is an integral part of the CLC religion that real men
don't use debuggers. Debuggers are for sissies.

 

[Ian Collins]

Linus Torvalds does all of his development without a debugger. Some
people do this. I cannot. I can get all of my logic working perfectly
pretty much all of the time when just writing code top-down, but only
about 98% of my code is perfect in syntax. I make little mistakes.
Sometimes odd mistakes. I usually understand what should be coded,
but I simply type things wrong sometimes, and don't catch them when
reading the code -- and sometimes I don't catch it at all until the
faulty results are there and I have to go back through. I usually find
something I had no intention of typing, and wasn't part of my thought
processes, but was something that simply came out wrong when I was
typing. That doesn't happen as often, but probably once every two
weeks.

If you were to write your code with the help of unit tests, most of
these problems would be solved way before debugging is required.

I also tend to make silly mistakes which I don't pick up when reading my
code (or other writers code, which makes me a poor code reviewer!) but
seldom make two complimentary errors in a test and the code written to
pass it. If a code change breaks a test, I'll usually undo it and try
again rather than spending time with a debugger working out what I did
wrong. Sometimes curiosity will get the better of me and I will have a
look, but I try not to. This inevitable temptation is why I've never
tried a PHP debugger.

 

[Rick C. Hodgin]

Rick C. Hodgin wrote:
If you were to write your code with the help of unit tests, most of
these problems would be solved way before debugging is required.
https://github.com/RickCHodgin/libsf/tree/master/vvm/core/vvmtests

I also tend to make silly mistakes which I don't pick up when reading my
code (or other writers code, which makes me a poor code reviewer!) but
seldom make two complimentary errors in a test and the code written to
pass it. If a code change breaks a test, I'll usually undo it and try
again rather than spending time with a debugger working out what I did
wrong. Sometimes curiosity will get the better of me and I will have a
look, but I try not to. This inevitable temptation is why I've never
tried a PHP debugger.

I am trying Solaris Studio 12.3 right now. It uses Netbeans 7.0. Is there
a way to upgrade it to 7.3 or later? 7.0 has weird errors. One is if you
launch less than full maximized, and then later maximize, the mouse does
not track appropriately.

Best regards,
Rick C. Hodgin