subject:"How far can stack \[LIFO\] solve do automatic garbage collection and prevent memory leak \?"

On Aug 21, 12:18 pm, ehr...@dk3uz.ampr.org (Edmund H. Ramm) wrote:
 In 2d59bfaa-2aa5-4396-bd03-22200df8c...@x21g2000yqa.googlegroups.com Hugh 
 Aguilar hughaguila...@yahoo.com writes:

  [...]
  I really recommend that people spend a lot more time writing code,
  and a lot less time with all of this pseudo-intellectual nonsense.
  [...]

    I energetically second that!
 --
       e-mail: dk3uz AT arrl DOT net  |  AMPRNET: dk...@db0hht.ampr.org
       If replying to a Usenet article, please use above e-mail address.
                Linux/m68k, the best U**x ever to hit an Atari!

What open-source code have you posted publicly?

BTW, why did you request that your post not be archived, and be
removed in a few days? That doesn't seem very energetic. Also, now
that I've responded to it, it will be archived forever. It is so rare
that anybody agrees with me, I wanted to make a permanent record. :-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

David Kastrup d...@gnu.org writes:

 John Bokma j...@castleamber.com writes:

 On the other hand: some people I knew during my studies had no problem
 at all with introducing countless memory leaks in small programs (and
 turning off compiler warnings, because it gave so much noise...)

 [...]

 As for electrical engineering: done that (BSc) and one of my class
 mates managed to connect a transformer the wrong way
 around twice. Yet he had the highest mark in our class.

 Anybody worth his salt in his profession has a trail of broken things in
 his history.

Sure. The long version is: he blew up his work when he connected the
transformer wrong. He borrowed someone else's board and blew that one up
as well.

 The faster it thinned out, the better he learned.

He he he, his internships went along similar lines. Maybe he loved to
blow up things.

 The only reliable way never to break a thing is not to touch it in the
 first place.  But that will not help you if it decides to break on its
 own.

I don't think transfomers connect themselfs in the wrong way ;-). I
agree with that accidents do happen, but some people just manage to make
accidents happen way above average. And in that case they might start to
think if it's a good idea them touching things.

-- 
John Bokma   j3b

Blog: http://johnbokma.com/Facebook: http://www.facebook.com/j.j.j.bokma
Freelance Perl  Python Development: http://castleamber.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

On Aug 22, 11:12 am, John Bokma j...@castleamber.com wrote:

 And my
 experience is that a formal study in CS can't compare to home study
 unless you're really good and have the time and drive to read formal
 books written on CS. And my experience is that most self-educaters don't
 have that time.

I've read a lot of graduate-level CS books. I think most self-educated
programmers have read more of these books than have 4-year degree
students who were not required to in order to get their Bachelors
degree and who were too busy during college to read anything that
wasn't required.

 On the other hand: some people I knew during my studies had no problem
 at all with introducing countless memory leaks in small programs (and
 turning off compiler warnings, because it gave so much noise...)

I do this all the time. My slide-rule program, for example, has beau-
coup memory leaks. When I have time to mess with the program I clean
up these memory leaks, but it is not a big deal. The program just
runs, generates the gcode and PostScript, and then it is done. I don't
really worry about memory leaks except with programs that are run
continuously and have a user-interface, because they can eventually
run out of memory.

The real problem here is that C, Forth and C++ lack automatic garbage
collection. If I have a program in which I have to worry about memory
leaks (as described above), I would be better off to ignore C, Forth
and C++ and just use a language that supports garbage collection. Why
should I waste my time carefully freeing up heap space? I will very
likely not find everything but yet have a few memory leaks anyway.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-24 Thread Richard Owlett


Hugh Aguilar wrote:

[SNIP ;]

The real problem here is that C, Forth and C++ lack automatic garbage
collection. If I have a program in which I have to worry about memory
leaks (as described above), I would be better off to ignore C, Forth
and C++ and just use a language that supports garbage collection. Why
should I waste my time carefully freeing up heap space? I will very
likely not find everything but yet have a few memory leaks anyway.


IOW Hugh has surpassed GIGO to achieve AGG - 
*A*utomatic*G*arbage*G*eneration ;)



--
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

On Aug 24, 9:24 am, David Kastrup d...@gnu.org wrote:
 Anybody worth his salt in his profession has a trail of broken things in
 his history.

When I was employed as a Forth programmer, I worked for two brothers.
The younger one told me a funny story about when he was 13 or 14 years
old. He bought a radio at a garage sale. The radio worked perfectly,
except that it had no case. He was mighty proud of his radio and was
admiring it, but he noticed that the tubes were dusty. That wouldn't
do! Such a wonderful radio ought to look as good as it sounds! So he
removed the tubes and cleaned them all off with a soft cloth. At this
time it occurred to him that maybe he should have kept track of which
sockets the tubes had come out of. He put the tubes back in so that
they looked correct, but he couldn't be sure.

Fortunately, his older brother who was in high school knew
*everything* about electronics, or at least, that is what he claimed.
So the boy gets his big brother and asks him. The brother says: There
is one way to know for sure if the tubes are in correctly or not ---
plug the radio in. He plugs in the radio; it makes a crackling noise
and begins to smoke. The boy desperately yanks the cord, but it is too
late; his wonderful radio is toast. The older brother says: Now you
know!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

Hugh Aguilar hughaguila...@yahoo.com writes:

 On Aug 22, 11:12 am, John Bokma j...@castleamber.com wrote:

 And my
 experience is that a formal study in CS can't compare to home study
 unless you're really good and have the time and drive to read formal
 books written on CS. And my experience is that most self-educaters don't
 have that time.

 I've read a lot of graduate-level CS books. I think most self-educated
 programmers have read more of these books than have 4-year degree
 students who were not required to in order to get their Bachelors
 degree and who were too busy during college to read anything that
 wasn't required.

I doubt it. But this all comes back to what I earlier wrote: those with
a CS degree think they are better than people without, and people
without think they can achieve the same or better by just buying a few
books and reading them. On top of that, most of the people I knew in my
final year were very fanatic regarding CS: it was a hobby to
them. During coffeebreaks we talked about approximation algorithms for
TSPs for example. Not always, but it happened. I read plenty of books
during my studies that were not on the list, as did other students I
knew.

If I recall correctly, you don't have a CS degree. I do, and I can tell
you that your /guess/ (since that is all it is) is wrong. For most exams
I've done one had not only to have read the entire book (often in a very
short time), but also the hand-outs. And for quite some courses
additional material was given during the course itself, so not attending
all classes could result in a lower score. Reading additional books and
papers helped. Sometimes reading a book by a different author could be a
real eye opener (and the students I had contact with did exactly this).

On top of that, often in class excercises were done, and with some
courses I had to hand in home work (yikes).

Also, most books are easy to read compared to CS papers. In my final two
years I did several courses which solely consisted of reading a CS paper
and giving a presentation on the subject in front of your classmates
(and sometimes other interested people). Reading and understanding such
a paper is one (and quite an effort). Teaching it in front of a (small)
class within a few days is not easy, to say the least. We also had to
attend several talks by guest speakers. I went to more than the required
number, including a guest talk by Linus. When there was a break-through
in proving Fermat's last theorem there was a talk, which I attended,
like several other class mates.

I am sure there are students who are there just to get a degree and to
make money. But my class mates didn't fall into that category, or I have
missed something.

So yes, I am convinced that there are plenty of self-educated people who
can code circles around me or plenty of other people with a CS
degree. But IMO those people are very hard to find. Most people
overestimate their skills, with or without a degree; I am sure I do. And
it wouldn't surprise me if self-educated people do this more so.

 On the other hand: some people I knew during my studies had no problem
 at all with introducing countless memory leaks in small programs (and
 turning off compiler warnings, because it gave so much noise...)

 I do this all the time. My slide-rule program, for example, has beau-
 coup memory leaks. When I have time to mess with the program I clean
 up these memory leaks, but it is not a big deal. The program just
 runs, generates the gcode and PostScript, and then it is done. I don't
 really worry about memory leaks except with programs that are run
 continuously and have a user-interface, because they can eventually
 run out of memory.

Oh boy, I think you just made my point for me...

 The real problem here is that C, Forth and C++ lack automatic garbage
 collection. If I have a program in which I have to worry about memory
 leaks (as described above), I would be better off to ignore C, Forth
 and C++ and just use a language that supports garbage collection.

Several languages that support garbage collection still are able to leak
memory when circular datastructures are used (for example). Also,
allocating memory and never giving it back (by keeping a reference to
it) can also be memory leaking. And the wrong form of optimization can
result in a program using more memory than necessary. On top of that,
you have to understand when the gc releases memory, and things like
memory fragmentation. In short: you still have to use your head (on some
occasions even more).

 Why should I waste my time carefully freeing up heap space? I will
 very likely not find everything but yet have a few memory leaks
 anyway.

Why should you waste time with carefully checking for other issues? In
my experience, once you become sloppy with one aspect it's very easy to
become sloppy with others as well.

-- 
John Bokma   j3b

Blog: http://johnbokma.com/Facebook:

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

On Aug 24, 4:17 pm, Richard Owlett rowl...@pcnetinc.com wrote:
 Hugh Aguilar wrote:
  [SNIP ;]

  The real problem here is that C, Forth and C++ lack automatic garbage
  collection. If I have a program in which I have to worry about memory
  leaks (as described above), I would be better off to ignore C, Forth
  and C++ and just use a language that supports garbage collection. Why
  should I waste my time carefully freeing up heap space? I will very
  likely not find everything but yet have a few memory leaks anyway.

 IOW Hugh has surpassed GIGO to achieve AGG -
 *A*utomatic*G*arbage*G*eneration ;)

The C programmers reading this are likely wondering why I'm being
attacked. The reason is that Elizabeth Rather has made it clear to
everybody that this is what she wants:
http://groups.google.com/group/comp.lang.forth/browse_thread/thread/c37b473ec4da66f1

Every Forth programmer who aspires to get a job at Forth Inc. is
obliged to attack me. Attacking my software that I posted on the FIG
site is preferred, but personal attacks work too. It is a loyalty
test.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-24 Thread Richard Owlett


Hugh Aguilar wrote:

On Aug 24, 4:17 pm, Richard Owlettrowl...@pcnetinc.com  wrote:

Hugh Aguilar wrote:

[SNIP ;]



The real problem here is that C, Forth and C++ lack automatic garbage
collection. If I have a program in which I have to worry about memory
leaks (as described above), I would be better off to ignore C, Forth
and C++ and just use a language that supports garbage collection. Why
should I waste my time carefully freeing up heap space? I will very
likely not find everything but yet have a few memory leaks anyway.


IOW Hugh has surpassed GIGO to achieve AGG -
*A*utomatic*G*arbage*G*eneration ;)


The C programmers reading this are likely wondering why I'm being
attacked. The reason is that Elizabeth Rather has made it clear to
everybody that this is what she wants:
http://groups.google.com/group/comp.lang.forth/browse_thread/thread/c37b473ec4da66f1

Every Forth programmer who aspires to get a job at Forth Inc. is
obliged to attack me. Attacking my software that I posted on the FIG
site is preferred, but personal attacks work too. It is a loyalty
test.


*SNICKER SNICKER LOL*
I am not now, nor have been a professional programmer.
I still recognize you.
P.S. - ever read The Emperor's New Clothes


--
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-24 Thread Paul Rubin

Hugh Aguilar hughaguila...@yahoo.com writes:
 I've read a lot of graduate-level CS books.

Reading CS books doesn't make you a computer scientist any more than
listening to violin records makes you a violinist.  Write out answers to
all the exercises in those books, and get your answers to the more
difficult ones checked by a professor, and you'll be getting somewhere.
That's the point someone else was making about self-study: without
someone checking your answers at first, it's easy to not learn to
recogize your own mistakes.

Anyway, as someone else once said, studying a subject like CS isn't done
by reading.  It's done by writing out answers to problem after problem.
Unless you've been doing that, you haven't been studying.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

Paul Rubin no.em...@nospam.invalid writes:

 Hugh Aguilar hughaguila...@yahoo.com writes:
 I've read a lot of graduate-level CS books.

 Reading CS books doesn't make you a computer scientist any more than
 listening to violin records makes you a violinist.  Write out answers to
 all the exercises in those books, and get your answers to the more
 difficult ones checked by a professor, and you'll be getting somewhere.
 That's the point someone else was making about self-study: without
 someone checking your answers at first, it's easy to not learn to
 recogize your own mistakes.

 Anyway, as someone else once said, studying a subject like CS isn't done
 by reading.  It's done by writing out answers to problem after problem.
 Unless you've been doing that, you haven't been studying.

Yup. I would like to add the following three:

1) being able to teach to peers what you've read.

   As explained in a post I made: during several courses I took you got
   a paper from your teacher and had to teach in front of the class the
   next week. Those papers are quite hard to grasp on the first reading
   even if you know quite a bit of the topic. Understanding it enough
   to teach in front of a class and being able to handle the question
   round, in which the teacher participates, is quite a killer.

2) being able to program on paper / understand programs on paper.

   On several exams I had to write small programs on paper. The
   solutions had to compile (i.e. missing a ; for languages that
   required so was counted against you, or using optional ;).  One exam
   was about OOP and several OO languages were taught, and hence on
   paper one had to provide solutions in C++, Objective-C, Object
   Pascal, Smalltalk, Eiffel, etc. No compiler(s) handy.

   And of course questions like: what's wrong with this piece of code
   and how should it be written.

