from:"Matjaž Ostroveršnik"

Yeah sure. Let's go to something more productive. ;-)

On 13.4.2016 23:14, Pieter Hintjens wrote:
> I assume you hacked project.xml to make that work since it starts by
> including 'license.xml'.
>
> I assume also this is a learning thing for you and you're not actually
> solving any specific problems. In that case, enjoy. I'll leave this
> thread for now.
>
> On Wed, Apr 13, 2016 at 10:59 PM, Matjaž Ostroveršnik
>  wrote:
>>
>> On 13.4.2016 22:37, Pieter Hintjens wrote:
>>> gsl project.xml will not work from any folder; it will scatter
>>> generated files all over the place.
>>>
>>> usage rule is you build the model, in its directory. Never use a path
>>> to a model (xml) file that you pass to gsl.
>> If this is the intention, then we have a bug. ;-)
>>
>> [ostri@uran ~/zstuff/build/tmp]$ gsl ../top/project.xml
>> GSL/4.1c Copyright (c) 1996-2016 iMatix Corporation
>> gsl/4 I: Processing ../top/project.xml...
>> gsl/4 M: Generating skeleton for src/malamute.c
>> gsl/4 M: Generating skeleton for src/mshell.c
>> gsl/4 M: Generating skeleton for src/mlm_tutorial.c
>> gsl/4 M: Generating skeleton for src/mlm_tutorial_curve.c
>> gsl/4 M: Generating skeleton for src/mlm_perftest.c
>> gsl/4 M: Generating skeleton for src/mlm_selftest.c
>> gsl/4 M: Generating skeleton for include/malamute.h
>> gsl/4 M: Generating skeleton for include/mlm_proto.h
>> gsl/4 M: Generating skeleton for src/mlm_proto.c
>> gsl/4 M: Generating skeleton for include/mlm_server.h
>> gsl/4 M: Generating skeleton for src/mlm_server.c
>> gsl/4 M: Generating skeleton for include/mlm_client.h
>> gsl/4 M: Generating skeleton for src/mlm_client.c
>> gsl/4 M: Generating skeleton for src/mlm_msg.h
>> gsl/4 M: Generating skeleton for src/mlm_msg.c
>> gsl/4 M: Generating skeleton for src/mlm_stream_simple.h
>> gsl/4 M: Generating skeleton for src/mlm_stream_simple.c
>> gsl/4 M: Generating skeleton for src/mlm_mailbox_simple.h
>> gsl/4 M: Generating skeleton for src/mlm_mailbox_simple.c
>> gsl/4 M: Generating initial .gitignore file
>> gsl/4 M: Generating initial .gitattributes file
>> gsl/4 M: Building Java JNI binding (java)
>> gsl/4 M: Building Python binding (python)
>> gsl/4 M: Building Ruby binding (ruby)
>> gsl/4 M: Building Travis CI scripts (travis)
>> gsl/4 M: Generating skeleton .travis.yml script
>> gsl/4 M: Building packaging for Docker (docker)
>> gsl/4 M: Building Microsoft Visual Studio 2015 (vs2015)
>> gsl/4 M: Building GYP build system (project.gyp) (gyp)
>> gsl/4 M: E: please checkout libzmq into ../libzmq
>> gsl/4 M: E: please checkout czmq into ../czmq
>> gsl/4 M: Building GNU build system (autotools)
>> gsl/4 M: Building CMake build system (cmake)
>>
>>
>>> On Wed, Apr 13, 2016 at 10:12 PM, Matjaž Ostroveršnik
>>>  wrote:
>>>> It is not that by intention that want to work around the design.
>>>> There are just few inconsistency I've encountered. Perhaps my knowledge
>>>> not deep enough.
>>>>
>>>> gsl project.xml  - it works from any folder (e.g. gsl
>>>> ~/zstuff/malamute/project.xml)
>>>> gsl mlm_proto.xml   - it works fine from src folder, but it fails from
>>>> different folder
>>>>
>>>> The same program, but two different behaviors.  What is the usage rule
>>>> for gsl?
>>>>
>>>> On 13.4.2016 21:59, Pieter Hintjens wrote:
>>>>> Why are you trying to work around the design? If you could be explicit
>>>>> about that it would really help. I mean, if you try to use a knife as
>>>>> a screwdriver and the tip breaks off, it's not the knife's fault. Can
>>>>> you explain why you are trying to run gsl in the *wrong place* and why
>>>>> it's "unfortunate" that does not work?
>>>>>
>>>>>
>>>>> On Wed, Apr 13, 2016 at 9:44 PM, Matjaž Ostroveršnik
>>>>>  wrote:
>>>>>> I am (unfortunatelly ;-) ) confirming.
>>>>>> Found this in src/Makemodule.am
>>>>>>
>>>>>> # Produce generated code from models in the src directory
>>>>>> code:
>>>>>> cd $(srcdir)/src; gsl -topdir:.. -zproject:1 -q mlm_proto.xml
>>>>>> cd $(srcdir)/src; gsl -topdir:.. -zproject:1 -q 
>>>>>> mlm_client.xml
>>>>>> cd $(srcdir)/src; gsl -topdir:.. -zproject:1 -q 
>>>>>> mlm_se

Re: [zeromq-dev] gsl details

On 13.4.2016 22:37, Pieter Hintjens wrote:
> gsl project.xml will not work from any folder; it will scatter
> generated files all over the place.
>
> usage rule is you build the model, in its directory. Never use a path
> to a model (xml) file that you pass to gsl.

If this is the intention, then we have a bug. ;-)

[ostri@uran ~/zstuff/build/tmp]$ gsl ../top/project.xml
GSL/4.1c Copyright (c) 1996-2016 iMatix Corporation
gsl/4 I: Processing ../top/project.xml...
gsl/4 M: Generating skeleton for src/malamute.c
gsl/4 M: Generating skeleton for src/mshell.c
gsl/4 M: Generating skeleton for src/mlm_tutorial.c
gsl/4 M: Generating skeleton for src/mlm_tutorial_curve.c
gsl/4 M: Generating skeleton for src/mlm_perftest.c
gsl/4 M: Generating skeleton for src/mlm_selftest.c
gsl/4 M: Generating skeleton for include/malamute.h
gsl/4 M: Generating skeleton for include/mlm_proto.h
gsl/4 M: Generating skeleton for src/mlm_proto.c
gsl/4 M: Generating skeleton for include/mlm_server.h
gsl/4 M: Generating skeleton for src/mlm_server.c
gsl/4 M: Generating skeleton for include/mlm_client.h
gsl/4 M: Generating skeleton for src/mlm_client.c
gsl/4 M: Generating skeleton for src/mlm_msg.h
gsl/4 M: Generating skeleton for src/mlm_msg.c
gsl/4 M: Generating skeleton for src/mlm_stream_simple.h
gsl/4 M: Generating skeleton for src/mlm_stream_simple.c
gsl/4 M: Generating skeleton for src/mlm_mailbox_simple.h
gsl/4 M: Generating skeleton for src/mlm_mailbox_simple.c
gsl/4 M: Generating initial .gitignore file
gsl/4 M: Generating initial .gitattributes file
gsl/4 M: Building Java JNI binding (java)
gsl/4 M: Building Python binding (python)
gsl/4 M: Building Ruby binding (ruby)
gsl/4 M: Building Travis CI scripts (travis)
gsl/4 M: Generating skeleton .travis.yml script
gsl/4 M: Building packaging for Docker (docker)
gsl/4 M: Building Microsoft Visual Studio 2015 (vs2015)
gsl/4 M: Building GYP build system (project.gyp) (gyp)
gsl/4 M: E: please checkout libzmq into ../libzmq
gsl/4 M: E: please checkout czmq into ../czmq
gsl/4 M: Building GNU build system (autotools)
gsl/4 M: Building CMake build system (cmake)

