DSS priorities

[sjmackenzie]

I believe that there is a priority sequence that needs to be addressed in order to get beernet up and running asap.

1. Connection module
2. Distributed Ports

What would you regard as the proper sequence?

[sjrd]

The Connection module is the core of the DSS. It must be implemented first. Its first iteration should be able to transmit stateless entities (i.e., entities that can be pickled). Distributed Ports can come as a second iteration.

[ggutierrez]

Hi Guys,

I have a probably silly opinion on this regard. It seems that the connection module is the core of a lot of things that are related to the distribution. I know that ports in Oz have some guarantees regarding message exchange and things like that. Would not be easy to get a prototype of the complete distribution subsystem if we use zeromq sockets?. I know that we are not planning to include zeromq as a dependency of Mozart. However, the sockets provided by that library offer also some properties on messages delivery. If we do that we could have more contributions on the distributed subsystem and less people waiting for Ruma (or others) to finish the connection module.

I think that there are some very interesting things about that library that we should consider (at least for reference). For instance, a socket can transparently use inter process communication when used by processes of the same machine. I don't think we have that in the previous system and that sounds really appealing.

What do you think?

Cheers,

Gustavo Gutiérrez

El jueves, 21 de febrero de 2013 a las 12:37, Sébastien Doeraene escribió:

The Connection module is the core of the DSS. It must be implemented first. Its first iteration should be able to transmit stateless entities (i.e., entities that can be pickled). Distributed Ports can come as a second iteration.

—
Reply to this email directly or view it on GitHub (#10 (comment)).

[bmejias]

Hi guys,

Since beernet was mentioned, I have one comment and two questions.

Comment: The only distributed entity I used in Beernet is the distributed
port. I don't use any distributed variable. I only send values through
ports.

Now to the questions.

I'm planning to reimplement Beernet using classes. I have noticed that the
implementation using procedures is not that simple to understand to others.
Beernet is implemented as a OOP/component-based, but kind of home-made
using procedures, so it has a couple of workarounds to provide default
events to components, which can be achieved easier with the class-based
objects support in Mozart. I was never entirely convinced by the OOP syntax
in Oz, that's why I implemented it with closure-based objects. but I
believe that a implementation with class-based notation could be better to
have more contributors to Beernet. Anyway, being that said, here I come
with my questions:

1. Is the there any difference in OOP in Mozart 2? Same syntax? Same
   semantics?
2. How can I get started with Mozart 2? I want to have it running on my
   system so that I can start with the re-implementation of Beernet, and
   fixing some bugs on the current Beernet targetting Mozart 2.

that's it for now,
cheers
Boriss

On Thu, Feb 21, 2013 at 6:21 PM, Stewart Mackenzie <notifications@github.com

wrote:

I believe that there is a priority sequence that needs to be addressed in
order to get beernet up and running asap.

1. Connection module
2. Distributed Ports

What would you regard as the proper sequence?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10.

[sjrd]

Hi Boriss!

1. Is the there any difference in OOP in Mozart 2? Same syntax? Same semantics?

Same syntax, same semantics. The implementation at the VM level is different though, but you probably don't need to know that.

1. How can I get started with Mozart 2? I want to have it running on my system so that I can start with the re-implementation of Beernet, and fixing some bugs on the current Beernet targetting Mozart 2.

If you don't want to build from source, start with the binary packages available on SourceForge:
https://sourceforge.net/projects/mozart-oz/files/?source=navbar
Just unpack anywhere you want and add /bin to your path. You'll need to install Emacs and Tcl/Tk 8.5 separately. (If your distribution uses Tcl 8.6, I'm afraid you have to build from source, for now - see the Readme which is quite comprehensive).

Then in /bin you have the three usual executables: ozc, ozengine and oz.

[bmejias]

On Sat, Feb 23, 2013 at 11:59 PM, Sébastien Doeraene <
notifications@github.com> wrote:

Hi Boriss!

1. Is the there any difference in OOP in Mozart 2? Same syntax? Same
   semantics?

   Same syntax, same semantics. The implementation at the VM level is
   different though, but you probably don't need to know that.

OK. Thanks Sébastien for the prompt reply.

1. How can I get started with Mozart 2? I want to have it running on
   my system so that I can start with the re-implementation of Beernet, and
   fixing some bugs on the current Beernet targetting Mozart 2.

   If you don't want to build from source, start with the binary packages
   available on SourceForge:
   https://sourceforge.net/projects/mozart-oz/files/?source=navbar
   Just unpack anywhere you want and add /bin to your path. You'll need to
   install Emacs and Tcl/Tk 8.5 separately. (If your distribution uses Tcl
   8.6, I'm afraid you have to build from source, for now - see the Readme
   which is quite comprehensive).

