Re: [Adun-users] Back to the GUI

I remember now - this is the one problem with 0.26.2 that made me revert to
0.25.0
I need to file a bug with gnustep on this

I think the table is a good idea - I tried to document some issues with
various versions already on the website

On 7 March 2012 14:51, César Ávila <[EMAIL PROTECTED]> wrote:

> Now with a fresh installation of GNUStep startup 0.26.2 (installed as
> root). I got
> ./RunTests.st
> 2012-03-07 15:30:49.896 AdunShell[6202] Executing ./RunTests.st
> 2012-03-07 15:30:49.966 AdunShell[6202] Register known languages...
> 2012-03-07 15:30:49.966 AdunShell[6202] Language paths
> ("/home/cesar/GNUstep/Library/StepTalk/Languages/Smalltalk.stlanguage")
> 2012-03-07 15:30:49.976 AdunShell[6202] Caught exception
> NSInvalidArgumentException
> Reason +[STSmalltalkScriptObject _unnamed_method]: unrecognized selector
> sent to instance 0x7f6deacdc920
>
> So AdunShell is not working. On the other hand, the GUI seems to be
> working properly, at least the plugins.
>
> 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