- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Crashes on snapshot with the new compactor

by Eliot Miranda

Hi All, I have fixed a bug in the compactor that accounts for the two cases I've analysed and the two fairly repeatable crashes I have at hand (three cases in all). I hope that all those who have been experiencing crashes can start using the latest build asap. It is fixed in these commits: Name: VMMaker.oscog-eem.2187 Author: eem Time: 27 March 2017, 3:00:06.676146 pm UUID: 2259d299-65a4-42d0-a01b-4b25f5a89745 Ancestors: VMMaker.oscog-rsf.2186 SpurPlanningCompactor: Fix a big in resetting the free chunk used for the firstUnusedFieldsSpace after non-final pasxses (i.e. on snapshot). The old code didn't check to see if a free chunk was actually found(!!). and Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 4ceff23323bcd0f2d3d0a4a43c2995f43d09c98a https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/4ceff23323bcd0f2d3… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2017-03-27 (Mon, 27 Mar 2017) The bintray files are here: https://bintray.com/opensmalltalk/vm/cog/201703272314 _,,,^..^,,,_ (phone) > On Mar 25, 2017, at 1:27 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi All, > > a number of people are being affected by crashes on snapshotting the image, the worst possible time for a crash. There is a bug in the new compactor that unfortunately bites when saving. The compactor is invoked as part of a full garbage collect after the garbage collector has feed unreachable objects. Normally the new compactor makes only a single pass through the heap, which may not move all the objects that are possible to move. (The amount of objects that can be moved in a single pass is limited by available free space.) But on snapshot the compactor makes as may passes as are necessary to slide all movable objects down as far as possible. Unfortunately there is a bug in this second pass. > > Fixing this bug is now my priority. I have an example image from Esteban Lorenzano to test. I am asking anyone else that can provide an image that reliably crashes when trying to save it to make the image and changes available to me for testing if possible. > > In the mean time one may be able to work around the problem by doing a full garbage collect before snapshot. This should do a GC with a single compaction pass which should not fail, and then make it much more likely that the GC during snapshot will do a single compaction pass, since fewer objects should be mobile after the single pass compaction in the explicit GC. > > To do this in Pharo I would put a full gc here: > > SessionManager>>snapshot: save andQuit: quit > | isImageStarting snapshotResult | > ChangesLog default logSnapshot: save andQuit: quit. > > >> SmalltalkImage current primitiveGarbageCollect. > > self currentSession stop: quit. "Image not usable from here until the session is restarted!" > ... > > In Squeak I would put a full GC here: > > snapshot: save andQuit: quit withExitCode: exitCode embedded: embeddedFlag > "Mark the changes file and close all files as part of #processShutdownList. > If save is true, save the current state of this Smalltalk in the image file. > If quit is true, then exit to the outer OS shell. > If exitCode is not nil, then use it as exit code. > The latter part of this method runs when resuming a previously saved image. This resume logic checks for a document file to process when starting up." > > | resuming msg | > Object flushDependents. > Object flushEvents. > > ... > Smalltalk processShutDownList: quit. > >> SmalltalkImage current primitiveGarbageCollect. > Cursor write show. > save ifTrue: [resuming := embeddedFlag > ifTrue: [self snapshotEmbeddedPrimitive] > ifFalse: [self snapshotPrimitive]] "<-- PC frozen here on image file" > ifFalse: [resuming := false]. > > I do apologise for the bug. I hope it will be fixed within a few days. > > _,,,^..^,,,_ > best, Eliot

March 28, 2017

Re: [Pharo-dev] about smacc gt extensions

by Stephane Ducasse

Tx doru Yes this is the correct analysis. On Mon, Mar 27, 2017 at 9:43 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I committed a fix upstream. It will appear in the image with the next GT > integration. > > Doru > > > > On Mar 27, 2017, at 9:36 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > Hi Stef, > > > > Indeed, the Raw view should only show the basic structure of the object. > > > > But, the problem seems different in the screenshot you attached. You > have an OrderedCollection of Tokens, and selecting one, gets the value of > out it. This is an issue with the extension of SequenceableCollection and > it affects also other objects that understand value, such as blocks. > > > > I opened an issue: > > https://pharo.fogbugz.com/f/cases/19867/GTInspector- > extensions-for-items-of-a-SequenceableCollection-sends-an-extra-value > > > > Cheers, > > Doru > > > > > >> On Mar 26, 2017, at 9:54 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >> > >> hi andrei and doru > >> > >> I think that we should improve the gt extension of smacc. Right now > when I have a token I do not see it when inspecting it in raw. > >> > >> The raw view should always show the object implementation. > >> After we can have other view. Now with the token this is super strange > to get a string (or the result of value). because when you are exploring a > tree > >> you want to know if this is a string or a token. > >> > >> As in the following attachment: the current situation is confusing. > >> in the list I have a list of token and when I look at one, I get a > string. > >> > >> Stef > >> > >> <Screen Shot 2017-03-26 at 21.51.05.png> > >> > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "One cannot do more than one can do." > > > > > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "Problem solving efficiency grows with the abstractness level of problem > understanding." > > > > > >

