Comments (24)
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.
Related Issues (20)
- udpsend error in mac os HOT 10
- is it right to pass channel as channel message ? HOT 1
- library not found for -lmill HOT 1
- too slow HOT 1
- Conan package HOT 1
- socket leak on tcpconnect() timeout
- Wait for any event in event loop HOT 1
- please implement fdwait(FDW_ERR)
- Description of primitives without synchronization HOT 3
- tests/ip hangs HOT 7
- [install] make FAILS HOT 2
- implicit declaration of function 'asm' is invalid in C99
- FTBFS: dns/dns.h:1009:24: error: lvalue required as unary '&' operand HOT 2
- segment fault on osx HOT 1
- More compiler issues...
- Suggetion rename API for chdone/chclose
- many warnings compile with clang
- Is this maintained anymore? HOT 1
- libmill.org parked
- Deprecate, archive, and suggest libdill? HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from libmill.