Request: PEBakery Help Document

Hi ied206,


+
Something we miss for years now:
(current help files around have lots of missing and wrong info but still useful for now ... )

AutoIT creates help files on web
https://www.autoitscript.com/autoit3/docs/
later compile it to chm during each update.

This way Help files are both browsable (and searchable) on net, and offline chm available on distribution.

ps: Just like we do for projects zip distribution.

=>
I hope you can start same way with PEBakery.
http://pebakery.cwcodes.net/PEBakery/docs

Hi
I agree, especially for the likes of me ,who are still at the bottom of the learning curve
I guess when time and prioities permit ied206 to complete his online manual on
https://github.com/ied206/PEBakery/blob/docs/Manual/Commands/README.md
it will be hopefully, relatively to easy to action 

Something we miss for years now:
(current help files around have lots of missing and wrong info but still useful for now ... )

As one of the primary authors of WinbuilderN.chm I would be interested in knowing what info you believe is missing/wrong. Taking into consideration that the API Commands section refers to the old CAPI and not MacroLibrary....so it can be added/corrected.

I hope you can start same way with PEBakery.

Check out the github repository: https://github.com/ied206/PEBakery/tree/master/Manual

once the documentation is more mature the markdown files can easily be converted to html for publishing to the web or compiling to a chm.

Something we miss for years now:
(current help files around have lots of missing and wrong info but still useful for now ... )

As one of the primary authors of WinbuilderN.chm I would be interested in knowing what info you believe is missing/wrong.

No thanks, I never have interest to contribute with such info anymore, I close this page 7 years ago.
So far I know, JFX, Galapo, ChrisR do not have interest all these years.
That is the reason we never work on such help document.

Taking into consideration that the API Commands section refers to the old CAPI and not MacroLibrary....so it can be added/corrected.

Funny. 
After 7 years !
As one of the primary authors of WinbuilderN.chm better you update for "capi" for the projects that use capi or winbuilder (77 080 082 083 084 085 or javabuilder or whatever),
 which are all out of interest and out of topic.
    I am sure winbuilder and capi and their documentation and relevant projects become much better in passing time on last 7 years, which all are out of current topic interest.

Reminding:
Current topics is about a request for PEBakery Help document.








*

I hope you can start same way with PEBakery.

Check out the github repository: https://github.com/ied206/PEBakery/tree/master/Manual

once the documentation is more mature the markdown files can easily be converted to html for publishing to the web or compiling to a chm.

Reminding Under Construction
ex: https://github.com/ied206/PEBakery/tree/docs/Manual/Commands/08_Interface.md


I like to see ied206 follow Jonathan Bennett successful organization on AutoIT Help files :

AutoIT creates help files on web
https://www.autoitscript.com/autoit3/docs/
later compile it to chm during each update.

Like we do on project zip distributions,
 rather than the failure of winbuilder and capi and their documentation.

  We did not create forum and projects to reply same failures.

  Conversions always cause troubles.....

It takes a lot time to update and fix things if things do not start with correct steps.
 Proof of Concept: http://TheOven.org forum and Projects developed here.
    Projects developed with correct steps to forward AND with updates to get rid of old bad designed things since 7 years now.
       -> BiDirectional Development, with PEBakery I hope we only go 1 direction forward which will gain big free time.
    And Forum Moderated to get users Focus on Development rather than endless discussions.

ex: Last 31 topics





**
if you like to discuss things like "winbuilder" and "capi" and their documentation,
You are on wrong topic and section
There is a section for that:

Other World:
http://theoven.org/index.php?board=15.0

No thanks, I never have interest to contribute with such info anymore, I close this page 7 years ago.
So far I know, JFX, Galapo, ChrisR do not have interest all these years.
That is the reason we never work on such help document.

Then I'm afraid I don't understand why you brought up current documentation (which is shipped with all SE projects I might add) is incorrect or out of date.
As one of the authors of said documentation I offered to fix any errors. How is that "out of interest"? As ied206 said himself that he used WinbuilderN.chm as the basis for developing PEBakery and understanding how wb syntax was constructed and works, I should think you would be concerned with making sure any errors or omissions were corrected. Otherwise PEBakery is at risk of producing the same buggy results as the builder it is replacing.

Taking into consideration that the API Commands section refers to the old CAPI and not MacroLibrary....so it can be added/corrected.