March 27, 2017

Smalltalk jobs in Germany

by Stephane Ducasse

Hi guys Tomcat is looking for Smalltalkers in Germany. Contact them not me :) richard.v-lavante(a)tomcat.de christian.mann(a)tomcat.de Stef Actually now we are still looking for more Smalltalker again. Therefore today I turn to You and want to ask, it You know anybody, who has at least 2-3 Y. ST-experience (no matter which system) and wants to work for longer time in Germany, beginning in next 4-10 weeks. I thank You for Your help in advance and look forward to interesting news from You. Have a nice week! Viele GrÃ¼Ãe Best Regards Pozdravy Richard v. Lavante *Tomcat**Â®** GmbH **ITÂ·ConsultingÂ·Management* *Tomcat*Â® GmbH Flughafen Oberpfaffenhofen Friedrichshafener Str. 1 82205 Gilching Tel. +49-(0)8105-771801-0 Fax. +49-(0)89-849544 Mobil: +49-(0)172-9778982 Mail: richard.v-lavante(a)tomcat.de www.tomcat.de GeschÃ¤ftsfÃ¼hrer: Dipl.-Ing.(univ.) Richard von Lavante Firmensitz: D-82205 Gilching Register: MÃ¼nchen HRB 85435 *Tomcat*Â® ist eingetragenes Warenzeichen der *Tomcat*Â® GmbH

March 27, 2017

Re: [Pharo-dev] about smacc gt extensions

by Tudor Girba

I committed a fix upstream. It will appear in the image with the next GT integration. Doru > On Mar 27, 2017, at 9:36 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi Stef, > > Indeed, the Raw view should only show the basic structure of the object. > > But, the problem seems different in the screenshot you attached. You have an OrderedCollection of Tokens, and selecting one, gets the value of out it. This is an issue with the extension of SequenceableCollection and it affects also other objects that understand value, such as blocks. > > I opened an issue: > https://pharo.fogbugz.com/f/cases/19867/GTInspector-extensions-for-items-of… > > Cheers, > Doru > > >> On Mar 26, 2017, at 9:54 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> hi andrei and doru >> >> I think that we should improve the gt extension of smacc. Right now when I have a token I do not see it when inspecting it in raw. >> >> The raw view should always show the object implementation. >> After we can have other view. Now with the token this is super strange to get a string (or the result of value). because when you are exploring a tree >> you want to know if this is a string or a token. >> >> As in the following attachment: the current situation is confusing. >> in the list I have a list of token and when I look at one, I get a string. >> >> Stef >> >> <Screen Shot 2017-03-26 at 21.51.05.png> >> > > -- > www.tudorgirba.com > www.feenk.com > > "One cannot do more than one can do." > > > > -- www.tudorgirba.com www.feenk.com "Problem solving efficiency grows with the abstractness level of problem understanding."

March 27, 2017

Re: [Pharo-dev] Pharo Papers

by denker

