,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2020-11-29 06:32:26 MitraArdron wrote: | comment - Query re status; and minor comments | see: https://forth-standard.org/proposals/multi-tasking-proposal#contribution-167 `------------------------------------------ I'm wondering whether this proposal is going somewhere, or was just Andrew's idea ? I don't see serious problems with it, but I'd prefer to only implement one version of multitasking in webForth, but I'm also not seeing any movement for two years? Minor issues with the proposal .... I think "INIT-TASK" makes more sense than "CONSTRUCT" for consistency. ATOMIC! - I'm not quite sure what the point of this is? I'm presuming you mean that the Store can't be interrupted between starting to write and ending (for example if its writing a cell to multiple bytes). But in that case, I would presume that every ! in the core forth words should be an ATOMIC! . If that is not the meaning, then maybe it needs some explanation. (ATOMIC@ has the ame issue; ATOMIC-XCHG and ATOMIC-CAS seem fine to me) MUTEX - I'd suggest MUTEXGET MUTEXRELEASE because GET is too common a word not to cause clashes? USER variables seem to be a problem for me - I'm starting with eForth so there are about 40 already, Of those roughly 6 are directly needed to switch tasks (0..3 and SP0, RP0). Almost all the rest are are only relevant if the task has access to I/O or is reading and interpreting/compiling text (?KEY 'EMIT 'EXPECT 'TAP 'ECHO 'PROMPT temp SPAN >IN #TIB 'EVAL 'NUMBER HLD CONTEXT+ 8 CURRENT CP NP LAST BASE) So there is a lot of memory overhead 27 * cellsize bytes per task. If we are going to standardise, wouldn't it be good to be able to do lightweight (no I/O) tasks as well? ,---------. | Replies | `---------´ ,------------------------------------------ | 2020-11-28 01:21:15 MitchBradley replies: | comment - Data type for strings | see: https://forth-standard.org/standard/usage#reply-573 `------------------------------------------ In my own code, I use $ in stack diagrams to denote an "adr len" string. ,------------------------------------------ | 2020-11-28 09:06:42 veltas replies: | comment - Data type for strings | see: https://forth-standard.org/standard/usage#reply-574 `------------------------------------------ I think it would be convenient, and any shortening like this might help reading and interpretation of the standard. People might not be familiar with that notation and it would add a bit more confusion/work to Forthers that decide to check out the standard occasionally. It could not be used everywhere because some Forth words do not use *c-addr u* pairwise, for example `CMOVE` has ( *c-addr1* *c-addr2* *u* -- ), so would probably be left as-is. Then at a glance it might look like `CMOVE` operates on different things entirely to `COMPARE`, so I think in that regard it might not improve readability. I think if we add this shortening then counted strings deserve a different stack notation too, I think it would make stack notation much more useful, e.g. `COUNT` could have ( *sx* -- *sd* ) where *sx* is a hypothetical counted string address, instead of the current ( *c-addr* -- *c-addr* *u* ), where perhaps it is obvious the left is a counted string, but that kind of interpretation is not consistent e.g. with `CMOVE` stack notation where *c-addr1* appears on its own. I think I lean towards adding this change because it is factoring, and I think the benefits of factoring usually outweigh the perceived concerns. ,------------------------------------------ | 2020-11-28 11:28:08 AntonErtl replies: | comment - Data type for strings | see: https://forth-standard.org/standard/usage#reply-575 `------------------------------------------ It seems to me that in the standard most uses of c-addr u then refer individually to c-addr and u in the description, so one would have to also specify how to refer to the components of a string descriptor; e.g., if you have a string str1, the components might be str1a and str1u. In the standard document, I think that the costs of such a change are bigger than the benefits. In the larger Forth world, though, such a convention could be well worth it. ,------------------------------------------ | 2020-11-28 11:48:07 ruv replies: | comment - Data type for strings | see: https://forth-standard.org/standard/usage#reply-576 `------------------------------------------ I use _d-txt_ for that. Although, I don't happy with _d_ part, _xd-txt_ would be more correct. And a better variant should be something shorter. _$_ is not an alphabetical character, but all other data type symbols are alphabetical. So I would prefer an alphabetical symbol for strings too. ,------------------------------------------ | 2020-11-28 14:07:05 ruv replies: | comment - Data type for strings | see: https://forth-standard.org/standard/usage#reply-577 `------------------------------------------ > In the standard document, I think that the costs of such a change are bigger than the benefits. Yes, I also don't think it's worth to change the glossary entries. It's worth to find and just specify an alternative form for strings in the Table 3.1: Data types, and add the corresponding note in 3.1.4.2 Character strings. ,------------------------------------------ | 2020-11-28 19:19:56 MarcosCruz replies: | proposal - XML Forth Standard - migration from LaTeX to DocBook | see: https://forth-standard.org/proposals/xml-forth-standard-migration-from-latex-to-docbook#reply-578 `------------------------------------------ After trying other options, I use almost only [Asciidoctor](https://asciidoctor.org) for any type of documentation, including books and manuals. It's an improved implementation and converter of the [AsciiDoc](https://asciidoctor.org/docs/what-is-asciidoc/) markup, whose main goal is to represent all features of DocBook using a light and readable ASCII markup. Currently an Asciidoctor document can be converted directly into DocBook, HTML, PDF, EPUB, manpage... Other conversions are possible from DocBook, for example using [Pandoc](http://pandoc.org). I've been using Asciidoctor for years and I find it much easier and productive than working directly with XML, and much more powerful than any other markup I have tried.