Funny. 
After 7 years !
As one of the primary authors of WinbuilderN.chm better you update for "capi" for the projects that use capi or winbuilder (77 080 082 083 084 085 or javabuilder or whatever),
 which are all out of interest and out of topic.
    I am sure winbuilder and capi and their documentation and relevant projects become much better in passing time on last 7 years, which all are out of current topic interest.

I thing you missed the point of that statement. I will try to be more clear so you understand. I was saying that IF the missing/incorrect information YOU were referring to was under the "API Commands" section, then it was because at the time that help document was written that is what was available and in widespread use. Obviously the documents were not extended once "MacroLibray" took over AFTER that section was created, but I will not apologize for committing my time to FAMILY where it was needed instead of trying to keep up with an ever changing library between 2 split communities with different ideas of what commands should be included. At this point I have no intention of creating or updating any documentation relating to any API/MacroLibrary so discussing errors or omissions in help specific to the "API Commands" section is moot.


If I misunderstood you and your reference to missing/incorrect documentation was not referring to WinbuilderN.chm and was in fact referring to incomplete documentation in the PEBakery git repository then I apologize and we can forget the above conversation. I only want to make sure that the WinbuilderN.chm ied206 is using a reference does not contain errors that will set back development and lead to lost time chasing bugs.

AutoIT creates help files on web
https://www.autoitscript.com/autoit3/docs/
later compile it to chm during each update.


Like we do on project zip distributions,
 rather than the failure of winbuilder and capi and their documentation.

here you are mistaken. autoit does not build its help files on the web. instead the help file is built from source into htm files for a .chm and the htm files that make up the .chm are ported over to a minimized web version that makes up the "online" help you refer to.
You don't have to take my word for it though. Ask JFX or You can read the source codes see for yourself
You can find the uncompiled html files for the current version of AutoIt in the Archive. (called docs-v3.3.nnn-src.zip).
https://www.autoitscript.com/site/autoit/documentation-localization/
https://www.autoitscript.com/wiki/Documentation
https://www.autoitscript.com/autoit3/files/archive/autoit/autoit-docs-v3.3.14.2-src.zip

I fully support ied206's decision to have the documentation based in the git repository where anyone can have access to submit changes in an open and transparent manner and see the revision history. Just like we did with WinbuilderN.chm and just like autoit does with their documentation. And as I said, it is relatively easy to automate a process to convert the markdown files to html and  host on a web mirror or compile to .chm .

No thanks, I never have interest to contribute with such info anymore, I close this page 7 years ago.
So far I know, JFX, Galapo, ChrisR do not have interest all these years.
That is the reason we never work on such help document.

Then I'm afraid I don't understand why you brought up current documentation (which is shipped with all SE projects I might add) is incorrect or out of date.

As written previous post:
 Documentation you refer is about winbuilder and capi.
 They are good for winbuilder and capi and projects that they use now.
 Current topic is about PEBakery help document.

 chm files shipped to help any user, and on topics it is written chm file is not accurate.
  ex: GetParam, PackParam http://theoven.org/index.php?topic=2314.msg25021#msg25021
 chm files were good to have a good start, they are kept for that reason.

with PEBakery help documents and chm, we can get rid of them in some future.


*

As one of the authors of said documentation I offered to fix any errors. How is that "out of interest"?

As written previous post:

Funny. 
After 7 years !
As one of the primary authors of WinbuilderN.chm better you update for "capi" for the projects that use capi or winbuilder (77 080 082 083 084 085 or javabuilder or whatever),
 which are all out of interest and out of topic.
    I am sure winbuilder and capi and their documentation and relevant projects become much better in passing time on last 7 years, which all are out of current topic interest.

winbuilder and capi documentation is "out of ALL interest" who work on projects here.
As you are one of the author, you should be the one who stand after the validity documentation, like we do for projets and documents on topics here.
Thanks for the very funny offer after 7 years. 


*

Otherwise PEBakery is at risk of producing the same buggy results as the builder it is replacing.

I do not think so.
winbuilder development and help documents follow some development principles that none of us here agree with.
We also made predictions 7 - 8 years ago.
I believe time proves, our predictions, development principles are much more correct than people who made other predictions 7 - 8 years ago.
Sadly time could not prove things to you.