3) being able to write papers and a thesis (or two)

   No explanation needed, quite some people have no problem reading the
   required books, passing the exams, but need quite some time to do
   this (and some give up on it).

-- 
John Bokma   j3b

Blog: http://johnbokma.com/Facebook: http://www.facebook.com/j.j.j.bokma
Freelance Perl  Python Development: http://castleamber.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

On Aug 24, 5:16 pm, Paul Rubin no.em...@nospam.invalid wrote:
 Anyway, as someone else once said, studying a subject like CS isn't done
 by reading.  It's done by writing out answers to problem after problem.
 Unless you've been doing that, you haven't been studying.

What about using what I learned to write programs that work? Does that
count for anything?

If I don't have a professor to pat me on the back, will my programs
stop working? That sounds more like magic than technology.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

On Aug 21, 10:57 pm, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
 Anyway, I'm looking forward to hear why overuse of the return stack is a
 big reason why people use GCC rather than Forth. (Why GCC? What about
 other C compilers?) Me, in my ignorance, I thought it was because C was
 invented and popularised by the same universities which went on to teach
 it to millions of programmers, and is firmly in the poplar and familiar
 Algol family of languages, while Forth barely made any impression on
 those universities, and looks like line-noise and reads like Yoda. (And
 I'm saying that as somebody who *likes* Forth and wishes he had more use
 for it.) In my experience, the average C programmer wouldn't recognise a
 return stack if it poked him in the eye.

The Empire Strikes Back was a popular movie. I read an article (The
puppet like, I do not) criticizing the movie though. At one point,
Luke asked why something was true that Yoda had told him, and Yoda
replied: There is no why! The general idea is that the sudent (Luke)
was supposed to blindly accept what the professor (Yoda) tells him. If
he asks why?, he gets yelled at.

This is also the attitude that I find among college graduates. They
just believe what their professors told them in college, and there is
no why. This is essentially the argument being made above --- that C
is taught in college and Forth is not, therefore C is good and Forth
is bad --- THERE IS NO WHY!

People who promote idiomatic programming are essentially trying to
be Yoda. They want to criticize people even when those people's
programs work. They are just faking up their own expertise --- many of
them have never actually written a program that works themselves.

The reason why I like programming is because there is an inherent anti-
bullshit mechanism in programming. Your program either works or it
doesn't. If your program doesn't work, then it doesn't matter if it is
idiomatic, if you have a college degree, etc., etc.. That is the way I
see it, anyway. This perspective doesn't hold for much on
comp.lang.forth where we have people endlessly spouting blather
*about* programming, without actually doing any programming
themselves. This is why I don't take c.l.f. very seriously; people
attack me all of the time and I don't really care --- I know that my
programs work, which is what matters in the real world.

(Pardon my use of the word bullshit above; there is no better term
available.)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

Hugh Aguilar hughaguila...@yahoo.com writes:

 On Aug 24, 5:16 pm, Paul Rubin no.em...@nospam.invalid wrote:
 Anyway, as someone else once said, studying a subject like CS isn't done
 by reading.  It's done by writing out answers to problem after problem.
 Unless you've been doing that, you haven't been studying.

 What about using what I learned to write programs that work? Does that
 count for anything?

Of course it does; but who's going to verify your program?

 If I don't have a professor to pat me on the back, will my programs
 stop working? That sounds more like magic than technology.

I am sure you know what Paul means. As for patting on the back: you must
make a hell of an effort to get that.

-- 
John Bokma   j3b

Blog: http://johnbokma.com/Facebook: http://www.facebook.com/j.j.j.bokma
Freelance Perl  Python Development: http://castleamber.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

Hugh Aguilar hughaguila...@yahoo.com writes:

 This is also the attitude that I find among college graduates. They
 just believe what their professors told them in college, and there is
 no why.

Which college is that? It doesn't agree with my experiences. In CS quite
a lot has to be proven with a formal proof, exactly the opposite from
what you claim. And after some time students want to see the proof and
certainly don't accept there is no why! unless it's a trivial thing.

Maybe it's because your anecdote is an interpretation from a distance,
not based on the actual experience?

 This is essentially the argument being made above --- that C
 is taught in college and Forth is not, therefore C is good and Forth
 is bad --- THERE IS NO WHY!

At an university which languages you see depend a lot on what your
teachers use themselves. A language is just a verhicle to get you from a
to b. What a good study should teach you is how to drive the verhicle
without accidents and not that a red one is the best. From top of my
head I've seen 20+ languages during my study at the University of
Utrecht. Forth wasn't one of them, but I already knew about Forth before
I went to the UU. On top of that I had written an extremely minimalistic
Forth in Z80 assembly years before I went to the UU (based on the work
of someone else).

 People who promote idiomatic programming are essentially trying to
 be Yoda. They want to criticize people even when those people's
 programs work.

Works doesn't mean that a program is good or what. There is a lot to
say about a program that works, even one that works flawless. I do it
all the time about my own programs. It's good to be critical about your
own work. And if you're a teacher, it's good to provide positive feedback.

 They are just faking up their own expertise ---

Like you, you mean? You consider yourself quite the expert on how people
educate and what they learn when educated in a formal
environment. Without (if I recall correctly) only second hand
information and guessing.

 many of them have never actually written a program that works
 themselves.

Quite some part of CS can be done without writing a single line of code.

 The reason why I like programming is because there is an inherent anti-
 bullshit mechanism in programming. Your program either works or it
 doesn't.

Now can you provide a formal proof that it works, or do you just
consider running the program a few times sufficient proof that it works?

 If your program doesn't work, then it doesn't matter if it is
 idiomatic, if you have a college degree, etc., etc.. That is the way I
 see it, anyway.

Well, you see it wrong. A program that doesn't work and is idiomatic is
easier to make work and to verify by others that it works. A program
that's the result of trial-and-error (that's what quite some people end
up doing who are self-taught) is a pain in the ass (pardon my French) to
maintain or to extend.

 This perspective doesn't hold for much on
 comp.lang.forth where we have people endlessly spouting blather
 *about* programming,

and you are different how? Also note that your post is crossposted to
several other groups.

 without actually doing any programming themselves. This is why I don't
 take c.l.f. very seriously; people attack me all of the time and I
 don't really care 

heh, hence all the replies you write, and mentioning it in this post.

-- 
John Bokma   j3b

Blog: http://johnbokma.com/Facebook: http://www.facebook.com/j.j.j.bokma
Freelance Perl  Python Development: http://castleamber.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

John Bokma j...@castleamber.com writes:

 At an university which languages you see depend a lot on what your
 teachers use themselves. A language is just a verhicle to get you from a
 to b.

Addendum: or to illustrate a concept (e.g. functional programming, oop)

[..]
 Like you, you mean? You consider yourself quite the expert on how people
 educate and what they learn when educated in a formal
 environment. Without (if I recall correctly) only second hand
   ^^^

   Should've written With, of course.

 information and guessing.

-- 
John Bokma   j3b

Blog: http://johnbokma.com/Facebook: http://www.facebook.com/j.j.j.bokma
Freelance Perl  Python Development: http://castleamber.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-23 Thread Hugh Aguilar

On Aug 21, 12:32 pm, Alex McDonald b...@rivadpm.com wrote:
 Scintilla gets about 2,080,000 results on google; blather gets
 about 876,000 results. O Hugh, you pseudo-intellectual you!

  with gutter language such as
  turd

 About 5,910,000 results. It has a long history, even getting a mention
 in the Wyclif's 13th century bible.

You looked up blather and turd on google *AND* you are not a
pseudo-intellectual??? That is funny!

I don't consider myself to be a pseudo-intellectual. I don't have any
education however, so a pseudo-intellectual is the only kind of
intellectual that I could be.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-23 Thread Hugh Aguilar

On Aug 22, 3:40 pm, 1001nuits 1001nu...@gmail.com wrote:
 Another thing you learn in studying in University is the fact that you can  
 be wrong, which is quite difficult to accept for self taught people.

Yet another thing you learn in studying in University, is the art of
apple polishing! LOL

If a person has graduated from college, it is not clear what if
anything he has learned of a technical nature --- but it can be
assumed that he has learned to be a head-bobber (someone who
habitually bobs his head up and down in agreement when the boss is
speaking) and has learned to readily admit to being wrong when
pressured (when the boss looks at him without smiling for more than
two seconds). These are the traits that bosses want in an employee ---
that prove the employee to be trainable.

BTW, has anybody actually looked at my software?
http://www.forth.org/novice.html

All this pseudo-intellectual nonsense (including this post) is getting
boring. Why don't we try discussing software for a while? I wrote that
slide-rule program as a showcase of Forth. I've been thinking of
porting it over to another language, possibly C. Maybe one of you C
experts could write the C program though, as a comparison --- to show
how much better C is than Forth. You can demonstrate that my code was
badly written and strangely designed --- with a concrete example,
rather than just a lot hand-waving and chest-thumping.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-22 Thread Steven D'Aprano

Oh, I am so going to regret getting sucked into this tarpit... oh 
well.


On Sat, 21 Aug 2010 09:58:18 -0700, Hugh Aguilar wrote:

 The
 following is a pretty good example, in which Alex mixes big pseudo-
 intellectual words such as scintilla with gutter language such as
 turd in an ungrammatical mish-mash

You say that like it's a bad thing.

Besides, scintilla isn't a big pseudo-intellectual word. It might seem 
so to those whose vocabulary (that's another big word, like patronizing 
and fatuousness) is lacking, but it's really quite a simple word. It 
means a spark, hence scintillating, as in he thinks he's quite the 
scintillating wit, and he's half right. It also means an iota, a 
smidgen, a scarcely detectable amount, and if anyone can't see the 
connection between a spark and a smidgen, there's probably no hope for 
them.

Nothing intellectual about it, let alone pseudo-intellectual, except that 
it comes from Latin. But then so do well more half the words in the 
English language.

Anyway, I'm looking forward to hear why overuse of the return stack is a 
big reason why people use GCC rather than Forth. (Why GCC? What about 
other C compilers?) Me, in my ignorance, I thought it was because C was 
invented and popularised by the same universities which went on to teach 
it to millions of programmers, and is firmly in the poplar and familiar 
Algol family of languages, while Forth barely made any impression on 
those universities, and looks like line-noise and reads like Yoda. (And 
I'm saying that as somebody who *likes* Forth and wishes he had more use 
for it.) In my experience, the average C programmer wouldn't recognise a 
return stack if it poked him in the eye.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-22 Thread David Kastrup

John Bokma j...@castleamber.com writes:

 David Kastrup d...@gnu.org writes:

 John Passaniti john.passan...@gmail.com writes:

 Amen!  All this academic talk is useless.  Who cares about things like
 the big-O notation for program complexity.  Can't people just *look*
 at code and see how complex it is?!  And take things like the years of
 wasted effort computer scientists have put into taking data structures
 (like hashes and various kinds of trees) and extending them along
 various problem domains and requirements.  Real programmers don't
 waste their time with learning that junk.  What good did any of that
 ever do anyone?!

 It is my experience that in particular graduated (and in particular Phd)
 computer scientists don't waste their time _applying_ that junk.

 Question: do you have a degree in computer science?

 Since in my experience: people who talk about their experience with
 graduated people often missed the boat themselves and think that reading
 a book or two equals years of study.

I have a degree in electrical engineering.  But that's similarly
irrelevant.  I have a rather thorough background with computers (started
with punched cards), get along with about a dozen assembly languages and
quite a few other higher level languages.  I've had to write the BIOS
for my first computer and a number of other stuff and did digital
picture enhancement on DOS computers with EMM (programming 80387
assembly language and using a variant of Hartley transforms).

I have rewritten digital map processing code from scratch that has been
designed and optimized by graduated computer scientists (including one
PhD) to a degree where it ran twice as fast as originally, at the cost
of occasional crashes and utter unmaintainability.  Twice as fast
meaning somewhat less than a day of calculation time for medium size
data sets (a few 10 of data points, on something like a 25MHz 68020
or something).  So I knew the problem was not likely to be easy.  Took
me more than a week.  After getting the thing to compile and fixing the
first few crashing conditions, I got stuck in debugging.  The thing just
terminated after about 2 minutes of runtime without an apparent reason.
I spent almost two more days trying to find the problem before bothering
to even check the output.  The program just finished regularly.

That has not particularly helped my respect towards CS majors and PhDs
in the function of programmers (and to be honest: their education is not
intended to make them good programmers, but to enable them to _lead_
good programmers).

That does not mean that I am incapable of analyzing, say quicksort and
mergesort, and come up with something reasonably close to a closed form
for average, min, and max comparisons (well, unless a close
approximation is good enough, you have to sum about lg n terms which is
near instantaneous, with a real closed form mostly available when n is
special, like a power of 2).  And I know how to work with more modern
computer plagues, like the need for cache coherency.

So in short, I have a somewhat related scientific education, but I can
work the required math.  And I can work the computers.

 Oh, and rest assured, it works both ways: people who did graduate are
 now and then thinking it's the holy grail and no body can beat it with
 home study.

 Both are wrong, by the way.

Depends.  In my personal opinion, living close to the iron and being
sharp enough can make a lot of a difference.

Donald Knuth never studied computer science.  He more or less founded
it.  As a programmer, he is too much artist and too little engineer for
my taste: you can't take his proverbial masterpiece TeX apart without
the pieces crumbling.  He won't write inefficient programs: he has the
respective gene and the knowledge to apply it.  But the stuff he wrote
is not well maintainable and reusable.  Of course, he has no need for
reuse if he can rewrite as fast as applying an interface.

