[Development] Future of QBS

André Somers andre at familiesomers.nl
Tue Oct 17 19:16:42 CEST 2017



Op 17/10/2017 om 17:31 schreef Oswald Buddenhagen:
> On Tue, Oct 17, 2017 at 05:23:17PM +0200, Ulf Hermann wrote:
>>>> Exactly. The halting problem can be worked around pragmatically.
>>> ... at the price of getting different build results based on CPU speed ...
>>>
>>> Your fast desktop CPU crunches through the JS and you get a working
>>> built, while my sucky laptop CPU does not and the build fails for me.
>> A simple timeout may be a bit too pragmatic, but you could count the
>> JS instructions executed.
>>
> you guys are discussing the locks of a house without walls. when any
> type of reasonable limiter needs to kick in, the your build system is
> *broken*. that's a fatal error, not just a "different result", and you
> need to rethink what you're doing.
Could you clear up what you mean *exactly* here?
Do you mean 1) that any system that provides some kind of timeout (in
terms of wall time or another measure) for evaluation is broken, or that
2) a build setup that runs into such a timeout is broken? That's a big
difference.

_I_ think that doing 1) is reasonable to keep a IDE like Creator
responsive. And of course, you report an error and fail the build when
that happens. A message stating where the issue occured would of course
be very helpfull.

André




More information about the Development mailing list