yade-dev team mailing list archive

[Václav S(milauer <eudoxos@xxxxxxxx>]

> 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?
> In my commit 1584 I'm adding some snow-related stuff. It's my files
> that I have been developing as a separate code in the past. That code
> is using boost::serialization. So I guess that this is time for
> adding to yade a dependency on boost serialiaztion (unless you
> exclude='snow'). I think that actually having "twice" serialization
> in whole yade isn't too difficult to add. Look at how I'm using it in
> my files, and you can start adding it too in other files.... if you want.
>   
Hmmm... I don't have exactly time to do that, but I will study your
code, it can surely be interesting.

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). 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.

My time is constrained, though, those are just a few ideas about things
that I find frustrating at times.

Regards, Vaclav