Re: [papyrus-rt-dev] Papyrus-RT Build Problems — Blocked

[Ernesto Posse <eposse@xxxxxxxxxxxxx>]

The last codegen build (#8) succeeded. I've no idea what could have happened in build #7.

On Wed, Apr 6, 2016 at 10:34 AM, Christian Damus <give.a.damus@xxxxxxxxx> wrote:

And, in fact, the root cause of the problem with the codegen test turned out to be that the Eclipse configuration in which the test was executed omitted the org.eclipse.papyrus.cpp.library bundle.

That is fixed by adding this bundle as a dependency of the test bundle (because, in fact, the test requires it) and restoring the ComputerSystem model to the test cases.  The test passes.

But, now the build is hanging in the post-build script that generates the ComputerSystem (again) and runs it.  It looks like it’s hanging at the step of installing various features into the Eclipse configuration.  This all worked in a previous build.

Christian

On 6 April, 2016 at 09:23:16, Christian Damus (give.a.damus@xxxxxxxxx) wrote:

Hi, Ernesto, Céline,

It seems the 14th edition of the gerrit patch 69349 was charmed.  It now finally has its +1 verification from Hudson!  High fives all around.

I think this should now unblock merge of this patch into the Neon branch and all of the other work that’s been waiting for it.  Sorry for the delay.

(note that this patch doesn’t merge in the Gerrit UI, but it will once the neon branch is fast-forwarded to master, which I cannot do)

cW

On 6 April, 2016 at 08:19:48, Christian Damus (give.a.damus@xxxxxxxxx) wrote:

Well, I do feel silly.  All the logging that we need is already there; I just wasn’t looking in the right place in the build logs.

There appears to be confusion in the generated code between pointer types (see below, the lines starting with “>>").  Could it be that these are due to changes in the C++ Codegen Profile from the Papyrus Extras?  But that’s just a guess.  Perhaps Ansgar can shed some light on it.

So, for now, we’re stuck again.

cW

Running org.eclipse.papyrusrt.codegen.cpp.test.codecompare.CodeGenCompareTest
Testing PingPong.uml

Comparing PingPongProtocol.hh
Comparing Top-connections.log
Comparing PingPongProtocol.cc
Comparing TopControllers.hh
Comparing TopMain.cc
Comparing TopControllers.cc
Comparing MakefileTop.mk
Comparing Makefile
Comparing Top.hh
Comparing Pinger.hh
Comparing Pinger.cc
Comparing Ponger.hh
Comparing Top.cc
Comparing Ponger.cc
Testing ComputerSystem.uml
Comparing ComputerSystem.cc
Comparing Top-connections.log
Comparing ResourceType.cc
Comparing USBDeviceClasses.hh
Comparing AppType.cc
Comparing USBPrinterDriver.cc
Comparing Application.hh
Comparing LocalPrinter.cc
>> #define umlrtparam_data ( *(const void * *)msg->getParam( 0 ) ) :: #define umlrtparam_data ( *(const void * * *)msg->getParam( 0 ) )
Comparing ResourceManager.cc
Comparing AppControl.hh
>> UMLRTOutSignal docID( int docID ) const; :: UMLRTOutSignal docID( void * docID ) const;
Comparing ComputerSystem.hh
>> bool initStatus; :: void * initStatus;
Comparing Resource.hh
Comparing TopControllers.hh
Comparing Computer.hh
Comparing User.cc
Comparing ResourceManager.hh
>> int printerRequestCount; :: void * printerRequestCount;
Comparing USBDeviceClasses.cc
Comparing ResourceType.hh
Comparing AppControl.cc
>> char * fileName; :: void * * fileName;
Comparing USBDeviceDriver.cc
Comparing TopMain.cc
Comparing TopControllers.cc
Comparing OSCommand.cc
Comparing MakefileTop.mk
Comparing USBProtocol.cc
>> sizeof( void * ), :: sizeof( void * * ),
Comparing USBPrinterDriver.hh
Comparing WordProcessorApp.hh
>> char * document; :: void * * document;
Comparing Makefile
Comparing USBStorageDriver.cc
Comparing Top.hh
Comparing USBProtocol.hh
>> UMLRTOutSignal data( void * data ) const; :: UMLRTOutSignal data( void * * data ) const;
Comparing LocalPrinter.hh
>> bool connectionStatus; :: void * connectionStatus;
Comparing User.hh
>> int numSec; :: void * numSec;
Comparing Computer.cc
Comparing AppType.hh
Comparing OSCommand.hh
Comparing USBErrorCodes.hh
Comparing USBErrorCodes.cc
Comparing Top.cc
Comparing Application.cc
Comparing USBDeviceDriver.hh
>> int busID; :: void * busID;
Comparing ExtMassStorage.hh
>> bool connectionStatus; :: void * connectionStatus;
Comparing WordProcessorApp.cc
>> #define umlrtparam_percent ( *(int *)msg->getParam( 0 ) ) :: #define umlrtparam_percent ( *(const void * *)msg->getParam( 0 ) )
Comparing USBStorageDriver.hh
Comparing Resource.cc
Comparing ExtMassStorage.cc
>> #define umlrtparam_data ( *(const void * *)msg->getParam( 0 ) ) :: #define umlrtparam_data ( *(const void * * *)msg->getParam( 0 ) )

On 6 April, 2016 at 08:10:14, Christian Damus (give.a.damus@xxxxxxxxx) wrote:

Thanks, Ernesto,

I’ll see whether I can’t add some logging of comparison failures in the test.  Shouldn’t be difficult.

Did you also select the top-level Papyrus project for import?  You need that at a minimum, and you don’t need the Infra/Views/UML in your workspace because they will be in the PDE Target.  But, codegen does need stuff from the Papyrus Extras, namely the C++ Codegen feature.  So try importing also that project from the Oomph setup.  IIRC, it’s not actually completely self-contained, so you will additionally need to pull in some more from the Papyrus git repo (C++ profile, I think, and probably some base Qompass bundles).

Also, of course, you’ll need the latest Xtext SDK for Xbase and other bits.

I’m working on an Oomph setup model for developers for Mars and Neon in Gerrit 68693 but that can’t actually be completed until we have Neon builds of Papyrus-RT published, because the setup needs to be able to install those.

HTH,

Christian

On 5 April, 2016 at 17:30:14, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:

Hmmm... Strange that your manual generation won't match the automated one.

Unfortunately there is no simple way to determine the diffs, as far as I know. This test is in 'org.eclipse.papyrusrt.codegen.cpp.test' (under tests/junit/umlrt/codegen) in 'codecompare.CodeGenCompareTest'. Young-Soo wrote this, and looking at the source, it only reports file names. I think the only option is a manual diff.

Maybe using the Eclipse-based generator will produce the correct expected sources.

Alternatively, we could temporarily comment-out lines 43-45 in CodeGenCompareTest.java, which would disable the tests. 

I can try to help figuring this out, but I'm having trouble with my Neon setup. I get a lot of errors on the tooling projects. So I started with a fresh installation and the Papyrus Oomph setup, but after importing the Infra, Views and UML components I get errors in most projects. Is there a component that I need to select in Oomph to install besides Infra, Views or UML?

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

--

Ernesto Posse

Zeligsoft.com