[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [4diac-dev] InterfaceSpecBuilder
|
Hi,
thx for all the work. I had a first quick look and it looks very interesting.
Currently the Eclipse Jenkins server is down. Maybe that is the cause of the build issues. But I'm not sure. Will look into it as soon as it is back.
What I noticed is that in the first line of the copy right header you only placed copyright and a year. To be correct we would also need to name of the copy
right holder. If you are doing this personally than this would be your full name. If you are working for a company and the company owns your work (e.g., as it
is the case for me) then you need to place the name of the company owning the copyrights there.
thx again,
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
