Re: [Jgeneral] Wiki editing refusal

2022-05-11 Thread chris burke
This wiki config option seems relevant:

https://www.mediawiki.org/wiki/Manual:$wgObjectCacheSessionExpiry

We don't set this right now, and it defaults to 1 hour.
--
For information about J forums see http://www.jsoftware.com/forums.htm


Re: [Jgeneral] Wiki editing refusal

2022-05-11 Thread Henry Rich
Yeah, me too.  I tried earlier today to create a loss of data by using 
two browsers, but I couldn't.


Henry Rich


On 5/11/2022 3:42 PM, Devon McCormick wrote:

I usually do the first two steps Ian mentions - save all in the clipboard
and try again.  Lately I've gotten even lazier and just try again right
away and it hasn't failed in at least 10 tries.

On Wed, May 11, 2022 at 2:23 PM Ian Clark  wrote:


Recent Changes…
Thanks, Raul. That's a start. I'll give it a try next time it happens.
Trouble is, it's not a condition that can be triggered at will. At least, I
don't know how.

MediaWiki does a lot of logging, in so many different ways. When I have a
spare week I must study it more.

On Wed, 11 May 2022 at 19:04, Raul Miller  wrote:


The Recent Changes link on the left side of wiki pages is useful for
checking recent (potential) edits.

I know, I know, this sounds "obvious" but with so many competing
pieces of potentially useful information in front of us, "obvious" is
all-too-often in short supply.

I hope this helps,

--
Raul

On Wed, May 11, 2022 at 12:23 PM Ian Clark 

wrote:

I too would like a clear statement of best practice for recovering from
this situation. Maybe as a flowchart.

Whenever I see the warning message (usually after hitting "Save

changes")

my reflex action is to do what Bob recommends: scroll to the "editing

area"

and copy/paste it for emergency recovery. But it's so rarely necessary.
Usually it works to simply hit the "Save Changes" button a second time.

(If

I dare.)

On occasions when I've panicked (and thus forgotten how exactly I
responded) it's subsequently emerged that the server has actually
registered my changes and updated the page. But to verify this fact is

not

a simple task. If someone could only tell me how best to do it – as a
reflex action – the "demon warning" would no longer be an issue for me.

Good task-support for the task of recovery might include
-- a button which reliably copies the editing area to the system
pasteboard, not disruptable by a sick server or connection,
-- a confirmation message fom the server that the last "Save Changes"
button-click did not (logically) alter the page contents.

Ian

On Wed, 11 May 2022 at 16:51, Henry Rich  wrote:


I think it's simply a loss of your reservation after a timeout.
Wikipedia does the same.

When you start editing a page, you get rights to it for a short time
(maybe 5 min?).  After that, it's up for grabs.  When you repeat your
save, it goes through (parhaps after a check for conflict).

Henry Rich

On 5/11/2022 11:41 AM, 'robert therriault' via General wrote:

Before reloading the page, I would suggest copying your most recent

edits if you can.

Then if you lose the edits on reloading, you should be able go to

the

original page, edit and paste in your saved edits to continue on.

I have seen this as well, although not very often and I put it down

to

an interruption to my internet that might not be noticed by me on my
browser,

but was enough to disrupt the editing process within the wiki.

Cheers, bob


On May 11, 2022, at 08:33, Raul Miller 

wrote:

I suspect that that message means that your browser has lost track

of

a cookie or failed to perform a secondary request.

It does not seem to be a timeout. Or, if that message does

represent a

timeout, there are also other issues which can trigger the

problem:

Sometimes simply reloading the page has been sufficient to make

the

message go away.

I hope this helps,

--
Raul

On Tue, May 10, 2022 at 11:29 PM Arthur Anger <

artan...@comcast.net

wrote:

Now and then, after many minutes of making editing changes to a

Wiki

page, a Save request is greeted by:

   Sorry! We could not process your edit due to a loss of session

data.

   You might have been logged out.  . . .

Is this a timeout in the editor, and can it be lengthened?

Is this instead a result of temporary loss of communication,

which

does occur occasionally, but doesn't often have a visual effect

during

an

editing session?

I have sometimes managed to copy the edited page and reinstate it

later, but wonder if there is standard recovery procedure.

Thanks.
--Art


--

For information about J forums see

http://www.jsoftware.com/forums.htm
--

For information about J forums see

http://www.jsoftware.com/forums.htm
--

For information about J forums see

http://www.jsoftware.com/forums.htm


--
This email has been checked for viruses by AVG.
https://www.avg.com



--

For information about J forums see

http://www.jsoftware.com/forums.htm

--
For information about J forums see http://www.jsoftware.com/forums.htm


Re: [Jgeneral] Wiki editing refusal

2022-05-11 Thread Devon McCormick
I usually do the first two steps Ian mentions - save all in the clipboard
and try again.  Lately I've gotten even lazier and just try again right
away and it hasn't failed in at least 10 tries.

On Wed, May 11, 2022 at 2:23 PM Ian Clark  wrote:

> Recent Changes…
> Thanks, Raul. That's a start. I'll give it a try next time it happens.
> Trouble is, it's not a condition that can be triggered at will. At least, I
> don't know how.
>
> MediaWiki does a lot of logging, in so many different ways. When I have a
> spare week I must study it more.
>
> On Wed, 11 May 2022 at 19:04, Raul Miller  wrote:
>
> > The Recent Changes link on the left side of wiki pages is useful for
> > checking recent (potential) edits.
> >
> > I know, I know, this sounds "obvious" but with so many competing
> > pieces of potentially useful information in front of us, "obvious" is
> > all-too-often in short supply.
> >
> > I hope this helps,
> >
> > --
> > Raul
> >
> > On Wed, May 11, 2022 at 12:23 PM Ian Clark 
> wrote:
> > >
> > > I too would like a clear statement of best practice for recovering from
> > > this situation. Maybe as a flowchart.
> > >
> > > Whenever I see the warning message (usually after hitting "Save
> changes")
> > > my reflex action is to do what Bob recommends: scroll to the "editing
> > area"
> > > and copy/paste it for emergency recovery. But it's so rarely necessary.
> > > Usually it works to simply hit the "Save Changes" button a second time.
> > (If
> > > I dare.)
> > >
> > > On occasions when I've panicked (and thus forgotten how exactly I
> > > responded) it's subsequently emerged that the server has actually
> > > registered my changes and updated the page. But to verify this fact is
> > not
> > > a simple task. If someone could only tell me how best to do it – as a
> > > reflex action – the "demon warning" would no longer be an issue for me.
> > >
> > > Good task-support for the task of recovery might include
> > > -- a button which reliably copies the editing area to the system
> > > pasteboard, not disruptable by a sick server or connection,
> > > -- a confirmation message fom the server that the last "Save Changes"
> > > button-click did not (logically) alter the page contents.
> > >
> > > Ian
> > >
> > > On Wed, 11 May 2022 at 16:51, Henry Rich  wrote:
> > >
> > > > I think it's simply a loss of your reservation after a timeout.
> > > > Wikipedia does the same.
> > > >
> > > > When you start editing a page, you get rights to it for a short time
> > > > (maybe 5 min?).  After that, it's up for grabs.  When you repeat your
> > > > save, it goes through (parhaps after a check for conflict).
> > > >
> > > > Henry Rich
> > > >
> > > > On 5/11/2022 11:41 AM, 'robert therriault' via General wrote:
> > > > > Before reloading the page, I would suggest copying your most recent
> > > > edits if you can.
> > > > >
> > > > > Then if you lose the edits on reloading, you should be able go to
> the
> > > > original page, edit and paste in your saved edits to continue on.
> > > > >
> > > > > I have seen this as well, although not very often and I put it down
> > to
> > > > an interruption to my internet that might not be noticed by me on my
> > > > browser,
> > > > > but was enough to disrupt the editing process within the wiki.
> > > > >
> > > > > Cheers, bob
> > > > >
> > > > >> On May 11, 2022, at 08:33, Raul Miller 
> > wrote:
> > > > >>
> > > > >> I suspect that that message means that your browser has lost track
> > of
> > > > >> a cookie or failed to perform a secondary request.
> > > > >>
> > > > >> It does not seem to be a timeout. Or, if that message does
> > represent a
> > > > >> timeout, there are also other issues which can trigger the
> problem:
> > > > >> Sometimes simply reloading the page has been sufficient to make
> the
> > > > >> message go away.
> > > > >>
> > > > >> I hope this helps,
> > > > >>
> > > > >> --
> > > > >> Raul
> > > > >>
> > > > >> On Tue, May 10, 2022 at 11:29 PM Arthur Anger <
> artan...@comcast.net
> > >
> > > > wrote:
> > > > >>> Now and then, after many minutes of making editing changes to a
> > Wiki
> > > > page, a Save request is greeted by:
> > > > >>>   Sorry! We could not process your edit due to a loss of session
> > data.
> > > > >>>
> > > > >>>   You might have been logged out.  . . .
> > > > >>>
> > > > >>> Is this a timeout in the editor, and can it be lengthened?
> > > > >>>
> > > > >>> Is this instead a result of temporary loss of communication,
> which
> > > > does occur occasionally, but doesn't often have a visual effect
> during
> > an
> > > > editing session?
> > > > >>>
> > > > >>> I have sometimes managed to copy the edited page and reinstate it
> > > > later, but wonder if there is standard recovery procedure.
> > > > >>>
> > > > >>> Thanks.
> > > > >>> --Art
> > > > >>>
> > --
> > > > >>> For information about J forums see
> > http://www.jsoftware.com/forums.htm
> > > > >>
> > 

Re: [Jgeneral] J Playground test

2022-05-11 Thread 'robert therriault' via General
Okay, I think that I get it.

It looks like 't' is the only thing that triggers the incorrect message. When I 
have entered 'x' or 's' that does trigger a value error, so there is certainly 
something funny going on with 't'. And 't' continues to generate
++---++--+---++---+
|invalid name|not defined|noun|adverb|conjunction|verb|unknown|
++---++--+---++---+
until it is initialized, so it is not a first time encounter only issue. 

Cheers, bob


> On May 11, 2022, at 11:26, chris burke  wrote:
> 
> Bob
> 
> I still think this has nothing to do with the edit window.
> 
> When the Playground is first loaded, using t in Term should give a value
> error, not the boxed list that is shown. That t is also defined in the edit
> window is immaterial.
> 
> Chris
> 
> On Wed, May 11, 2022 at 11:18 AM 'robert therriault' via General <
> gene...@jsoftware.com> wrote:
> 
>> Yes, in that case you are initializing t and would be able to use it. I
>> only get the
>> 
>> ++---++--+---++---+
>> |invalid name|not defined|noun|adverb|conjunction|verb|unknown|
>> ++---++--+---++---+
>> 
>> message when I try to access a noun that has not been loaded and I believe
>> that the original problem was that t was not initialized when there was an
>> attempt to use it in the edit window.
>> 
>> If you are getting messages like that after initializing t then you are
>> seeing behaviour that I am not.
>> 
>> I'm sorry that I seem to have misunderstood some of your posts and have
>> not made myself as clear as I should have.
>> 
>> Cheers, bob
>> 
>>> On May 11, 2022, at 11:11, greg heil  wrote:
>>> 
>>> Bob
>>> 
>>> if run "t" from edit pane
>>> (ctrl-enter)
>>> is this not an
>>> initialization?
>>> 
>>> certainly
>>> i can put something in t
>>> and this overrides the default..
>>> 
>>> ~greg heil
>>> picsrp.github.io
>>> i.tgu.ca/real_cal
>>> twitter.com/g1h
>>> twitter.com/tweitku
>>> 
>>> --
>>> 
>>> from: 'robert therriault' via General 
>>> to: gene...@jsoftware.com
>>> date: May 11, 2022, 10:59 AM
>>> subject: Re: [Jgeneral] J Playground test
>>> 
>>> Hi greg,
>>> 
 I think you may be assuming that when you see the contents of the edit
>> window that it has been loaded. It is not automatically loaded, but is only
>> loaded when the user chooses to load it. I believe that is the
>> initialization that you are expecting.
>>> 
>>> Let me know if I have misunderstood.
>>> 
>>> Cheers, bob
>>> --
>>> For information about J forums see http://www.jsoftware.com/forums.htm
>> 
>> --
>> For information about J forums see http://www.jsoftware.com/forums.htm
>> 
> --
> For information about J forums see http://www.jsoftware.com/forums.htm

--
For information about J forums see http://www.jsoftware.com/forums.htm


Re: [Jgeneral] J Playground test

2022-05-11 Thread greg heil
Joe

Thanks for your
years of effort
on the playground!

so i do need to initialize variables
(system variables are "Global"?)

how do I similarly
initialize "helpplay_jws_"
so i, and Gilles,
can use the help facility?

~greg heil
picsrp.github.io
i.tgu.ca/real_cal
twitter.com/g1h
twitter.com/tweitku

--

