[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [4diac-dev] InterfaceSpecBuilder
|
Hi,
Jenkins is back and it looks like you used tabs in your code. For 4diac FORTE we still have the policy of replace tabs with spaces and our CI build is checking
for that.
Cheers,
Alois
On Tue, 2022-05-24 at 21:56 +0200, Davor Cihlar wrote:
> Hi again!
> The feature is finally pushed.
> I can confirm that pushing to %topic= works, all commits are in the same topic.
> But I'm not sure that everything else is correct. It looks like Gerrit is still handling the commits independently. And for some reason there is a build
> failure, even for the first and relatively simple commit. I've tested all commits so I'm not expecting any build errors.
>
> On 5/18/22 19:01, Martin Melik-Merkumians wrote:
>
> >
> > I guess yes. I personally use topics, but with the git review module available at Python pip
> >
> > --------------------------------------------------
> > Dipl.-Ing. Martin Melik-Merkumians
> > Advanced Mechatronic Systems
> > Automation and Control Institute (ACIN)
> > TU Wien
> > DVR-Number: 0005886
> >
> > Gusshausstr. 27-29, room CD-04-24
> > 1040 Vienna, Austria
> > Phone: +43 (0)1 588 01 37688
> > Fax: +43 (0)1 588 01 937688
> > Email: melik-merkumians@xxxxxxxxxxxxxxxxx
> > http://www.acin.tuwien.ac.at/
> > --------------------------------------------------
> >
> > Von: 4diac-dev <4diac-dev-bounces@xxxxxxxxxxx> Im Auftrag von Davor Cihlar
> > Gesendet: Mittwoch, 18. Mai 2022 18:55
> > An: 4diac-dev@xxxxxxxxxxx
> > Betreff: Re: [4diac-dev] InterfaceSpecBuilder
> >
> > I wasn't familiar with the topic concept so I found this: https://gerrit-review.googlesource.com/Documentation/intro-user.html#topics
> > If I'm understanding that correctly, I should make my changes as usual and then push them all to a ref like for/develop%topic=ifspecbuilder?
> >
> >
> > On 5/18/22 18:45, Martin Melik-Merkumians wrote:
> >
> > > Hi,
> > >
> > > as far as I understood Gerrit, you can spilt that in several commits, but you need to provide a common topic for all commits to be than submitted at once.
> > >
> > > Best regards,
> > > Martin
> > >
> > > --------------------------------------------------
> > > Dipl.-Ing. Martin Melik-Merkumians
> > > Advanced Mechatronic Systems
> > > Automation and Control Institute (ACIN)
> > > TU Wien
> > > DVR-Number: 0005886
> > >
> > > Gusshausstr. 27-29, room CD-04-24
> > > 1040 Vienna, Austria
> > > Phone: +43 (0)1 588 01 37688
> > > Fax: +43 (0)1 588 01 937688
> > > Email: melik-merkumians@xxxxxxxxxxxxxxxxx
> > > http://www.acin.tuwien.ac.at/
> > > --------------------------------------------------
> > >
> > > Von: 4diac-dev <4diac-dev-bounces@xxxxxxxxxxx> Im Auftrag von Davor Cihlar
> > > Gesendet: Mittwoch, 18. Mai 2022 18:43
> > > An: 4diac-dev@xxxxxxxxxxx
> > > Betreff: Re: [4diac-dev] InterfaceSpecBuilder
> > >
> > > Hi!
> > > I started on improving and adapting the ifSpecBuilder for FORTE core. (Today I figured out unit testing and wrote tests for the storage class.) My idea
> > > was to do adaptation in a few phases which would be organized in corresponding commits. Is that even possible to do with Gerrit? Can I contribute multiple
> > > commits at once for one issue? If so, are there any special considerations for the commit message? Or should I squash the commits?
> > >
> > > On 5/17/22 12:52, Alois Zoitl wrote:
> > >
> > > > hi,
> > > >
> > > > I was never happy with the itnerfaceSpec parsing. It got a bit better with some helper methods we introduced but never really good. I find your approach
> > > > very
> > > > nice and would be happy if you would like to contribute it to 4diac FORTE.
> > > >
> > > > Cheers,
> > > > Alois
> > > >
> > > > On Mon, 2022-05-16 at 19:08 +0200, Davor Cihlar wrote:
> > > >
> > > > > Hi!
> > > > > For iterating access to PostgreSQL result with multiple rows I went with a generic SIFBs (CGenFunctionBlock<CFunctionBlock>). I need some additional
> > > > > events
> > > > > and outputs and it doesn't make sense to do that through a comm layer.
> > > > > So I started writing my own GEN_PQ_ITER and everything was fine until I needed to fill out SFBInterfaceSpec. It's a nightmare to set everything up
> > > > > before
> > > > > filling it, and it's also not flexible at all. Further port changes are the same problems all over again + refactoring of the previous code.
> > > > > To simplify things I made SFBInterfaceSpec (source code attached). Does it make sense to incorporate it into Forte core? I also think that a parser
> > > > > for
> > > > > generic SIFBs should be standardized as currently every GEN_* implements its own parser.
> > > > >
> > > > > An example would look like this:
> > > > > bool GEN_PQ_ITER::createInterfaceSpec(const char *pa_sConfig, SFBInterfaceSpec &pa_oInterfaceSpec) {
> > > > > unsigned long numbers[2];
> > > > > if (!parseSpec(pa_sConfig, "PQ_ITER", numbers, 2))
> > > > > return false;
> > > > >
> > > > > static const std::array staticEINames = { g_nStringIdINIT, g_nStringIdREQ };
> > > > > static const std::array staticEONames = { g_nStringIdINITO, g_nStringIdCNF };
> > > > >
> > > > > auto ifsb = CIfSpecBuilder();
> > > > > bool stat =
> > > > > ifsb.m_oEI.setStaticEvents(staticEINames) &&
> > > > > ifsb.m_oEO.setStaticEvents(staticEONames) &&
> > > > > ifsb.m_oDI.addData("QI", g_nStringIdBYTE) && /* g_nStringIdQI can be used instead of "QI" */
> > > > > ifsb.m_oDI.addDataRange("SD_", (int)numbers[0]) &&
> > > > > ifsb.m_oDO.addData("QO", g_nStringIdBYTE) &&
> > > > > ifsb.m_oDO.addDataRange("RD_", (int)numbers[1]) &&
> > > > > ifsb.bind(ifsb.m_oEI["INIT"], {ifsb.m_oDI["QI"], ifsb.m_oDI["ID"]}) &&
> > > > > ifsb.bind(ifsb.m_oEI["REQ"], ifsb.m_oDI["QI"]) &&
> > > > > ifsb.bind(ifsb.m_oEO["INITO"], ifsb.m_oDO["QO"]);
> > > > >
> > > > > stat = stat && ifsb.build(m_oMixedStorage, pa_oInterfaceSpec);
> > > > > if (!stat) {
> > > > > DEVLOG_ERROR("interface spec builder failed!\n");
> > > > > }
> > > > >
> > > > > return stat;
> > > > > }
> > > > > As it can be seen, the builder supports both static and dynamic configuration (although not yet for "withs"). And in the end it uses only one member
> > > > > for data
> > > > > storage (m_oMixedStorage) which automatically cleans up at SIFB's EOL.
> > > > > I don't expect this method to use more memory than before. It even has potential to use less memory as there is only one memory block used (after
> > > > > setup). The
> > > > > only disadvantage would be slower initialization which shouldn't matter any way. By using this way of initialization in other GEN_* FBs the code size
> > > > > could
> > > > > also be reduced a bit.
> > > > > It would be nice to be able to use constexpr for std::array (so it can be stored in ROM), but something needs to be done first, I need to look into
> > > > > it.
> > > > > _______________________________________________
> > > > > 4diac-dev mailing list
> > > > > 4diac-dev@xxxxxxxxxxx
> > > > > To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/4diac-dev
> > > >
> > > > _______________________________________________
> > > > 4diac-dev mailing list
> > > > 4diac-dev@xxxxxxxxxxx
> > > > To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/4diac-dev
> > >
> > >
> > >
> > > _______________________________________________
> > > 4diac-dev mailing list
> > > 4diac-dev@xxxxxxxxxxx
> > > To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/4diac-dev
> >
> >
> > _______________________________________________
> > 4diac-dev mailing list
> > 4diac-dev@xxxxxxxxxxx
> > To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/4diac-dev
> _______________________________________________
> 4diac-dev mailing list
> 4diac-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/4diac-dev
