> On 28 May 2019, at 23:59, <[email protected]> <[email protected]> wrote:
>
> May 28, 2019, 7:36 AM by [email protected]:
>
>> Hi Cern and Markus,
>>
>>
>>> On 27 May 2019, at 21:15, markus <>> [email protected]
>>> <mailto:[email protected]>>> > wrote:
>>>
>>> Thanks for the pointer, I had not looked at those fields in Container
>>> yet - I can see that there were grand plans indeed, what I don't see
>>> is where they were supposed to go.
>>>
>>> And I mean that in many ways. It's not clear where each one of
>>> these services was supposed to be implemented, how they were supposed
>>> to be integrated with the rest (.ini file or some new mechanism) and
>>> finally - I'm not entirely sure what problems some of them were
>>> supposed to solve.
>>>
>>> For instance status.config - if that had a fixed
>>> (configurable in some way) port the service_announcement you
>>> pointed to would make sense and be quite useful.
>>>
>>> Can you elaborate what you meant by different transports? What is it
>>> you are looking for?
>>>
>>> Have fun,
>>> Markus
>>>
>>> On Mon, 27 May 2019 17:35:00 +0200 (CEST)
>>> <>> [email protected] <mailto:[email protected]>>> > wrote:
>>>
>>>
>>>> 27. 5. 2019 3:20 od >>> [email protected] <mailto:[email protected]>>>> :
>>>>
>>>>
>>>>> In my quest to figure out how machinetalk works I came across the
>>>>> following in mkwrapper.py:
>>>>>
>>>>> def main():
>>>>> parser = argparse.ArgumentParser(
>>>>> description='Mkwrapper is wrapper around the linuxcnc
>>>>> python module' 'as temporary workaround for Machinetalk based user
>>>>> interfaces' )
>>>>> So if mkwrapper.py is/was considered a temporary workaround, how
>>>>> does/should the real thing look like?
>>>>>
>>>>
>>>> Problem with Machinetalk, one which needs to be remembered at all
>>>> times, is that it is in an unfinished state from a development point
>>>> of view and probably the specification was never finished also. Hard
>>>> to say as Michael Haberler, who cooked it up at the beginning, left
>>>> the project and I don't know if Alexander Roessler is active in
>>>> Machinetalk development anymore.
>>>>
>>>> So short term band-aids become long term solutions. Not good but
>>>> probably good enough for now.
>>>>
>>>> As you can see the Machinetalk suffers a little bit by grandiose
>>>> dreams which never materialized. Like the preparation work in
>>>> Container
>>>> message, >>>
>>>> https://github.com/machinekit/machinetalk-protobuf/blob/master/src/machinetalk/protobuf/message.proto#L128
>>>>
>>>> <https://github.com/machinekit/machinetalk-protobuf/blob/master/src/machinetalk/protobuf/message.proto#L128>
>>>> <>>>
>>>> https://github.com/machinekit/machinetalk-protobuf/blob/master/src/machinetalk/protobuf/message.proto#L128
>>>>
>>>> <https://github.com/machinekit/machinetalk-protobuf/blob/master/src/machinetalk/protobuf/message.proto#L128>>>>
>>>> > ,
>>>> for ZeroMQ thought up service discovery instead of DNS-SD/mDNS. Also,
>>>> it didn't cover the problem of multiple transport protocols
>>>> (IPC/TCP/UDP), which I think is sorely needed. And the NOTYET defines
>>>> are still open work in the source code. From today point of view, I
>>>> think it needs some rework. And I am open to discussion on how to do
>>>> this. (I am of the opinion that the definition should be accessible
>>>> before the code.)
>>>>
>>>> Cern.
>>>>
>>
>> Machinetalk has been the vehicle for having remote GUI’s. It’s been a
>> solution so far, but that does not mean it’s complete. I can’t help you with
>> that because that’s matter I do not have knowledge/experience on.
>> mkwrapper is a python wrapper around NML, >
>> https://github.com/machinekit/machinekit/pull/314
>> <https://github.com/machinekit/machinekit/pull/314>
>>
> Yes, but it's not only that. I find it kind of a problem that when people
> talk about Machinetalk they mean remote GUI capability. It's like when people
> tell others that Machinekit is LinuxCNC for BeagleBone Black or BBB project.
Indeed.
>
> Look for example at communication between rtapi_app instance and HALCMD
> application.
>
>>
>> The Machinekit project once forked from LinuxCNC because some people were
>> dissatisfied with the effort it took to have their code merged in the master
>> branch.
>> That made that new features were slow to turn up into the master branch, if
>> at all.
>>
> And I am glad for it. It is one of the reasons why I am here and not there.
>
>>
>> There is not “one grand designer” or “roadmap" that gives direction to this
>> project. It’s up to people adding code that’s of their interest. And as some
>> people add a lot of code it’s natural that these are to be the driving force
>> behind a project. Taking it in a direction that scratches an itch or has
>> their interest. So “direction” by “effect”.
>> I’m mostly interested in the HAL layer for example. I don’t have a lot of
>> knowledge about the internals of the CNC stack, or on Haltalk for that
>> matter. Although I do use them.
>>
> I think that "roadmap" in some form is a good think. Or better yet RFC.
> Basically design of the project before code. Create general specification to
> which subsequent development should adhere. It is clearly missing in the form
> of Machinetalk (and it's subsets like HALtalk and so on) and given the fact
> that Machinetalk is basically decoupling API and lot of other programs depend
> on it in situations you cannot really determine, any change is minefield.
I’ve done automation projects as you describe. Design behaviour before code.
State machine, sequence diagrams etc.
We can create a designated page/section in the docs? We’re using Jekyll and
asciidoc to create the website and documentation. Using plantuml graphics in
those asciidocs is a no brainer. And a picture says more than... you know...
>
>>
>> If you want to add/improve code and functionality on parts of the Machinekit
>> project, that would be great and welcomed!
>> The difficulty arises in that these kinds of efforts are hard, so there will
>> be only a few people who really understand what’s going on (that’s why it’s
>> so difficult to understand the legacy code base).
>>
> Can concur, took me a long while to get to at least some proficiency.
>
>> Because of the C4 process, I as a maintainer do not have to know about code,
>> or do “reviews” other than basic stuff. I do not decide if a PR is “good” or
>> “bad” on the basis of what it does. The only thing I try to do (if that’s
>> within my knowledge set) is to see if the PR does not break the API. We
>> don’t want to mess up existing systems, especially because this kind of
>> software is driving _real_ machines.
>>
> Bingo. That's the core of the problem. Everybody assumes how the API is
> constructed or meant but nobody knows for sure. And for every change
> everybody will make there will be somewhere somebody who will be pissed off.
> Because his program of which you had no prior knowledge suddenly stops
> working. (Simplistic example can be seen here:
> https://github.com/machinekit/machinekit/pull/1456#discussion_r250955577
> <https://github.com/machinekit/machinekit/pull/1456#discussion_r250955577> )
>
> So any change must be of the big bang style.
>
>
>> If anybody uses Machinekit in a product and relies on a stable branch, it’s
>> up for that person/company to fork and create a stable branch and take care
>> of that. We have a build system that will show if packages are successfully
>> built, and that’s my (literally) green light for merging. That simple.
>> If for whatever reason a PR breaks the code, then either the maintainer
>> being around fixes it, or if they are gone and nobody can fix it, we revert
>> the PR.
>>
>> If you want to add functionality, see problems, improve, the way this works
>> (best) is:
>> Create an issue on github for the repository it concerns.
>>
> When I will have everything completely summarized, will do.
>
>> This is the focus point for the problem, and helps keeping the
>> information/discussion centered
>> Explain your case, discuss
>> Have other people engaged in the discussion. This really helps.
>> Hopefully this results you end up with likeminded people.
>> Create PR’s preferably in small bits. Do not break the API.
>>
> In many cases it is not possible to not break API. What is possible is to
> create second version which will live alongside the original implementation.
> And like the mkwrapper that's probably OK too.
Yes, that’s the way, create a second version. That’s what’s been done
previously.
>
> Cern.
>
>> Smaller bits are easier and less “scarier” than a huge blob that only the
>> author of the code understand. It creates progress, traction, increases the
>> chance of early testing. Having said that, because the code can be
>> difficult, PR's might be bigger if there are a lot of architectural changes
>> needed. But either way, make a PR and it will be merged if it does not mess
>> up the existing code.
>> So long story short, Do not let the “there is no roadmap” fact hold you back.
>>
>> Bas
>>
>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> website: > >>>> http://www.machinekit.io <http://www.machinekit.io>>>>>
>>>>> <>>>> http://www.machinekit.io <http://www.machinekit.io>>>>> >>
>>>>> blog: > >>>> http://blog.machinekit.io <http://blog.machinekit.io>>>>>
>>>>> <>>>> http://blog.machinekit.io <http://blog.machinekit.io>>>>> >>
>>>>> github: > >>>> https://github.com/machinekit
>>>>> <https://github.com/machinekit>
>>>>> <>>>> https://github.com/machinekit <https://github.com/machinekit>>>>> >
>>>>> --- You received this message
>>>>> because you are subscribed to the Google Groups "Machinekit" group.
>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>> send an email to > >>>> [email protected]
>>>>> <mailto:[email protected]>
>>>>> <>>>> mailto:[email protected]
>>>>> <mailto:[email protected]>>>>> >> . Visit this
>>>>> group at > >>>> https://groups.google.com/group/machinekit
>>>>> <https://groups.google.com/group/machinekit>
>>>>> <>>>> https://groups.google.com/group/machinekit
>>>>> <https://groups.google.com/group/machinekit>>>>> >> . To view this
>>>>> discussion on the web visit >
>>>>> https://groups.google.com/d/msgid/machinekit/6b0977ef-1595-4919-ae1b-faf3b8428670%40googlegroups.com
>>>>>
>>>>> <https://groups.google.com/d/msgid/machinekit/6b0977ef-1595-4919-ae1b-faf3b8428670%40googlegroups.com>
>>>>> <https://groups.google.com/d/msgid/machinekit/6b0977ef-1595-4919-ae1b-faf3b8428670%40googlegroups.com?utm_medium=email&utm_source=footer>>
>>>>> .
>>>>> For more options, visit > https://groups.google.com/d/optout
>>>>> <https://groups.google.com/d/optout>> .
>>>>>
>>>>
>>>>
>>>
>>> --
>>> website: >> http://www.machinekit.io <http://www.machinekit.io>>> blog: >>
>>> http://blog.machinekit.io <http://blog.machinekit.io>>> github: >>
>>> https://github.com/machinekit <https://github.com/machinekit>
>>> ---
>>> You received this message because you are subscribed to the Google Groups
>>> "Machinekit" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to >> [email protected]
>>> <mailto:[email protected]>>> .
>>> Visit this group at >> https://groups.google.com/group/machinekit
>>> <https://groups.google.com/group/machinekit>>> .
>>> To view this discussion on the web visit >>
>>> https://groups.google.com/d/msgid/machinekit/20190527121558.02c13f85%40edeltraud
>>>
>>> <https://groups.google.com/d/msgid/machinekit/20190527121558.02c13f85%40edeltraud>>>
>>> .
>>> For more options, visit >> https://groups.google.com/d/optout
>>> <https://groups.google.com/d/optout>>> .
>>>
>
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github:
https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
Visit this group at https://groups.google.com/group/machinekit.
To view this discussion on the web visit
https://groups.google.com/d/msgid/machinekit/BE82C931-051D-4474-9409-266BF4F05A9B%40basdebruijn.com.
For more options, visit https://groups.google.com/d/optout.
