[Pharo-project] Introducing Myself / FFI comments
Folks - After long hesitation I've decided to subscribe to the Pharo list. I'm doing this mostly to put perspective on some issues that have come up here and where I feel I have a unique perspective on them. If you haven't guessed, I've been called many unfriendly names here, most recently "the FFI maintainer". Let's start there with putting some perspective on the issues. Fortunately, all of this discussion has been archived so we don't need to play "he said, she said" but I can just point you to the messages themselves. Lukas claims: "In fact we had that in Squeak 3.9 and early Pharo versions. I even wrote code that adapted this mechanism for FFI, but the FFI maintainer insisted on sticking with his compiler hacks." What Lukas *isn't* mentioning is that his proposal would have rendered all FFI code ever written nonfunctional and non-loadable. Practically speaking, it would have simplified two methods with fifty lines of code at the expense of making six years of work of many people unusable: http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/106992.ht... http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107037.ht... http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107039.ht... http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107204.ht... Then of course, Stef threw in his usual good-natured self and changed what had been a relatively issue-focused discussion into an old-fashioned personal assault: http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107124.ht... http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107134.ht... Despite that I proposed what I felt might be a workable alternative, which got shot down by Lukas in an instant: http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107136.ht... http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107144.ht... A third proposal was made, that I agreed with as will, Lukas ignored the proposal completely: http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107313.ht... http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107338.ht... At the end of the discussion, Lukas still hadn't responded to various compromises that I had offered to discuss with him: http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107309.ht... http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107337.ht... I've certainly had points in the past where some people here have every right to be mad at me and where I've made gross mistakes. But this wasn't one of those times. I've been fairly patient, took the discussion into whichever direction Lukas wanted, made alternative proposals, agreed with third party proposals, didn't even raise to the rhetoric bait that was thrown at me multiple times. The *one* tradeoff I wasn't willing to make for the sake of my users was to break their code; was to make their code non-loadable for absolutely no benefit for these users. Cleaning up two methods and fifty lines of code isn't worth breaking six years of work from lots of people. It wasn't then, it isn't today. And when Stef says "Some people may now understand why we finally decided to do Pharo." then you should probably wonder what that means in the context of this discussion. Finding solutions that benefit *all* parties involved isn't one of his primary strengths in my experience. Back to lurking for now, - Andreas
On 28 February 2010 07:54, Andreas Raab <andreas.raab@gmx.de> wrote:
Folks -
Back to lurking for now,
wait.. i'd really like to have eventually <apicall: 'Win32HBrush CreateSolidBrush (ulong)' module: 'gdi32.dll'> instead of: <apicall: Win32HBrush 'CreateSolidBrush' (ulong) module: 'gdi32.dll'> so, pragma syntax will be consistent. Yes, backwards compatibility hurts. Yes everything has its costs, but.. do you willing to reopen this topic again (after 4 years passed) towards making FFI pragmas pluggable into parser/compiler? By pluggable i mean that by loading next-gen FFI package, there will be no need to patch/add not a single method in parser/compiler. I think its quite easy to write some code which helps with transition automation. I imagine a following process: - write a new FFI-Legacy package, which supports transition to new format then user: - loads this package, before loading any code which using FFI - load any code which using FFI , during which it should be automatically converted to new pragma format(s) - save converted code - user now free to unload FFI-Legacy and use new pragma syntax.
 - Andreas
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Andreas Raab a écrit :
The *one* tradeoff I wasn't willing to make for the sake of my users was to break their code; was to make their code non-loadable for absolutely no benefit for these users. Cleaning up two methods and fifty lines of code isn't worth breaking six years of work from lots of people. It wasn't then, it isn't today.
However, breaking code compatibility is very common in opensource world, probably to ease evolution. I remember to read somewhere it happens several time in Python, an alive and kicking community...
I would like to add to this discussion. The issue on "breaking code compatibility" /per se/ it is not the central issue, the real trouble is to have to expend too much time to learn how to "re-compatibilize" the cote, or use [the] new construct that is not deprecated. I'm not an active Python developer, but I used to work in a place where it was used extensively and the 'elbow' feedback I got from colleagues was that that Python did a good job on this aspect. my 0.01999.... -- Cesar Rabak Em 28/02/2010 05:24, Hilaire Fernandes < hilaire@ofset.org > escreveu: Andreas Raab a écrit :
The *one* tradeoff I wasn't willing to make for the sake of my users was to break their code; was to make their code non-loadable for absolutely no benefit for these users. Cleaning up two methods and fifty lines of code isn't worth breaking six years of work from lots of people. It wasn't then, it isn't today.
However, breaking code compatibility is very common in opensource world, probably to ease evolution. I remember to read somewhere it happens several time in Python, an alive and kicking community... _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Ok andreas other times and other communication problems. Let us try to improve on that and build a new relationship. Let us try to restart with a clean board and some nice piece of chalk and draw the future. In 2010 how can we make progress on that and move ahead. We are all ready to see progress on this front and avoid forking FFI for nothing. Stef
Folks -
After long hesitation I've decided to subscribe to the Pharo list. I'm doing this mostly to put perspective on some issues that have come up here and where I feel I have a unique perspective on them. If you haven't guessed, I've been called many unfriendly names here, most recently "the FFI maintainer".
Let's start there with putting some perspective on the issues. Fortunately, all of this discussion has been archived so we don't need to play "he said, she said" but I can just point you to the messages themselves. Lukas claims:
"In fact we had that in Squeak 3.9 and early Pharo versions. I even wrote code that adapted this mechanism for FFI, but the FFI maintainer insisted on sticking with his compiler hacks."
What Lukas *isn't* mentioning is that his proposal would have rendered all FFI code ever written nonfunctional and non-loadable. Practically speaking, it would have simplified two methods with fifty lines of code at the expense of making six years of work of many people unusable:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/106992.ht... http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107037.ht... http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107039.ht... http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107204.ht...
Then of course, Stef threw in his usual good-natured self and changed what had been a relatively issue-focused discussion into an old-fashioned personal assault:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107124.ht... http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107134.ht...
Despite that I proposed what I felt might be a workable alternative, which got shot down by Lukas in an instant:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107136.ht... http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107144.ht...
A third proposal was made, that I agreed with as will, Lukas ignored the proposal completely:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107313.ht... http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107338.ht...
At the end of the discussion, Lukas still hadn't responded to various compromises that I had offered to discuss with him:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107309.ht... http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107337.ht...
I've certainly had points in the past where some people here have every right to be mad at me and where I've made gross mistakes. But this wasn't one of those times. I've been fairly patient, took the discussion into whichever direction Lukas wanted, made alternative proposals, agreed with third party proposals, didn't even raise to the rhetoric bait that was thrown at me multiple times.
The *one* tradeoff I wasn't willing to make for the sake of my users was to break their code; was to make their code non-loadable for absolutely no benefit for these users. Cleaning up two methods and fifty lines of code isn't worth breaking six years of work from lots of people. It wasn't then, it isn't today.
And when Stef says "Some people may now understand why we finally decided to do Pharo." then you should probably wonder what that means in the context of this discussion. Finding solutions that benefit *all* parties involved isn't one of his primary strengths in my experience.
Back to lurking for now, - Andreas
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
Andreas Raab -
csrabak＠bol.com.br -
Hilaire Fernandes -
Igor Stasenko -
Stéphane Ducasse