Testers please

[martien friedeman]

I have written this tool that allows you to look at runtime data and
code at the same time.
And now I need people to test it.

The easiest way to see what I mean is to look at some videos:

http://codeinvestigator.googlepages.com/codeinvestigator_videos

It requires Apache and Sqlite.

It works for me with a Firefox browser on Linux.

[azrael]

Re: Testers please

I took a first look on the video. Amazing. I love it. You got a tester

good job, man

// but one thing, why not zope and postgre?


martien friedeman je napisao/la:

I have written this tool that allows you to look at runtime data and
code at the same time.
And now I need people to test it.
>
The easiest way to see what I mean is to look at some videos:

http://codeinvestigator.googlepages.com/codeinvestigator_videos

>
It requires Apache and Sqlite.
>
It works for me with a Firefox browser on Linux.

[James Stroud]

Re: Testers please

martien friedeman wrote:

I have written this tool that allows you to look at runtime data and
code at the same time.
And now I need people to test it.
>
The easiest way to see what I mean is to look at some videos:

http://codeinvestigator.googlepages.com/codeinvestigator_videos

>
It requires Apache and Sqlite.
>
It works for me with a Firefox browser on Linux.

Amazing!

[stef]

Re: Testers please

martien friedeman wrote:

I have written this tool that allows you to look at runtime data and
code at the same time.
And now I need people to test it.
>
The easiest way to see what I mean is to look at some videos:

http://codeinvestigator.googlepages.com/codeinvestigator_videos

>
It requires Apache and Sqlite.
>
It works for me with a Firefox browser on Linux.

Great idea !
Especially for newbies, so you've to make sure it's always in the "first
starters package".

As most modern code-editors, already support context sensitive popup's,
can't you make a module that can be added to any editor ?

a few other suggestions
- for large datasets, display only the "corner" values
- for loops, also only display the "corner" values
- to decrease datasize enormuous, limit the functionality to a piece of
code selected by the user
- get rid of Apache and SQLite, too complicated for newbies

keep on the good work,
cheers,
Stef Mientki

[fridrikm@gmail.com]

Re: Testers please

On Feb 13, 1:38 am, martien friedeman <martien.friede ...@gmail.com>
wrote:

I have written this tool that allows you to look at runtime data and
code at the same time.
And now I need people to test it.
>
The easiest way to see what I mean is to look at some videos:http://codeinvestigator.googlepages....tigator_videos
>
It requires Apache and Sqlite.
>
It works for me with a Firefox browser on Linux.

I'm absolutely stunned. This is a great idea, especially because we
all hate learning other people's code, and this makes the process so
much easier.

Got some exams coming up this week, but I'll do some testing in the
weekend.

I'd like to suggest one thing though. When evaluating conditional
statements, it would be very useful to see what "else" meant in terms
of the statement itself, for example:

if foo == 1:
# Instead of showing "true" this would show "foo == 1"
elif foo == 2:
# This would show "foo == 2"
else:
# Instead of showing "false". Here comes the tricky part. This
should show the opposite of "foo == 1", as well as the following elif
statements. So in this case, the tab could show "not (foo == 1) |
(foo == 2)".

The reason for why showing the negated else in the header (looking for
a better word, this refers to the header shown when you click
something) would be helpful is because it helps keep track of what
statements are being evaluated, since "False" gives no information on
what statment is being tested and if the code is long, you have to
scroll way up to take a look at the if statement, so it will help a
lot with complex code.

While this is not hard to implement (unless I'm missing something),
the implementation has some problems, because conditional statements
can become very long, the else statement's tab could show an
exceptionally long statement whereas showing just "False" keeps it at
a fair length.

I might be missing something in this suggestion though - if so, please
set me straight.

At any rate, I think you've done a great job on this. When I get
around to testing it this weekend I'll post the results on the
project's SourceForge forums.

Regards,
Friðrik Már

[azrael]

Re: Testers please

it would be nice when someone would paste some instructions or
tutorial how to bound it all together. where to paste the file. a
dummy tutorial if possible.

[Martien Friedeman]

Re: Testers please

Thanks for getting involved. And kind remarks.

The labeling of 'false' and 'true' is just for shortness sake.
The condition itself could be quite a mess and span several lines. You
mentioned that.
The only reason I like to display it, is to show whether a
block of coding, the colored bit, is performed or not.

Without that you would find out anyway; nothing becomes underlined
when you move your mouse in that area: Nothing in that area is
interactive. Because nothing happened there.

Even when the condition itself shows on the tab, not just the outcome, the
user would still need to scroll up to that tab if it was not visible.

The user interface is in HTML, maybe a tooltip when one moves the cursor
over a colored condition block could show up that shows the condition and
its value.
I hate them tooltips though. They make the whole interface so jumpy.

More work in that area needed then.

[Martien Friedeman]

Re: Testers please

Thanks Stef!

I looked at that area of storing large structures. That would seriously
make the whole thing much more complicated.

Say you have object 'foo' and it has lots of attributes.

If you're only accessing foo.length in the statement

'if foo.length 12:'

why should I store everything about foo? Its 'length' is the only
attribute accessed, therefore I only store its 'length'.
And therefore you can not click on 'foo', only on 'length'.
No video shows such an example though.

On the other hand if you had the statement

'if foo:'

then 'foo' would be able to be clicked, and it would say '<__main__.Foo
instance ... etc. The usual. No attributes though.

The interface is web based; I was going to make it as universal as
possible. The web server is required to do the Ajax thing and display
pages. Makes it harder to install too, unfortunately.

The size of the 'recording' is a major drawback, it was clearly not meant
to record the processing of millions of records.

I need to find a way to specify the area in the code that needs recording.

Thanks for the suggestions.

[Scott David Daniels]

Re: Testers please

Martien Friedeman wrote:

The size of the 'recording' is a major drawback, it was clearly not meant
to record the processing of millions of records.
>
I need to find a way to specify the area in the code that needs recording.

Use something like zlib and write a compressed log -- especially
with logs you are working with highly compressible data. The gzip
module can be used to easily write to it on the fly (incrementally) .
You'll find with very little effort you'll get very good compression.
Recently I saw a set of standard logs, not designed for any compression,
showing a factor of 9 compression -- that is, I was seeing less than
a single bit required per byte in the original.

--
--Scott David Daniels
scott.daniels@a cm.org

[Martien Friedeman]

Re: Testers please

Thanks for that for that Scott.
Most of hassle is storing the program flow.

For example:
Iteration 3 of the loop starting on line 12 has itself a loop on line 15
that has 14 iterations.
Iteration 4 of the loop starting on line 12 has a completely different set
of iterations for the loop on line 15. If at all(!)

All that is stored in a tree which I pickle and write to the database.

Massive program runs will create large trees.
And this pickling is expensive.