from: Joe Bogner 
reply-to: gene...@jsoftware.com
to: gene...@jsoftware.com
date: May 11, 2022, 11:09 AM
subject: Re: [Jgeneral] J Playground test

>Thanks Bob and Chris/all. I confirmed my behavior is the same as bob's and is 
>working as I expect, but I can see how it could be confusing to a new user. 
>Having worked with JQT, I wouldn't expect to be able to type "t" without 
>running the script on the right side first to initialize t. The playground 
>edit window is the same as File->Open in JQT. In JQT it opens the file in a 
>separate window, whereas the playground opens it in the edit window (right 
>pane). That script is not run until the user runs it

>I also agree it'd be nice to have a toggle for "Toggle Edit Window" under 
>"View" which would enable the user to hide it when they are using the Labs (or 
>we automatically hide it). I've added it as an enhancement

https://github.com/jsoftware/j-playground/issues/51

--

from: 'robert therriault' via General 
reply-to: gene...@jsoftware.com
to: General forum 
date: May 11, 2022, 10:53 AM
subject: Re: [Jgeneral] J Playground test

Hi Chris,

>I can use the terminal window before loading the edit window, but I won't be 
>able to access the variables declared in the edit window until it is run, 
>which I think is reasonable behaviour.

>The issues at the beginning of this thread, I believe, are the result of 
>trying to access variables declared in the edit window on the terminal before 
>the edit window has been loaded. Sort of the same situation as script files 
>and the terminal session if you did not know that script files needed to be 
>loaded. In the case of the Playground, the edit window is seen at the same 
>time as the terminal, so the user might assume that all information is 
>available in both places.

>I agree that the edit window is not necessary when running labs, but I think 
>Joe is rightly focussing on the correctness of the Playground's results and 
>will move back to the interface when he is comfortable with the Playground's 
>accuracy.

>These comments are useful when he gets back to working in that area, but would 
>be better if they were entered as issues here: 
>https://github.com/jsoftware/j-playground/issues

Cheers, bob
--
For information about J forums see http://www.jsoftware.com/forums.htm


Re: [Jgeneral] J Playground test

2022-05-11 Thread chris burke
Bob

I still think this has nothing to do with the edit window.

When the Playground is first loaded, using t in Term should give a value
error, not the boxed list that is shown. That t is also defined in the edit
window is immaterial.

Chris

On Wed, May 11, 2022 at 11:18 AM 'robert therriault' via General <
gene...@jsoftware.com> wrote:

> Yes, in that case you are initializing t and would be able to use it. I
> only get the
>
> ++---++--+---++---+
> |invalid name|not defined|noun|adverb|conjunction|verb|unknown|
> ++---++--+---++---+
>
> message when I try to access a noun that has not been loaded and I believe
> that the original problem was that t was not initialized when there was an
> attempt to use it in the edit window.
>
> If you are getting messages like that after initializing t then you are
> seeing behaviour that I am not.
>
> I'm sorry that I seem to have misunderstood some of your posts and have
> not made myself as clear as I should have.
>
> Cheers, bob
>
> > On May 11, 2022, at 11:11, greg heil  wrote:
> >
> > Bob
> >
> > if run "t" from edit pane
> > (ctrl-enter)
> > is this not an
> > initialization?
> >
> > certainly
> > i can put something in t
> > and this overrides the default..
> >
> > ~greg heil
> > picsrp.github.io
> > i.tgu.ca/real_cal
> > twitter.com/g1h
> > twitter.com/tweitku
> >
> > --
> >
> > from: 'robert therriault' via General 
> > to: gene...@jsoftware.com
> > date: May 11, 2022, 10:59 AM
> > subject: Re: [Jgeneral] J Playground test
> >
> > Hi greg,
> >
> >> I think you may be assuming that when you see the contents of the edit
> window that it has been loaded. It is not automatically loaded, but is only
> loaded when the user chooses to load it. I believe that is the
> initialization that you are expecting.
> >
> > Let me know if I have misunderstood.
> >
> > Cheers, bob
> > --
> > For information about J forums see http://www.jsoftware.com/forums.htm
>
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm


Re: [Jgeneral] Wiki editing refusal

2022-05-11 Thread Ian Clark
Recent Changes…
Thanks, Raul. That's a start. I'll give it a try next time it happens.
Trouble is, it's not a condition that can be triggered at will. At least, I
don't know how.

MediaWiki does a lot of logging, in so many different ways. When I have a
spare week I must study it more.

On Wed, 11 May 2022 at 19:04, Raul Miller  wrote:

> The Recent Changes link on the left side of wiki pages is useful for
> checking recent (potential) edits.
>
> I know, I know, this sounds "obvious" but with so many competing
> pieces of potentially useful information in front of us, "obvious" is
> all-too-often in short supply.
>
> I hope this helps,
>
> --
> Raul
>
> On Wed, May 11, 2022 at 12:23 PM Ian Clark  wrote:
> >
> > I too would like a clear statement of best practice for recovering from
> > this situation. Maybe as a flowchart.
> >
> > Whenever I see the warning message (usually after hitting "Save changes")
> > my reflex action is to do what Bob recommends: scroll to the "editing
> area"
> > and copy/paste it for emergency recovery. But it's so rarely necessary.
> > Usually it works to simply hit the "Save Changes" button a second time.
> (If
> > I dare.)
> >
> > On occasions when I've panicked (and thus forgotten how exactly I
> > responded) it's subsequently emerged that the server has actually
> > registered my changes and updated the page. But to verify this fact is
> not
> > a simple task. If someone could only tell me how best to do it – as a
> > reflex action – the "demon warning" would no longer be an issue for me.
> >
> > Good task-support for the task of recovery might include
> > -- a button which reliably copies the editing area to the system
> > pasteboard, not disruptable by a sick server or connection,
> > -- a confirmation message fom the server that the last "Save Changes"
> > button-click did not (logically) alter the page contents.
> >
> > Ian
> >
> > On Wed, 11 May 2022 at 16:51, Henry Rich  wrote:
> >
> > > I think it's simply a loss of your reservation after a timeout.
> > > Wikipedia does the same.
> > >
> > > When you start editing a page, you get rights to it for a short time
> > > (maybe 5 min?).  After that, it's up for grabs.  When you repeat your
> > > save, it goes through (parhaps after a check for conflict).
> > >
> > > Henry Rich
> > >
> > > On 5/11/2022 11:41 AM, 'robert therriault' via General wrote:
> > > > Before reloading the page, I would suggest copying your most recent
> > > edits if you can.
> > > >
> > > > Then if you lose the edits on reloading, you should be able go to the
> > > original page, edit and paste in your saved edits to continue on.
> > > >
> > > > I have seen this as well, although not very often and I put it down
> to
> > > an interruption to my internet that might not be noticed by me on my
> > > browser,
> > > > but was enough to disrupt the editing process within the wiki.
> > > >
> > > > Cheers, bob
> > > >
> > > >> On May 11, 2022, at 08:33, Raul Miller 
> wrote:
> > > >>
> > > >> I suspect that that message means that your browser has lost track
> of
> > > >> a cookie or failed to perform a secondary request.
> > > >>
> > > >> It does not seem to be a timeout. Or, if that message does
> represent a
> > > >> timeout, there are also other issues which can trigger the problem:
> > > >> Sometimes simply reloading the page has been sufficient to make the
> > > >> message go away.
> > > >>
> > > >> I hope this helps,
> > > >>
> > > >> --
> > > >> Raul
> > > >>
> > > >> On Tue, May 10, 2022 at 11:29 PM Arthur Anger  >
> > > wrote:
> > > >>> Now and then, after many minutes of making editing changes to a
> Wiki
> > > page, a Save request is greeted by:
> > > >>>   Sorry! We could not process your edit due to a loss of session
> data.
> > > >>>
> > > >>>   You might have been logged out.  . . .
> > > >>>
> > > >>> Is this a timeout in the editor, and can it be lengthened?
> > > >>>
> > > >>> Is this instead a result of temporary loss of communication, which
> > > does occur occasionally, but doesn't often have a visual effect during
> an
> > > editing session?
> > > >>>
> > > >>> I have sometimes managed to copy the edited page and reinstate it
> > > later, but wonder if there is standard recovery procedure.
> > > >>>
> > > >>> Thanks.
> > > >>> --Art
> > > >>>
> --
> > > >>> For information about J forums see
> http://www.jsoftware.com/forums.htm
> > > >>
> --
> > > >> For information about J forums see
> http://www.jsoftware.com/forums.htm
> > > >
> --
> > > > For information about J forums see
> http://www.jsoftware.com/forums.htm
> > >
> > >
> > > --
> > > This email has been checked for viruses by AVG.
> > > https://www.avg.com
> > >
> > > --
> > > For information about J forums see 

