libev and libevent

Marc Lehmann schmorp at schmorp.de
Wed Feb 21 04:21:25 CET 2018


On Wed, Feb 21, 2018 at 07:03:21AM +0800, Andy Green <andy at warmcat.com> wrote:
> > Maybe you can borrow some ideas or even some code from them.
> 
> Maybe you can fix your library headers.  Or maybe not.

Just out of curiosity, which of Harald's libraries are you refering to?

On Wed, Feb 21, 2018 at 07:26:03AM +0800, Andy Green <andy at warmcat.com> wrote:
> > 
> > Anyhow, I don't think this is the right place for introductory programming
> 
> You brought this subject up.

I pointed at a solution to your problem, which you claimed isn't a
solution because your prtogramming skills weren't good enough to be
familiar with it, after which I either had the choice of leaving you
or teach you about this technique i more detail. Opaque types and data
hiding is a very standard technique used in almost all libraries, so
it's not really a libev thing, thus the reference to the "introductory
programming", because that is what it is, a basic technique in C
programming.

So, if by "you brought this up" you mean "you tried to help me with my
problem" then you are spot on.

> > Quite possibly, lws_ev_io_watcher could even be identical to
> > struct ev_io, and with some work, it doesn't even have to be a pointer, and
> > lws_ev_watcher might not need to be a separate data type either.
> 
> That is the first constructive suggestion, thanks.

The thread is full of constructive suggestions, it's just that you were
unable or unwiling to understand and/or apply them.

> It adds another layer of indirection.  But actually that is probably a
> good idea.

It also incidentally shows most of the strongly worded and derisive claims
you made to be untrue. What are your thoughts about that?

> > > However you cannot compose an opaque / forward-referenced struct into
> > > another struct with type safety, because the size of the undefined thing is
> > > unknown.
> > 
> > Yes, you can, multiple ways.
> 
> Note the word "compose" has a specific meaning here...

... a meaning which you won't explain here, so this is a useless comment,
because nobody knows what's going in on your mind. What I said is
certainly true.

> > Again, not trivial, but what you are trying to do is hardly typical.
> 
> All of these event loop things are contributed.  I don't think any of these
> extreme tricks to workaround your header clash problem will help with
> maintainability or source code clarity.

None of these "extreme" tricks as you call them are needed, either, mind you.

> > To say it bluntly, you come about as very tight-lipped about your needs
> > and a bit arrogant, when considering that your programming skills are
> > comparatively limited, given you are quite troubled by even simple
> > abstraction problems in C...
> 
> Wow!  You are living down to my expectations :-)

If by that you mean "I attack you and then you call me out, and I totally
expected that" then there is nothing surprising about it indeed.

> > Both Harald and I have tried to help you, and it would suit you well if you
> > would explain your problem a bit more and would use rational arguments
> > instead of shouting at people...
> 
> No... you preferred to attack the user and find a way that nothing needed to

You are very deluded - you used ad hominems instead of rational arguments
almost form the very beginning. I merely pointed out that your progamming
skills are lacking and your tone is arrogant, certainly in relation to your
actual skills - again, it would become you well to show a bit more humility
and learn from people who, clearly, know better how to design APIs and
implement data hiding than you do.

What you are doing is projecting your own attacks on others, but that doesn't
make it true.

Even if you can't show any humility or the will to learn, you should
certainly use rational arguments instead of hand waving, shouting, and making
stuff up just to disagree.

> change on your side, even when a comparable, more popular library has no
> problem with its header hygiene doing the same thing.

Nothing in this thread is about what any reasonable person would call
"header hygiene". The fact that libev provides a libevent-compatible API
and therefore also provides its, well, public API symbols is construed by
you to be some header hygiene problem. You clearly either don't understand
what header hygiene means or you are misusing it on purpose.

This is just another example of a non-rational made-up argument without any
merit or even content.

> As I said I will just leave it unselectable for choose-at-runtime in cmake -
> and suggest people avoid using libev.

You of course didn't say this before, but that's an entirely rational
solution if you are incapable of solving this problem yourself. I.e.
giving up when your skills are not up tp the job is probably the best
solution, also for your users.

It's also fine to suggest people to avoid using libev - libev was always
provided "as is", and certainly is a tool for experts and not beginners,
and anybody making thier event loop selection based on misunderstanding
of basic programming techniques is probably better of with other event
libraries, although I am not sure what those would be.

In any case, you are clearly only intersted in trolling and not interested
in solving your problem, so I regret having tried to help you.

Good luck for your futgure endeavours and good bye.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\



More information about the libev mailing list