25 replies to this topic

[Galapo]

Lancelot informed me today that a decision has been made to freeze WB development at 080, i.e. 080 is THE stable release of WB.

Just wondering if this is indeed true and if there's going to be a formal announcement?

If that's the case, would it be possible to do a service pack release on 080 adding the shift-selectable interface feature of 081?

Thanks,
Galapo.

[Wonko the Sane]

Hey, in order to avoid forking, are we going to do "in-house forking"?


Wonko

[Galapo]

Well, I thought I might at least have a slim possibility of having the (very useful!) feature added to 080 rather than retro-fitted to 077rc2!

Regards,
Galapo.

[Wonko the Sane]

Yep.

We can name it 080++ or 080# in order to avoid confusion with current naming schemes :
http://www.boot-land...?...=11141&st=2
http://www.boot-land...?...=10986&st=3
http://www.boot-land...showtopic=10569

Or maybe something meaningful like codename "Irreverent Insertion" or "Apodictic Addition"




Wonko

[paraglider]

What does that mean? No more development of WB? Is WB dead?

[Brito]

Just wondering if this is indeed true and if there's going to be a formal announcement?

No need as wb is not frozen at 080.

What I told lancelot is that development is frozen for the moment as it is a good time to reflect on what has happened over the last few months, next version will simply be done with quality time, no rushes.

I might at least have a slim possibility of having the (very useful!) feature added to 080 rather than retro-fitted to 077rc2!

Sorry, it will have to wait for wb 082 for the reasons pointed by Wonko. I don't know which feature you are mentioning but you can add a feature request if you haven't done so already: http://www.boot-land...hp?showforum=96

Can't promise that it will be included but opening a feature request allows to keep a record and a place where we can discuss its feasibility.

In the meanwhile, you're welcome to use winbuilder.exe 077rc2 or any other version which fits better your project. We'll strive to make of 082 an upgrade that .script developers see advantage in making.

[Wonko the Sane]

What does that mean? No more development of WB? Is WB dead?

That is not dead which can eternal lie, yet with stranger aeons, even Death may die.

Just for the record, the message from this thread may be understood like Wonko the Sane is agreeing to whatever the WB development team is doing or is planning to do, or that however he is somehow connected to the whatever is happening or will happen in the future, which is obviously NOT the case.

Truth is that, seemingly by pure chance, the WB development appears like having agreed at least partially to the suggestions Wonko the Sane (completely unsolicited for) proposed in the past.



Wonko

[paraglider]

Hopefully we will finish up with a development model where controversial features are discussed before they are implemented.

To my mind the highest priority issue is the performance of the scripting engine. The win7 feature script runs for 6 minutes and I have a Core I7 965.

[Lancelot]

Hi Nuno,

Just my name passed by, here I am , I informed Galapo very clearly, there is no misunderstanding, and honestly would not like to see this topic from Galapo today :>.

What Galapo ask is,
As you know wb have features mostly independent eachother, more or less: engine - helpersyntaxes - interface - download - editor etc....
what Galapo asks if possible to have a interface feature added to 080 having 080rev4 without touching rest (especially engine) of 080.
(-->or more, maybe a bug fix release ONLY that fixes bugs and add side thingies which I believe Galapo will like more, and probably help to new project starters when they come)

If Galapo asked me idea before opening this topic, be sure I would well inform him that his request would not be possible due to...blablabla (no comment) ..

To me, no importance, Even I took a whole time on 080 development topic with dreaming on jumping new wb version, I still use 77rc2 :>.

[Brito]

To my mind the highest priority issue is the performance of the scripting engine.

I don't know the script in question that uses 6 minutes but perhaps other alternatives could be found?

- Use an external script interpreter like AutoIt or cmd.exe?
- Reduce the complexity found inside the script?
- Cache wherever possible to improve speed on next run?

