yade-users team mailing list archive

[Janek Kozicki <cosurgi@xxxxxxxxx>]

Vaclav SMILAUER said:     (by the date of Mon, 06 Nov 2006 12:13:24 +0100)

quick summary: use g++ 3.3.5, 3.3.6 or maybe 4.0 for today.
 

> Hello, thanks a lot for you 4hedra stuff. I will read it at the same 
> time as running it, which is not yet here.
> 
> A few comments on the current trunk:
> 
> 1. 
> yade-libs/yade-lib-serialization/src/yade-lib-serialization/ContainerHandler.tpp:109 
> comment the line (begins findType(...)): gives compile error and it is 
> not used anyways. (current svn trunk , i.e. 1004)

Yes, I know that it does not compile with g++ 4.1 (4.0 maybe works) for
that reason I'm currently using g++ 3.3.5

I'm working on fixing that, and I already have a solution (it is
in /snippets/trunk/Serialization-and-boost in SVN), I just need time
to implement this in yade. But currently you must use older
compiler :( 3.3.6 will work too.

findType *is* used. As a template method in serialization. But its use
is so convoluted that you will have hard time tracking it down. The
solution that I have is to get rid of findType totally. But until I
fix it, that findType is necessary, otherwise you will have problems with
loading/saving data.

> 2. Preferences loading works in a bizzare way; I have to add plugin 
> directories manually to preferences->dynlibDirectories in 
> Omega::scanPlugins. (otherwise, a 1-item list (directory "") is read 
> back from the XML file). Then yade crashes.

loading/saving configuration is not working because of missing findType.

> Right now recompiling with 
> -ggdb3 to run it in gdb. Will report later on. Could you BTW flag in 
> some way what revisions in the svn are buildable/runnable (perhaps some 
> automatic tests on that run every night on a source farm or sth like 
> that - projects like mozilla have that, too :-) ).

I was thinking about that too. But currently the traffic is so small,
that I just help people when they got problems :) Also, when I plan
changes that will break the trunk for longer then one or two hours I
will send a notification post here. 

Later on we will need to find a way to make that automatic :)


Current trunk is working. But only with oder versions of g++, Really
sorry I haven't thought earlier to tell you about that. I discovered
this error by accident when I tried to run yade on debian etch.
Instead of spending time to fix that (make findType working with 4.1)
I decided to not touch it because fixing findType is a temporary
solution to the larger problem. I prefer to left it broken, so that
later I'll have enough motivation (and time) to fix this larger
problem that removes the need for findType completely. The solution
to that larger probelm is waiting inside /snippets in SVN :)



> Suggestions:
> * get rid of qmake; parallel builds are AFAICT broken because qmake 
> generates makefiles and doesn't support concurrent builds natively. I 
> may try scons in some time (yes, it supports Qt out of the box also).

Yes, I plan to do that. The problem is that I'll have to use libtool,
which I don't understand. And so far, Czesiu (Artur Czechowaski) was
unable to solve that problem too. We tried hard to do that....

If I (or someone else) will understand how to configure libtool to
make libraries .so just as qmake generates them with flag

CONFIG += dll

We will be able to stop using qmake and switch to make completely.
This is really the *only* obstacle here. I hate to use qmake, too.

> 
> Naming suggestions:
>   * Volatile Contact -> TransientContact (since transient/permanent are 
> exact antonymes used in english; volatile is per analogy from chemistry 
> and seems unsuitable; using permanent instead of persistent would have 
> the connotation that it cannot break, so persistent is just fine)

The planned "big changes" are to remove those two altogether :) And
only a single container for interactions will be needed. The
transient/volatile nature of contact will be automatically detected
by MetaEngines, just like it corrently works for
InteractingMyTetrahedron and InteractingBox. Then this naming problem
will disapperar.

But currently I can rename that, no problem at all :)) I will do it
in the next commit :)

>   * abbreviate names; instead of PhysicalParameters, you can use 
> PhysParams just fine (well, PhPms is too short and confusing) and I 
> think it improves readability of the source.

yes, I'm thinking about that too. My current thoughts is to say
clearly in the documentation (on the webpage) that following prefixes
are used in every class in yade:

  base class                   example name
---------------------------------------------
  body_geometrical_model	bgm_tetrahedron
  body_interacting_geometry	big_4_spheres    (was InteractingMyTetrahedron)
  body_state                    bst_rigid_body
  body_physical_parameters	bpm_elastic
  body_bounding_volume		bbv_aabb

  interaction_geometry		ig_4x4_spheres   (was InteractionOfMyTetrahedron)
  interaction_physics		ip_simple_elastic
  
  physical_action		pa_force

That will make the class names much shorter and more readable. Also
I'm in favour to switching into lowercase names with underscore. And
stop using CamelCase. Consider this class name for example, which
name is better:

  InteractingMyTetrahedron2InteractingBox4InteractionOfMyTetrahedron

or

  big_4_spheres_AND_big_box_TO_ig_4x4_spheres

I still don't know. Is AND and TO a good choice? Maybe old "2" and
"4" were better? I really don't know. Please tell me what you think,
I'm starving to hear any opinions. Maybe you have some better idea.
Or maybe you prefer the old CameCase naming ? Please tell.



>   * for interacting/interaction, I will think about something better. 
> Yes, it is confusing.

many thanks. After you understand how that tetrahedron example works,
you will see what interactING and interactION really mean inside
yade. Then perhaps you will have a better idea for names.


-- 
# Janek Kozicki
_______________________________________________
Yade-users mailing list
Yade-users@xxxxxxxxxxxxxxxx
https://lists.berlios.de/mailman/listinfo/yade-users