May 29, 2019, 12:33 PM by [email protected]:
>
>
>> 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...
>
Sure, special section in the docs could be helpful. I have been thinking about
somehow integrating all these informations from MH's wiki and videos and AR's
blog serial into the docs as the current situation when every soul interested
in Machinetalk is send to some obscure sources as a first thing is not very
good. And even though there is some "documentation" about Machinetalk Protobuf
messages, it is auto-generated and my first reaction when I have seen it was
"WTF is this mess?" So it becomes useful one gets the idea what Machinetalk is
about.
However, the questing remains who will write it and who will comment on it? I
can write some, but some kind of collaboration would go a long way.
Cern.
>>>
>>> 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.
>
--
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/LgJO6Qn--3-1%40tuta.io.
For more options, visit https://groups.google.com/d/optout.