Then in /bin you have the three usual executables: ozc, ozengine and oz.

It's looking good. Downloaded, untar, I'm using tcl 8.4 and 8.5, so no
problem there.
cd beernet
make
sources compiled, although the test code, and some of the utilities use
OS.system to launch other mozart processes. I guess I can let the utilities
wait a bit on that, and rewrite the test to just use local ports in
simulation mode, so that I don't need OS.system.

By the way... is this the new hackers mailing list the facto?

cheers
Boriss

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-13999786.

[sjmackenzie]

Dear all.

Anything below a socket is fair game, anything above the socket level has
to be in 'reflective' oz. that's our over arching constraint on developing
the DSS (correct me if im wrong). That ascertained lets move forward. This
below text is below socket level or in some contorted way, related. Your
bellows huff.

It so happens something out there fits the bill. Sustrik (the founding
developer of zeromq) has lanced out and created nanomsg. This is a tight c
based library with no dependencies, compiles in some 2.3 seconds, has a cpp
binding (one file only) that can be included into our project. Nanomsg
pulls in all those years of zeromq experience, yet makes it flexible and
easy to try new things - a fresh start, so to say.
The project uses X/11, which means we may easily include it into our
project.

Though nanomsg hasn't built much of a community. So in the long run it is
susceptible to companies targeting it, or should Sustrik decide to drop
the project we real have issues.

Take it for a spin http://www.github.com/250bpm/nanomsg . Read his blog
www.250bpm.com he speaks sense.

A fresh start might not be good, because we forego lively, sprawling,
eye-balling zmq community.

Zeromq: has carefully set up a process that places the community above all.
Indeed, one that the oz community are evolving into. The zmq community as a
whole own the software, and their lgpl3 prevents patent troll attacks - and
direct inclusion into oz. Vendor locking prone vendors will have a hardtime
locking down zmq. As it has the conditions to outlast and adapt to pretty
much anything. From this point of view it is a veritable Sun Tzu Art of
Software War. For this reason, I recommend zeromq - if we make a mistake
it'll be on this point.

Raw sockets: is good, because we have one less build dependency. Given that
oz and nanomsg both use cmake and git, and that nano compiles in a couple
of seconds, its negligible. Though, I believe we would be unwise if we went
the raw socket way. Somebody please enlighten me if you see otherwise.

We plan to create nanomsg-oz bindings and amend the Open.oz library, or
indeed create a new one. This gives us fast asynchronous io, framing, no
longer will oz clog the network card, messaging patterns, faster than
zeromq messaging and a very simple socket interface. I believe the API
given to us will allow us to easily implement distributed oz entities.

I lean towards @ggutierrez suggestion of implementing a prototype first with zeromq/nanomsg.

Work starts month end so it'll be great to hear your concerns.

[sjrd]

By the way... is this the new hackers mailing list the facto?

Hum ... yep, it seems so.

Regarding zmq, nanomsg, or anything similar. May I ask the following question: "What does [the said library] offers that 1) raw sockets do not provide and 2) that we need?

Also, if the consensus is to introduce a new library for networking abstraction in Mozart 2, then: make sure it fits well in the lightweight threads+asynchronous I/O events scheme. The way boostenv is articulated around Boost ASIO is far from being random. All builtins that perform I/O create an asynchronous request to be performed by ASIO, and return immediately with a dataflow variable that will hold the result. This ensures that other lightweight threads can continue to execute while one is "blocking" on the I/O. Upon completion of the asynchronous handler, the dataflow variable is bound to the actual result, which wakes up any thread waiting on that variable. The whole scheme presents a very natural abstraction over asynchronous I/O, so that Oz code need not care about blocking issues. It was not the case in Mozart 1.

[sjmackenzie]

Kenny and I just had a long skype session with Sébastien . (Thanks, Sébastien for sharing your time and knowledge)

It would so seem that we do not need all the functionality associated with zeromq and nanomsg.
The DSS is so oz specific that most of those features... if not all of those features will be wasted.

So we'll do an implementation on raw TCP sockets.

Although for your reading pleasure please read: http://www.aosabook.org/en/zeromq.html for some finer details on the architecture.

Also a point that I should raise. Kenny implemented a zeromq binding for Mozart1. This triggered strange errors that arose due to interacting with oz lightweight threads. So it isn't worth expending effort solving those issues when they are clearly solved by Sébastien's asynchronous handler. All that is left is opening a connection, which can be done with raw sockets anyway.