-- 
David Kastrup
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-22 Thread John Bokma

David Kastrup d...@gnu.org writes:

 John Bokma j...@castleamber.com writes:

 David Kastrup d...@gnu.org writes:

 John Passaniti john.passan...@gmail.com writes:

 Amen!  All this academic talk is useless.  Who cares about things like
 the big-O notation for program complexity.  Can't people just *look*
 at code and see how complex it is?!  And take things like the years of
 wasted effort computer scientists have put into taking data structures
 (like hashes and various kinds of trees) and extending them along
 various problem domains and requirements.  Real programmers don't
 waste their time with learning that junk.  What good did any of that
 ever do anyone?!

 It is my experience that in particular graduated (and in particular Phd)
 computer scientists don't waste their time _applying_ that junk.

 Question: do you have a degree in computer science?

 Since in my experience: people who talk about their experience with
 graduated people often missed the boat themselves and think that reading
 a book or two equals years of study.

 I have a degree in electrical engineering.  But that's similarly
 irrelevant.

Nah, it's not: your attitude towards people with a degree in computer
science agrees with what I wrote.

 That has not particularly helped my respect towards CS majors and PhDs
 in the function of programmers (and to be honest: their education is not
 intended to make them good programmers, but to enable them to _lead_
 good programmers).

I disagree. 

 That does not mean that I am incapable of analyzing, say quicksort and
 mergesort,

Oh, that's what I was not implying. I am convinced that quite some
people who do self-study can end up with better understanding of things
than people who do it for a degree. I have done both: I already was
programming in several languages before I was studying CS. And my
experience is that a formal study in CS can't compare to home study
unless you're really good and have the time and drive to read formal
books written on CS. And my experience is that most self-educaters don't
have that time.

On the other hand: some people I knew during my studies had no problem
at all with introducing countless memory leaks in small programs (and
turning off compiler warnings, because it gave so much noise...)

 Donald Knuth never studied computer science.

Yes, yes, and Albert Einstein worked at an office.

Those people are very rare. 

But my experience (see for plenty of examples: Slashdot) is that quite
some people who don't have a degree think that all that formal education
is just some paper pushing and doesn't count. While some of those who do
have the paper think they know it all. Those people who are right in
either group are a minority in my experience.

As for electrical engineering: done that (BSc) and one of my class mates
managed to connect a transformer the wrong way around twice. Yet he
had the highest mark in our class.

So in short: yes, self-study can make you good at something. But
self-study IMO is not in general a replacement for a degree. Someone who
can become great after self-study would excel at a formal study and
learn more. Study works best if there is competition and if there are
challenges. I still study a lot at home, but I do miss the challenges
and competition.

-- 
John Bokma   j3b

Blog: http://johnbokma.com/Facebook: http://www.facebook.com/j.j.j.bokma
Freelance Perl  Python Development: http://castleamber.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-22 Thread 1001nuits



Le Sun, 22 Aug 2010 20:12:36 +0200, John Bokma j...@castleamber.com a  
écrit:



David Kastrup d...@gnu.org writes:


John Bokma j...@castleamber.com writes:


David Kastrup d...@gnu.org writes:


John Passaniti john.passan...@gmail.com writes:

Amen!  All this academic talk is useless.  Who cares about things  
like

the big-O notation for program complexity.  Can't people just *look*
at code and see how complex it is?!  And take things like the years  
of
wasted effort computer scientists have put into taking data  
structures

(like hashes and various kinds of trees) and extending them along
various problem domains and requirements.  Real programmers don't
waste their time with learning that junk.  What good did any of that
ever do anyone?!


It is my experience that in particular graduated (and in particular  
Phd)

computer scientists don't waste their time _applying_ that junk.


Question: do you have a degree in computer science?

Since in my experience: people who talk about their experience with
graduated people often missed the boat themselves and think that  
reading

a book or two equals years of study.


I have a degree in electrical engineering.  But that's similarly
irrelevant.


Nah, it's not: your attitude towards people with a degree in computer
science agrees with what I wrote.


That has not particularly helped my respect towards CS majors and PhDs
in the function of programmers (and to be honest: their education is not
intended to make them good programmers, but to enable them to _lead_
good programmers).


I disagree.


That does not mean that I am incapable of analyzing, say quicksort and
mergesort,


Oh, that's what I was not implying. I am convinced that quite some
people who do self-study can end up with better understanding of things
than people who do it for a degree. I have done both: I already was
programming in several languages before I was studying CS. And my
experience is that a formal study in CS can't compare to home study
unless you're really good and have the time and drive to read formal
books written on CS. And my experience is that most self-educaters don't
have that time.

On the other hand: some people I knew during my studies had no problem
at all with introducing countless memory leaks in small programs (and
turning off compiler warnings, because it gave so much noise...)


Donald Knuth never studied computer science.


Yes, yes, and Albert Einstein worked at an office.

Those people are very rare.

But my experience (see for plenty of examples: Slashdot) is that quite
some people who don't have a degree think that all that formal education
is just some paper pushing and doesn't count. While some of those who do
have the paper think they know it all. Those people who are right in
either group are a minority in my experience.

As for electrical engineering: done that (BSc) and one of my class mates
managed to connect a transformer the wrong way around twice. Yet he
had the highest mark in our class.

So in short: yes, self-study can make you good at something. But
self-study IMO is not in general a replacement for a degree. Someone who
can become great after self-study would excel at a formal study and
learn more. Study works best if there is competition and if there are
challenges. I still study a lot at home, but I do miss the challenges
and competition.



Hi all,

I quite agree with the fact that self learning is not enough.

Another thing you learn in studying in University is the fact that you can  
be wrong, which is quite difficult to accept for self taught people. When  
you work in groups, you are bound to admit that you don't have the best  
solution all the time. To my experience, self-taught people I worked with  
had tremendous difficulties to accept that they were wrong, that their  
design was badly done, that their code was badly written or strangely  
designed.


Because self teaching was done with a lot of efforts, in particular to  
figure out complex problems on their own. Most of the time, the self  
learned people are attached to the things they learned by themselves and  
have difficulties to envisage that being right of wrong is often not an  
issue provided the group comes to the best option. They often live  
contradiction as a personal offense while it is just work, you know.


That's another interest of the degree, confrontation with other people  
that have the same background. And letting the things learned at the place  
they should be and not in the affective area.


1001




--
Utilisant le logiciel de courrier révolutionnaire d'Opera :  
http://www.opera.com/mail/

--
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-21 Thread Elizabeth D Rather


On 8/20/10 7:42 PM, Standish P wrote:
...

Admittedly, I am asking a question that would be thought
provoking to those who claim to be experts but these experts are
actually very stingy and mean business people, most certainly worse
than Bill Gates, only it did not occur to them his ideas and at the
right time.


The problem as I see it is that you're asking complex questions in a 
forum that, at best, supports simple answers.  The information you're 
looking for exists, on the net, free.  There are free pdfs of manuals on 
Forth available with program downloads from FORTH, Inc., MPE, Gforth, 
and other sources, as well as some inexpensive books.  But you have to 
be willing to make the investment to download and read them, because the 
answers to your questions are not simple one-liners that you can get 
from newsgroups, and the folks in newsgroups are not prepared to host 
computer science seminars -- many of us are working programmers, 
engineers, and project managers who have limited time to spend here.  If 
you're willing to invest your time enough to investigate some of these 
sources, and still have questions, we'll be happy to try to help.


Cheers,
Elizabeth

--
==
Elizabeth D. Rather   (US  Canada)   800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

Forth-based products and Services for real-time
applications since 1973.
==
--
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-21 Thread David Kastrup

John Passaniti john.passan...@gmail.com writes:

 Amen!  All this academic talk is useless.  Who cares about things like
 the big-O notation for program complexity.  Can't people just *look*
 at code and see how complex it is?!  And take things like the years of
 wasted effort computer scientists have put into taking data structures
 (like hashes and various kinds of trees) and extending them along
 various problem domains and requirements.  Real programmers don't
 waste their time with learning that junk.  What good did any of that
 ever do anyone?!

It is my experience that in particular graduated (and in particular Phd)
computer scientists don't waste their time _applying_ that junk.  They
have learnt to analyze it, they could tell you how bad their own
algorithms are (if they actually bothered applying their knowledge), but
it does not occur to them to replace them by better ones.  Or even
factor their solutions in a way that the algorithms and data structures
are actually isolated.

I think there must be some programmer gene.  It is not enough to be able
to recognize O(n^k) or worse (though it helps having a more exact rather
than a fuzzy notion of them _if_ you have that gene).  You have to fear
it.  It has to hurt.  You need to feel compassion with the CPU.  It's
not enough to sit there in your easychair, occasionally sucking on your
pipeline and listen to its story about a hard realtime youth and its
strained connection to its motherboard.  When it stops, you have to see
its benchmarks and feel their pain in your own backplane.

-- 
David Kastrup
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-21 Thread Alex McDonald

On 21 Aug, 06:42, Standish P stnd...@gmail.com wrote:
 On Aug 20, 3:51 pm, Hugh Aguilar hughaguila...@yahoo.com wrote:



  On Aug 18, 6:23 pm, Standish P stnd...@gmail.com wrote:

   On Aug 17, 6:38 pm, John Passaniti john.passan...@gmail.com wrote:

You asked if Forth borrowed lists from Lisp.  It did not.  In Lisp,
lists are constructed with pair of pointers called a cons cell.
That is the most primitive component that makes up a list.  Forth has
no such thing; in Forth, the dictionary (which is traditionally, but
not necessarily a list) is a data structure that links to the previous
word with a pointer.  

   Would you show me a picture, ascii art or whatever for Forth ? I know
   what lisp lists look like so I dont need that for comparison. Forth
   must have a convention and a standard or preferred practice for its
   dicts. However, let me tell you that in postscript the dictionaries
   can be nested inside other dictionaries and any such hiearchical
   structure is a nested associative list, which is what linked list,
   nested dictionaries, nested tables are.

  You can see an example of lists in my novice package (in the list.4th
  file):http://www.forth.org/novice.html
  Also in there is symtab, which is a data structure intended to be used
  for symbol tables (dictionaries). Almost nobody uses linked lists for
  the dictionary anymore (the FIG compilers of the 1970s did, but they
  are obsolete).

  I must say, I've read through this entire thread and I didn't
  understand *anything* that *anybody* was saying (especially the OP).

 You didnt understand anything because no one explained anything
 coherently.

It indicates that you're asking a question that *you don't
understand*.

I'm continually amazed that people come to Usenet, wikis, websites and
other fora and ask questions that even the most basic of research (and
a bit of care with terminology aka using the right words) would show
to be confused. A quick scan of the available literature on garbage
collection and stacks, starting with the fundamentals, would surely
show you what you need to know.

 Admittedly, I am asking a question that would be thought
 provoking to those who claim to be experts but these experts are
 actually very stingy and mean business people, most certainly worse
 than Bill Gates, only it did not occur to them his ideas and at the
 right time.


What surprises may is that anyone bothered to answer, as your question
was neither thought provoking nor in need of attention from an
expert. Their generosity in the face of so much stupidity stands out
as remarkable.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-21 Thread Hugh Aguilar

On Aug 21, 5:29 am, Alex McDonald b...@rivadpm.com wrote:
On 21 Aug, 06:42, Standish P stnd...@gmail.com wrote:
Admittedly, I am asking a question that would be thought
provoking to those who claim to be experts but these experts are
actually very stingy and mean business people, most certainly worse
than Bill Gates, only it did not occur to them his ideas and at the
right time.

What surprises may is that anyone bothered to answer, as your question
was neither thought provoking nor in need of attention from an
expert. Their generosity in the face of so much stupidity stands out
as remarkable.

I wouldn't call the OP stupid, which is just mean-spirited. That is
not much of a welcome wagon for somebody who might learn Forth
eventually and join our rather diminished ranks. Lets go with over-
educated instead! I thought that his question was vague. It seemed
like the kind of question that students pose to their professor in
class to impress him with their thoughtfulness, so that he'll forget
that they never did get any of their homework-assignment programs to
actually work. I yet maintain that writing programs is what
programming is all about.

I see a lot of pseudo-intellectual blather on comp.lang.forth. The
following is a pretty good example, in which Alex mixes big pseudo-
intellectual words such as scintilla with gutter language such as
turd in an ungrammatical mish-mash --- and defends the overuse of
the return stack for holding temporary data as being readable(?!):
http://groups.google.com/group/comp.lang.forth/browse_thread/thread/4b9f67406c6852dd/0218831f02564410

On Jul 23, 4:43 pm, Alex McDonald b...@rivadpm.com wrote:
Whereas yours contained several tens, and nearly every one of them is
wrong. Hugh, do you actually have any evidence -- even a scintilla --
that supports this log winded opinions-as-fact post? Take any of the
statements you make, and demonstrate that you can justify it.
Reminding us that you said it before doesn't count.

Start with this turd of an assertion and see if you can polish it;
Most of the time, when Forth code gets really ugly, it is because of
an overuse of R...R --- that is a big reason why people use GCC
rather than Forth.
--
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-21 Thread Alex McDonald

