[Yade-dev] buildbot warnings in Yade on yade-full

2019-02-25 Thread buildbot
The Buildbot has detected a problem in the build on builder yade-full while 
building Yade.
Full details are available at:
 https://yade-dem.org/buildbot/builders/yade-full/builds/4983

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

Buildslave for this Build: r0calcul9

Build Reason: The Nightly scheduler named 'nightly' triggered this build
Build Source Stamp: HEAD
Blamelist: 

Build Had Warnings: warnings test test_1

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


[Yade-dev] buildbot warnings in Yade on yade-full

2019-02-25 Thread buildbot
The Buildbot has detected a problem in the build on builder yade-full while 
building Yade.
Full details are available at:
 https://yade-dem.org/buildbot/builders/yade-full/builds/4982

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

Buildslave for this Build: r0calcul9

Build Reason: The Nightly scheduler named 'nightly' triggered this build
Build Source Stamp: HEAD
Blamelist: 

Build Had Warnings: warnings test test_1

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


Re: [Yade-dev] [Bug 1810283] Re: Wiki homepage broken

2019-02-25 Thread Janek Kozicki
ops, it doesn't work again :/

Bruno Chareyre said: (by the date of Fri, 22 Feb 2019 16:38:04 +0100)

> On 2/22/19 4:14 PM, Jan Stránský wrote:
> > just a note concerning wiki, I know (but have no experience with them) 
> > that gitlab offers wiki pages. Maybe it would be worth moving also 
> > wiki within the gitlab migration..  
> 
> Yes, it was mentioned in earlier messages and it is an option.
> If someone wants to try and migrate current content to gitlab.com that's 
> fine.
> 
> However if we keep running a dedicated server in 3SR anyway (because 
> there is not just the wiki to host) there is less need for such a migration.
> Gitlab migration reduces the dependency on 3SR hardware significantly, 
> keeping just that server with wiki and other things on it is doable.

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


Re: [Yade-dev] YADE_REQUIRE_FEATURE and Linking.

2019-02-25 Thread Bruno Chareyre

Hi Janek,

On 2/15/19 7:06 PM, Janek Kozicki wrote:

   ./scripts/linkdeps.py:  
m=re.match('^YADE_REQUIRE_FEATURE\((.*)\).*',l)

which means that the only mention of YADE_REQUIRE_FEATURE is in
documentation, and that Chia Weng Boon tried to use it in
PotentialBlocks code, but it is commented out.

So should we remove this section? But why is it present in 
./scripts/linkdeps.py ?


It could be that the mechanism is functional but not effectively used. 
Not sure. Worth a try before removing.


You should get an idea of the the mechanism effectively used at the 
moment just reading CMakeLists.txt.
On this basis cmake will define c++ preprocessor macros which can be 
used for #ifdef's.



The next section about Linking is also incorrect, because when I do this command

   find -name "*.so" -exec basename {} \; | sort | uniq

in the build tree, I obtain:

_GLViewer.so
_customConverters.so
_packObb.so
_packPredicates.so
_packSpheres.so
_polyhedra_utils.so
_utils.so
boot.so
libyade.so
wrapper.so

which is different from what is described in 
https://yade-dev.gitlab.io/trunk/prog.html#linking
The above libs correspond to python modules which can be imported in 
python scripts, they are not loaded at runtime (well, utils is loaded at 
runtime but that's because the startup script has some "import utils" 
inside).
We oscillated between monolithic build and independent plugins a couple 
time if I remember well. We are more on the monolithic side at the moment.
Why the split is as it is now is not something I can justify fully, I 
would have to check case by case.
I suspect in some cases - e.g. polyhedra - it's just because the 
developper liked it this way.
I know utils is high demanding in terms of RAM so utils+libyade in one 
single lib would probably increase the memory requirement for compiling 
yade.



What should we do with this?
I think developer manual could assume monolithic build and so there is 
no real need for a "linking" section.
The possibility of adding independent python modules with boost::python 
could be mentioned, with an example selected in the above.



PS: I am not sure where I should post these concerns:

* https://gitlab.com/yade-dev/trunk/merge_requests/69
* https://gitlab.com/yade-dev/trunk/issues
* here, on yade-dev


Too many communication channels are not good. One has too monitor them all.


For me it doesn't make a real difference since I'm receiving them all, 
but I'm "owner" of the gitlab group, I don't know what happens for others.


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