>
> On Wed, Apr 13, 2016 at 10:12 PM, Matjaž Ostroveršnik
>  wrote:
>> It is not that by intention that want to work around the design.
>> There are just few inconsistency I've encountered. Perhaps my knowledge
>> not deep enough.
>>
>> gsl project.xml  - it works from any folder (e.g. gsl
>> ~/zstuff/malamute/project.xml)
>> gsl mlm_proto.xml   - it works fine from src folder, but it fails from
>> different folder
>>
>> The same program, but two different behaviors.  What is the usage rule
>> for gsl?
>>
>> On 13.4.2016 21:59, Pieter Hintjens wrote:
>>> Why are you trying to work around the design? If you could be explicit
>>> about that it would really help. I mean, if you try to use a knife as
>>> a screwdriver and the tip breaks off, it's not the knife's fault. Can
>>> you explain why you are trying to run gsl in the *wrong place* and why
>>> it's "unfortunate" that does not work?
>>>
>>>
>>> On Wed, Apr 13, 2016 at 9:44 PM, Matjaž Ostroveršnik
>>>  wrote:
>>>> I am (unfortunatelly ;-) ) confirming.
>>>> Found this in src/Makemodule.am
>>>>
>>>> # Produce generated code from models in the src directory
>>>> code:
>>>>cd $(srcdir)/src; gsl -topdir:.. -zproject:1 -q mlm_proto.xml
>>>>cd $(srcdir)/src; gsl -topdir:.. -zproject:1 -q mlm_client.xml
>>>>cd $(srcdir)/src; gsl -topdir:.. -zproject:1 -q mlm_server.xml
>>>>gsl -target:- project.xml
>>>>
>>>>
>>>> On 13.4.2016 21:40, Pieter Hintjens wrote:
>>>>> No hypothesis. I'm telling you a fact. If you run gsl in the wrong
>>>>> place *it will not work*. Please do not debug misuse.
>>>>>
>>>>> On Wed, Apr 13, 2016 at 8:57 PM, Matjaž Ostroveršnik
>>>>>  wrote:
>>>>>> Pieter hypothesis is that the src folder is hard coded. ;-)
>>>>>>
>>>>>>
>>>>>> On 13.4.2016 20:10, Kevin Sapper wrote:
>>>>>>
>>>>>> Now you got me curious :)
>>>>>>
>>>>>> The error message with commented license.xml should be:
>>>>>> $ gsl src/mlm_proto.xml
>>>>>> 2016/04/13 20:04:48: GSL/4.1a/github Copyright (c) 1996-2011 iMatix
>>>>>> Corporation
>>>>>> 2016/04/13 20:04:48: gsl/4 I: Processing src/mlm_proto.xml...
>>>>>> 2016/04/13 20:04:48: (zproto_codec_c.gsl 206) Can't open output file

Re: [zeromq-dev] gsl details

It is not that by intention that want to work around the design.
There are just few inconsistency I've encountered. Perhaps my knowledge 
not deep enough.

gsl project.xml  - it works from any folder (e.g. gsl 
~/zstuff/malamute/project.xml)
gsl mlm_proto.xml   - it works fine from src folder, but it fails from 
different folder

The same program, but two different behaviors.  What is the usage rule 
for gsl?

On 13.4.2016 21:59, Pieter Hintjens wrote:
> Why are you trying to work around the design? If you could be explicit
> about that it would really help. I mean, if you try to use a knife as
> a screwdriver and the tip breaks off, it's not the knife's fault. Can
> you explain why you are trying to run gsl in the *wrong place* and why
> it's "unfortunate" that does not work?
>
>
> On Wed, Apr 13, 2016 at 9:44 PM, Matjaž Ostroveršnik
>  wrote:
>> I am (unfortunatelly ;-) ) confirming.
>> Found this in src/Makemodule.am
>>
>> # Produce generated code from models in the src directory
>> code:
>>   cd $(srcdir)/src; gsl -topdir:.. -zproject:1 -q mlm_proto.xml
>>   cd $(srcdir)/src; gsl -topdir:.. -zproject:1 -q mlm_client.xml
>>   cd $(srcdir)/src; gsl -topdir:.. -zproject:1 -q mlm_server.xml
>>   gsl -target:- project.xml
>>
>>
>> On 13.4.2016 21:40, Pieter Hintjens wrote:
>>> No hypothesis. I'm telling you a fact. If you run gsl in the wrong
>>> place *it will not work*. Please do not debug misuse.
>>>
>>> On Wed, Apr 13, 2016 at 8:57 PM, Matjaž Ostroveršnik
>>>  wrote:
>>>> Pieter hypothesis is that the src folder is hard coded. ;-)
>>>>
>>>>
>>>> On 13.4.2016 20:10, Kevin Sapper wrote:
>>>>
>>>> Now you got me curious :)
>>>>
>>>> The error message with commented license.xml should be:
>>>> $ gsl src/mlm_proto.xml
>>>> 2016/04/13 20:04:48: GSL/4.1a/github Copyright (c) 1996-2011 iMatix
>>>> Corporation
>>>> 2016/04/13 20:04:48: gsl/4 I: Processing src/mlm_proto.xml...
>>>> 2016/04/13 20:04:48: (zproto_codec_c.gsl 206) Can't open output file:
>>>> ../include/mlm_proto.h
>>>>
>>>> Which again happens because the current working directory is applied to all
>>>> relative paths.
>>>>
>>>>
>>>> On Mi, Apr 13, 2016 at 7:58 , Matjaž Ostroveršnik
>>>>  wrote:
>>>>
>>>> I commented out the license file, but the same.
>>>>
>>>> I am getting
>>>> GSL/4.1c Copyright (c) 1996-2016 iMatix Corporation
>>>> gsl/4 I: Processing src/mlm_proto.xml...
>>>> (zproto_lib.gsl 99) Undefined expression: class.load_file (...)
>>>>
>>>>
>>>> On 13.4.2016 19:50, Kevin Sapper wrote:
>>>>
>>>> OK, I just thought a little bit harder ;)
>>>>
>>>> src/mlm_proto.xml includes a second xml files:  >>> "license.xml" />. Where filename is a relative path from the current 
>>>> working
>>>> directory. Thus if you execute gsl from project root directory it is not
>>>> able to find the src/license.xml.
>>>>
>>>> But from project root you can run make code.
>>>>
>>>> On Mi, Apr 13, 2016 at 7:44 , Matjaž Ostroveršnik
>>>>  wrote:
>>>>
>>>> Hi Kevin,
>>>>
>>>> Thanks for fast reply. I believe it is not problem with tabs.
>>>> The same command in src folder succeeds, while one folder above, but with
>>>> proper reference to the xml file it fails.
>>>> My assumption is that gsl takes "instructions" from some default place,
>>>> unless it is explicitly stated. And I do not know this place.;-)
>>>>
>>>> Best regards
>>>>
>>>> Matjaž
>>>>
>>>> On 13.4.2016 19:36, Kevin Sapper wrote:
>>>>
>>>> Hi Matjaž,
>>>>
>>>> without being able to take a closer look now, GSL does not like tabs at the
>>>> beginning of the line.
>>>>
>>>> Am 13.04.2016 6:16 nachm. schrieb "Matjaž Ostroveršnik"
>>>> :
>>>>> Hi veterans,
>>>>>
>>>>> I am trying to understand how gsl woks. Yes I read the instructions
>>>>> (https://github.com/imatix/gsl)
>>>>>
>>>>> command
>>>>> gsl mlm_proto.xml
>>>>>
>>>&g

Re: [zeromq-dev] gsl details

I am (unfortunatelly ;-) ) confirming.
Found this in src/Makemodule.am

# Produce generated code from models in the src directory
code:
 cd $(srcdir)/src; gsl -topdir:.. -zproject:1 -q mlm_proto.xml
 cd $(srcdir)/src; gsl -topdir:.. -zproject:1 -q mlm_client.xml
 cd $(srcdir)/src; gsl -topdir:.. -zproject:1 -q mlm_server.xml
 gsl -target:- project.xml