They are in now. > On 24 Mar 2017, at 15:03, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > With Nick, we try to add the PHARO tag on some on our publications but > apparently he does appear in the list. Is it updated from time to time > ? > > Regards, > > On Thu, Feb 23, 2017 at 10:57 AM, denker <marcus.denker(a)inria.fr> wrote: >> Hello, >> >> I have setup a collection at HAL. For now it is empty, we should fill it and then add it to the website >> (and announce it then, not nowâ¦). >> >> The collection automatically has every paper on HAL that has âPHAROâ as a keyword in the field >> "Project/Collaborationâ. >> >> https://hal.inria.fr/PHARO/ >> https://hal.archives-ouvertes.fr/PHARO >> >> HAL is not Inria specific, here is some more infos (from https://hal.archives-ouvertes.fr ): >> >> HAL is an open archive where authors can deposit scholarly documents from all academic fields. >> >> For the attention of the authors >> >> â¢ The deposit must be made in agreement with the co-authors and in the respect for the policy of the publishers. >> â¢ The deposit is subject of a control, HAL reserves the right to refuse items that do not meet the criteria of the archive. >> â¢ Any deposit is definitive, no withdrawals will be made after the on-line posting of the publication. >> â¢ Text files in pdf format or image files are sent to CINES (https://www.cines.fr/en/) for long-term archiving. >> >> For the attention of the readers >> >> â¢ In a context of electronic distribution, every author keep all its intellectual property rights. >> >> >> >> >>> On 16 Feb 2017, at 15:13, denker <marcus.denker(a)inria.fr> wrote: >>> >>> One idea on my TODO that I got from colleagues here working on another OpenSource/Research >>> system (Sofa3D): to add all publication to the website automatically using HAL (the national french >>> paper database). >>> >>> It looks like this on the website: >>> https://www.sofa-framework.org/applications/publications/ >>> >>> and here âhow to add a paperâ: >>> >>> https://www.sofa-framework.org/applications/publications/add-a-publication-… >>> >>> I will definitely set this up for Pharo later this year (read: as soon as possible) >>> >>> Marcus >>> >>> >>>> On 16 Feb 2017, at 14:30, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>> And now for your regularly scheduled random trivia show... >>>> I was mildly curious about how many papers touched on Pharo. >>>> >>>> 1,110 on google scholar for... >>>> "pharo" "programming" >>>> http://tiny.cc/pharo-scholar >>>> >>>> 1,630 on normal google for... >>>> "pharo" "programming" "abstract" "introduction" "conclusion" >>>> "references" filetype:pdf >>>> http://tiny.cc/pharo-papers >>>> >>>> Probably a lot of overlap between them. >>>> cheers -ben >>>> >>> >> >> > > > > -- > Serge Stinckwich > UCN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ >

March 27, 2017

Re: [Pharo-dev] about smacc gt extensions

by Tudor Girba

Hi Stef, Indeed, the Raw view should only show the basic structure of the object. But, the problem seems different in the screenshot you attached. You have an OrderedCollection of Tokens, and selecting one, gets the value of out it. This is an issue with the extension of SequenceableCollection and it affects also other objects that understand value, such as blocks. I opened an issue: https://pharo.fogbugz.com/f/cases/19867/GTInspector-extensions-for-items-of… Cheers, Doru > On Mar 26, 2017, at 9:54 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > hi andrei and doru > > I think that we should improve the gt extension of smacc. Right now when I have a token I do not see it when inspecting it in raw. > > The raw view should always show the object implementation. > After we can have other view. Now with the token this is super strange to get a string (or the result of value). because when you are exploring a tree > you want to know if this is a string or a token. > > As in the following attachment: the current situation is confusing. > in the list I have a list of token and when I look at one, I get a string. > > Stef > > <Screen Shot 2017-03-26 at 21.51.05.png> > -- www.tudorgirba.com www.feenk.com "One cannot do more than one can do."

March 27, 2017