On 21 Aug, 17:58, Hugh Aguilar hughaguila...@yahoo.com wrote:
 On Aug 21, 5:29 am, Alex McDonald b...@rivadpm.com wrote:

  On 21 Aug, 06:42, Standish P stnd...@gmail.com wrote:
   Admittedly, I am asking a question that would be thought
   provoking to those who claim to be experts but these experts are
   actually very stingy and mean business people, most certainly worse
   than Bill Gates, only it did not occur to them his ideas and at the
   right time.

  What surprises may is that anyone bothered to answer, as your question
  was neither thought provoking nor in need of attention from an
  expert. Their generosity in the face of so much stupidity stands out
  as remarkable.

 I wouldn't call the OP stupid, which is just mean-spirited.

Perhaps I'm just getting less forgiving the older I get, or the more I
read here. The internet is a fine resource for research, and tools
like google, archivx and so on are easy to access and take but a
little effort to use.

 That is
 not much of a welcome wagon for somebody who might learn Forth
 eventually and join our rather diminished ranks.

I care neither to be included in your diminished ranks, nor do I
take much regard of popularity as you define it. Standish P doesn't
want to join anything; he (like you) has an agenda for yet another
club with a membership of one.

 Lets go with over-
 educated instead! I thought that his question was vague. It seemed
 like the kind of question that students pose to their professor in
 class to impress him with their thoughtfulness, so that he'll forget
 that they never did get any of their homework-assignment programs to
 actually work.

It didn't work. He hasn't done any homework, neither do you, and it
shows.

 I yet maintain that writing programs is what
 programming is all about.

You remind me of those that would build a house without an architect,
or fly without bothering to study the weather.


 I see a lot of pseudo-intellectual blather on comp.lang.forth. The
 following is a pretty good example, in which Alex mixes big pseudo-
 intellectual words such as scintilla

Scintilla gets about 2,080,000 results on google; blather gets
about 876,000 results. O Hugh, you pseudo-intellectual you!

 with gutter language such as
 turd

About 5,910,000 results. It has a long history, even getting a mention
in the Wyclif's 13th century bible.

 in an ungrammatical mish-mash --- and defends the overuse of
 the return stack for holding temporary data as being readable(?!):


I did? Where? You're making stuff up. Again.


 http://groups.google.com/group/comp.lang.forth/browse_thread/thread/4...

 On Jul 23, 4:43 pm, Alex McDonald b...@rivadpm.com wrote:

  Whereas yours contained several tens, and nearly every one of them is
  wrong. Hugh, do you actually have any evidence -- even a scintilla --
  that supports this log winded opinions-as-fact post? Take any of the
  statements you make, and demonstrate that you can justify it.
  Reminding us that you said it before doesn't count.

  Start with this turd of an assertion and see if you can polish it;
  Most of the time, when Forth code gets really ugly, it is because of
  an overuse of R...R --- that is a big reason why people use GCC
  rather than Forth.


Something you never did address, probably because the statement you
made is just another symptom of Aguilar's Disease; presenting as fact
an opinion based on personal experience, limited observation and no
research.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-21 Thread John Bokma

David Kastrup d...@gnu.org writes:

 John Passaniti john.passan...@gmail.com writes:

 Amen!  All this academic talk is useless.  Who cares about things like
 the big-O notation for program complexity.  Can't people just *look*
 at code and see how complex it is?!  And take things like the years of
 wasted effort computer scientists have put into taking data structures
 (like hashes and various kinds of trees) and extending them along
 various problem domains and requirements.  Real programmers don't
 waste their time with learning that junk.  What good did any of that
 ever do anyone?!

 It is my experience that in particular graduated (and in particular Phd)
 computer scientists don't waste their time _applying_ that junk.

Question: do you have a degree in computer science?

Since in my experience: people who talk about their experience with
graduated people often missed the boat themselves and think that reading
a book or two equals years of study.

Oh, and rest assured, it works both ways: people who did graduate are
now and then thinking it's the holy grail and no body can beat it with
home study.

Both are wrong, by the way.

-- 
John Bokma   j3b

Blog: http://johnbokma.com/Facebook: http://www.facebook.com/j.j.j.bokma
Freelance Perl  Python Development: http://castleamber.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-21 Thread Brad

On Aug 21, 3:36 am, David Kastrup d...@gnu.org wrote:

 I think there must be some programmer gene.  It is not enough to be able
 to recognize O(n^k) or worse (though it helps having a more exact rather
 than a fuzzy notion of them _if_ you have that gene).  

Some of the best minds in comp.lang.forth have a penchant for sarcasm
- one of the reasons I always read their posts. Maybe it gets lost on
the international crowd, but I love it.

-Brad
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-20 Thread Standish P

On Aug 19, 8:25 am, c...@tiac.net (Richard Harter) wrote:
 On Wed, 18 Aug 2010 01:39:09 -0700 (PDT), Nick Keighley

 nick_keighley_nos...@hotmail.com wrote:
 On 17 Aug, 18:34, Standish P stnd...@gmail.com wrote:
  How are these heaps being implemented ? Is there some illustrative
  code or a book showing how to implement these heaps in C for example ?

 any book of algorithms I'd have thought

 http://en.wikipedia.org/wiki/Dynamic_memory_allocation
 http://www.flounder.com/inside_storage_allocation.htm


 I've no idea how good either of these is


 The wikipedia page is worthless.  The flounder page has
 substantial meat, but the layout and organization is a mess.  A
 quick google search didn't turn up much that was general - most
 articles are about implementations in specific environments.

I second your assessment.

What we have is blind leading the blind. Keith Thompson A CORPORATE
MINDER - with multiple accounts - on a Crusade to limit discussions of
useful nature on the usenet, must be giving anti-education, pro-
illiteracy corporatists (who did much of studies and development on
TAX-PAYER MONEY, maybe from now on we should fund Indian/Chinese/
Vietnamese/Russian/Cuban companies that have a tradition of sharing
knowledge from the socialist value system) ,lots of joy because that
means more market for their user-friendly , thought-killing
products and high priced courses.

You will see how consistently, she gives short replies, that have
ZILCH educational contents, compared to the volume of details they
boast on their websites they claim know.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-20 Thread Malcolm McLean

On Aug 19, 2:14 pm, spinoza spinoza1...@yahoo.com wrote:
 All the rest [how to implement heaps] is
 detail for the little techies to normally, get wrong.

That's a fundamental feature of structured programming.

If we maintain the interface malloc(), realloc(), and free(), then we
could have a fairly simple or a fairly complicated scheme, and the
user doesn't care or need to know.

The problem is that a lot of techniques we can use to speed up memory
management, such as allocating from a stack, can't be used with this
interface. Designing good interfaces is hard.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-20 Thread Hugh Aguilar

On Aug 18, 6:23 pm, Standish P stnd...@gmail.com wrote:
 On Aug 17, 6:38 pm, John Passaniti john.passan...@gmail.com wrote:

  You asked if Forth borrowed lists from Lisp.  It did not.  In Lisp,
  lists are constructed with pair of pointers called a cons cell.
  That is the most primitive component that makes up a list.  Forth has
  no such thing; in Forth, the dictionary (which is traditionally, but
  not necessarily a list) is a data structure that links to the previous
  word with a pointer.  

 Would you show me a picture, ascii art or whatever for Forth ? I know
 what lisp lists look like so I dont need that for comparison. Forth
 must have a convention and a standard or preferred practice for its
 dicts. However, let me tell you that in postscript the dictionaries
 can be nested inside other dictionaries and any such hiearchical
 structure is a nested associative list, which is what linked list,
 nested dictionaries, nested tables are.

You can see an example of lists in my novice package (in the list.4th
file):
http://www.forth.org/novice.html
Also in there is symtab, which is a data structure intended to be used
for symbol tables (dictionaries). Almost nobody uses linked lists for
the dictionary anymore (the FIG compilers of the 1970s did, but they
are obsolete).

I must say, I've read through this entire thread and I didn't
understand *anything* that *anybody* was saying (especially the OP). I
really recommend that people spend a lot more time writing code, and a
lot less time with all of this pseudo-intellectual nonsense. This
whole thread (and most of what I see on C.L.F. these days) reminds me
of the dialectic method of the early Middle Ages --- a lot of talk
and no substance.

Write some programs! Are we not programmers?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-20 Thread Hugh Aguilar

On Aug 18, 6:13 pm, Standish P stnd...@gmail.com wrote:
  Mostly it had a snowball's chance because it was never picked up by
  the CS gurus who, AFAIK, never really took a serious look at it.

 Its quite possible that the criticism is unfair, but dont you think
 that in part some responsibility must be borne by your organization in
 not doing a good job of education ?
 ...
 She is quite humble. Take a look at this page,

 http://www.forth.com/resources/evolution/index.html

That is actually pretty humorous; she managed to describe herself as a
leading expert twice in a single short paragraph. LOL

See! I do have a sense of humor!
http://groups.google.com/group/comp.lang.forth/browse_thread/thread/4c4dba9135bcf03e/8086ee13095bf78c
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-20 Thread John Passaniti

On Aug 20, 6:51 pm, Hugh Aguilar hughaguila...@yahoo.com wrote:
 You can see an example of lists in my novice package (in the list.4th
 file):http://www.forth.org/novice.html
 Also in there is symtab, which is a data structure intended to be used
 for symbol tables (dictionaries). Almost nobody uses linked lists for
 the dictionary anymore (the FIG compilers of the 1970s did, but they
 are obsolete).

Thanks for pointing this out, Hugh.  After reading the code in your
novice package and symtab, I am confused:  With code of that caliber
and the obvious stunning intellect behind it, why hasn't everyone
adapted your awesome symtab for symbol tables instead?  Any why hasn't
there been an effort to translate symtab into other languages so users
outside of Forth can also experience the sheer speed and hyper-
efficient use of memory and CPU?  Let me say I find it refreshing that
a great programmer like yourself doesn't bother with stupid fads like
testing algorithms against large data sets and measuring performance
relative to competitive algorithms.  That's all academic nonsense.
The only test and measurement anyone needs are the comments at the top
of symtab where you state your algorithm is better.  You clearly
wouldn't have written that if it wasn't true.

 Write some programs! Are we not programmers?

Amen!  All this academic talk is useless.  Who cares about things like
the big-O notation for program complexity.  Can't people just *look*
at code and see how complex it is?!  And take things like the years of
wasted effort computer scientists have put into taking data structures
(like hashes and various kinds of trees) and extending them along
various problem domains and requirements.  Real programmers don't
waste their time with learning that junk.  What good did any of that
ever do anyone?!

Thanks Hugh for a refreshing stance on what it means to be a
programmer.

-- 
http://mail.python.org/mailman/listinfo/python-list

OI VEY, I AGREE -was once [Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?]

2010-08-20 Thread Richard Owlett


John Passaniti wrote:

On Aug 20, 6:51 pm, Hugh Aguilarhughaguila...@yahoo.com  wrote:

You can see an example of lists in my novice package (in the list.4th
file):http://www.forth.org/novice.html
Also in there is symtab, which is a data structure intended to be used
for symbol tables (dictionaries). Almost nobody uses linked lists for
the dictionary anymore (the FIG compilers of the 1970s did, but they
are obsolete).


Thanks for pointing this out, Hugh.  After reading the code in your
novice package and symtab, I am confused:  With code of that caliber
and the obvious stunning intellect behind it, why hasn't everyone
adapted your awesome symtab for symbol tables instead?  Any why hasn't
there been an effort to translate symtab into other languages so users
outside of Forth can also experience the sheer speed and hyper-
efficient use of memory and CPU?  Let me say I find it refreshing that
a great programmer like yourself doesn't bother with stupid fads like
testing algorithms against large data sets and measuring performance
relative to competitive algorithms.  That's all academic nonsense.
The only test and measurement anyone needs are the comments at the top
of symtab where you state your algorithm is better.  You clearly
wouldn't have written that if it wasn't true.


Write some programs! Are we not programmers?


Amen!  All this academic talk is useless.  Who cares about things like
the big-O notation for program complexity.  Can't people just *look*
at code and see how complex it is?!  And take things like the years of
wasted effort computer scientists have put into taking data structures
(like hashes and various kinds of trees) and extending them along
various problem domains and requirements.  Real programmers don't
waste their time with learning that junk.  What good did any of that
ever do anyone?!

Thanks Hugh for a refreshing stance on what it means to be a
programmer.



Never thought I I'd agree wholeheartedly with very verbose John.

Hugh, you are complete idiot!

(and other less complementary  ...)
--
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-20 Thread Standish P

On Aug 18, 8:05 pm, Elizabeth D Rather erat...@forth.com wrote:
 On 8/18/10 2:23 PM, Standish P wrote:

  On Aug 17, 6:38 pm, John Passanitijohn.passan...@gmail.com  wrote:

  You asked if Forth borrowed lists from Lisp.  It did not.  In Lisp,
  lists are constructed with pair of pointers called a cons cell.
  That is the most primitive component that makes up a list.  Forth has
  no such thing; in Forth, the dictionary (which is traditionally, but
  not necessarily a list) is a data structure that links to the previous
  word with a pointer.

  Would you show me a picture, ascii art or whatever for Forth ? I know
  what lisp lists look like so I dont need that for comparison. Forth
  must have a convention and a standard or preferred practice for its
  dicts. However, let me tell you that in postscript the dictionaries
  can be nested inside other dictionaries and any such hiearchical
  structure is a nested associative list, which is what linked list,
  nested dictionaries, nested tables are.

 You indicated that you have a copy of Forth Application Techniques.
 Sections 8.1 and 8.2 cover this topic, with some drawings.

Can someone send me a scan copy of sec 8.1 to 8.2 within the exemption
in the copyright law for my personal study and evaluation of the book
only.