On 13.4.2016 21:40, Pieter Hintjens wrote:
> No hypothesis. I'm telling you a fact. If you run gsl in the wrong
> place *it will not work*. Please do not debug misuse.
>
> On Wed, Apr 13, 2016 at 8:57 PM, Matjaž Ostroveršnik
>  wrote:
>> Pieter hypothesis is that the src folder is hard coded. ;-)
>>
>>
>> On 13.4.2016 20:10, Kevin Sapper wrote:
>>
>> Now you got me curious :)
>>
>> The error message with commented license.xml should be:
>> $ gsl src/mlm_proto.xml
>> 2016/04/13 20:04:48: GSL/4.1a/github Copyright (c) 1996-2011 iMatix
>> Corporation
>> 2016/04/13 20:04:48: gsl/4 I: Processing src/mlm_proto.xml...
>> 2016/04/13 20:04:48: (zproto_codec_c.gsl 206) Can't open output file:
>> ../include/mlm_proto.h
>>
>> Which again happens because the current working directory is applied to all
>> relative paths.
>>
>>
>> On Mi, Apr 13, 2016 at 7:58 , Matjaž Ostroveršnik
>>  wrote:
>>
>> I commented out the license file, but the same.
>>
>> I am getting
>> GSL/4.1c Copyright (c) 1996-2016 iMatix Corporation
>> gsl/4 I: Processing src/mlm_proto.xml...
>> (zproto_lib.gsl 99) Undefined expression: class.load_file (...)
>>
>>
>> On 13.4.2016 19:50, Kevin Sapper wrote:
>>
>> OK, I just thought a little bit harder ;)
>>
>> src/mlm_proto.xml includes a second xml files:  > "license.xml" />. Where filename is a relative path from the current working
>> directory. Thus if you execute gsl from project root directory it is not
>> able to find the src/license.xml.
>>
>> But from project root you can run make code.
>>
>> On Mi, Apr 13, 2016 at 7:44 , Matjaž Ostroveršnik
>>  wrote:
>>
>> Hi Kevin,
>>
>> Thanks for fast reply. I believe it is not problem with tabs.
>> The same command in src folder succeeds, while one folder above, but with
>> proper reference to the xml file it fails.
>> My assumption is that gsl takes "instructions" from some default place,
>> unless it is explicitly stated. And I do not know this place.;-)
>>
>> Best regards
>>
>> Matjaž
>>
>> On 13.4.2016 19:36, Kevin Sapper wrote:
>>
>> Hi Matjaž,
>>
>> without being able to take a closer look now, GSL does not like tabs at the
>> beginning of the line.
>>
>> Am 13.04.2016 6:16 nachm. schrieb "Matjaž Ostroveršnik"
>> :
>>> Hi veterans,
>>>
>>> I am trying to understand how gsl woks. Yes I read the instructions
>>> (https://github.com/imatix/gsl)
>>>
>>> command
>>> gsl mlm_proto.xml
>>>
>>> executed from malamute/src folder
>>> properly generates mlm_proto.c and mlm_proto.bnf in the current directory
>>>
>>> command
>>> gsl src/mlm_proto.xml
>>>
>>> executed from one folder above produces
>>>
>>> GSL/4.1c Copyright (c) 1996-2016 iMatix Corporation
>>> gsl/4 I: Processing src/mlm_proto.xml...
>>> (zproto_lib.gsl 99) Undefined expression: class.load_file (...)
>>>
>>> obviously gsl gets some additional input from files in current directory.
>>> 1. Which files are those?
>>> 2. Can I explicitly state where to take this file from?
>>> 3. What the following command is supposed to do? (explanation of
>>> parameters)
>>> gsl -topdir:.. -zproject:1 -q mlm_proto.xml
>>>
>>>
>>> Thanks in advance
>>>
>>> Matjaž
>>> ___
>>> zeromq-dev mailing list
>>> zeromq-dev@lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>>
>>
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>>
>>
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>>
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] gsl details

Pieter hypothesis is that the src folder is hard coded. ;-)

On 13.4.2016 20:10, Kevin Sapper wrote:

Now you got me curious :)

The error message with commented license.xml should be:
$ gsl src/mlm_proto.xml
2016/04/13 20:04:48: GSL/4.1a/github Copyright (c) 1996-2011 iMatix
Corporation

2016/04/13 20:04:48: gsl/4 I: Processing src/mlm_proto.xml...
2016/04/13 20:04:48: (zproto_codec_c.gsl 206) Can't open output file:
../include/mlm_proto.h

Which again happens because the current working directory is applied
to all relative paths.

On Mi, Apr 13, 2016 at 7:58 , Matjaž Ostroveršnik
wrote:

I commented out the license file, but the same.

I am getting
GSL/4.1c Copyright (c) 1996-2016 iMatix Corporation
gsl/4 I: Processing src/mlm_proto.xml...
(zproto_lib.gsl 99) Undefined expression: class.load_file (...)

On 13.4.2016 19:50, Kevin Sapper wrote:

OK, I just thought a little bit harder ;)

src/mlm_proto.xml includes a second xml files: "license.xml" />. Where filename is a relative path from the current
working directory. Thus if you execute gsl from project root
directory it is not able to find the src/license.xml.

But from project root you can run make code.

On Mi, Apr 13, 2016 at 7:44 , Matjaž Ostroveršnik
wrote:

Hi Kevin,

Thanks for fast reply. I believe it is not problem with tabs.
The same command in src folder succeeds, while one folder above,
but with proper reference to the xml file it fails.
My assumption is that gsl takes "instructions" from some default
place, unless it is explicitly stated. And I do not know this place.;-)

Best regards

Matjaž

On 13.4.2016 19:36, Kevin Sapper wrote:

Hi Matjaž,

without being able to take a closer look now, GSL does not like
tabs at the beginning of the line.

Am 13.04.2016 6:16 nachm. schrieb "Matjaž Ostroveršnik"
<mailto:matjaz.ostrovers...@gmail.com>>:

Hi veterans,

I am trying to understand how gsl woks. Yes I read the
instructions
(https://github.com/imatix/gsl)

command
gsl mlm_proto.xml

executed from malamute/src folder
properly generates mlm_proto.c and mlm_proto.bnf in the
current directory

command
gsl src/mlm_proto.xml

executed from one folder above produces

GSL/4.1c Copyright (c) 1996-2016 iMatix Corporation
gsl/4 I: Processing src/mlm_proto.xml...
(zproto_lib.gsl 99) Undefined expression: class.load_file (...)

obviously gsl gets some additional input from files in current
directory.
1. Which files are those?
2. Can I explicitly state where to take this file from?
3. What the following command is supposed to do? (explanation
of parameters)
gsl -topdir:.. -zproject:1 -q mlm_proto.xml

Thanks in advance

Matjaž
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org <mailto:zeromq-dev@lists.zeromq.org>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] gsl details

You are good mind reader. ;-)
For a moment forget the time it need to be invested in order to 
implement it in cmake.

I understand there supposed to be several build environments (autotools, 
cmake, ...) in order to cover all platforms that zmq /mlm is running upon.
All starts from the same sources and ant the end they must produce the 
same deliverables (programs, libraries, header, rpm packages, you name it).
But what is between start and end, depends on particular build 
environment. It is not rational to standardize also the intermediate 
results.

Why do you think this is an evil plan?

On 13.4.2016 19:53, Pieter Hintjens wrote:
> It’s set up to run from within src. So you must
>
> cd src
> gsl mlm_proto.xml
> cd ..
>
> I suspect you have the evil plan of trying to put all generated files
> somewhere specific. It’s a neat idea but will not work, if you are
> thinking of it. If not, forget I said anything :)
>
> On Wed, Apr 13, 2016 at 7:50 PM, Kevin Sapper  wrote:
>> OK, I just thought a little bit harder ;)
>>
>> src/mlm_proto.xml includes a second xml files:  > "license.xml" />. Where filename is a relative path from the current working
>> directory. Thus if you execute gsl from project root directory it is not
>> able to find the src/license.xml.
>>
>> But from project root you can run make code.
>>
>> On Mi, Apr 13, 2016 at 7:44 , Matjaž Ostroveršnik
>>  wrote:
>>
>> Hi Kevin,
>>
>> Thanks for fast reply. I believe it is not problem with tabs.
>> The same command in src folder succeeds, while one folder above, but with
>> proper reference to the xml file it fails.
>> My assumption is that gsl takes "instructions" from some default place,
>> unless it is explicitly stated. And I do not know this place.;-)
>>
>> Best regards
>>
>> Matjaž
>>
>> On 13.4.2016 19:36, Kevin Sapper wrote:
>>
>> Hi Matjaž,
>>
>> without being able to take a closer look now, GSL does not like tabs at the
>> beginning of the line.
>>
>> Am 13.04.2016 6:16 nachm. schrieb "Matjaž Ostroveršnik"
>> :
>>> Hi veterans,
>>>
>>> I am trying to understand how gsl woks. Yes I read the instructions
>>> (https://github.com/imatix/gsl)
>>>
>>> command
>>> gsl mlm_proto.xml
>>>
>>> executed from malamute/src folder
>>> properly generates mlm_proto.c and mlm_proto.bnf in the current directory
>>>
>>> command
>>> gsl src/mlm_proto.xml
>>>
>>> executed from one folder above produces
>>>
>>> GSL/4.1c Copyright (c) 1996-2016 iMatix Corporation
>>> gsl/4 I: Processing src/mlm_proto.xml...
>>> (zproto_lib.gsl 99) Undefined expression: class.load_file (...)
>>>
>>> obviously gsl gets some additional input from files in current directory.
>>> 1. Which files are those?
>>> 2. Can I explicitly state where to take this file from?
>>> 3. What the following command is supposed to do? (explanation of
>>> parameters)
>>> gsl -topdir:.. -zproject:1 -q mlm_proto.xml
>>>
>>>
>>> Thanks in advance
>>>
>>> Matjaž
>>> ___
>>> zeromq-dev mailing list
>>> zeromq-dev@lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>>
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] gsl details