Re: [Jgeneral] J Playground test

2022-05-11 Thread 'robert therriault' via General
Yes, in that case you are initializing t and would be able to use it. I only 
get the 

++---++--+---++---+
|invalid name|not defined|noun|adverb|conjunction|verb|unknown|
++---++--+---++---+

message when I try to access a noun that has not been loaded and I believe that 
the original problem was that t was not initialized when there was an attempt 
to use it in the edit window. 

If you are getting messages like that after initializing t then you are seeing 
behaviour that I am not.

I'm sorry that I seem to have misunderstood some of your posts and have not 
made myself as clear as I should have.

Cheers, bob

> On May 11, 2022, at 11:11, greg heil  wrote:
> 
> Bob
> 
> if run "t" from edit pane
> (ctrl-enter)
> is this not an
> initialization?
> 
> certainly
> i can put something in t
> and this overrides the default..
> 
> ~greg heil
> picsrp.github.io
> i.tgu.ca/real_cal
> twitter.com/g1h
> twitter.com/tweitku
> 
> --
> 
> from: 'robert therriault' via General 
> to: gene...@jsoftware.com
> date: May 11, 2022, 10:59 AM
> subject: Re: [Jgeneral] J Playground test
> 
> Hi greg,
> 
>> I think you may be assuming that when you see the contents of the edit 
>> window that it has been loaded. It is not automatically loaded, but is only 
>> loaded when the user chooses to load it. I believe that is the 
>> initialization that you are expecting.
> 
> Let me know if I have misunderstood.
> 
> Cheers, bob
> --
> For information about J forums see http://www.jsoftware.com/forums.htm

--
For information about J forums see http://www.jsoftware.com/forums.htm


Re: [Jgeneral] J Playground test

2022-05-11 Thread greg heil
Bob

if run "t" from edit pane
(ctrl-enter)
is this not an
initialization?

certainly
i can put something in t
and this overrides the default..

~greg heil
picsrp.github.io
i.tgu.ca/real_cal
twitter.com/g1h
twitter.com/tweitku

--

from: 'robert therriault' via General 
to: gene...@jsoftware.com
date: May 11, 2022, 10:59 AM
subject: Re: [Jgeneral] J Playground test

Hi greg,

>I think you may be assuming that when you see the contents of the edit window 
>that it has been loaded. It is not automatically loaded, but is only loaded 
>when the user chooses to load it. I believe that is the initialization that 
>you are expecting.

Let me know if I have misunderstood.

Cheers, bob
--
For information about J forums see http://www.jsoftware.com/forums.htm


Re: [Jgeneral] J Playground test

2022-05-11 Thread Joe Bogner
Thanks Bob and Chris/all. I confirmed my behavior is the same as bob's and
is working as I expect, but I can see how it could be confusing to a new
user. Having worked with JQT, I wouldn't expect to be able to type "t"
without running the script on the right side first to initialize t. The
playground edit window is the same as File->Open in JQT. In JQT it opens
the file in a separate window, whereas the playground opens it in the edit
window (right pane). That script is not run until the user runs it

I also agree it'd be nice to have a toggle for "Toggle Edit Window" under
"View" which would enable the user to hide it when they are using the Labs
(or we automatically hide it). I've added it as an enhancement
https://github.com/jsoftware/j-playground/issues/51


On Wed, May 11, 2022 at 1:53 PM 'robert therriault' via General <
gene...@jsoftware.com> wrote:

> Hi Chris,
>
> I can use the terminal window before loading the edit window, but I won't
> be able to access the variables declared in the edit window until it is
> run, which I think is reasonable behaviour.
>
> The issues at the beginning of this thread, I believe, are the result of
> trying to access variables declared in the edit window on the terminal
> before the edit window has been loaded. Sort of the same situation as
> script files and the terminal session if you did not know that script files
> needed to be loaded. In the case of the Playground, the edit window is seen
> at the same time as the terminal, so the user might assume that all
> information is available in both places.
>
> I agree that the edit window is not necessary when running labs, but I
> think Joe is rightly focussing on the correctness of the Playground's
> results and will move back to the interface when he is comfortable with the
> Playground's accuracy.
>
> These comments are useful when he gets back to working in that area, but
> would be better if they were entered as issues here:
> https://github.com/jsoftware/j-playground/issues
>
> Cheers, bob
>
> > On May 11, 2022, at 10:36, chris burke  wrote:
> >
> > This just looks like a bug. It shouldn't be necessary to run the edit
> > window first just to use Term.
>
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm


Re: [Jgeneral] Wiki editing refusal

2022-05-11 Thread Raul Miller
The Recent Changes link on the left side of wiki pages is useful for
checking recent (potential) edits.

I know, I know, this sounds "obvious" but with so many competing
pieces of potentially useful information in front of us, "obvious" is
all-too-often in short supply.

I hope this helps,

--
Raul

On Wed, May 11, 2022 at 12:23 PM Ian Clark  wrote:
>
> I too would like a clear statement of best practice for recovering from
> this situation. Maybe as a flowchart.
>
> Whenever I see the warning message (usually after hitting "Save changes")
> my reflex action is to do what Bob recommends: scroll to the "editing area"
> and copy/paste it for emergency recovery. But it's so rarely necessary.
> Usually it works to simply hit the "Save Changes" button a second time. (If
> I dare.)
>
> On occasions when I've panicked (and thus forgotten how exactly I
> responded) it's subsequently emerged that the server has actually
> registered my changes and updated the page. But to verify this fact is not
> a simple task. If someone could only tell me how best to do it – as a
> reflex action – the "demon warning" would no longer be an issue for me.
>
> Good task-support for the task of recovery might include
> -- a button which reliably copies the editing area to the system
> pasteboard, not disruptable by a sick server or connection,
> -- a confirmation message fom the server that the last "Save Changes"
> button-click did not (logically) alter the page contents.
>
> Ian
>
> On Wed, 11 May 2022 at 16:51, Henry Rich  wrote:
>
> > I think it's simply a loss of your reservation after a timeout.
> > Wikipedia does the same.
> >
> > When you start editing a page, you get rights to it for a short time
> > (maybe 5 min?).  After that, it's up for grabs.  When you repeat your
> > save, it goes through (parhaps after a check for conflict).
> >
> > Henry Rich
> >
> > On 5/11/2022 11:41 AM, 'robert therriault' via General wrote:
> > > Before reloading the page, I would suggest copying your most recent
> > edits if you can.
> > >
> > > Then if you lose the edits on reloading, you should be able go to the
> > original page, edit and paste in your saved edits to continue on.
> > >
> > > I have seen this as well, although not very often and I put it down to
> > an interruption to my internet that might not be noticed by me on my
> > browser,
> > > but was enough to disrupt the editing process within the wiki.
> > >
> > > Cheers, bob
> > >
> > >> On May 11, 2022, at 08:33, Raul Miller  wrote:
> > >>
> > >> I suspect that that message means that your browser has lost track of
> > >> a cookie or failed to perform a secondary request.
> > >>
> > >> It does not seem to be a timeout. Or, if that message does represent a
> > >> timeout, there are also other issues which can trigger the problem:
> > >> Sometimes simply reloading the page has been sufficient to make the
> > >> message go away.
> > >>
> > >> I hope this helps,
> > >>
> > >> --
> > >> Raul
> > >>
> > >> On Tue, May 10, 2022 at 11:29 PM Arthur Anger 
> > wrote:
> > >>> Now and then, after many minutes of making editing changes to a Wiki
> > page, a Save request is greeted by:
> > >>>   Sorry! We could not process your edit due to a loss of session data.
> > >>>
> > >>>   You might have been logged out.  . . .
> > >>>
> > >>> Is this a timeout in the editor, and can it be lengthened?
> > >>>
> > >>> Is this instead a result of temporary loss of communication, which
> > does occur occasionally, but doesn't often have a visual effect during an
> > editing session?
> > >>>
> > >>> I have sometimes managed to copy the edited page and reinstate it
> > later, but wonder if there is standard recovery procedure.
> > >>>
> > >>> Thanks.
> > >>> --Art
> > >>> --
> > >>> For information about J forums see http://www.jsoftware.com/forums.htm
> > >> --
> > >> For information about J forums see http://www.jsoftware.com/forums.htm
> > > --
> > > For information about J forums see http://www.jsoftware.com/forums.htm
> >
> >
> > --
> > This email has been checked for viruses by AVG.
> > https://www.avg.com
> >
> > --
> > For information about J forums see http://www.jsoftware.com/forums.htm
> >
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm


Re: [Jgeneral] J Playground test

2022-05-11 Thread 'robert therriault' via General
Hi greg,

I think you may be assuming that when you see the contents of the edit window 
that it has been loaded. It is not automatically loaded, but is only loaded 
when the user chooses to load it. I believe that is the initialization that you 
are expecting. 

Let me know if I have misunderstood.

Cheers, bob

> On May 11, 2022, at 10:48, greg heil  wrote:
> 
> am i missing an
> initialization?

--
For information about J forums see http://www.jsoftware.com/forums.htm


Re: [Jgeneral] J Playground test

2022-05-11 Thread 'robert therriault' via General
Hi Chris,

I can use the terminal window before loading the edit window, but I won't be 
able to access the variables declared in the edit window until it is run, which 
I think is reasonable behaviour. 

The issues at the beginning of this thread, I believe, are the result of trying 
to access variables declared in the edit window on the terminal before the edit 
window has been loaded. Sort of the same situation as script files and the 
terminal session if you did not know that script files needed to be loaded. In 
the case of the Playground, the edit window is seen at the same time as the 
terminal, so the user might assume that all information is available in both 
places.

I agree that the edit window is not necessary when running labs, but I think 
Joe is rightly focussing on the correctness of the Playground's results and 
will move back to the interface when he is comfortable with the Playground's 
accuracy.

These comments are useful when he gets back to working in that area, but would 
be better if they were entered as issues here: 
https://github.com/jsoftware/j-playground/issues

Cheers, bob

> On May 11, 2022, at 10:36, chris burke  wrote:
> 
> This just looks like a bug. It shouldn't be necessary to run the edit
> window first just to use Term.

--
For information about J forums see http://www.jsoftware.com/forums.htm


Re: [Jgeneral] J Playground test

2022-05-11 Thread greg heil
Bob

i get the exact display
Gilles reported
from either the Term frame
or executing (ctrl-enter)
from the edit frame

am i missing an
initialization?

~greg heil
picsrp.github.io
i.tgu.ca/real_cal
twitter.com/g1h
twitter.com/tweitku

--

from: chris burke 
to: General forum 
date: May 11, 2022, 10:37 AM
subject: Re: [Jgeneral] J Playground test

>This just looks like a bug. It shouldn't be necessary to run the edit window 
>first just to use Term.

>However on a related matter - when you load a lab, it should automatically 
>hide the edit window.

--