I've developed wb projects in the past using a mobile Pentium with 700Mhz and 256Mb of RAM that was more than enough to build a good boot disk project within a perfectly reasonable time: http://nunobrito.eu/...load.php?view.7

Also, wb got optimized processing speed over the last couple of years and available CPU/RAM is at the level of i7 just like you mention.

It seems to me that adding more performance will not make these type of scripts run faster, perhaps the script needs to be recoded with performance in mind.

For example, instead of using multiple IF statements inside a script, it would be good to think in other coding options.

Or better yet, you could help them improve the script since I'm sure they'd benefit a lot from the coding experience that you've gathered over the decades.


--------------

What Galapo ask is,
As you know wb have features mostly independent eachother, more or less: engine - helpersyntaxes - interface - download - editor etc....
what Galapo asks if possible to have a interface feature added to 080 having 080rev4 without touching rest (especially engine) of 080.
(-->or more, maybe a bug fix release ONLY that fixes bugs and add side thingies which I believe Galapo will like more, and probably help to new project starters when they come)

Sure, no problem.

Write these requests on the bug tracker forum section and if the request is being focused then we'll be talking more about them. Just be sure to keep one request per topic so that we can keep on track.

[Galapo]

What I told lancelot is that development is frozen for the moment as it is a good time to reflect on what has happened over the last few months, next version will simply be done with quality time, no rushes.

Ok, thanks for the information.

Sorry, it will have to wait for wb 082 for the reasons pointed by Wonko. I don't know which feature you are mentioning but you can add a feature request if you haven't done so already: http://www.boot-land...hp?showforum=96

Can't promise that it will be included but opening a feature request allows to keep a record and a place where we can discuss its feasibility.

Have you tested 081? The feature is already there, so no need to add a feature request for a feature already there.

In the meanwhile, you're welcome to use winbuilder.exe 077rc2 or any other version which fits better your project. We'll strive to make of 082 an upgrade that .script developers see advantage in making.

Well, you'll have to reign psc in on this one because 081rc1 is broken with most projects

Hopefully we will finish up with a development model where controversial features are discussed before they are implemented.

I really hope that's the case too and have made this suggestion on multiple occasions. Hopefully we'll get psc to agree.

Also, wb got optimized processing speed over the last couple of years and available CPU/RAM is at the level of i7 just like you mention.

It seems to me that adding more performance will not make these type of scripts run faster, perhaps the script needs to be recoded with performance in mind.

Nuno, this is just a way of escaping the real issue and the fact that WB is quite sluggish. Either there can be work-around to the problem itself, or the problem can be addressed.

Because the fact is that though WB got optimised for speed, lately it has become less optimised again. You can easily test this with LiveXP since the projects supports 077rc2 and 080. You see if you run tests that depending on scripts selected, 077rc2 can process the project up to more than twice as fast as 080. That's the reason why LiveXP still maintains script support for 077rc2 -- because we as developers do not want to sit waiting for WB to process the project when another version does the same thing in half the time. Something has happened between 077rc2 and 080 where the script processing speed of WB has become much slower.

Regards,
Galapo.

[pscEx]

Because the fact is that though WB got optimised for speed, lately it has become less optimised again. You can easily test this with LiveXP since the projects supports 077rc2 and 080. You see if you run tests that depending on scripts selected, 077rc2 can process the project up to more than twice as fast as 080.

Just for the record:

Last versions the speed has been increased by more and more introducing the use of #$?.

Because users demanded the "more readibility", every script line in version 081 is scanned and internally the #$? replaced.

That additional work of course demands additional processing steps whicvh increases the needed time.

BTW: The time increase in nativeEx_barebone is much less than the 100% and more, reported for LiveXP.

Compare 081 with 074 and you'll see that it is clearly faster.

Peter

[Brito]

Well, you'll have to reign psc in on this one because 081rc1 is broken with most projects

It's not a problem, the uneven versions are only good as prototypes.