I commented out the license file, but the same.

I am getting
GSL/4.1c Copyright (c) 1996-2016 iMatix Corporation
gsl/4 I: Processing src/mlm_proto.xml...
(zproto_lib.gsl 99) Undefined expression: class.load_file (...)

On 13.4.2016 19:50, Kevin Sapper wrote:

OK, I just thought a little bit harder ;)

src/mlm_proto.xml includes a second xml files: "license.xml" />. Where filename is a relative path from the current
working directory. Thus if you execute gsl from project root directory
it is not able to find the src/license.xml.

But from project root you can run make code.

On Mi, Apr 13, 2016 at 7:44 , Matjaž Ostroveršnik
wrote:

Hi Kevin,

Thanks for fast reply. I believe it is not problem with tabs.
The same command in src folder succeeds, while one folder above, but
with proper reference to the xml file it fails.
My assumption is that gsl takes "instructions" from some default
place, unless it is explicitly stated. And I do not know this place.;-)

Best regards

Matjaž

On 13.4.2016 19:36, Kevin Sapper wrote:

Hi Matjaž,

without being able to take a closer look now, GSL does not like tabs
at the beginning of the line.

Am 13.04.2016 6:16 nachm. schrieb "Matjaž Ostroveršnik"
mailto:matjaz.ostrovers...@gmail.com>>:

Hi veterans,

I am trying to understand how gsl woks. Yes I read the instructions
(https://github.com/imatix/gsl)

command
gsl mlm_proto.xml

executed from malamute/src folder
properly generates mlm_proto.c and mlm_proto.bnf in the current
directory

command
gsl src/mlm_proto.xml

executed from one folder above produces

GSL/4.1c Copyright (c) 1996-2016 iMatix Corporation
gsl/4 I: Processing src/mlm_proto.xml...
(zproto_lib.gsl 99) Undefined expression: class.load_file (...)

obviously gsl gets some additional input from files in current
directory.
1. Which files are those?
2. Can I explicitly state where to take this file from?
3. What the following command is supposed to do? (explanation of
parameters)
gsl -topdir:.. -zproject:1 -q mlm_proto.xml

Thanks in advance

Matjaž
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org <mailto:zeromq-dev@lists.zeromq.org>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] gsl details


Hi Kevin,

Thanks for fast reply. I believe it is not problem with tabs.
The same command in src folder succeeds, while one folder above, but 
with proper reference to the xml file it fails.
My assumption is that gsl takes "instructions" from some default place, 
unless it is explicitly stated. And I do not know this place.;-)


Best regards

Matjaž

On 13.4.2016 19:36, Kevin Sapper wrote:


Hi Matjaž,

without being able to take a closer look now, GSL does not like tabs 
at the beginning of the line.


Am 13.04.2016 6:16 nachm. schrieb "Matjaž Ostroveršnik" 
mailto:matjaz.ostrovers...@gmail.com>>:


Hi veterans,

I am trying to understand how gsl woks. Yes I read the instructions
(https://github.com/imatix/gsl)

command
gsl mlm_proto.xml

executed from malamute/src folder
properly generates mlm_proto.c and mlm_proto.bnf in the current
directory

command
gsl src/mlm_proto.xml

executed from one folder above produces

GSL/4.1c Copyright (c) 1996-2016 iMatix Corporation
gsl/4 I: Processing src/mlm_proto.xml...
(zproto_lib.gsl 99) Undefined expression: class.load_file (...)

obviously gsl gets some additional input from files in current
directory.
1. Which files are those?
2. Can I explicitly state where to take this file from?
3. What the following command is supposed to do? (explanation of
parameters)
   gsl -topdir:.. -zproject:1 -q mlm_proto.xml


Thanks in advance

Matjaž
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org <mailto:zeromq-dev@lists.zeromq.org>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev



___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] gsl details

Hi veterans,