reminding amalux

...and yes, smiley, you are right; the fact that Nuno has sided with and defended his xb developer's childish, self-righteous, self promoting behavior throughout this exchange is inexcusable and shameful (though he'll never see it) and as you can now see, when losing a debate, that debate gets shutdown

How sad that this once great forum has been brought to this level by two ego centric, foolish men (Nuno and PSC) bent on promoting their own agenda at any cost. Oh but we'll have 'peace' once again, when the most talented, hard working and gifted members of your team keep telling you something is wrong with the way you're doing business, threaten to fire 'em!

*

Taking into consideration that the API Commands section refers to the old CAPI and not MacroLibrary....so it can be added/corrected.

Funny. 
After 7 years !
As one of the primary authors of WinbuilderN.chm better you update for "capi" for the projects that use capi or winbuilder (77 080 082 083 084 085 or javabuilder or whatever),
 which are all out of interest and out of topic.
    I am sure winbuilder and capi and their documentation and relevant projects become much better in passing time on last 7 years, which all are out of current topic interest.

I thing you missed the point of that statement. I will try to be more clear so you understand. I was saying that IF the missing/incorrect information YOU were referring to was under the "API Commands" section, then it was because at the time that help document was written that is what was available and in widespread use. Obviously the documents were not extended once "MacroLibray" took over AFTER that section was created, but I will not apologize for committing my time to FAMILY where it was needed instead of trying to keep up with an ever changing library between 2 split communities with different ideas of what commands should be included. At this point I have no intention of creating or updating any documentation relating to any API/MacroLibrary so discussing errors or omissions in help specific to the "API Commands" section is moot.

I thing you missed the point of current topic.
I will try to be more clear so you understand. (maybe)
We never have interest on documentation of winbuilder and capi.


*

If I misunderstood you and your reference to missing/incorrect documentation was not referring to WinbuilderN.chm and was in fact referring to incomplete documentation in the PEBakery git repository then I apologize and we can forget the above conversation. I only want to make sure that the WinbuilderN.chm ied206 is using a reference does not contain errors that will set back development and lead to lost time chasing bugs.

Since you misunderstood :
I provide link to incomplete documentation to only prove it is under construction now.

Reminding Under Construction
ex: https://github.com/ied206/PEBakery/tree/docs/Manual/Commands/08_Interface.md


I like to see ied206 follow Jonathan Bennett successful organization on AutoIT Help files :

I do not know how you misunderstood
"Reminding Under Construction"
and
"I like to see ied206 follow Jonathan Bennett successful organization on AutoIT Help files"
.

Probably my bad english again. ( Joking )


As written before,
We never have interest in feedback to any winbuilder documentation since 7 years now.
WinbuilderN.chm file is good enough to start and deprecate in some hopefully near future.



*
We do not spend our valuable free time with development circle principles which seem you are after, as predicted by 7 - 8 ago.
We also have FAMILY and JOB.

If winbuilder and its documentation is so good to you, then continue with them. We never had such interest.

I only hope, 7 years time on current topic proves to you, development forward principles are better we do on projects here.

Now with PEBakery, builder and documentation can also be improved on same development principles like all other good software developments.

*
See you on next post.

here you are mistaken. autoit does not build its help files on the web. instead the help file is built from source into htm files for a .chm and the htm files that make up the .chm are ported over to a minimized web version that makes up the "online" help you refer to.
You don't have to take my word for it though. Ask JFX or You can read the source codes see for yourself
You can find the uncompiled html files for the current version of AutoIt in the Archive. (called docs-v3.3.nnn-src.zip).
https://www.autoitscript.com/site/autoit/documentation-localization/
https://www.autoitscript.com/wiki/Documentation
https://www.autoitscript.com/autoit3/files/archive/autoit/autoit-docs-v3.3.14.2-src.zip

I fully support ied206's decision to have the documentation based in the git repository where anyone can have access to submit changes in an open and transparent manner and see the revision history. Just like we did with WinbuilderN.chm and just like autoit does with their documentation. And as I said, it is relatively easy to automate a process to convert the markdown files to html and  host on a web mirror or compile to .chm .

Thanks for the info,

You know I always support open source development. 

You missed to provide link to Jonathan Bennett AutoIT git repository. ?

Hi ied206,

