yade-dev team mailing list archive

[Janek Kozicki <janek_listy@xxxxx>]

Václav S(milauer said:     (by the date of Wed, 26 Nov 2008 23:12:56 +0100)

> 
> > After you commit, the "primary view" window is empty (draws nothing),
> > but when I click "New 3D" view - the new window draws everything as
> > it should. Can you fix that?
> >   
> I am not aware of changing anything related to the 3d view lately. Can
> you precise?

Well, I'm sure that it happened only after I did 'svn up', and see
commit history. I did svn up from my 1582 to your 1583. It's not too
annoying though, it's enough if I close the automatically opened
3dview and reopen a new one.

And (of course) it' doesn't happen always. But it never happened
before. To reproduce this, just start GUI, generate something and let
it automatically open the controller. The 3dview will be empty. Even
'a','g' will not work for toggling axis/grid.



> There is more things I would like to change in yade globally (besides
> serialization), so I think I will try to develop a working prototype
> from scratch (using existing classes here and there). 

yes, this is exactly what sometimes I dream about doing. But I don't
think I'll ever have time for that.....


> What I would like
> to address specifically is:
> 
> 1. Use shared_ptr only if necessary, it has some performance penalties.
> It would be enough if the owner (Body, Interaction, ...) used auto_ptr
> to avoid leaks. If the owned object is used after the owner has been
> destroyed (which is OK with shared_ptr, but will crash with auto_ptr),
> it is a bug anyway.
> 2. Better and faster python support, be it through py++ wrapper or other
> option, but _not_ by using conversions from and to strings.
> 3. Better serialization, if possible automatically getting attributes to
> save (needs reflection - for example reflex library from CERN's root; if
> we have that, most macros in class declarations can be avoided).
> 4. Experiment with multimethods, if it would not be faster to have
> hardwired if/else if/else if/... clauses for a few combinations rather
> than completely generic solution. I know it defeats genericity, but it
> is a compromise to consider.
> 5. Experiment with pluginless build and whether plugins should be
> supported. The current state is that I know of exactly 0 cases that
> external plugin was built and used with yade compiled elsewhere. (oofem,
> for example, is a single binary, and is still very modular)
> 6. Use some neat features from c++0x (future; g++ doesn't support those
> as of now)
> 7. Use new (or better than those new) class names, have less files, less
> management code, more real code that does something.


your ideas are good. Almost each of them is a great deal of work.

I can tell you that multimethods won't get faster with your approach.
Linear access time to read a function pointer in a table *is* a
linear time. With if/else you are getting logarithmic time. If
logarithmic time is faster than linear in case if there are only a
few choices - honestly I don't know. But it's not worth the effort to
check that. So that one I'd skip.

But if you want to try that anyway, there's an exact copy/paste
implementation of that in "Modern C++ Design" book by Andrei
Alexandrescu.


-- 
Janek Kozicki                                                         |