I am trying to understand how gsl woks. Yes I read the instructions 
(https://github.com/imatix/gsl)

command
gsl mlm_proto.xml

executed from malamute/src folder
properly generates mlm_proto.c and mlm_proto.bnf in the current directory

command
gsl src/mlm_proto.xml

executed from one folder above produces

GSL/4.1c Copyright (c) 1996-2016 iMatix Corporation
gsl/4 I: Processing src/mlm_proto.xml...
(zproto_lib.gsl 99) Undefined expression: class.load_file (...)

obviously gsl gets some additional input from files in current directory.
1. Which files are those?
2. Can I explicitly state where to take this file from?
3. What the following command is supposed to do? (explanation of parameters)
   gsl -topdir:.. -zproject:1 -q mlm_proto.xml


Thanks in advance

Matjaž
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Idiot guide to update mlm server project

Thanks Osiris.

I did it. Difference before and after is only in timestamps at the end, 
so I believe it is ok.
The change is minimal:
- added comments (how to build out of source & work with eclipse
- commented lines which caused the in source build

I comit the zproject_cmake.gsl
Can't git push.

What should I to do next, to finalize?
I'd like to go full circle, before I apply the curve patch.

Thanks in advance

Matjaž

On 10.4.2016 3:03, Osiris Pedroso wrote:
> Matjaz, checkout the zproject/tstgenbld.sh script.
>
> It does the generation, build and make test for a list of projects (czmq, 
> malamute, zyre).
>
> I think it would be simple to add some cmake targets to regen the sources if 
> zproject and gsl projects are on disk.
>
> As long as we don't wire to do it automatically as Pieter prefers, I think it 
> would be great to have it available for us newbies.
>
> Sent from my iPad. Regularly foiled by autocorrect. But duck it..
>
>> On Apr 9, 2016, at 14:35, Pieter Hintjens  wrote:
>>
>> On Sat, Apr 9, 2016 at 9:00 PM, Matjaž Ostroveršnik
>>  wrote:
>>
>>> "Source" and generated files in our solution are clearly separated and
>>> in different folders.
>> Not possible in our case due to independent layers of code generation,
>> often feeding into each other.
>>
>> E.g. in CZMQ, we have:
>>
>> * A tool that generates the socket option classes (zsock_option.gsl)
>> * A tool that generates the project packaging (zproject packaging targets)
>> * A tool that generates man pages from sources (mkman)
>> * A tool that generates server/client classes from state machine models 
>> (zproto)
>> * A tool that generates protocol codecs from protocol models (zproto)
>> * A tool that generates language bindings (zproject again)
>>
>> The outputs of one generator look like "normal" code to higher layers.
>>
>>> What is the top level build command in mlm case, which builds everything
>>> from sources to binaries and tests data?
>> All generated code is saved in the git repository, as you saw. The top
>> level command to rebuild generated models is `make code`, and then
>> `gsl project.xml`.
>>
>>> With mlm one needs to dig into generated sources and read the comments
>>> (I admit the are clearly marked). The problem is that at least one
>>> (maybe more) has two hops or more. (header file->api file->...) . Second
>>> hop was one  too much for me. ;-)
>> Yes, sorry. This is the price we pay for abstraction. FWIW the current
>> approach is significantly simpler than we've done in the past. We
>> don't have much meta.
>>
>>> I break the rule by intention (i.e. by updating the generated file),
>>> since I wanted to experiment. The experiment is over and I'd like to put
>>> the changes in proper places. That's the point where I am now, and
>>> unfortunately I am stuck.
>> Hmm.
>>
>>> That was my initial intention (i.e. I changed the CMake file; just few
>>> lines). ;-)
>> So, you need to untangle the various changes and then we can work
>> together to backport each one (if possible, sometimes it won't be).
>>
>> Start with the simplest one.
>>
>>> Can you (actually any of the product veterans): in form of short build
>>> instructions(part of the distribution)
>>> - provide a list of  "source" generated files
>> The models are (for our generation) always XML files, sometimes with
>> other extensions.
>>
>> The sources for other generation tools are arbitrary. E.g.
>> CMakeLists.txt, configure.ac, etc.
>>
>>> If the sources and generated files are clearly separated and completely
>>> integrated into the build procedure, then everything above in less
>>> important.
>> Not going to happen, sorry. There are tradeoffs, and one is to make
>> code generation at one level invisible to other levels. That's done on
>> purpose. Malamute has N classes, all in include and src. That's a
>> contract with all build tools that work on the project. Whether or not
>> some of those classes, or pieces of them, are generated is an internal
>> decision. It cannot be exposed at the structural level or we add
>> significant cost elsewhere, to layers that should not be paying it.
>>
>>> It would be nice if the build procedure...
>>> - would be completely inside the project structure (I understand that
>>> one building the mlm has to work with zproject project files also;
>>> correct me please if I am not right)
>> You can build Malamute without knowing anything about zproject.
>>
>> -Pieter
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Idiot guide to update mlm server project

Ok .Thanks.

On 10.4.2016 20:08, Pieter Hintjens wrote:
> See my answer to your previous email. When you want to talk to two
> servers (redundancy or failover), use two dealer sockets. In the Guide
> this is explained in the Harmony pattern, somewhere near the end.
>
> On Sun, Apr 10, 2016 at 7:56 PM, Matjaž Ostroveršnik
>  wrote:
>>   >You can build Malamute without knowing anything about zproject.
>> Ok. Thanks. That good news. I got information that I need to fix
>> something in zproject also. ;-)
>>
>>   >make code
>>
>>> gsl project.xml
>> Ok let's start here and see to where we can come. ;-)
>>
>> Thanks for help.
>>
>> BTW. I can't find a file with source code, where DEALER port selects socket 
>> to write to or read from (in case of multiaddress attach)
>>
>> Best regards
>>
>> Matjaž
>>
>>
>>
>> On 9.4.2016 21:35, Pieter Hintjens wrote:
>>> On Sat, Apr 9, 2016 at 9:00 PM, Matjaž Ostroveršnik
>>>  wrote:
>>>
>>>> "Source" and generated files in our solution are clearly separated and
>>>> in different folders.
>>> Not possible in our case due to independent layers of code generation,
>>> often feeding into each other.
>>>
>>> E.g. in CZMQ, we have:
>>>
>>> * A tool that generates the socket option classes (zsock_option.gsl)
>>> * A tool that generates the project packaging (zproject packaging targets)
>>> * A tool that generates man pages from sources (mkman)
>>> * A tool that generates server/client classes from state machine models 
>>> (zproto)
>>> * A tool that generates protocol codecs from protocol models (zproto)
>>> * A tool that generates language bindings (zproject again)
>>>
>>> The outputs of one generator look like "normal" code to higher layers.
>>>
>>>> What is the top level build command in mlm case, which builds everything
>>>> from sources to binaries and tests data?
>>> All generated code is saved in the git repository, as you saw. The top
>>> level command to rebuild generated models is `make code`, and then
>>> `gsl project.xml`.
>>>
>>>> With mlm one needs to dig into generated sources and read the comments
>>>> (I admit the are clearly marked). The problem is that at least one
>>>> (maybe more) has two hops or more. (header file->api file->...) . Second
>>>> hop was one  too much for me. ;-)
>>> Yes, sorry. This is the price we pay for abstraction. FWIW the current
>>> approach is significantly simpler than we've done in the past. We
>>> don't have much meta.
>>>
>>>> I break the rule by intention (i.e. by updating the generated file),
>>>> since I wanted to experiment. The experiment is over and I'd like to put
>>>> the changes in proper places. That's the point where I am now, and
>>>> unfortunately I am stuck.
>>> Hmm.
>>>
>>>> That was my initial intention (i.e. I changed the CMake file; just few
>>>> lines). ;-)
>>> So, you need to untangle the various changes and then we can work
>>> together to backport each one (if possible, sometimes it won't be).
>>>
>>> Start with the simplest one.
>>>
>>>> Can you (actually any of the product veterans): in form of short build
>>>> instructions(part of the distribution)
>>>> - provide a list of  "source" generated files
>>> The models are (for our generation) always XML files, sometimes with
>>> other extensions.
>>>
>>> The sources for other generation tools are arbitrary. E.g.
>>> CMakeLists.txt, configure.ac, etc.
>>>
>>>> If the sources and generated files are clearly separated and completely
>>>> integrated into the build procedure, then everything above in less
>>>> important.
>>> Not going to happen, sorry. There are tradeoffs, and one is to make
>>> code generation at one level invisible to other levels. That's done on
>>> purpose. Malamute has N classes, all in include and src. That's a
>>> contract with all build tools that work on the project. Whether or not
>>> some of those classes, or pieces of them, are generated is an internal
>>> decision. It cannot be exposed at the structural level or we add
>>> significant cost elsewhere, to layers that should not be paying it.
>>>
>>>> It would be nice if the build procedure...
>>>> - would be completely inside the project structure (I understand that
>>>> one building the mlm has to work with zproject project files also;
>>>> correct me please if I am not right)
>>> You can build Malamute without knowing anything about zproject.
>>>
>>> -Pieter
>>> ___
>>> zeromq-dev mailing list
>>> zeromq-dev@lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] adaptable net

Within your mail.

On 10.4.2016 20:07, Pieter Hintjens wrote:
> On Sun, Apr 10, 2016 at 7:42 PM, Matjaž Ostroveršnik
>  wrote:
>
>> What were conceptual reasons to make tracker as string? What is wrong with
>> some integer value (e.g. uint32/64)?
> Easier to generate guaranteed unique values, and messages that need
> this kind of reliability tend not to worry about efficiency. You can
> always store trackers as fixed size strings depending how you
> implement them (thus no allocation).
c strings end with binary zero. Binary trackers can have zeros in the 
middle, therefore on the path from client to worker and backwards some 
intermediate layer can simply strip contents after the zero, since type 
of the field is c string.
Maybe later on I'll ask you for explanation how to transfer strings 
through zmq without allocation/dealocation. ;-)
>
>> Any conceptual objection to extend the confirm message with a (possibly zero
>> length) blob?
> Sure, if you can tell me what problem you're solving (as usual). Just
> adding fields because they *may* be useful tends to make messy
> protocols.
I'd like to add blob in order to transfer back a reply to the service 
request. Sometimes it is not enough just simple answer I did it or it 
failed.
Normal communication in service usage is:
client: please do something with the provided data
worker: I did it, and the result of the service is the flowing data. 
(the following data is blob, that I proposed to add)
>
>> That is possible, but what about simple zsock_attach with several connect
>> addresses? Just simple change from connect to attach. ;-)
> I think zsock_attach already allows this:
Yes that's exactly wanted I wanted to say. If multi address connect 
could replace spawning 1+ actors and additional pipe, I would rather use 
multi address connect.
>
> ```
> //  Attach a socket to zero or more endpoints. If endpoints is not null,
> //  parses as list of ZeroMQ endpoints, separated by commas, and prefixed by
> //  '@' (to bind the socket) or '>' (to connect the socket). Returns 0 if all
> //  endpoints were valid, or -1 if there was a syntax error. If the endpoint
> //  does not start with '@' or '>', the serverish argument defines whether
> //  it is used to bind (serverish = true) or connect (serverish = false).
> ```
>
>> Each new thread is potential can of worms. I prefer not to use them unless
>> absolutely necessary. ;-)
> Actors are safe and easy to use.
I don't doubt in actor plumbing code. I am more affraid of the actor 
implementation code. E.g. not long ago I tried to start zauth actor 
within mlm_server, which was already actor. It crashed. Then I moved 
zauth actor to the main thread and just provided the address of the 
zauth to it, and it worked. I can not exclude my mistake, but simpler 
the code is, simpler it is debuged and maintained.
>
>> Is there a way to influence the selection of next server/router on DEALER?
>> As far I know it is round robin fashion only.
>> Perhaps some callback function on zsock_t which returns id of the next
>> socket to use?
> Use two or more dealer sockets, connect each one to a single router,
> and select the one you send to, explicitly.
I did it with Majordomo pattern and it worked, but it was all my code. :-)
I just wanted to piggy back on the existing zmq code. There must be 
definitely somewhere in the code a section which defines which next 
connection to use for send or recv. ;-)
>
> -Pieter
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Idiot guide to update mlm server project

 >You can build Malamute without knowing anything about zproject.
