Hi Jon,
On 27.10.2025 16:42, Sahananda wrote:
I have read this, and I don't think that I can answer it quickly. It is more about project
management and who makes the decision what goes into the language than anything technical.
Where it is just a case of Josep Maria correcting mistakes in and improving the documentation
(many thanks) I can make the judgement on readability, but I can't really say anything about
technical correctness as most of these changes are in areas I'm unfamiliar with or I would need to
spend time getting to know the context.
As it is, I did not build the documentation with Josep Maria's patches, just judged the
readability on the basis of the source xml.
Would it help, if someone would post a +1 with the tracker item then?
Were it native code, I would not be capable of 'judging' the merit or otherwise of a change to a
C++ segment.
When you requested someone to promote those 4 patches, I was happy to do it on the basis that I
was just saving you some time with the mechanics of applying the patches which I assumed you had
already judged the merits of. Later it became clear that P.O. could do it if I parsed the English.
In principle, and time permitting, I am happy to take on the mechanics of applying patches if that
frees resource from those like yourself capable of developing the code, but I do not want, without
discussion, to create a precedent that leads to an unguarded way into the source code.
Thank you for this attitude, I really mean it!
OTOH, there are quite a few tracker items where I think that you or P.O. would be able to
confidently handle them on your own. You are both very knowledgeable ooRexx "users" for many, many
years with a lot of experience!
It would be of great help, if the tracker items could be reduced as much as possible, either by
applying patches, assess the reasoning and if you have an educated disagreement, then do not accept,
otherwise if you have an educated agreement, then please agree (and maybe apply, fix), and if
undecided, post a follow-up hinting at the need to have an additional assessment. (This would be
really very helpful!)
If it was left to me, I have sufficient regard for Josep Maria, and knowing that he is active on
the developers list and the ARB that I would invite him to become a committer.
+1
I'm not asking that you (Rony) in particular solve this, and I do not have a particular proposal
for how to solve it. I just wanted to flag up my concern.
Thank you very much, Jon!
I hope that is clearer
Very much so!
Best regards
---rony
On Sat, 25 Oct 2025 at 21:52, Rony G Flatscher <[email protected]> wrote:
Hi Jon and P.O.,
would it maybe possible that you come up with a brief draft, suggestion?
This way it wiuld
probabky gelp the most and allow eg. Myself to better unddrstand the
problem and possible
solutions.
Cheers
—-rony
Rony G. Flatscher (mobil/e)
Am 25.10.2025 um 20:38 schrieb P.O. Jonsson <[email protected]>:
Dear Rony,
It is not just about the mechanics of applying a patch. What I think Jon is
hinting at are
guidelines for who and under what conditions parched are accepted.
IMO it should really be up to the core developers if a patch should be
allowed or not. If it
is just about linguistic problems Jon may be in a position to help out
(whereas I would
prefer not to since I am not a native speaker).
So some guidelines would be welcome indeed.
Hälsningar/Regards/Grüsse,
P.O. Jonsson
[email protected]
Am 25.10.2025 um 15:53 schrieb Rony G. Flatscher <[email protected]>:
On 25.10.2025 15:24, Sahananda wrote:
I have been thinking about this. If I apply a patch I am actually
reviewing the providers
work.
We should really have some guidelines about this.
Just because I was given committer status a decade ago, doesn't mean that I
have an
overview of all the changes that are going on nor that I can necessarily be
the arbiter of
whether a patch should be committed or not nor whether it would need
falling back.
I feel it would be helpful to me to have clearly stated procedures for
accepting/rejecting/committing patches.
How about this for creating patches:
* a patch should be created in the "trunk" directory
How about this for applying patches:
* a patch must be applicable from the "trunk" directory
* before applying a patch the command "svn update" should issued to get
the latest version
from Sourceforge
* then the patch should be applied locally with "svn patch
name-of-diff/patchfile" from
the "trunk" directory
o if there are problems, because there are overlapping changes with
commits that
occurred after the creation of the diff/patch file, then this
should be communicated
in the respective tracker entry;
+ the creator of the diff/patch can then do an "svn update" and
see where his
changes overlap with the newer text and can resolve them and
then create an
updated diff/patch file with "svn diff" and submit it
+ it may be the case that the problems are not complicated and
can be resolved on
the side of the applyer of the diff/patch file by inspecting
the mark-up that
"svn" applies
Here are two links that explain much better how svn conflicts can be
resolved:
* Tortoise (Windows):
<https://www.tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-conflicts.html>
<https://www.tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-conflicts.html>
* Command line (shown for Unix, but the command line is the same on
Windows):
<https://www.tutorialspoint.com/svn/svn_resolve_conflicts.htm>
<https://www.tutorialspoint.com/svn/svn_resolve_conflicts.htm>
There may be better explanations, tutorials on the net.
Hope that helps
---rony
On Sat, 25 Oct 2025 at 13:38, Rony G. Flatscher <[email protected]>
wrote:
One important hint about applying patches. It may be the case that in
the meantime
someone else committed changes. In order to make sure that everything
is alright, one
should always do a "svn update" before a "svn commit". This way one can
see before the
commit, whether there are areas which got concurrently changed, in
which case this
needs to be resolved. However, usually changes occur in different parts
of the code,
the documentation and the tests which svn should be able to handle (it
is able to
realize which version was used for the patch and infer any changes in
between and can
usually apply patches in full if they do not overlap).
---rony
On 24.10.2025 17:40, Sahananda wrote:
Hi All,
I think I am now in a position to apply patches.
I reinstalled Tortoise, and now I see a child dialog of the diff dialog
that I didn't
notice before allowing me to choose which patch to action (it was a
Hobsons Choice).
The dialog was off my screen apart from a tiny sliver, but once I
managed to grab it
and drag it onto the screen I could choose the patch and then the diff
was populated.
As P.O. had already applied the changes (thank you) and I had updated
to the post
change level while rebuilding my working copy to mirror Josep Maria's
there was now no
change left to apply, but I am confident that it would work in future.
As Rony says, the patch to be actioned should be placed in the folder
above what is
indicated in the Index: clause within the patch file. In this case,
the 'docs' folder.
Jon
On Fri, 24 Oct 2025 at 16:14, Rony G. Flatscher
<[email protected]> wrote:
First of all, thank you all *very* much for taking on the patches
and also all of
your work in the documentation/patch area!
Sorry to read that you had so many problems with it, maybe a few
words, hints:
* The path given at the beginning of the diff/patch files tells
one in which
directory the creator of the diff/patch was located; so if it
starts with
"trunk/rexxref/en-US/....xml", it must have been the "docs"
directory, so
Josep Maria had that from the Sourceforge project checked out,
but P.O. and
Jon did probably check out the doc's "trunk" directory (and all
its
subdirectories), but not the directory "docs" in which "trunk"
and the
"releases" are located. Therefore applying the patch did not
work.
* Maybe to ease handling, please create the diff/patches from within the
"trunk"
directory (underneath a possibly existing "docs" directory),
then the
diff/patch should start with "rexxref/en-US/....xml" instead
and one can apply
them from "trunk" then.
* Ad forward slashes: these should work on the Windows version of
svn as well.
Please keep up your great work!
---rony
On 24.10.2025 12:41, Josep Maria Blasco wrote:
The revision number shouldn't matter, as far as I know.
It was the current one when I uploaded the patches.
Regarding the paths, the instruction set I'm following reads
Once you are ready with the intended changes,
*go up to the root of the documentation* and issue "svn diff >
myPatchForChapter3.1.2.diff"
which will write all the changes to that text file. Submit that
diff-file
(patch-file) as a patch[...]
Maybe the boldfaced part explains the difference?
Josep Maria
Missatge de Sahananda <[email protected]> del dia dv., 24 d’oct.
2025 a les 10:47:
I would also be interested in an answer to this. I tried
creating a patch
locally and noted these differences from Josep Maria's patch.
The file references did not have paths.
My Working copy was at revision 13031 whilst Josep Maria's was
at 13026
I also note that Josep Maria's patch which contained directory
information
used '/' as the path separator.
Jon
My Header
Index: intro.xml
===================================================================
--- intro.xml (revision 13031)
+++ intro.xml (working copy)
Josep Maria's Header
Index: trunk/rexxref/en-US/intro.xml
===================================================================
--- trunk/rexxref/en-US/intro.xml (revision 13026)
+++ trunk/rexxref/en-US/intro.xml (working copy)
On Fri, 24 Oct 2025 at 08:15, ooRexx <[email protected]> wrote:
Dear all,
I wanted to apply the patches proposed by Josep Maria but
failed
miserably to do so. I have now applied the changes
indicated in
doc_bug_326.diff manually and that worked so there is
nothing wrong with
my SVN. I nevertheless would like to know why the patch did
not work.
Here is what I did:
% cd
/Users/jenkins/ooRexxSVN-Code-0/docs/trunk/rexxref/en-US
% svn update
Aktualisiere ».«:
Revision 13031.
% svn patch /Users/jenkins/Downloads/doc_bug_326.diff
C trunk/rexxref/en-US/instrc.xml
> Abschnitt @@ -2081,9 +2081,8 @@ zurückgewiesen
Konfliktübersicht:
Textkonflikte: 1
What am I doing wrong?
Is the patch not in the correct form?
Or do I have to perform the patches in a specific order?
I am on r13031 and the patch was made at r13026, does that
make a difference?
Here the rejection grounds
--- trunk/rexxref/en-US/instrc.xml
+++ trunk/rexxref/en-US/instrc.xml
@@ -2081,9 +2081,8 @@
in this case must be either
<computeroutput>SCIENTIFIC</computeroutput> or
<computeroutput>ENGINEERING</computeroutput>. You can omit
the subkeyword
VALUE if <emphasis role="italic">expression2</emphasis>
does not begin
with a
-symbol or a literal string,
-that is, if it starts with a special character, such as an
operator
character
-or parenthesis.</para>
+symbol, that is, if it starts with a string or a special
character,
+such as an operator character or parenthesis.</para>
<para>You can retrieve the current NUMERIC FORM setting
with the
<xref linkend="bifForm" xrefstyle="select:title"/>
built-in function.
</para>
Hälsningar/Regards/Grüsse,
ooRexx
[email protected]
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
--
--
__________________________________________________________________________________
Prof. Dr. Rony G. Flatscher, iR
Department Wirtschaftsinformatik und Operations Management
WU Wien
Welthandelsplatz 1
A-1020 Wien/Vienna, Austria/Europe
http://www.wu.ac.at
__________________________________________________________________________________
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
