1. Roadmap to Euphoria 4.2
- Posted by ghaberek (admin) Aug 30, 2019
- 1561 views
While not complete, I have detail most of my plans for the 4.2 release here: Roadmap42
-Greg
2. Re: Roadmap to Euphoria 4.2
- Posted by euphoric (admin) Aug 30, 2019
- 1551 views
While not complete, I have detail most of my plans for the 4.2 release here: Roadmap42
I've found some typos in the docs... I'll try to remember to ticket those.
What do you most need help with that I or others could do?
3. Re: Roadmap to Euphoria 4.2
- Posted by ghaberek (admin) Aug 30, 2019
- 1581 views
What do you most need help with that I or others could do?
I need a volunteer to head up a separate project to review, audit, and update the documentation found in docs/*.txt and include/(std/)*.e, as well as the wiki.
I'd recommend whoever does this use a project board to keep things organized. I can create a new project for this if someone volunteers to move forward.
Additional volunteers could then pick up individual tasks on the project to review, update, and sign off on each one until we've gone through everything.
-Greg
4. Re: Roadmap to Euphoria 4.2
- Posted by petelomax Aug 30, 2019
- 1546 views
Q: Why compile some things into the backend and not others? Why not use CURL for all HTTP/FTP functions?
A: We need to maintain some balance and avoid including "everything but the kitchen sink" into the backend -- leading to a bloated and unportable executables. We should also avoid making everything an external library, which creates more strain on users to package and ship their own applications. Small libraries and high-priority libraries should be built into the backend. Large and low-priority libraries should be shipped separately.
Still not entirely clear. Presumably you could do everything via libcurl, but you want some http/ftp functionality in the backend, w/o needing any external libs/dll/so? If so, can you be more specific on what you plan to embed in the backend?
5. Re: Roadmap to Euphoria 4.2
- Posted by irv Aug 30, 2019
- 1554 views
I'm wondering about the "include complete binaries" along with the wrappers for various things. Could there be problems with this? One I can foresee is - considering the slowness of Euphoria updates, a download of Eu is likely to contain an older version of lib n than is on the user's computer (if they do regular updates).
That means there'll need to be a "smart" installer for each platform to prevent overwriting the new with the old. Even if the binaries are kept in a separate directory, and only used by Eu, somebody is going to have to keep the eu version more or less up to date with the developers version, because people are going to use the developers' documentation and wonder why Eu "won't do x".
Or am I wrong about this and missing something?
Secondly, what about libraries which are still "works in progress", according to their developers?
"libui is currently mid-alpha software. Much of what is currently present runs stabily enough for the examples and perhaps some small programs to work, but the stability is still a work-in-progress, much of what is already there is not feature-complete, some of it will be buggy on certain platforms, and there's a lot of stuff missing."
That's fine, and it will hopefully be updated "real soon". But will whoever maintains the Eu packages keep up as well? Will there need to be a new Eu version every six months, or what? Need some clarification, please.
I'm not saying these are bad ideas, just wondering if I have missed something here.
6. Re: Roadmap to Euphoria 4.2
- Posted by ghaberek (admin) Aug 30, 2019
- 1548 views
Presumably you could do everything via libcurl
We'll make libcurl available for those who want to use it directly.
but you want some http/ftp functionality in the backend, w/o needing any external libs/dll/so?
That is not correct. Sorry if this was confusing. I just want to make it so applications that already use std/net/http.e routines don't have to suddenly start requiring libcurl.
This can be done on Windows by using WinInet, and on *NIX by using the system libcurl. On Linux/BSD that's [apt|yum|pkg] install away, and OS X provides libcurl out of the box.
If all else fails, we'll fall back to the original HTTP-only routines and throw ERR_HTTPS_UNAVAILABLE when HTTPS requests are made. Thus, we keep the old and add the new.
If so, can you be more specific on what you plan to embed in the backend?
My intent was to follow the in the line of using PCRE for std/regex.e and pick third-party libraries to add features without adding bloat.
Anything that is a "must have" feature would be baked in. Anything that's "too big" to compile in should be shipped as a shared library.
I think my current choice of features (JSON, XML, ZIP, etc.) are "must haves" and I've picked libraries that are stable and quite small.
My motivation for these features is based on the past several years of discussion on the forum. I think we need to ship features that people need.
-Greg
7. Re: Roadmap to Euphoria 4.2
- Posted by ghaberek (admin) Aug 30, 2019
- 1599 views
I'm wondering about the "include complete binaries" along with the wrappers for various things. Could there be problems with this? One I can foresee is - considering the slowness of Euphoria updates, a download of Eu is likely to contain an older version of lib n than is on the user's computer (if they do regular updates).
Oops, sorry, I was copy/pasting between lines and I missed that. I didn't mean to say "on all platforms" for all the external libraries. We should ship libcurl and libssh2 on Windows, but they're going to have to be apt/yum/pkg/brew installed in order to work on all *NIX flavors. Both of those have not had any ABI compatibility changes to date. (see libssh2, libcurl). Do you foresee any issues with compatibility for these?
That means there'll need to be a "smart" installer for each platform to prevent overwriting the new with the old. Even if the binaries are kept in a separate directory, and only used by Eu, somebody is going to have to keep the eu version more or less up to date with the developers version, because people are going to use the developers' documentation and wonder why Eu "won't do x".
Or am I wrong about this and missing something?
I plan to pull in the documentation to Euphoria's docs as well, and I think my comment and question above also apply here.
Secondly, what about libraries which are still "works in progress", according to their developers?
"libui is currently mid-alpha software. Much of what is currently present runs stabily enough for the examples and perhaps some small programs to work, but the stability is still a work-in-progress, much of what is already there is not feature-complete, some of it will be buggy on certain platforms, and there's a lot of stuff missing."
I didn't just pick libui arbitrarily; I've been following that project since it started. Part of the reason I picked that over something like IUP is because it's had a relatively slow release history. I liked IUP for this but they release a new versions about every six months, and it could be entirely different by the time we do another release. Edit to add: also, IUP only supports Windows and Linux, while libui supports Windows, Linux, and OS X. Unsure about BSD flavors.
My goal is to provide an absolute basic GUI library, akin to how Python includes tkinter. It's not pretty, and it's not great, but it's shipped by default and works right out of the box.
That's fine, and it will hopefully be updated "real soon". But will whoever maintains the Eu packages keep up as well? Will there need to be a new Eu version every six months, or what? Need some clarification, please.
I'm not saying these are bad ideas, just wondering if I have missed something here.
I'm not going to commit to anything beyond this next release. I don't know what the future holds and I don't want to make promises I can't keep. Eventually I think we need to adopt or develop a package manager that can suit our needs directly. Keeping library "packages" separate from language "releases" would lessen the burden if shipping the either one in a timely manner.
-Greg
8. Re: Roadmap to Euphoria 4.2
- Posted by _tom (admin) Sep 04, 2019
- 1492 views
What do you most need help with that I or others could do?
I need a volunteer to head up a separate project to review, audit, and update the documentation found in docs/*.txt and include/(std/)*.e, as well as the wiki.
I'd recommend whoever does this use a project board to keep things organized. I can create a new project for this if someone volunteers to move forward.
Additional volunteers could then pick up individual tasks on the project to review, update, and sign off on each one until we've gone through everything.
-Greg
Go ahead and create the docs project board.
Is there going to be a oE4.1.1 release? (Kind of a practice run?)
Installation could give you these options:
- doc/tutorial only; for mildly curious
- language only; to get going with minimal effort
- fully charged: language, WEE, euGTK, compiler?
The docs have these components:
| language | fully charged | gui | learning |
| traditional value:action:flow technical |
built-ins std/lib add-on libraries contributed |
euGTK others ? |
tutorial examples |
help is needed for any item mentioned
traditional described in same language/examples as in conventional languages
simplified using value:action:flow metaphor
technical bnf notation, comp sci viewpoint
built-in any feature that does not require external files.
std/lib include files that already exist
add-on libraries that require user to have .dll/.so files installed
contributed like wrappers for game libraries; of general interest; but not supported by the language developers
euGTK the most universal gui for oE right now
IUP has dropped 32 bit; messy libraries that change with each Linux kernal
tk works everywhere; oE and Phix
tutorial more examples; more tutorials
Phix show similarities and differences
wiki needs
must allow greater file size for each link than provided right now; 100 lines is not enough capacity
wanted... alternative to CHM documentation format
_tom
9. Re: Roadmap to Euphoria 4.2
- Posted by irv Sep 04, 2019
- 1470 views
Alternative to CHM - how about html? It's pretty well proven, and people can read that on any platform, including their phones and watches.
In my opinion, the current docs are a bit too "technical" for newcomers. Like diving in head first.
More demos would be more friendly. And pictures. When I hear about a new programming language, one of the things I do is look to see if there are pictures of applications written in that language (not necessarily commercial apps). If I like what I see, I then look at the source code to see how much work it takes to achieve those results.
10. Re: Roadmap to Euphoria 4.2
- Posted by _tom (admin) Sep 04, 2019
- 1475 views
Alternative to CHM - how about html? It's pretty well proven, and people can read that on any platform, including their phones and watches.
The Phix docs use CHM and searching works well. I would like to emulate this option (in addtion to PDF and htm).
The curse is creating them (I do not want to use the actual CHM format) and then viewing them on Linux.
In my opinion, the current docs are a bit too "technical" for newcomers. Like diving in head first.
This is from April! It got 520 hits! I also got no feedback!
I made an introductory tutorial for Phix
https://drive.google.com/open?id=1OOUkO_zrPZDsqvZDO6pzg9XUZfTAYPyb
Phix is a bit easier to introduce to new programmers than oE.
Very beta stage.
................
Consider this an invitation for everyone to start by creating a couple of introductions to oE under the theme of simpler | smarter | speedier.
(Everyone says their language is "simple", that means oE and Phix must be simpler.)
More demos would be more friendly. And pictures. When I hear about a new programming language, one of the things I do is look to see if there are pictures of applications written in that language (not necessarily commercial apps). If I like what I see, I then look at the source code to see how much work it takes to achieve those results.
I see oE and euGTK as inseparable. You are invited to create a chapter on "things to do with oE/euGTK" with lots of pictures! It most certainly needs to be part of the updated docs.
_tom
11. Re: Roadmap to Euphoria 4.2
- Posted by irv Sep 04, 2019
- 1438 views
If we expect people to help, we need to use a format that everyone can use. Both to view, and to create the docs.
Which means a standard format, with help viewers available for the various platforms, and help creators available for the various platforms which can create platform-agnostic help files.
Preferably a program to create help files which can be installed without downloading a huge toolchain with the attendant learning curve, if there's a choice.
Suggestions?
Oh, by they way "Why isn't it written in Euphoria/Phix?" is sure to be one of the first questions someone asks.
12. Re: Roadmap to Euphoria 4.2
- Posted by ghaberek (admin) Sep 04, 2019
- 1476 views
If we expect people to help, we need to use a format that everyone can use. Both to view, and to create the docs.
Which means a standard format, with help viewers available for the various platforms, and help creators available for the various platforms which can create platform-agnostic help files.
We already have a toolchain for creating docs: creole and eudoc. The problem is, nobody's touched the code in years, and creole support is getting harder and harder to find. Markdown seems to have that format war.
Preferably a program to create help files which can be installed without downloading a huge toolchain with the attendant learning curve, if there's a choice.
I've found most "generic" documentation generators, like Doxygen, are only generic to curly-brace languages. And most other popular languages have their own generator, like Sphinx for Python.
Suggestions?
Move to markdown. Parse docs into an intermediate format, like EDS or SQLite. Have pluggable output generators, and default to HTML.
Oh, by they way "Why isn't it written in Euphoria/Phix?" is sure to be one of the first questions someone asks.
It is likely this will continue to be written in Euphoria.
ll that being said, I don't think it's time to move to a new documentation system. Let's focus on the correctness of what we've got now, and revisit that after a release.
-Greg
13. Re: Roadmap to Euphoria 4.2
- Posted by irv Sep 05, 2019
- 1416 views
Watcom no longer works. Hasn't in years. (For 4.1)
Yet the manual indicates otherwise:
6.4.2 C Compilers Supported
The Translator currently works with GNU C on Unix-like OSes, GNU C on Windows from MinGW or Cygwin using the -gcc option and with Watcom C (the default) on Windows. These are all free compilers.
GNU C will exist already on your Unix system. The others can be downloaded from their respective Web sites.
... So two corrections are needed in that one section.
It hasn't been changed, even though parts have been inaccurate "for years".
So, sorry if this seems rude, but why should we spend a lot of time checking and correcting the docs if even this small but important correction hasn't been made in years?
Suggestion: give me the necessary passwords to edit the on-line docs, and I'll fix that, as well as making other corrections people post here (once discussed and agreed upon). As far as I can tell, most programming languages have their most up-to-date documentation on-line - not with the download. Which only seems reasonable. People can't find and document bugs until the release has been used.
14. Re: Roadmap to Euphoria 4.2
- Posted by _tom (admin) Sep 05, 2019
- 1418 views
Not being able to edit online docs has been a mystery for a long time. I understood, from a long time ago, that I could not edit them or easily download updates--result is they have been ignored.
At the moment I have started to make a clone of the std/lib docs in the wiki; problem is I have to cut and paste each page and progress is very slow.
Direct editing of the online docs would solve a lot of problems!
_tom
15. Re: Roadmap to Euphoria 4.2
- Posted by irv Sep 05, 2019
- 1380 views
Not being able to edit online docs has been a mystery for a long time. I understood, from a long time ago, that I could not edit them or easily download updates--result is they have been ignored.
At the moment I have started to make a clone of the std/lib docs in the wiki; problem is I have to cut and paste each page and progress is very slow.
Direct editing of the online docs would solve a lot of problems!
_tom
And worse, if I understand it correctly, the docs are generated from comments in the source code. Which means unless they are corrected there as well, the next time the docs are generated, they revert to the old version. This is known in the engineering field as PPP.
16. Re: Roadmap to Euphoria 4.2
- Posted by _tom (admin) Sep 05, 2019
- 1406 views
ll that being said, I don't think it's time to move to a new documentation system. Let's focus on the correctness of what we've got now, and revisit that after a release.
-Greg
eudoc/creole works to create docs for
- wiki html
- pdf (via wkhtmltopdf)
nothing wrong with creole markup syntax because it was designed to be generic and intuitive
The missing final step is to provide a single download so users can have offline html docs that provide:
- tree navigation
- better searching
- indexing
The CHM format takes html and puts into a single download--with navigation and searching. The curse is: even Microsoft has abandoned the format, Microsoft makes it messy to create; CHM was never fully adopted by Linux. CHM is not an obvious solution to docs even if Phix uses it.
the workflow for creating docs does not have to change--only a few improvements can come later
_tom
17. Re: Roadmap to Euphoria 4.2
- Posted by ghaberek (admin) Sep 05, 2019
- 1391 views
It hasn't been changed, even though parts have been inaccurate "for years".
The online docs are for Euphoria 4.0 and Watcom still works for that version, so the documentation is not wrong. Watcom support was dropped for version 4.1 and later.
So, sorry if this seems rude, but why should we spend a lot of time checking and correcting the docs if even this small but important correction hasn't been made in years?
Because nobody's ever done an actual 4.1 release? And part of getting a release out is double-checking the documentation to ensure it's correct. Which is what I'm asking for help with.
Suggestion: give me the necessary passwords to edit the on-line docs, and I'll fix that, as well as making other corrections people post here (once discussed and agreed upon).
There is nothing to give. The online documentation is just a published version of the docs supplied with each release. As it stands, the online docs will be updated when a release is published.
As far as I can tell, most programming languages have their most up-to-date documentation on-line - not with the download. Which only seems reasonable. People can't find and document bugs until the release has been used.
It seems to me that this would create a chicken-and-egg problem. Which is the source of truth, the docs or the code comments? Generating the docs from the comments seems like the best solution here.
-Greg
18. Re: Roadmap to Euphoria 4.2
- Posted by _tom (admin) Sep 05, 2019
- 1399 views
And worse, if I understand it correctly, the docs are generated from comments in the source code. Which means unless they are corrected there as well, the next time the docs are generated, they revert to the old version.
The std/lib docs are written directly into the source-code. The eudoc program separates the documentation from the source-code and saves the contents as a .txt file. Because documentation is written using creole markup, the creole program can convert the text docs into html. Given html files I can convert them into a pdf using wkhtmltopdf.
The remaining docs are individual .txt files using creole formatting. Eudoc can be used to combine all .txt files (individual and from std/lib) into complete documentation. Then creole does the txt to html conversion.
This all works even if it sounds convoluted.
_tom
19. Re: Roadmap to Euphoria 4.2
- Posted by ghaberek (admin) Sep 05, 2019
- 1433 views
Not being able to edit online docs has been a mystery for a long time. I understood, from a long time ago, that I could not edit them or easily download updates--result is they have been ignored.
At the moment I have started to make a clone of the std/lib docs in the wiki; problem is I have to cut and paste each page and progress is very slow.
Direct editing of the online docs would solve a lot of problems!
It seems I've been unclear in my request for assistance in auditing the documentation.
To be clear: the documentation is generated from the code in include/std and the text files in docs/ (refman_2.txt, etc.). The only way to update the docs is to edit these files.
Here is the approximate workflow you'll need:
- Check out the Euphoria source code from GitHub.*
- Generate the HTML docs using eudoc and creole.
- Open the HTML docs in your browser and review.
- Make your corrections to the source or text files.
- Commit your changes to your local git repo.
- Repeat steps 2-5 until you're done.
- Push your commits back to GitHub.*
* Ideally you should create a fork, push your changes there, and then create a pull request.
-Greg
Forked into: Help With Editing the Euphoria Documentation
20. Re: Roadmap to Euphoria 4.2
- Posted by _tom (admin) Sep 05, 2019
- 1389 views
[quote ghaberek]
It hasn't been changed, even though parts have been inaccurate "for years".
The online docs are for Euphoria 4.0 and Watcom still works for that version, so the documentation is not wrong. Watcom support was dropped for version 4.1 and later.
So, sorry if this seems rude, but why should we spend a lot of time checking and correcting the docs if even this small but important correction hasn't been made in years?
Because nobody's ever done an actual 4.1 release? And part of getting a release out is double-checking the documentation to ensure it's correct. Which is what I'm asking for help with.
Suggestion: give me the necessary passwords to edit the on-line docs, and I'll fix that, as well as making other corrections people post here (once discussed and agreed upon).
There is nothing to give. The online documentation is just a published version of the docs supplied with each release. As it stands, the online docs will be updated when a release is published.
As far as I can tell, most programming languages have their most up-to-date documentation on-line - not with the download. Which only seems reasonable. People can't find and document bugs until the release has been used.
It seems to me that this would create a chicken-and-egg problem. Which is the source of truth, the docs or the code comments? Generating the docs from the comments seems like the best solution here.
It is an old mantra that the source-code is the documentation. Documentation as side-cars tends to get lost.
There is nothing to give. The online documentation is just a published version of the docs supplied with each release. As it stands, the online docs will be updated when a release is published.
How difficult would it be to create a clone of the on-line docs so we can edit them? So one set is as-is, the second set (clearly identified) is for user editing.
If you do no have a quick solution I will create a set in the wiki using the laborious cut-and-paste methond.
_tom
21. Re: Roadmap to Euphoria 4.2
- Posted by irv Sep 05, 2019
- 1388 views
For Linux, I can find only two CHM viewers which haven't been abandoned long ago: xchm and kchmviewer. The latter requires KDE to be installed, which is an 89meg download! And KDE has always looked ugly to me.
xchm works (as far as I can tell - how would I know if some parts weren't working or some features that Phix depends upon aren't implemented?)
The auto-creation of an index is nice to have, but for my html/eu editor Bear, I have created an index of Euphoria keywords more or less automatically from the docs. It took only a small amount of editing. It would not be particularly difficult to add a sorted list of libraries/functions as a sidebar.
22. Re: Roadmap to Euphoria 4.2
- Posted by _tom (admin) Sep 05, 2019
- 1396 views
It seems I've been unclear in my request for assistance in auditing the documentation.
I was comfortable with Mercurial (the old way) and have not yet switched to Git thinking. But yes, I get the gist of the process, and yes I will be using it to help with the docs update.
Yes, anything done in the wiki and formum has to be manually added to the Git repository and then checked again.
What Irv and I are going for is a platform that anyone can edit and contribute to the docs. My current solution is to clone the docs into the wiki which allows anyone to edit them. I have started to do this but ran into fatigue problems. If you can not do this easily I will continue until I have editable wiki docs.
Then the process would be to download the wiki, do a diff to see what editing changes have occurred, then copy the changes to the source-code, then have a set of docs that have to be reviewed, ....
This will work!
_tom
23. Re: Roadmap to Euphoria 4.2
- Posted by ghaberek (admin) Sep 05, 2019
- 1444 views
nothing wrong with creole markup syntax because it was designed to be generic and intuitive
There's nothing wrong with Creole itself. The problem is that the world seems to have forgotten about it, including its original authors. There have been no updates to the Creole website for over ten years.
Meanwhile Markdown, which predates Creole by a few years, has been continuously adopted, improved, and standardized (in the form of CommonMark) and is now in very wide use all over the world.
So as I stated, I think Markdown has won that format war and it's one of many things we need to adapt to if we want to stay relevant and attract new users and developers.
The missing final step is to provide a single download so users can have offline html docs that provide:
- tree navigation
- better searching
- indexing
I think these are all good improvements worthy of a new documentation system. I just don't think now is the time to upend the documentation.
The CHM format takes html and puts into a single download--with navigation and searching. The curse is: even Microsoft has abandoned the format, Microsoft makes it messy to create; CHM was never fully adopted by Linux. CHM is not an obvious solution to docs even if Phix uses it.
I don't think CHM is a good idea. I think HTML should be the main format for documentation.
One idea I suggested earlier was to store the documentation in an intermediate format, a database like EDS or SQLite.
We could use that to ship a help browser application similar to CHM. I wrote something like this fifteen years ago, called Help File Maker (see The Archive).
This is part of my motivation for trying to bundle a basic GUI library with a Euphoria release: it would be helpful to have some GUI utilities bundled in the distribution.
-Greg
24. Re: Roadmap to Euphoria 4.2
- Posted by _tom (admin) Sep 05, 2019
- 1378 views
For Linux, I can find only two CHM viewers which haven't been abandoned long ago: xchm and kchmviewer. The latter requires KDE to be installed, which is an 89meg download! And KDE has always looked ugly to me.
xchm works (as far as I can tell - how would I know if some parts weren't working or some features that Phix depends upon aren't implemented?)
The auto-creation of an index is nice to have, but for my html/eu editor Bear, I have created an index of Euphoria keywords more or less automatically from the docs. It took only a small amount of editing. It would not be particularly difficult to add a sorted list of libraries/functions as a sidebar.
The Bear will be the solution for oE docs. Docs would then be available as: txt, html, pdf, and bear.
I have gone through most of the CHM creator/view options and concluded that none are Linux friendly. To view Phix docs I use xchm.
My secret agenda is to unify oE and Phix documentation. I do not wish oE and Phix to be clones of each other--that kills creativity. But I do wish to make it easier for anyone to appreciate what oE and Phix can do.
_tom
25. Re: Roadmap to Euphoria 4.2
- Posted by _tom (admin) Sep 05, 2019
- 1388 views
Can you create a clone of the existing docs--with minimal effort--as a forked wiki page?
I you can not, then I will continue to use cut-and-paste to do it myself.
_tom
26. Re: Roadmap to Euphoria 4.2
- Posted by irv Sep 05, 2019
- 1380 views
If the source code is the documentation, then the source code needs to be up to date and correct.
Which means updating the source code, re-generating all documentation created by that source code and updating the website.
Every time an error or omission is found in the docs.
Every time a bug is discovered.
Every time Windows or Linux or Watcom or whoever changes something.
When that happens, a new release must be prepared.
If all this is done in a timely manner, then the idea should work.
Even though there is a logical flaw in thinking that it can ever be completely correct. Perfection eludes us humans.
Wouldn't it be a whole lot easier to correct the docs online?
27. Re: Roadmap to Euphoria 4.2
- Posted by irv Sep 05, 2019
- 1394 views
It hasn't been changed, even though parts have been inaccurate "for years".
The online docs are for Euphoria 4.0 and Watcom still works for that version, so the documentation is not wrong. Watcom support was dropped for version 4.1 and later.
Sorry, but the documentation I found on line makes no mention that Watcom doesn't work for 4.1. Where, exactly is that?
If it's not there, and we can't add a simple line of text to a web page, then I think we're hopelessly incompetent. So would anyone else.
28. Re: Roadmap to Euphoria 4.2
- Posted by ghaberek (admin) Sep 05, 2019
- 1349 views
Sorry, but the documentation I found on line makes no mention that Watcom doesn't work for 4.1. Where, exactly is that?
It's not been put into the documentation yet. Any number of other things are also out of date. This is exactly why I'm asking for help!
If it's not there, and we can't add a simple line of text to a web page, then I think we're hopelessly incompetent. So would anyone else.
I'm sorry you feel that way. But you're complaining about the very thing I'm asking for help with. Are you volunteering to help fix these errors?
-Greg
29. Re: Roadmap to Euphoria 4.2
- Posted by _tom (admin) Sep 05, 2019
- 1363 views
Simple, we must be able to edit the online docs.
So, can you make a clone of docs that are editable on the wiki? If not, then I will use copy-paste to make such a copy.
_tom