Ok. Thanks. That good news. I got information that I need to fix 
something in zproject also. ;-)

 >make code

>gsl project.xml

Ok let's start here and see to where we can come. ;-)   

Thanks for help.

BTW. I can't find a file with source code, where DEALER port selects socket to 
write to or read from (in case of multiaddress attach)

Best regards

Matjaž



On 9.4.2016 21:35, Pieter Hintjens wrote:
> On Sat, Apr 9, 2016 at 9:00 PM, Matjaž Ostroveršnik
>  wrote:
>
>> "Source" and generated files in our solution are clearly separated and
>> in different folders.
> Not possible in our case due to independent layers of code generation,
> often feeding into each other.
>
> E.g. in CZMQ, we have:
>
> * A tool that generates the socket option classes (zsock_option.gsl)
> * A tool that generates the project packaging (zproject packaging targets)
> * A tool that generates man pages from sources (mkman)
> * A tool that generates server/client classes from state machine models 
> (zproto)
> * A tool that generates protocol codecs from protocol models (zproto)
> * A tool that generates language bindings (zproject again)
>
> The outputs of one generator look like "normal" code to higher layers.
>
>> What is the top level build command in mlm case, which builds everything
>> from sources to binaries and tests data?
> All generated code is saved in the git repository, as you saw. The top
> level command to rebuild generated models is `make code`, and then
> `gsl project.xml`.
>
>> With mlm one needs to dig into generated sources and read the comments
>> (I admit the are clearly marked). The problem is that at least one
>> (maybe more) has two hops or more. (header file->api file->...) . Second
>> hop was one  too much for me. ;-)
> Yes, sorry. This is the price we pay for abstraction. FWIW the current
> approach is significantly simpler than we've done in the past. We
> don't have much meta.
>
>> I break the rule by intention (i.e. by updating the generated file),
>> since I wanted to experiment. The experiment is over and I'd like to put
>> the changes in proper places. That's the point where I am now, and
>> unfortunately I am stuck.
> Hmm.
>
>> That was my initial intention (i.e. I changed the CMake file; just few
>> lines). ;-)
> So, you need to untangle the various changes and then we can work
> together to backport each one (if possible, sometimes it won't be).
>
> Start with the simplest one.
>
>> Can you (actually any of the product veterans): in form of short build
>> instructions(part of the distribution)
>> - provide a list of  "source" generated files
> The models are (for our generation) always XML files, sometimes with
> other extensions.
>
> The sources for other generation tools are arbitrary. E.g.
> CMakeLists.txt, configure.ac, etc.
>
>> If the sources and generated files are clearly separated and completely
>> integrated into the build procedure, then everything above in less
>> important.
> Not going to happen, sorry. There are tradeoffs, and one is to make
> code generation at one level invisible to other levels. That's done on
> purpose. Malamute has N classes, all in include and src. That's a
> contract with all build tools that work on the project. Whether or not
> some of those classes, or pieces of them, are generated is an internal
> decision. It cannot be exposed at the structural level or we add
> significant cost elsewhere, to layers that should not be paying it.
>
>> It would be nice if the build procedure...
>> - would be completely inside the project structure (I understand that
>> one building the mlm has to work with zproject project files also;
>> correct me please if I am not right)
> You can build Malamute without knowing anything about zproject.
>
> -Pieter
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] adaptable net


It was superb concert and now back to business. :-)

On 9.4.2016 12:33, Pieter Hintjens wrote:

Too many questions at once :)

*teasing on*
Said by a person who writes thick books in its own free time. :-)
*teasing off*

- Async request-reply already works, using service requests, and
mailboxes for replies.
That's nice to hear. I noticed various interfaces, but I concentrated on 
service part only.

I'll check that.

- For reliability, there is already a "tracker" field in messages. My
intention was/is that recipients can send CONFIRMs back for specific
messages. These flow asynchronously, and allow senders to retry as
needed. See mlm_proto.xml.
I noticed that, but obviously I was not reading right comments. ;-) It 
seems to be the right stuff. :-)


What were conceptual reasons to make tracker as string? What is wrong 
with some integer value (e.g. uint32/64)?
This way we skip string space allocate/deallocate pairs on each stage of 
transfer. It is anyhow internal structure.


Any conceptual objection to extend the confirm message with a (possibly 
zero length) blob?


Client confirms reception of a message, or server forwards this
confirmation to original sender. If status code is 300 or 
higher, this

indicates that the message could not be delivered.
Message tracker




- If you need additional reliability layers I'd suggest writing this
in an application on top of Malamute rather than in the
protocol/server/client itself. Since you can embed mlm_server as a
thread, and talk to the broker over inproc:, you can embed routing
applications in the same process.
That is possible, but what about simple zsock_attach with several 
connect addresses? Just simple change from connect to attach. ;-)
Each new thread is potential can of worms. I prefer not to use them 
unless absolutely necessary. ;-)


Is there a way to influence the selection of next server/router on 
DEALER? As far I know it is round robin fashion only.
Perhaps some callback function on zsock_t which returns id of the next 
socket to use?

- As always, try to make small, incremental changes that can be proven
independently. Be wary, even paranoid, of your own ability to make
large-scale architectures. If you want to make large experiments, you
can certainly do this, yet it will always be hard to bring such
changes back into master.

Of course. :-)


-Pieter

On Sat, Apr 9, 2016 at 1:57 AM, Matjaž Ostroveršnik
 wrote:

Hi all,

In last days I am studying the mlm server architecture. Nice and clean
design. Congrats to the architects.

My objective is set to prepare adaptable net of nodes with client and worker
functionality (i.e. service pattern in mlm semantics) that
can communicate among themselves. It is always client (consumer of the
results of the service)-worker(provider of the service) communication, but
nodes have both client and worker functionality.

There is/are one or more brokers between clients and workers. Communication
goes client-broker-worker-broker-client. Brokers should be as simple as
possible.

A. Broker:

There are two or more brokers in the net.
Brokers hold no vital information. If one broker goes down (regular /
irregular shutdown) net must readapt. No payload is lost.
broker is go between clients and workers from the security reasons (clients
must not have direct access to the workers and vice versa)

brokers allow only connection of registered clients/workers

brokers distribute work between workers offering the same service (load
balancing)

e.g. round-robin

provide alternative paths between clients and workers.  (resistance to
failure)

C1->B1->W1->B1-C1 if there are several brokers the same pair C1/W1 can
communicate via different brokers, assuming that all  workers and all
clients are connected to all brokers.

source of information about other brokers in the net

i.e. client/worker connects to one predefined broker, periodically it
distributes the list of other brokers to its workers/clients
brokers have periodically "quorum" when they exchange information about them
selves (i.e. list of all active brokers)
initially each node is configured with at least one broker (others are
provided dynamically)
initially each broker is configured with at least one peer broker (is there
mechanism to make broadcast on WAN?)

B. Clients:

connected to one broker initially, gradually they "see" whole set of brokers
if one broker fails, client uses different path (via retransmitting the
message)
clients distribute work between brokers

C. Workers:

- each worker provides one service type
- there can be several workers offering the same service

D. Messages:

payload is opaque (size cca 4KB)
meta-data : sender, receiver, unique-msg id, possible duplicate, original
message id (for replys), retry cnt
if they are expired and until there is an option for retry client retries
them

E. Message exchange:

it is always initiated by the

Re: [zeromq-dev] Idiot guide to update mlm server project

2016-04-09 Thread Matjaž Ostroveršnik

Pieter,

Thanks for quick answer(s). Please find my feedback within your mail.

