revno: 2793
committer: Bruno Chareyre
branch nick: yade
timestamp: Tue 2011-03-22 19:32:04 +0100
message:
- Add functions for constrictions sizes statistics.
- Remove a few compile warnings.
modified:
lib/triangulation/FlowBounding
Thanks a lot!
Anton
On Tue, Mar 22, 2011 at 6:14 PM, Rémi Cailletaud
wrote:
> Hi,
>
> Le 18/03/2011 16:57, Anton Gladky a écrit :
>> Something like https://www.yade-dem.org/source/yade_r2790.tar.gz
>
> done,
>
>> and it would be good to have symbolic link
>> https://www.yade-dem.org/source/ya
revno: 2792
committer: Rémi Cailletaud
branch nick: yade
timestamp: Tue 2011-03-22 18:12:32 +0100
message:
buildbot now creates a source targz
modified:
scripts/build-infrastructure/master.cfg
--
lp:yade
https://code.launchpad.net/
> Yes, it is the insertion sort as in the collider.
Thanks,
I have created a branch and placed there this code for possible
following modifications of the algorithm.
https://code.launchpad.net/~yade-dev/yade/insertion-sort-test
To check it just:
scons; ./insertion-sort-test
Anton
> No. OpenMP is supposed to run a loops in a few threads. Not anymore.
> Parallelizing of a _algo_ is a problem of a developers.
Yes, yes, I know.
> Proof in the attached file. Compile it and run (may be several times) by
>
Thanks for the proof, that was my question. :)
Bruno
_
22.03.2011 16:13, Anton Gladky wrote:
Yes, you are right.
You have put in this code the idea of insertionsortcollider, which is
in the trunk now?
Anton
Yes, it is the insertion sort as in the collider.
--
Best regards,
Sergei D.
___
Mailing li
Yes, you are right.
You have put in this code the idea of insertionsortcollider, which is
in the trunk now?
Anton
On Tue, Mar 22, 2011 at 2:05 PM, Sergei D. wrote:
> 22.03.2011 14:58, Bruno Chareyre wrote:
>>
>> but parallelizing a serial algo the non-intrusive way is
>> exactly what OpenMP
22.03.2011 14:58, Bruno Chareyre wrote:
but parallelizing a serial algo the non-intrusive way is
exactly what OpenMP is supposed to do
No. OpenMP is supposed to run a loops in a few threads. Not anymore.
Parallelizing of a _algo_ is a problem of a developers.
Proof in the attached file. Compile
>
> Because Insertion sorting is a serial algo. It haven't a isolated data
> for different threads and haven't a mechanism to exchange data between
> threads. So, threadA can write to data from threadB (and will do it).
Perhaps I get you wrong, but there is no need for explicit mechanisms to
isola
Well, paralellizing a "for" loop is very simple. I was wondering if
there was an obvious reason why it should break the algorithm in this
precise case.
Because Insertion sorting is a serial algo. It haven't a isolated data
for different threads and haven't a mechanism to exchange data betwee
On 22/03/11 11:43, Sergei D. wrote:
> 22.03.2011 13:31, Bruno Chareyre wrote:
>> Why do you think it should it break the algorithm?
>> It is because "interactions->insert(newI)" could insert two interactions
>> in the same list from different threads?
> No. It will breaks the Insertion Sort Algo, n
The tag, debian/0.60.2-1 has been created
at e358c3b335711b6131e1ce5a94f8927b242bb3e6 (commit)
- Shortlog
commit e358c3b335711b6131e1ce5a94f8927b242bb3e6
Author: Anton Gladky
Date: Tue Mar 22 12:42:23 2011 +0100
Changelo
The annotated tag, upstream/0.60.2 has been created
at b1ad2328e895bd784b8574ea4412be4bce355e55 (tag)
tagging 7cb8e4c417c17b8763151b010a764589b4d113c8 (commit)
replaces upstream/0.60.1
tagged by Anton Gladky
on Tue Mar 22 12:25:57 2011 +0100
- Shortlog --
The following commit has been merged in the pristine-tar branch:
commit 29e0dde37ceb5d0b3d403dd10783bfecb08633e6
Author: Anton Gladky
Date: Tue Mar 22 12:25:57 2011 +0100
pristine-tar data for yade_0.60.2.orig.tar.bz2
diff --git a/yade_0.60.2.orig.tar.bz2.delta b/yade_0.60.2.orig.tar.bz2.d
The following commit has been merged in the master branch:
commit 3d93a61f7a533450f009764e87701a8780811719
Author: Anton Gladky
Date: Tue Mar 22 12:33:51 2011 +0100
Deleted patches, aplied by upstream in 0.60.2
diff --git a/debian/patches/fix-forcecontainer-crash-lp724396.patch
b/debian/p
The following commit has been merged in the master branch:
commit 7f541c9fb16a3e411a9b9bc0591b78c5e23ba031
Merge: f49f563fe88a39cf295361cd27d0ad7a690e4ad8
7cb8e4c417c17b8763151b010a764589b4d113c8
Author: Anton Gladky
Date: Tue Mar 22 12:25:57 2011 +0100
Merge commit 'upstream/0.60.2'
--
The following commit has been merged in the master branch:
commit e358c3b335711b6131e1ce5a94f8927b242bb3e6
Author: Anton Gladky
Date: Tue Mar 22 12:42:23 2011 +0100
Changelog update
diff --git a/debian/changelog b/debian/changelog
index c9e28a5..ed99bcb 100644
--- a/debian/changelog
+++ b/
22.03.2011 13:31, Bruno Chareyre wrote:
Why do you think it should it break the algorithm?
It is because "interactions->insert(newI)" could insert two interactions
in the same list from different threads?
No. It will breaks the Insertion Sort Algo, not
interactions->insert/erase (the operations
Ok, if there are two against one, I'll respect democracy !
Le 22/03/2011 11:16, Bruno Chareyre a écrit :
It's good to remove junk accounts. If somebody wants to keep receiving
the yade-dev mails, he can at least send a message to say so.
Bruno
On 22/03/11 10:47, Anton Gladky wrote:
Hi, Jerome
Why do you think it should it break the algorithm?
It is because "interactions->insert(newI)" could insert two interactions
in the same list from different threads?
It must be very rare since interactions are stored in bodies: maybe it
explains why tests are passed (just luck).
Let's be super-caref
> I changed https://yade-dem.org/wiki/Authors_and_contributors
>
> maybe too quick, if anyone disagrees, then I am sorry for that, and
> please correct.
Wow, that was fast!
Ok with me. Thanks.
Bruno
___
Mailing list: https://launchpad.net/~yade-dev
Po
It's good to remove junk accounts. If somebody wants to keep receiving
the yade-dev mails, he can at least send a message to say so.
Bruno
On 22/03/11 10:47, Anton Gladky wrote:
> Hi, Jerome!
>
> I think it is normally to deactivate inactive accounts. Some projects
> do it regularly, even having
Another option. We can create yade-commiters team and include there
all people, who contribute a code.
In this case, we will do not need to keep yade-dev like a moderated
team, it will be open group.
Is that better?
Anton
On Tue, Mar 22, 2011 at 10:47 AM, Anton Gladky wrote:
> Hi, Jerome!
>
Hi, Jerome!
I think it is normally to deactivate inactive accounts. Some projects
do it regularly, even having "restricted by time" membership, when you
need to re-apply for membership (sure, we do not need it)
.
If somebody keeps his membership just to read mailing list - no
problem, he will stay
Hello,
Le 21/03/2011 21:08, Anton Gladky a écrit :
Also I would like to clean up yade-dev team a little bit from inactive
users.
What is the reason of this "witch hunt" ? (with a little exageration...)
For me, there is no special requirements to belong to a mailing list :
this should be allo
Hi,
New bug-fixes yade releases 0.50.1 and 0.60.2 are ready.
It is strongly recommended to update, if you use appropriate yade
series (0.50 or 0.60).
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
0.50.1
1. Backport some documentation changes.
2. debian-packaging stuff fixes
3. Backport fix for stal
Good luck Vaclav!
and congratulations for the great job you did.
We our proud of giving an everyday contribution to the project Yade,
and your work and enthusiasm have been encouraging us to do it at the
best possible.
Best regards, Emanuele.
On 03/16/2011 11:45 PM, Václav Šmilauer wrote:
De
27 matches
Mail list logo
