Re: [Adun-users] Back to the GUI

At last with startup 0.20.1, I've been working fine using the command line.
The Analyzer in the GUI is not working (as I reported before).  I am not
able to run the tests

./RunTests.st
2012-03-07 17:32:53.088 AdunShell[23424] Executing ./RunTests.st
2012-03-07 17:32:53.124 AdunShell[23424] No valid build output dir found in
/home/cesar/adun/buildOutput
2012-03-07 17:32:53.124 AdunShell[23424] Writing build output to registered
default file at /home/cesar/adun/buildOutput
2012-03-07 17:32:53.160 AdunShell[23424] Register known languages...
2012-03-07 17:32:53.160 AdunShell[23424] Language paths
("/home/cesar/GNUstep/Library/StepTalk/Languages/Smalltalk.stlanguage")
Verbose output enabled

Test Suite: AmberFD
Testing Amber HarmonicBond Analytical Forces ... 2012-03-07 17:32:53.179
AdunShell[23424] Caught exception NSInvalidArgumentException
Reason NSTask - launch path (../Scripts/FD.st) not valid


2012/3/7 César Ávila <[EMAIL PROTECTED]>

> I also tried 0.25.0 with the same result. So, as you mentioned, perhaps it
> is related to the way I install GNUStep. On the linux box that I am
> testing, I am only able to install it on my home folder.
> I think we should create a table with all the known issues for the
> versions of GNUStep that we have tested.
>
>
> 2012/3/7 Michael Johnston <[EMAIL PROTECTED]>
>
>> Strange problem - it seems make can't find the FFML header.
>>
>> if you run with messages=yes you can see where it searching - and also
>> check that FFML.h got installed into the correct place
>>
>>  btw gnustep-make changed a good bit in terms of install paths etc
>> between those version - and also the system install locations for gnustep
>> changed (from everthing under /usr/GNUstep to be more fhs compatible e.g.
>> libraries under /usr/lib etc). You'll need to ensure you source the correct
>> GNUstep.sh file so the right make and library versions are found.
>>
>> On 7 March 2012 11:54, César Ávila <[EMAIL PROTECTED]> wrote:
>>
>>> Well, at least the latest stable version of GNUStep startup (0.26.2) is
>>> not able to compile Adun. Note that 0.20.1 is able to compile it. Moving on
>>> to test 0.25 (in 64 bits)
>>>
>>> Making all for app UL...
>>>  Creating UL.app/....
>>>  Compiling file ViewController.m ...
>>> In file included from ./ULFramework/ULSystemBuilder.h:33,
>>>                  from ULFramework/ULFramework.h:31,
>>>                  from ViewController.h:32,
>>>                  from ViewController.m:27:
>>> ./ULFramework/ULInteractionsBuilder.h:32:23: warning: FFML/FFML.h: No
>>> such file or directory
>>> In file included from ViewController.m:28:
>>> ULResponder.h:111:7: warning: no newline at end of file
>>> In file included from ./ULFramework/ULSystemBuilder.h:34,
>>>                  from ULFramework/ULFramework.h:32,
>>>                  from ViewController.h:33,
>>>                  from ViewController.m:28:
>>> ./ULFramework/ULInteractionsBuilder.h:50: error: expected
>>> specifier-qualifier-list before ‘FFParameterFileTree’
>>> ViewController.m: In function ‘-[ViewController awakeFromNib]’:
>>> ViewController.m:195: warning: unused variable ‘item’
>>> ViewController.m: At top level:
>>> ViewController.m:526: warning: ignoring #pragma mark
>>> ViewController.m:527: warning: ignoring #pragma mark Server
>>> ViewController.m:711: warning: ignoring #pragma mark
>>> ViewController.m:712: warning: ignoring #pragma mark Menu
>>> ViewController.m:951: warning: ignoring #pragma mark
>>> ViewController.m:1111: warning: ignoring #pragma mark
>>> ViewController.m:1112: warning: ignoring #pragma mark Transcript
>>> make[4]: *** [obj/UL.obj/ViewController.m.o] Error 1
>>> make[3]: *** [internal-app-run-compile-submake] Error 2
>>> make[2]: *** [UL.all.app.variables] Error 2
>>> make[1]: *** [internal-all] Error 2
>>> make: *** [internal-all] Error 2
>>>
>>>
>>> 2012/2/28 César Ávila <[EMAIL PROTECTED]>
>>>
>>>> Thanks. I will give them a try and report back
>>>>
>>>>
>>>>
>>>>
>>>> 2012/2/28 Michael Johnston <[EMAIL PROTECTED]>
>>>>
>>>>> I forgot that the tests can be used to check is everything working on
>>>>> 64bit
>>>>>
>>>>> cd Test
>>>>> ./RunTests
>>>>>
>>>>> If they pass its ok
>>>>>
>>>>> On 27 February 2012 15:56, Michael Johnston <
>>>>> [EMAIL PROTECTED]> wrote:
>>>>>
>>>>>> Just saw this mail which I'd forgotten about
>>>>>>
>>>>>> Firstly theoretically it should be possible to do what you say below
>>>>>> but I've never been able to do it (Previously I was talking about running
>>>>>> 32bit GUI in a 32 bit Linux on a 64 bit machine).
>>>>>>
>>>>>> However after looking through the code, it, amazingly, seems that it
>>>>>> dodges all the 64 bit transition bullets, completely by accident. There 
>>>>>> is
>>>>>> one place where there is a problem but I can't find anywhere that calls 
>>>>>> it,
>>>>>> so it should be okay (for some reason I bypassed this code with a 
>>>>>> different
>>>>>> implementation that avoids the problems but don't remember why or even
>>>>>> doing it).
>>>>>>
>>>>>> FYI The major potential problem was with encoding/decoding of
>>>>>> NSIndexSets used to store nonbonded interaction information across
>>>>>> architectures i.e. 32->64 and vice-versa
>>>>>>
>>>>>> Going back to your original question, the GUI from
>>>>>> gnustep-startup-0.25 works for me perfectly on 32-bit so I'd try that 
>>>>>> first
>>>>>> - 0.26 has some issues on Ubuntu at least. Just keep an eye out for any
>>>>>> strange behaviour that might indicate a problem. The only time you could
>>>>>> potentially encounter issues is when using a datasource built on a 32 bit
>>>>>> machine. btw If you can run 1 step of dynamics on the 64 bit machine, 
>>>>>> with
>>>>>> a datasource from a 32 bit machine, and get no seg-faults and the
>>>>>> same-energies this basically confirms everything is ok.
>>>>>>
>>>>>>
>>>>>> On 8 February 2012 19:05, César Ávila <[EMAIL PROTECTED]> wrote:
>>>>>>
>>>>>>> How do you compile a 32 bit version of the GUI in a 64 bit linux?
>>>>>>>
>>>>>>>
>>>>>>> 2012/2/8 Michael Johnston <[EMAIL PROTECTED]>
>>>>>>>
>>>>>>>> Unfortunately I don't have access to any 64bit OS to test if the
>>>>>>>> problem still exists (the program will work with a 32bit os on a 64 bit
>>>>>>>> machine btw)
>>>>>>>>
>>>>>>>> I will try to find exactly what parts of the code are affected by
>>>>>>>> the 32->64 transition and see how difficult it is to fix.
>>>>>>>>
>>>>>>>> On Tue, Feb 7, 2012 at 11:26 PM, César Ávila <[EMAIL PROTECTED]>wrote:
>>>>>>>>
>>>>>>>>> Two years ago, I reported on a "Strange Behaviour of the GUI" (you
>>>>>>>>> can
>>>>>>>>> search for this on the mailing list). The problem was followed up
>>>>>>>>> in the
>>>>>>>>> Bugs Tracker
>>>>>>>>>
>>>>>>>>> https://gna.org/bugs/?16267
>>>>>>>>>
>>>>>>>>> Basically, when you try to apply a plugin using the GUI, the
>>>>>>>>> analyse button
>>>>>>>>> is not active for the currently selected object (a simulation for
>>>>>>>>> instance).
>>>>>>>>> The problem was related to the use of gnustep-startup-0.20.1
>>>>>>>>>  (which
>>>>>>>>> uses gnustep-gui
>>>>>>>>> 0.14). On the other hand, using a newer startup back at that time,
>>>>>>>>> prevented me from using AdunCore.
>>>>>>>>> Has anyone tried a Gnustep version that works ok for both on 64 bit
>>>>>>>>> architectures?
>>>>>>>>>
>>>>>>>>> This message has been automatically forwarded to you by the Adun
>>>>>>>>> team http://adun.imim.es
>>>>>>>>> _______________________________________________
>>>>>>>>> Adun-users mailing list
>>>>>>>>> [EMAIL PROTECTED]
>>>>>>>>> https://mail.gna.org/listinfo/adun-users
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

This message has been automatically forwarded to you by the Adun team 
http://adun.imim.es
_______________________________________________
Adun-users mailing list
[EMAIL PROTECTED]
https://mail.gna.org/listinfo/adun-users