Rationale behind removal of DynLexPad dynpmc, OpenGL and SDL bindings

[Jimmy Zhuo]

> rakudo threw away our libffi binding because

> 1. libffi had troubles on windows (which is unfair. libfffi works on
> much more platforms than dyncall, is actively maintained together
> with gcc, and has an easier interface. the windows problem was a
> problem of a single dev. no one else has it),
> and 2. our nci interface was rotten in one of the latest
rewrite/throw-away
> sessions.

> does rakudo really want to keep their suboptimal and hardly maintained
> dyncall library?
> And even if they prefer dyncall over libfii, why cannot we keep the
better library
> and just fix the harm done (i.e. runtime signature parsing).

Parrot can't keep the better library, because our active customer doesn't
use it. There are many better things in the world, parrot couldn't keep
them in her core.

> if parrot throws away the ffi binding for no apparent reason, no single
language
> besides rakudo will show interest.
> guaranteed.

You talk about the other language besides rakudo which is not actullay
existent(or is existent but not active in many years.). Parrot had been
supporting these nonexistent languages in the ideal world. If A project
loses touch with reality, it's dieing. Parrot is on the road. There is a
better image to describe it.
http://www.theschooloflife.com/assets/Uploads/28April2011resize.jpg

>> Now for the DynLexPad PMC.
>>
>> Again, it's not used by NQP and Rakudo, and I believe even the
>> ordinary LexPad needs to go:
>>

> again technical concerns:
> our lexpad works, rakudos lexpad is broken with threads.

No, our threads is broken with rakudo's lexpad.

> your solution: throw away the ones which works.

> my iproposal: optimize our lexpad pmc in the same way rakudo did it,
and rakudo does not need to maintain theirs.

My proposal:
1. patch our threads to work with rakudo's lexpad, and remove our lexpad
which is not used by rakudo.
2. submit a patch to rakudo, and remove our lexpad

Parrot is not the god, customer is Parrot's god. If somebody thinks Parrot
is in the right way, and Rakudo is in the wrong way. you can convince
rakudo to the right way. If you can't, Parrot should goes into the rakudo's
way. Yes, this looks brutal, but, this is the market. Any project which is
losing touch with market is meaningless to maintain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.parrot.org/pipermail/parrot-dev/attachments/20130308/b1fc8726/attachment.html>