from: 'robert therriault' via General 
to: gene...@jsoftware.com
date: May 11, 2022, 10:30 AM
subject: Re: [Jgeneral] J Playground test

Hi greg,

>What I mean by "has not yet been run" is that although you can see the 
>information in the edit window, that information has not been entered into the 
>terminal. The different choices that can brought up in the edit window can be 
>seen under the Examples menu in the playground, but you would still need to 
>run the edit window before the contents would be available to the terminal 
>window.

>I am on a Mac and ctrl f1 isn't a short cut that does anything for me. What 
>results were you expecting and what are they the same as?

Cheers, bob
--
For information about J forums see http://www.jsoftware.com/forums.htm


Re: [Jgeneral] J Playground test

2022-05-11 Thread chris burke
This just looks like a bug. It shouldn't be necessary to run the edit
window first just to use Term.

However on a related matter - when you load a lab, it should automatically
hide the edit window.

On Wed, May 11, 2022 at 10:10 AM 'robert therriault' via General <
gene...@jsoftware.com> wrote:

> From what I can see the issue is that even though you can see the contents
> of the edit window, it has not yet been run.
>
> Perhaps, the easiest solution is to have the edit section hidden when the
> Playground first loads.
>
> When the user opens an example edit session there could be a comment at
> the top that says that the edit session will not be loaded until you either
> select loading from the menu or use an appropriate shortcut, followed by a
> list of the short cuts. This comment at the top would be required on
> example edit sessions and shorter version might be useful on user generated
> edit sessions.
>
> Cheers, bob
>
> > On May 11, 2022, at 09:37, greg heil  wrote:
> >
> > same in win10/chrome
> >
> > BTW
> > it might be useful
> > to have a 'revert' functionality
> > that reloaded the system
> > without affecting user data
> >
> > ~greg heil
> > picsrp.github.io
> > i.tgu.ca/real_cal
> > twitter.com/g1h
> > twitter.com/tweitku
> >
> > --
> >
> > from: Gilles Kirouac  via gmail.com
> > reply-to: gene...@jsoftware.com
> > to: gene...@jsoftware.com
> > date: May 11, 2022, 9:26 AM
> > subject: [Jgeneral] J Playground test
> >
> >> I tested the Playground minimally with Firefox and Edge in Win10.
> >
> > I started with the landing page at
> > https://code.jsoftware.com/wiki/Playground
> >
> > In Term, if you type "t", you get
> > t
> >> ++---++--+---++---+
> >> |invalid name|not defined|noun|adverb|conjunction|verb|unknown|
> >> ++---++--+---++---+
> >
> >> In Term (after reloading the page), if you type ";" followed by Ctrl+F1
> (Contextual Help), the input line goes away and you get
> >
> > |value error: helpplay_jws_
> > |   helpplay_jws_'0 0 1 1 ;'
> > |[-0]
> >
> > ~ Gilles
> > --
> > For information about J forums see http://www.jsoftware.com/forums.htm
>
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm


Re: [Jgeneral] J Playground test

2022-05-11 Thread 'robert therriault' via General
Hi greg,

What I mean by "has not yet been run" is that although you can see the 
information in the edit window, that information has not been entered into the 
terminal. The different choices that can brought up in the edit window can be 
seen under the Examples menu in the playground, but you would still need to run 
the edit window before the contents would be available to the terminal window. 

I am on a Mac and ctrl f1 isn't a short cut that does anything for me. What 
results were you expecting and what are they the same as?

Cheers, bob

> On May 11, 2022, at 10:21, greg heil  wrote:
> 
> Not sure what you mean by
> "it has not been run"

--
For information about J forums see http://www.jsoftware.com/forums.htm


Re: [Jgeneral] J Playground test

2022-05-11 Thread greg heil
Bob

Not sure what you mean by
"it has not been run"

but i do
get the same results
if i type "t"
or do a ctrl-F1
from the edit window

~greg heil
picsrp.github.io
i.tgu.ca/real_cal
twitter.com/g1h
twitter.com/tweitku

--

from: 'robert therriault' via General 
reply-to: gene...@jsoftware.com
to: gene...@jsoftware.com
date: May 11, 2022, 10:10 AM
subject: Re: [Jgeneral] J Playground test

>From what I can see the issue is that even though you can see the contents of 
>the edit window, it has not yet been run.

>Perhaps, the easiest solution is to have the edit section hidden when the 
>Playground first loads.

>When the user opens an example edit session there could be a comment at the 
>top that says that the edit session will not be loaded until you either select 
>loading from the menu or use an appropriate shortcut, followed by a list of 
>the short cuts. This comment at the top would be required on example edit 
>sessions and shorter version might be useful on user generated edit sessions.

Cheers, bob
--
For information about J forums see http://www.jsoftware.com/forums.htm


Re: [Jgeneral] J Playground test

2022-05-11 Thread 'robert therriault' via General
From what I can see the issue is that even though you can see the contents of 
the edit window, it has not yet been run.

Perhaps, the easiest solution is to have the edit section hidden when the 
Playground first loads.
 
When the user opens an example edit session there could be a comment at the top 
that says that the edit session will not be loaded until you either select 
loading from the menu or use an appropriate shortcut, followed by a list of the 
short cuts. This comment at the top would be required on example edit sessions 
and shorter version might be useful on user generated edit sessions.

Cheers, bob

> On May 11, 2022, at 09:37, greg heil  wrote:
> 
> same in win10/chrome
> 
> BTW
> it might be useful
> to have a 'revert' functionality
> that reloaded the system
> without affecting user data
> 
> ~greg heil
> picsrp.github.io
> i.tgu.ca/real_cal
> twitter.com/g1h
> twitter.com/tweitku
> 
> --
> 
> from: Gilles Kirouac  via gmail.com
> reply-to: gene...@jsoftware.com
> to: gene...@jsoftware.com
> date: May 11, 2022, 9:26 AM
> subject: [Jgeneral] J Playground test
> 
>> I tested the Playground minimally with Firefox and Edge in Win10.
> 
> I started with the landing page at
> https://code.jsoftware.com/wiki/Playground
> 
> In Term, if you type "t", you get
> t
>> ++---++--+---++---+
>> |invalid name|not defined|noun|adverb|conjunction|verb|unknown|
>> ++---++--+---++---+
> 
>> In Term (after reloading the page), if you type ";" followed by Ctrl+F1 
>> (Contextual Help), the input line goes away and you get
> 
> |value error: helpplay_jws_
> |   helpplay_jws_'0 0 1 1 ;'
> |[-0]
> 
> ~ Gilles
> --
> For information about J forums see http://www.jsoftware.com/forums.htm