Best regards

Matjaž

On 9.4.2016 12:24, Pieter Hintjens wrote:
> On Fri, Apr 8, 2016 at 9:43 PM, Matjaž Ostroveršnik
>  wrote:
>
>> I managed to locally extend the mlm server with:
>> - ability to make out of source builds for cmake
>> - support for blobs for service interface
>> - curve support
> Nice stuff :)
>
> I'm writing a book on how the development process for pieces like
> Malamute works, at scalable-c.com. It's still in progress, but what
> there already is may help.
I'll check. You are really writing a lot. :-)
> There are a few ground rules. You've been editing files that were
> generated, and they quite clearly say so, in their header. When you do
> this, you are writing throw-away code.
>
> This is always the tradeoff with code generation. More power, yet
> harder to learn.
I am aware of benefits of the code generation.
*bragging on*
I developed a generator for database abstraction layer. The code it 
generates is in use with 80+ customers within financial industry. Few 
implementations are important even on the state level (in different 
countries).
*bragging off*
"Source" and generated files in our solution are clearly separated and 
in different folders. Generated files are all the same (e.g. generated 
source files or let me say object file produced by the compiler) from a 
build process point of view.
The build procedure uses this generator, but when you say make (i.e. 
cmake) everything is within the build procedure (e.g. source file 
generation, compilation, linking etc.). In cmake file of mlm I saw only 
compiling of the sources but without source generation.

What is the top level build command in mlm case, which builds everything 
from sources to binaries and tests data?

With mlm one needs to dig into generated sources and read the comments 
(I admit the are clearly marked). The problem is that at least one 
(maybe more) has two hops or more. (header file->api file->...) . Second 
hop was one  too much for me. ;-)

I break the rule by intention (i.e. by updating the generated file), 
since I wanted to experiment. The experiment is over and I'd like to put 
the changes in proper places. That's the point where I am now, and 
unfortunately I am stuck.
> You need to learn two main tools: zproto and zproject. Each has a set
> of code generators, each producing a set of outputs from one or more
> input "model" files. It is quite flat, little abstraction, so easy to
> learn.
>
> E.g. to change the client state machine you edit mlm_client.xml. (And
> again, it says this clearly in the header of mlm_client_engine.inc!)
> and then you run "make code" to regenerate.
>
> The second thing is, one change at a time. Start with the simplest
> change, get a PR, learn the process, and then move to the next change.
> Don't come to a project with a large change set, or people will
> probably refuse it (and that's in our C4 process).
That was my initial intention (i.e. I changed the CMake file; just few 
lines). ;-)
> If you find a generated file that does not clearly state its origin,
> tell us and we'll fix it.
I completely understand your position, but please do not forget, that 
you conceived, designed and gradually implemented the build procedure 
like it is now, and everything is clear and understandable / explainable 
for you. Have in mind poor rookies like me, who do not have such prior 
knowledge.

Can you (actually any of the product veterans): in form of short build 
instructions(part of the distribution)
- provide a list of  "source" generated files
- with each file from this list provide additional data:
   - what is the ultimate source for the file (we saw that some has more 
than one hop)
   - what is the command to convert the ultimate source file into this file
You can go also in inverted direction (i.e. A generates B,C,D, where 
A->B uses program P1, A->C is using program P2, etc)
Then it is on rookie to find the description of the generator language 
to be able to fix the A in a proper way. ;-)

If the sources and generated files are clearly separated and completely 
integrated into the build procedure, then everything above in less 
important.

It would be nice if the build procedure:
- would be completely inside the project structure (I understand that 
one building the mlm has to work with zproject project files also; 
correct me please if I am not right)
- all build time generated files (e.g. generated sources, object files, 
...) separated and not mixed with real sources like they are now.

This way newbies like me would have much lower learning curve.
BTW for second line above I am more that willing to take cmake part of 
(re)work on me.

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] adaptable net

2016-04-08 Thread Matjaž Ostroveršnik


Hi all,

In last days I am studying the mlm server architecture. Nice and clean 
design. Congrats to the architects.


My objective is set to prepare adaptable net of nodes with client and 
worker functionality (i.e. service pattern in mlm semantics) that
can communicate among themselves. It is always client (consumer of the 
results of the service)-worker(provider of the service) communication, 
but nodes have both client and worker functionality.


There is/are one or more brokers between clients and workers. 
Communication goes client-broker-worker-broker-client. Brokers should be 
as simple as possible.


A. Broker:

1. There are two or more brokers in the net.
2. Brokers hold no vital information. If one broker goes down (regular
   / irregular shutdown) net must readapt. No payload is lost.
3. broker is go between clients and workers from the security reasons
   (clients must not have direct access to the workers and vice versa)
1. brokers allow only connection of registered clients/workers
4. brokers distribute work between workers offering the same service
   (load balancing)
1. e.g. round-robin
5. provide alternative paths between clients and workers. (resistance
   to failure)
1. C1->B1->W1->B1-C1 if there are several brokers the same pair
   C1/W1 can communicate via different brokers, assuming that all 
   workers and all clients are connected to all brokers.

6. source of information about other brokers in the net
1. i.e. client/worker connects to one predefined broker,
   periodically it distributes the list of other brokers to its
   workers/clients
2. brokers have periodically "quorum" when they exchange
   information about them selves (i.e. list of all active brokers)
3. initially each node is configured with at least one broker
   (others are provided dynamically)
4. initially each broker is configured with at least one peer
   broker (is there mechanism to make broadcast on WAN?)

B. Clients:

1. connected to one broker initially, gradually they "see" whole set of
   brokers
2. if one broker fails, client uses different path (via retransmitting
   the message)
3. clients distribute work between brokers

C. Workers:

1. - each worker provides one service type
2. - there can be several workers offering the same service

D. Messages:

1. payload is opaque (size cca 4KB)
2. meta-data : sender, receiver, unique-msg id, possible duplicate,
   original message id (for replys), retry cnt
3. if they are expired and until there is an option for retry client
   retries them

E. Message exchange:

1. it is always initiated by the client part of the node and goes to
   the service worker, which replys
2. if message is not return in predefined period of time (msg exchange
   timeout) it is retried (predefined number of retries)
3. client can select the broker to send the message through, but worker
   always returns message via arriving path(broker)
4. message exchange C-B-W-B-C is fast (sub seccond)

Current mlm server is by my opinion platform for this task. Am I too 
optimistic?

Existing functionality:
  - A.1-2
  - A.4 (?) believe so
  - C.*
  - E.1 (how to do reply?)
  - E.3-4
Already added functionality:
  - A.3.1 (curve)
  - D.1  (blobs)
TODO functionality:
  - A.5
  - A.6 (the toughest stuff)
  - B.1-3
  - D.2-3
  - E.2

Questions:

1. Async request-reply pattern. Is it already supported? Code talks
   about replys, but I am unsure. Hints?
2. D.2-3, E.2: Is current message (mlm_msg_t) suitable for expansion
   (e.g. unique-id, original-unique-id, retry-cnt)?Or should I do it in
   some other way?
3. A.5: clients / workers should connect to different brokers (e.g.
   array of mlm_client actors )
4. A.6: Currently I do not have solution for A.6. Is zgossip the right
   solution?
5. B.1-3 - Strictly related to A.6 solution

What is your opinion on this?
Would you do something in a different way?
How you would tackle A.6?

Thanks in advance

Matjaž

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] Idiot guide to update mlm server project

2016-04-08 Thread Matjaž Ostroveršnik

Dear all,

I managed to locally extend the mlm server with:
- ability to make out of source builds for cmake
- support for blobs for service interface
- curve support

All tests went smooth. :-)

During the upgrade I changed:

CMakeLists.txt

include/mlm_client.h

include/mlm_server.h

src/malamute.c

src/mlm_client.c

src/mlm_client_engine.inc

src/mlm_perftest.c

src/mlm_server.c

src/mlm_server_engine.inc

and added

 debug_build.sh  --- cmake -> make for release version

 release_build.sh--- cmake -> make for debug version

 src/mlm_tutorial_curve.c--- test / tutorial program for mlm 
curve


I noticed that "include/mlm_client.h" is generated from 
api/mlm_client.api and api/mlm_client.api is generated from mlm_client.xml.
It is a similar story with other files.