I have only looked at the book cover on forth site and its table of
contents on amazon.

why elase would I ask where it is if I had a copy and would go
directly to index assuming it has a good indexing.

Alternative, a link to an open source of explanation would be
requested.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-20 Thread Standish P

On Aug 20, 3:51 pm, Hugh Aguilar hughaguila...@yahoo.com wrote:
 On Aug 18, 6:23 pm, Standish P stnd...@gmail.com wrote:





  On Aug 17, 6:38 pm, John Passaniti john.passan...@gmail.com wrote:

   You asked if Forth borrowed lists from Lisp.  It did not.  In Lisp,
   lists are constructed with pair of pointers called a cons cell.
   That is the most primitive component that makes up a list.  Forth has
   no such thing; in Forth, the dictionary (which is traditionally, but
   not necessarily a list) is a data structure that links to the previous
   word with a pointer.  

  Would you show me a picture, ascii art or whatever for Forth ? I know
  what lisp lists look like so I dont need that for comparison. Forth
  must have a convention and a standard or preferred practice for its
  dicts. However, let me tell you that in postscript the dictionaries
  can be nested inside other dictionaries and any such hiearchical
  structure is a nested associative list, which is what linked list,
  nested dictionaries, nested tables are.

 You can see an example of lists in my novice package (in the list.4th
 file):http://www.forth.org/novice.html
 Also in there is symtab, which is a data structure intended to be used
 for symbol tables (dictionaries). Almost nobody uses linked lists for
 the dictionary anymore (the FIG compilers of the 1970s did, but they
 are obsolete).

 I must say, I've read through this entire thread and I didn't
 understand *anything* that *anybody* was saying (especially the OP).

You didnt understand anything because no one explained anything
coherently. Admittedly, I am asking a question that would be thought
provoking to those who claim to be experts but these experts are
actually very stingy and mean business people, most certainly worse
than Bill Gates, only it did not occur to them his ideas and at the
right time.


 I really recommend that people spend a lot more time writing code, and a
 lot less time with all of this pseudo-intellectual nonsense.

You have to have a concept to write code.

 This
 whole thread (and most of what I see on C.L.F. these days) reminds me
 of the dialectic method of the early Middle Ages --- a lot of talk
 and no substance.

 Write some programs! Are we not programmers?- Hide quoted text -

 - Show quoted text -

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-19 Thread Standish P

On Aug 18, 5:38 pm, Keith Thompson ks...@mib.org wrote:
 Standish P stnd...@gmail.com writes:
  On Aug 18, 12:30 pm, Elizabeth D Rather erat...@forth.com wrote:
 [...]
  Mostly it had a snowball's chance because it was never picked up by
  the CS gurus who, AFAIK, never really took a serious look at it.

  Its quite possible that the criticism is unfair, but dont you think
  that in part some responsibility must be borne by your organization in
  not doing a good job of education ?
 [snip]
  Show me on what page does it explain how Forth implements dynamic
  binding or lexical binding and takes care of the scope of definition
  of the nouns ?

 [...]


 Show me how this is relevant to comp.lang.c, comp.lang.c++, comp.theory,
 or comp.lang.python.  Please trim the Newsgroups line.

provide a rigorous proof that people are more interested in the
nauseating nude pictures that you post of your mother in the
newsgroups than in the subject of forth implementation. as a matter of
fact a lot of people in various language groups are interested in
implementation aspects and the languages borrow ideas from each other.

now, get away from my thread and take away your odious posts which
positively cause me nausea and vomiting.

we will soon find out the game of stacks.


 --
 Keith Thompson (The_Other_Keith) ks...@mib.org  http://www.ghoti.net/~kst
 Nokia
 We must do something.  This is something.  Therefore, we must do this.
     -- Antony Jay and Jonathan Lynn, Yes Minister

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-19 Thread John Kelly

On Thu, 19 Aug 2010 00:56:35 -0700 (PDT), Standish P stnd...@gmail.com
wrote:

On Aug 18, 5:38 pm, Keith Thompson ks...@mib.org wrote:
 Standish P stnd...@gmail.com writes:

  Show me on what page does it explain how Forth implements dynamic
  binding or lexical binding and takes care of the scope of definition
  of the nouns ?

 Show me how this is relevant to comp.lang.c, comp.lang.c++, comp.theory,
 or comp.lang.python.  Please trim the Newsgroups line.

fact a lot of people in various language groups are interested in
implementation aspects and the languages borrow ideas from each other.

Standish sounds like Spinoza in disguise.  Nevertheless, ngs like c.l.c
need more diversity.  Standards minutia is boring.


-- 
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-19 Thread spinoza1111

On Aug 18, 1:44 am, James Kanze james.ka...@gmail.com wrote:
 On Aug 17, 6:21 pm, Standish P stnd...@gmail.com wrote:

   Garbage collection doesn't use a stack. It uses a heap,
   which is in the abstract a collection of memory blocks of
   different lengths, divided into two lists, generally
   represented as linked lists:
   1.  A list of blocks that are free and may be used to store
   new data
   2.  A list of blocks that are in use, or haven't been freed (yet)
  Is this all that a heap is or is there more to it ?

 There are many different ways to implement a heap.  The above is
 not a good one, and I doubt that it's really used anywhere.

Actually, that's the only way to implement a heap in the abstract.
Forest and trees, mate. Mathematically a heap is a block of storage, a
list of free blocks and a list of allocated blocks. All the rest is
detail for the little techies to normally, get wrong. The confusion
between scientific and technical progress is a mirror of the (far more
serious) confusion between scientific progress and ethical advance.

Sure, when you free a block it is a good idea to see if you can join
it with its neighbors to get the biggest bang for the buck. This,
again, is a detail relative to the grand plan which gives only techies
a hard-on, because the way scientific is confused with technical
progress is, in Foucault's terms, capillary. Part of ethical
regression is the overemphasis on efficiency and metaphors taken from
America's genocidal first use of nuclear weapons.


  I have been looking for simple but complete explanation of
  heap for a while and not gotten to it.

 Complete in what sense?  The basic principle of how to use it is
 simple.  As for how to implement it, there are many different
 algorithms that can be used.

Correct, for a change.


  I think I am looking for a stack allocation on the same
  pattern.

 Stack allocation is far, far simpler (usually).

And very different.


  In a disk, a file is fragmented in many contiguous blocks and
  is accessed automatically.

 At the system level, the same thing holds for memory, and the
 actual physical memory is fragmented into contiguous blocks,
 each the size of a page.  The MMU (hardware) makes this
 transparent to user programs, however.

   There is no way you could do memory management of all but the most
   trivial and fixed-length data chunks using a stack.

 The length isn't the issue.  The order of allocation and freeing
 is.  (For many specific uses, stack based allocators can and
 have been used, but they don't work for generally allocation.)

 --
 James Kanze

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-19 Thread Anton Ertl

John Nagle na...@animats.com writes:
In the superscalar era, there's not much of an advantage to avoiding
stack accesses.

Apart from 4stack, I am not aware of a superscalar stack machine (and
4stack is more of an LIW than a superscalar).

OTOH, if by stack accesses you mean memory accesses through the stack
pointer on a register machine, then evidence contradicts your claim.
E.g., if we can keep one or two more of Gforth's VM's registers in
real registers rather than on the stack of an IA32 CPU, we see
significant speedups (like a factor of 2).

x86 superscalar machines have many registers not
visible to the program, as the fastest level of cache.

They have a data cache for memory accesses (about 3 cycles load-to-use
latency on current CPUs for these architectures), and they have rename
registers (not visible to programmers) that don't cache memory.  They
also have a store buffer with store-to-load forwarding, but that still
has no better load-to-use latency.

In practice,
the top of the stack is usually in CPU registers.

Only if the Forth system is written that way.

 The huge number
of programmer-visible register machines like SPARCs turned out to be
a dead end.

Really?  Architectures with 32 programmer-visible registers like SPARC
(but, unlike SPARC, without register windows) are quite successful in
embedded systems (e.g., MIPS, SPARC).

So did making all the instructions the same width; it
makes the CPU simpler, but not faster, and it bulks up the program
by 2x or so.

In the beginning it also made the CPU faster.  As for the bulk, here's
some data from 2007dec11.202...@mips.complang.tuwien.ac.at; it's the
text (code) size of /usr/bin/dpkg in a specific version of the dpkg
package:

.text
section
 98132 dpkg_1.14.12_hurd-i386.deb
230024 dpkg_1.14.12_m68k.deb
249572 dpkg_1.14.12_amd64.deb
254984 dpkg_1.14.12_arm.deb
263596 dpkg_1.14.12_i386.deb
271832 dpkg_1.14.12_s390.deb
277576 dpkg_1.14.12_sparc.deb
295124 dpkg_1.14.12_hppa.deb
320032 dpkg_1.14.12_powerpc.deb
351968 dpkg_1.14.12_alpha.deb
361872 dpkg_1.14.12_mipsel.deb
371584 dpkg_1.14.12_mips.deb
615200 dpkg_1.14.12_ia64.deb

Sticking with the Linux packages (i.e., not the Hurd one), the range
in code size increase over the i386 code is 0.97 (ARM) to 1.41 (MIPS)
for the classical architectures with fixed-size instructions (RISCs).
Only the IA64 has a code size increase by a factor of 2.33.  Note that
code size is not everything that's in a program binary, and the rest
should be unaffected by whether the instructions are fixed-size or
variable-sized, so the overall effect on the binary will be smaller.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
 New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2010: http://www.euroforth.org/ef10/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-19 Thread Richard Harter

On Wed, 18 Aug 2010 01:39:09 -0700 (PDT), Nick Keighley
nick_keighley_nos...@hotmail.com wrote:

On 17 Aug, 18:34, Standish P stnd...@gmail.com wrote:

 How are these heaps being implemented ? Is there some illustrative
 code or a book showing how to implement these heaps in C for example ?

any book of algorithms I'd have thought

http://en.wikipedia.org/wiki/Dynamic_memory_allocation
http://www.flounder.com/inside_storage_allocation.htm

I've no idea how good either of these is

The wikipedia page is worthless.  The flounder page has
substantial meat, but the layout and organization is a mess.  A
quick google search didn't turn up much that was general - most
articles are about implementations in specific environments.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-19 Thread Keith Thompson

Standish P stnd...@gmail.com writes:
 On Aug 18, 5:38 pm, Keith Thompson ks...@mib.org wrote:
[...]
 Show me how this is relevant to comp.lang.c, comp.lang.c++, comp.theory,
 or comp.lang.python.  Please trim the Newsgroups line.

 provide a rigorous proof that people are more interested in the
 nauseating nude pictures that you post of your mother in the
 newsgroups than in the subject of forth implementation.
[snip]

*plonk*

-- 
Keith Thompson (The_Other_Keith) ks...@mib.org  http://www.ghoti.net/~kst
Nokia
We must do something.  This is something.  Therefore, we must do this.
-- Antony Jay and Jonathan Lynn, Yes Minister
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-19 Thread Richard Harter

On Thu, 19 Aug 2010 04:14:42 -0700 (PDT), spinoza
spinoza1...@yahoo.com wrote:

On Aug 18, 1:44=A0am, James Kanze james.ka...@gmail.com wrote:
 On Aug 17, 6:21 pm, Standish P stnd...@gmail.com wrote:

   Garbage collection doesn't use a stack. It uses a heap,
   which is in the abstract a collection of memory blocks of
   different lengths, divided into two lists, generally
   represented as linked lists:
   1. =A0A list of blocks that are free and may be used to store
   new data
   2. =A0A list of blocks that are in use, or haven't been freed (yet)
  Is this all that a heap is or is there more to it ?

 There are many different ways to implement a heap. =A0The above is
 not a good one, and I doubt that it's really used anywhere.

Actually, that's the only way to implement a heap in the abstract.
Forest and trees, mate. Mathematically a heap is a block of storage, a
list of free blocks and a list of allocated blocks. All the rest is
detail for the little techies to normally, get wrong. The confusion
between scientific and technical progress is a mirror of the (far more
serious) confusion between scientific progress and ethical advance.

Sure, when you free a block it is a good idea to see if you can join
it with its neighbors to get the biggest bang for the buck.

[snip]

I appreciate your desire to provide a mathematical definition
but the one you gave won't quite do.  Your definition does not
specify what is meant by a block.  The notion of defining a heap
as a list of free list and a list of allocated blocks is
unfortunate. Neither a free list nor a list of allocated blocks
is of the essence.

It isn't easy to give a good definition of a heap (in the sense
of a storage heap) but here is a shot at it.

A heap is a data structure consisting of a pair (H,B) of
substructures, operations (split,join), and attribute A where:

H is a set of sequentially addressable elements.  That is, the
elements form a sequence, each element has an integer associated
with it (its address) and the difference between the addresses of
successive elements is a constant, w.  Let h_i be the address of
the initial element of H and h_f be the address of the final
element of H.

B is a set of integers such that (1) each element b of B is an
address of an element of H, and (2) h_i and h_f are elements of
B.  From this definition we can define the successor succ(b) of
each element (h_f has no successor) and we can order B if we
wish.

Given the construction of succ on B we can define block(b) as the
set of elements in H such that their addresses a satisfy

b = a  succ(a)

It is trivial to prove that the blocks of B divide H into
disjoint subsets that cover H.

The attribute A is defined for elements of B.  A(b) may have
either of two values - free and inuse.  A block b is said to be
free if A(b) = free and in use if A(b) = inuse.

An address, h, of H is said to be free if A(largest address b in
B that is = h) = free and in use otherwise. 

Now for the two operations: 

The join operator operates on all free elements of b except h_f.
It removes the successor of an element of b.  The effect is to
set succ(b) := succ(succ(b)).

The split operator operates on all free element addresses in H
that are not element addresses in B.  Let s be the argument for
split.  Split adds s to B.  The effect of split is to find the
largest address b in B that is smaller than s, set succ(s) :=
succ(b) and succ(b) := s.  Note that the successor changes
implicitly follow from the definitions of H, B, split, and join.

The above definition covers defining a storage heap.  It
establishes what blocks are, what the sequence of blocks is, and
how to alter the sequence of blocks.

The important thing here is that free lists/allocated lists are
not basic abstractions; rather they are derived concepts based on
the primitive concept of a block and the operations performed on
a set of blocks.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-18 Thread John Nagle


On 8/17/2010 11:20 AM, Standish P wrote:

On Aug 17, 1:17 am, torb...@diku.dk (Torben Ægidius Mogensen) wrote:

Standish Pstnd...@gmail.com  writes:

[Q] How far can stack [LIFO] solve do automatic garbage collection and
prevent memory leak ?



Because a stack has push and pop, it is able to release and allocate
memory. We envisage an exogenous stack which has malloc() associated
with a push and free() associated with a pop.


See


How many programmers have applied the ideas of these papers in their
programming practice ? I paste the abstract for convenience


http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.23.5498


Abstract:
This paper describes a memory management discipline for programs that
perform dynamic memory allocation and de-allocation. At runtime, all
values are put into regions. The store consists of a stack of regions.
All points of region allocation and deallocation are inferred
automatically, using a type and effect based program analysis. The
scheme does not assume the presence of a garbage collector.


That's actually an interesting idea.  If you can figure out object
lifetimes at compile time, allocation can be made far more efficient.

One of the basic questions is whether a function will ever keep
an object.  That is, will the function ever keep a reference to an
object that outlives the return from the function?  In many cases,
one can easily determine at compile time that a function will never
keep a passed object.  In such a case, you don't have to do reference
count updates on the object.  Most math functions have this property,
even vector and matrix math functions - they have no persistent state.

Python could use a bit of this.  If a function argument can
be identified as non-kept, then the function doesn't need to
do reference count updates on it.  If a local variable in
a function is used only by non-keep functions and operations,
it can be created on the stack and released cheaply at block exit.

One can go much further in lifetime inference than this, as
the papers demonstrate.  There's a big win in the simple optimization
of identifying non-keep parameters, especially in mathematical work
where they're very common.  It's not clear that getting fancier than
that is a win.

Does Shed Skin have this optimization?  It should.

John Nagle
--
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-18 Thread Nick Keighley

On 17 Aug, 18:34, Standish P stnd...@gmail.com wrote:
 On Aug 16, 11:09 am, Elizabeth D Rather erat...@forth.com wrote:
  On 8/15/10 10:33 PM, Standish P wrote:

   If Forth is a general processing language based on stack, is it
   possible to convert any and all algorithms to stack based ones and
   thus avoid memory leaks since a pop automatically releases memory when
   free is an intrinsic part of it.

  Forth uses two stacks.  The data stack is used for passing parameters
  between subroutines (words) and is completely under the control of the
  programmer.  Words expect parameters on this stack; they remove them,
  and leave only explicit results.  The return stack is used primarily
  for return addresses when words are called, although it is also
  available for auxiliary uses under guidelines which respect the primary
  use for return addresses.

  Although implementations vary, in most Forths stacks grow from a fixed
  point (one for each stack) into otherwise-unused memory.  The space
  involved is allocated when the program is launched, and is not managed
  as a heap and allocated or deallocated by any complicated mechanism.  On
  multitasking Forth systems, each task has its own stacks.  Where
  floating point is implemented (Forth's native arithmetic is
  integer-based), there is usually a separate stack for floats, to take
  advantage of hardware FP stacks.

       - is forth a general purpose language? Yes
       - are all algorithms stack based? No

   Does Forth uses stack for all algorithms ? Does it use pointers , ie
   indirect addressing ? If it can/must use stack then every algorithm
   could be made stack based.

  Forth uses its data stack for parameter passing and storage of temporary
  values.  It is also possible to define variables, strings, and arrays in
  memory, in which case their addresses may be passed on the data stack.

  Forth is architecturally very simple.  Memory allocations for variables,
  etc., are normally static, although some implementations include
  facilities for heaps as needed by applications.
  although some implementations include facilities for heaps as needed by 
  applications.

 How are these heaps being implemented ? Is there some illustrative
 code or a book showing how to implement these heaps in C for example ?

any book of algorithms I'd have thought

http://en.wikipedia.org/wiki/Dynamic_memory_allocation
http://www.flounder.com/inside_storage_allocation.htm

I've no idea how good either of these is

 Are dictionaries of forth and postscript themselves stacks if we
 consider them as nested two column tables which lisp's lists are in
 essence, but only single row. Multiple rows would just be multiple
 instances of it at the same level inside parens.

I can't make much sense of that. But you seem to see Lisp data
structures in all sorts of strange places. I don't see that Lisp lists
are nested two column tables

 we can peek into stacks which is like car.

no.


 if it is not unusually
 costly computation, why not allow it ? there is no need to restrict to
 push and pop.

some stacks have a top() operation.


 roll( stack_name, num)

 itself can give all those postfix permutations that push and pop cant
 generate with a single stack. Can we use dictionaries to generate
 multiple stacks inside one global stack ?

I've no idea what you on about


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-18 Thread Nick Keighley

On 17 Aug, 21:37, Elizabeth D Rather erat...@forth.com wrote:
 On 8/17/10 10:19 AM, Standish P wrote
  On Aug 17, 12:32 pm, John Passanitijohn.passan...@gmail.com  wrote:

  It is true that the other languages such as F/PS also have borrowed
  lists from lisp in the name of nested-dictionaries and mathematica
  calls them nested-tables as its fundamental data structure.

  No.

  you are contradicting an earlier poster from forth who admitted the
  part on dicts.

he's saying a forth dictionary isn't a lisp s-exp. Well it isn't.

 Not at all.  A Forth dictionary is a simple linked list, not the
 complicated kind of nested structures you're referring to.  You really
 seem addicted to very complex structures.

I thought he had the opposite problem! I thought it was trying to
knock in all his programming nails with same stack-based hammer.


  They really aren't necessary for general programming.

whaever *that* is
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-18 Thread spinoza1111

On Aug 18, 1:21 am, Standish P stnd...@gmail.com wrote:
  Garbage collection doesn't use a stack. It uses a heap, which is in
  the abstract a collection of memory blocks of different lengths,
  divided into two lists, generally represented as linked lists:

  1.  A list of blocks that are free and may be used to store new data

  2.  A list of blocks that are in use, or haven't been freed (yet)

 Is this all that a heap is or is there more to it ? I have been
 looking for simple but complete explanation of heap for a while and
 not gotten to it. I think I am looking for a stack allocation on the
 same pattern. In a disk, a file is fragmented in many contiguous
 blocks and is accessed automatically.





  There is no way you could do memory management of all but the most
  trivial and fixed-length data chunks using a stack. Sure, you could
  reserve thousands of bytes on the stack for an array but suppose your
  language allows arrays to grow or shrink. To keep its property of
  being adjacent, you'd have to do something horrible such as move
  unrelated data allocated later, which raises all sorts of security
  issues, doesn't it.
  A stack, or something which works like a stack (that is, a stack) is a
  necessary but not sufficient condition for a working C runtime because
  C functions can call themselves recursively, whether directly or
  indirectly. If this last condition did not obtain, each function could
  give the functions it calls some of its own memory and the called
  function could save a fixed set of non-stacked general registers in
  that area; this was in fact the practice on IBM 370 and in assembler
  language at a time when many data processing managers though
  recursion was a Communist plot.

  However, data structures of variable size, or data structures that
  merely take up a lot of space, don't play nice with others on the
  stack, so, we place their address on the stack and store them in
  another place, which was named the heap, probably, as a sort of
  witticism.

  Gilbert and Sullivan:

  If anyone anything lacks
  He'll find it all ready in stacks

 This you might want to take this to the Forth people because they are
 marketing their language as a cure for all that plagues programming
 today.

No, they're not. Stack based languages have seen better days and Forth
(and the SL/1 language I supported with compilers at Bell-Northern
Research) were last in fashion in the 1970s. Processors seldom could
multitask, so it wasn't recognized that the stack could be a
performance bottleneck, where stack operations cannot be pipelined or
executed in parallel.

John Hennessy of Stanford and MIPS made the stack must die case at ACM
ASPLOS in 1987. Niklaus Wirth was also at this conference at which I
was a fly on the wall, maintaining that the stack was good for
reliability and verifiability of software.

Forth had a snowball's chance because it forces ordinary programmers
to think in Reverse Polish notation and is for the above reasons hard
to pipeline, although of course it can be pipelined.



  was wrong, and needs to be brought up to date:

  You cannot do everything in a stack
  Unless you code an almighty hack
  If you're a coding Knight who says, Neep,
  You'll probably need to implement a heap
  A pile a heap of benefits you'll reap
  If only my advice in your brain you'll keep
  And avoid memory leaks from which data doth seep
  By using a well-implemented, well structured, and well-documented
  Heap!

  [Chorus of Sailors]
  We will to heart your advice take, and always use a heap!

  [Soloist]
  Oh thank you do
  To this be true
  And always my sage advice do keep
  That you always need to use a heap!- Hide quoted text -

  - Show quoted text -

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-18 Thread Alex McDonald

On 18 Aug, 11:09, spinoza spinoza1...@yahoo.com wrote:
 On Aug 18, 1:21 am, Standish P stnd...@gmail.com wrote:


  This you might want to take this to the Forth people because they are
  marketing their language as a cure for all that plagues programming
  today.

 No, they're not.

That I agree with.

 Stack based languages have seen better days and Forth
 (and the SL/1 language I supported with compilers at Bell-Northern
 Research) were last in fashion in the 1970s. Processors seldom could
 multitask, so it wasn't recognized that the stack could be a
 performance bottleneck, where stack operations cannot be pipelined or
 executed in parallel.

 John Hennessy of Stanford and MIPS made the stack must die case at ACM
 ASPLOS in 1987. Niklaus Wirth was also at this conference at which I
 was a fly on the wall, maintaining that the stack was good for
 reliability and verifiability of software.

 Forth had a snowball's chance because it forces ordinary programmers
 to think in Reverse Polish notation and is for the above reasons hard
 to pipeline, although of course it can be pipelined.

I really don't understand much of what you're saying here; Forth can
be implemented on processors that have several hardware assisted
stacks, 1 stack or even no stack at all. Multitasking? Why's that a
problem? And why is it hard to pipeline? Are you thinking of a
specific processor?





-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-18 Thread Elizabeth D Rather


On 8/18/10 12:09 AM, spinoza wrote:

On Aug 18, 1:21 am, Standish Pstnd...@gmail.com  wrote:

Garbage collection doesn't use a stack. It uses a heap, which is in
the abstract a collection of memory blocks of different lengths,
divided into two lists, generally represented as linked lists:



1.  A list of blocks that are free and may be used to store new data



2.  A list of blocks that are in use, or haven't been freed (yet)


Is this all that a heap is or is there more to it ? I have been
looking for simple but complete explanation of heap for a while and
not gotten to it. I think I am looking for a stack allocation on the
same pattern. In a disk, a file is fragmented in many contiguous
blocks and is accessed automatically.


Stacks (at least as far as Forth uses them) and heaps are fundamentally 
different things.


...

However, data structures of variable size, or data structures that
merely take up a lot of space, don't play nice with others on the
stack, so, we place their address on the stack and store them in
another place, which was named the heap, probably, as a sort of
witticism.


In Forth, they go in data space, which might or might not be in the 
dictionary, and is almost never in a dynamically managed heap; certainly 
not on a stack.

...



No, they're not. Stack based languages have seen better days and Forth
(and the SL/1 language I supported with compilers at Bell-Northern
Research) were last in fashion in the 1970s. Processors seldom could
multitask, so it wasn't recognized that the stack could be a
performance bottleneck, where stack operations cannot be pipelined or
executed in parallel.


Lol.  Forth supported multitasking on every processor it was implemented 
on in the 70's, with blazing speed compared to competitive techniques. 
I have never seen stack operations to be a bottleneck.


...

Forth had a snowball's chance because it forces ordinary programmers
to think in Reverse Polish notation and is for the above reasons hard
to pipeline, although of course it can be pipelined.


Mostly it had a snowball's chance because it was never picked up by 
the CS gurus who, AFAIK, never really took a serious look at it.


Cheers,
Elizabeth

--
==
Elizabeth D. Rather   (US  Canada)   800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

Forth-based products and Services for real-time
applications since 1973.
==
--
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-18 Thread Paul Rubin

Elizabeth D Rather erat...@forth.com writes:
 Processors seldom could multitask, so it wasn't recognized that the
 stack could be a performance bottleneck
 Lol.  Forth supported multitasking on every processor it was
 implemented on in the 70's, with blazing speed compared to competitive
 techniques. I have never seen stack operations to be a bottleneck.

I think multitasking in that post refers to superscalar execution,
which wasn't done in the 1970's except on supercomputers.  That the
stack is a bottleneck is the precise reason that optimizing Forth
compilers do complicated flow analysis to translate stack operations
into register operations.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-18 Thread John Nagle