Nuno, this is just a way of escaping the real issue and the fact that WB is quite sluggish. Either there can be work-around to the problem itself, or the problem can be addressed.

Ok, in that case attention will be given to see what can be done.

I'd still suggest developing workarounds to speed scripts up, this way you'll eventually get a project flying at jet fighter speed instead of a 747 speed.

[Galapo]

Just for the record:

Last versions the speed has been increased by more and more introducing the use of #$?.

Because users demanded the "more readibility", every script line in version 081 is scanned and internally the #$? replaced.

Hi Peter,

Tests were in relation to 080 -- the version where you implemented more of your no-quote intentions! Sure, there is a drastic increase in speed over 074 because 076 brought the speed increase. The issue relates to something changing between 077rc2 and 080 (Lancelot can pinpoint the exact versions a bit more exactly than me, somewhere around 078sp5?). Performance hit comes with app scripts or scripts using api, so you'll notice it less in your project. The more app scripts in a project, the greater the speediness of 077rc2 over 080 is noticed.

Ok, in that case attention will be given to see what can be done.

Thanks, Nuno, that'd be greatly appreciated by everyone.

I'd still suggest developing workarounds to speed scripts up, this way you'll eventually get a project flying at jet fighter speed instead of a 747 speed.

It not with scripts themselves, but with winbuilder.exe processing of the api. Maybe you could take a look yourself if you have time at optimising the api. But still the issue remains that 077rc2 processes much much faster than 080.

Thanks,
Galapo.

[pscEx]

Performance hit comes with app scripts or scripts using api, so you'll notice it less in your project. The more app scripts in a project, the greater the speediness of 077rc2 over 080 is noticed.

I agree that the issue is caused by extended use of API.

Exactly one day year before (+ 2 days) I already gave a warning: http://www.boot-land...?...ost&p=70002
I mentioned a time increase of 500% by (unnecessary) use of the API.

That proofs Nuno's suggestion to use script programming techniques to fasten the build.

Peter

Edit: Changed "day" to "year"

[paraglider]

The win7 version of require_file is much simpler.

Maybe the answer for complicated common api functions is to support plugin dll functions so the functions can be replaced with compiled code.

[Galapo]

That proofs Nuno's suggestion to use script programming techniques to fasten the build.

Of course, but then at the expense of cross-project and cross-architecture compatibility. There has to be some balance here. Maybe having separate PE1 and PE2 APIs again would be an advantage. But the common API was most actively developed by Pedro in a time when winbuilder itself was more speedy than it currently is.

But still the fact remains that something has happened between 077rc2 and 080 releases. Sure, api can probably be optimised more. But that still doesn't take away from the fact that 077rc2 is remarkably faster at processing a project over 080 and the reason why LiveXP still recommends the use of that version.

Regards,
Galapo.

[Brito]

Maybe the answer for complicated common api functions is to support plugin dll functions so the functions can be replaced with compiled code.

If by common API functions you are referring to functions inside api.script that each project can customize to suit their needs - then yes, a compiled binary would be n times faster than script interpreting when repeated n times across a project if it is well coded.

This is something that project developers can start improving right away and I'd recommend using autoIt or similar.

--------------------------

If by common API functions you are referring to the "raw" functions inside winbuilder.exe - then I'd say it is out of planning for the next times. Instead of modifying the whole core engine, it would be really simpler (and safer) to look at these speed hog scripts and code them in other manners.

I mean, if you have a scripts with spaghetti IF's, Loops back and forth, regwrites or any other processing that takes 6 minutes then it's time to see how the script in question can be put on a "diet".

[Galapo]

If by common API functions you are referring to functions inside api.script that each project can customize to suit their needs - then yes, a compiled binary would be n times faster than script interpreting when repeated n times across a project if it is well coded.

This is something that project developers can start improving right away and I'd recommend using autoIt or similar.

Nuno, I hope you realise that this is not as simple at it may seem at first. Some issues:

1. How to pass existing script, global, and permenant variables to this new (let's call it) capi.exe?
2. How to have capi.exe update project global variables (ie Set,%var%,NewValue,GLOBAL)?
3. How to have capi.exe update project permanent variables (ie Set,%var%,NewValue,PERMENANT)?

Note: this is only particuarly relevant for projects no longer supporting 077rc2. For projects supporting 077rc2 there is not that big of a problem at all because this version of WB is rather speedy at processing. The issue comes for projects using 080 and later.

I'd recommend you opening a topic where these matters can be discussed by wb developers and project developers of projects supporting only 080 and later.

Note #2: I've never said that this is strictly about CAPI, but winbuilder.exe script processing slowdown is more noticeable with CAPI. Even scripts using no api commands and only native/internal wb commands are processed noticeably slower with 080 over 077cr2.

Take TempPE script as an example. It only uses native/internal wb commands, no api syntax at all. 077rc2 processes the script in 3.484 seconds, while 080 processes the script in 5.938 seconds.  TempPE_logs.rar   9.62KB   358 downloads

Like I said before, you can test this winbuilder.exe slowdown by testing on a project such as LiveXP which supports both 077rc2 and 080 -- you'll see that 077cr2 beats 080 hands-down on speed. Sure CAPI can be improved, but the main reason why it would need to be improved is to provide a work-around to recent winbuilder.exe script processing slowdown. Like I said above, the issue isn't that significant for projects still supporting 077rc2, and my recommendation would be for projects to drop back to supporting 077rc2 while winbuilder.exe is worked on to get back to 077rc2 speed and while capi.exe discussions take place and while someone develops it.

Regards,
Galapo.

[Brito]

Sure. Let's open a new topic and talk about script code optimizations.

Post on the new topic all these questions and we'll start from there.

[Wonko the Sane]

From the outside, and given that faster execution speed is always welcome , what about the (good ) pre-processor approach?

http://www.boot-land...?...c=7330&st=5

I mean, winbuilder is not that much mission-critical/real-time, if one would be sure that the build wouldn't stop with a stoopid error at 3/4 to 4/5 of the job done, he/she could start the build and go take a walk or a coffee, and the processing speed would be largely irrelevant.


Wonko

[MedEvil]

For a end user the speed is pretty irrelevant, but not for a developer, who has to do numerous builds a day.

[Wonko the Sane]

For a end user the speed is pretty irrelevant, but not for a developer, who has to do numerous builds a day.

Sure, I was talking about an ADDITIONAL measure to easen life of BOTH Users and Developers.


Wonko

[pscEx]

For a end user the speed is pretty irrelevant, but not for a developer, who has to do numerous builds a day.

I am a developer, and you can imagine when I test WB with LiveXP where in the recommended download 81 (in words eighty one) scripts are active in factory setting.

And because of many dependencies and cross-references, I do not know which scripts are not needed and can be deselected.

Therefore: Each test gives time for at least three coffees (5 minutes per coffee).

Peter

[Galapo]

Sure. Let's open a new topic and talk about script code optimizations.

Nuno, I repeat: this isn't just about script optimisation, it is primarily about the slowdown with winbuilder.exe itself. The logs above bear this out. TempPE.script you'll notice is already optimised, using internal winbuilder.exe commands, ie no api use at all. As such, 077rc2 will always run much faster than 080, whether it's a non-api script like TempPE, or an api script.

If you think sourcecode optimisation of winbuilder.exe and requires discussion with us in addition to Peter, then maybe open a topic on the bugtracker.

If you think TempPE.script requires optimisation, there's already a topic for that script created by Peter. You could post there. But like I said, even with (further) optimisation, 077rc2 will process the script faster in line with the test logs above.

For those using projects supporting 078-080 and no longer 077rc2, you could open a topic where you could discuss with them the optimisation of CAPI into an external executable. I'd be happy to post the difficulties I raised with such a task there.

Thanks,
Galapo.