[Yade-dev] New version of Yade release, release plan

[Anton Gladky]

Dear Yade users and developers,

As is customary at the beginning of January, we aim to release a new version
of Yade. The release process takes some time, so we kindly request that you
commit all your planned features by the *end of the day on January 19, 2023*
,
so that we can prepare the tarball, test it on all supported architectures,
and
upload it into the package archives.

The version 2024.01 is intended to be included in the next Long-term-support
Ubuntu Release 24.04, scheduled for release in April 2024 and will be
supported
until 2029.

Please plan your work accordingly.

Thanks and best regards,

Anton
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Deprecate Debian Stretch, Ubuntu 16.04, 18.04

[Anton Gladky]

Hi Bruno,

we can freeze the daily versions and drop deprecated distros
from all CI pipelines.

Regards

Anton

Am Mo., 20. Nov. 2023 um 21:01 Uhr schrieb Bruno Chareyre
:
>
> Hi Anton,
>
> I agree to stop building them. To be sure: are you thinking about removing 
> them from "daily" package repository as well, or just to freeze the versions 
> there?
>
> Cheers
>
> Bruno
>
>
> On 20/11/2023 20:52, Anton Gladky wrote:
>
> Dear all,
>
> We are adding more and more releases to be supported.|
> Debian Trixie is being added in the near future, and later
> next year, Ubuntu 24.04 LTS will also be included.
>
> My proposal is to deprecate at least Debian Stretch, Ubuntu 16.04,
> and Ubuntu 18.04. We need to free up some resources, and
> having always older distributions in pipelines is unlikely to bring
> any benefit.
>
> What are your thoughts? How many users are really using those
> distributions?
>
> Best regards
>
> Anton
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
> --
>
> Bruno Chareyre
> Associate Professor
>
> Grenoble INP - UGA
> Institut d'ingénierie et de management / Graduate Schools of engineering and 
> management
> 46 av. Félix-Viallet - 38301 Grenoble
> www.grenoble-inp.fr
>
> 3SR Lab
> Soils, Solids, Structures, Risks
> 1270, rue de la piscine - 38400 Saint Martin d’Hères
> www.3sr.univ-grenoble-alpes.fr
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] Deprecate Debian Stretch, Ubuntu 16.04, 18.04

[Anton Gladky]

Dear all,

We are adding more and more releases to be supported.|
Debian Trixie is being added in the near future, and later
next year, Ubuntu 24.04 LTS will also be included.

My proposal is to deprecate at least Debian Stretch, Ubuntu 16.04,
and Ubuntu 18.04. We need to free up some resources, and
having always older distributions in pipelines is unlikely to bring
any benefit.

What are your thoughts? How many users are really using those
distributions?

Best regards

Anton

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] Yade 2023.02a released

[Anton Gladky]

Dear Yade users and developers,

We are excited to announce the release of Yade 2023.02a!
This latest version comes with several new features and improvements
that we hope will enhance your experience with the software.

Thanks to all our developers and users for their contributions to this
release.
Special thanks to Janek for his contribution and for preparing the release
notes.

Debian packages are now available in the current Debian Testing and
have also been synced to the Ubuntu archive. Daily packages are also
available and provide all the new features for most active platforms.
Please see the installation page in the documentation.

Thank you for your continued support and contributions to Yade.

Anton


Changelog:

==
yade-2023.02a

Short summary of 2023.02a release:
short title (Merge Request count, until !912)

Documentation / Comments  (26 MRs)
Bug fixes (12 MRs)
LevelSet  (12 MRs)
Small improvements( 9 MRs)
Fluid & thermal & particle saturation ( 7 MRs)
High precision RealHP ComplexHP ( 7 MRs)
PotentialParticles / Blocks   ( 5 MRs)
Examples  ( 4 MRs)
Tests & checks & CI   ( 4 MRs)
Polyhedra / Facets( 3 MRs)
Clumps( 3 MRs)
Packaging improvements & building ( 2 MRs)
Alpha shapes  ( 2 MRs)
clang-format & reorganize ( 7 MRs)
OpenMPI calculations  ( 0 MRs)
GUI   ( 0 MRs)


Documentation / Comments  (26 MRs)
  remove link to wiki in homepage + mention the generic  adress for paid
support in another place (!822)
  GnuplotHyperlink (!824)
  Peace in Ukraine (!833)
  a valid link to russian scientists protesting war (it  disappeared from
russian websites) (!834)
  trunk | new thesis (!837)
  Fix doc: import error in make doc (!840)
  Reintroducing git version number in doc index (!842)
  Doc updates (installation, ViscEl, makeClumpCloud) (!841)
  VTKRecorder doc typo and +1 paper (!854)
  Update information about yadedaily installation (!855)
  Doc: missing new line in raw docstring (!860)
  Fix broken link to pdf docs (!863)
  New publications (!875)
  clarify options and packages (!861)
  Remove google-analytics script #280 (!873)
  Py3 related comment in one capillary script (!876)
  Add short-course guides and slides to website (!871)
  Add news about Yade hackathon (!879)
  Modifying Installation page, merging indications of  features and
external packages (!870)
  Fix #286, replace frontpage Changelog link + other  homepage
modifications (!882)
  clarify a FIXME which has been partly fixed. (!903)
  Doc updates regarding Clump and OAR compilation option  (!900)
  New publications (!905)
  +1 paper (!912)
  mention ubuntu20.04 virtual machine (!915)
  Yade on Twitter (!920)

Bug fixes (12 MRs)
  small fix: correct shebang and follow XDG specification  (!831)
  fix #256 (!852)
  fix #259 (!850)
  fix #264 - Failed screenshot tests in test_22_04 (!853)
  workaround bug  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009739
(!858)
  Revert "workaround bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009739; (!867)
  reimplement flipCell, fix
https://answers.launchpad.net/yade/+question/701782 (!864)
  Fix compilation with g++ 12 (!885)
  One more g++ 12 fix. (!886)
  Fix ppc64el and i386 (!890)
  Remove last trace of libloki-dev (!888)
  FIX #290, binding functions should not use 'def_readonly'  (!898)

LevelSet  (12 MRs)
  Level set visualisation (!828)
  Reflecting recent qt visualization of LevelSet in the doc  (!836)
  Level set Periodic Boundary Conditions (!832)
  LevelSet Updates (!865)
  A better definition of LS grids for superquadrics (back  to [Duriez2021b]
behavior) (!883)
  Smeared Heaviside step function for level sets (!881)
  Level-set DEM periodic boundary conditions update (!897)
  LS updates (!908)
  Correcting location of LS-LS ScGeom contactPoint (!911)
  Avoiding a brutal throw when boost root finding algorithm does not find
any in LevelSet (!928)
  LevelSet new discharge example, updates in smearing considerations and
formal changes (!914)
  fabricTensor for non-spherical particles through extrema argument (!916)

Small improvements( 9 MRs)
  Removing unused Body.chain (!825)
  add support for python 3.10 and add new find paths for  CLP, CuBlas and
freeglut with  new archlinux image (!830)
  Introducing capillary files in yade-data. (!877)
  Fix urls to input data in the benchmark scripts, and set
 preventGranularRatcheting=False, hertzian=True (!895)
  use precomputed shearIncrement: faster and compatible  with all Ig2
functors,... (!893)
  ensure randomColor() uses utils func (!909)
  Removing unused chain attribute from facet() Python  signature (!913)
  

Re: [Yade-dev] Upcoming Yade Release 2023.01

[Anton Gladky]

Thanks for your work, Janek! I really appreciate it!

I will start preparing for a release this week, but will wait
until next week for some upcoming features.

Regards

Anton


Am Mi., 18. Jan. 2023 um 23:20 Uhr schrieb Janek Kozicki (yade) <
jkozicki-y...@pg.edu.pl>:

> Hi,
>
> I created update Changelog MR for this:
>
> https://gitlab.com/yade-dev/trunk/-/merge_requests/917/diffs
>
> best regards
> Janek
>
> Anton Gladky said: (by the date of Mon, 16 Jan 2023 21:16:59 +0100)
>
> > Dear all,
> >
> > as always at the beginning of the year we are preparing
> > the stable Yade Release.
> >
> > Please, push your changes through merge requests till this Friday,
> > 20.01.2023 and think about adding some more notes into the
> > Changelog [1].
> >
> > [1] https://pad.systemli.org/p/yade-2023-changelog
> >
> > Thank you
> >
> > Anton
> >
> > ___
> > Mailing list: https://launchpad.net/~yade-dev
> > Post to : yade-dev@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~yade-dev
> > More help   : https://help.launchpad.net/ListHelp
>
>
> --
> --
> Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> Gdansk University of Technology (Gdansk Tech)
> Faculty of Applied Physics and Mathematics
> Institute of Physics and Applied Computer Science
> Division of Theoretical Physics and Quantum Information
> --
> http://yade-dem.org/
> http://pg.edu.pl/p/jan-kozicki-19725
> http://mostwiedzy.pl/en/jan-kozicki,19725-1
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] Upcoming Yade Release 2023.01

[Anton Gladky]

Dear all,

as always at the beginning of the year we are preparing
the stable Yade Release.

Please, push your changes through merge requests till this Friday,
20.01.2023 and think about adding some more notes into the
Changelog [1].

[1] https://pad.systemli.org/p/yade-2023-changelog

Thank you

Anton

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Please enable runners for some projects in the group

[Anton Gladky]

Thanks, Janek! It really works!

Anton


Am Sa., 15. Okt. 2022 um 14:19 Uhr schrieb Janek Kozicki (yade) <
jkozicki-y...@pg.edu.pl>:

> Hi,
>
> I have created a single group runner, called loop1-group-runner, in:
>
> https://gitlab.com/groups/yade-dev/-/runners?runner_type[]=GROUP_TYPE
>
> now it appears in every of our projects. Also there is a
> yade-runner-01, last time I checked it ran out of disc space and
> couldn't do any jobs. Maybe it is time to recheck yade-runner-01 and
> maybe erase it, Bruno?
>
> I suppose, that once group runners are enabled in all projects that
> you linked below, it should work? I only checked in docker-prod and
> it seems to work:
>
> https://gitlab.com/yade-dev/docker-prod/-/jobs/3178115457
>
> best regards
> Janek
>
> Anton Gladky said: (by the date of Sat, 15 Oct 2022 11:46:18 +0200)
>
> > Hi.
> >
> > as you probably know, gitlab is changing its business modell.
> > Right now we are affected by this change through the usage
> > of shared runners for some projects.
> >
> > @Janek, @Bruno or maybe somebody else, could you please
> > your runner-instances for the following projects:
> >
> > - Docker-Prod: https://gitlab.com/yade-dev/docker-prod/-/settings/ci_cd
> > - Singularity-Prod:
> > https://gitlab.com/yade-dev/singularity-prod/-/settings/ci_cd
> > - Answers (no CI, but would be good to have):
> > https://gitlab.com/yade-dev/answers/-/settings/ci_cd
> > - Yade-Website (reserved for the future):
> > https://gitlab.com/yade-dev/yade-website/-/settings/ci_cd
> > - Yade-data (no CI, but would be good to have)
> > https://gitlab.com/yade-dev/yade-data/-/settings/ci_cd
> >
> > Thanks
> >
> > Anton
>
>
> --
> --
> Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> Gdansk University of Technology (Gdansk Tech)
> Faculty of Applied Physics and Mathematics
> Institute of Physics and Applied Computer Science
> Division of Theoretical Physics and Quantum Information
> --
> http://yade-dem.org/
> http://pg.edu.pl/jkozicki (click English flag on top right)
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] Please enable runners for some projects in the group

[Anton Gladky]

Hi.

as you probably know, gitlab is changing its business modell.
Right now we are affected by this change through the usage
of shared runners for some projects.

@Janek, @Bruno or maybe somebody else, could you please
your runner-instances for the following projects:

- Docker-Prod: https://gitlab.com/yade-dev/docker-prod/-/settings/ci_cd
- Singularity-Prod:
https://gitlab.com/yade-dev/singularity-prod/-/settings/ci_cd
- Answers (no CI, but would be good to have):
https://gitlab.com/yade-dev/answers/-/settings/ci_cd
- Yade-Website (reserved for the future):
https://gitlab.com/yade-dev/yade-website/-/settings/ci_cd
- Yade-data (no CI, but would be good to have)
https://gitlab.com/yade-dev/yade-data/-/settings/ci_cd

Thanks

Anton
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Yade vs. war in Ukraine

[Anton Gladky]

Hello Bruno,

thanks for this initiative! I do really support it.

I am personally affected by this situation and my life is being splitted
now on "before" and "after".

Thanks you all for support.

Anton

Am Do., 3. März 2022 um 18:16 Uhr schrieb Bruno Chareyre
:
>
> Hi guys,
>
> My heart is broken since the beginning of that war on Ukraine.
> I believe international cooperation is one of our value in the Yade
> community.
>
> If you agree we could include a statement on the website in support of
> peace, like other scientific communities did [1].
>
> Regards
>
> Bruno
>
> [1]
> https://www.interpore.org/index.php?page=acymailing_front=archive=view=120=559-kfFKWJJ3zkJa0l=1=1
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] TODO-List for Yade

[Anton Gladky]

Dear all,

As discussed during the last meeting of yade-devs, I have prepared
a list of TODO-tasks [1] for Yade, which can be completed during the student
works, Google summer of code and other similar contests and springs.

Feel free to add new ideas (even crazy ones!) into this list. If somebody
will work on the particular task, it will be separated into the extra-task to be
tracked.

[1] https://gitlab.com/yade-dev/trunk/-/issues/251

Thanks and best regards

Anton

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] Yade 2022.01a released

[Anton Gladky]

Dear Yade users and developers,

As always at the beginning of the year we are releasing the new Yade version.
Yade 2022.01a has just been released [1]!

Thanks all developers and users for contributions! Special thanks to Janek for
his contribution and preparing the release notes!

Last year we started regular online meetings of Yade members. Feel free to join
us (more details are here [2]).

[1] https://gitlab.com/yade-dev/trunk/-/releases/2022.01a
[2] https://lists.launchpad.net/yade-dev/msg15105.html

Best regards

Anton


OpenPGP_signature
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] New version of Yade, 2022. Release plan

[Anton Gladky]

Dear Yade users and developers,

as always at the beginning of January we want to release a new Yade version.
Release process takes some time, so please commit all your planned features
till the end of the December 2021, so we can prepare tarball, test it on all
supported architectures and upload it into the package archives.

The version 2022.01 should go into the next Long-term-support Ubuntu Release,
which is planned to be released in April 2022 and will be supported till 2027,
and even with Extended Security Maintenance till 2032.

Please plan your work accordingly.

Thanks and best regards

Anton

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Dev meeting next week

[Anton Gladky]

Dear all,

I am travelling now, but I will try to join.

Regards

Anton


Am Do., 15. Juli 2021 um 11:13 Uhr schrieb Bruno Chareyre <
bruno.chare...@3sr-grenoble.fr>:

> Dear Yade devs,
> For a few months now some of us started holding meetings to discuss dev
> aspects.
> We figured it would be good to gather more of the devs in these meetings,
> so if you are interested and available you are welcome to join next meeting.
> It will be on Wednesday next week, June 21th, at 11:00 EU time.
>
> Please reply in this thread if you plan to join so we can send you the
> zoom link.
>
> Cheers
>
> Bruno
>
>
>
> --
>
>
> ___
> Bruno Chareyre
> Associate Professor
> 3SR lab., ENSE³, Grenoble INP
> Tél : +33 4 56 52 86 21
> 
>
> Email too brief?
> Here's why: email charter
> 
>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Docker/Singularity images for production (and possibly development)

[Anton Gladky]

Hi Bruno,

I have created several branches for all supported distributions (ubuntu and
debian).
Both (yade and yadedaily) are installed, but the doc-packages were dropped,
I
do not think they are needed for production.

Also I tried to reduce the size of the images, so they are just a little
more than 1gb.
Pipeline are scheduled for every day (after newly built yadedaily-packages
are placed
into the repository).

For yadedaily one needs to install also the python-mpi4py package. It
should be fixed with
this MR [1].

[1] https://gitlab.com/yade-dev/trunk/-/merge_requests/636

Please test the setup. And when it is OK, I will update the documentation.
Basically you need to run the following:

docker run --rm -it registry.gitlab.com/yade-dev/docker-prod:ubuntu20.04

or

docker run --rm -it registry.gitlab.com/yade-dev/docker-prod:debian-buster

Best regards

Anton


Am Fr., 5. März 2021 um 10:38 Uhr schrieb Bruno Chareyre <
bruno.chare...@3sr-grenoble.fr>:

> Hi there,
>
> I'm planning to build new docker images in yade's gitlab for production,
> and possibly for development (see second part of this message, some
> background comes first).  This is open to suggestions.
>
> * Background:
>
> I recently started playing with "Singularity" images since I found our HPC
> department made it available on the clusters. There was also a user
> mentioning that on launchpad recently. From end-user POV, singularity
> images work like docker images, but a very practical difference is that it
> is allowed on our (and others') HPC. Docker isn't, for security reason.
>
> It made running yade so easy. The above command worked immediately, and
> should work just the same on every system with singularity installed:
> *ssh myHPC*
> *singularity exec
> docker://registry.gitlab.com/bchareyre/docker-yade:ubuntu20.04-daily
> 
> yadedaily --check*
>
> or equivalently:
>
>
>
>
> *export YADE='singularity exec
> docker://registry.gitlab.com/bchareyre/docker-yade:ubuntu20.04-daily
> 
> yadedaily' $YADE --check $YADE myScript.py $ etc. *
>
> Key points:
> 1- singularity accepts docker images in input.
> 2- the above command is using some custom docker with yadedaily
> pre-installed (which then needs to be downloadable from somewhere where
> docker is permitted)
> 3- it is compatible with MPI(!). The host system's MPI is able to
> communicate with the image system's MPI in a scenario like this, as if it
> was just yade running natively on the host:
>
> *mpirun -np 500 $YADE someParrallelStuff.py *4- a condition for this MPI
> magic to work is that the mpi library is in the same version for the host
> and for the executed image
> 5- performance: no measurable difference compared to a yade compiled on
> the host (be it running -j1, -jN or mpiexec).
>
> For the moment the custom dockers are built in [1]
> .
> I'm also building a Singularity images with [2]
> 
> but I didn't really use it since I can build it from docker directly on the
> cluster (building the singularity image is implicit in *singularity exec
> docker://...*). Building on-site may not be allowed everywhere, though,
> and in that case [2] could be useful.
>
> * What can be done:
>
> I will move [1,2] or something similar to gitlab/yade-dev and advertise it
> in the install page. Also build more versions for people to use them. More
> versions because of the MPI point above (4): depending on the host system
> someone may want OMPI v1 (unbuntu16), or v2 (ubuntu18), etc.
>
> For production images it would make sense to just use canonical
> debian/ubuntu with yade and/or yadedaily preinstalled. But, it is not
> exactly what I did for the moment. Instead I used docker images from our
> registry. Which implies the images have yade, and also what it needs to
> compile yade (I didn't test compilation yet but it should work).
>
> I was thinking of splitting that into two types of images; minimal images
> for production and "dev" images with all compilation pre-requisites. Then I
> realized that the best "dev" image would be - by far - one reflecting the
> state of the system at the end of our current pipeline, i.e. one with a
> full /build folder and possibly ccache info (if not too large).
>
> If such dev images were pushed to yade registry then anyone could grab
> latest build and recompile incrementally. It could save a lot of
> (compilation) time for us when trying to debug something on multiple
> distros.
>
> And what about that?: compiling with a ubuntu20 docker image on a ubuntu20
> host should make it possible to use the pipeline's ccache while still
> running yade on the native system (provided that the install path is in the
> host filesystem).
>
> Maybe pushing to registry could be done directly as part of current
> 

Re: [Yade-dev] Docker/Singularity images for production (and possibly development)

[Anton Gladky]

Hi Bruno,

this is very interesting! I have never heard about singularity yet. Thanks
for information.

>From my point of view, it is not a problem at all to build docker-images
with yadedaily
inside, if it is helpful for you and anybody. I have some concerns about
large dev-images,
but I am also opened to it.

I would propose to organize a short zoom/bbb/jitsi video-meeting and to
discuss it by voice.
We are practicing it already with Janek and Klaus for some other (paper)
stuff and it works
perfectly and just faster as writing long emails.

Best regards

Anton


Am Sa., 6. März 2021 um 19:18 Uhr schrieb Bruno Chareyre <
bruno.chare...@3sr-grenoble.fr>:

>
> On 06/03/2021 17:06, Janek Kozicki (yade) wrote:
>
> I am not exactly sure what you want to discuss,
>
> I don't know either LOL. That's more an announcement in advance so someone
> can raise issues, ask features, etc.
>
> Do you want to create some sort of packages with yade installed inside?
>
> You can call it package, but that's more like some docker images in a
> different format (from a very macroscopic point of view). Main thing is
> that it is allowed on HPC (where compiling yade can be big pain) and it
> seems to become more popular.
>
> Hence people will look for a yade-docker target (one with yade inside) in
> order to build their singularity images, and it is fairly easy to offer
> some.
>
> Mind that before using Singularity I have never been able to get all
> checkTests to pass on our HPC cluster. I was able to run what I needed most
> of the time, but never to pass all tests. There was always an issue with
> something.
>
> I am not sure if yade-dev registry will be able to hold big
> docker images.
>
> Good point, though the images have no reason to be much bigger than our
> current docker images. The problem would be more images, not larger images.
> I will check registry limit. If it is a problem I can keep pushing to
> gitlab.com/bchareyre registry, not an issue.   See:
> https://gitlab.com/bchareyre/docker-yade/container_registry/1672064
>
> As you see the images are from 1.1GB to 1.7GB, not a big increment.
>
> We may run out of space if we don't start paying
> gitlab for hosting.
>
> Not an issue. What I described is what I'm already doing under my account
> (without paying). If migrating one thing from gitlab/bchareyre to
> gitlab/yade-dev is the cause of running out of space, then I'll just not
> migrate. It is not an problem to provide the images to the users under my
> registry.
>
> Perhaps these singularity_docker packages should also be on yade-dem.org ?
>
> Excessively complex. We would have to setup a registry on our local server
> while gitlab does that very well.
>
>
> The interesting stuff for me would be if we could use these HPC
> singularity servers in our gitlab continuous integration pipeline :)
>
> If you mean accessing more hardware ressources, no, it will not work in
> Grenoble.
> The HPC clusters are dedicated to scientific computing. They have special
> job submission systems, it will absolutely not integrate in a CI framework.
>
> The yade-runner-01 quickly runs out of space whenever try to I enable
> it ;-)
>
> Yeah, but this is a completely different type of ressources, even if they
> are provided by the same people overall.
> Maybe it is a good time to check again how I could get gitlab runners for
> yade. They improved a number of things and offered new services in the
> recent years. There might be docker farms more easily accessible than when
> Rémi configured yade-runner-01, now. Rémi was basically ahead of things.
>
>
> Maybe it is only a matter of single line in
> file /etc/gitlab-runner/config.toml , change:
>
>   executor = "docker"
>
> to
>
>   executor = "singularity"
>
> I think this is quite likely.
>
>
> Very likely but there is no point doing that, I think.
> Why would you generate a singularity image from a docker image to achieve
> something the docker image does just as well?
> In the context of using gitlabCI/docker we have root privileges, hence no
> issue with docker.
>
>
> We already have incremental recompilation in our gitlab CI pipeline.
> The ccache is used for that. The trick was to mount inside docker
> (for you: inside singularity) a local directory from the host
> filesystem, where the ccache files are stored.
>
> That the gitlab compilation is incremental doesn't make my own local
> compilation incremental.
> However if I can download a snapshot of the gitlab pipeline as a virtual
> machine I can compile incrementally, locally, even though the initial
> compilation wasn't local.
>
> Note that the docker images are re-downloaded from gitlab only when
> they have been rebuilt on https://gitlab.com/yade-dev/docker-yade/-/pipelines
> And this download is pretty slow. Fortunately it happens only every
> few weeks. Otherwise docker uses the cached linux distro image.
>
> I see where I lost you. Singularity images (at least in my project) are
> not in any way related to CI.
> They 

[Yade-dev] Yade 2021.01a is released

[Anton Gladky]

Dear Yade users and developers,

As always at the beginning of the year we are releasing
the newer Yade version. A couple of days ago Yade 2021.01a
was released [1]! Thanks all for contributions!

Special thanks to Janek for his contribution and preparing the
release notes! French team thanks for pushing MPI version of the
Yade and other features and fixes!

[1] https://gitlab.com/yade-dev/trunk/-/releases/2021.01a

Best regards

Anton
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] New Yade version, beginning of January 2021 - Release notes.

[Anton Gladky]