On 8/18/2010 1:32 PM, Paul Rubin wrote:

Elizabeth D Rathererat...@forth.com  writes:

Processors seldom could multitask, so it wasn't recognized that the
stack could be a performance bottleneck

Lol.  Forth supported multitasking on every processor it was
implemented on in the 70's, with blazing speed compared to competitive
techniques. I have never seen stack operations to be a bottleneck.


I think multitasking in that post refers to superscalar execution,
which wasn't done in the 1970's except on supercomputers.  That the
stack is a bottleneck is the precise reason that optimizing Forth
compilers do complicated flow analysis to translate stack operations
into register operations.


   Some small FORTH machines had dedicated stack hardware.  On each
CPU cycle, the CPU could do one stack access, one main memory access,
and one return stack access.  This was before cacheing; those CPUs
were slow relative to their memory, so a non-cached 
one-instruction-per-clock machine made sense.


   In the superscalar era, there's not much of an advantage to avoiding
stack accesses.  x86 superscalar machines have many registers not
visible to the program, as the fastest level of cache.  In practice,
the top of the stack is usually in CPU registers.   The huge number
of programmer-visible register machines like SPARCs turned out to be
a dead end.  So did making all the instructions the same width; it
makes the CPU simpler, but not faster, and it bulks up the program
by 2x or so.

John Nagle

--
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-18 Thread Standish P

On Aug 18, 12:30 pm, Elizabeth D Rather erat...@forth.com wrote:
On 8/18/10 12:09 AM, spinoza wrote:

On Aug 18, 1:21 am, Standish Pstnd...@gmail.com wrote:
Garbage collection doesn't use a stack. It uses a heap, which is in
the abstract a collection of memory blocks of different lengths,
divided into two lists, generally represented as linked lists:

1. A list of blocks that are free and may be used to store new data

2. A list of blocks that are in use, or haven't been freed (yet)

Is this all that a heap is or is there more to it ? I have been
looking for simple but complete explanation of heap for a while and
not gotten to it. I think I am looking for a stack allocation on the
same pattern. In a disk, a file is fragmented in many contiguous
blocks and is accessed automatically.

Stacks (at least as far as Forth uses them) and heaps are fundamentally
different things.

...

However, data structures of variable size, or data structures that
merely take up a lot of space, don't play nice with others on the
stack, so, we place their address on the stack and store them in
another place, which was named the heap, probably, as a sort of
witticism.

In Forth, they go in data space, which might or might not be in the
dictionary, and is almost never in a dynamically managed heap; certainly
not on a stack.
...

No, they're not. Stack based languages have seen better days and Forth
(and the SL/1 language I supported with compilers at Bell-Northern
Research) were last in fashion in the 1970s. Processors seldom could
multitask, so it wasn't recognized that the stack could be a
performance bottleneck, where stack operations cannot be pipelined or
executed in parallel.

Lol. Forth supported multitasking on every processor it was implemented
on in the 70's, with blazing speed compared to competitive techniques.
I have never seen stack operations to be a bottleneck.

Forth had a snowball's chance because it forces ordinary programmers
to think in Reverse Polish notation and is for the above reasons hard
to pipeline, although of course it can be pipelined.

Mostly it had a snowball's chance because it was never picked up by
the CS gurus who, AFAIK, never really took a serious look at it.

Its quite possible that the criticism is unfair, but dont you think
that in part some responsibility must be borne by your organization in
not doing a good job of education ? I have looked at this book you
authored in the past few weeks and found a link for your convenience
now. This is entitled Advanced .

http://www.amazon.com/Forth-Application-Techniques-5th-Notebook/dp/1419685767/ref=sr_1_1?ie=UTF8s=booksqid=1282175842sr=8-1#reader_1419685767

Show me on what page does it explain how Forth implements dynamic
binding or lexical binding and takes care of the scope of definition
of the nouns ?

Provide me with a link, if you kindly would, that can take me to a
tutorial of Forth internals or discusses this issue.

Cheers,
Elizabeth

She is quite humble. Take a look at this page,

http://www.forth.com/resources/evolution/index.html

She is currently the number 1 in the forth world and if there was a
nobel prize in forth, it would go to these three.

Authors

Elizabeth D. Rather
FORTH, Inc.
5959 W. Century Blvd.
Suite 700
Los Angeles, CA 90045

Elizabeth Rather is the co-founder of FORTH, Inc. and is a leading
expert in the Forth programming language. Elizabeth was a colleague of
Chuck Moore back when he worked at NRAO in the early 1970s. During his
development of Forth, she became the second ever Forth programmer.
Since then, she has become a leading expert in the language and one of
its main proponents. Elizabeth was the chair of the ANSI Technical
Committee that produced the ANSI Standard for Forth (1994). She is an
author of several books on Forth and gives regular training seminars
on its usage.

Donald R. Colburn

c/o Digital Media Magic
14712 Westbury Rd.
Rockville, MD 20853

Don Colburn was one of the earliest Forth users. He was one of the
founders of the Forth Interest Group, and contributed to the
development of the first public-domain figForth. Subsequently, he
founded Creative Solutions, Inc. (CSI), which introduced MacForth™ in
1984. MacForth was the first programming language capable of running
on the Macintosh when it was first introduced. Don was a member of
the ANSI Technical Committee that produced the ANSI Standard for Forth
(1994). He died in 2009.

Charles H. Moore
Computer Cowboys
40 Cedar Lane
P.O. Box 127
Sierra City, CA 96125

Chuck Moore is Chairman and CTO of Green Arrays, Inc. He co-founded
FORTH, Inc., in 1971 and went on to develop a Forth-based chip
(RTX2000) in the mid 1980s, derivatives of which are still being used
widely by NASA. At Computer Cowboys, Mr. Moore designed the Sh-Boom
microprocessor and then co-founded iTv, an Internet Appliance
manufacturer. During the 1990s, he used his own CAD software to design

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-18 Thread Standish P

On Aug 17, 6:38 pm, John Passaniti john.passan...@gmail.com wrote:

 You asked if Forth borrowed lists from Lisp.  It did not.  In Lisp,
 lists are constructed with pair of pointers called a cons cell.
 That is the most primitive component that makes up a list.  Forth has
 no such thing; in Forth, the dictionary (which is traditionally, but
 not necessarily a list) is a data structure that links to the previous
 word with a pointer.  

Would you show me a picture, ascii art or whatever for Forth ? I know
what lisp lists look like so I dont need that for comparison. Forth
must have a convention and a standard or preferred practice for its
dicts. However, let me tell you that in postscript the dictionaries
can be nested inside other dictionaries and any such hiearchical
structure is a nested associative list, which is what linked list,
nested dictionaries, nested tables are.

 This is in fact one of the nice things about
 Lisp; because all lists are created out of the same primitive cons
 cell, you can consistently process any list in the system.  In Forth,
 any lists (such as the dictionary, if it is a list) are specific to
 their purpose and have to be treated individually.

 I don't know what you mean by nested-dictionaries.  There is no such
 thing in Forth.  Dictionaries don't nest.  You can create wordlists,
 but each wordlist is flat.  When most people think of a nested
 dictionary, they would think of a structure that would allow any
 arbitrary level of nesting, not a string of flat wordlists.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-18 Thread Keith Thompson

Standish P stnd...@gmail.com writes:
 On Aug 18, 12:30 pm, Elizabeth D Rather erat...@forth.com wrote:
[...]
 Mostly it had a snowball's chance because it was never picked up by
 the CS gurus who, AFAIK, never really took a serious look at it.

 Its quite possible that the criticism is unfair, but dont you think
 that in part some responsibility must be borne by your organization in
 not doing a good job of education ?
[snip]
 Show me on what page does it explain how Forth implements dynamic
 binding or lexical binding and takes care of the scope of definition
 of the nouns ?
[...]

Show me how this is relevant to comp.lang.c, comp.lang.c++, comp.theory,
or comp.lang.python.  Please trim the Newsgroups line.

-- 
Keith Thompson (The_Other_Keith) ks...@mib.org  http://www.ghoti.net/~kst
Nokia
We must do something.  This is something.  Therefore, we must do this.
-- Antony Jay and Jonathan Lynn, Yes Minister
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-18 Thread Elizabeth D Rather


On 8/18/10 2:23 PM, Standish P wrote:

On Aug 17, 6:38 pm, John Passanitijohn.passan...@gmail.com  wrote:


You asked if Forth borrowed lists from Lisp.  It did not.  In Lisp,
lists are constructed with pair of pointers called a cons cell.
That is the most primitive component that makes up a list.  Forth has
no such thing; in Forth, the dictionary (which is traditionally, but
not necessarily a list) is a data structure that links to the previous
word with a pointer.


Would you show me a picture, ascii art or whatever for Forth ? I know
what lisp lists look like so I dont need that for comparison. Forth
must have a convention and a standard or preferred practice for its
dicts. However, let me tell you that in postscript the dictionaries
can be nested inside other dictionaries and any such hiearchical
structure is a nested associative list, which is what linked list,
nested dictionaries, nested tables are.


You indicated that you have a copy of Forth Application Techniques. 
Sections 8.1 and 8.2 cover this topic, with some drawings.


Cheers,
Elizabeth

--
==
Elizabeth D. Rather   (US  Canada)   800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

Forth-based products and Services for real-time
applications since 1973.
==
--
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

On Aug 16, 4:20 am, Malcolm McLean malcolm.mcle...@btinternet.com
wrote:
 On Aug 16, 10:20 am, Standish P stnd...@gmail.com wrote: [Q] How far can 
 stack [LIFO] solve do automatic garbage collection and
  prevent memory leak ?

 Most programs can be written so that most of their memory allocations
 are matched by destructors at the same level.

 However the allocations that can't be written this way typically tend
 to be the small frequently-called ones used for nodes in dynamic graph
 objects, or small resizeable buffers to hold strings and the like.
 This is where you get the performance hit with repeated calls to
 malloc() and free().

 So generally it's not worthwhile writing a stack allocator for a
 normal program. That's not to say there aren't a few individual cases
 where it can help performance. (See the chapter Memory games in my
 book Basic Agorithms for details about memory allocation strategies).

all the page numbers in your books TOC have a little varying offset
from actual, pictures are nice for kids ..
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?


 Garbage collection doesn't use a stack. It uses a heap, which is in
 the abstract a collection of memory blocks of different lengths,
 divided into two lists, generally represented as linked lists:

 1.  A list of blocks that are free and may be used to store new data

 2.  A list of blocks that are in use, or haven't been freed (yet)

Is this all that a heap is or is there more to it ? I have been
looking for simple but complete explanation of heap for a while and
not gotten to it. I think I am looking for a stack allocation on the
same pattern. In a disk, a file is fragmented in many contiguous
blocks and is accessed automatically.

 There is no way you could do memory management of all but the most
 trivial and fixed-length data chunks using a stack. Sure, you could
 reserve thousands of bytes on the stack for an array but suppose your
 language allows arrays to grow or shrink. To keep its property of
 being adjacent, you'd have to do something horrible such as move
 unrelated data allocated later, which raises all sorts of security
 issues, doesn't it.


 A stack, or something which works like a stack (that is, a stack) is a
 necessary but not sufficient condition for a working C runtime because
 C functions can call themselves recursively, whether directly or
 indirectly. If this last condition did not obtain, each function could
 give the functions it calls some of its own memory and the called
 function could save a fixed set of non-stacked general registers in
 that area; this was in fact the practice on IBM 370 and in assembler
 language at a time when many data processing managers though
 recursion was a Communist plot.

 However, data structures of variable size, or data structures that
 merely take up a lot of space, don't play nice with others on the
 stack, so, we place their address on the stack and store them in
 another place, which was named the heap, probably, as a sort of
 witticism.

 Gilbert and Sullivan:

 If anyone anything lacks
 He'll find it all ready in stacks

This you might want to take this to the Forth people because they are
marketing their language as a cure for all that plagues programming
today.

 was wrong, and needs to be brought up to date:

 You cannot do everything in a stack
 Unless you code an almighty hack
 If you're a coding Knight who says, Neep,
 You'll probably need to implement a heap
 A pile a heap of benefits you'll reap
 If only my advice in your brain you'll keep
 And avoid memory leaks from which data doth seep
 By using a well-implemented, well structured, and well-documented
 Heap!

 [Chorus of Sailors]
 We will to heart your advice take, and always use a heap!

 [Soloist]
 Oh thank you do
 To this be true
 And always my sage advice do keep
 That you always need to use a heap!- Hide quoted text -

 - Show quoted text -

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

On Aug 16, 11:09 am, Elizabeth D Rather erat...@forth.com wrote:
 On 8/15/10 10:33 PM, Standish P wrote:


  If Forth is a general processing language based on stack, is it
  possible to convert any and all algorithms to stack based ones and
  thus avoid memory leaks since a pop automatically releases memory when
  free is an intrinsic part of it.

 Forth uses two stacks.  The data stack is used for passing parameters
 between subroutines (words) and is completely under the control of the
 programmer.  Words expect parameters on this stack; they remove them,
 and leave only explicit results.  The return stack is used primarily
 for return addresses when words are called, although it is also
 available for auxiliary uses under guidelines which respect the primary
 use for return addresses.

 Although implementations vary, in most Forths stacks grow from a fixed
 point (one for each stack) into otherwise-unused memory.  The space
 involved is allocated when the program is launched, and is not managed
 as a heap and allocated or deallocated by any complicated mechanism.  On
 multitasking Forth systems, each task has its own stacks.  Where
 floating point is implemented (Forth's native arithmetic is
 integer-based), there is usually a separate stack for floats, to take
 advantage of hardware FP stacks.

      - is forth a general purpose language? Yes
      - are all algorithms stack based? No

  Does Forth uses stack for all algorithms ? Does it use pointers , ie
  indirect addressing ? If it can/must use stack then every algorithm
  could be made stack based.

 Forth uses its data stack for parameter passing and storage of temporary
 values.  It is also possible to define variables, strings, and arrays in
 memory, in which case their addresses may be passed on the data stack.

 Forth is architecturally very simple.  Memory allocations for variables,
 etc., are normally static, although some implementations include
 facilities for heaps as needed by applications.

 although some implementations include facilities for heaps as needed by 
 applications.

How are these heaps being implemented ? Is there some illustrative
code or a book showing how to implement these heaps in C for example ?

Are dictionaries of forth and postscript themselves stacks if we
consider them as nested two column tables which lisp's lists are in
essence, but only single row. Multiple rows would just be multiple
instances of it at the same level inside parens.

we can peek into stacks which is like car. if it is not unusually
costly computation, why not allow it ? there is no need to restrict to
push and pop.

roll( stack_name, num)

itself can give all those postfix permutations that push and pop cant
generate with a single stack. Can we use dictionaries to generate
multiple stacks inside one global stack ?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-17 Thread James Kanze

On Aug 17, 6:21 pm, Standish P stnd...@gmail.com wrote:
  Garbage collection doesn't use a stack. It uses a heap,
  which is in the abstract a collection of memory blocks of
  different lengths, divided into two lists, generally
  represented as linked lists:

  1.  A list of blocks that are free and may be used to store
  new data

  2.  A list of blocks that are in use, or haven't been freed (yet)

 Is this all that a heap is or is there more to it ?

There are many different ways to implement a heap.  The above is
not a good one, and I doubt that it's really used anywhere.

 I have been looking for simple but complete explanation of
 heap for a while and not gotten to it.

Complete in what sense?  The basic principle of how to use it is
simple.  As for how to implement it, there are many different
algorithms that can be used.

 I think I am looking for a stack allocation on the same
 pattern.

Stack allocation is far, far simpler (usually).

 In a disk, a file is fragmented in many contiguous blocks and
 is accessed automatically.

At the system level, the same thing holds for memory, and the
actual physical memory is fragmented into contiguous blocks,
each the size of a page.  The MMU (hardware) makes this
transparent to user programs, however.

  There is no way you could do memory management of all but the most
  trivial and fixed-length data chunks using a stack.

The length isn't the issue.  The order of allocation and freeing
is.  (For many specific uses, stack based allocators can and
have been used, but they don't work for generally allocation.)

--
James Kanze
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

On Aug 17, 1:17 am, torb...@diku.dk (Torben Ægidius Mogensen) wrote:
 Standish P stnd...@gmail.com writes:
  [Q] How far can stack [LIFO] solve do automatic garbage collection and
  prevent memory leak ?

  Because a stack has push and pop, it is able to release and allocate
  memory. We envisage an exogenous stack which has malloc() associated
  with a push and free() associated with a pop.

 See

How many programmers have applied the ideas of these papers in their
programming practice ? I paste the abstract for convenience

 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.23.5498

Abstract:
This paper describes a memory management discipline for programs that
perform dynamic memory allocation and de-allocation. At runtime, all
values are put into regions. The store consists of a stack of regions.
All points of region allocation and deallocation are inferred
automatically, using a type and effect based program analysis. The
scheme does not assume the presence of a garbage collector. The scheme
was first presented by Tofte and Talpin (1994); subsequently, it has
been tested in The ML Kit with Regions, a region-based, garbage-
collection free implementation of the Standard ML Core language, which
includes recursive datatypes, higher-order functions and updatable
references (Birkedal et al. 96, Elsman and Hallenberg 95). This paper
defines a region-based dynamic semantics for a skeletal programming
language extracted from Standard ML. We present the inference system
which specifies where regions can be allocated and de-allocated and a
detailed proof that the system is sound wi...


 http://portal.acm.org/citation.cfm?doid=174675.177855

ABSTRACT
We present a translation scheme for the polymorphically typed call-by-
value lgr;-calculus. All runtime values, including function closures,
are put into regions. The store consists of a stack of regions. Region
inference and effect inference are used to infer where regions can be
allocated and de-allocated. Recursive functions are handled using a
limited form of polymorphic recursion. The translation is proved
correct with respect to a store semantics, which models as a region-
based run-time system. Experimental results suggest that regions tend
to be small, that region allocation is frequent and that overall
memory demands are usually modest, even without garbage collection.


 http://www.springerlink.com/content/m2074884n6gt612h/


Abstract
We report on our experience with designing, implementing, proving
correct, and evaluating a region-based memory management system.
dynamic storage management - regions - Standard ML



         Torben

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-17 Thread Brad

On Aug 17, 10:34 am, Standish P stnd...@gmail.com wrote:
 On Aug 16, 11:09 am, Elizabeth D Rather erat...@forth.com wrote:

 How are these heaps being implemented ? Is there some illustrative
 code or a book showing how to implement these heaps in C for example ?

Forth does not use a heap, except maybe to implement malloc/free which
many Forth apps do not use. The dictionary is a linked list structure.
Now seems like a good time for you to teach yourself Forth (by
studying the best commercial implementation you can find) since you
seem to be working with a clean slate. But I will say a few things
about stacks in general.

There are many ways to implement stacks. The simplest is to declare
some space for the stack and then post-increment or pre-decrement a
stack pointer depending on whether you're pushing or popping. Normally
you make the memory for them big enough that they don't overflow.

If you are concerned about stack overflow you can change the
implementation. Add bounds checking, for example.

Another trick is to use an 8-bit stack pointer. Then you will have a
circular stack. If there is underflow or overflow it at least will not
step on other data. It will only return bad data, which you may find
preferable to an ugly crash. OTOH, bugs that cause spectacular
failures tend to be discovered. You can also initialize the stack
memory with a pattern like 0xDEAD and then after sufficiently
exercising the code, examine the memory contents to see the high
water mark of the stack pointer.

-Brad
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

On Aug 16, 12:20 am, Standish P stnd...@gmail.com wrote:
 [Q] How far can stack [LIFO] solve do automatic garbage collection and
 prevent memory leak ?

 Because a stack has push and pop, it is able to release and allocate
 memory. We envisage an exogenous stack which has malloc() associated
 with a push and free() associated with a pop.

 The algorithm using the stack would have to be perfect to prevent
 stack overflow or condition of infinite recursion depth. This would
 involve data type checking to filter out invalid input. The task must
 be casted in an algorithm that uses the stack. Then the algorithm must
 be shown to be heuristically or by its metaphor, to be correct using
 informal reasoning.

 Are there any standard textbooks or papers that show stacks
 implemented in C/C++/Python/Forth with malloc/free in push and pop ?
 If Forth is a general processing language based on stack, is it
 possible to convert any and all algorithms to stack based ones and
 thus avoid memory leaks since a pop automatically releases memory when
 free is an intrinsic part of it.

 KR ANSI has the example of modular programming showing how to
 implement a stack but he uses a fixed length array. It is also
 possibly an endogenous stack. We look for an exogenous stack so that
 element size can vary.

 ===
 Standish P stnd...@gmail.com

Another way to pose my question, as occurred to me presently is to ask
if a stack is a good abstraction for programming ? Certainly, it is
the main abstraction in Forth and Postscript and implementable readily
in C,C++ and I assume python.

It is true that the other languages such as F/PS also have borrowed
lists from lisp in the name of nested-dictionaries and mathematica
calls them nested-tables as its fundamental data structure.

I am asking for a characterization of algorithms that benefit from
this abstraction or programming paradigm and comparison with others.

The whole case of OOP is the clustering of thought, ie book-keeping,
in the mind of the programmer around fewer objects than ten or twenty
fold functions.

so the name of the game is the same, ie to help the programmer keep
track of things for writing fault free code without chasing every
case, easy visualization, easy recall and communication with fellow
programmers of abstract concepts in terms of real world objects and
easy modification and code reuse.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-17 Thread John Kelly

On Tue, 17 Aug 2010 11:53:27 -0700 (PDT), Standish P stnd...@gmail.com
wrote:

Another way to pose my question, as occurred to me presently is to ask
if a stack is a good abstraction for programming ? Certainly, it is
the main abstraction in Forth and Postscript and implementable readily
in C,C++ and I assume python.

so the name of the game is the same, ie to help the programmer keep
track of things for writing fault free code without chasing every
case, easy visualization, easy recall and communication with fellow
programmers of abstract concepts in terms of real world objects and
easy modification and code reuse.


Go is an attempt to combine the ease of programming of an interpreted,
dynamically typed language with the efficiency and safety of a
statically typed, compiled language. It also aims to be modern, with
support for networked and multicore computing

To make the stacks small, Go's run-time uses segmented stacks. A newly
minted goroutine is given a few kilobytes, which is almost always
enough. When it isn't, the run-time allocates (and frees) extension
segments automatically

http://golang.org/doc/go_lang_faq.html



-- 
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

2010-08-17 Thread John Passaniti

On Aug 17, 2:53 pm, Standish P stnd...@gmail.com wrote:
 Another way to pose my question, as occurred to me presently is
 to ask if a stack is a good abstraction for programming ?
 Certainly, it is the main abstraction in Forth and Postscript
 and implementable readily in C,C++ and I assume python.

A stack is a fine abstraction for some kinds of programming.  It fails
for others.  In languages where functions are first-class entities
that can be stored and passed around like any other kind of data,
stacks can be problematic because a function can out-live the stack
frame they were created in.

 It is true that the other languages such as F/PS also have borrowed
 lists from lisp in the name of nested-dictionaries and mathematica
 calls them nested-tables as its fundamental data structure.

No.

 The whole case of OOP is the clustering of thought, ie book-keeping,
 in the mind of the programmer around fewer objects than ten or twenty
 fold functions.

That's one view of OOP.  It's not the only one.

 so the name of the game is the same, ie to help the programmer keep
 track of things for writing fault free code without chasing every
 case, easy visualization, easy recall and communication with fellow
 programmers of abstract concepts in terms of real world objects and
 easy modification and code reuse.

You, like probably everyone else who has thought about how to
simplify languages will eventually end up at the same place-- you'll
have a model that meets your objectives, but with some programmers
will find is unnecessarily limiting.  More importantly, you'll run
into some classes of problems for which your simple model makes things
inordinately complicated relative to what other languages and
paradigms offer.

Here's a better idea:  Become familiar with the languages you've
cited, and more.  I would recommend Forth, Lisp, Smalltalk or Ruby,
Lua or JavaScript.  Learn each and then come back and tell us if you
think limiting the programmer to objects with stack-ordered lifetimes
is enough.  Oh, and while you're at it, dip your toes into a problem
domain you don't normally do any work in.  If you're an embedded
systems guy, then spend some time writing a non-trivial web
application.  Go outside your comfort zone and find a problem domain
where cherished idioms and tools no longer apply.  I think it will
open your eyes.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

On Aug 17, 12:32 pm, John Passaniti john.passan...@gmail.com wrote:
 On Aug 17, 2:53 pm, Standish P stnd...@gmail.com wrote:

  Another way to pose my question, as occurred to me presently is
  to ask if a stack is a good abstraction for programming ?
  Certainly, it is the main abstraction in Forth and Postscript
  and implementable readily in C,C++ and I assume python.

 A stack is a fine abstraction for some kinds of programming.  It fails
 for others.  In languages where functions are first-class entities
 that can be stored and passed around like any other kind of data,
 stacks can be problematic because a function can out-live the stack
 frame they were created in.

  It is true that the other languages such as F/PS also have borrowed
  lists from lisp in the name of nested-dictionaries and mathematica
  calls them nested-tables as its fundamental data structure.

 No.

you are contradicting an earlier poster from forth who admitted the
part on dicts.


  The whole case of OOP is the clustering of thought, ie book-keeping,
  in the mind of the programmer around fewer objects than ten or twenty
  fold functions.

 That's one view of OOP.  It's not the only one.

and what can you add to enlighten the readers on the other view ?


  so the name of the game is the same, ie to help the programmer keep
  track of things for writing fault free code without chasing every
  case, easy visualization, easy recall and communication with fellow
  programmers of abstract concepts in terms of real world objects and
  easy modification and code reuse.

 You, like probably everyone else who has thought about how to
 simplify languages will eventually end up at the same place-- you'll
 have a model that meets your objectives, but with some programmers
 will find is unnecessarily limiting.  More importantly, you'll run
 into some classes of problems for which your simple model makes things
 inordinately complicated relative to what other languages and
 paradigms offer.

The objective is to discuss those cases via specific examples (not
generalities), and talk ABOUT them, not AROUND them.

 Here's a better idea:  

Its a very fine wild goose chase project statement.

 Become familiar with the languages you've
 cited, and more.  I would recommend Forth, Lisp, Smalltalk or Ruby,
 Lua or JavaScript.  Learn each and then come back and tell us if you
 think limiting the programmer to objects with stack-ordered lifetimes
 is enough.  Oh, and while you're at it, dip your toes into a problem
 domain you don't normally do any work in.  If you're an embedded
 systems guy, then spend some time writing a non-trivial web
 application.  Go outside your comfort zone and find a problem domain
 where cherished idioms and tools no longer apply.  I think it will
 open your eyes.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?