--
For information about J forums see http://www.jsoftware.com/forums.htm


Re: [Jgeneral] J Playground test

2022-05-11 Thread greg heil
same in win10/chrome

BTW
it might be useful
to have a 'revert' functionality
that reloaded the system
without affecting user data

~greg heil
picsrp.github.io
i.tgu.ca/real_cal
twitter.com/g1h
twitter.com/tweitku

--

from: Gilles Kirouac  via gmail.com
reply-to: gene...@jsoftware.com
to: gene...@jsoftware.com
date: May 11, 2022, 9:26 AM
subject: [Jgeneral] J Playground test

>I tested the Playground minimally with Firefox and Edge in Win10.

I started with the landing page at
https://code.jsoftware.com/wiki/Playground

In Term, if you type "t", you get
t
>++---++--+---++---+
>|invalid name|not defined|noun|adverb|conjunction|verb|unknown|
>++---++--+---++---+

>In Term (after reloading the page), if you type ";" followed by Ctrl+F1 
>(Contextual Help), the input line goes away and you get

|value error: helpplay_jws_
|   helpplay_jws_'0 0 1 1 ;'
|[-0]

~ Gilles
--
For information about J forums see http://www.jsoftware.com/forums.htm


[Jgeneral] J Playground test

2022-05-11 Thread Gilles Kirouac

I tested the Playground minimally with Firefox and Edge in Win10.

I started with the landing page at
https://code.jsoftware.com/wiki/Playground

In Term, if you type "t", you get
t
++---++--+---++---+
|invalid name|not defined|noun|adverb|conjunction|verb|unknown|
++---++--+---++---+

In Term (after reloading the page), if you type ";" followed by Ctrl+F1 
(Contextual Help), the input line goes away and you get


|value error: helpplay_jws_
|   helpplay_jws_'0 0 1 1 ;'
|[-0]



~ Gilles
--
For information about J forums see http://www.jsoftware.com/forums.htm


Re: [Jgeneral] Wiki editing refusal

2022-05-11 Thread Ian Clark
I too would like a clear statement of best practice for recovering from
this situation. Maybe as a flowchart.

Whenever I see the warning message (usually after hitting "Save changes")
my reflex action is to do what Bob recommends: scroll to the "editing area"
and copy/paste it for emergency recovery. But it's so rarely necessary.
Usually it works to simply hit the "Save Changes" button a second time. (If
I dare.)

On occasions when I've panicked (and thus forgotten how exactly I
responded) it's subsequently emerged that the server has actually
registered my changes and updated the page. But to verify this fact is not
a simple task. If someone could only tell me how best to do it – as a
reflex action – the "demon warning" would no longer be an issue for me.

Good task-support for the task of recovery might include
-- a button which reliably copies the editing area to the system
pasteboard, not disruptable by a sick server or connection,
-- a confirmation message fom the server that the last "Save Changes"
button-click did not (logically) alter the page contents.

Ian

On Wed, 11 May 2022 at 16:51, Henry Rich  wrote:

> I think it's simply a loss of your reservation after a timeout.
> Wikipedia does the same.
>
> When you start editing a page, you get rights to it for a short time
> (maybe 5 min?).  After that, it's up for grabs.  When you repeat your
> save, it goes through (parhaps after a check for conflict).
>
> Henry Rich
>
> On 5/11/2022 11:41 AM, 'robert therriault' via General wrote:
> > Before reloading the page, I would suggest copying your most recent
> edits if you can.
> >
> > Then if you lose the edits on reloading, you should be able go to the
> original page, edit and paste in your saved edits to continue on.
> >
> > I have seen this as well, although not very often and I put it down to
> an interruption to my internet that might not be noticed by me on my
> browser,
> > but was enough to disrupt the editing process within the wiki.
> >
> > Cheers, bob
> >
> >> On May 11, 2022, at 08:33, Raul Miller  wrote:
> >>
> >> I suspect that that message means that your browser has lost track of
> >> a cookie or failed to perform a secondary request.
> >>
> >> It does not seem to be a timeout. Or, if that message does represent a
> >> timeout, there are also other issues which can trigger the problem:
> >> Sometimes simply reloading the page has been sufficient to make the
> >> message go away.
> >>
> >> I hope this helps,
> >>
> >> --
> >> Raul
> >>
> >> On Tue, May 10, 2022 at 11:29 PM Arthur Anger 
> wrote:
> >>> Now and then, after many minutes of making editing changes to a Wiki
> page, a Save request is greeted by:
> >>>   Sorry! We could not process your edit due to a loss of session data.
> >>>
> >>>   You might have been logged out.  . . .
> >>>
> >>> Is this a timeout in the editor, and can it be lengthened?
> >>>
> >>> Is this instead a result of temporary loss of communication, which
> does occur occasionally, but doesn't often have a visual effect during an
> editing session?
> >>>
> >>> I have sometimes managed to copy the edited page and reinstate it
> later, but wonder if there is standard recovery procedure.
> >>>
> >>> Thanks.
> >>> --Art
> >>> --
> >>> For information about J forums see http://www.jsoftware.com/forums.htm
> >> --
> >> For information about J forums see http://www.jsoftware.com/forums.htm
> > --
> > For information about J forums see http://www.jsoftware.com/forums.htm
>
>
> --
> This email has been checked for viruses by AVG.
> https://www.avg.com
>
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm


Re: [Jgeneral] Wiki editing refusal

2022-05-11 Thread Henry Rich
I think it's simply a loss of your reservation after a timeout.  
Wikipedia does the same.


When you start editing a page, you get rights to it for a short time 
(maybe 5 min?).  After that, it's up for grabs.  When you repeat your 
save, it goes through (parhaps after a check for conflict).


Henry Rich

On 5/11/2022 11:41 AM, 'robert therriault' via General wrote:

Before reloading the page, I would suggest copying your most recent edits if 
you can.

Then if you lose the edits on reloading, you should be able go to the original 
page, edit and paste in your saved edits to continue on.

I have seen this as well, although not very often and I put it down to an 
interruption to my internet that might not be noticed by me on my browser,
but was enough to disrupt the editing process within the wiki.

Cheers, bob


On May 11, 2022, at 08:33, Raul Miller  wrote:

I suspect that that message means that your browser has lost track of
a cookie or failed to perform a secondary request.

It does not seem to be a timeout. Or, if that message does represent a
timeout, there are also other issues which can trigger the problem:
Sometimes simply reloading the page has been sufficient to make the
message go away.

I hope this helps,

--
Raul

On Tue, May 10, 2022 at 11:29 PM Arthur Anger  wrote:

Now and then, after many minutes of making editing changes to a Wiki page, a 
Save request is greeted by:
  Sorry! We could not process your edit due to a loss of session data.

  You might have been logged out.  . . .

Is this a timeout in the editor, and can it be lengthened?

Is this instead a result of temporary loss of communication, which does occur 
occasionally, but doesn't often have a visual effect during an editing session?

I have sometimes managed to copy the edited page and reinstate it later, but 
wonder if there is standard recovery procedure.

Thanks.
--Art
--
For information about J forums see http://www.jsoftware.com/forums.htm

--
For information about J forums see http://www.jsoftware.com/forums.htm

--
For information about J forums see http://www.jsoftware.com/forums.htm



--
This email has been checked for viruses by AVG.
https://www.avg.com

--
For information about J forums see http://www.jsoftware.com/forums.htm


Re: [Jgeneral] Wiki editing refusal

2022-05-11 Thread 'robert therriault' via General
Before reloading the page, I would suggest copying your most recent edits if 
you can.

Then if you lose the edits on reloading, you should be able go to the original 
page, edit and paste in your saved edits to continue on.

I have seen this as well, although not very often and I put it down to an 
interruption to my internet that might not be noticed by me on my browser,
but was enough to disrupt the editing process within the wiki.

Cheers, bob

> On May 11, 2022, at 08:33, Raul Miller  wrote:
> 
> I suspect that that message means that your browser has lost track of
> a cookie or failed to perform a secondary request.
> 
> It does not seem to be a timeout. Or, if that message does represent a
> timeout, there are also other issues which can trigger the problem:
> Sometimes simply reloading the page has been sufficient to make the
> message go away.
> 
> I hope this helps,
> 
> -- 
> Raul
> 
> On Tue, May 10, 2022 at 11:29 PM Arthur Anger  wrote:
>> 
>> Now and then, after many minutes of making editing changes to a Wiki page, a 
>> Save request is greeted by:
>>  Sorry! We could not process your edit due to a loss of session data.
>> 
>>  You might have been logged out.  . . .
>> 
>> Is this a timeout in the editor, and can it be lengthened?
>> 
>> Is this instead a result of temporary loss of communication, which does 
>> occur occasionally, but doesn't often have a visual effect during an editing 
>> session?
>> 
>> I have sometimes managed to copy the edited page and reinstate it later, but 
>> wonder if there is standard recovery procedure.
>> 
>> Thanks.
>> --Art
>> --
>> For information about J forums see http://www.jsoftware.com/forums.htm
> --
> For information about J forums see http://www.jsoftware.com/forums.htm

--
For information about J forums see http://www.jsoftware.com/forums.htm


Re: [Jgeneral] Wiki editing refusal

2022-05-11 Thread Raul Miller
I suspect that that message means that your browser has lost track of
a cookie or failed to perform a secondary request.

It does not seem to be a timeout. Or, if that message does represent a
timeout, there are also other issues which can trigger the problem:
Sometimes simply reloading the page has been sufficient to make the
message go away.

I hope this helps,

-- 
Raul

On Tue, May 10, 2022 at 11:29 PM Arthur Anger  wrote:
>
> Now and then, after many minutes of making editing changes to a Wiki page, a 
> Save request is greeted by:
>   Sorry! We could not process your edit due to a loss of session data.
>
>   You might have been logged out.  . . .
>
> Is this a timeout in the editor, and can it be lengthened?
>
> Is this instead a result of temporary loss of communication, which does occur 
> occasionally, but doesn't often have a visual effect during an editing 
> session?
>
> I have sometimes managed to copy the edited page and reinstate it later, but 
> wonder if there is standard recovery procedure.
>
> Thanks.
> --Art
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm


[Jgeneral] Report on the J wiki meeting of May 5, 2022

2022-05-11 Thread 'robert therriault' via General
==Report on the J wiki meeting of May 5, 2022==

Present: Art Anger, Raul Miller, Bob Therriault

1)First topic for discussion was the J playground and the group had made some 
suggestions about making a landing page for them 
https://code.jsoftware.com/wiki/Playground . Also we wondered if some of the 
issues with lab instructions might be solved by having a lab verb that uses a 
different message that matches the J playground interface rather than jQt, 
possibly using a flag to indicate that J is running in the Playground. 

2)And then we talked about the way that the process had gone with the update on 
the images this week and it seemed that there was not really an interest in 
working together as a group as much as it was about having tasks accomplished. 
Perhaps, the plan will be to work as a group of projects that are supportive of 
one another but are over seen by an individual or perhaps a group of 
individuals. The best example of this so far has been the J playground which 
has made its advances in this way. Similar projects may be done at different 
stages of the transition. Art's Array Manipulation pages 
https://code.jsoftware.com/wiki/Array_Manipulation and the general navigation 
improvements to be made with the prototype landing page might be future 
projects that fit this approach. 

3)Further discussion on the process for the server transfer, whether there is a 
way to transfer pages across between servers or whether there is work to be 
done on both servers to keep them up to date.

4)A potential new participant in the wiki group is Raghu Ranganathan who 
developed the k wiki https://k.miraheze.org/wiki/Main_Page and worked on the 
BQN interface. We are looking forward to working with him and overcoming the 
challenge of time zones between North America and India.

5)Navigation continues to be an area of focus for wiki improvement because of 
so much information scattered in so many places. Raul suggested that categories 
would address some of this and to focus on the pain point that newcomers 
express. 

6)Finally we talked to Art about the Array Manipulation pages which he sees as 
a useful page for anyone doing something that they have not done before, 
whether beginner or more experienced. Bob showed him the structure of Oleg's 
phrase page https://code.jsoftware.com/wiki/Phrases that might be useful as a 
bit of a guide to the approach that may be taken. Art was wondering about a 
method of collapsing his code segments so that the page has a bit more of a 
compressed look and Raul was able to get that working in a very satisfactory 
way. This may be very useful going forward because it allows information to be 
expanded quickly without leaving the page. Art also was looking for ways to 
highlight text without using headings which trigger table of contents creation. 
Raul suggested using style attributes with either a div element or a span 
element to control the look of the text without using the heading format. The 
meeting wrapped up with Raul creating expanding links for Art's Array 
Manipulation page.

For access to previous meeting reports 
https://code.jsoftware.com/wiki/Wiki_Development

If you would like to participate in the development of the J wiki please 
contact us on the general forum and we will get you an invitation to the next J 
wiki meeting held on Thursdays at 11:00 (UTC)

Cheers, bob
--
For information about J forums see http://www.jsoftware.com/forums.htm