Re: Octave-maintainers Digest, Vol 7, Issue 7

[Muthiah Annamalai]

Hello John,
Great package. Didnt actually get to try it yet. The screenshots look 
really nice.

I have attached the error message I got while building the code on
GNU/Linux with Ubuntu. Am I doing something wrong?

Thanks,
-Muthu



On Wed, 2006-10-04 at 14:59 -0500, address@hidden
wrote:
> Send Octave-maintainers mailing list submissions to
>       address@hidden
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>       https://www.cae.wisc.edu/mailman/listinfo/octave-maintainers
> or, via email, send a message with subject or body 'help' to
>       address@hidden
> 
> You can reach the person managing the list at
>       address@hidden
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Octave-maintainers digest..."
> 
> 
> Today's Topics:
> 
>    1. octavede - a ide for octave (John Swensen)
>    2. Re: octavede - a ide for octave (Sebastien Loisel)
>    3. Re: octavede - a ide for octave (David Bateman)
>    4. download link on homepage for 2.9.9 (address@hidden)
>    5. Re: download link on homepage for 2.9.9 (David Bateman)
>    6. Re: download link on homepage for 2.9.9 (John W. Eaton)
>    7. More on interpreter speed (Quentin Spencer)
>    8. More on interpreter speed (John W. Eaton)
>    9. Re: More on interpreter speed (Tom Holroyd (NIH/NIMH) [E])
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 03 Oct 2006 21:46:14 -0400
> From: John Swensen <address@hidden>
> Subject: octavede - a ide for octave
> To: octave maintainers mailing list <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; format=flowed; charset=ISO-8859-1
> 
> I have been working on an IDE for octave for an hour or two a week for 
> the past 2 years or so.  Sometimes I have had stretches where little 
> progress is made, but I think there is enough in place to let everyone 
> know about it.  It is still probably pre-alpha, and now that I am a 
> first year grad student I haven't had much time for anything other than 
> classwork, but here it is none-the-less.
> 
> http://sourceforge.net/projects/octavede
> 
> I still don't have a web page up, just the project page and you will 
> have to retrieve the sources from subversion.  I have a few screenshots 
> up of what it looks like.  A while back I submitted a patch that had 
> essentially been written by someone else and JWE pointed me to it.  I 
> simply cleaned it up and made other changes the VTE maintainer wanted 
> and resubmitted.  In essence, it allows VTE to "swallow" up the PIDs of 
> child processes so there isn't a process shown for the IDE *and* for 
> octave, just one for the combination.
> 
> Currently the method for interacting with Octave in *not* thread safe.  
> I simply check to see if the interpreter isn't in a command and then 
> pull the history and variable information.  I haven't had it crash on me 
> a single time since I put multiple check in at different points to 
> determine whether the interpreter is in a command, but probability says 
> that I can guarantee it will happen at some point.  I did however run 
> the Octave2.m benchmark from sciviews.org with and without the IDE and 
> there was a 10 millisecond difference for the cumulative runtime, so I 
> think it is safe to say that the IDE doesn't add a lot of overhead.  One 
> of the main reasons I am posting to this list is to probe the waters 
> about adding some hooks into the interpreter such that after a command 
> returns to the top level or hits a break point that information queried 
> by the IDE can be pushed into some thread-safe object for later 
> retrieval by the IDE.
> 
> The editor still needs a lot of work, and I personally would like to 
> give it emacs key-bindings, or even just embed the Xemacs widget in a 
> window that is part of octavede.  If anyone is a GtkSourceView wizard, I 
> am not and could use help.
> 
> I don't have a good list of dependencies off hand, but you can look in 
> the configure.ac file for a list and any recent version of the autotools 
> will let you know the exact packages that are missing.  I have tested it 
> on x86 Ubuntu, PowerPC Mac, and IntelMac and they seem to work fine.  It 
> ran on cygwin/X11 with the GTK stuff from cygwinports a little while 
> back, but I don't have a Windows machine anymore, so I can't test it.
> 
> Any questions or comments can be sent to me directly or posted on the 
> sourceforge forums and I will try to answer them in a timely manner.
> 
> John Swensen
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Wed, 4 Oct 2006 04:17:03 +0200
> From: "Sebastien Loisel" <address@hidden>
> Subject: Re: octavede - a ide for octave
> To: "John Swensen" <address@hidden>
> Cc: octave maintainers mailing list <address@hidden>
> Message-ID:
>       <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Good job, John,
> 
> adding some hooks into the interpreter such that after a command
> > returns to the top level or hits a break point that information queried
> > by the IDE can be pushed into some thread-safe object for later
> > retrieval by the IDE.
> 
> 
> >From my own experience, this would in fact be a very good thing. Basically
> have an idle() function that gets called when the interpreter is in a safe
> state and stuff has changed.
> 
> S?bastien Loisel
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> https://www.cae.wisc.edu/pipermail/octave-maintainers/attachments/20061004/f6e0796d/attachment-0001.html
>  
> 
> ------------------------------
> 
> Message: 3
> Date: Wed, 04 Oct 2006 10:17:21 +0200
> From: David Bateman <address@hidden>
> Subject: Re: octavede - a ide for octave
> To: Sebastien Loisel <address@hidden>
> Cc: octave maintainers mailing list <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Sebastien Loisel wrote:
> > Good job, John,
> >
> >     adding some hooks into the interpreter such that after a command
> >     returns to the top level or hits a break point that information
> >     queried
> >     by the IDE can be pushed into some thread-safe object for later
> >     retrieval by the IDE.
> >
> >
> > From my own experience, this would in fact be a very good thing.
> > Basically have an idle() function that gets called when the
> > interpreter is in a safe state and stuff has changed.
> >
> > S?bastien Loisel
> >
> I think we'd all be happy to see the appropriate hooks added. The
> important thing is that the hooks are placed at the right point. I'd
> like to see that the IDE uses the octave history and readline facilities
> rather than have to reimplement these in an independent and probably
> incompatible manner. If one of you propose a set of hooks, we could
> review them and start on the path to actually getting them included...
> 
> D.
> 
> -- 
> David Bateman                                address@hidden
> Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
> Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
> 91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 
> 
> The information contained in this communication has been classified as: 
> 
> [x] General Business Information 
> [ ] Motorola Internal Use Only 
> [ ] Motorola Confidential Proprietary
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Wed, 4 Oct 2006 11:30:24 +0000 (GMT)
> From: "address@hidden" <address@hidden>
> Subject: download link on homepage for 2.9.9
> To: address@hidden
> Message-ID:
>       <address@hidden>
> Content-Type: text/plain;charset="iso-8859-15"
> 
> I've read that 2.9.9 is released, but the link is still on 2.9.8
> 
> Michel
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Wed, 04 Oct 2006 13:35:23 +0200
> From: David Bateman <address@hidden>
> Subject: Re: download link on homepage for 2.9.9
> To: address@hidden
> Cc: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-15
> 
> address@hidden wrote:
> > I've read that 2.9.9 is released, but the link is still on 2.9.8
> >
> > Michel
> >
> >   
> Also the front-page. The front-page item should include a comment that
> the order of the return argues for the system function have changed and
> the return type of the cellfun(@f,...) have changed for compatibility,
> as this might cause problems for some people.
> 
> Regards
> David
> 
> -- 
> David Bateman                                address@hidden
> Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
> Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
> 91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 
> 
> The information contained in this communication has been classified as: 
> 
> [x] General Business Information 
> [ ] Motorola Internal Use Only 
> [ ] Motorola Confidential Proprietary
> 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Wed, 4 Oct 2006 09:30:34 -0400
> From: "John W. Eaton" <address@hidden>
> Subject: Re: download link on homepage for 2.9.9
> To: David Bateman <address@hidden>
> Cc: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
> 
> On  4-Oct-2006, David Bateman wrote:
> 
> | address@hidden wrote:
> | > I've read that 2.9.9 is released, but the link is still on 2.9.8
> 
> I updated the page.
> 
> | Also the front-page. The front-page item should include a comment that
> | the order of the return argues for the system function have changed and
> | the return type of the cellfun(@f,...) have changed for compatibility,
> | as this might cause problems for some people.
> 
> There is now a news item.  I'll add a link to the NEWS file when we
> make the switch to "testing".
> 
> Thanks,
> 
> jwe
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Wed, 04 Oct 2006 09:49:39 -0500
> From: Quentin Spencer <address@hidden>
> Subject: More on interpreter speed
> To: octave maintainers mailing list <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> This may be of interest to those who have recently expressed interest in 
> finding ways of speeding up the interpreter. I was recently testing two 
> different ways of computing the same vector inside a function to see 
> which was fastest. My code was organized in the form:
> 
> tic
>   block A
> toc
> tic
>   block B
> toc
> 
> where blocks A and B compute the same thing in different ways, but using 
> some (not all) of the same intermediate variables. I was consistently 
> getting results that looked like this:
> Elapsed time is 0.025230 seconds.
> Elapsed time is 0.001198 seconds.
> 
> Having assumed that computation B was faster, I replaced block A with a 
> copy of what was in block B in the hope of further tweaking it. However, 
> running the function with both of the blocks being identical, I noticed 
> that I was still seeing the same large discrepancy in the times. I also 
> tested the same thing in Matlab. The first time I ran it I got this:
> Elapsed time is 0.003115 seconds.
> Elapsed time is 0.000627 seconds.
> 
> All subsequent times I ran it, I got something more like this:
> Elapsed time is 0.000481 seconds.
> Elapsed time is 0.000433 seconds.
> 
> This was quite unexpected. I am used to getting faster results on the 
> second run after a function has been loaded into memory, but this 
> doesn't explain why octave consistently runs a block of code inside a 
> function faster the second time than the first time. To me this looks 
> like maybe octave is freeing the memory used for internal variables when 
> it exits a function, and maybe Matlab is somehow holding onto it. Is my 
> assessment correct? The most involved octave/matlab scripts I run 
> usually involve many repeated calls to the same functions with similar 
> parameters, so that keeping memory allocated for a subsequent call to 
> the same function in this way would essentially gain me a 5x speedup in 
> execution time. I'm sure this is fairly common among other users who do 
> large computation as well. Assuming my guesses about what is going on 
> here are correct, how difficult would it be to modify octave's approach 
> to memory management? What possible negative consequences could result?
> 
> Quentin
> 
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Wed, 4 Oct 2006 11:15:50 -0400
> From: "John W. Eaton" <address@hidden>
> Subject: More on interpreter speed
> To: Quentin Spencer <address@hidden>
> Cc: octave maintainers mailing list <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
> 
> On  4-Oct-2006, Quentin Spencer wrote:
> 
> | This may be of interest to those who have recently expressed interest in 
> | finding ways of speeding up the interpreter. I was recently testing two 
> | different ways of computing the same vector inside a function to see 
> | which was fastest. My code was organized in the form:
> | 
> | tic
> |   block A
> | toc
> | tic
> |   block B
> | toc
> | 
> | where blocks A and B compute the same thing in different ways, but using 
> | some (not all) of the same intermediate variables. I was consistently 
> | getting results that looked like this:
> | Elapsed time is 0.025230 seconds.
> | Elapsed time is 0.001198 seconds.
> 
> This could just be a bug.  Can you post a complete example that
> demonstrates the problem?
> 
> jwe
> 
> 
> ------------------------------
> 
> Message: 9
> Date: Wed, 04 Oct 2006 15:58:42 -0400
> From: "Tom Holroyd (NIH/NIMH) [E]" <address@hidden>
> Subject: Re: More on interpreter speed
> Cc: octave maintainers mailing list <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> It's also worth pointing out that cputime is more accurate, and that if you 
> use the form
> 
>       [t, u, s] = cputime();
> 
> then you can distinguish between time spent in the OS (s) and time spent in 
> Octave (u).
> Might be useful to do that here.
> 
> John W. Eaton wrote:
> > On  4-Oct-2006, Quentin Spencer wrote:
> > 
> > | This may be of interest to those who have recently expressed interest in 
> > | finding ways of speeding up the interpreter. I was recently testing two 
> > | different ways of computing the same vector inside a function to see 
> > | which was fastest. My code was organized in the form:
> > | 
> > | tic
> > |   block A
> > | toc
> > | tic
> > |   block B
> > | toc
> > | 
> > | where blocks A and B compute the same thing in different ways, but using 
> > | some (not all) of the same intermediate variables. I was consistently 
> > | getting results that looked like this:
> > | Elapsed time is 0.025230 seconds.
> > | Elapsed time is 0.001198 seconds.
> > 
> > This could just be a bug.  Can you post a complete example that
> > demonstrates the problem?
> > 
> > jwe
>

error_text.txt
Description: Text document