on to the pipeline
>   checkPotentialVTKRecorders
>   make runtime of two checkScripts acceptable
>   Improve performance test, add it to the pipeline.
>   Add multi core check
>   add enum tests and fix .deb builds
>   Add 32bit architecture to the pipeline.
>
> OpenMPI calculations (8 MRs):
>   Correct and improve two methods in domaindecomposition.py
>   Mpy update
>   cleaner exit and spawn/despawn
>   MpiDoc rebased
>   One Py3-required LOG_TRACE, Making Py3 mandatory for MPI compilation. Fix 
> #144 Py2 (no-)support
>   fix thread-unsafe assignment of permForceSynced (fix #156, setPermF broken)
>   Temporarily disable insertionSortParallel() until #138 is solved.
>   fix parallel collision detection (fix #138) : FIX Out-of-bounds access in 
> insertionSortParallel
>
> clang-format in the pipeline (7 MRs):
>   clang-format ./pkg
>   clang-format ./py
>   clang-format ./lib
>   clang-format ./core
>   clang-format gui/qt5. Remove qt4.
>   Add clang-format test to the CI pipeline.
>   clang-format discussion.
>
> Packaging improvements (6 MRs):
>   Prepare 20.04 deb-packages
>   Add instructions for yadedaily Ubuntu 20.04 packages
>   Update scripts for uploading daily-packages
>   Fix deb packages
>   build deb also on master pipeline
>   Clean aptly DB after update
>
> GUI (3 MRs):
>   Draw grid label coordinates, allow custom change of grid density.
>   remove unaligned margins in GUI inspect.
>   Add enum support for GUI dropdown menus.
>
> ===
> Are the extra debian packages yade-long-double or yade-float128, maybe even 
> yade-mpfr150
> even possible?
>
> best regards
> Janek
>
> Janek Kozicki (yade) said: (by the date of Sun, 6 Dec 2020 00:26:03 +0100)
>
> > Hi Anton,
> >
> > Do you think that you could also prepare yade-long-double or
> > yade-float128, maybe even yade-mpfr150 packages?
> >
> > Better if all of them used ENABLE_MPFR, to avoid slow boost::cpp_bin_float.
> >
> > It would work great to protect (via dpkg tests caused by changes in
> > other packages) our achievement of having working high precision in
> > yade. We don't want this functionality to break at some later time.
> >
> > best regards
> > Janek
> >
> >
> > Anton Gladky said: (by the date of Mon, 16 Nov 2020 20:13:06 +0100)
> >
> > > Hello Jérôme,
> > >
> > > our goal is to get the newer Yade into the Debian Bullseye, because
> > > it will be the default version for the next two years (till 2023).
> > >
> > > It would be good to upload Yade into the repository in January (till soft 
> > > freeze
> > > on 2021-02-12). After that date any upload into the repository should be
> > > coordinated with the Release team and is actually not for the new software
> > > versions.
> > >
> > > If you are able to push your changes till the end of December and all 
> > > tests
> > > are passing, I think it would be possible to accept it for the new 
> > > release.
> > >
> > > I am not a fan of a last-minute commit (especially on Friday afternoon
> > > :) ) because it can break the stuff with a very limited time to fix it.
> > >
> > > Anyway, if you are not able to do it on time - there is still an
> > > opportunity to release a minor version later.
> > >
> > > Please take time and test your code (including --test and --check scripts)
> > > to prevent breakages and to provide Yade with new and reliable features.
> > >
> > > Best regards
> > >
> > >
> > > Anton
> > >
> > > Am Fr., 13. Nov. 2020 um 11:23 Uhr schrieb Jerome Duriez
> > > :
> > >
> > > >
> > > > Dear all,
> > > >
> > > > Sorry for the inconvenience but is there any flexibility in that 
> > > > schedule ?
> > > >
> > > > I have been working on a new Shape child and I may get closer to the
> > > > endpoint of my work in the form of a merge request.
> > > >
> > > > It now represents "32 files changed, 2193 insertions(+), 178
> > > > deletions(-)" since 2020.01(a ?) = commit 9964f5.
> > > >
> > > >
> > > > In case there is some flexibility in the schedule and if I'm not the
> > > > only one interested in that flexibility (MPI maybe ?..), maybe we could
> > > > discuss inclusion of that Shape child in the new release ?
> > > >
> > > > If not, let it be, I would totally understand to miss that train.
> &g

Re: [Yade-dev] New Yade version, beginning of January 2021

[Anton Gladky]

Hello Jérôme,

our goal is to get the newer Yade into the Debian Bullseye, because
it will be the default version for the next two years (till 2023).

It would be good to upload Yade into the repository in January (till soft freeze
on 2021-02-12). After that date any upload into the repository should be
coordinated with the Release team and is actually not for the new software
versions.

If you are able to push your changes till the end of December and all tests
are passing, I think it would be possible to accept it for the new release.

I am not a fan of a last-minute commit (especially on Friday afternoon
:) ) because it can break the stuff with a very limited time to fix it.

Anyway, if you are not able to do it on time - there is still an
opportunity to release a minor version later.

Please take time and test your code (including --test and --check scripts)
to prevent breakages and to provide Yade with new and reliable features.

Best regards


Anton

Am Fr., 13. Nov. 2020 um 11:23 Uhr schrieb Jerome Duriez
:

>
> Dear all,
>
> Sorry for the inconvenience but is there any flexibility in that schedule ?
>
> I have been working on a new Shape child and I may get closer to the
> endpoint of my work in the form of a merge request.
>
> It now represents "32 files changed, 2193 insertions(+), 178
> deletions(-)" since 2020.01(a ?) = commit 9964f5.
>
>
> In case there is some flexibility in the schedule and if I'm not the
> only one interested in that flexibility (MPI maybe ?..), maybe we could
> discuss inclusion of that Shape child in the new release ?
>
> If not, let it be, I would totally understand to miss that train.
>
>
> Jérôme
>
> --
> Chargé de Recherche / Research Associate
> INRAE, RECOVER
> 3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
> +33 (0)4 42 66 99 21
> https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez
>
> On 12/11/2020 22:18, Anton Gladky wrote:
> > Dear Yade users and developers,
> >
> > As always at the beginning of January I am planning to prepare
> > a release of a new Yade version.
> >
> > Please try to push your changes inyo the code at least till the mid
> > of December, so we will have enough time to test it on different
> > platforms during the Christmas period and release it on time.
> > Also please try not to push too much breaking changes at that
> > period..
> >
> > The new Debian Bullseye release is scheduled already [1]. So we
> > should not be too late to prepare a new Yade for the next stable
> > Debian version.
> >
> > Also it would be good to prepare short but meaningful release notes.
> > Current git-workflow has too many small log-messages, so it is
> > difficult to get meaningful information from there. Please use this
> > link to add some notes [2].
> >
> > [1] https://wiki.debian.org/DebianBullseye
> > [2] https://pad.systemli.org/p/yade-2021-release-notes
> >
> > Thank you
> >
> > Anton Gladky
> >
> > ___
> > Mailing list: https://launchpad.net/~yade-dev
> > Post to : yade-dev@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~yade-dev
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] Yade_2020.01a for Debian 10 Buster and Debian 9 Stretch

[Anton Gladky]

Dear Yade users and developers,

backport repositories of Debian 10 Buster (stable) [1]
and Debian 9 Stretch (oldstable) [2] have got an updated
yade_2020.01a.

If you use one of those distributions, you can install updated
Yade from backports:

sudo apt-get install yade -t stretch-backports

or

sudo apt-get install yade -t buster-backports.

If you have any questions or troubles with it, please let me know.

[1] https://buildd.debian.org/status/package.php?p=yade=buster-backports
[2] https://buildd.debian.org/status/package.php?p=yade=stretch-backports

Best regards

Anton

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] New Yade version, beginning of January 2021

[Anton Gladky]

Dear Yade users and developers,

As always at the beginning of January I am planning to prepare
a release of a new Yade version.

Please try to push your changes inyo the code at least till the mid
of December, so we will have enough time to test it on different
platforms during the Christmas period and release it on time.
Also please try not to push too much breaking changes at that
period..

The new Debian Bullseye release is scheduled already [1]. So we
should not be too late to prepare a new Yade for the next stable
Debian version.

Also it would be good to prepare short but meaningful release notes.
Current git-workflow has too many small log-messages, so it is
difficult to get meaningful information from there. Please use this
link to add some notes [2].

[1] https://wiki.debian.org/DebianBullseye
[2] https://pad.systemli.org/p/yade-2021-release-notes

Thank you

Anton Gladky

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] should we drop qt4 support?

[Anton Gladky]

Hello Janek,

I think it is a time already to drop qt4 support completely.

> If we decided to remove qt4, then we need to decide which version of
> GLViewer::postSelection(…)

If we drop qt4 directory completely, then we will have only qt5-version
of this method, right?

Regards

Anton

Am So., 8. März 2020 um 23:07 Uhr schrieb Janek Kozicki (yade)
:
>
> If we decided to remove qt4, then we need to decide which version of
> GLViewer::postSelection(…) to use, because `meld gui/qt4 gui/qt5`
> shows that this function is the only one that differs between the two
> directories.
>
>
>
> Janek Kozicki (yade) said: (by the date of Sun, 8 Mar 2020 22:54:07 +0100)
>
> > These last two merge requests have duplicate changes in both directories.
> > The changes are identical, because I did
> >
> >   git diff --staged > /tmp/z.patch
> >   # edit file, replace qt5 with qt5
> >   patch -p1 < /tmp/z.patch
> >
> > but having two copies of same stuff isn't healthy. Does anyone still use 
> > qt4?
> >
> > best regards
> > Janek
> >
> >
> >
> > --
> > Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> > Gdańsk University of Technology
> > Faculty of Applied Physics and Mathematics
> > Department of Theoretical Physics and Quantum Information
> > --
> > http://yade-dem.org/
> > http://pg.edu.pl/jkozicki (click English flag on top right)
> >
> > ___
> > Mailing list: https://launchpad.net/~yade-dev
> > Post to : yade-dev@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~yade-dev
> > More help   : https://help.launchpad.net/ListHelp
>
>
> --
> --
> Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> Gdańsk University of Technology
> Faculty of Applied Physics and Mathematics
> Department of Theoretical Physics and Quantum Information
> --
> http://yade-dem.org/
> http://pg.edu.pl/jkozicki (click English flag on top right)
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] High precision Real and minieigen

[Anton Gladky]

Hello Janek,

sorry for delays, "real" life is taking much more time when we get older :)

> * I would rather avoid pybind11 switch in a rush, better give it a few months

Maybe I was not clear, pybind11 is just a possible option. If we
really decide to switch to it, we need to evaluate, whether it is
suitable for us, whether it really helps to improve compilation times
and what it costs for us (time).

> * I would prefer minieigen-src package (no extra compilation time for people 
> who use `double`)
> * minieigen-src in ubuntu 20.04 will let more people to test & use high 
> precision.

Unfortunately, it is almost impossible for the time being. If I add a
new "minieigen-src" binary package, the package should go through
"NEW"-queue [1], which has almost 300 packages, waiting for review
from Debian FTP-masters. It can delay upload for months.

We should probably consider alternative ways to help you to integrate
high-precision stuff.

[1] https://ftp-master.debian.org/new.html

Best regards

Anton

Am Fr., 21. Feb. 2020 um 22:30 Uhr schrieb Janek Kozicki (yade)

