Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Which of crategus or Ferada fork should we follow? #77

Open
Ambrevar opened this issue Mar 22, 2020 · 3 comments
Open

Which of crategus or Ferada fork should we follow? #77

Ambrevar opened this issue Mar 22, 2020 · 3 comments

Comments

@Ambrevar
Copy link

Some time ago I believe Quicklisp switched to @Ferada 's repository: quicklisp/quicklisp-projects#1302

I see that now @crategus has resumed work on this project.

Are the two forks diverging? What's the plan?

@Ambrevar
Copy link
Author

Also see #57.

@stacksmith
Copy link

stacksmith commented Mar 22, 2020

A word of warning: @crategus seems to misunderstand that many of the GTK lightweight objects (iterators of all sorts, temporary rects and points, for instance) are meant to be stack-allocated and passed around as temporaries. Making them full Lisp objects only to translate them back and forth, often for no reason, then deallocate them immediately is not only wasteful, but asking for bugs and GC issues. Things are even worse since CFFI caches complex foreign types such as these poorly . I've posted many issues resulting from the above with no reply. For instance,a new CFFI type generated for every instance of a the same complex foreign type, in every binding and every parameter!#69
I had to completely rewrite text editing classes correcting errors, using simplified rectangles and points that reuse the same CFFI types, and using plain foreign pointers for objects of no relevance, until I got sick and tired of the whole thing.
@Ferada has fixed a number of related issues.

@Ferada
Copy link

Ferada commented Apr 2, 2020

Without going into details too much: I'm doing maintenance only, I'll also not spend time rebasing roughly 200 patches onto a now updated and diverging upstream. Feel free to request changing the Quicklisp entry back again, but then I also suggest someone does a merge, otherwise already fixed issues would have to be fixed again (presumably, I haven't checked).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants