Barry
> Cc: MRAB ; Python-list@python.org
> Subject: Re: Why I fail so bad to check for memory leak with this code?
>
> On Fri, 22 Jul 2022 at 09:00, Barry wrote:
> > With code as complex as python’s there will be memory allocations that
> occur that will not be directly re
nal of a memory leak is very clear, as you noticed.
>
> For rare leaks I would use a tool like valgrind.
Thank you all, but I needed a simple decorator to automatize the memory
leak (and segfault) tests. I think that this version is good enough, I hope
that can be useful to someone:
def
that will not be directly related to the python code you test.
To put it another way there is noise in your memory allocation signal.
Usually the signal of a memory leak is very clear, as you noticed.
For rare leaks I would use a tool like valgrind.
Barry
> --
> https://mail.python.org/
On 21/07/2022 23:39, Marco Sulla wrote:
I've done this other simple test:
#!/usr/bin/env python3
import tracemalloc
import gc
import pickle
tracemalloc.start()
snapshot1 = tracemalloc.take_snapshot().filter_traces(
(tracemalloc.Filter(True, __file__), )
)
for i in range(1000):
pi
I've done this other simple test:
#!/usr/bin/env python3
import tracemalloc
import gc
import pickle
tracemalloc.start()
snapshot1 = tracemalloc.take_snapshot().filter_traces(
(tracemalloc.Filter(True, __file__), )
)
for i in range(1000):
pickle.dumps(iter([]))
gc.collect()
snapsh
This naif code shows no leak:
import resource
import pickle
c = 0
while True:
pickle.dumps(iter([]))
if (c % 1) == 0:
max_rss = resource.getrusage(resource.RUSAGE_SELF).ru_maxrss
print(f"iteration: {c}, max rss: {max_rss} kb")
c += 1
--
https://mail.python.org/
On Thu, 21 Jul 2022 at 22:28, MRAB wrote:
>
> It's something to do with pickling iterators because it still occurs
> when I reduce func_76 to:
>
> @trace
> def func_76():
> pickle.dumps(iter([]))
It's too strange. I found a bunch of true memory leaks with this
decorator. It seems to be relia
On 21/07/2022 20:47, Marco Sulla wrote:
I tried to check for memory leaks in a bunch of functions of mine using a
simple decorator. It works, but it fails with this code, returning a random
count_diff at every run. Why?
import tracemalloc
import gc
import functools
from uuid import uuid4
import
I tried to check for memory leaks in a bunch of functions of mine using a
simple decorator. It works, but it fails with this code, returning a random
count_diff at every run. Why?
import tracemalloc
import gc
import functools
from uuid import uuid4
import pickle
def getUuid():
return str(uuid
Pasha Stetsenko wrote at 2020-10-23 11:32 -0700:
> ...
> static int my_init(PyObject*, PyObject*, PyObject*) { return 0; }
> static void my_dealloc(PyObject*) {}
I think, the `dealloc` function is responsible to actually
free the memory area.
I see for example:
static void
Spec_dealloc(Spec* se
Thanks MRAB, this was it.
I guess I was thinking about tp_dealloc as a C++ destructor, where the base
class' destructor is called automatically.
On Fri, Oct 23, 2020 at 11:59 AM MRAB wrote:
> On 2020-10-23 19:32, Pasha Stetsenko wrote:
> > Thanks for all the replies!
> > Following Chris's advice
On 2020-10-23 19:32, Pasha Stetsenko wrote:
Thanks for all the replies!
Following Chris's advice, I tried to reduce the code to the smallest
reproducible example (I guess I should have done it sooner),
but here's what I came up with:
```
#include
#include
static int my_init(PyObject*,
n is open source, available at
https://github.com/h2oai/datatable, but the code I posted above is
completely independent from my library.
On Fri, Oct 23, 2020 at 10:44 AM Dieter Maurer wrote:
> Pasha Stetsenko wrote at 2020-10-22 17:51 -0700:
> > ...
> >I'm a maintainer of a
Pasha Stetsenko wrote at 2020-10-22 17:51 -0700:
> ...
>I'm a maintainer of a python library "datatable" (can be installed from
>PyPi), and i've been recently trying to debug a memory leak that occurs in
>my library.
>The program that exposes the leak is quite s
> On Oct 22, 2020, at 5:51 PM, Pasha Stetsenko wrote:
>
> Dear Python gurus,
>
> I'm a maintainer of a python library "datatable" (can be installed from
> PyPi), and i've been recently trying to debug a memory leak that occurs in
> my library.
>
On Fri, Oct 23, 2020 at 12:20 PM Pasha Stetsenko wrote:
> I'm currently not sure where to go from here. Is there something wrong with
> my python object that prevents it from being correctly processed by the
> Python runtime? Because this doesn't seem to be the usual case of
> incrementing the ref
Dear Python gurus,
I'm a maintainer of a python library "datatable" (can be installed from
PyPi), and i've been recently trying to debug a memory leak that occurs in
my library.
The program that exposes the leak is quite simple:
```
import datatable as dt
import gc # just in
Bartosz Golaszewski schrieb am 24.07.2018 um 13:05:
> Ok I've found the problem and it's my fault. From tp_dealloc's documentation:
>
> ---
> The destructor function should free all references which the instance
> owns, free all memory buffers owned by the instance (using the freeing
> function co
2018-07-24 13:30 GMT+02:00 Bartosz Golaszewski :
> 2018-07-24 12:09 GMT+02:00 Bartosz Golaszewski :
>> 2018-07-23 21:51 GMT+02:00 Thomas Jollans :
>>> On 23/07/18 20:02, Bartosz Golaszewski wrote:
>>>> Hi!
>>>
>>> Hey!
>>>
>>>> A
2018-07-24 12:09 GMT+02:00 Bartosz Golaszewski :
> 2018-07-23 21:51 GMT+02:00 Thomas Jollans :
>> On 23/07/18 20:02, Bartosz Golaszewski wrote:
>>> Hi!
>>
>> Hey!
>>
>>> A user recently reported a memory leak in python bindings (C extension
>>&g
2018-07-23 21:51 GMT+02:00 Thomas Jollans :
> On 23/07/18 20:02, Bartosz Golaszewski wrote:
>> Hi!
>
> Hey!
>
>> A user recently reported a memory leak in python bindings (C extension
>> module) to a C library[1] I wrote. I've been trying to fix it since
>&
On 23/07/18 20:02, Bartosz Golaszewski wrote:
> Hi!
Hey!
> A user recently reported a memory leak in python bindings (C extension
> module) to a C library[1] I wrote. I've been trying to fix it since
> but so far without success. Since I'm probably dealing with a space
>
Hi!
A user recently reported a memory leak in python bindings (C extension
module) to a C library[1] I wrote. I've been trying to fix it since
but so far without success. Since I'm probably dealing with a space
leak rather than actual memory leak, valgrind didn't help much even
wh
Mayling ge wrote:
> Sorry. The code here is just to describe the issue and is just pseudo
> code,
That is the problem with your post. It's too vague for us to make sense of
it.
Can you provide a minimal example that shows what you think is a "memory
leak"? Then w
Mayling ge
Sent: Tuesday, July 4, 2017 9:01 AM
To: python-list
Subject: memory leak with re.match
Hi,
My function is in the following way to handle file line by line.
There are
multiple error patterns defined and need to apply to each line.
I use
From: Python-list on
behalf of Mayling ge
Sent: Tuesday, July 4, 2017 9:01 AM
To: python-list
Subject: memory leak with re.match
Hi,
My function is in the following way to handle file line by line. There are
multiple error patterns defined and need to apply to each line. I
Thanks. I actually comment out all handling code. The loop ends with the
re_pat.match and nothing followed.
Sent from Mail Master
On 07/05/2017 08:31, [1]Cameron Simpson wrote:
On 04Jul2017 17:01, Mayling ge wrote:
> My function is in the following way to handle file lin
On 04Jul2017 17:01, Mayling ge wrote:
My function is in the following way to handle file line by line. There are
multiple error patterns defined and need to apply to each line. I use
multiprocessing.Pool to handle the file in block.
The memory usage increases to 2G for a 1G file. A
the file processing. File closed in the end.
If I comment out the call to re_pat.match, memory usage is normal and
keeps under 100Mb.
am I using re in a wrong way? I cannot figure out a way to fix the memory
leak. And I googled .
def line_match(lines, errors)
for
On Wed, May 28, 2014 at 5:56 AM, Neal Becker wrote:
> I'm trying to track down a memory leak in a fairly large code. It uses a lot
> of
> numpy, and a bit of c++-wrapped code. I don't yet know if the leak is purely
> python or is caused by the c++ modules.
Somethi
I'm trying to track down a memory leak in a fairly large code. It uses a lot
of
numpy, and a bit of c++-wrapped code. I don't yet know if the leak is purely
python or is caused by the c++ modules.
At each iteration of the main loop, I call gc.collect()
If I then look at gc.garb
Turns out one of the libraries I am using has a cache system. If I shut if off
then my problem goes away...
On Saturday, May 3, 2014 7:15:59 AM UTC-6, ptb wrote:
> Hello all,
>
>
>
> I'm using Python 3.4 and am seeing the memory usage of my program grow
> unbounded. Here's a snippet of the
Hello all,
I'm using Python 3.4 and am seeing the memory usage of my program grow
unbounded. Here's a snippet of the loop driving the main computation
opt_dict = {'interior':cons_dict['int_eq'],'lboundary':cons_dict['lboundary'],
'rboundary':cons_dict['rboundary'],
'mate
On 2012-6-2 18:53, Diez B. Roggisch wrote:
Python does some special things that confuse valgrind. Don't bother.
http://svn.python.org/projects/python/trunk/Misc/README.valgrind
Thanks for the link.
It clears a lot of my confusing, such as uninitialized reading...
--
WQ
--
http://mail.python.
Qi writes:
> Hi guys,
>
> Is there any known memory leak problems, when embed Python 2.7.3
> in C++?
> I Googled but only found some old posts.
>
> I tried to only call Py_Initialize() and Py_Finalize(), nothing else
> between those functions, Valgrind still reports
On 2012-5-29 23:29, Ulrich Eckhardt wrote:
Call the pair of functions twice, if the reported memory leak doesn't
increase, there is no problem. I personally wouldn't even call this a
leak then, but that depends a bit on the precise definition.
I should still call it a memory leak
Am 29.05.2012 16:37, schrieb Qi:
> I tried to only call Py_Initialize() and Py_Finalize(), nothing else
> between those functions, Valgrind still reports memory leaks
> on Ubuntu?
Call the pair of functions twice, if the reported memory leak doesn't
increase, there is no problem
Hi guys,
Is there any known memory leak problems, when embed Python 2.7.3
in C++?
I Googled but only found some old posts.
I tried to only call Py_Initialize() and Py_Finalize(), nothing else
between those functions, Valgrind still reports memory leaks
on Ubuntu?
Is that a know problem? Did
On 5/17/2012 5:50 AM, Alain Ketterlin wrote:
gry writes:
sys.version --> '2.6 (r26:66714, Feb 21 2009, 02:16:04) \n[GCC 4.3.2
[gcc-4_3-branch revision 141291]]
I thought this script would be very lean and fast, but with a large
value for n (like 15), it uses 26G of virtural memory, and
gry writes:
> sys.version --> '2.6 (r26:66714, Feb 21 2009, 02:16:04) \n[GCC 4.3.2
> [gcc-4_3-branch revision 141291]]
> I thought this script would be very lean and fast, but with a large
> value for n (like 15), it uses 26G of virtural memory, and things
> start to crumble.
>
> #!/usr/bin/
On Friday, 11 May 2012 22:29:39 UTC+1, gry wrote:
> sys.version --> '2.6 (r26:66714, Feb 21 2009, 02:16:04) \n[GCC 4.3.2
> [gcc-4_3-branch revision 141291]]
> I thought this script would be very lean and fast, but with a large
> value for n (like 15), it uses 26G of virtural memory, and things
On Sat, May 12, 2012 at 7:29 AM, gry wrote:
> f = open(sys.argv[1], 'w')
What are you passing as the file name argument? Could that device be
the cause of your memory usage spike?
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
sume any more virtual memory than
what is normally used by the Python interpreter. I suspect there is
something else at play here.
> What would be a better way to do this? (aside from checking arg
> values and types, I know...)
I don't see anything wrong with the way you're currently doing it,
assuming you can solve your memory leak issue.
Ian
--
http://mail.python.org/mailman/listinfo/python-list
sys.version --> '2.6 (r26:66714, Feb 21 2009, 02:16:04) \n[GCC 4.3.2
[gcc-4_3-branch revision 141291]]
I thought this script would be very lean and fast, but with a large
value for n (like 15), it uses 26G of virtural memory, and things
start to crumble.
#!/usr/bin/env python
'''write a file o
I have the same problem with python 2.6.2.
I have upgraded to 2.7.1 and the leak is gone.
--
http://mail.python.org/mailman/listinfo/python-list
On Jun 20, 3:50 pm, foobar wrote:
> Regarding adding a new logger for each thread - each thread represents
> a telephone call in a data collection system. I need to be able to
> cleanly provided call-loggingfor debugging to my programmers as well
> as dataloggingand verification; having a single
rites:
>
>
>
> > I've run across a memory leak in a long running process which I can't
> > determine if its my issue or if its the logger.
>
> BTW did you also ask this question on Stack Overflow? I've answered there,
> too.
>
> http://sta
foobar gmail.com> writes:
>
> I've run across a memory leak in a long running process which I can't
> determine if its my issue or if its the logger.
>
BTW did you also ask this question on Stack Overflow? I've answered there, too.
http://stackoverflow.com/quest
foobar gmail.com> writes:
> I've run across a memory leak in a long running process which I can't
> determine if its my issue or if its the logger.
As Chris Torek said, it's not a good idea to create a logger for each thread. A
logger name represents a place in your a
In article
foobar wrote:
>I've run across a memory leak in a long running process which I can't
>determine if its my issue or if its the logger.
You do not say what version of python you are using, but on the
other hand I do not know how much the logger code has evolved
I've run across a memory leak in a long running process which I can't
determine if its my issue or if its the logger.
The long and short is I'm doing load testing on an application server
which spawns handlers threads which in turn each spawn a single
application thread. A graphic
On Thu, 30 Sep 2010 04:06:03 -0700 (PDT)
Tom Conneely wrote:
> Thanks for your reply, you've given me plenty to think about
>
> On Sep 29, 11:51 pm, Antoine Pitrou wrote:
> >
> > > My original plan was to have the data processing and data acquisition
> > > functions running in separate processes
I'm posting this last message as I've found the source of my initial
memory leak problem, unfortunately it was an embarrassingly basic
mistake. In my defence I've got a horrible cold, but I'm just making
excuses.
I begin by mallocing the memory, which gives me a pointer
Thanks for your reply, you've given me plenty to think about
On Sep 29, 11:51 pm, Antoine Pitrou wrote:
>
> > My original plan was to have the data processing and data acquisition
> > functions running in separate processes, with a multiprocessing.Queue
> > for passing the raw data packets. The r
On Wed, 29 Sep 2010 06:50:05 -0700 (PDT)
Tom Conneely wrote:
>
> My original plan was to have the data processing and data acquisition
> functions running in separate processes, with a multiprocessing.Queue
> for passing the raw data packets. The raw data is read in as a char*,
> with a non const
I'm attempting to write a library for reading data via USB from a
device and processing the data to display graphs. I have already
implemented parts of this code as pure python, as a proof of concept
but I have now moved on to implementing the functions in a C
extension.
My original plan was to ha
On 27-Aug-2010, at 2:14 AM, Brad wrote:
> On Aug 25, 4:05 am, Alex McDonald wrote:
>> Your example of writing code with
>> memory leaks *and not caring because it's a waste of your time* makes
>> me think that you've never been a programmer of any sort.
>
> "Windows applications are immune from
On Aug 25, 4:05 am, Alex McDonald wrote:
> Your example of writing code with
> memory leaks *and not caring because it's a waste of your time* makes
> me think that you've never been a programmer of any sort.
"Windows applications are immune from memory leaks since programmers
can count on regula
On Aug 25, 4:01 pm, John Passaniti wrote:
> On Aug 25, 5:01 pm, Joshua Maurice wrote:
>
> > I agree. Sadly, with managers, especially non-technical
> > managers, it's hard to make this case when the weasel
> > guy says "See! It's working.".
>
> Actually, it's not that hard. The key to communicat
On Aug 25, 5:01 pm, Joshua Maurice wrote:
> I agree. Sadly, with managers, especially non-technical
> managers, it's hard to make this case when the weasel
> guy says "See! It's working.".
Actually, it's not that hard. The key to communicating the true cost
of software development to non-technic
John Passaniti writes:
> On Aug 24, 8:00 pm, Hugh Aguilar wrote:
>> 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://tinyurl.com/2bjwp7q]
>
> Hello to those ou
On Aug 25, 1:44 pm, John Passaniti wrote:
> On Aug 24, 9:05 pm, Hugh Aguilar wrote:
>
> > What about using what I learned to write programs that work?
> > Does that count for anything?
>
> It obviously counts, but it's not the only thing that matters. Where
> I'm employed, I am currently managin
On Aug 24, 9:05 pm, Hugh Aguilar wrote:
> What about using what I learned to write programs that work?
> Does that count for anything?
It obviously counts, but it's not the only thing that matters. Where
I'm employed, I am currently managing a set of code that "works" but
the quality of that cod
On Aug 24, 8:00 pm, Hugh Aguilar wrote:
> 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://tinyurl.com/2bjwp7q]
Hello to those outside of comp.lang.forth, where H
On 19 Aug, 16:25, c...@tiac.net (Richard Harter) wrote:
> On Wed, 18 Aug 2010 01:39:09 -0700 (PDT), Nick Keighley
> wrote:
> >On 17 Aug, 18:34, Standish P wrote:
> >> How are these heaps being implemented ? Is there some illustrative
> >> code or a book showing how to implement these heaps in C
Alex McDonald writes:
> Your example of writing code with
>memory leaks *and not caring because it's a waste of your time* makes
>me think that you've never been a programmer of any sort. Ever.
Well, I find his approach towards memory leaks as described in
<779b992b-7199-4126-bf3a-7ec40ea80...@j1
On 25 Aug, 01:00, Hugh Aguilar wrote:
> On Aug 24, 4:17 pm, Richard Owlett 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 desc
Hugh Aguilar writes:
> On Aug 24, 5:16 pm, Paul Rubin 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 wh
John Bokma 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 qui
Hugh Aguilar 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, exactl
Hugh Aguilar writes:
> On Aug 24, 5:16 pm, Paul Rubin 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 wh
On Aug 21, 10:57 pm, Steven D'Aprano 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
On Aug 24, 5:16 pm, Paul Rubin 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
Paul Rubin writes:
> Hugh Aguilar 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
Hugh Aguilar 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 checke
Hugh Aguilar wrote:
On Aug 24, 4:17 pm, Richard Owlett 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
On Aug 24, 4:17 pm, Richard Owlett 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, Fort
Hugh Aguilar writes:
> On Aug 22, 11:12 am, John Bokma 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
>>
On Aug 24, 9:24 am, David Kastrup 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
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 coll
On Aug 22, 11:12 am, John Bokma 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 lo
David Kastrup writes:
> John Bokma 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 eng
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 writes:
>
> > [...]
> > I really recommend that people spend a lot more time writing code,
> > and a lot less time with all of this pseudo-int
David Kastrup wrote:
John Bokma 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 th
John Bokma 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 o
On 24 Aug, 01:00, Hugh Aguilar wrote:
> On Aug 21, 12:32 pm, Alex McDonald 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 result
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
On Aug 21, 12:32 pm, Alex McDonald 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
Le Sun, 22 Aug 2010 20:12:36 +0200, John Bokma a
écrit:
David Kastrup writes:
John Bokma writes:
David Kastrup writes:
John Passaniti writes:
Amen! All this academic talk is useless. Who cares about things
like
the big-O notation for program complexity. Can't people just *l
David Kastrup writes:
> John Bokma writes:
>
>> David Kastrup writes:
>>
>>> John Passaniti 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?!
John Bokma writes:
> David Kastrup writes:
>
>> John Passaniti 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 o
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 un
On Aug 21, 3:36 am, David Kastrup 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
David Kastrup writes:
> John Passaniti 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 s
On 21 Aug, 17:58, Hugh Aguilar wrote:
> On Aug 21, 5:29 am, Alex McDonald wrote:
>
> > On 21 Aug, 06:42, 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 b
On Aug 21, 5:29 am, Alex McDonald wrote:
> On 21 Aug, 06:42, 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
On 21 Aug, 06:42, Standish P wrote:
> On Aug 20, 3:51 pm, Hugh Aguilar wrote:
>
>
>
> > On Aug 18, 6:23 pm, Standish P wrote:
>
> > > On Aug 17, 6:38 pm, John Passaniti wrote:
>
> > > > You asked if Forth "borrowed" lists from Lisp. It did not. In Lisp,
> > > > lists are constructed with pair
John Passaniti 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
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
On Aug 20, 3:51 pm, Hugh Aguilar wrote:
> On Aug 18, 6:23 pm, Standish P wrote:
>
>
>
>
>
> > On Aug 17, 6:38 pm, John Passaniti 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
1 - 100 of 365 matches
Mail list logo