:
>
> Hi Anton,
>
> Yes, the number of defines in Serialization.hpp is crazy.
> Changing/removing them to use pybind11 would take a lot of work.
> I'm sure it is possible, but not quickly.
>
> We can open an issue about pybind11 switch. Discuss pros and cons,
> find a good strategy to deal with crazy defines and complete it later.
>
> Doing this switch right now is unrealistic. Working on another moving
> target (pybind11) on top of an already moving target (minieigen HP
> not fully integrated) is irresponsible. If possible I would prefer:
>
>   * minieigen-src package (slower compilation only for non-double)
>   * or integrate minieigen with yade sources for now (rather undesirable
> due to compilation time).
>
> Whatever we do I would prefer to integrate HP, because doubles will
> appear very quickly in the code.
>
> Ah, if we talked about pybind11 switch three months ago it would be
> perfect timing for me :( In fact I was thinking about it that time,
> but I didn't want to push into something that wasn't guaranteed to be
> working [*]. Figuring out the correct way to convert high precision
> to/from python with boost was difficult, for a while I prefer to not
> repeat this task with pybind11. But surely we can get back to this
> later.
>
> The extra time for compilation happens only when non-double type is used.
> If minieigen-src package gets to 20.04 it will be possible later for
> people to compile high precision yade from gitlab sources without big hassle.
>
> The build_focal_simple [1] is 5 minutes because it's not parallelized.
> The problem is that pybuild is not accepting -j argument.
> With make -j 6 it is faster [2][3].
>
> Also a fast quad_double (62 decimal places, package libqd-dev)
> integration is in the works with boost::multiprecision developers [4].
>
> To summarize:
>
>  * I would rather avoid pybind11 switch in a rush, better give it a few months
>  * I would prefer minieigen-src package (no extra compilation time for people 
> who use `double`)
>  * minieigen-src in ubuntu 20.04 will let more people to test & use high 
> precision.
>
> I understand that this solution is temporary until we figure a
> proper way to deal with pybind11. The 4 year LTS is more than enough
> to solve pybind11 + Serialization.hpp problem.
>
> It is better to finish HP integration to not lose what is already
> working.
>
> best regards
> Janek
>
>
> [*] pybind11 is a new dependency and a new package, boost is well
> integrated with itself, it was guaranteed to work.
>
> [1] https://gitlab.com/yade-dev/minieigen/-/jobs/444927466
>
> [2] https://gitlab.com/cosurgi/minieigen-real/pipelines/118211208 - I used 
> this to test HP
>
> [3] In the pipeline with ccache it's usually not a problem. On
> debian build servers: it won't be a problem until we decide to
>     make yade-float128 package. But if we made an accompanying
> minieigen-float128 this problem would disappear. But pybind11
> alternative is good also, just unrealistic right now.
>
> [4] https://github.com/boostorg/multiprecision/issues/184
>
>
> Anton Gladky said: (by the date of Fri, 21 Feb 2020 20:09:07 +0100)
>
> > Hi Janek,
> >
> > we have misunderstanding here. python3-minieigen is the __binary__
> > package and it is a bad idea to ship the source code with the package.
> >
> > Adding minieigen-src binary package is possible, but it looks like very
> > undesired way.
> >
> > As I see, only Yade is using minieigen in the Debian. So, theoretically we
> > can merge it again with Yade. Not sure, whether it is a good way thou

Re: [Yade-dev] High precision Real and minieigen

[Anton Gladky]

Guys, just to be clear: pybind11 migration was just a possible option
for the future.
I have no experience and no idea, whether it is better option or not.
We can experiment
with minieigen (switching it to pybind11) and see, whether it is
suitable for our needs.

Anton

Am Sa., 22. Feb. 2020 um 13:13 Uhr schrieb Bruno Chareyre
:
>
> It makes sense to me to not rush to pybind right now, although I don't mean 
> to refrain any volunteer...
> B
>
>
>
> On Sat, 22 Feb 2020 at 11:05, Janek Kozicki (yade)  
> wrote:
>>
>> OK, I will experiment a bit and see what it takes to switch to pybind11.
>>
>> Janek
>>
>>
>> Janek Kozicki (yade) said: (by the date of Fri, 21 Feb 2020 22:30:04 
>> +0100)
>>
>> > Hi Anton,
>> >
>> > Yes, the number of defines in Serialization.hpp is crazy.
>> > Changing/removing them to use pybind11 would take a lot of work.
>> > I'm sure it is possible, but not quickly.
>> >
>> > We can open an issue about pybind11 switch. Discuss pros and cons,
>> > find a good strategy to deal with crazy defines and complete it later.
>> >
>> > Doing this switch right now is unrealistic. Working on another moving
>> > target (pybind11) on top of an already moving target (minieigen HP
>> > not fully integrated) is irresponsible. If possible I would prefer:
>> >
>> >   * minieigen-src package (slower compilation only for non-double)
>> >   * or integrate minieigen with yade sources for now (rather undesirable
>> > due to compilation time).
>> >
>> > Whatever we do I would prefer to integrate HP, because doubles will
>> > appear very quickly in the code.
>> >
>> > Ah, if we talked about pybind11 switch three months ago it would be
>> > perfect timing for me :( In fact I was thinking about it that time,
>> > but I didn't want to push into something that wasn't guaranteed to be
>> > working [*]. Figuring out the correct way to convert high precision
>> > to/from python with boost was difficult, for a while I prefer to not
>> > repeat this task with pybind11. But surely we can get back to this
>> > later.
>> >
>> > The extra time for compilation happens only when non-double type is used.
>> > If minieigen-src package gets to 20.04 it will be possible later for
>> > people to compile high precision yade from gitlab sources without big 
>> > hassle.
>> >
>> > The build_focal_simple [1] is 5 minutes because it's not parallelized.
>> > The problem is that pybuild is not accepting -j argument.
>> > With make -j 6 it is faster [2][3].
>> >
>> > Also a fast quad_double (62 decimal places, package libqd-dev)
>> > integration is in the works with boost::multiprecision developers [4].
>> >
>> > To summarize:
>> >
>> >  * I would rather avoid pybind11 switch in a rush, better give it a few 
>> > months
>> >  * I would prefer minieigen-src package (no extra compilation time for 
>> > people who use `double`)
>> >  * minieigen-src in ubuntu 20.04 will let more people to test & use high 
>> > precision.
>> >
>> > I understand that this solution is temporary until we figure a
>> > proper way to deal with pybind11. The 4 year LTS is more than enough
>> > to solve pybind11 + Serialization.hpp problem.
>> >
>> > It is better to finish HP integration to not lose what is already
>> > working.
>> >
>> > best regards
>> > Janek
>> >
>> >
>> > [*] pybind11 is a new dependency and a new package, boost is well
>> > integrated with itself, it was guaranteed to work.
>> >
>> > [1] https://gitlab.com/yade-dev/minieigen/-/jobs/444927466
>> >
>> > [2] https://gitlab.com/cosurgi/minieigen-real/pipelines/118211208 - I used 
>> > this to test HP
>> >
>> > [3] In the pipeline with ccache it's usually not a problem. On
>> > debian build servers: it won't be a problem until we decide to
>> > make yade-float128 package. But if we made an accompanying
>> > minieigen-float128 this problem would disappear. But pybind11
>> > alternative is good also, just unrealistic right now.
>> >
>> > [4] https://github.com/boostorg/multiprecision/issues/184
>> >
>> >
>> > Anton Gladky said: (by the date of Fri, 21 Feb 2020 20:09:07 +0100)
>> >
>> > > Hi Janek,
>> > >
>> > > we have misunderstanding here. python3-min

Re: [Yade-dev] High precision Real and minieigen

[Anton Gladky]

Hi Janek,

we have misunderstanding here. python3-minieigen is the __binary__
package and it is a bad idea to ship the source code with the package.

Adding minieigen-src binary package is possible, but it looks like very
undesired way.

As I see, only Yade is using minieigen in the Debian. So, theoretically we
can merge it again with Yade. Bot sure, whether it is a good way though
Yade compiles too slow. Minieigen adds definitely 4-5 compilation minutes
and Gigabytes of used RAM.

We should really have a look at pybind11 alternative, if it accelerates the
compilation. But when I see Serialization.hpp, I am getting crazy from the
number of "defines" there.

Anton

Am Fr., 21. Feb. 2020 um 17:04 Uhr schrieb Janek Kozicki (yade)
:
>
> Uh Anton, I'm sorry to be so boring:
>
> I have checked with sid in /etc/apt/sources.list:
>
>   deb-src http://ftp.pl.debian.org/debian/ sid  main non-free contrib
>
> and built the python3-minieigen_0.50.3+dfsg1-12_amd64.deb package.
>
> There is no /usr/include/minieigen/*pp files inside :(
>
> For high precision to work, they are necessary. Maybe the proper way
> to do this is to introduce python3-minieigen-dev package? I'm not
> sure. These sources are needed because of these include [1] statements.
>
> I am attaching once again the file python3-minieigen.install which
> installs *pp files. Even the *.cpp files are used. If you feel
> that *.cpp files are too much, we could duplicate the .cpp files in
> yade (they are rather short) and only include the *.hpp files (these
> are quite long). But all *pp files in /usr/include/minieigen/ would
> be perfect.
>
> Best regards
> Janek

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] High precision Real and minieigen

[Anton Gladky]

Hi Janek,

I habe backported both of your patches [1], [2] into the
existing in Debian minieigen-package and uploaded into
the Debian.

The newer minieigen can now be polished, new version released and
uploaded with no rush.

[1] https://github.com/eudoxos/minieigen/pull/24
[2] https://github.com/eudoxos/minieigen/pull/25

Best regards

Anton

Am Mi., 19. Feb. 2020 um 22:37 Uhr schrieb Janek Kozicki (yade)
:
>
> I have asked Vaclav to transfer maintenance of miniEigen to us:
>
> https://github.com/eudoxos/minieigen/pull/26
>
> cheers
> Janek

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Call for testing, updated yadedaily packages

[Anton Gladky]

Hello Jerome,

please, remove amazonaws.com from your /etc/apt/sources.list.
It was for testing purposes.

http://www.yade-dem.org/packages/ is the only proper place for the yadedaily
packages.

Regards

Anton

Am Mo., 27. Jan. 2020 um 10:04 Uhr schrieb Jerome Duriez
:
>
> Hi Anton and everyone,
>
> As of today, is it still meaningfull to have this 
> "http://yadedaily.s3.amazonaws.com; in /etc/apt/sources.list.d/yadedaily.list 
> ?
>
> sudo apt-get update here returns
>
> [...]
> Ign:12 http://yadedaily.s3.amazonaws.com/debian bionic InRelease
> Err:13 http://yadedaily.s3.amazonaws.com/debian bionic Release
>   404  Not Found [IP: 52.216.134.75 80]
> [...]
>
>
> Best,
>
> Jérôme
>
> --
> Chargé de Recherche / Research Associate
> Inrae, RECOVER
> 3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
> +33 (0)4 42 66 99 21
> https://www6.paca.inrae.fr/recover/personnel/equipes/jerome-duriez
>
> On 27/06/2019 21:15, Anton Gladky wrote:
>
> Dear all,
>
> yadedaily packages are being under renovation at the moment. And now they 
> need to be tested.
> I want to ask you to do it and give a feedback.
>
> 3 Distributions are supported:
> - Debian Buster
> - Debian Stretch
> - Ubuntu 18.04 Bionic
>
> Packages are hosted on Amason S3 for the moment.
> The following steps need to be taken to test the packages
>
> 1. Add yade GPG-key:
> If you have the yadedaily package, you can skip this step.
>
> wget -O - http://yadedaily.s3.amazonaws.com/yadedaily.gpg | sudo apt-key 
> add -
>
> 2. Add repo into the apt:
> - Debian Buster:
>   sudo bash -c 'echo "deb http://yadedaily.s3.amazonaws.com/debian buster 
> main" >> /etc/apt/sources.list.d/yadedaily.list'
>
> - Debian Stretch:
>   sudo bash -c 'echo "deb http://yadedaily.s3.amazonaws.com/debian 
> stretch main" >> /etc/apt/sources.list.d/yadedaily.list'
>
> - Ubuntu 18.04 Bionic:
>   sudo bash -c 'echo "deb http://yadedaily.s3.amazonaws.com/debian bionic 
> main" >> /etc/apt/sources.list.d/yadedaily.list'
>
> 3. Install yadedaily:
>  sudo apt update && sudo apt install yadedaily
>
> After that you can run the software:
>
> yadedaily
> yadedaily --test
> yadedaily --check
>
> Please let me know, whether everything is working as expected.
>
> If you do not want to use yadedaily any more, just do:
>sudo apt purge yadedaily
>
> Remove test-repo from sources:
> sudo rm  /etc/apt/sources.list.d/yadedaily.list
>
> I will update packages manually within the test period. After that we can 
> automate the process.
>
> Thanks
>
> Anton
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] High precision Real.

[Anton Gladky]

Hi Janek,

> BTW, Anton did you notice that building debian package fails on
> master due to missing python-gts?
> https://gitlab.com/yade-dev/trunk/issues/139

please review this MR [1]. It fixes build-dependency problem and also
--help regression introduced with "--stdperformance" option.

> And in meantime I will include minieigen sources in yade tree, just
> like we did with python-gts. By this way it will work for everyone
> without dependency hell, until the changes are in official minieigen
> repository.

Can we avoid it somehow? minieigen sources were in Yade tree many years
ago and we managed to drop them, introducing minieigen packages.
It would not be the best variant to put them in the source again.

[1] https://gitlab.com/yade-dev/trunk/-/merge_requests/396

Regards

Anton

Am Mo., 27. Jan. 2020 um 16:26 Uhr schrieb Janek Kozicki (yade)
:
>
> Anton Gladky said: (by the date of Thu, 23 Jan 2020 06:44:02)
>
> > I do really appreciate this kind of work!
> > But how can we rely on custom builds of the third party software?
> > Sorry, but this restriction will get Yade into the dependency hell.
>
> Yes, I completely agree with this premise. I will prepare merge
> request for Vaclav in https://github.com/eudoxos/minieigen
>
> And in meantime I will include minieigen sources in yade tree, just
> like we did with python-gts. By this way it will work for everyone
> without dependency hell, until the changes are in official minieigen
> repository.
>
> thanks a lot for your work.
>
> best regards
> Janek
>
> BTW, Anton did you notice that building debian package fails on
> master due to missing python-gts?
> https://gitlab.com/yade-dev/trunk/issues/139
>
>
> Janek Kozicki (yade) said: (by the date of Mon, 13 Jan 2020 22:34:25 
> +0100)
>
> > Hi, the code for high precision is complete and passes all the tests.
> >
> > I am writing documentation for this now, I will mention there:
> > - about VTK ↔ double compatibility
> > - about GLViewer ↔ double compatibility
> > - how to build and run high precision code
> >
> > I have separated most of this work in to several "topic" merge
> > requests, so that you can check each of them separately. The general
> > idea is that "if you don't use high-precision then the old behavior
> > remains". Meaning that I avoid modifying existing code, only add some
> > sort of redirection and conversion layer that vanishes (is optimized
> > away) completely when HP is not used.
> >
> > There are some changes still not extracted into separate merge
> > requests from !366. I will continue working on this and writing 
> > documentation.
> >
> > These are ready for you to review:
> >
> > * The last remaining double to Real changes.
> >   https://gitlab.com/yade-dev/trunk/merge_requests/376
> >
> > * Print time spent on each of the --checks
> >   https://gitlab.com/yade-dev/trunk/merge_requests/375
> >   (a very short one, that's because I needed to make Lubrication tests 
> > faster in !366)
> >
> > * Ensure that VTK is compatibile with Real.
> >   https://gitlab.com/yade-dev/trunk/merge_requests/377
> >
> > * OpenGL Real compatibility
> >   https://gitlab.com/yade-dev/trunk/merge_requests/378
> >
> > * Another step towards enabling high precision Real
> >   https://gitlab.com/yade-dev/trunk/merge_requests/362
> >
> > * Enable vectorization
> >   https://gitlab.com/yade-dev/trunk/merge_requests/365
> >
> > They can be merged to master in any order. If any rebase conflicts
> > arise I will solve them quickly. Maybe !362 and !365 should be merged last,
> > because I tested rebasing it on each of the previous ones.
> >
> >
> > please tell me what you think.
> >
> > best regards
> > Janek
> >
> >
> >
> > --
> > Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> > Gdańsk University of Technology
> > Faculty of Applied Physics and Mathematics
> > Department of Theoretical Physics and Quantum Information
> > --
> > http://yade-dem.org/
> > http://pg.edu.pl/jkozicki (click English flag on top right)
> >
> > ___
> > Mailing list: https://launchpad.net/~yade-dev
> > Post to : yade-dev@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~yade-dev
> > More help   : https://help.launchpad.net/ListHelp
>
>
> --
> --
> Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> Gdańsk University of Technology
> Faculty of Applied Physics and Mathematics
> Department of Theoretical Physics and Quantum Information
> --
> http://yade-dem.org/
> http://pg.edu.pl/jkozicki (click English flag on top right)

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] New yade release is planned for Jan 2020

[Anton Gladky]

Hello,

would you be able to finish till the end of this week?

Yade is currently not in Debian testing, so we are  in risk not to get it
to the Ubuntu 20.04.

Regards

Anton




On Tue, Jan 7, 2020, 21:30 Deepak Kn  wrote:

> Hello,
> Thank you very much, I have modified some of the parts in the openfoam
> coupling and I'm currently validating it and updating the documentation.
> Can we fix a date, say : 13th Jan (coming monday ? )
>
> On Tue, Jan 7, 2020 at 12:53 PM Janek Kozicki (yade) <
> jkozicki-y...@pg.edu.pl> wrote:
>
>> This is great. Thank you very much for your hard work!
>>
>>
>> Anton Gladky said: (by the date of Mon, 6 Jan 2020 21:04:35 +0100)
>>
>> > Dear Yade developers,
>> >
>> > I am starting to tag the new release. It happens within the next few
>> days.
>> >
>> > Regards
>> >
>> > Anton
>> >
>> > Am Di., 10. Dez. 2019 um 12:55 Uhr schrieb Bruno Chareyre
>> > :
>> > >
>> > > Thanks Anton, I think the timing is good. It actually will be a major
>> release considering py3 and mpi support. Minimal doc for mpi should be
>> complete by that time.
>> > >
>> > > I was also planning to name a 3rd edition of the doc with additional
>> authors.
>> > >
>> > > Cheers
>> > >
>> > > Bruno
>> > >
>> > > Le lun. 9 déc. 2019 21:56, Anton Gladky  a
>> écrit :
>> > >>
>> > >> Dear Yade developers,
>> > >>
>> > >> at the beginning of January 2020 I am planning to tag
>> > >> newer Yade version. After that it will be uploaded into
>> > >> the Debian and automatically synced into the next
>> > >> Ubuntu LTS 20.04.
>> > >>
>> > >> If you are planning some more changes to be pushed into
>> > >> this version, please prepare merge requests till the end of this
>> > >> year. Plan some time for review/pipelines etc.
>> > >>
>> > >> Also it would be good to fo through the list of known issues
>> > >> and fix/close as much as possible.
>> > >>
>> > >> If you have some good reasons to delay the release - please
>> > >> let me know.
>> > >>
>> > >> Thanks and best regards
>> > >>
>> > >> Anton
>> > >>
>> > >> ___
>> > >> Mailing list: https://launchpad.net/~yade-dev
>> > >> Post to : yade-dev@lists.launchpad.net
>> > >> Unsubscribe : https://launchpad.net/~yade-dev
>> > >> More help   : https://help.launchpad.net/ListHelp
>> > >>
>> > >>
>> > > ___
>> > > Mailing list: https://launchpad.net/~yade-dev
>> > > Post to : yade-dev@lists.launchpad.net
>> > > Unsubscribe : https://launchpad.net/~yade-dev
>> > > More help   : https://help.launchpad.net/ListHelp
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~yade-dev
>> > Post to : yade-dev@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~yade-dev
>> > More help   : https://help.launchpad.net/ListHelp
>>
>>
>> --
>> --
>> Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
>> Gdańsk University of Technology
>> Faculty of Applied Physics and Mathematics
>> Department of Theoretical Physics and Quantum Information
>> --
>> http://yade-dem.org/
>> http://pg.edu.pl/jkozicki (click English flag on top right)
>>
>> ___
>> Mailing list: https://launchpad.net/~yade-dev
>> Post to : yade-dev@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~yade-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] New yade release is planned for Jan 2020

[Anton Gladky]

Dear Yade developers,

I am starting to tag the new release. It happens within the next few days.

Regards

Anton

Am Di., 10. Dez. 2019 um 12:55 Uhr schrieb Bruno Chareyre
:
>
> Thanks Anton, I think the timing is good. It actually will be a major release 
> considering py3 and mpi support. Minimal doc for mpi should be complete by 
> that time.
>
> I was also planning to name a 3rd edition of the doc with additional authors.
>
> Cheers
>
> Bruno
>
> Le lun. 9 déc. 2019 21:56, Anton Gladky  a écrit :
>>
>> Dear Yade developers,
>>
>> at the beginning of January 2020 I am planning to tag
>> newer Yade version. After that it will be uploaded into
>> the Debian and automatically synced into the next
>> Ubuntu LTS 20.04.
>>
>> If you are planning some more changes to be pushed into
>> this version, please prepare merge requests till the end of this
>> year. Plan some time for review/pipelines etc.
>>
>> Also it would be good to fo through the list of known issues
>> and fix/close as much as possible.
>>
>> If you have some good reasons to delay the release - please
>> let me know.
>>
>> Thanks and best regards
>>
>> Anton
>>
>> ___
>> Mailing list: https://launchpad.net/~yade-dev
>> Post to : yade-dev@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~yade-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] new bullseye image - problems building master, again Doc building problem.

[Anton Gladky]

We can temporarily try to switch to debian:sid, where this
problem is probably fixed a couple of days ago.

Anton

Am Di., 31. Dez. 2019 um 23:38 Uhr schrieb Janek Kozicki (yade)
:
>
> Maybe I should patch our bullseye image with your patch?
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=946481;filename=python3.8.patch;msg=5
>
>
>
> Anton Gladky said: (by the date of Tue, 31 Dec 2019 15:35:16 +0100)
>
> > This is ipython problem.
> >
> > On Tue, Dec 31, 2019, 13:46 Janek Kozicki (yade) 
> > wrote:
> >
> > > It seems that now we have the same doc building problem as before:
> > >
> > > https://gitlab.com/yade-dev/trunk/-/jobs/391247986
> > >
> > >  reading sources... [ 24%] index-toctree
> > >  reading sources... [ 26%] index-toctree-book
> > >  reading sources... [ 28%] index-toctree-manuals
> > >  reading sources... [ 30%] index-toctree-reference
> > >  reading sources... [ 32%] index-toctree-theory
> > >  reading sources... [ 33%] index-toctree_manuals
> > >  reading sources... [ 35%] installation
> > >  reading sources... [ 37%] introduction
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Janek Kozicki (yade) said: (by the date of Mon, 30 Dec 2019 14:28:17
> > > +0100)
> > >
> > > > Janek Kozicki (yade) said: (by the date of Mon, 30 Dec 2019 14:00:50
> > > +0100)
> > > >
> > > > > Regarding the version numbers I made an MR which workarounds the
> > > problem:
> > > > >
> > > > > https://gitlab.com/yade-dev/trunk/merge_requests/367
> > > > >
> > > > > I am not sure if that's the correct way to go. Isn't there something
> > > > > wrong with bullseye python versions right now?
> > > >
> > > >
> > > > If the rest is working, then perhaps that test was a bit too
> > > > restrictive before.
> > > >
> > > >
> > > > >
> > > > > This is the history of the pipelines for last commit in master:
> > > > >
> > > > >
> > > https://gitlab.com/yade-dev/trunk/commit/0b6b10845892801b0893be211e011bdc1707f8cd/pipelines?ref=master
> > > > >
> > > > > We can see when it stopped working.
> > > > >
> > > > > Interestingly the libCGAL problem seems to disappear for now?
> > > > >
> > > > > best regards
> > > > > Janek
> > > > >
> > > > >
> > > > >
> > > > > Janek Kozicki (yade) said: (by the date of Sun, 29 Dec 2019
> > > 20:41:59 +0100)
> > > > >
> > > > > > I just noticed following problems after new bullseye image has been
> > > built:
> > > > > >
> > > > > > ImportError: libCGAL.so.13: cannot open shared object file: No such
> > > > > > file or directory
> > > > > >
> > > > > >
> > > > > >
> > > > > > Image was built 14h ago:
> > > > > > container registry:
> > > https://gitlab.com/yade-dev/docker-yade/container_registry
> > > > > >
> > > > > >
> > > > > > Also in the pipeline in one of my MRs I found:
> > > > > >
> > > > > > python version reported by by cmake is  [(3, 8, 0), '3.8']  and by
> > > > > > C++ is  [(3, 7, 5), '3.7.5']
> > > > > >
> > > > > > We can workaround this one, but is this intended behavior?
> > > > > >
> > > > > > best regards
> > > > > > Janek
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> > > > > > Gdańsk University of Technology
> > > > > > Faculty of Applied Physics and Mathematics
> > > > > > Department of Theoretical Physics and Quantum Information
> > > > > > --
> > > > > > http://yade-dem.org/
> > > > > > http://pg.edu.pl/jkozicki (click English flag on top right)
> > > > > >
> > > > > > ___
> > > > > > Mailing list: https://launchpad.net/~yade-dev
> > > > > > Post to : yade

Re: [Yade-dev] new bullseye image - problems building master, again Doc building problem.

[Anton Gladky]

This is ipython problem.

On Tue, Dec 31, 2019, 13:46 Janek Kozicki (yade) 
wrote:

> It seems that now we have the same doc building problem as before:
>
> https://gitlab.com/yade-dev/trunk/-/jobs/391247986
>
>  reading sources... [ 24%] index-toctree
>  reading sources... [ 26%] index-toctree-book
>  reading sources... [ 28%] index-toctree-manuals
>  reading sources... [ 30%] index-toctree-reference
>  reading sources... [ 32%] index-toctree-theory
>  reading sources... [ 33%] index-toctree_manuals
>  reading sources... [ 35%] installation
>  reading sources... [ 37%] introduction
>
>
>
>
>
>
>
>
> Janek Kozicki (yade) said: (by the date of Mon, 30 Dec 2019 14:28:17
> +0100)
>
> > Janek Kozicki (yade) said: (by the date of Mon, 30 Dec 2019 14:00:50
> +0100)
> >
> > > Regarding the version numbers I made an MR which workarounds the
> problem:
> > >
> > > https://gitlab.com/yade-dev/trunk/merge_requests/367
> > >
> > > I am not sure if that's the correct way to go. Isn't there something
> > > wrong with bullseye python versions right now?
> >
> >
> > If the rest is working, then perhaps that test was a bit too
> > restrictive before.
> >
> >
> > >
> > > This is the history of the pipelines for last commit in master:
> > >
> > >
> https://gitlab.com/yade-dev/trunk/commit/0b6b10845892801b0893be211e011bdc1707f8cd/pipelines?ref=master
> > >
> > > We can see when it stopped working.
> > >
> > > Interestingly the libCGAL problem seems to disappear for now?
> > >
> > > best regards
> > > Janek
> > >
> > >
> > >
> > > Janek Kozicki (yade) said: (by the date of Sun, 29 Dec 2019
> 20:41:59 +0100)
> > >
> > > > I just noticed following problems after new bullseye image has been
> built:
> > > >
> > > > ImportError: libCGAL.so.13: cannot open shared object file: No such
> > > > file or directory
> > > >
> > > >
> > > >
> > > > Image was built 14h ago:
> > > > container registry:
> https://gitlab.com/yade-dev/docker-yade/container_registry
> > > >
> > > >
> > > > Also in the pipeline in one of my MRs I found:
> > > >
> > > > python version reported by by cmake is  [(3, 8, 0), '3.8']  and by
> > > > C++ is  [(3, 7, 5), '3.7.5']
> > > >
> > > > We can workaround this one, but is this intended behavior?
> > > >
> > > > best regards
> > > > Janek
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> > > > Gdańsk University of Technology
> > > > Faculty of Applied Physics and Mathematics
> > > > Department of Theoretical Physics and Quantum Information
> > > > --
> > > > http://yade-dem.org/
> > > > http://pg.edu.pl/jkozicki (click English flag on top right)
> > > >
> > > > ___
> > > > Mailing list: https://launchpad.net/~yade-dev
> > > > Post to : yade-dev@lists.launchpad.net
> > > > Unsubscribe : https://launchpad.net/~yade-dev
> > > > More help   : https://help.launchpad.net/ListHelp
> > >
> > >
> > > --
> > > --
> > > Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> > > Gdańsk University of Technology
> > > Faculty of Applied Physics and Mathematics
> > > Department of Theoretical Physics and Quantum Information
> > > --
> > > http://yade-dem.org/
> > > http://pg.edu.pl/jkozicki (click English flag on top right)
> > >
> > > ___
> > > Mailing list: https://launchpad.net/~yade-dev
> > > Post to : yade-dev@lists.launchpad.net
> > > Unsubscribe : https://launchpad.net/~yade-dev
> > > More help   : https://help.launchpad.net/ListHelp
> >
> >
> > --
> > --
> > Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> > Gdańsk University of Technology
> > Faculty of Applied Physics and Mathematics
> > Department of Theoretical Physics and Quantum Information
> > --
> > http://yade-dem.org/
> > http://pg.edu.pl/jkozicki (click English flag on top right)
> >
> > ___
> > Mailing list: https://launchpad.net/~yade-dev
> > Post to : yade-dev@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~yade-dev
> > More help   : https://help.launchpad.net/ListHelp
>
>
> --
> --
> Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> Gdańsk University of Technology
> Faculty of Applied Physics and Mathematics
> Department of Theoretical Physics and Quantum Information
> --
> http://yade-dem.org/
> http://pg.edu.pl/jkozicki (click English flag on top right)
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] New yade release is planned for Jan 2020

[Anton Gladky]

Dear Yade developers,

at the beginning of January 2020 I am planning to tag
newer Yade version. After that it will be uploaded into
the Debian and automatically synced into the next
Ubuntu LTS 20.04.

If you are planning some more changes to be pushed into
this version, please prepare merge requests till the end of this
year. Plan some time for review/pipelines etc.

Also it would be good to fo through the list of known issues
and fix/close as much as possible.

If you have some good reasons to delay the release - please
let me know.

Thanks and best regards

Anton

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Doc building problem

[Anton Gladky]

The problem was really in python3.8 and ipython in Debian Sid.

See:

https://bugs.debian.org/946481

Anton

Am Di., 3. Dez. 2019 um 21:58 Uhr schrieb Anton Gladky :
>
> Hi Bruno,
>
> thanks for the hint. It looks like the problem is due to
> ongoing Python3.7->Python3.8 transition. We'll see.
>
> Regards
>
> Anton
>
> Am Di., 3. Dez. 2019 um 16:27 Uhr schrieb Bruno Chareyre
> :
> >
> > Hi Anton,
> > A recent change coming to mind is [1] (and I'm not super-familiar with 
> > commenting a line in sphinx), it's easily reverted if you want to check.
> > Nothing else comes to mind.
> > B
> >
> > [1] 
> > https://gitlab.com/yade-dev/trunk/commit/33601df81df0a74f5d4618bc8dbf4e54159f6352
> >
> > On Mon, 2 Dec 2019 at 22:02, Anton Gladky  wrote:
> >>
> >> Hmm,
> >>
> >> it looks like the problem is in debian:sid, in debian:bullseye everything 
> >> is
> >> working as expected.
> >>
> >> Anton
> >>
> >> Am Mo., 2. Dez. 2019 um 20:02 Uhr schrieb Anton Gladky 
> >> :
> >> >
> >> > Hello all,
> >> >
> >> > I am preparing the newer Yade for the Debian and upcoming Ubuntu LTS.
> >> > It will be python3-only build. A couple of weeks ago the build worked 
> >> > fine.
> >> > But now, the compilation stucks on building docs:
> >> >
> >> > ==
> >> > building [mo]: all of 0 po files
> >> > building [html]: all source files
> >> > updating environment: 53 added, 0 changed, 0 removed
> >> > reading sources... [  1%] FEMxDEM
> >> > reading sources... [  3%] FoamCoupling
> >> > reading sources... [  5%] GPUacceleration
> >> > reading sources... [  7%] HydroForceEngine
> >> > reading sources... [  9%] acousticemissions
> >> > reading sources... [ 11%] amazonEC2
> >> > reading sources... [ 13%] citing
> >> > reading sources... [ 15%] consulting
> >> > reading sources... [ 16%] formulation
> >> > reading sources... [ 18%] formulation-link
> >> > reading sources... [ 20%] github
> >> > reading sources... [ 22%] gitrepo
> >> > reading sources... [ 24%] index-toctree
> >> > reading sources... [ 26%] index-toctree-book
> >> > reading sources... [ 28%] index-toctree-manuals
> >> > reading sources... [ 30%] index-toctree-reference
> >> > reading sources... [ 32%] index-toctree-theory
> >> > reading sources... [ 33%] index-toctree_manuals
> >> > reading sources... [ 35%] installation
> >> > reading sources... [ 37%] introduction
> >> > ==
> >> >
> >> > And nothing more. Has anybody ideas, why it happens?
> >> >
> >> > Thanks
> >> >
> >> > Anton
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~yade-dev
> >> Post to : yade-dev@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~yade-dev
> >> More help   : https://help.launchpad.net/ListHelp
> >>
> >>
> >
> >
> > --
> > --
> > ___
> > Bruno Chareyre
> > Associate Professor
> > ENSE³ - Grenoble INP
> > Lab. 3SR
> > BP 53
> > 38041 Grenoble cedex 9
> > Tél : +33 4 56 52 86 21
> > 
> >
> > Email too brief?
> > Here's why: email charter
> > ___
> > Mailing list: https://launchpad.net/~yade-dev
> > Post to : yade-dev@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~yade-dev
> > More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Doc building problem

[Anton Gladky]

Hi Bruno,

thanks for the hint. It looks like the problem is due to
ongoing Python3.7->Python3.8 transition. We'll see.

Regards

Anton

Am Di., 3. Dez. 2019 um 16:27 Uhr schrieb Bruno Chareyre
:
>
> Hi Anton,
> A recent change coming to mind is [1] (and I'm not super-familiar with 
> commenting a line in sphinx), it's easily reverted if you want to check.
> Nothing else comes to mind.
> B
>
> [1] 
> https://gitlab.com/yade-dev/trunk/commit/33601df81df0a74f5d4618bc8dbf4e54159f6352
>
> On Mon, 2 Dec 2019 at 22:02, Anton Gladky  wrote:
>>
>> Hmm,
>>
>> it looks like the problem is in debian:sid, in debian:bullseye everything is
>> working as expected.
>>
>> Anton
>>
>> Am Mo., 2. Dez. 2019 um 20:02 Uhr schrieb Anton Gladky 
>> :
>> >
>> > Hello all,
>> >
>> > I am preparing the newer Yade for the Debian and upcoming Ubuntu LTS.
>> > It will be python3-only build. A couple of weeks ago the build worked fine.
>> > But now, the compilation stucks on building docs:
>> >
>> > ==
>> > building [mo]: all of 0 po files
>> > building [html]: all source files
>> > updating environment: 53 added, 0 changed, 0 removed
>> > reading sources... [  1%] FEMxDEM
>> > reading sources... [  3%] FoamCoupling
>> > reading sources... [  5%] GPUacceleration
>> > reading sources... [  7%] HydroForceEngine
>> > reading sources... [  9%] acousticemissions
>> > reading sources... [ 11%] amazonEC2
>> > reading sources... [ 13%] citing
>> > reading sources... [ 15%] consulting
>> > reading sources... [ 16%] formulation
>> > reading sources... [ 18%] formulation-link
>> > reading sources... [ 20%] github
>> > reading sources... [ 22%] gitrepo
>> > reading sources... [ 24%] index-toctree
>> > reading sources... [ 26%] index-toctree-book
>> > reading sources... [ 28%] index-toctree-manuals
>> > reading sources... [ 30%] index-toctree-reference
>> > reading sources... [ 32%] index-toctree-theory
>> > reading sources... [ 33%] index-toctree_manuals
>> > reading sources... [ 35%] installation
>> > reading sources... [ 37%] introduction
>> > ==
>> >
>> > And nothing more. Has anybody ideas, why it happens?
>> >
>> > Thanks
>> >
>> > Anton
>>
>> ___
>> Mailing list: https://launchpad.net/~yade-dev
>> Post to : yade-dev@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~yade-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> --
> ___
> Bruno Chareyre
> Associate Professor
> ENSE³ - Grenoble INP
> Lab. 3SR
> BP 53
> 38041 Grenoble cedex 9
> Tél : +33 4 56 52 86 21
> 
>
> Email too brief?
> Here's why: email charter
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Doc building problem

[Anton Gladky]

Hmm,

it looks like the problem is in debian:sid, in debian:bullseye everything is
working as expected.

Anton

Am Mo., 2. Dez. 2019 um 20:02 Uhr schrieb Anton Gladky :
>
> Hello all,
>
> I am preparing the newer Yade for the Debian and upcoming Ubuntu LTS.
> It will be python3-only build. A couple of weeks ago the build worked fine.
> But now, the compilation stucks on building docs:
>
> ==
> building [mo]: all of 0 po files
> building [html]: all source files
> updating environment: 53 added, 0 changed, 0 removed
> reading sources... [  1%] FEMxDEM
> reading sources... [  3%] FoamCoupling
> reading sources... [  5%] GPUacceleration
> reading sources... [  7%] HydroForceEngine
> reading sources... [  9%] acousticemissions
> reading sources... [ 11%] amazonEC2
> reading sources... [ 13%] citing
> reading sources... [ 15%] consulting
> reading sources... [ 16%] formulation
> reading sources... [ 18%] formulation-link
> reading sources... [ 20%] github
> reading sources... [ 22%] gitrepo
> reading sources... [ 24%] index-toctree
> reading sources... [ 26%] index-toctree-book
> reading sources... [ 28%] index-toctree-manuals
> reading sources... [ 30%] index-toctree-reference
> reading sources... [ 32%] index-toctree-theory
> reading sources... [ 33%] index-toctree_manuals
> reading sources... [ 35%] installation
> reading sources... [ 37%] introduction
> ==
>
> And nothing more. Has anybody ideas, why it happens?
>
> Thanks
>
> Anton

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] Doc building problem

[Anton Gladky]

Hello all,

I am preparing the newer Yade for the Debian and upcoming Ubuntu LTS.
It will be python3-only build. A couple of weeks ago the build worked fine.
But now, the compilation stucks on building docs:

==
building [mo]: all of 0 po files
building [html]: all source files
updating environment: 53 added, 0 changed, 0 removed
reading sources... [  1%] FEMxDEM
reading sources... [  3%] FoamCoupling
reading sources... [  5%] GPUacceleration
reading sources... [  7%] HydroForceEngine
reading sources... [  9%] acousticemissions
reading sources... [ 11%] amazonEC2
reading sources... [ 13%] citing
reading sources... [ 15%] consulting
reading sources... [ 16%] formulation
reading sources... [ 18%] formulation-link
reading sources... [ 20%] github
reading sources... [ 22%] gitrepo
reading sources... [ 24%] index-toctree
reading sources... [ 26%] index-toctree-book
reading sources... [ 28%] index-toctree-manuals
reading sources... [ 30%] index-toctree-reference
reading sources... [ 32%] index-toctree-theory
reading sources... [ 33%] index-toctree_manuals
reading sources... [ 35%] installation
reading sources... [ 37%] introduction
==

And nothing more. Has anybody ideas, why it happens?

Thanks

Anton

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] gitlab artifacts missing

[Anton Gladky]

Hallo Bruno,

could you please send me a script, which is doing the download/upload?

Actually, when I do

"wget 
https://gitlab.com/yade-dev/trunk/-/jobs/artifacts/master/download?job=pages;

I get right now the error code 8.

Actually, if you use the symbol &&, it will not execute the next step,
if the previous one failed.

Something like:

wget 
https://gitlab.com/yade-dev/trunk/-/jobs/artifacts/master/download?job=pages
&& rm -rf /var/www/yade-dem.org && cp * /var/www/yade-dem.org

should solve the problem. If wget fails, like in this case - rm and cp
will not be executed. And we get old documentation,
but in any case - not the empty pages.

I hope, my writings can be understood :)

Regards

Anton

Am Mi., 13. Nov. 2019 um 18:05 Uhr schrieb Bruno Chareyre
:

>
> Hi there,
> yade-dem.org is currently down while yade-dev.gitlab.io/trunk/ is not.
>
> The reason is that yade server is downloading the gitlab artifacts like this:
> wget 
> https://gitlab.com/yade-dev/trunk/-/jobs/artifacts/master/download?job=pages,
> but at the moment that url returns nothing. Hence empty website.
>
> Obviously our script should test the output of wget, to not replace the 
> content by nothing. We can fix this. Even so, I would like to understand why 
> the artifacts are not there. They usually are. Is it because they expired on 
> gitlab? Is it because of a failed pipeline?
> Maybe we should form another url to try and get the content of 
> yade-dev.gitlab.io/trunk/ (if possibe) instead of checking out an artifact.
> I don't have time to check more right now so in case someone has inspiration, 
> let me know:
> - if you know how to make wget conditional
> - if you know a better target url
>
> Cheers
>
> Bruno
>
> --
> --
> ___
> Bruno Chareyre
> Associate Professor
> ENSE³ - Grenoble INP
> Lab. 3SR
> BP 53
> 38041 Grenoble cedex 9
> Tél : +33 4 56 52 86 21
> 
>
> Email too brief?
> Here's why: email charter
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] [Bug 1852197] Re: Segmentation fault on pfacet gridconnection contact

[Anton Gladky]

Ok, found, changed the path to memoizeDb. ASAN says:


=
==5085==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 
0x7f7d59ac2c6f bp 0x7f7d40cf7ac0 sp 0x7f7d40cf61d0 T16777215)
==5085==The signal is caused by a READ memory access.
==5085==Hint: address points to the zero page.
In [5]: #0 0x7f7d59ac2c6e in 
yade::Bo1_PFacet_Aabb::go(boost::shared_ptr const&, 
boost::shared_ptr&, yade::Se3 const&, yade::Body const*) 
/trunk/pkg/common/PFacet.cpp:817
#1 0x7f7d59141278 in 
yade::BoundDispatcher::processBody(boost::shared_ptr const&) 
/trunk/pkg/common/Dispatching.cpp:54
#2 0x7f7d59142ded in yade::BoundDispatcher::action() [clone ._omp_fn.0] 
/trunk/pkg/common/Dispatching.cpp:36
#3 0x7f7d50c11e0e in GOMP_parallel 
(/lib/x86_64-linux-gnu/libgomp.so.1+0xde0e)
#4 0x7f7d591433ee in yade::BoundDispatcher::action() 
/trunk/pkg/common/Dispatching.cpp:31
#5 0x7f7d59821812 in yade::InsertionSortCollider::action() 
/trunk/pkg/common/InsertionSortCollider.cpp:309
#6 0x7f7d58c04381 in yade::Scene::moveToNextTimeStep() 
/trunk/core/Scene.cpp:98
#7 0x7f7d58c12613 in yade::SimulationFlow::singleAction() 
/trunk/core/SimulationFlow.cpp:26
#8 0x7f7d58ccefc7 in yade::ThreadWorker::callSingleAction() 
/trunk/core/ThreadWorker.cpp:73
#9 0x7f7d58cc5259 in yade::ThreadRunner::call() 
/trunk/core/ThreadRunner.cpp:54
#10 0x7f7d58cc71cf in yade::ThreadRunner::run() 
/trunk/core/ThreadRunner.cpp:28
#11 0x7f7d58cc74c8 in boost::_mfi::mf0::operator()(yade::ThreadRunner*) const 
/usr/include/boost/bind/mem_fn_template.hpp:49
#12 0x7f7d58cc74c8 in void 
boost::_bi::list1 
>::operator(), 
boost::_bi::list0>(boost::_bi::type, boost::_mfi::mf0&, boost::_bi::list0&, int) 
/usr/include/boost/bind/bind.hpp:259
#13 0x7f7d58cc74c8 in boost::_bi::bind_t, boost::_bi::list1 > 
>::operator()() /usr/include/boost/bind/bind.hpp:1294
#14 0x7f7d58cc74c8 in 
boost::detail::function::void_function_obj_invoker0, 
boost::_bi::list1 > >, 
void>::invoke(boost::detail::function::function_buffer&) 
/usr/include/boost/function/function_template.hpp:159
#15 0x7f7d58cccf6b in boost::function0::operator()() const 
/usr/include/boost/function/function_template.hpp:768
#16 0x7f7d58cccf6b in boost::detail::thread_data 
>::run() /usr/include/boost/thread/detail/thread.hpp:117
#17 0x7f7d55a39f64  
(/lib/x86_64-linux-gnu/libboost_thread.so.1.67.0+0x14f64)
#18 0x7f7d5f80afa2 in start_thread 
/build/glibc-vjB4T1/glibc-2.28/nptl/pthread_create.c:486
#19 0x7f7d5f3514ce in clone (/lib/x86_64-linux-gnu/libc.so.6+0xf94ce)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /trunk/pkg/common/PFacet.cpp:817 in 
yade::Bo1_PFacet_Aabb::go(boost::shared_ptr const&, 
boost::shared_ptr&, yade::Se3 const&, yade::Body const*)
==5085==ABORTING

=

Could you please file a bug on gitlab with this content? Thanks

-- 
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1852197

Title:
  Segmentation fault on pfacet gridconnection contact

Status in Yade:
  New

Bug description:
  I seem to get a Segmentation fault (core dumped) when using
  GridConnection, PFacet, and randomDensePack. And I am not sure why. I
  have attached an image and "working" example.

  
  Thanks in advance,
  Justin


  Edit: I could not seem to upload an picture or example code. Thus code
  below:

  
  from yade.gridpfacet import *
  import numpy as np
  from yade import utils
  from yade import ymport
  import sys,time,math,random

  from yade import qt
  qt.View()

  #print(os.path.basename(__file__))
  #quit()
  ### ParallelEngine, -j4

  boxCenter = (0,0,.025)
  ## double check that /2 would create correct length, I.e., import based_70 to 
see if they match... they should
  boxDem = (.2123/2,.212/2,.064/2)  ### based_70 is 212.3x212.21x63.65

  boxDem = (.07,.07,.025)  ###

  blen = boxDem[0]*2  ## Length of Ball pit
  bhei = .025   ## Height of Ball pit

  # Spheres information
  sphereRadius = .004 # [m]
  nu = .48 
  #G = 30 # [Pa]
  den_rub = 89724 # [kg/m^3]
  yng_rub = 300 # [Pa] 
  fric_rub = radians(38)  # [degrees] 
  
O.materials.append(FrictMat(frictionAngle=fric_rub,young=yng_rub,density=den_rub,poisson=nu,label='rubber'))
  O.materials.append(FrictMat(young=200e9,density=8050,poisson=.3, 
label='steel')) # used steel properties to make rigid

  ## Stud informtion
  #studStartZ = (.01+.022+.01905)
  studStartZ = (.01+bhei+.01905)
  transVel = 0.000222*2
  rotVel = 0.00872665*2

  ### pack auto fills, i.e., I no longer pick the amount of spheres
  pred = 
pack.inAlignedBox((-(boxDem[0]-.001),-(boxDem[0]-.001),bhei+sphereRadius/2+.001),((boxDem[0]-.001),(boxDem[0]-.001),bhei+.045))
  sp = pack.randomDensePack(pred, radius=sphereRadius, 
memoizeDb='tmp/single_grass.sqlite', returnSpherePack=True)
  sp.toSimulation(wire=False,material='rubber')

  ## Time step 

[Yade-dev] [Bug 1852197] Re: Segmentation fault on pfacet gridconnection contact

[Anton Gladky]

I am getting this error:

Traceback (most recent call last):
  File "./../inst/bin/yade-trunk", line 337, in runScript
execfile(script,globals())
  File "/usr/lib/python3/dist-packages/past/builtins/misc.py", line 82, in 
execfile
exec_(code, myglobals, mylocals)
  File "2.py", line 41, in 
sp = pack.randomDensePack(pred, radius=sphereRadius, 
memoizeDb='tmp/single_grass.sqlite', returnSpherePack=True)
  File 
"/home/anton/dem/yade/inst/lib/x86_64-linux-gnu/yade-trunk/py/yade/pack.py", 
line 559, in randomDensePack
_memoizePacking(memoizeDb,sp,radius,rRelFuzz,wantPeri,fullDim)
  File 
"/home/anton/dem/yade/inst/lib/x86_64-linux-gnu/yade-trunk/py/yade/pack.py", 
line 400, in _memoizePacking
conn=sqlite3.connect(memoizeDb)
sqlite3.OperationalError: unable to open database file
[[ ^L clears screen, ^U kills line. F12 controller, F11 3D view (press "h" in 
3D view for help), F10 both, F9 generator, F8 plot. ]]

-- 
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1852197

Title:
  Segmentation fault on pfacet gridconnection contact

Status in Yade:
  New

Bug description:
  I seem to get a Segmentation fault (core dumped) when using
  GridConnection, PFacet, and randomDensePack. And I am not sure why. I
  have attached an image and "working" example.

  
  Thanks in advance,
  Justin


  Edit: I could not seem to upload an picture or example code. Thus code
  below:

  
  from yade.gridpfacet import *
  import numpy as np
  from yade import utils
  from yade import ymport
  import sys,time,math,random

  from yade import qt
  qt.View()

  #print(os.path.basename(__file__))
  #quit()
  ### ParallelEngine, -j4

  boxCenter = (0,0,.025)
  ## double check that /2 would create correct length, I.e., import based_70 to 
see if they match... they should
  boxDem = (.2123/2,.212/2,.064/2)  ### based_70 is 212.3x212.21x63.65

  boxDem = (.07,.07,.025)  ###

  blen = boxDem[0]*2  ## Length of Ball pit
  bhei = .025   ## Height of Ball pit

  # Spheres information
  sphereRadius = .004 # [m]
  nu = .48 
  #G = 30 # [Pa]
  den_rub = 89724 # [kg/m^3]
  yng_rub = 300 # [Pa] 
  fric_rub = radians(38)  # [degrees] 
  
O.materials.append(FrictMat(frictionAngle=fric_rub,young=yng_rub,density=den_rub,poisson=nu,label='rubber'))
  O.materials.append(FrictMat(young=200e9,density=8050,poisson=.3, 
label='steel')) # used steel properties to make rigid

  ## Stud informtion
  #studStartZ = (.01+.022+.01905)
  studStartZ = (.01+bhei+.01905)
  transVel = 0.000222*2
  rotVel = 0.00872665*2

  ### pack auto fills, i.e., I no longer pick the amount of spheres
  pred = 
pack.inAlignedBox((-(boxDem[0]-.001),-(boxDem[0]-.001),bhei+sphereRadius/2+.001),((boxDem[0]-.001),(boxDem[0]-.001),bhei+.045))
  sp = pack.randomDensePack(pred, radius=sphereRadius, 
memoizeDb='tmp/single_grass.sqlite', returnSpherePack=True)
  sp.toSimulation(wire=False,material='rubber')

  ## Time step set to 20% of Rayleigh Wave
  O.dt=.2*utils.RayleighWaveTimeStep() # 0.0011302534626965682
  print(O.dt)

  ### Steps needed to run sim
  sphereFalls = 1000
### Steps spheres need to fall 
and level out and turn on studs
  startRot = sphereFalls+math.floor((studStartZ-bhei-.01)/transVel/O.dt)
### Step needed for transVel to get studs level with spheres

  ## Rotation steps
  deg_to_rad_length = (60*pi/180); # [rad]
  num_sec_roto = deg_to_rad_length/rotVel; # [s]
  num_of_steps_roto = num_sec_roto/O.dt;

  endSim   = startRot + math.floor(num_of_steps_roto)
  ### total steps in sim

  O.engines=[
###Reset all forces stored in Scene::forces (O.forces in 
python). Typically, this is the first engine to be run at every step.  
In addition, reset those energies that should be reset, if energy tracing is 
enabled.
## Resets forces and moments that act on bodies
ForceResetter(),

## Using bounding boxes find possible body collisions.
InsertionSortCollider([
Bo1_Facet_Aabb(), 
Bo1_PFacet_Aabb(),
Bo1_Sphere_Aabb(),
Bo1_GridConnection_Aabb(),
Bo1_PFacet_Aabb(),
]),
InteractionLoop([
Ig2_Facet_Sphere_ScGeom(),
Ig2_Wall_PFacet_ScGeom(),
Ig2_Wall_Sphere_ScGeom(),
Ig2_Sphere_Sphere_ScGeom(),
Ig2_Sphere_GridConnection_ScGridCoGeom(),
Ig2_Sphere_PFacet_ScGridCoGeom(),
Ig2_GridNode_GridNode_GridNodeGeom6D(),
Ig2_GridConnection_GridConnection_GridCoGridCoGeom(),
Ig2_GridConnection_PFacet_ScGeom(),

[Yade-dev] AddressSanitizer is enabled in the CI-pipeline

[Anton Gladky]

Dear Yade developers,

last weekend [1] we enabled the new target in the pipeline: make_asan.
Also the new Yade option ENABLE_ASAN was added into the Cmake.
Documentation is updated correspondingly.

ASAN - is the abbreviation of AddressSanitizer [2] - memory error detector,
which finds heap corruptions, memory overflows etc.

Generally, Yade is being compiled with special compiler flags and then
'-test' and
'--check' steps are being executed. If you add a new engine or any other
class, which is executed by "--test" or "--check" step, you can see in
the pipeline, whether  your code is not doing something weird with the
memory.

It can help to increase the software stability, correctness of the results
and general quality of the software.

If you see some problems with this step in the pipeline - please let me know.

[1] https://gitlab.com/yade-dev/trunk/merge_requests/331
[2] https://github.com/google/sanitizers/wiki/AddressSanitizer

Best regards

Anton

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] clang-format (Was: Re: Removing trailing white space, yay or nay?)

[Anton Gladky]

Hi Bruno,

OK, if we have an agreement on that, we will merge MR 298.
Thus the .clang-format will be in the root of the trunk and people
can start to use it.

We will have a test phase (2-3 months), so we can probably find
and fix some issues in .clang-format, update documentation.
Also CI-pipeline can be prepared, but only with Allow-To-Fail option.

If everything is successful - we can then reformat the files, which were not
formatted on-the go during the test phase. Cang-format-step can then
be switched on strictly in the CI-pipeline.

Best regards

Anton

Am Di., 22. Okt. 2019 um 11:38 Uhr schrieb Bruno Chareyre
:
>
> Thanks Anton, it makes sense to me.
>
> On Mon, 21 Oct 2019 at 21:02, Anton Gladky  wrote:
>>
>> If we do a one-shot-reformatting - it is also OK. But I would then prefer
>> to set the author of this commit, something to "clang-formatter",
>> Just to identify, that this particular change was done by this action.
>
>
> Now I'm unsure myself. Maybe for stable files which we rarely touch the 
> "cons" of reformatting are more than the "pros".
> A special commiter is a very good point. And even if it's done per-file it 
> would be better to have a commit by that clang-formatter on the top of actual 
> commit rather than altogether - so the changes don't get hiden.
>
>>
>>
>> For example, my IDE shows at each line, who was the last author
>> of the particular line  (git blame basically). Sometimes it is useful to 
>> contact
>> the author of the line/code personally.
>
>
> Yep, "git blame" will be meaningless. Fortunately that's not the only way to 
> browse history, but yeah, that's the main downside.
>
>>
>> But again, it is up to the majority to decide, whether to use this tool or 
>> not.
>> But the code is getting more readable, more uniform and professional
>
>
> It would be an improvement in my view.
> Cheers
>
> Bruno
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] clang-format (Was: Re: Removing trailing white space, yay or nay?)

[Anton Gladky]

Hi Bruno,

I think Janek has already answered most of the questions.

> What would be the workflow in general for, let's say, a kdevelop/kate user?

It is supported by most of IDEs, as it is getting to be a standard
tool for industry. The command-line tool will work always though.

> I'm particularly curious about your statement in the giltab thread [1]: 
> "Reformatting everything is not the best idea. It will change everything and 
> can hurt the history. I would propose to do it step by step, only by changing 
> the files."

> Do you suggest that each time a file will be modified it should be also 
> re-formatted, but no systematic reformatting would be done beyond that?
> Isn't it maximizing the risk of mixing real changes with formatting? I would 
> think reformatting everything in one single commit would make the history 
> much more clear.

I do not have a very strong opinion about that. If we do a
one-shot-reformatting - it is also OK. But I would then prefer
to set the author of this commit, something to "clang-formatter",
Just to identify, that this particular change was done by this action.

For example, my IDE shows at each line, who was the last author
of the particular line  (git blame basically). Sometimes it is useful to contact
the author of the line/code personally.

If we decide to use clang-formatter for the project - it will be
better to have it in all IDEs activated permanently. And "on-save"
the IDE will reformat it. It works in most of cases just fine. And
after some time you see, that you feel uncomfortable, if the project
is not using it  :) And yes, such flame-war questions like tabs/spaces,
width, position of braces, trailing whitespaces etc are disappearing
completely.

But again, it is up to the majority to decide, whether to use this tool or not.
But the code is getting more readable, more uniform and professional

Best regards

Anton

Am Mo., 21. Okt. 2019 um 11:57 Uhr schrieb Bruno Chareyre
:


>
> Hi Anton,
> It's not yet all clear to me how it will work.
> What would be the workflow in general for, let's say, a kdevelop/kate user?
> Edit, then "git-clang-format" before commit?
>
> I'm particularly curious about your statement in the giltab thread [1]: 
> "Reformatting everything is not the best idea. It will change everything and 
> can hurt the history. I would propose to do it step by step, only by changing 
> the files."
>
> Do you suggest that each time a file will be modified it should be also 
> re-formatted, but no systematic reformatting would be done beyond that?
> Isn't it maximizing the risk of mixing real changes with formatting? I would 
> think reformatting everything in one single commit would make the history 
> much more clear.
>
> Last thing I'm thinking about: how will we avoid that different authors with 
> (even slightly) different editing tools and auto-formating settings end up in 
> committing conflicting auto-formats?
>
> Bruno
>
> [1] https://gitlab.com/yade-dev/trunk/merge_requests/298#note_233001456
>
>
>
> On Sun, 20 Oct 2019 at 21:47, Anton Gladky  wrote:
>>
>> Dear all,
>>
>> there are several pre-defined styles in the clang-formatter.
>> I have recursively run all of them in the current trunk and I controlled,
>> how many lines were changed (+ lines added, - lines removed)
>>
>>
>> Style | +  | -   | Line length
>> 
>> LLVM  | 95796  | 71398   | 80
>> Google| 95748  | 72468   | 80
>> Chromium  | 104646 | 72689   | ?
>> Mozilla   | 109952 | 70635   | 80
>> WebKit| 76487  | 69974 * | ?
>> Microsoft | 97828  | 73115   | ?
>>
>> As you can see the minimal diff was produced by the
>> WebKit-style. It can be caused by the fact, that some
>> styles are changing the line length of the code. So,
>> this parameter is also in the table.
>>
>> After that I have took the WebKit style and played with
>> the type of indents: spaces, tabs (Always and ForIndentation).
>>
>> UseTab  | IndentWidth  | +  | -
>> 
>> Never   | 1| 77654  | 71141
>> Never   | 2| 73701  | 67188
>> Never   | 4| 76487  | 69974
>> Never   | 6| 78023  | 71510
>> Never   | 8| 77785  | 71272
>> ForIndentation  | 1| 77624  | 7
>> ForIndentation  | 2| 73336  | 66823
>> ForIndentation  | 4| 74727  | 68214
>> ForIndentation  | 6| 77538  | 71025
>> ForIndentation  | 8| 63022  | 56509 *
>> Always  | 1|

[Yade-dev] clang-format (Was: Re: Removing trailing white space, yay or nay?)

[Anton Gladky]

Dear all,

there are several pre-defined styles in the clang-formatter.
I have recursively run all of them in the current trunk and I controlled,
how many lines were changed (+ lines added, - lines removed)


Style | +  | -   | Line length

LLVM  | 95796  | 71398   | 80
Google| 95748  | 72468   | 80
Chromium  | 104646 | 72689   | ?
Mozilla   | 109952 | 70635   | 80
WebKit| 76487  | 69974 * | ?
Microsoft | 97828  | 73115   | ?

As you can see the minimal diff was produced by the
WebKit-style. It can be caused by the fact, that some
styles are changing the line length of the code. So,
this parameter is also in the table.

After that I have took the WebKit style and played with
the type of indents: spaces, tabs (Always and ForIndentation).

UseTab  | IndentWidth  | +  | -

Never   | 1| 77654  | 71141
Never   | 2| 73701  | 67188
Never   | 4| 76487  | 69974
Never   | 6| 78023  | 71510
Never   | 8| 77785  | 71272
ForIndentation  | 1| 77624  | 7
ForIndentation  | 2| 73336  | 66823
ForIndentation  | 4| 74727  | 68214
ForIndentation  | 6| 77538  | 71025
ForIndentation  | 8| 63022  | 56509 *
Always  | 1| 77623  | 71110
Always  | 2| 73340  | 66827
Always  | 4| 74722  | 68209
Always  | 8| 63013  | 56500

I think that "tabs" won. Also "always" looks like too
restrictive, so I have chosen this parameter with the
indentwidth 8 as the minimal invasive.

The last one is the maximal line length:

ColumnLimit   | +  | -

80| 99719  | 62788
100   | 83550  | 61566
120   | 75988  | 61015
140   | 71907  | 60655  *
160   | 69721  | 60506
180   | 68393  | 60430
200   | 67445  | 60374
220   | 66670  | 60316
240   | 66146  | 60304

Results are interesting. Clear is that we need to
cut over long lines. My proposal would be 140,
though most of guidelines use 80.

Opinions?

Regards

Anton

Am Fr., 18. Okt. 2019 um 15:30 Uhr schrieb Janek Kozicki (yade)
:
>
> It’s a great idea. And I’m surprised how personal it is for me :) Code 
> readability is top priority for me. I’m sure we will find the clang-format 
> settings which suits us.
>
> Automatic checks if the recently touched files (e.g files from the current 
> MR) were reformatted will definitely help us. At first this will add some 
> unreadable diffs. But later it will be a refreshing breeze :)
>
> -- Janek Kozicki
> On 17 Oct 2019, 18:59 +0200, Anton Gladky , wrote:
>
> Hi,
>
> I propose to use the clang-format [1], which automatically formats
> the code according to the pre-defined rules. It has a nice support
> by most of IDEs and can also be used through command line.
>
> There are some pre-defined styles (LLVM, Google, Chromium, Mozilla, WebKit),
> and i think we just need to choose. Fine-tuning is also possible, but
> it is not necessary.
>
> Running this tool recursively all over the code is possible, but can produce
> a large, not reviewable diff. But formatting the files, touched during
> development process can step-by-step fix most parts of the code and be
> consistent in the future.
>
> I have prepared a WIP-merge request [2], where the .clang-format file is added
> and the Scene.cpp was reformatted using this tool. So you can check,
> whether it will work for us. Style format can be changed, but it looks like
> LLVM-style will produce the minimal changes.
>
> Pipelines can also check, whether the committer formatted the code
> with clang-format. At the end we will forget the formatting problem in Yade.
>
> Generally, I have a good experience with this tool and I hope it can
> work for this project as well. Comments are welcome.
>
> [1] https://clang.llvm.org/docs/ClangFormat.html
> [2] https://gitlab.com/yade-dev/trunk/merge_requests/298
>
> Regards
>
>
> Anton
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Removing trailing white space, yay or nay?

[Anton Gladky]

Hi,

I propose to use the clang-format [1], which automatically formats
the code according to the pre-defined rules. It has a nice support
by most of IDEs and can also be used through command line.

There are some pre-defined styles (LLVM, Google, Chromium, Mozilla, WebKit),
and i think we just need to choose. Fine-tuning is also possible, but
it is not necessary.

Running this tool recursively all over the code is possible, but can produce
a large, not reviewable diff. But formatting the files, touched during
development process can step-by-step fix most parts of the code and be
consistent in the future.

I have prepared a WIP-merge request [2], where the .clang-format file is added
and the Scene.cpp was reformatted using this tool. So you can check,
whether it will work for us. Style format can be changed, but it looks like
LLVM-style will produce the minimal changes.

Pipelines can also check, whether the committer formatted the code
with clang-format. At the end we will forget the formatting problem in Yade.

Generally, I have a good experience with this tool and I hope it can
work for this project as well. Comments are welcome.

[1] https://clang.llvm.org/docs/ClangFormat.html
[2] https://gitlab.com/yade-dev/trunk/merge_requests/298

Regards


Anton

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Python inheritance

[Anton Gladky]

Hi,

without stack trace it is difficult to analyze.
Please compile Yade with debug symbols,
run your script till it crashes and provide
the stack trace.

Regards

On Mon, Oct 7, 2019, 16:46 William Chèvremont <
william.chevrem...@univ-grenoble-alpes.fr> wrote:

> Dear Yade dev,
>
> I'm facing an issue implementing a new interaction law into Yade.
>
> To be quick, I would like to provide normal force norm from python and
> integrate this value into the lubrication law.
>
> The current state of my work is on branch 'potential' on gitlab. What's
> new in this branch:
>
> - pkg/dem/LubricationWithPotential.{cpp, hpp} : Lubrication law with
> arbitraty contact law + potential solver, and some potential coded in c++.
> This part work perfectly.
>
> - py/wrapper/yadeWrapper.cpp: I've written a wrapping class and
> boost.python exposing expressions. I want to inherit this class in python
> in order to provide the value to the solver above.
>
> It works perfectly if I call O.step();. Problems are coming as soon as I
> launch O.run(), I got a segfault signal when the c++ code call the python
> overrided function.
>
> What's wrong???
>
> Summary of the code:
>
> :::python:::
>
> classSimplePotential(GenericPotential):
> def contactForce(self, u):
> #print("pyContactForce!");
> return 0;
> def potentialForce(self, u):
> #print("pyPotentialForce!");
> return 1;
> def hasContact(sefl, u):
> return False;
>
> :::C++:::
>
>
> class pyGenericPotential : public GenericPotential, public
> py::wrapper {
> public:
>
> Real potential(Real const& u, LubricationPhys const&) const {
> TRACE;
> return contactForce(u) + potentialForce(u);
> }
>
> void applyPotential(Real const& u, LubricationPhys& phys, Vector3r
> const) {
> TRACE;
> phys.normalContactForce = contactForce(u)*n;
> phys.normalPotentialForce = potentialForce(u)*n;
> phys.contact = hasContact(u);
> }
>
> virtual Real contactForce(Real const& u) const {
> TRACE;
> return get_override("contactForce")(u);
> }
>
> virtual Real potentialForce(Real const& u) const {
> TRACE;
> return get_override("potentialForce")(u);
> }
>
> virtual bool hasContact(Real const& u) const {
> TRACE;
> return get_override("hasContact")(u);
> }
> };
>
>
> py::class_("GenericPotential")
>
> .def("contactForce",py::pure_virtual(::contactForce),"This
> function should return contact force norm.")
>
> .def("potentialForce",py::pure_virtual(::potentialForce),"This
> function should return potential force norm.")
>
> .def("hasContact",py::pure_virtual(::hasContact),"This
> function should return true if there are contact.");
> --
> 
>
> William Chèvremont
>
> Doctorant, PhD student
> 04 56 52 01 86
>
> Laboratoire de Rhéologie et Procédés
> Bureau Bureau B-365
> 363 Rue de la chimie - bâtiment B
> Domaine Universitaire - BP 53 - 38041 Grenoble cedex 9
> www.univ-grenoble-alpes.fr
> http://www.laboratoire-rheologie-et-procedes.fr/
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] yadedaily packages are functional again

[Anton Gladky]

Dear all,

after months of work and tests yadedaily packages
are available again. Thanks all especially to the team
in 3sR in Grenoble and Janek.

Instructions are here [1]. If you find some problems  with
it, please file an issue on gitlab [2].

[1] https://yade-dem.org/doc/installation.html#packages
[2] https://gitlab.com/yade-dev/trunk/issues

Best Regards

Anton

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] Scheduled rebuilds of docker images and trunk/master

[Anton Gladky]

Dear all,

I have set up the regular rebuilt of all docker images:
for the stable distributions - once a month, fo Debian testing
- weekly. The schedules can be seen and adjusted here [1].

Also the master branch of the trunk is being now rebuilt daily [2].

I hope it will increase the integrity and quality of the software

[1] https://gitlab.com/yade-dev/docker-yade/pipeline_schedules
[2] https://gitlab.com/yade-dev/trunk/pipeline_schedules

Best regards

Anton

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Call for testing, updated yadedaily packages

[Anton Gladky]

Dear all,

packages for Debian 11 Bullseye are ready for testing.
In addition to the original mail [1], this action needs to be
done for this distribution:

- *Debian 11 Bullseye*:
  sudo bash -c 'echo "deb http://yadedaily.s3.amazonaws.com/debian
bullseye main" >> /etc/apt/sources.list.d/yadedaily.list'

Feedback is welcome.

This package is needed for the users of the current Debian Testing.
Also it is used to test the new packages, coming into the Debian and
later into the Ubuntu.

I am not planning to add some more distributions this year. Next year
we will prepare packages for Ubuntu 20.04.

When the infrastructure question will be solved, I will update a
documentation
for the yadedaily packages.

[1] https://lists.launchpad.net/yade-dev/msg14823.html

Best regards

Anton
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Call for testing, updated yadedaily packages

[Anton Gladky]

Hello all,

packages for Ubuntu 16.04 Xenial are ready for testing.
In addition to the original mail [1], this action needs to be
done for this distribution:

- Ubuntu 16.04 Xenial:
  sudo bash -c 'echo "deb http://yadedaily.s3.amazonaws.com/debian
xenial main" >> /etc/apt/sources.list.d/yadedaily.list'

Feedback is welcome.

Next week there will be no updates of the yadedaily packages due to some
technical reasons. Over the next week packages will be updated.

[1] https://lists.launchpad.net/yade-dev/msg14823.html

Best regards

Anton


Anton


Am So., 28. Juli 2019 um 12:46 Uhr schrieb Janek Kozicki :
>
> Looks like this conversation is now split between yade-dev and
> https://gitlab.com/yade-dev/trunk/issues/58
>
> Reply to whichever you want, I monitor both channels :)
>
> Bruno can you make an Account for Anton on yade-dem.org ?
>
> I asked Anton to make .deb packages with debug symbols, but he cannot
> upload them with his weak internet connection as they are quite large.
>
> After repo infrastructure is moved out of Anton's laptop we will be
> able to provide packages with debug symbols, which will be very
> useful: a normal user will be able to send us crash reports with
> debug symbols.
>
> cheers
> Janek
>
> Anton Gladky said: (by the date of Wed, 17 Jul 2019 20:17:18 +0200)
>
> > Hi Bruno,
> >
> > > Was there specific difficulties with ubuntu16.04 (even if it's getting 
> > > old I'm sure there would be users of it)?
> >
> > Basically - Qt4 orientation of the GUI. So, debian rules should be
> > patched to use it.
> > But if you think it is necessary for the users - let's try to do it.
> >
> > > - Where to host: yade-dem.org is available like before (it's on a brand 
> > > new hardware and it should stay for years), we need to give you access to 
> > > it I guess.
> >
> > Yes. Ideally there should be possible to run a docker. And also it
> > would be good to have an access
> > to the folder, which is symlinced to the the yade-dem.org/packages.
> >
> > > - Who/how to sign the packages: I don't see it very convenient if you 
> > > have to do anything manually, we are updating master many times a day at 
> > > the moment. Or maybe a few of us need to learn how to do it to.
> > It is extremely easy. It runs similar to the documentation: packages
> > should be pulled from gitlab,
> > signing etc is done by this script [1] and aptly. Dockerfile for the
> > image is here [2]
> >
> > [1] 
> > https://gitlab.com/yade-dev/trunk/blob/master/scripts/ppa_ci/aptly/update_repos_next.sh
> > [2] 
> > https://gitlab.com/yade-dev/trunk/blob/master/scripts/ppa_ci/aptly/Dockerfile
> >
> > Regards
> >
> > Anton
> >
> > Am Mo., 15. Juli 2019 um 18:23 Uhr schrieb Bruno Chareyre
> > :
> > >
> > > Hi Anton,
> > >
> > > On Fri, 12 Jul 2019 at 19:03, Anton Gladky  wrote:
> > >>
> > >> Comments, critic are
> > >> very welcome.
> > >
> > >
> > > This is great! Thank you very much.
> > > Was there specific difficulties with ubuntu16.04 (even if it's getting 
> > > old I'm sure there would be users of it)?
> > > If yes, then let it be. If it just needs to add a name in [1] then it's 
> > > maybe worth it.
> > > [1] 
> > > https://gitlab.com/yade-dev/trunk/merge_requests/185/diffs#9e4f27c17b0dc74b4dff4de88036f97a4daf0f00_0_7
> > >
> > >>
> > >> > p.s. just curious about the amazonaws hosting, issues with gitlab.com? 
> > >> > If it helps local server yade-dem.org can be used to. Nothing against
> > >>
> > >> Now it is done on my laptop and I am just using the Amazon S3 for 
> > >> testing purposes.
> > >> We can surely use it further, but I would also prefer to move to 
> > >> yade-dem.org.
> > >> But we need to coordinate that.
> > >
> > >
> > > Ok. There are two questions then:
> > > - Where to host: yade-dem.org is available like before (it's on a brand 
> > > new hardware and it should stay for years), we need to give you access to 
> > > it I guess.
> > > - Who/how to sign the packages: I don't see it very convenient if you 
> > > have to do anything manually, we are updating master many times a day at 
> > > the moment. Or maybe a few of us need to learn how to do it to.
> > >
> > >
> > >>
> > >> Theoretically, we could use the gitlab infrastructure to build the 
> > >> repository as we

Re: [Yade-dev] Call for testing, updated yadedaily packages

[Anton Gladky]

Hi Bruno,

> Was there specific difficulties with ubuntu16.04 (even if it's getting old 
> I'm sure there would be users of it)?

Basically - Qt4 orientation of the GUI. So, debian rules should be
patched to use it.
But if you think it is necessary for the users - let's try to do it.

> - Where to host: yade-dem.org is available like before (it's on a brand new 
> hardware and it should stay for years), we need to give you access to it I 
> guess.

Yes. Ideally there should be possible to run a docker. And also it
would be good to have an access
to the folder, which is symlinced to the the yade-dem.org/packages.

> - Who/how to sign the packages: I don't see it very convenient if you have to 
> do anything manually, we are updating master many times a day at the moment. 
> Or maybe a few of us need to learn how to do it to.
It is extremely easy. It runs similar to the documentation: packages
should be pulled from gitlab,
signing etc is done by this script [1] and aptly. Dockerfile for the
image is here [2]

[1] 
https://gitlab.com/yade-dev/trunk/blob/master/scripts/ppa_ci/aptly/update_repos_next.sh
[2] 
https://gitlab.com/yade-dev/trunk/blob/master/scripts/ppa_ci/aptly/Dockerfile

Regards

Anton

Am Mo., 15. Juli 2019 um 18:23 Uhr schrieb Bruno Chareyre
:
>
> Hi Anton,
>
> On Fri, 12 Jul 2019 at 19:03, Anton Gladky  wrote:
>>
>> Comments, critic are
>> very welcome.
>
>
> This is great! Thank you very much.
> Was there specific difficulties with ubuntu16.04 (even if it's getting old 
> I'm sure there would be users of it)?
> If yes, then let it be. If it just needs to add a name in [1] then it's maybe 
> worth it.
> [1] 
> https://gitlab.com/yade-dev/trunk/merge_requests/185/diffs#9e4f27c17b0dc74b4dff4de88036f97a4daf0f00_0_7
>
>>
>> > p.s. just curious about the amazonaws hosting, issues with gitlab.com? If 
>> > it helps local server yade-dem.org can be used to. Nothing against
>>
>> Now it is done on my laptop and I am just using the Amazon S3 for testing 
>> purposes.
>> We can surely use it further, but I would also prefer to move to 
>> yade-dem.org.
>> But we need to coordinate that.
>
>
> Ok. There are two questions then:
> - Where to host: yade-dem.org is available like before (it's on a brand new 
> hardware and it should stay for years), we need to give you access to it I 
> guess.
> - Who/how to sign the packages: I don't see it very convenient if you have to 
> do anything manually, we are updating master many times a day at the moment. 
> Or maybe a few of us need to learn how to do it to.
>
>
>>
>> Theoretically, we could use the gitlab infrastructure to build the 
>> repository as well.
>> But the problem is that it should be signed by the private yade-GPG key.
>> And I would escape to upload this private key into the gitlab servers due
>> to security concerns. Maybe I am missing something.
>
>
> I know exactly what you mean. That's why currently yade-dem.org does wget the 
> documentation from gitlab (checking every 10 minutes or so) instead of gitlab 
> pushing actively. We did not like giving credentials to gitlab.
> I don't think you missed anything, there is no escape on this aspect.
>
> Regards
>
> Bruno
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Call for testing, updated yadedaily packages

[Anton Gladky]

Dear all,

thank you for testing! It looks like we do not have major problems
with the DEB-packages. The packaging should surely be improved
(especially python3-yadepackage), but it is more less usable now.
That is why I prepared a merge request [1]. Comments, critic are
very welcome.

[1] https://gitlab.com/yade-dev/trunk/merge_requests/185

> p.s. just curious about the amazonaws hosting, issues with gitlab.com? If
it helps local server yade-dem.org can be used to. Nothing against

Please see an attached picture to understand better the current
way of packaging. Gitlab is building DEB-packages based on the
master-branch. But it is not enough to provide a convenient way to
install DEB-packages. Somebody should prepare an update for the
repository.

Previously it was done by Launchpad and their PPAs. Now it is done
on my laptop and I am just using the Amazon S3 for testing purposes.
We can surely use it further, but I would also prefer to move to
yade-dem.org.
But we need to coordinate that.

Theoretically, we could use the gitlab infrastructure to build the
repository as well.
But the problem is that it should be signed by the private yade-GPG key.
And I would escape to upload this private key into the gitlab servers due
to security concerns. Maybe I am missing something.

Best regards

PS Sorry for not being too responsive. I am only able to do this work
late in the evening.

Anton


Am Fr., 28. Juni 2019 um 17:05 Uhr schrieb Bruno Chareyre <
bruno.chare...@3sr-grenoble.fr>:

> Hi Anton,
> Thank you very much!
> I confirm installation on ubuntu 18.04.
> Cheers
> Bruno
>
> p.s. just curious about the amazonaws hosting, issues with gitlab.com? If
> it helps local server yade-dem.org can be used to. Nothing against
>
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] Call for testing, updated yadedaily packages

[Anton Gladky]

Dear all,

yadedaily packages are being under renovation at the moment. And now they
need to be tested.
I want to ask you to do it and give a feedback.

3 Distributions are supported:
- Debian Buster
- Debian Stretch
- Ubuntu 18.04 Bionic

Packages are hosted on Amason S3 for the moment.
The following steps need to be taken to test the packages

1. Add yade GPG-key:
If you have the yadedaily package, you can skip this step.

wget -O - http://yadedaily.s3.amazonaws.com/yadedaily.gpg | sudo
apt-key add -

2. Add repo into the apt:
- *Debian Buster:*
  sudo bash -c 'echo "deb http://yadedaily.s3.amazonaws.com/debian
buster main" >> /etc/apt/sources.list.d/yadedaily.list'

- *Debian Stretch*:
  sudo bash -c 'echo "deb http://yadedaily.s3.amazonaws.com/debian
stretch main" >> /etc/apt/sources.list.d/yadedaily.list'

- *Ubuntu 18.04 Bionic:*
  sudo bash -c 'echo "deb http://yadedaily.s3.amazonaws.com/debian
bionic main" >> /etc/apt/sources.list.d/yadedaily.list'

3. Install yadedaily:
 sudo apt update && sudo apt install yadedaily

After that you can run the software:

yadedaily
yadedaily --test
yadedaily --check

Please let me know, whether everything is working as expected.

If you do not want to use yadedaily any more, just do:
   sudo apt purge yadedaily

Remove test-repo from sources:
sudo rm  /etc/apt/sources.list.d/yadedaily.list

I will update packages manually within the test period. After that we can
automate the process.

Thanks

Anton
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Sporadic compilation error

[Anton Gladky]

Yes, I really missed most of them. But I will prepare
the merge request soon, so we can discuss it everything
in details.

Thanks

Anton

Am Mi., 12. Juni 2019 um 11:37 Uhr schrieb Janek Kozicki :
>
> Hi Anton,
>
> just to make sure: have you noticed Bruno's and my comments attached to
> your commits on gitlab?
>
> https://gitlab.com/yade-dev/trunk/commit/81652f1c47575ecbc9599308a449ccd3c28ff634
>
> https://gitlab.com/yade-dev/trunk/commit/9d8211c3721b4bd9b3ceebe396a4bf14957d04e1
>
> https://gitlab.com/yade-dev/trunk/commit/f76b011b0e083c6c73f4e09e5567306cd32ba8e7
>
> To stay on track it is usefu to bookmark this page:
> https://gitlab.com/groups/yade-dev/-/activity
>
> best regards
> Janek
>
>
> Anton Gladky said: (by the date of Sun, 9 Jun 2019 08:00:44 +0200)
>
> > I think the problem is that two or more
> > processes are concurrently creating
> > moc-files and overwriting it, breaking
> > the structure.
> >
> > On Sat, Jun 8, 2019, 21:39 Anton Gladky  wrote:
> >
> > > > Maybe investigating the difference between the "regular" setup and
> > > > "deb-packages" compilation would give some insight.
> > >
> > > Basically the same [1]
> > >
> > > [1]
> > > https://gitlab.com/yade-dev/trunk/blob/feature/dailypackages/scripts/ppa_ci/debian/rules#L18
> > >
> > > Anton
> --
> Janek Kozicki   http://janek.kozicki.pl/  |

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Sporadic compilation error

[Anton Gladky]

I think the problem is that two or more
processes are concurrently creating
moc-files and overwriting it, breaking
the structure.

On Sat, Jun 8, 2019, 21:39 Anton Gladky  wrote:

> > Maybe investigating the difference between the "regular" setup and
> > "deb-packages" compilation would give some insight.
>
> Basically the same [1]
>
> [1]
> https://gitlab.com/yade-dev/trunk/blob/feature/dailypackages/scripts/ppa_ci/debian/rules#L18
>
> Anton
>
> Am Sa., 8. Juni 2019 um 21:01 Uhr schrieb Janek Kozicki  >:
> >
> > Also it is interesting that this error did not occur in hundreds of
> > pipeline compilations after each `git push` to gitlab. Maybe
> > investigating the difference between the "regular" setup and
> > "deb-packages" compilation would give some insight.
> >
> >
> >
> > Janek Kozicki said: (by the date of Sat, 8 Jun 2019 20:53:54 +0200)
> >
> > > It happened locally for me, and it always was random :(
> > >
> > > In some other QT project which I had, I managed to fix this by making
> > > sure that mocs compilation always goes first, separately before the
> > > rest of the compilation.
> > >
> > > I didn't investigate how to achieve this in CMakeLists.txt
> > > maybe this would solve it.
> > >
> > >
> > > Anton Gladky said: (by the date of Sat, 8 Jun 2019 20:48:45 +0200)
> > >
> > > > Hi Janek,
> > > >
> > > > > Previously the error was about py/pack/_packObb.cpp, now it has
> moved
> > > > > to py/_libVersions.cpp
> > > >
> > > > OK, I will try to reproduce it locally. But it is now a blocker for
> > > > deb-packages.
> > > >
> > > > > btw, did you notice:
> > > > >
> https://salsa.debian.org/science-team/libqglviewer/merge_requests/1  ?
> > > >
> > > > Thank you. Debian is frozen now due to release. But I will definitely
> > > > let it go after it.
> > > >
> > > > Regards
> > > >
> > > > Anton
> > > >
> > > > Am Sa., 8. Juni 2019 um 18:52 Uhr schrieb Janek Kozicki <
> janek_li...@wp.pl>:
> > > > >
> > > > > Hi Anton,
> > > > >
> > > > > We have spotted a very similar mocs compilation error even before
> I implemented
> > > > > libVersions: https://gitlab.com/yade-dev/trunk/issues/67
> > > > >
> > > > > I seems that it randomly fails on the last py/*.cpp file.
> > > > >
> > > > > Previously the error was about py/pack/_packObb.cpp, now it has
> moved
> > > > > to py/_libVersions.cpp
> > > > >
> > > > > I don't know what is this. Maybe some missing include from QT
> libraries?
> > > > >
> > > > > btw, did you notice:
> > > > >
> https://salsa.debian.org/science-team/libqglviewer/merge_requests/1  ?
> > > > >
> > > > > best regards
> > > > > Janek
> > > > >
> > > > > Anton Gladky said: (by the date of Sat, 8 Jun 2019 18:34:49
> +0200)
> > > > >
> > >  [...]
> > > > >
> > > > >
> > > > > --
> > > > > Janek Kozicki
> http://janek.kozicki.pl/  |
> > > > >
> > > > > ___
> > > > > Mailing list: https://launchpad.net/~yade-dev
> > > > > Post to : yade-dev@lists.launchpad.net
> > > > > Unsubscribe : https://launchpad.net/~yade-dev
> > > > > More help   : https://help.launchpad.net/ListHelp
> > >
> > >
> > > --
> > > Janek Kozicki   http://janek.kozicki.pl/
> |
> > >
> > > ___
> > > Mailing list: https://launchpad.net/~yade-dev
> > > Post to : yade-dev@lists.launchpad.net
> > > Unsubscribe : https://launchpad.net/~yade-dev
> > > More help   : https://help.launchpad.net/ListHelp
> >
> >
> > --
> > Janek Kozicki   http://janek.kozicki.pl/  |
> >
> > ___
> > Mailing list: https://launchpad.net/~yade-dev
> > Post to : yade-dev@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~yade-dev
> > More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Sporadic compilation error

[Anton Gladky]

> Maybe investigating the difference between the "regular" setup and
> "deb-packages" compilation would give some insight.

Basically the same [1]

[1] 
https://gitlab.com/yade-dev/trunk/blob/feature/dailypackages/scripts/ppa_ci/debian/rules#L18

Anton

Am Sa., 8. Juni 2019 um 21:01 Uhr schrieb Janek Kozicki :
>
> Also it is interesting that this error did not occur in hundreds of
> pipeline compilations after each `git push` to gitlab. Maybe
> investigating the difference between the "regular" setup and
> "deb-packages" compilation would give some insight.
>
>
>
> Janek Kozicki said: (by the date of Sat, 8 Jun 2019 20:53:54 +0200)
>
> > It happened locally for me, and it always was random :(
> >
> > In some other QT project which I had, I managed to fix this by making
> > sure that mocs compilation always goes first, separately before the
> > rest of the compilation.
> >
> > I didn't investigate how to achieve this in CMakeLists.txt
> > maybe this would solve it.
> >
> >
> > Anton Gladky said: (by the date of Sat, 8 Jun 2019 20:48:45 +0200)
> >
> > > Hi Janek,
> > >
> > > > Previously the error was about py/pack/_packObb.cpp, now it has moved
> > > > to py/_libVersions.cpp
> > >
> > > OK, I will try to reproduce it locally. But it is now a blocker for
> > > deb-packages.
> > >
> > > > btw, did you notice:
> > > > https://salsa.debian.org/science-team/libqglviewer/merge_requests/1  ?
> > >
> > > Thank you. Debian is frozen now due to release. But I will definitely
> > > let it go after it.
> > >
> > > Regards
> > >
> > > Anton
> > >
> > > Am Sa., 8. Juni 2019 um 18:52 Uhr schrieb Janek Kozicki 
> > > :
> > > >
> > > > Hi Anton,
> > > >
> > > > We have spotted a very similar mocs compilation error even before I 
> > > > implemented
> > > > libVersions: https://gitlab.com/yade-dev/trunk/issues/67
> > > >
> > > > I seems that it randomly fails on the last py/*.cpp file.
> > > >
> > > > Previously the error was about py/pack/_packObb.cpp, now it has moved
> > > > to py/_libVersions.cpp
> > > >
> > > > I don't know what is this. Maybe some missing include from QT libraries?
> > > >
> > > > btw, did you notice:
> > > > https://salsa.debian.org/science-team/libqglviewer/merge_requests/1  ?
> > > >
> > > > best regards
> > > > Janek
> > > >
> > > > Anton Gladky said: (by the date of Sat, 8 Jun 2019 18:34:49 +0200)
> > > >
> >  [...]
> > > >
> > > >
> > > > --
> > > > Janek Kozicki   http://janek.kozicki.pl/  |
> > > >
> > > > ___
> > > > Mailing list: https://launchpad.net/~yade-dev
> > > > Post to : yade-dev@lists.launchpad.net
> > > > Unsubscribe : https://launchpad.net/~yade-dev
> > > > More help   : https://help.launchpad.net/ListHelp
> >
> >
> > --
> > Janek Kozicki   http://janek.kozicki.pl/  |
> >
> > ___
> > Mailing list: https://launchpad.net/~yade-dev
> > Post to : yade-dev@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~yade-dev
> > More help   : https://help.launchpad.net/ListHelp
>
>
> --
> Janek Kozicki   http://janek.kozicki.pl/  |
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] Sporadic compilation error

[Anton Gladky]

Hello all,

there is an annoying error during the Yade compilation
for Deb-Packages, which appears often, but sporadically [1]:

py/CMakeFiles/_utils.dir/build.make:89: recipe for target
'py/CMakeFiles/_utils.dir/_utils_autogen/mocs_compilation.cpp.o'
failed
make[3]: Leaving directory '/builds/yade-dev/deb_bionic/yadedaily/debian/build'
/builds/yade-dev/deb_bionic/yadedaily/debian/build/py/_libVersions_autogen/mocs_compilation.cpp:4:1:
error: 'othing' does not name a type
/builds/yade-dev/deb_bionic/yadedaily/debian/build/py/_libVersions_autogen/mocs_compilation.cpp:4:8:
error: expected declaration before '}' token

@Janek Kozicki  , do you have an idea, what can cause an error.

[1] https://gitlab.com/yade-dev/trunk/-/jobs/227728534

Thank you

Anton

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] [Bug 1814286] Re: Various LaTeX symbols missing in Yade documentation

[Anton Gladky]

Sorry for causing those problems. Yes, I did not check this
change on older distributions.

Anyway, the pngmath is deprecated in sphinx_1.8, so this
change is necessary for the newer distributions, where 1.8
is used.

If imgmath is not working properly, we need to investigate
the problem deeper.

Regards

Anton

Am Mo., 4. Feb. 2019 um 18:20 Uhr schrieb Robert Caulk
<1814...@bugs.launchpad.net>:
>
> >>Hmm, this search in Buster indicates that pngmath is still there,
> am I missing something?
>
> I guess it exists without support based on this warning thrown by make
> doc:
>
> "WARNING: sphinx.ext.pngmath has been deprecated. Please use
> sphinx.ext.imgmath instead."
>
> Have you tried replacing \def with \newcommand locally Janek?
>
> --
> You received this bug notification because you are subscribed to Yade.
> https://bugs.launchpad.net/bugs/1814286
>
> Title:
>   Various LaTeX symbols missing in Yade documentation
>
> Status in Yade:
>   New
>
> Bug description:
>   See [1]. Looks like the builder is missing some important LaTeX
>   libraries.
>
>
>   [1] https://yade-dev.gitlab.io/trunk/formulation.html#variables
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/yade/+bug/1814286/+subscriptions

-- 
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1814286

Title:
  Various LaTeX symbols missing in Yade documentation

Status in Yade:
  New

Bug description:
  See [1]. Looks like the builder is missing some important LaTeX
  libraries.

  
  [1] https://yade-dev.gitlab.io/trunk/formulation.html#variables

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1814286/+subscriptions

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] [Bug 1814286] Re: Various LaTeX symbols missing in Yade documentation

[Anton Gladky]

Hi guys,

I committed those changes. pngmath is not part of sphinx any more,
so the change is really necessary

Anton

Am Fr., 1. Feb. 2019 um 18:25 Uhr schrieb Robert Caulk
<1814...@bugs.launchpad.net>:
>
> Yes, Mathjax seems cleaner. Does it result in better resolution of math
> on the web. The old equations used to look grainy with pngmath iirc.
>
> Is there a way to test changes and their effect on the website without
> merging to develop branch?
>
> --
> You received this bug notification because you are subscribed to Yade.
> https://bugs.launchpad.net/bugs/1814286
>
> Title:
>   Various LaTeX symbols missing in Yade documentation
>
> Status in Yade:
>   New
>
> Bug description:
>   See [1]. Looks like the builder is missing some important LaTeX
>   libraries.
>
>
>   [1] https://yade-dev.gitlab.io/trunk/formulation.html#variables
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/yade/+bug/1814286/+subscriptions

-- 
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1814286

Title:
  Various LaTeX symbols missing in Yade documentation

Status in Yade:
  New

Bug description:
  See [1]. Looks like the builder is missing some important LaTeX
  libraries.

  
  [1] https://yade-dev.gitlab.io/trunk/formulation.html#variables

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1814286/+subscriptions

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] Release, GitLab?

[Anton Gladky]

Hello yade devs,

as far as I understand we are moving (have moved already) to
GitLab. But I saw some commits on github as well.

Some  questions:

- Should we disable commits on github?
- Should all links in the Yade code be updated to GitLab variants?
- Do we prepare release from GitLab?

Also we need to decide, how this release will be done. As usually,
creating 2019.01-branch and tagging the release there? Or creating
the single "stable" branch for all other future releases?

I am ready to postpone the release for the next couple of days to
solve this questions, if necessary.

Thanks for your work on Yade code.

Anton

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] New Yade version? Debian freeze is coming

[Anton Gladky]

Thanks all for quick responses.

> Anton, how much time do I have?

I would then propose to make a release next weekend (26-27 of January).
Would it be OK?

Anton

Am Mi., 16. Jan. 2019 um 13:02 Uhr schrieb Janek Kozicki :
>
> I agree, you can make a release.
>
> If you know that it is correct, then I leave it to you to remove this warning 
> from Tesselation.ipp :)
>
> Tesselation.ipp:78:2: warning: #warning "It was move_point before CGAL 
> 4.13"
>
> I am planning to at least fix some examples. Anton, how much time do I have?
>
> best regards
> Janek
>
>
> Bruno Chareyre said: (by the date of Wed, 16 Jan 2019 11:13:02 +0100)
>
> > Hi Anton,
> > I think current code is stable and it is a good time to freeze.
> >
> > @All
> > Does someone have hot stuff to be included (shortly)?
> >
> > Bruno
> >
> > On 1/15/19 8:44 PM, Anton Gladky wrote:
> > > Dear Yade developers,
> > >
> > > the previous Yade version was released almost a year ago.
> > > What is the state of the code right now? Would it be possible
> > > to make a new release within the next a couple of weeks?
> > >
> > > The new Debian release is being prepared at the moment and
> > > the soft freeze is planned for 12.02.2019. It would be good to
> > > have a newer Yade there for the next two years.
> > >
> > > Opinions are welcome
> > >
> > > Best regards
> > >
> > > Anton
>
>
> --
> Janek Kozicki   http://janek.kozicki.pl/  |
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] New Yade version? Debian freeze is coming

[Anton Gladky]

Dear Yade developers,

the previous Yade version was released almost a year ago.
What is the state of the code right now? Would it be possible
to make a new release within the next a couple of weeks?

The new Debian release is being prepared at the moment and
the soft freeze is planned for 12.02.2019. It would be good to
have a newer Yade there for the next two years.

Opinions are welcome

Best regards

Anton

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Migrating to GitLab

[Anton Gladky]

Hello Bruno,

thanks for the explanation. That is more-less clear. From my side - OK.

>  would like to have you in the maintainers group if you agree.

Yes, I agree. Thanks.

Best regards

Anton

Am Fr., 11. Jan. 2019 um 14:53 Uhr schrieb Bruno Chareyre
:
>
>
>
> On Thu, 10 Jan 2019 at 21:40, Anton Gladky  wrote:
>>
>> Sorry guys, I still cannot understand, what brings:
>> - renaming master->develop
>> - having potentially broken/not-mergable experimental branch.
>
>
>
> Oh yes, it's confused. Things will become more clear with a functional repo 
> (I'm only waiting for runners to be assigned presently, then we can switch).
>
> Master took the name "develop" in the course of this discussion because of 
> the master-develop framework mentioned earlier (by Janek).
> If we keep a single branch there is no reason to rename it. It will be master.
>
> Experimental: my intention was to let people play with an experimental gitlab 
> repo so they can learn a bit of gitlab CI without messing up yade history.
> Of course they can play with git in their personal repo but the cycle will be 
> incomplete if they are not assigned runners. Hence why I suggested a draft 
> project, perhaps only in a transitory phase.
> There is no added complexity, it's just a clone of the main repo with runners 
> assigned (we will not assign runners to each other personal repo, I guess it 
> goes without saying).
> If kept in the long run then maybe experimental repo could help sharing 
> experimental stuff through precompiled packages without interfering with main 
> repo.
> Say, someone finds out that pink-colored GUI is better and he wants others to 
> try it. If it's in experimental others can simply apt-get install to inspect 
> the achievement.
>
>>
>> Anyway, I am not so active in the project, so feel free to make your own
>> decisions. Do not forget to keep simple things simple...
>
>
> I would like to have you in the maintainers group if you agree. And thanks 
> for comments, they are helpful.
> Cheers
>
> Bruno
>
>>
>>
>> Regards
>>
>>
>> Anton
>>
>> Am Do., 10. Jan. 2019 um 20:16 Uhr schrieb Janek Kozicki :
>> >
>> > OK, I think I finally understood your intentions:
>> >
>> > merge requests go to develop (renamed from master), with several devs
>> > approving it with www interface.
>> >
>> > experimental branch is not used for that, but for whatever wild stuff
>> > comes into mind.
>> >
>> > This way Jerome needs not to worry, and everyone is happy :)
>> >
>> >
>> >
>> >
>> > Janek Kozicki said: (by the date of Wed, 9 Jan 2019 15:24:18 +0100)
>> >
>> > > Anton Gladky said: (by the date of Tue, 8 Jan 2019 20:45:15 +0100)
>> > >
>> > > > Hi Bruno,
>> > > >
>> > > > > Anton, do you have comments on MR on Gitlab interface? Do you
>> > > > > confirm that they are a must?
>> > > >
>> > > > Yes, definitely must have! As I told already each merge request can
>> > > > be checked automatically by CI and reviewed by other developers
>> > > > (with "approve"-technique).
>> > >
>> > > very nice! I didn't know about this before.
>> > >
>> > > I will have a look at that API which you mentioned.
>> > >
>> > >
>> > > > I am fully support the feature-branch + merge request way of
>> > > > working. It can really help to double check the code and implement
>> > > > some additional tests.
>> > >
>> > > So I am trying to wrap my head around this. We would have:
>> > >
>> > > --> other people's feature repos
>> > >  \
>> > > ->\ other people's feature repos
>> > > \MR\MR
>> > > --> experimental
>> > >   \   /   \   \   /  /
>> > > --> develop
>> > >\\
>> > > \\
>> > >  \Release 1   \Release 2
>> > >   \Release 1.1
>> > >
>> > > ?
>> > >
>> > > Bruno Chareyre said: (by the date of Tue, 8 Jan 2019 17:50:02 +0100)
>> > >
>> > > > I would propose develop+experimental for a start, with rel

Re: [Yade-dev] Migrating to GitLab

[Anton Gladky]

Sorry guys, I still cannot understand, what brings:
- renaming master->develop
- having potentially broken/not-mergable experimental branch.

If somebody can summarize me it in 2-3 words - would be fine.

For some "wild" stuff it is enough to have the own feature branch
and everybody can do there, all, what they want.

Anyway, I am not so active in the project, so feel free to make your own
decisions. Do not forget to keep simple things simple...

Regards


Anton

Am Do., 10. Jan. 2019 um 20:16 Uhr schrieb Janek Kozicki :
>
> OK, I think I finally understood your intentions:
>
> merge requests go to develop (renamed from master), with several devs
> approving it with www interface.
>
> experimental branch is not used for that, but for whatever wild stuff
> comes into mind.
>
> This way Jerome needs not to worry, and everyone is happy :)
>
>
>
>
> Janek Kozicki said: (by the date of Wed, 9 Jan 2019 15:24:18 +0100)
>
> > Anton Gladky said: (by the date of Tue, 8 Jan 2019 20:45:15 +0100)
> >
> > > Hi Bruno,
> > >
> > > > Anton, do you have comments on MR on Gitlab interface? Do you
> > > > confirm that they are a must?
> > >
> > > Yes, definitely must have! As I told already each merge request can
> > > be checked automatically by CI and reviewed by other developers
> > > (with "approve"-technique).
> >
> > very nice! I didn't know about this before.
> >
> > I will have a look at that API which you mentioned.
> >
> >
> > > I am fully support the feature-branch + merge request way of
> > > working. It can really help to double check the code and implement
> > > some additional tests.
> >
> > So I am trying to wrap my head around this. We would have:
> >
> > --> other people's feature repos
> >  \
> > ->\ other people's feature repos
> > \MR\MR
> > --> experimental
> >   \   /   \   \   /  /
> > --> develop
> >\\
> > \\
> >  \Release 1   \Release 2
> >   \Release 1.1
> >
> > ?
> >
> > Bruno Chareyre said: (by the date of Tue, 8 Jan 2019 17:50:02 +0100)
> >
> > > I would propose develop+experimental for a start, with release branches as
> > > in Anton's picture.
> >
> > So that would mean: rename master to develop, and create experimental?
> >
> > > Very liberal config for exp, and conservative for dev (even very
> > > conservative initially, we will see if it is too conservative).
> > > exp will *not* merge to develop, it will diverge progressively, most
> > > likely, but it is not an issue. It can be re-synced. No commits can be 
> > > lost
> > > since by definition a MR to exp is from somewhere.
> >
> > in other mail I only mentioned a nice method of solving conflicts.
> > Here let's focus on how you see that it should work. Especially I am
> > not sure what you mean by:
> >
> > "exp will *not* merge to develop, it will diverge progressively, most 
> > likely"
> >
> >
> > Jerome raises a very important question: where do you merge request to?
> >
> > Jerome wants to stay away from experimental and do merge requests to 
> > develop?
> >
> > It means that it eliminates the buffer (in my previous posts it
> > was a buffer between develop ↔ master, according to Bruno's naming
> > suggestion that would be a buffer between experimental ↔ develop)
> > which I was proposing.
> >
> > Do we want this buffer?
> >
> >
> > --
> > Janek Kozicki
> >
> > ___
> > Mailing list: https://launchpad.net/~yade-dev
> > Post to : yade-dev@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~yade-dev
> > More help   : https://help.launchpad.net/ListHelp
>
>
> --
> Janek Kozicki   http://janek.kozicki.pl/  |
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Migrating to GitLab

[Anton Gladky]

Hi Bruno,

> Anton, do you have comments on MR on Gitlab interface? Do you confirm that 
> they are a must?

Yes, definitely must have! As I told already each merge request can
be checked automatically by CI and reviewed by other developers
(with "approve"-technique).

>  Did you ever hack the API to trigger them from CLI (that would mae Janek 
> happy ;) )?

A year ago I had successfully migrated almost 1000 git-repos from one
service to Gtilab
(new salsa.debian.org) using GitLab-API and was very satisfied. I have
never used
it before, and it took just some hours to do it. API is good documented!

The only develop-master privilege, which I can imaging, is the
automatic build of
stable-yade packages. Master-branch should be synced into the Launchpad and
the stable packages will be built after each sync. But Yade releases
are not so often,
not sure it will make any sense.

[1] https://lists.debian.org/debian-science/2017/12/msg00029.html

Best regards

Anton

Am Di., 8. Jan. 2019 um 17:52 Uhr schrieb Bruno Chareyre
:
>
>
>
> On Tue, 8 Jan 2019 at 09:56, Jerome Duriez  wrote:
>>
>> let's maybe try to avoid switching from only one branch to more than
>> three ?...
>
>
> We have already 19 branches on github/yade/trunk, plus other branches under 
> personal accounts.
> Limiting the number of branches is not a realistic objective, don't worry 
> about that. It will become more clear with concrete usage, and you will not 
> have to handle them all anyway.
> This being said, I'm also not sure we really need that develop-master duality.
>
> I would propose develop+experimental for a start, with release branches as in 
> Anton's picture.
> Very liberal config for exp, and conservative for dev (even very conservative 
> initially, we will see if it is too conservative).
> exp will not merge to develop, it will diverge progressively, most likely, 
> but it is not an issue. It can be re-synced. No commits can be lost since by 
> definition a MR to exp is from somewhere.
>
> Anton, do you have comments on MR on Gitlab interface? Do you confirm that 
> they are a must? Did you ever hack the API to trigger them from CLI (that 
> would mae Janek happy ;) )?
> Thx
> Bruno
>
>>
>> On 07/01/2019 20:36, Anton Gladky wrote:
>> > --> develop
>> >\\
>> > \ \
>> >  \Release 1 \Release 2
>> >   \Release 1.1
>> >
>> > I can remember only a couple of times, where the hot-fixes were
>> > needed to be integrated into the release-branch due to some serious
>> > stability or functionality issues.
>> >
>> > Last years I have an experience of work with master-develop
>> > approach. It is not bad. But you really need to know, why do
>> > you need it.
>> >
>> > I am fully support the feature-branch + merge request way of working.
>> > It can really help to double check the code and implement some
>> > additional tests.
>> >
>> > [1] https://github.com/yade/trunk/tree/0.60
>> >
>> > My 2cts
>> >
>> > Regards
>> >
>> > Anton
>> >
>> > Am Mo., 7. Jan. 2019 um 17:39 Uhr schrieb Janek Kozicki 
>> > :
>> >> Bruno Chareyre said: (by the date of Mon, 7 Jan 2019 16:59:53 +0100)
>> >>
>> >>> Daily builds would be based on the develop branch.
>> >> good, that answer my question from other mail.
>> >>
>> >>>> (by the way, with a tighter control on development, would we still
>> >>>> need a distinction between "yade" and "yadedaily" packages ?..)
>> >>> Yade is stable release, not updated very often, included in main
>> >>> debian/ubuntu repos.
>> >>> Yadedaily is updated  more than daily, after each change to the source
>> >>> code, not included in debian/ubuntu repos.
>> >>> They are very different things and I think we need both.
>> >> agreed.
>> >>
>> >>>> Also, with "develop" and "master", I guess any proposal for code
>> >>>> modification would have to be closely examined and validated twice :
>> >>>> - once to make it into "develop"
>> >>>> - and once, to make it from "develop" into "master"
>> >>>> ?...
>> >>> There is no reason to check the develop->master merge if everything in
>> >>> develop is already validated by regtests + human review.
>> >>> Our g

Re: [Yade-dev] stability & compatibility between newer and older versions of yade

[Anton Gladky]

Hi all,

please do not forget, that Yade has already a rich opportunity
to create semi-unit-tests (yade --test) and nice semi-integration-tests
(yade --check). Sure, one can create unit tests for pure C++-functions
using boost::unit_test, cppunit or googletest etc., but I would propose
first to extend existing tests, not to spread an energy for the connecting
the new framework into the Yade (+new dependencies, +new cmake-change,
+integration overhead).

And if the existing "yade --test" or "yade --check" are really not enough,
one need to analyze the problem deeper and then make a decision for the
connecting of newer frameworks.

Regards

Anton

Am Mo., 7. Jan. 2019 um 18:26 Uhr schrieb Janek Kozicki :
>
> Bruno Chareyre said: (by the date of Sun, 6 Jan 2019 17:08:12 +0100)
>
> > Thanks for raising this major issue. It would be great to populate unit
> > tests indeed.
> >
> > I recently
> > https://github.com/yade/trunk/commit/b5fbefc6463294f580296cb5727dbbfd733fa8a0
> > introduced a regression test for the utils module and I would like
> > to advertise it here. It is testing only one function from utils
> > currently.
>
> Very interesting, thank you!
>
> I have in mind writing testing code in C++, so that's a little different.
>
> > It needs volunteers to expand it (which can be done simply by reproducing
> > the logic of testUserCreatedInteraction() in more functions). If nobody is
> > going to add tests systematically - the ideal case - I would suggest at
> > least that:
> > *when a bug is fixed a unit test is added simultaneously*.
> > Fixing a bug usually gives a fresh vision of the behavior, which makes
> > writing a unit test easier.
> > Ultimately we could even collectively agree that a bug is not fixed if
> > there is no test proving it.
>
> I would go a bit further: assume that current yade version is the
> reference version. Then I would add test to every C++ function and class
> method. Store the results of tests as a reference result. When a bug
> is found, then the reference result would change. Or worse: it would
> turn out that although function is tested, the test did not catch the
> bug. And that would be great incentive to add a test case where this
> bug happened.
>
> And also this would be a lot easier for others: the code testing
> this function is already written, only another set of input
> parameters must be added to test this case where bug appeared.
>
> Yes, I know that it is a crazy amount of work.
>
> > About 1: would be great provided that it doesn't end-up in simply removing
> > examples which do not work.
>
> Definitely not. The main goal is to really fix all examples. This is
> a perfect opportunity for me to see the latest additions to yade! :)
>
> > Classifying examples is also an important point and I would discourage the
> > previous approach of moving failing scripts to a special
> > "examples/not-working" folder since it breaks the classification in
> > subfolders. Better rename them (something like *.py.fail) while keeping
> > them in their original location.
> > It is less clear if/how you intend to implement the "all examples must
> > work" policy. It is difficult to automatize testing of examples since they
> > are very heterogeneous. For instance some examples don't have a O.run() as
> > user is supposed to click "play" instead.
> > If the error happens after playing the error will not be detected. I
> > suspect many other special situations like this one.
>
> Maybe I would be able to implement this idea in following manner:
> run yade on each example with extra flag --test-example or such.
> This flag would mean that O.run() must be invoked anyways. If user
> has to click it, then yade instead does it. Some parts of examples
> would be untestable like interaction with GUI, in such cases a dummy
> function would be called instead (the point is that example.py need
> not be modified, the --test-example flag should take care of that). If
> examples produce some output file, than that is checked too. I am not
> sure how it will turn up. That's just a general idea.
>
>
> > About 2. I support the idea of investigating new techniques yet I don't
> > understand the suggestion very well. My impression is that all plugins are
> > already eligible for unit tests. For instance, testing a function from
> > utils in [1] did not need any change to the utils module itslef. All it
> > needs is to effectively design and write the unit tests for each other
> > function of each other class/module. That's indeed hundreds - if not
> > thousands - of tests.
>
> Well, time for me to learn what boost::unit_tests has to offer ;)
>
> The general idea within the framework is that it would be able to
> print a list of all publicly accessible C++ methods (not necessarily
> all of them being exported to python) which do not have an
> accompanying test.
>
> I don't know how to achieve this now. That's just an idea.
>
> Then using that list we would know the test coverage ;) If this list
> 

Re: [Yade-dev] Migrating to GitLab

[Anton Gladky]

Hello all,

last several years I did Yade releases and the process was
the following. Before the release was done I created the corresponding
release-branch (for example 0.60 [1]) and just tagged the new
Yade version there. It worked relatively good.

--> develop
  \\
   \ \
\Release 1 \Release 2
 \Release 1.1

I can remember only a couple of times, where the hot-fixes were
needed to be integrated into the release-branch due to some serious
stability or functionality issues.

Last years I have an experience of work with master-develop
approach. It is not bad. But you really need to know, why do
you need it.

I am fully support the feature-branch + merge request way of working.
It can really help to double check the code and implement some
additional tests.

[1] https://github.com/yade/trunk/tree/0.60

My 2cts

Regards

Anton

Am Mo., 7. Jan. 2019 um 17:39 Uhr schrieb Janek Kozicki :
>
> Bruno Chareyre said: (by the date of Mon, 7 Jan 2019 16:59:53 +0100)
>
> > Daily builds would be based on the develop branch.
>
> good, that answer my question from other mail.
>
> > > (by the way, with a tighter control on development, would we still
> > > need a distinction between "yade" and "yadedaily" packages ?..)
> >
> > Yade is stable release, not updated very often, included in main
> > debian/ubuntu repos.
> > Yadedaily is updated  more than daily, after each change to the source
> > code, not included in debian/ubuntu repos.
> > They are very different things and I think we need both.
>
> agreed.
>
> > > Also, with "develop" and "master", I guess any proposal for code
> > > modification would have to be closely examined and validated twice :
> > > - once to make it into "develop"
> > > - and once, to make it from "develop" into "master"
> > > ?...
> > There is no reason to check the develop->master merge if everything in
> > develop is already validated by regtests + human review.
> > Our github/master corresponds to "develop" more or less.
> > Merging develop into master in the new model would correspond to Anton
> > calling for update and releasing 2018.b. More or less.
>
> agred.
>
> > We probably need a liberal, truly unstable repo on the top of this, at
> > least in a transitory phase, so that everyone can play with gitlab a bit
> > and break everything with no limit. For instance to compare --no-ff,
> > --only-ff, and other variants.
>
> how about calling it experimental ? :-))
>
> And yes, we definitely need something like that.
> Where git reset --hard is nothing to be afraid of.
>
> --
> Janek Kozicki
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Yade is not compatible with CGAL_4.13

[Anton Gladky]

Hello Janek,

thanks for the fix! I have checked it and it really resolves the problem
with the newer CGAL. I will reactivate CGAL-function for the
Debian-build again.

Regards

Anton

Am Mo., 7. Jan. 2019 um 13:44 Uhr schrieb Janek Kozicki :
>
> Bruno Chareyre said: (by the date of Sun, 6 Jan 2019 15:34:11 +0100)
>
> > > Hi Janek,
> > > I think that was the right fix, thanks.
> > > Note that yade is not using the periodic triangulation implemented in CGAL
> > > [1] so there is no question on that point afaik.
> > > Bruno
>
> good, great to know. During the migration I am not committing
> anything to gitlab. I also will wait until you synchronize my commits
> on github to gitlab :)
>
> > > [1] that's because yade included periodicity years before cgal. I actually
> > > implemented a periodicity based on cgal's non-periodic triangulation. Cgal
> > > devs made periodic regular triangulation available more recently -
> > > triggered by me for a part - but it's still not used in yade. Hopefully it
> > > will be used one day but the refactoring it implies is a bit daunting.
>
> Before we even think about doing this, let's first make sure that
> whatever we modify has working tests :)
>
> > I forgot to answer the test coverage question: no, move() is not covered by
> > any test, even indirectly.
> > The function is not used in other parts of the code currently.
>
> That is one of the test cases which I want to discuss in the
> compatibility thread :)
>
> --
> Janek Kozicki
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Migrating to GitLab

[Anton Gladky]

Hello,

I would vote for the option with merge requests. Yade
has enough core developers to review, comment and
accept those requests. And it is not a problem if the MR
will take 2-3 days for the review process.

In this case one can see in the GitLab-pipeline, whether the code
compiles, tests passed, documentation is not broken and many
additional checks, which can improve the code quality.

My 2 cts

Anton

Am Di., 11. Dez. 2018 um 17:04 Uhr schrieb Bruno Chareyre
:
>
>
>
> On 12/5/18 7:21 AM, Klaus Thoeni wrote:
> > I terms of branching, I think this should be kept flexible. I think
> > branches make sense if you work on major changes. However, I still
> > think main devs should be able to push directly to the trunk,
> > obviously with care ;-)
> I think we need to distinguish two aspects:
> 1- do we "push" or do we "request-merge"?
> 2- who is allowed to accept the merge requests?
>
> I don't see a real need to use direct push (point 1), one exception is
> when fixing simple bugs maybe.
> What you say is more  (I guess) that some devs need enough rights to
> accept their own MR (point 2). Right?
>
> Bruno
>
>
>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] Yade is not compatible with CGAL_4.13

[Anton Gladky]

Dear Yade developers,

Yade fails to compile against newest CGAL_4,13,
The corresponding bug on Debian tracker is [#911685].

[#911685] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911685

Some relevant lines are here.

===
CGT::SimpleVertexInfo, CGT::SimpleCellInfo>;
CGT::_Tesselation::VertexHandle =
CGAL::internal::CC_iterator >,
CGAL::Boolean_tag, CGAL::Boolean_tag >,
CGAL::Alpha_shape_cell_base_3 >,
CGAL::Boolean_tag, CGAL::Boolean_tag >, CGAL::Sequential_tag>
> > >, CGAL::Boolean_tag, CGAL::Boolean_tag >, CGAL::Default,
 CGAL::Default, CGAL::Default>, false>; CGT::Real = double]':
/root/yade/yade-2018.02b/pkg/dem/TesselationWrapper.cpp:186:28:   required
from here
/root/yade/yade-2018.02b/lib/triangulation/Tesselation.ipp:78:12: error:
'CGT::_Tesselation >::RTriangulation' {aka 'class
CGAL::Regular_triangulation_3 >,
CGAL::Boolean_tag, CGAL::Boolean_tag >, CGAL::Alpha_shape_cell_base_3 >,
CGAL::Boolean_tag, CGAL:
:Boolean_tag >, CGAL::Sequential_tag>, CGAL::Default>'} has no
member named 'move_point'; did you mean 'Bare_point'?
  Vh = Tri->move_point ( vertexHandles[id], Sphere ( Point ( x,y,z ),pow (
rad,2 ) ) );

===

It would be good if somebody tries to compile the yade
against this CGAL version and fixes the issue. It is getting
really painful that CGAL developers break the API permanently

Thanks and regards

Anton
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Migrating to GitLab

[Anton Gladky]

Hi,

I think it is a very good idea to migrate the code to GirLab.
After >2 years of using this project I can only say the positive
about it.

Simple setup of CI/CD, automatic check of merge requests and
approve-technique can really improve the code quality and stability.

Regards

Anton


Am Di., 27. Nov. 2018 um 19:54 Uhr schrieb Bruno Chareyre <
bruno.chare...@3sr-grenoble.fr>:

> Hi devs,
> This is an announcement (1) and call for opinions (2).
>
> (1)  We will be migrating the integration framework to GitLab.com soon.
> That is: the config of buildbot, doc generation, and packaging will be
> using gitlab and will be hosted on gitlab.com [1], while hardware
> ressources will be provided locally by 3SR and/or Gricad's Gitlab [2].
> It should increase flexibility and decrease maintainance issues.
> Rémi made most of the work already (thank you!). Curious about it? You
> can check [3].
> The switch could happen in a couple months.
>
> ___
> (2)
> GitLab.com could also host the master branch in replacement of
> GitHub.com. It is not required though, and there is no problem to keep
> it on GitHub (like we kept bug tracking on launchpad after moving master
> to github), or not. This is open question to me. Migrating a branch is
> easy to do and easy to revert, so there is no technical constraint on
> us. It just needs to decide if we want to keep github or adopt gitlab
> for the source code (or both...).
>
> If source code was migrated, same question for bug tracking and answers?
>
> Whatever is decided for the above, the migration is also a good
> opportunity to think about the branch management model. Are we happy
> with it?
> Currently we have a centralized usage of a distributed CVS. Most
> contributors push to master directly  with strictly no pre-assessement
> of the contributions. Another possible (and classical) model would be to
> only accept merge requests from other branches. Which can have
> advantages, namely: easier to review since the the requests will usually
> collect a larger number of commits (all from a single user typically,
> hence self consistent), and more secured since it favors pre-assessment.
>
> Opinions?
>
> Cheers
>
> Bruno
>
> [1] https://about.gitlab.com/product/
> [2] https://gricad-gitlab.univ-grenoble-alpes.fr/
> [3] https://gitlab.com/remche/trunk
>
> --
> ___
> Bruno Chareyre
> Associate Professor
> ENSE³ - Grenoble INP
> Lab. 3SR
> BP 53
> 38041 Grenoble cedex 9
> Tél : +33 4 56 52 86 21
> Fax : +33 4 76 82 70 43
> 
>
> Email too brief?
> Here's why! http://emailcharter.org
>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] [Yade-users] [Question #674958]: Yade installation from ubunto 18.04.1

[Anton Gladky]

Hi Bruno,

> On another note, isn't the 16.04 package missing a dependency on
> python-pyqt5.qtwebkit since it has to be installed manually on the top
> of yadedaily on fresh install? I can try and add it to [1] if you,
> Anton, agree - best way for me to learn.

sure, go ahead! But please commit into the correct branch. For 16.04
it is "xenial" [1].

[1] https://github.com/yade/yadedaily/blob/xenial/control

Regards

Anton
Am Do., 11. Okt. 2018 um 12:39 Uhr schrieb Bruno Chareyre
:
>
> Hi there,
> We were considering it recently with Rémi but I was unsure if it was
> out-of-box or not, then we postponed (Rémi is no longer at 3SR,
> thanksfully he did not disapear completely but he may be less available).
> @Rémi, can you please set the repo? others can then test and fix.
>
> On another note, isn't the 16.04 package missing a dependency on
> python-pyqt5.qtwebkit since it has to be installed manually on the top
> of yadedaily on fresh install? I can try and add it to [1] if you,
> Anton, agree - best way for me to learn.
> Cheers
> Bruno
>
> [1] https://github.com/yade/yadedaily/blob/master/control
>
> On 10/10/2018 05:32 PM, Anton Gladky wrote:
> > (Moving discussion to yade-dev).
> >
> > @Remi, would it be possible for you to add 18.04 repo for yadedaily?
> > It should work out-of-box.
> >
> > Regards
> >
> > Anton
> >
> > Am Mi., 10. Okt. 2018 um 12:22 Uhr schrieb Robert Caulk
> > :
> >> Question #674958 on Yade changed:
> >> https://answers.launchpad.net/yade/+question/674958
> >>
> >> Robert Caulk proposed the following answer:
> >> yadedaily is not packaged yet, but yade is:
> >>
> >> sudo apt-get install yade
> >>
> >> should work on Ubuntu 18.04.
> >>
> >> --
> >> You received this question notification because your team yade-users is
> >> an answer contact for Yade.
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~yade-users
> >> Post to : yade-us...@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~yade-users
> >> More help   : https://help.launchpad.net/ListHelp
> > ___
> > Mailing list: https://launchpad.net/~yade-dev
> > Post to : yade-dev@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~yade-dev
> > More help   : https://help.launchpad.net/ListHelp
> >
>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] [Yade-users] [Question #674958]: Yade installation from ubunto 18.04.1

[Anton Gladky]

(Moving discussion to yade-dev).

@Remi, would it be possible for you to add 18.04 repo for yadedaily?
It should work out-of-box.

Regards

Anton

Am Mi., 10. Okt. 2018 um 12:22 Uhr schrieb Robert Caulk
:
>
> Question #674958 on Yade changed:
> https://answers.launchpad.net/yade/+question/674958
>
> Robert Caulk proposed the following answer:
> yadedaily is not packaged yet, but yade is:
>
> sudo apt-get install yade
>
> should work on Ubuntu 18.04.
>
> --
> You received this question notification because your team yade-users is
> an answer contact for Yade.
>
> ___
> Mailing list: https://launchpad.net/~yade-users
> Post to : yade-us...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-users
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] [Bug 1774065] Re: doctests fail with numpy 1.14

[Anton Gladky]

I workarounded it on Weekend [1]. I wanted to test it before the commit
into the Yade's trunk. There are really problems with the new numpy
1.14, python 2 and bz2. tar.gz works.

Also there were some problems with the new sphinx [2]. It should also be
backported into the Yade's trunk.

[1] https://salsa.debian.org/science-
team/yade/blob/master/debian/patches/10_fix_bz2_pyhon2_problem.patch

[2] https://salsa.debian.org/science-
team/yade/blob/master/debian/patches/12_fix_doc_generation.patch

-- 
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1774065

Title:
  doctests fail with numpy 1.14

Status in Yade:
  New
Status in Debian:
  Fix Released

Bug description:
  ==
  FAIL: saveDataTxt (yade.plot)
  Doctest: yade.plot.saveDataTxt
  --
  Traceback (most recent call last):
File "/usr/lib/python2.7/doctest.py", line 2226, in runTest
  raise self.failureException(self.format_failure(new.getvalue()))
  AssertionError: Failed doctest test for yade.plot.saveDataTxt
File "/usr/lib/x86_64-linux-gnu/yade/py/yade/plot.py", line 614, in 
saveDataTxt

  --
  File "/usr/lib/x86_64-linux-gnu/yade/py/yade/plot.py", line 626, in 
yade.plot.saveDataTxt
  Failed example:
  d=numpy.genfromtxt('/tmp/dataFile.txt.bz2',dtype=None,names=True)
  Exception raised:
  Traceback (most recent call last):
File "/usr/lib/python2.7/doctest.py", line 1315, in __run
  compileflags, 1) in test.globs
File "", line 1, in 
  d=numpy.genfromtxt('/tmp/dataFile.txt.bz2',dtype=None,names=True)
File "/usr/lib/python2.7/dist-packages/numpy/lib/npyio.py", line 1689, 
in genfromtxt
  fhd = iter(np.lib._datasource.open(fname, 'rt', encoding=encoding))
File "/usr/lib/python2.7/dist-packages/numpy/lib/_datasource.py", line 
260, in open
  return ds.open(path, mode, encoding=encoding, newline=newline)
File "/usr/lib/python2.7/dist-packages/numpy/lib/_datasource.py", line 
614, in open
  encoding=encoding, newline=newline)
File "/usr/lib/python2.7/dist-packages/numpy/lib/_datasource.py", line 
88, in _python2_bz2open
  raise ValueError("bz2 text files not supported in python2")
  ValueError: bz2 text files not supported in python2
  --
  File "/usr/lib/x86_64-linux-gnu/yade/py/yade/plot.py", line 627, in 
yade.plot.saveDataTxt
  Failed example:
  d['a']
  Exception raised:
  Traceback (most recent call last):
File "/usr/lib/python2.7/doctest.py", line 1315, in __run
  compileflags, 1) in test.globs
File "", line 1, in 
  d['a']
  NameError: name 'd' is not defined
  --
  File "/usr/lib/x86_64-linux-gnu/yade/py/yade/plot.py", line 629, in 
yade.plot.saveDataTxt
  Failed example:
  d['b']
  Exception raised:
  Traceback (most recent call last):
File "/usr/lib/python2.7/doctest.py", line 1315, in __run
  compileflags, 1) in test.globs
File "", line 1, in 
  d['b']
  NameError: name 'd' is not defined

  
  --
  Ran 58 tests in 1.063s

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1774065/+subscriptions

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] [Bug 1774065] Re: doctests fail with numpy 1.14

[Anton Gladky]

Workaround is to use tar.gz instead of bz2.

-- 
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1774065

Title:
  doctests fail with numpy 1.14

Status in Yade:
  New
Status in Debian:
  Confirmed

Bug description:
  ==
  FAIL: saveDataTxt (yade.plot)
  Doctest: yade.plot.saveDataTxt
  --
  Traceback (most recent call last):
File "/usr/lib/python2.7/doctest.py", line 2226, in runTest
  raise self.failureException(self.format_failure(new.getvalue()))
  AssertionError: Failed doctest test for yade.plot.saveDataTxt
File "/usr/lib/x86_64-linux-gnu/yade/py/yade/plot.py", line 614, in 
saveDataTxt

  --
  File "/usr/lib/x86_64-linux-gnu/yade/py/yade/plot.py", line 626, in 
yade.plot.saveDataTxt
  Failed example:
  d=numpy.genfromtxt('/tmp/dataFile.txt.bz2',dtype=None,names=True)
  Exception raised:
  Traceback (most recent call last):
File "/usr/lib/python2.7/doctest.py", line 1315, in __run
  compileflags, 1) in test.globs
File "", line 1, in 
  d=numpy.genfromtxt('/tmp/dataFile.txt.bz2',dtype=None,names=True)
File "/usr/lib/python2.7/dist-packages/numpy/lib/npyio.py", line 1689, 
in genfromtxt
  fhd = iter(np.lib._datasource.open(fname, 'rt', encoding=encoding))
File "/usr/lib/python2.7/dist-packages/numpy/lib/_datasource.py", line 
260, in open
  return ds.open(path, mode, encoding=encoding, newline=newline)
File "/usr/lib/python2.7/dist-packages/numpy/lib/_datasource.py", line 
614, in open
  encoding=encoding, newline=newline)
File "/usr/lib/python2.7/dist-packages/numpy/lib/_datasource.py", line 
88, in _python2_bz2open
  raise ValueError("bz2 text files not supported in python2")
  ValueError: bz2 text files not supported in python2
  --
  File "/usr/lib/x86_64-linux-gnu/yade/py/yade/plot.py", line 627, in 
yade.plot.saveDataTxt
  Failed example:
  d['a']
  Exception raised:
  Traceback (most recent call last):
File "/usr/lib/python2.7/doctest.py", line 1315, in __run
  compileflags, 1) in test.globs
File "", line 1, in 
  d['a']
  NameError: name 'd' is not defined
  --
  File "/usr/lib/x86_64-linux-gnu/yade/py/yade/plot.py", line 629, in 
yade.plot.saveDataTxt
  Failed example:
  d['b']
  Exception raised:
  Traceback (most recent call last):
File "/usr/lib/python2.7/doctest.py", line 1315, in __run
  compileflags, 1) in test.globs
File "", line 1, in 
  d['b']
  NameError: name 'd' is not defined

  
  --
  Ran 58 tests in 1.063s

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1774065/+subscriptions

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Python 2 removal

[Anton Gladky]

Hello Jerome,

thank you for you answer. I am not sure, how difficult could it be to
switch the Yade or to add a support of Python3. The syntax of python
2 and 3 is not so different. One can find a lot of such migration tutorials.

It would probably be more problematic two support both versions simultaneously
as to make a complete migration.

Best regards

Anton


2018-05-31 13:10 GMT+02:00 Jerome Duriez :
> Hi Anton,
>
> I'd consider this idea, ie I have some time and motivation, and no
> knowledge.. :-)
> Moreover / instead possible personal efforts, I could also look into the
> possibility proposing a dedicated internship to some IT (with an emphasis on
> the "I") student.
>
> Since I do not have a precise perception of the task, what is your opinion
> regarding the internship option ?
> Would the migration be indeed feasible in this framework ? For which
> internship duration (1 month, 5 month, .. ?) and which education level
> (license/undergraduate, master/graduate, .. ?)
>
> We can discuss by direct emails if appropriate,
>
>
> Best,
>
> Jérôme
>
> --
> Chargé de Recherche / Research Associate
> Irstea, RECOVER
> 3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
> +33 (0)4 42 66 99 21
>
> On 07/05/2018 20:09, Anton Gladky wrote:
>
> Dear Yade developers,
>
> Python 2 reaches end of life and will probably removed
> soon from Debian [1] and then most probably from Ubuntu-Mint
> etc archives too. It is only the question of time. I think it will unlikely
> happen till the Buster release (mid 2019), but it will probably
> happen at the end of 2019.
>
> Anyway, the migration of Yade onto Python 3 of Yade is really
> necessary to guarantee the further project life in modern distributions.
>
> It would be good if somebody finds some resources (time, man
> power) and start this work. It should not be too difficult, but
> requires time, knowledge and motivation to do this migration.
>
> It will be necessary to guarantee the smooth migration period not
> to break the other's work.
>
> I will not do it due to extreme lack of free time, but can do some
> kind of review/advice/etc.
>
> [1] https://lists.debian.org/debian-devel/2018/04/msg00508.html
>
> Best regards
>
> Anton
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] [Bug 1773337] Re: Doc section "Debian packaging instructions" obsolete

[Anton Gladky]

Hi Jerome,

thanks for catching it. This section can be completely removed, because
it is obsolete since many years.

-- 
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1773337

Title:
  Doc section "Debian packaging instructions" obsolete

Status in Yade:
  New

Bug description:
  Hi,

  The https://yade-dem.org/doc/prog.html#debian-packaging-instructions
  section seems to me obsolete.

  1.
  For sure, all links in 
https://yade-dem.org/doc/prog.html#prepare-source-package are broken. They 
actually direct to some trunk folder which has been first moved [1], then 
simply removed [2].
  YADE-specific links in 
https://yade-dem.org/doc/prog.html#create-binary-package are also broken

  2.
  By the way, is it actually still possible to have different packages for 
different YADE versions ? (or do we just have yadedaily and yade packages ?)
  And can any of these instructions still be used ?

  
   FIX proposal 

  Remove everything from https://yade-dem.org/doc/prog.html#debian-
  packaging-instructions :-) and essentially mention that YADE packaging
  is done according to https://github.com/yade/yadedaily files ?
  (Depending on the answer to 2.)


  Jérôme

  [1] 
https://github.com/yade/trunk/commit/31f3b16394f7b2801e3e015544e96215bf98ae3d
  [2] 
https://github.com/yade/trunk/commit/cc91b709a1a0529d5a0618bf7bbbd58a8a1bc720

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1773337/+subscriptions

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] Python 2 removal

[Anton Gladky]

Dear Yade developers,

Python 2 reaches end of life and will probably removed
soon from Debian [1] and then most probably from Ubuntu-Mint
etc archives too. It is only the question of time. I think it will unlikely
happen till the Buster release (mid 2019), but it will probably
happen at the end of 2019.

Anyway, the migration of Yade onto Python 3 of Yade is really
necessary to guarantee the further project life in modern distributions.

It would be good if somebody finds some resources (time, man
power) and start this work. It should not be too difficult, but
requires time, knowledge and motivation to do this migration.

It will be necessary to guarantee the smooth migration period not
to break the other's work.

I will not do it due to extreme lack of free time, but can do some
kind of review/advice/etc.

[1] https://lists.debian.org/debian-devel/2018/04/msg00508.html

Best regards

Anton

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Odp: Re: Yade for LTS Ubuntu 18.04

[Anton Gladky]

Dear Yade developers,

the new minor Yade 2018.02b was released on 20-th of February.
It allows us to compile Yade against CGAL_4.11 and fixes some
bugs. Tarballs are available on GitHub [1] and Launchpad [2].

Also the new version was uploaded to Debian [3] and even synced
into the Ubuntu LTS 18.04 Bionic [4] and successfully built for all
relevant platforms.

Thanks all for the great work!

[1] https://github.com/yade/trunk/releases
[2] https://launchpad.net/yade/+download
[3] https://buildd.debian.org/status/package.php?p=yade
[4] https://launchpad.net/ubuntu/+source/yade/2018.02b-1

Anton

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Odp: Re: Yade for LTS Ubuntu 18.04

[Anton Gladky]

Dear all,

thanks all for the effective and fast
contribution resolving CGAL issue!

I will try to fix polyhedron-crash test
as soon as possible and release
the new minor Yade version.

Best regards

Anton

On Feb 16, 2018 17:27, "Luc Scholtes"  wrote:

Hi guys,
Just a remark: the latest fix seems to solve the random behavior observed
several months ago with the FlowEngine:
https://answers.launchpad.net/yade/+question/659557
This is great :)
However, now, DFNFlow does not give the expected behavior: it seems that
the fractured cells are not identified correctly.
I'll try to work on it asap.
Best
Luc

2018-02-14 15:12 GMT+01:00 Janek Kozicki (yade-dev) :

> This is awesome. Thank you very much. I have just compiled the latest
> version, and I confirm that DEM-PFV test works.
>
> Finding uninitialized variables can be a super difficult job, hence:
> congratulations! And I must say that I am surprised why there was no
> warning about this variable. I specifically fixed all the remaining
> warnings in my second commit, just in hope of avoiding this kind of
> situation. The only warnings that I get right now are from external
> libraries: vtk and numpy. There must be some missing compiler flag, which
> allowed this uninitialized variable without a warning. Maybe we could try
> to find this missing compiler flag to enable uninitialized warning. Or
> maybe the problem was that this part of code was not instatinated in time
> when the warning could trigger.
>
> Regarding the checkPolyhedraCrush.py, for the time being I have locally
> (without a commit) commented out those four lines of code at the end which
> invoke O.Run(). That makes all tests to pass and debian package is
> successfully built. Of course I am not committing this commenting out. We
> need to think about this a bit. For the moment I am only 100% sure that the
> problem is due to CGAL 4.11, because it always works in 4.9. If we cannot
> fix this, then perhaps we release yade with cgal 4.11 support, but without
> polyhedra crush support.
>
> best regards
> Janek
>
> On 14 Feb 2018, 11:19 +0100, Bruno Chareyre  r>, wrote:
>
> Hi Robert,
> Congrats for finding the bug and thanks for fixing.
>
> On 02/13/2018 11:55 PM, Robert Caulk wrote:
>
> the issue was compiler related. GCC 5.4 on ubuntu 16.04 initialized
> factorizeOnly to false by default, while GCC 7.2 on ubuntu 18.04 did
> not do this.
>
>
> That's a good example of "undefined" behavior when using non-initialized
> variables... Definitely a nasty bug.
>
> Therefore, the only necessary change ended up being the explicit
> initialization of factorizeOnly=false.
>
> Indeed. :)
>
> In addition to the bug fix, I edited the solvers so flow.useSolvers=3
> and 4 can now be used with the default CPU build. I can confirm that
> flow.useSolver=4 enables multicore CPU factorization, while
> flow.useSolver=3 sticks to 1 core factorization :-).
>
> Excellent. FYI multicore CPU factorization was faster than single core
> in my benchmarks, but multicore solve phase (using the factorized form)
> was not, it was even a bit slower than single core. Hence the distinct
> attributes  numFactorizeThreads and numSolveThreads.
> Cheers
>
> Bruno
>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help : https://help.launchpad.net/ListHelp
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
>

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Yade for LTS Ubuntu 18.04

[Anton Gladky]

Yes, it should be OK.

Anton


2018-02-09 16:06 GMT+01:00 Bruno Chareyre <bruno.chare...@grenoble-inp.fr>:
> What is an appropriate system to try this? ubuntu 18.04 beta is ok?
> B
>
>
> On 02/08/2018 07:35 PM, Janek Kozicki (yade-dev) wrote:
>>
>> Hi Anton and Bruno,
>>
>> I am glad that I can help, and use this opportunity to get back in track
>> ;) So I will do this entire Saturday after I get back home on friday night.
>>
>> Should I work on latest yade trunk?
>>
>> BTW: I'm writing this from an airport ;)
>>
>> Best regards,
>> Janek
>>
>> On 8 Feb 2018, 19:10 +0100, Anton Gladky <gladky.an...@gmail.com>, wrote:
>>>
>>> Hi Bruno,
>>>
>>> CGAL_ 4.11 is the only version now for Debian (testing) [1]
>>> and upcoming Ubuntu 18.04 [2]. The shipped Yade does
>>> not support CGAL due to compilation problems.
>>>
>>> I am preparing the new Yade upload, but we have a chance
>>> to patch the Yade within the next two weeks or prepare
>>> the 2018.02b release with CGAL-support and upload it.
>>>
>>> [1] https://tracker.debian.org/pkg/cgal
>>> [2] https://launchpad.net/ubuntu/+source/cgal
>>>
>>> Anton
>>>
>>>
>>> 2018-02-08 18:45 GMT+01:00 Bruno Chareyre
>>> <bruno.chare...@grenoble-inp.fr>:
>>>>
>>>> Hi Anton,
>>>> Thank you very much.
>>>> I'm not so sure what we are speaking about here.
>>>> Yade 2018.02a is the candidate source code for producing a binary
>>>> yade-stable in Ubuntu 18.04, correct (approximately)?
>>>> If yes, can we build yade-stable with CGAL at the moment?
>>>> Bruno
>>>>
>>>>
>>>>
>>>> On 02/08/2018 06:35 PM, Anton Gladky wrote:
>>>>>
>>>>>
>>>>> Well, if we find a way to fix it within the next 2 weeks,
>>>>> I think there is a chance to get it pushed into Debian->Ubuntu.
>>>>>
>>>>> Regards
>>>>>
>>>>> Anton
>>>>>
>>>>>
>>>>> 2018-02-08 15:23 GMT+01:00 Bruno Chareyre
>>>>> <bruno.chare...@grenoble-inp.fr>:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 02/07/2018 05:35 PM, Janek Kozicki (yade-dev) wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Regarding compiling yade with CGAL 4.11, I can look into it on
>>>>>>> Saturday,
>>>>>>> if my last patches didn't work for you?
>>>>>>
>>>>>>
>>>>>> I did not test it yet I'm afraid. :-/
>>>>>> It sounds like a critical issue for a 18.04 release. Is it?
>>>>>> Would that mean to skip the whole CGAL related code in the binary
>>>>>> release?
>>>>>> I'll go back to this asap, thanks for pinging.
>>>>>>
>>>>>> Bruno
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ___
>>>>>> Mailing list: https://launchpad.net/~yade-dev
>>>>>> Post to : yade-dev@lists.launchpad.net
>>>>>> Unsubscribe : https://launchpad.net/~yade-dev
>>>>>> More help : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ___
>>>> Mailing list: https://launchpad.net/~yade-dev
>>>> Post to : yade-dev@lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~yade-dev
>>>> More help : https://help.launchpad.net/ListHelp
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~yade-dev
>>> Post to : yade-dev@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~yade-dev
>>> More help : https://help.launchpad.net/ListHelp
>
>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Yade for LTS Ubuntu 18.04

[Anton Gladky]

Hi Bruno,

CGAL_ 4.11 is the only version now for Debian (testing) [1]
and upcoming Ubuntu 18.04 [2]. The shipped Yade does
not support CGAL due to compilation problems.

I am preparing the new Yade upload, but we have a chance
to patch the Yade within the next two weeks or prepare
the 2018.02b release with CGAL-support  and upload it.

[1] https://tracker.debian.org/pkg/cgal
[2] https://launchpad.net/ubuntu/+source/cgal

Anton


2018-02-08 18:45 GMT+01:00 Bruno Chareyre <bruno.chare...@grenoble-inp.fr>:
> Hi Anton,
> Thank you very much.
> I'm not so sure what we are speaking about here.
> Yade 2018.02a is the candidate source code for producing a binary
> yade-stable in Ubuntu 18.04, correct (approximately)?
> If yes, can we build yade-stable with CGAL at the moment?
> Bruno
>
>
>
> On 02/08/2018 06:35 PM, Anton Gladky wrote:
>>
>> Well, if we find a way to fix it within the next 2 weeks,
>> I think there is a chance to get it pushed into Debian->Ubuntu.
>>
>> Regards
>>
>> Anton
>>
>>
>> 2018-02-08 15:23 GMT+01:00 Bruno Chareyre
>> <bruno.chare...@grenoble-inp.fr>:
>>>
>>>
>>> On 02/07/2018 05:35 PM, Janek Kozicki (yade-dev) wrote:
>>>>
>>>>
>>>> Regarding compiling yade with CGAL 4.11, I can look into it on Saturday,
>>>> if my last patches didn't work for you?
>>>
>>> I did not test it yet I'm afraid. :-/
>>> It sounds like a critical issue for a 18.04 release. Is it?
>>> Would that mean to skip the whole CGAL related code in the binary
>>> release?
>>> I'll go back to this asap, thanks for pinging.
>>>
>>> Bruno
>>>
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~yade-dev
>>> Post to : yade-dev@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~yade-dev
>>> More help   : https://help.launchpad.net/ListHelp
>
>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Yade for LTS Ubuntu 18.04

[Anton Gladky]

Well, if we find a way to fix it within the next 2 weeks,
I think there is a chance to get it pushed into Debian->Ubuntu.

Regards

Anton


2018-02-08 15:23 GMT+01:00 Bruno Chareyre :
>
>
> On 02/07/2018 05:35 PM, Janek Kozicki (yade-dev) wrote:
>>
>>
>> Regarding compiling yade with CGAL 4.11, I can look into it on Saturday,
>> if my last patches didn't work for you?
>
> I did not test it yet I'm afraid. :-/
> It sounds like a critical issue for a 18.04 release. Is it?
> Would that mean to skip the whole CGAL related code in the binary release?
> I'll go back to this asap, thanks for pinging.
>
> Bruno
>
>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Yade for LTS Ubuntu 18.04

[Anton Gladky]

Hi Bruno,

OK, let`s try to do it on Wednesday (I will probably be available after 8pm).

I also want to ask everybody to have a look at the bug-tracker [1].
It would be good to fix at least some of them. For example #1723454
is analyzed, needs to be fixed (nullptr check?) and tested Maybe
a couple more...

[1] https://bugs.launchpad.net/yade

Regards

Anton


2018-02-05 16:24 GMT+01:00 Bruno Chareyre <bruno.chare...@grenoble-inp.fr>:
> Hi Anton,
> Thanks for notice.
> I would suggest to release ASAP unless someone raises a solid reason not to
> do so by - let's say - wednesday this week.
> Cheers
> Bruno
>
>
> On 02/03/2018 05:49 PM, Anton Gladky wrote:
>>
>> Dear Yade developers,
>>
>> the freeze for the next 18.04 LTS version of Ubuntu
>> (stop sync from Debian) will be on the 1st of March.
>>
>> If the newer Yade version should appear here, one
>> need to release it ASAP and to be pushed in Debian.
>>
>> Please let me know we if there some reasons not
>> to release it now.
>>
>> Thanks
>>
>> Anton
>>
>> ___
>> Mailing list: https://launchpad.net/~yade-dev
>> Post to : yade-dev@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~yade-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] Yade for LTS Ubuntu 18.04

[Anton Gladky]

Dear Yade developers,

the freeze for the next 18.04 LTS version of Ubuntu
(stop sync from Debian) will be on the 1st of March.

If the newer Yade version should appear here, one
need to release it ASAP and to be pushed in Debian.

Please let me know we if there some reasons not
to release it now.

Thanks

Anton

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] doc warning on Qt4->Qt5

[Anton Gladky]

Hi Bruno,

the idea is to drop deprecated (and duplicated) Qt4-code,
when it will be reasonable. If you think there are 14.04
users, then you are right, it is better to wait till 14.04 gets
EOL and then drop Qt4 from the code and declare Yade
as Qt5-only.

Regards

Anton


2017-11-30 16:36 GMT+01:00 Bruno Chareyre <bruno.chare...@grenoble-inp.fr>:
>
>
> On 11/29/2017 07:31 PM, Anton Gladky wrote:
>>
>> The question is, how long does Yade want to support Ubuntu 14.04 LTS,
>> where QT5 version of libqglviewer does not exist. Another option is to
>> provide backport of libqglviewer-qt5-dev for Ubuntu 14.04, document it
>> as a mandatory package for Yade and drop Qt4 support completely.
>
> Hi Anton,
> I'm not sure I get all aspects of your question but I would tend to choose
> the energy-minimizing solution.
> For binary packages (I guess it is your main question) I don't think it is
> worth it to support 14.04 if it needs more efforts. Backporting
> libqglviewer, typically, is a waste of time since we are in the tail of
> 14.04. For the moment the 14.04 binary builds without problems, so let it
> be.
> If in the futur some changes become painful because of Qt4 we can just drop
> 14.04 support at that point.
> Would it be reasonable?
>
> In my mind, this is not really related to the resurected comment. I found
> the comment more useful for people _compiling_ on 14.04 (and possibly on
> other exotic distros, clusters, etc.) as a pointer to a potential source of
> trouble.
>
> Cheers
>
> Bruno
>
>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Yade with CGAL 4.11

[Anton Gladky]

Hi all,

is there any progress on fixing this issue? I have disabled CGAL for
Debian builds, but it would be good to switch it on again.

Also the stable Yade version is almost one year old. It is time to release
something newer soon. If there are some volunteers to go through
existing bugs on launchpad [1] and fix/close/react on some of them,
it would be good.

I will probably be able to prepare a release at the beginning of 2018.

[1] https://bugs.launchpad.net/yade

Best regards

Anton


2017-11-07 19:35 GMT+01:00 Bruno Chareyre :
>
>
> On 11/07/2017 06:47 PM, Janek Kozicki wrote:
>>
>> I just feel a little uneasy about cross_product of two
>> (sphere-sphere) pairs ;)
>
>
> Well... after admitting that spheres can be mutually orthogonal (which is
> really the case) cross product is fine... :)
> But you are right, here cross product is really ordinary cross_product.
> Bruno
>
>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Yade with CGAL 4.11

[Anton Gladky]

Hi Janek,

parallel Yade build in Debian/Ubuntu is disabled due to enormous RAM
consumption during build which leads to compilation failure. Remove
"--no-parallel" option here [1] and you will be able to build in parallel mode.

I tried to fix it myself, but without any positive result.

I will probably remove libcgal-dev dependency from the package right now
not to block CGAL migration. If we find a solution, it can easily be resumed
later.

[1] https://sources.debian.net/src/yade/2017.01a-9/debian/rules/#L7

Best regards

Anton


2017-11-03 10:21 GMT+01:00 Janek Kozicki <janek_li...@wp.pl>:
> Hi,
>
> I am building with `time dpkg-buildpackage -rfakeroot -b -j32` but it appears 
> that -j32 is deliberately ignored. I understand why, but my PC is powerful 
> enough ;) Can you tell me how to enable it back?
>
> It must be somewhere in ./debian/* dir that you have prepared.
>
> best regards
> Janek
>
> Janek Kozicki said: (by the date of Fri, 3 Nov 2017 09:43:25 +0100)
>
>> Hi Anton,
>>
>> did you try to fix it yourself during past week? (I see that this bug
>> report is a week old) If yes, do you have maybe some useful advice?
>>
>> Am I correct that this FTBFS is about yade in (clean install of)
>> stretch with CGAL 4.11 pulled from experimental?
>>
>> best regards
>> Janek
>>
>>
>> Anton Gladky said: (by the date of Thu, 2 Nov 2017 21:22:51 +0100)
>>
>> > Hi all,
>> >
>> > it looks like Yade is not compatible with the new CGAL 4.11 and
>> > it blocks the upload of new CGAL into the Debian [1].
>> >
>> > It would be good if somebody could try to fix this issue.
>> >
>> > [1] https://bugs.debian.org/876524
>> >
>> > Thanks
>> >
>> > Anton
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~yade-dev
>> > Post to : yade-dev@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~yade-dev
>> > More help   : https://help.launchpad.net/ListHelp
>>
>>
>> --
>> Janek Kozicki   http://janek.kozicki.pl/  |
>>
>> ___
>> Mailing list: https://launchpad.net/~yade-dev
>> Post to : yade-dev@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~yade-dev
>> More help   : https://help.launchpad.net/ListHelp
>
>
> --
> Janek Kozicki   http://janek.kozicki.pl/  |
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] Yade with CGAL 4.11

[Anton Gladky]

Hi all,

it looks like Yade is not compatible with the new CGAL 4.11 and
it blocks the upload of new CGAL into the Debian [1].

It would be good if somebody could try to fix this issue.

[1] https://bugs.debian.org/876524

Thanks

Anton

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Please: we don't want compile warnings

[Anton Gladky]

Hi,

I think it makes sense to enable "warnung-as-errors" for buildbot-builds.
So the build will fail if new warnings were introduced in the last commits.

Something like:

cmake -DCMAKE_CXX_FLAGS="-Werror -Wall" ../src/to/yade

Of course one need to fix all warnings before switching it on hardly.

Anton


2017-11-02 13:38 GMT+01:00 Bruno Chareyre :
> Hi all,
> I've seen an increase of compile warnings after some commits in the last
> months (members of the blamelist in bcc of this message ;)).
> I would like to recall that compile warnings should be considered like bugs
> and be fixed.
> Please make sure there is no compile warning before pushing code to trunk,
> and if some code you previously pushed gives some please fix.
> Warnings reveal real problems sometimes, and they clutter the compile logs
> always.
> If you are not sure how to fix some of them (e.g. the award-winning
> "comparison between signed and unsigned") you can ask on yade-dev.
> Cheers
> Bruno
>
>
>
> --
> ___
> Bruno Chareyre
> Associate Professor
> ENSE³ - Grenoble INP
> Lab. 3SR
> BP 53
> 38041 Grenoble cedex 9
> Tél : +33 4 56 52 86 21
> Fax : +33 4 76 82 70 43
> 
>
> Email too brief?
> Here's why! http://emailcharter.org
>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] [Bug 1723454] Re: "Segmentation fault (core dumped)" error when "DomainLimiter" is added

[Anton Gladky]

Thanks for bug report. Backtrace is here:

==
#0  0x557b10ddd180 in  ()
#1  0x7fac49e31cf9 in 
boost::python::converter::shared_ptr_deleter::operator()(void const*) () at 
/usr/lib/x86_64-linux-gnu/libboost_python-py27.so.1.62.0
#2  0x7fac4bbb951a in boost::detail::sp_counted_base::release() 
(this=0x557b134a25c0) at 
/usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:146
#3  0x7fac4bbb9af5 in boost::detail::sp_counted_base::release() 
(this=) at 
/usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:144
#4  0x7fac4bbb9af5 in boost::detail::shared_count::~shared_count() 
(this=, __in_chrg=) at 
/usr/include/boost/smart_ptr/detail/shared_count.hpp:473
#5  0x7fac4bbb9af5 in boost::shared_ptr::~shared_ptr() 
(this=, __in_chrg=) at 
/usr/include/boost/smart_ptr/shared_ptr.hpp:336
#6  0x7fac4bbb9af5 in boost::shared_ptr::reset() 
(this=0x557b1356d900) at /usr/include/boost/smart_ptr/shared_ptr.hpp:667
#7  0x7fac4bbb9af5 in BodyContainer::erase(int, bool) (this=0x557b11b86410, 
id=, eraseClumpMembers=eraseClumpMembers@entry=false) at 
./core/BodyContainer.cpp:61
#8  0x7fac4c0b17ce in DomainLimiter::action() (this=0x557b13686ba0) at 
./pkg/dem/DomainLimiter.cpp:27
#9  0x7fac4bc55cb2 in Scene::moveToNextTimeStep() 
(this=this@entry=0x557b11aa97b0) at ./core/Scene.cpp:88
#10 0x7fac4bc58a63 in SimulationFlow::singleAction() (this=0x557b119961f0) 
at ./core/SimulationFlow.cpp:24
#11 0x7fac4bc5c58f in ThreadWorker::callSingleAction() 
(this=0x557b119961f0) at ./core/ThreadWorker.cpp:71
#12 0x7fac4bc59707 in ThreadRunner::call() (this=this@entry=0x557b11b887e0) 
at ./core/ThreadRunner.cpp:52
#13 0x7fac4bc599e0 in ThreadRunner::run() (this=0x557b11b887e0) at 
./core/ThreadRunner.cpp:26
#14 0x7fac4bc5bb42 in boost::function0::operator()() const 
(this=) at /usr/include/boost/function/function_template.hpp:770
#15 0x7fac4bc5bb42 in boost::detail::thread_data::run() (this=) at 
/usr/include/boost/thread/detail/thread.hpp:116
#16 0x7fac48ebbf96 in  () at 
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.62.0
#17 0x7fac4eb72494 in start_thread (arg=0x7fac01d84700) at 
pthread_create.c:333
#18 0x7fac4df91abf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

==
Full relevant backtrace:


#7  0x7fac4bbb9af5 in BodyContainer::erase(int, bool) (this=0x557b11b86410, 
id=, eraseClumpMembers=eraseClumpMembers@entry=false) at 
./core/BodyContainer.cpp:61  
b = @0x557b1356d900: {  

 
  px = 0x0, 

 
  pn = {

 
pi_ = 0x0   

 
  } 

 
}   

 
scene = @0x557b11b863d0: {  

 
  px = 0x557b11aa97b0,  

 
  pn = {

 
pi_ = 0x557b11b87b10

 
  } 

 
}
==

body[id] is probably a nullptr here [1].

[1]
https://github.com/yade/trunk/blob/2017.01/core/BodyContainer.cpp#L61

Anton

-- 
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1723454

Re: [Yade-dev] No more commit emails ? (no more gitHub/trunk import into Launchpad)

[Anton Gladky]

It does not work unfortunately. So, we need an assistance from
Remi to send mails from the buildbot.

Best regards

Anton


2017-06-19 20:53 GMT+02:00 Anton Gladky <gladky.an...@gmail.com>:
> 2017-06-19 14:42 GMT+02:00 Bruno Chareyre <bruno.chare...@grenoble-inp.fr>:
>> There is probably a way to make github (instead of launchpad) send the
>> commit messages.
>> Maybe time for a migration?
>
> I have just enabled them. Let's see, whether it will work with
> launchpad mailing list. Launchpad code import was just like
> a backup and emails. So, if this way works,
> we can deprecate the source code on the launchpad.
>
> If this way will no work, I would ask Remi to send git diffs through
> the buildbot.
>
> Best regards
>
> Anton

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] No more commit emails ? (no more gitHub/trunk import into Launchpad)

[Anton Gladky]

2017-06-19 14:42 GMT+02:00 Bruno Chareyre :
> There is probably a way to make github (instead of launchpad) send the
> commit messages.
> Maybe time for a migration?

I have just enabled them. Let's see, whether it will work with
launchpad mailing list. Launchpad code import was just like
a backup and emails. So, if this way works,
we can deprecate the source code on the launchpad.

If this way will no work, I would ask Remi to send git diffs through
the buildbot.

Best regards

Anton

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] buildbot failure in Yade on yade-full

[Anton Gladky]

The idea was to build with the buildbot the maximal set of features,
if it is possible. It was probably forgotten to update that set.

Anton


2017-05-03 10:40 GMT+02:00 Bruno Chareyre <bruno.chare...@grenoble-inp.fr>:
> Hi,
> Every combination must compile and the error needed a fix (now fixed, thx!),
> yet the question of which combination the buidlbot should build (granted
> that we don't have the ressource to build every possible combinations) is
> valid.
> I would think it needs to include as many features as possible, and I'm
> actually surprised that it doesn't include LINSOLV since yadedaily has it (I
> think??).
> I'll try and have a look.
>
> Bruno
>
> On 05/02/2017 11:34 PM, Janek Kozicki wrote:
>>
>> Anton Gladky said: (by the date of Tue, 2 May 2017 22:38:29 +0200)
>>
>>> Hi Robert,
>>>
>>> the Yade should work in any combination of enabled features and should
>>> not fail to compile or to crash. I did not look into your changes, but I
>>> think
>>> you need to add a couple of #ifdef guards to make it compilable.
>>>
>>> Best regards
>>> Anton
>>
>> ahhh... now I know. My apologies :-)
>>
>>
>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] buildbot failure in Yade on yade-full

[Anton Gladky]

Hi Robert,

the Yade should work in any combination of enabled features and should
not fail to compile or to crash. I did not look into your changes, but I think
you need to add a couple of #ifdef guards to make it compilable.

Best regards

Anton


2017-05-02 21:45 GMT+02:00 Robert Caulk :
> Ok so after looking into this more I noticed that the buildbot is not using
> the default cmake build. In this case, LINSOLV is disabled on the buildbot
> machine, which is what led to the occurrence of the error on the buildbot
> but not my desktop.
>
> Shouldn't we have the buildbot also testing out compilation of features that
> are considered "default" in addition to a stripped down build? In this case,
> the entire LINSOLV package is not compiled and tested by the buildbot after
> every commit.
>
> Best,
>
> Robert
>
> On Tue, May 2, 2017 at 10:55 AM, Robert Caulk  wrote:
>>
>> Hey guys,
>>
>> So I have an issue I am hoping someone might be able to help me with.
>> These changes compile perfectly on my desktop [1]. But the buildbot catches
>> an issue that my desktop did not catch [2]. It appears to be an issue with
>> the use of templates inheritance in the flow engine regime, which I have now
>> fixed.  But again, it compiles perfectly fine on my desktop either way. So
>> the only way for me to find out if this is going to pass the buildbot is to
>> push more changes to the trunk? And let's be honest, the likelihood of the
>> buildbot getting upset about something else is high and the last thing we
>> need are pushes to the trunk in the form of compilation trial-and-errors.
>>
>> So what should I do? Has anyone else encountered this issue where the
>> trunk compiles fine on their own computer but the buildbot catches a
>> problem?
>>
>> Cheers,
>>
>> Robert
>>
>>
>>
>> [1]https://github.com/yade/trunk/commit/f6970362d9e6e866e8adbc8cbea18e54f677f785
>>
>> [2]https://yade-dem.org/buildbot/builders/yade-full/builds/3979/steps/compile/logs/stdio
>>
>> On Tue, May 2, 2017 at 9:58 AM, Robert Caulk  wrote:
>>>
>>> Very sorry, taking care of this now.
>>>
>>> On Tue, May 2, 2017 at 10:51 AM,  wrote:

 The Buildbot has detected a failed build on builder yade-full while
 building yade.
 Full details are available at:
  https://yade-dem.org/buildbot/builders/yade-full/builds/3979

 Buildbot URL: https://yade-dem.org/buildbot/

 Buildslave for this Build: r0calcul9

 Build Reason: scheduler
 Build Source Stamp: [branch master]
 f6970362d9e6e866e8adbc8cbea18e54f677f785
 Blamelist: robcaulk 

 BUILD FAILED: failed compile

 sincerely,
  -The Buildbot



 ___
 Mailing list: https://launchpad.net/~yade-dev
 Post to : yade-dev@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~yade-dev
 More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] [Bug 1685735] Re: Exception KeyError

[Anton Gladky]

Could you please try to use "O.stop()" insntead of "exit()"?

-- 
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1685735

Title:
  Exception KeyError

Status in Yade:
  New

Bug description:
  I run parametric studies using yade-batch.

  I have a stop-condition that I check regularly. If the stop-condition
  is reach, I exit the script using sys.exit(0); (see attached script).

  The script exit well but when I look at the log, I have:

  Exception KeyError: KeyError(140414846273280,) in  ignored

  Yade version: yade-2017-03-30.git-5528a5c
  Available features: ['Odeint', 'VTK', 'OpenMP','GTS', 'CGAL', 'PFVFLOW', 
'LINSOLV', 'GL2PS', 'LBMFLOW']

  Full output:
  TCP python prompt on localhost:9013, auth cookie `**'
  Welcome to Yade 2017-03-30.git-5528a5c 
  XMLRPC info provider on http://localhost:21013
  Running script scriptV4c.py
  /usr/lib/python2.7/dist-packages/matplotlib/artist.py:221: 
MatplotlibDeprecationWarning: This has been deprecated in mpl 1.5, please use 
the
  axes property.  A removal date has not been set.
warnings.warn(_get_axes_msg, mplDeprecation, stacklevel=1)
  Nombre de spheres:  4189
  glue
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  reverse
  done
  Exception KeyError: KeyError(140414846273280,) in  ignored

  === JOB SUMMARY 
  id  : OMP_NUM_THREADS=1,shearVel=0.01,volfrac=0.52,frictDegree=50
  status  : 0 (OK)
  duration: 23:30:54
  command : YADE_BATCH=2017_04_12_friction.table:19 DISPLAY=  
/data/yade/install/bin/yade-2017-03-30.git-5528a5c --threads=1 --nice=10 -x 
scriptV4c.py> 
2017_04_05_frictcoef/scriptV4c.py.OMP_NUM_THREADS=1,shearVel=0.01,volfrac=0.52,frictDegree=50.log
 2>&1
  started : Thu Apr 13 11:45:03 2017
  finished: Fri Apr 14 11:15:57 2017

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1685735/+subscriptions

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Critical bugfix for periodic boundaries

[Anton Gladky]

Hi Bruno,

thanks for the catch and for the fix. This commit was pushed
into the frozen Debian to have it fixed in Stretch [1].

[1] https://tracker.debian.org/news/843733

Best regards

Anton


2017-04-14 12:28 GMT+02:00 Bruno Chareyre :
> Hello all,
> A recent commit [1] fixed a critical bug of contact detection in periodic
> boundary conditions. All simulations with periodic conditions are
> potentially affected.
> I strongly suggest an update for everyone using periodic boundaries.
>
> I know personally at least four users who suffered from this bug over the
> last six years, I imagine many more have had the same problem without
> understanding it.
> Typically, a periodic simulation would crash in a (seemingly)
> non-deterministic way, after hours or days of simulations. It was actually
> the consequence of having one or more particle inside another, because the
> contact between them was missed (hence if you have unexplained crashes, stop
> the simulation right before it and check if you find particles overlapping
> too much).
>
> The logic of periodic sorting is so involved (I'm glad Vaçlav invented it)
> that I don't dare trying to explain the problem in details. The short story:
> in contrast with the non-periodic case sorting elements of a periodic ring
> can't be done in N steps (at least with our algorithm, N being the number of
> elements). As it was the case before the fix the list of positions was left
> partially un-ordered.
>
> Cheers.
>
> Bruno
>
> [1]
> https://github.com/yade/trunk/commit/c7c8e6f62d452c81a31415f05a12587a6cc8c452
>
>
>
> --
>
> ___
> Bruno Chareyre
> Associate Professor
> ENSE³ - Grenoble INP
> Lab. 3SR
> BP 53
> 38041 Grenoble cedex 9
> Tél : +33 4 56 52 86 21
> Fax : +33 4 76 82 70 43
> 
>
> Email too brief?
> Here's why! http://emailcharter.org
>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Yade GUI problem on Debian Stretch

[Anton Gladky]

That issue is already fixed.

Anton


2017-04-13 20:21 GMT+02:00 Janek Kozicki :
> Ouch, this is bad. Did you manage to fix this so far? If not, is
> there still a chance to push a fix to stretch?
> I will have a look at that.
>
> From my previous graphics problems I would start at looking at what
> exactly qglviewer version is use, and whether qt4 and qt5 are being
> mixed.
>
> cheers
> Janek

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] YADE_SPH

[Anton Gladky]

Hi Bruno,

I have no information whether it is planned to develop it further
and whether somebody is using it. As far as I remember, all
SPH-relevant changes are guarded by the YADE_SPH
macroses.

It looks like isActive is used also in ViscoelasticPM and LudingPM and
ViscoelasticCapillarPM.

Best regards

Anton


2017-04-04 11:55 GMT+02:00 Bruno Chareyre :
> Dear Anton,
> Could you tell us the status of the YADE_SPH feature and if there is a
> chance to see it further developed?
> I incidentally found an attribute which seems to be used exlusively for that
> purpose (here below), so I'm now wondering.  :)
> Bruno
>
> class Interaction: public Serializable{
> ...
> bool isActive;
>
> --
> ___
> Bruno Chareyre
> Associate Professor
> ENSE³ - Grenoble INP
> Lab. 3SR
> BP 53
> 38041 Grenoble cedex 9
> Tél : +33 4 56 52 86 21
> Fax : +33 4 76 82 70 43
> 
>
> Email too brief?
> Here's why! http://emailcharter.org
>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 4027: added tmux command tip

[Anton Gladky]

Hi guys,

just FYI. I needed to drop PDF-file from the Debian version of yade
for now, because it caused compilation failures and there was a
chance for yade to be dropped from the next stable Debian.

If it is fixed already, I will resurrect PDF file later after release.

Best regards

Anton


2017-03-28 17:50 GMT+02:00 Bruno Chareyre :
> Finally the buildbot is back and the doc is uploaded ([1], linked from last
> section of [2]).
> When you "make doc" and it fails it can be latex/pdf failure, html failure,
> or e-pub failure, they are three independent compilations. That's why you
> got the pdf maybe.
>
> Bruno
>
> [1] https://yade-dem.org/doc/amazonEC2.html#cloudcomputing
> [2] https://yade-dem.org/doc/installation.html

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] [Bug 1666339] Re: DFNflow crashes for compiled trunk but not non-optimized debug compiled trunk

[Anton Gladky]

Hi,

it can also be a bug in a specific version of CGAL. To exclude a
compiler error, you can try to compile the Yade using Clang
(instructions in the documentation).

Anton

-- 
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1666339

Title:
  DFNflow crashes for compiled trunk but not non-optimized debug
  compiled trunk

Status in Yade:
  New

Bug description:
  Distro: Xenial 16.04LTS
  Yade Version: yade-2017-0207.git-11c276f
  Compilation: default compilation with debug flags and '#define DFNFLOW' 
uncommented in DFNFlow.cpp

  
  Summary:

  DFNFlowEngine crashes for compiled yade-2017-0207.git-11c276f sources.
  The segmentation fault also occurs for a debug compiled version and
  yields the attached core dump. Interestingly, the DFNFlowEngine does
  not crash for a non-optimized debug compilation of the same sources.

  
  Description of failure:

  According to the core dump, the failure can be traced back to
  DFNFlow.cpp:176, where it is checking if the cell is inifinite
  (although I have also had it fail at the permeability assignment
  directly below line 176 for a modified version of DFNflow.cpp).

   DFNFlow.cpp:

   176: if ( Tri.is_infinite(cell1) || Tri.is_infinite(cell2)) cerr<<"Infinite 
cell found intrickPermeability, should be handled somehow, maybe"<info().kNorm()[facet->second]=cell2->info().kNorm()[Tri.mirror_index(cell1,
 facet- >second)] = pow((aperture+residualAperture),3)/(12*viscosity);

  I am unsure why this line is causing a crash in the optimized-debug
  compiled code, but not the non-optimized-debug compiled code.

  My optimized-debug compiled executable is simply built with the flag
  -DDEBUG=ON. My non-optimized debug compiled code uses an edited
  CMakeLists.txt to avoid optimization:

  IF(CMAKE_COMPILER_IS_GNUCC)
SET(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -O0")
SET(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -O0")
  ENDIF(CMAKE_COMPILER_IS_GNUCC)

  The attached zip contains:
mwe.py  // input script 
liteSpecimen2mm.spheres  // packing file
jointSurf.stl  // stl for smooth joint
coreDump2.txt  // core dump after executing mwe.py with optimized debug 
compiled yade

  Any assistance with this bug is greatly appreciated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1666339/+subscriptions

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp