Windows/MSVC support and on-flow ideas about libmill HOT 24 CLOSED

Nice work!

As for the go() part, why not create a pull request? Don't forget to state it's MIT licensed, please, so that I can merge it without licensing issues.

As for choose syntax and typed channels, I've deliberately tried to make the syntax as simple and golang-like as possible. After all, it's a convenience library, so the usability should be goal no.1. Having to specify the type in each command sucks, but it sucks less than having to declare a new type for each kind of channel you want to use.

As for the problem with goto labels, I can re-write the code so that it doesn't use them. It will still need COUNTER gcc-ism but that's supported by MSVC as well.

What do you think?

from libmill.

Interesting.

I kind of like the typed channels as it gives you a certain amount of type safety. In small examples I get your point that not having to type them is useful, but with anything larger than that things start to become a bit unwieldy making sure that you use the right types on the send and receive side.

Maybe I have a slightly different definition of usability than you. Typically I find magical constructs to be annoying and the closer you can make the API match the natural language the better. Otherwise you miss one bit and you get the craziest compile errors imaginable. My personal take would be to not try and match the go syntax correctly (and lets face it you can't), but rather to use the same concepts but in a more C like manner. That way people are less surprised by magic stuff and their effect on break, continue, compilation errors, etc. In this regard the go command isn't too magical, but the in, out, and end are supremely magical.

I'm curious: how would you remove the goto labels, but keep the current API? The reason I suggested the switch statement is that I couldn't think of a different way of moving between multiple code blocks where the setup and jump to was in the same line.

from libmill.

Well, why not use libtask then? It's as C-idiomatic as it can possibly get and functionally it matches mill.

As for the goto labels, the idea is something like this:

int res = -1;
while(1) {
    if (res != -1) {
       goto label1;
   }
   mill_in(...);
   if(0) {
       label1:
       if(res == 1) {
           // code from clause1
          break;
       }
       goto label2;
   }
   mill_out(...);
   if(0) {
      label2:
      if(res == 2) {
          // code from clause2
          break;
      }
   }
   res = mill_wait(...);
}

from libmill.

That being said, if you have an idea of how to allow for typed channels without having to invent a new name for each channel type, I'm all for it. Type-safeness <3

from libmill.

Thanks. I'll give the goto labels a try.
Moving the res = mill_wait up to the top would have the advantage of not needing the end macro.
Just had a look at libtask ... interesting, but the API is fairly clumsy.

from libmill.

Ok, the code now doesn't use goto labels. Let me know whether it helped with your MSVC work.

from libmill.

Thanks I'll have a look at it next weekend. I'm out of office this week.
On May 3, 2015 1:35 PM, "sustrik" [email protected] wrote:

Ok, the code now doesn't use goto labels. Let me know whether it helped
with your MSVC work.

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

from libmill.

any chance we can get a CMakeLists.txt for windows like nanomsg? ty :)

https://github.com/nanomsg/nanomsg/blob/master/CMakeLists.txt

from libmill.

Sure, why not, but it's only the tests that's built at the moment.

from libmill.

CMake build is in place now.

from libmill.

oops - i thought this was nanomsg.. my bad. ignore comments below. will test mill.. think it can replace some of my nanomsg "inproc" stuff, with mill

/*
yes.. ty!!! i've been using it. curious about the Statc vs Share lib, and the NN_EXPORTS and NN_EXPORT .. looks like TTimos branch has different strategy for this.

also btw: sometimes "tcp_shutdown" and "timeo" do fail... not sure exactly, could be only when compiled x86 and Static lib. will put an issue if/when i can recreate
*/

from libmill.

Inactive for several months. Closing it. Reopen as needed.

from libmill.

Doesn't build on Windows

from libmill.

Not supposed to.

from libmill.

Any plans to port this to win? It would be HUGE. We don't dev on Win and don't like it, but all of our customers run it so we have to support it. We would be happy to help in the porting to the extent we have resources to do so. Is there a specific / known list of issues that if solved would enable porting (and more specifically, building with mingw64 tools)

from libmill.

You can give it a try. IIRC there's no poll() on Windows. Take poll.inc and rewrite it using select(). Fix other compilation errors. See whether it works.

from libmill.

will take a look thx. looking at a sigsetjmp port unless you know of one already

from libmill.

Use setjmp() instead of sigsetjmp() and longjmp() instead of siglongjmp().

from libmill.

ok thx. on to resource.h...

from libmill.

You won't need it on windows. It's used only in epoll.inc and kqueue.inc and you are going to create your own select.inc anyway.

from libmill.

moving to getrlimit. also, switching to your libdill, to try and solve what appears to be a smaller universe of problems first before the wider one of libmill. sound about right?

from libmill.

getrlimit = resource.h. Same answer as above. As for libdill, as you wish, but notice there's no networking library there.

from libmill.

@mewalig how's progress?

from libmill.

I got through the part that overlaps with libdill-- you can see what I've done in a diff file I attached to a comment to sustrik/libdill#18. have not finished fixing the remaining parts, including incompatibilities in dns/dns.c and other networking-related parts. If anyone would like to pitch in, lmk and I will open a fork or at least send a patch of what I have so far

from libmill.