| Re: [4diac-dev] InterfaceSpecBuilder |
Hello!
I've pushed the updated changeset.
Tabs were in a pair of files in the first commit and it was fixed in one of the last commits. I didn't expect that commits will be checked individually for tabs. Commits got ammended and it should be fixed now.
Copyright headers are also fixed.
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_______________________________________________ 4diac-dev mailing list 4diac-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/4diac-dev