Osiris kindly provided me bunch of links and instructions. I went 
through, but it is really a lot of reading. I managed to install 
zproject and gsl. I am not sure what to do next. Complete git diff is 
750 lines.

Guys I need idiot proof short guide (with commands) how to merge the 
changes into the project and transport it to the github.
I believe that there generators are great in big picture, but they are 
obstacles for me now. :-(

Please help me.

Best regards

Matjaž
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Test failing on OS X 10.9.4


Hi Osiris,

Which time zone you are living in? You are non stop on-line. Thanks, I 
appreciate your fast check.

What are those 4 failed tests?
I don't remember touching them.

Best regards

Matjaž

On 6.4.2016 19:45, Osiris Pedroso wrote:

Lucky you,

Ubuntu 14.04 results:


Testsuite summary for zeromq 4.2.0

# TOTAL: 78
# PASS:  74
# SKIP:  0
# XFAIL: 0
# FAIL:  4
# XPASS: 0
# ERROR: 0

See ./test-suite.log
Please report to zeromq-dev@lists.zeromq.org 




FAIL: tests/test_term_endpoint
==

lt-test_term_endpoint: tests/test_term_endpoint.cpp:136: int main(): 
Assertion `rc == 0' failed.


FAIL: tests/test_ipc_wildcard
=

lt-test_ipc_wildcard: tests/test_ipc_wildcard.cpp:41: int main(): 
Assertion `rc == 0' failed.


FAIL: tests/test_xpub_manual


lt-test_xpub_manual: tests/test_xpub_manual.cpp:108: int 
test_xpub_proxy_unsubscribe_on_disconnect(): Assertion `zmq_bind 
(xsub_proxy, frontend) == 0' failed.


FAIL: tests/test_filter_ipc
===

lt-test_filter_ipc: tests/test_filter_ipc.cpp:100: void run_test(int, 
T, int, int) [with T = int]: Assertion `rc == 0' failed.


On Wed, Apr 6, 2016 at 5:14 AM Shital Mehta > wrote:



   zeromq 4.2.0: ./test-suite.log


# TOTAL: 78
# PASS:  77
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: tests/test_shutdown_stress


Invalid argument (src/stream_engine.cpp:136)

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org 
http://lists.zeromq.org/mailman/listinfo/zeromq-dev



___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] malamute CMake & eclipse & service blobs


Hi Osiris,

Thanks for the info. I'll try to dig into, to understand it.
If you are in Rome, do like Romans do. ;-)

After I am through, I'd really ask you to walk me through the procedure 
for the first time, so that I won't make some major mistake.


In the meantime I added two methods for service communication to the 
client. It works. :-)


// 
---

//  *** Draft method, for development use, may change without warning ***
//  Send blob to service
//  Returns 0 if OK, -1 if failed due to lack of memory or other error.
MLM_EXPORT int mlm_client_svc_send_chunk
(
mlm_client_t *self,
const char *address,
const char *subject,
zchunk_t*   content
);
// 
---

//  Receive a subject and zchunk content from the server.
//  This method is orthogonal to the mlm_client_svc_send_chunk.
//  Returns 0 or -1 in case of error. Free the returned
//  subject and content when finished with them. To get the type of
//  the command, use mlm_client_command ().

MLM_EXPORT int mlm_client_svc_recv_chunk
(
mlm_client_t *self,
char **subject_p,
zchunk_t** content
);
Basically the methods allow sending blobs (zchunk_t*) between client and 
worker.


What is the procedure for the new features inclusion?
- what are the steps
- who is approving?

Who is working on security? Am I right that malamute server does not 
support the curve yet?

Has somebody tried to integrate more traditional PKI into zmq?

Thanks in advance

Matjaž

On 6.4.2016 18:40, Osiris Pedroso wrote:

Hi Matjaz,

Read the zproject/README.md and look for the section *Tips for 
modifying generated files in an already existent project 
<https://github.com/opedroso/zproject#toc2-94>*


Seems like every zeromq project that has a project.xml in its home 
directory has some portion of its code/scripts automatically generated.
The source of these generated files live in zeromq/zproject project 
and they have extension .GSL.


There is another project, imatix/gsl that contains the GSL program 
that will use the .GSL files referenced by your target project i.e. 
zeromq/malamute/project.xml to generate the output code/scripts for 
that process.


I have been trying to undertstand that process of late as well, and I 
wrote the script zeromq/zproject/tstgenbld.sh which will apply the 
current .GSL files in zeromq/zproject on my disk on several projects 
(CZMQ, ZYRE and MALAMUTE), regenerating them, then building and 
running their automated tests.


This way, I can automate testing the current build, then testing the 
modified build once I drop my modified .GSL files in my 
zeromq/zproject disk location.


If you want to make the changes you suggested in your previous email, 
provide me with the before and after CMakeLists.txt file you made and 
I will help you modifying the generating .GSL to generated your new 
version automatically.


Then you can test and if you like it, a submit a PULL REQUEST 
submitting to the project.


Hope this helps,
Osiris

On Wed, Apr 6, 2016 at 8:29 AM Matjaž Ostroveršnik 
mailto:matjaz.ostrovers...@gmail.com>> 
wrote:


Thanks for quick reply.
I am a novice and I need a longer explanation.

I cloned zproject and went through the file. Some strange syntax
;-) Mixture of cmake and something else (i.e. dot commands).
What is the purpose of this? Isn't cmake declarative enough, so
that this conditional generation can be skipped?

I know exactly what to change in CMakeLists.txt file, but I do not
know the syntax of the gsl file to fix it there.

Do you think that out of source cmake builds is something that
malamute development team needs? If it is only for me, I can stick
with the existing solution. ;-)

How is zproject related to malamut project?

Best regards


Matjaž


On 6.4.2016 14:55, Osiris Pedroso wrote:


Here is the process to find out which file creates any generated
file:

 1. get the name of file you are interested
 2. clone zeromq/zproject
 3. search for the filename you are interested in *.gsl:

|O:\git\zproject>findstr /c:CMakeLists. txt *.gsl
zproject_cmake.gsl:.output "CMakeLists.txt"
zproject_java.gsl:.output "$(topdir)/CMakeLists.txt"
zproject_java.gsl:.output "$(topdir)/android/CMakeLists.txt" |

So in your case, I believe zproject/zproject_cmake.gsl is the
    file that generates it


On Wed, Apr 6, 2016 at 7:38 AM Matjaž Ostroveršnik
mailto:matjaz.ostrovers...@gmail.com>> wrote:

Hi all,

I am in process of experimenting with malamute. In order
to play with it, the development environment needs to be
configured.
Below is my experience with malamute & eclipse & cmake.

Re: [zeromq-dev] malamute CMake & eclipse


Thanks for quick reply.
I am a novice and I need a longer explanation.

I cloned zproject and went through the file. Some strange syntax ;-) 
Mixture of cmake and something else (i.e. dot commands).
What is the purpose of this? Isn't cmake declarative enough, so that 
this conditional generation can be skipped?


I know exactly what to change in CMakeLists.txt file, but I do not know 
the syntax of the gsl file to fix it there.


Do you think that out of source cmake builds is something that malamute 
development team needs? If it is only for me, I can stick with the 
existing solution. ;-)


How is zproject related to malamut project?

Best regards

Matjaž

On 6.4.2016 14:55, Osiris Pedroso wrote:


Here is the process to find out which file creates any generated file:

 1. get the name of file you are interested
 2. clone zeromq/zproject
 3. search for the filename you are interested in *.gsl:

|O:\git\zproject>findstr /c:CMakeLists.txt *.gsl 
zproject_cmake.gsl:.output "CMakeLists.txt" zproject_java.gsl:.output 
"$(topdir)/CMakeLists.txt" zproject_java.gsl:.output 
"$(topdir)/android/CMakeLists.txt" |


So in your case, I believe zproject/zproject_cmake.gsl is the file 
that generates it



    On Wed, Apr 6, 2016 at 7:38 AM Matjaž Ostroveršnik
mailto:matjaz.ostrovers...@gmail.com>> wrote:

Hi all,

I am in process of experimenting with malamute. In order to
play with it, the development environment needs to be configured.
Below is my experience with malamute & eclipse & cmake.
Perhaps someone can shorten his/her environment establishing
time. :-)




___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] malamute CMake & eclipse