BlackBox Framework Center

For the issue see : https://redmine.blackboxframework.org/issues/156.
For the discussion see: viewtopic.php?f=41&t=610
For the diffs see: https: https://redmine.blackboxframework.org/p ... 97faa7e691.
The latest build is http://blackboxframework.org/unstable/i ... a1.857.zip.

I am asking the group to support this proposal with the following comments and caveats:

- It is an important new (to BlackBox, it has been around in the software community since the 1950's, and formed a significant Modula II feature in the 'Wirthian' world) capability.

- While I am not personally expert in the details, I find it quite credible that multi-stack support requires Kernel changes, so wants to be implemented in the standard distribution rather than entirely as "App-store" add on modules.

- We need to get the proposal into a "stable" build, and then widely distributed, to gain experience and further feedback on the API propsal.

- I am personally keen to contribute to this, but this will not happen for several months. So I think this is a rather exceptional proposal where we want to keep an open mind about reconsidering the details after experience, even if it might mean subsequent revisions do cause some backward compatibility issues.

- I will mention two other areas where we might want to reconsider the details after some months wider experience. But I don't think these are reasons to delay this vote any more because:
-- These areas do not alter the core API
-- Despite considerable discussion a universal concensus does not look to be very near.

These topics are:
- The benefits versus the costs of abstracting the low-level operating system calls out of Kernel. I think this topic could be raised as separate issue after some months experience with using the API on the Windows implementation, and could form part of a wider issue on this topic.

- The composition of the Obx examples. We might, later, want to revise these, or even move them entirely to an external location (CPC ?).

In summary, I think it is time to suspend this discussion, and to take some positive forward action.

I am upset that Robert ignored my request for the preliminary voting. I think that such situation is not OK. Robert, why did you ignore this request? I made the big work to find how to make this issue realization better and I am not along in the opinion that HostCoroutines is better way to place Fibers calls. Why all this is ignored?

We had the bad experience with Utf8 conversion. The better realization was sacrificed with the same manner "lets discuss this letter and maybe add better solution to Strings module". So we have slower and more dangerous conversion now in BlackBox.

I vote No, because there was no preliminary voting and also the discussion is not finished yet
https://community.blackboxframework.org ... 2e53#p1033
viewtopic.php?f=41&t=610&p=5958#p5958

Josef's suggested solution does not follow FILO (First-in, last-out) rules and also make WinApi calls in the System modules.

Ivan Denisov wrote:I am upset that Robert ignored my request for the preliminary voting.

Ivan
I have not ignored your request for a preliminary "realization" vote.

The way we customarily work is to have a 'lead' implementer for the resolution of each issue; sometimes it is the person who raised the issue, sometimes someone else. I don't see an effective alternative to this way of working. The lead on issue #156 is Josef.

I see four possible future paths for this issue:
1 - We do not incorporate coroutines at all
2 - We incorporate, now, the current proposal as requested by its lead - possibly with some small last-minute improvements
3 - We wait until, as a result of discussion, the current proposal evolves to a significantly changed state
4 - We reject the current issue, but, later, accept a new issue on the coroutines topic.

I, personally, don't want path 1.
For reasons I shall explain below, I don't think path 3 is going to happen, at least not quickly.

This vote allows us to choose between path 2 (which gives a quick solution) or leaves open paths 1, 3 & 4. We would then, over a longer time-frame, need further votes to come to a decision. In that sense this vote is already preliminary.

I considered a more preliminary, implementation based, question. I rejected that because I think that it is less likely to come to a clear result, and even if the vote went "The majority don't like certain implementation specifics of the current proposal" that does not narrow down the set of future paths any more effectively than the vote as currently worded.

Regarding path 3, and why I think trying it will only waste more time:
There has already been considerable discussion at the implementation detail level. The discussion has improved the original draft, but we have now reached the stage where the two main contributers are just repeating themselves. Some observers (myself, and probably others) are not following the low-level detail, so discussion there is ineffective. The other observers who are following the low-level detail have already had a good chance to contribute, so waiting brings no further benefit.

I have opened a new thread to change the discussion from "How do we implement it" to "What does it do" & "Why do we need it (in the standard distribution)" to make the discussion relevant & accessible to a wider group. That initiative has not lead to new thinking that results in concensus.

So we need to move, even if on the basis of majority rather than full concensus.

I am, again personally, sympathetic to the idea of taking care, and some trouble, to support operating system abstraction, and multi-platform development. But if this comes with excessive cost "sympathy" does not mean automatic support for every related implementation detail. This is a big, separate, topic, with much detail to consider. Linking it closely to the coroutines issue is not leading to a quick solution. I think this is better handled as a separate issue, and to get it supported there will need to be clear (and short) discussion at the "What is it and why we need it?" level as well as detailed implementation proposals.


I shall leave this vote open for a few more days. People may change their votes. There are now three related threads open on this forum (plus one on the community forum) where people are still welcome to explain their thoughts. I can't do any more and progress this issue to a conclusion.

"The longevity of interim solutions"
http://programmer.97things.oreilly.com/ ... _Solutions
K. Henney, Ed., 97 things every programmer should know: collective wisdom from the experts, 1st ed. Sebastopol, Calif: O’Reilly, 2010.

I agree that for many cases a lead of the issue should keep his line. However some general design points can not be the responsibility of one person. There should be separate voting for some general design ideas (while we have no features policy or developers guideline). Then lead of the issue can shape the solution according some chosen strategy. Now it looks like the strategy "As I will so I command (Br.). I do as I please (Am.)" which will lose any Center authority without any been gained. As an organization we did not pass serious lifetime proofing for the pool of existing users. However we already making some brave experiments in our second (patch) release. I am translating now some point of view about the general Center activity from the Russian board. All this makes my position more strict and earlier I claimed to limit 1.7.1 feature by multiple stack support for further discussion of a good coroutines implementation design.

Dear Ivan,
we are a few people only. Robert just try to keep this small group together. Ivan you have down a great job by creating and managing the Center website. Please don't add new rules (e.g. no WinApi calls in module xxx) for Linux implementation which we never discuss here. Josef’s solution is not against Linux implementation.

There are over 150 changes between BB 1.6 and 1.7. About 75 changes I collect before the Center started with the first change. Josef have done a lot of improvements in my part of work.

One create topic was to include Fyodor’s change to allow Russian variable names. Do you know that there exist to different solution? One solution changed the symbol table from SHORTCHAR to CHAR (not an easy task, the solution is very difficult to understand) and the other solution uses utf-8.

We have open topics (e.g. adding debugger) which are waiting for getting started …

Another open point is to write a document which descript all the new futures of BlackBox 1.7. You will be surprise how much work it is. Most of them we have already forgot.

Ivan, we are all unhappy with the current situation.
- Helmut

I did my job with creating some infrastructure for the Center, and also I improved my writing English by talking with you, folks. I do not want to disturb anybody so I will stay away from Center activity for some time. I hope you are understanding me and will not miss much

Ivan Denisov wrote:I did my job with creating some infrastructure for the Center, and also I improved my writing English by talking with you, folks. I do not want to disturb anybody so I will stay away from Center activity for some time. I hope you are understanding me and will not miss much

This would be very sad because you are doing a great job as administrator.

- Josef

Ivan Denisov wrote:[...]
I will stay away from Center activity for some time.

this is a pity. I really appreciate your work in setting up and administrating the Center.

I hope you are understanding me and will not miss much

no. I cannot understand it.
I currently have not enough spare time to invest much for the Center, but sometimes I find the time to watch a little bit more.
I understand some of your concerns about portability.
But I cannot understand why you feel offended such severely that you want to retract yourself.

Ivan, could you please have a look at issue-#158?
viewtopic.php?f=41&t=616#p5974

- Josef

Ivan Denisov wrote:I hope you are understanding me and will not miss much

I am greatly saddened by this situation which I was trying to avoid. I do regret this failure.

I will not attempt to try to make you change your mind; that might be considered patronising. But I do hope that the time will come (sooner, rather than later) when you feel you wish to rejoin this group, and we will enthusiastically welcome you back.

Best regards, and very many thanks for your very significant contributions. - Robert