with no further response, proves concept was right.

Homes32 summarize some reasons why wb documentation failed, there are more.... , no need to live same bad experience again.
Also thanks to Homes32, it is even better to create help documents from a help source, when help source updated all htm chm etc. also will be updated. Great.
Another reason to admire Jonathan Bennett AutoIT 


Back to topic post:

+
Something we miss for years now:
(current help files around have lots of missing and wrong info but still useful for now ... )

AutoIT creates help files on web (fix: help file is built from source into htm )
https://www.autoitscript.com/autoit3/docs/
later compile it to chm during each update.

This way Help files are both browsable (and searchable) on net, and offline chm available on distribution.

ps: Just like we do for projects zip distribution.

=>
I hope you can start same way with PEBakery.
http://pebakery.cwcodes.net/PEBakery/docs


+
ps: Just like we do for projects zip distribution.
-->
Following Jonathan Bennett AutoIT documentation, with open source adjustments following links provided by Homes32
It will be as easy as updating a plugin on 5 projects (for now) with a single upload button when help document organized nicely.

I feel, In the end we can have a plugin ex: \Utils\Help Documents having upload button that uploads plugin to 6 servers  (+1 PEBakery server)
 + with updated help source + updating chm for zip distributions + updating web htm


Anyway, first things first.  Better design help document in a way it should be as first steps. 

Homes32 summarize some reasons why wb documentation failed, there are more.... , no need to live same bad experience again.

Please refrain from using my name falsely to push your opinions.