Esteban's ChangeLog week of 20 March 2017

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 20 March 2017 to 26 March 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=20/3/2017&to=26/3/2017 ChangeLog ========= 23 March 2017: -------------- * Fixed (again!) build process for linux (libssh2 version was not correct). 22 March 2017: -------------- * I made another pass to some problems on *icebeg>* : added a new "branch browser" to compare sources from remote branchs and added a couple of fixes to make the system a bit stronger... still working on this :) * I spent some time again on VM building, where a couple of issues arised: === Build windows VM with cygwin instead mingw [Nico Cellier](https://github.com/nicolas-cellier-aka-nice) moved the [OSVM](https://github.com/OpenSmalltalk/opensmalltalk-vm) to cygwin as part of his effort to produce Win64 VMs (and to align PharoVM with the other VMs flavours built). This was a cool work, but it requires some work for our side to properly build the [PharoVM](https://github.com/pharo-project/pharo-vm). === Fix a problem with SDL2 and linux SDL2 version was upgraded, but there was a remaining problem when building it, so I needed to track down the problem and fix it. Overall, the process are ok now... nevertheless I cannot merge the changes to make them available for users because with latest VM sources there are some problems here and there (not all tests pass). So I'm waiting for Eliot :) 20 March 2017: -------------- * I added edit of repositories to [Iceberg](https://github.com/npasserini/iceberg) :) This is usefull when you make a mistake and do not locate sources properly when cloning or when you want to re-locate repository after moving it in your disk. cheers! Esteban

March 27, 2017

about smacc gt extensions

by Stephane Ducasse

hi andrei and doru I think that we should improve the gt extension of smacc. Right now when I have a token I do not see it when inspecting it in raw. The raw view should always show the object implementation. After we can have other view. Now with the token this is super strange to get a string (or the result of value). because when you are exploring a tree you want to know if this is a string or a token. As in the following attachment: the current situation is confusing. in the list I have a list of token and when I look at one, I get a string. Stef [image: Inline image 1]

March 26, 2017

Re: [Pharo-dev] about push up and pull up

by Stephane Ducasse

Tx John for the historical perspective.I see. I would like to have a uniform naming: "move method up :)" We will revisit everything with Calypso. And fix some problems: In Pharo we broke the precondition that pulling up a method should only work if the state it accessed is already in the destination. We want also to have a layer (refactoring not accessing UI element) and a layer on top to manage interaction with the user. Right now this is mixed up. We should be able to invoke refactorings without UI. Stef On Sun, Mar 26, 2017 at 12:08 AM, John Brant <brant(a)refactoryworkers.com> wrote: > > On Mar 25, 2017, at 2:27 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > > > Hi guys > > > > I wonder why we have push up method and pull up instance variables. > > I remember that long time ago we got a discussion but I forgot. > > Do you remember? > > > > Stef (writing chapters for new books for total newbies: yes the future > pharoers) > > In the original RefactoringBrowser, if you wanted to move an instance > variable up in the hierarchy, you would select the superclass and perform > pull up instance variable. It would then open a dialog where you chose what > subclass instance variable you wanted to pull up. Since we were at the > superclass in the browser instead of the instance variable, I chose pull up > instance variable for the name. At that time, we hadnât implemented context > selection menu options for the class definition, so we didnât have a way to > select an instance variable in the browser without opening a dialog. > > Later, I implemented push up method. In this case, the browser already > supported selecting methods, so it didnât make sense to have the user move > to the superclass, perform pull up method, and then select the method you > want to pull up from a dialog. > > Essentially, the push vs. pull naming was based on where you were in the > browser. If the thing to move wasnât where you were in the browser, then > pull was used â you would reach over to the other place and pull it to you. > However, if the thing was currently where you were in the browser, then you > would push it to the new location. > > Of course, the current browser doesnât follow my push vs. pull naming > convention. When you pull up an instance variable, you need to have the > class that defines the variable selected. > > > John Brant >

March 26, 2017

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0

by Ben Coman

On Sat, Mar 25, 2017 at 8:12 AM, Ben Coman <btc(a)openinworld.com> wrote: > On Sat, Mar 25, 2017 at 5:17 AM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> >> 2017-03-24 17:23 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >>> >>> On Fri, Mar 24, 2017 at 9:30 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >>> wrote: >>> > >>> > 2017-03-24 11:29 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>> >> >>> >> >>> >> VM 64bits >>> >> ========= >>> >> - Is incredibly hard to compile a 64bits version of libgit2 0.23 (the >>> >> one we are using) for macOS, which makes >>> >> impossible to use Iceberg. Not sure this is blocking, but well... I >>> >> needed to point it :) >>> > >>> > Hi Esteban, >>> > Doesn't the Travis build correctly succeed? >>> > https://bintray.com/opensmalltalk/vm/cog/201703222227#files >>> > >>> > yes, but the PharoVM for mac in 64bits is not including libgit2 (because >>> > I was unable to compile it) :P >>> > if you (or anyone) find the time and helps me doing that, I will be >>> > very, very, very grateful (and release will be earlier ;) >>> >>> Do you mean build libgit2 standalone? or as part of pharo-vm build? >>> >>> I dug out my old mac-mini to try. Its an older OSX Version 10.9.5. I >>> could upgrade to try if needed. >>> I don't know about the rpath warning. I ignored it. >>> >>> Standalone... >>> >>> 502 mkdir LIBGIT >>> 503 cd LIBGIT/ >>> 504 git clone https://github.com/libgit2/libgit2.git >>> 505 cd libgit2 >>> 521 git checkout v0.23.0 >>> 522 mkdir ../build && cd ../build >>> 525 cmake ../libgit2 >>> -- Configuring done >>> CMake Warning (dev): >>> Policy CMP0042 is not set: MACOSX_RPATH is enabled by default. Run >>> "cmake >>> --help-policy CMP0042" for policy details. Use the cmake_policy command >>> to >>> set the policy and suppress this warning. >>> MACOSX_RPATH is not specified for the following targets: >>> git2 >>> >>> 526 cmake --build . >>> 528 file libgit2.0.23.0.dylib >>> libgit2.0.23.4.dylib: Mach-O 64-bit dynamically linked shared library >>> x86_64 >>> >>> 529 cmake --version >>> cmake version 3.0.0 >>> >>> 530 uname -a >>> Darwin bens-mac-mini.home.gateway 13.4.0 Darwin Kernel Version 13.4.0: >>> Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 >>> x86_64 >>> >> >> Same for me here on OSX 10.11.6 El Capitan, >> libgit2 builds out of the box, same warning for RPATH >> Maybe we could reactivate on travis? > > Is this relevant regarding using ssh with using libgit ? > https://github.com/libgit2/libgit2/issues/2665 I'm having trouble with my mac-mini with extended pauses between shell commands so I've not been able to test whether this is relevant, but doing... $ cd ~/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/build.macos64x64/pharo.cog.spur $ ./mvm I see==> tar x -f ../../.thirdparty-cache/libgit2-v0.23.0.tar.gz -C builddbg/third-party cd builddbg/third-party/libgit2-0.23.0 \ && cmake \ -DCMAKE_INSTALL_PREFIX=/Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64 \ -DUSE_SSH=ON \ -DCURL=ON \ -DBUILD_CLAR=OFF \ -DOPENSSL_FOUND=ON \ -DLIBSSH2_FOUND=ON \ -DLIBSSH2_INCLUDE_DIRS=/Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64/include \ -DLIBSSH2_LIBRARIES=/Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64/lib/libssh2.1.dylib \ -DCMAKE_C_FLAGS="-L/usr/lib -L/Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64/lib -lssl -lcrypto -liconv" \ -DCMAKE_OSX_ARCHITECTURES=x86_64 \ -DCMAKE_SHARED_LINKER_FLAGS=-Wl,-rpath,@executable_path:@executable_path/Plugins \ && make \ && make install -- The C compiler identification is AppleClang 6.0.0.6000056 ... -- checking for module 'libssh2' -- package 'libssh2' not found -- Looking for libssh2_userauth_publickey_frommemory in /Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64/lib/libssh2.1.dylib -- Looking for libssh2_userauth_publickey_frommemory in /Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64/lib/libssh2.1.dylib - found ---------------- Trying again on its own in a clean dir... 533 cd ~/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/build.macos64x64/pharo.cog.spur/builddbg/third-party 534 rm -r libgit2-0.23.0 535 tar x -f ../../../../.thirdparty-cache/libgit2-v0.23.0.tar.gz -C . 536 cd libgit2-0.23.0/ 537 cmake ....same...params...as...above I get the same error, -- package 'libssh2' not found but if I up-arrow to run `cmake` again, that message doesn't appear. Maybe its caching the result from the next line from the -- Looking for libssh2_userauth_publickey_frommemory in /Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64/lib/libssh2.1.dylib - found So does that mean SSH ended up found and cmake cached the result? $ make ==> Linking C shared library libgit2.dylib [100%] Built target git2 $ otool -L libgit2.dylib ==> /Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/build.macos64x64/pharo.cog.spur/builddbg/third-party/libgit2-0.23.0/libgit2.23.dylib (compatibility version 23.0.0, current version 0.23.0) /usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 55471.14.16) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.17.0) /Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64/lib/libssh2.1.dylib (compatibility version 2.0.0, current version 2.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) So does that look like libgit is set up to use ssh okay? ------ btw, I found a related topic... http://stackoverflow.com/questions/32744681/libgit2-and-libssh2-cmake-packa… and here is the quick reference diff... https://www.diffchecker.com/SOGHWKRC So I notice among other things that changes LIBSSH2_INCLUDE_DIRS to LIBSSH2_INCLUDE_DIR, and our build uses -DLIBSSH2_INCLUDE_DIRS thats all I got for now. cheers -ben

March 26, 2017