• The fact that there IS a WinbulderN.chm (that by the way was developed by a few of us INDEPENDENTLY from nuno/psc winbuilder developers) proves that the documentation was NOT a failure.
• The fact that WinbuilderN documentation survives to this day and is published on multiple mediums, including .wiki, .chm and web/html (http://wb.paraglidernc.com/Help/) proves that is is NOT a failure.
• The fact that there IS a PEBakery replacement to winbuilder is proof that the documentation was NOT a failure.

Unless you care to elaborate and provide examples of incorrect documentation in relation to WinbuilderN.chm along with corrections then you are only trolling and there is no further discussion to be had on the topic. Hence no further response from me.

What you fail to understand is that WinbuilderN.chm was developed in much the same way as the Autoit documentation, to which I will be the first one to agree with you is top notch.

• Autoit written in a combination of plain text files, udf headers, and .htm files which are compiled to .chm and .html
• WinbuilderN.chm help written in the google .wiki format and compiled to chm & html
• PEBakery documentation written in markdown (https://daringfireball.net/projects/markdown/), a language that was designed to be easier to write and maintain then html and directly published to .html suitable for both .chm, wiki, and online html help.

I feel, In the end we can have a plugin ex: \Utils\Help Documents having upload button that uploads plugin to 6 servers  (+1 PEBakery server)
 + with updated help source + updating chm for zip distributions + updating web htm

Yes. this is exactly what will be possible with the way the help is being designed.
As the documents are in the repository alongside the code, they can be updated as features are added/removed and can be compiled automatically by the build process, viewed in their natural state, or fetched on demand by 3rd party and compiled to whatever you want. Funny how well "failed" processes work... 

If you find errors or omissions in the current PEBakery documentation and are uncomfortable making a pull request, please open a bug report on the git repository containing the information you believe is incorrect and what you think is should read, and I will be happy to make the corrections as time allows.

In conclusion, we both want the same thing, and that's is what development is working towards, so lets lets lay this topic to rest, I feel there is no more constructive discussion to be had on this particular thread.

-regards,
Homes32

Hi Homes32,

Homes32 summarize some reasons why wb documentation failed, there are more.... , no need to live same bad experience again.

Please refrain from using my name falsely to push your opinions.

• The fact that there IS a WinbulderN.chm (that by the way was developed by a few of us INDEPENDENTLY from nuno/psc winbuilder developers) proves that the documentation was NOT a failure.
• The fact that WinbuilderN documentation survives to this day and is published on multiple mediums, including .wiki, .chm and web/html (http://wb.paraglidernc.com/Help/) proves that is is NOT a failure.

Thanks for info with more reasons why wb documentation failed, I did not want to wrote more,
 but you insist to continue winbuilder and its documentation failure to success, since you are one of the author.

there are more....

I do not want to write more, but you decide to bend logic.

*
I already know wb help documents and its historic story.
Some part of old help documents is around here
http://ludovici.winbuilder.net/Tools/Help/
which was good enough to create PEBakery or for a new user, rest requires tests...
one help document or another does not have effect on PEBakery development.

Historic story is:
After paraglider decide to put his personal help document with chm and htm, which is used by all project at that time.
Nuno, instead of supporting paraglider help document (which Nuno do not like to),
 decide to open gate to another help document using wiki and followers (ex: homes32)
It is sure independent from nuno/psc  We know reasons behind..... Nuno can not write anything related since away from PE ~10 years and more. Peter Schang never support such help document, knowing it is unlogical.
And it is only fun to watch failure, psc (Peter Schang) implement , add/remove things which help document authors not aware 
At least old help document was better with provided info, but missing chm and search options that comes with chm.....

The only reason of wb help document on wiki was to put help button over wb that point to wiki instead of paraglider wb help document webpages project developers decide to put link on projects.
It was only fun to watch from here.

And evolution of wb wiki help document naturally ended long time ago.
Goal was to put competitive help document instead of paraglider's help document.
Goal success, end of wb wiki help document evolution.
 Ashes to ashes. Next : winbuilder.


As I wrote before:

, no need to live same bad experience again.

and no need to turn reality to other things Homes32.
If you truely believe what you wrote with list,
 than you also never understand why http://theoven.org created at first, why JFX Lancelot Galapo Chris kicked out.
   and you do not understand why there is now PEBakery.
     and you do not see what is coming in future.
--> This is something you can respond on another topic. Only relevant about current topic is your list contains lots of bended logic or "never understand things"

See you on next post.

I feel, In the end we can have a plugin ex: \Utils\Help Documents having upload button that uploads plugin to 6 servers  (+1 PEBakery server)
 + with updated help source + updating chm for zip distributions + updating web htm

Yes. this is exactly what will be possible with the way the help is being designed.
As the documents are in the repository alongside the code, they can be updated as features are added/removed and can be compiled automatically by the build process, viewed in their natural state, or fetched on demand by 3rd party and compiled to whatever you want. Funny how well "failed" processes work... 

If you find errors or omissions in the current PEBakery documentation and are uncomfortable making a pull request, please open a bug report on the git repository containing the information you believe is incorrect and what you think is should read, and I will be happy to make the corrections as time allows.

Idea yes, method no.
You intentionally avoid understanding reason behind of current topic.
Well better you spend your free time to update wb documentation anyway.

In conclusion, we both want the same thing, and that's is what development is working towards, so lets lets lay this topic to rest, I feel there is no more constructive discussion to be had on this particular thread.

well since first post I know you want to close, by mostly none constructive proofs of wb document failure to success.
no thanks.

Meanwhile you also provide some useful info, only thanks for them.


Your posts only provides more proof why we should follow Jonathan Bennett AutoIT help document organization instead of git hub help.
It is not important written in markdown or whatever, ied206 decides.

I like to see ChrisR back with updating help documents
and I like to see JFX back with new syntax updating help documents (ex: Autoit v2 to Autoit v3)


*
Homes32, I believe you make your point, and I responded so far.
Instead of testing new PEBakery and updating relevant plugins,
 I spend very valuable free time responding your posts.
    Reminding me shitland days people like to spend time to post instead of development.
     Not constructive at all.

Further about wb help documents, use Other World section.




*
So My request to ied206 for help document continues :

I hope you can start same way with PEBakery.
http://pebakery.cwcodes.net/PEBakery/docs

In my opinion, managing manual in github is better.

1. Can track changes later
Document's version can be tracked with no additional cost in github.
And github's diff function allow users to track which command is changed in document.

2. Easy to collaborate
Users and developers can submit patches via github pull request.
Doing this without git makes things hard.

3. Markdown can be compiled into HTML
Since makrdown is designed for HTML, I can compile manual in markdown to static html files easy.
To make things simple, compiled manual can be uploaded to cwcodes.net alongside test builds.
So while users can see lastest version of manual in github, they can grab a copy of stable manual in cwcodes.net.

Sounds like a good beginning.

http://pebakery.cwcodes.net/PEBakery/docs
is on your hands.

Galapo can help to automate things with git hub when required.
Let us know.