J7 IDE

[Chris Burke]

Background info on IDE changes planned for J7 is at:
http://www.jsoftware.com/papers/jfe.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

[Sherlock, Ric]

Thank you for making that available. It is a really interesting read.

I really like the decision to retain a separate method for defining a GUI and event handling for portability across JFEs. I'm also really looking forward to investigating the jbserver!

Will the mechanism for implementing x-platform support for things like 1!:x and 2!:x be similar to the way say the media/platimg addon is organised?  i.e. a generic script containing the common interface that loads the appropriate platform-specific script defining low level verbs that do the cd calls.


> From: Chris Burke
>
> Background info on IDE changes planned for J7 is at:
> http://www.jsoftware.com/papers/jfe.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

[Björn Helgason]

>JFEs become open source J code and can be developed cooperatively by the community.

I guess this will make many people happy

2009/10/21 Chris Burke <cburke@...>:
> Background info on IDE changes planned for J7 is at:
> http://www.jsoftware.com/papers/jfe.htm
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>



--
Björn Helgason, Verkfræðingur
Fugl&Fiskur ehf,
Þerneyjarsundi 23, Hraunborgum
Po Box 127,801 Selfoss ,
t-póst: gosinn@...
gsm: [phone]
Landslags og skrúðgarðagerð, gröfuþjónusta
http://groups.google.com/group/J-Programming


Tæknikunnátta höndlar hið flókna, sköpunargáfa er meistari einfaldleikans

góður kennari getur stigið á tær án þess að glansinn fari af skónum
          /|_      .-----------------------------------.
         ,'  .\  /  | Með léttri lund verður        |
     ,--'    _,'   | Dagurinn í dag                     |
    /       /       | Enn betri en gærdagurinn  |
   (   -.  |        `-----------------------------------'
   |     ) |         (\_ _/)
  (`-.  '--.)       (='.'=)   ♖♘♗♕♔♙
   `. )----'        (")_(") ☃☠
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

[Oleg Kobchenko]

There is now a page on J Wiki to discuss JFE for J701.

   http://www.jsoftware.com/jwiki/System/Beta/Front%20End

It is fairly free-form, and any ideas are welcome.

> From: "Sherlock, Ric" <R.G.Sherlock@...>
>
> Thank you for making that available. It is a really interesting read.
>
> I really like the decision to retain a separate method for defining a GUI and
> event handling for portability across JFEs. I'm also really looking forward to
> investigating the jbserver!
>
> Will the mechanism for implementing x-platform support for things like 1!:x and
> 2!:x be similar to the way say the media/platimg addon is organised?  i.e. a
> generic script containing the common interface that loads the appropriate
> platform-specific script defining low level verbs that do the cd calls.
>
> > From: Chris Burke
> >
> > Background info on IDE changes planned for J7 is at:
> > http://www.jsoftware.com/papers/jfe.htm

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

[Kip Murray]

How about an Integrated Use Environment (IUE)?  What kind of environment would
suit a student in a class where J is used as a programmable graphing calculator?
   His teacher?  Other instructional models?  Other users?

I imagine a two-pane environment with a note in the top pane: "Enter and edit
definitions here.  Type 'load definitions' in the execution window below to make
them available for use there."  In the execution window only the command being
entered would be editable.


Oleg Kobchenko wrote in the thread J7 IDE:

> There is now a page on J Wiki to discuss JFE for J701.
>
>    http://www.jsoftware.com/jwiki/System/Beta/Front%20End
>
> It is fairly free-form, and any ideas are welcome.
>
>
>
>
>> From: "Sherlock, Ric" <R.G.Sherlock@...>
>>
>> Thank you for making that available. It is a really interesting read.
>>
>> I really like the decision to retain a separate method for defining a GUI and
>> event handling for portability across JFEs. I'm also really looking forward to
>> investigating the jbserver!
>>
>> Will the mechanism for implementing x-platform support for things like 1!:x and
>> 2!:x be similar to the way say the media/platimg addon is organised?  i.e. a
>> generic script containing the common interface that loads the appropriate
>> platform-specific script defining low level verbs that do the cd calls.
>>
>>> From: Chris Burke
>>>
>>> Background info on IDE changes planned for J7 is at:
>>> http://www.jsoftware.com/papers/jfe.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

[John Baker-11]

The devil is always in the details.

I am generally in favor of replacing native foreigns with cd calls but the
potential removal of the 1!: and 2! families caught my eye.  If this step is
taken please provide clear scripts on the various platforms illustrating how
these verbs can be replaced with equivalent cd calls. I am particularily
concerned about losing the component file facility in jfiles that sets on
top of the indexed read 1!: calls.   The jfiles system is very useful,
performs well, and cannot be easily replaced with mapped files or streams.

On Thu, Oct 22, 2009 at 3:07 AM, Oleg Kobchenko <olegykj@...> wrote:

> There is now a page on J Wiki to discuss JFE for J701.
>
>   http://www.jsoftware.com/jwiki/System/Beta/Front%20End
>
> It is fairly free-form, and any ideas are welcome.
>
>
>
>
> > From: "Sherlock, Ric" <R.G.Sherlock@...>
>  >
> > Thank you for making that available. It is a really interesting read.
> >
> > I really like the decision to retain a separate method for defining a GUI
> and
> > event handling for portability across JFEs. I'm also really looking
> forward to
> > investigating the jbserver!
> >
> > Will the mechanism for implementing x-platform support for things like
> 1!:x and
> > 2!:x be similar to the way say the media/platimg addon is organised?
>  i.e. a
> > generic script containing the common interface that loads the appropriate
> > platform-specific script defining low level verbs that do the cd calls.
> >
> > > From: Chris Burke
> > >
> > > Background info on IDE changes planned for J7 is at:
> > > http://www.jsoftware.com/papers/jfe.htm
>
>
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>

--
John D. Baker
bakerjd99@...
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

[Raul Miller-4]

On Wed, Oct 21, 2009 at 6:14 PM, Chris Burke <cburke@...> wrote:
> Background info on IDE changes planned for J7 is at:
> http://www.jsoftware.com/papers/jfe.htm

This looks very nice.

I think that your stdio jfe will be useful for several reasons:

[1] It should be very simple to implement.
[2] It will be useful in unix contexts where X is not available (for
example, cron jobs).
[3] Since we will be able to "switch" front ends, starting a stdio
front end and then doing graphics later will not be the obstacle it
has been in the past.

That said, I would recommend changing

JE calls input_jfe_'' for input
15!:18'' returns prompt

JE calls output_jfe_'' for output
15!:19'' returns output string
15!:20'' returns output type (input, formatted, error, etc)

to

JE calls
   input_jfe_ prompt
for input

JE calls
  outputtype output_jfe_ outputstring
for output.  outputtype may be input, formatted, error, etc.

(i just now noticed the wiki page -- I read your letter and slept on
it over night before responding, I will think about contributing on that
wiki page in the future.)

Thanks,

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

[Eric Iverson-3]

Agreed that good scripts replacing the 1!: and 2!: families are critical.
There should be no problem in providing the same functionality and there is
every reason to retain jfiles.

On Thu, Oct 22, 2009 at 8:48 AM, John Baker <bakerjd99@...> wrote:

> The devil is always in the details.
>
> I am generally in favor of replacing native foreigns with cd calls but the
> potential removal of the 1!: and 2! families caught my eye.  If this step
> is
> taken please provide clear scripts on the various platforms illustrating
> how
> these verbs can be replaced with equivalent cd calls. I am particularily
> concerned about losing the component file facility in jfiles that sets on
> top of the indexed read 1!: calls.   The jfiles system is very useful,
> performs well, and cannot be easily replaced with mapped files or streams.
>
> On Thu, Oct 22, 2009 at 3:07 AM, Oleg Kobchenko <olegykj@...> wrote:
>
> > There is now a page on J Wiki to discuss JFE for J701.
> >
> >   http://www.jsoftware.com/jwiki/System/Beta/Front%20End
> >
> > It is fairly free-form, and any ideas are welcome.
> >
> >
> >
> >
> > > From: "Sherlock, Ric" <R.G.Sherlock@...>
> >  >
> > > Thank you for making that available. It is a really interesting read.
> > >
> > > I really like the decision to retain a separate method for defining a
> GUI
> > and
> > > event handling for portability across JFEs. I'm also really looking
> > forward to
> > > investigating the jbserver!
> > >
> > > Will the mechanism for implementing x-platform support for things like
> > 1!:x and
> > > 2!:x be similar to the way say the media/platimg addon is organised?
> >  i.e. a
> > > generic script containing the common interface that loads the
> appropriate
> > > platform-specific script defining low level verbs that do the cd calls.
> > >
> > > > From: Chris Burke
> > > >
> > > > Background info on IDE changes planned for J7 is at:
> > > > http://www.jsoftware.com/papers/jfe.htm
> >
> >
> >
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
> >
>
>
>
> --
> John D. Baker
> bakerjd99@...
>  ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>

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

[Dan Bron]

John Baker wrote:
>  I am generally in favor of replacing native
>  foreigns with cd calls but the potential
>  removal of the 1!: and 2! families caught my eye.  

I think many Jers will be shielded from these changes, because a lot of us
require 'files'  and use  fread  as opposed to native  1!:1  etc.

-Dan

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

[Eric Iverson-3]

Your suggestion of verb arguments rather than foreign conjunctions is
currently under discussion. For me, in the development stage, doing it the
current way was easier and more flexible and avoided some issues, Now that
the specs have settled it might be cleaner (more J) to do as you suggest.
This will probably be sorted out fairly soon.

Your point about the ease of switching front ends is valid and I have found
it to be quite useful. So far mostly in developing one JFE from within
another but I can see interesting posibilities down the road.

There is one other facility that wasn't mentioned in jfe.htm. The beta will
include scripts that duplicate the old jee facility. That is, a J console
session that works with stdio that communicates via sockets with a separate
J task that is running a JFE that provides the full GTK gui as well as a
command line (socket) interface. I was always surprised at how useful the
jee facility was and was pleased with how easy it was to provide it in
completely open J code in J701.

On Thu, Oct 22, 2009 at 9:01 AM, Raul Miller <rauldmiller@...> wrote:

> On Wed, Oct 21, 2009 at 6:14 PM, Chris Burke <cburke@...> wrote:
> > Background info on IDE changes planned for J7 is at:
> > http://www.jsoftware.com/papers/jfe.htm
>
> This looks very nice.
>
> I think that your stdio jfe will be useful for several reasons:
>
> [1] It should be very simple to implement.
> [2] It will be useful in unix contexts where X is not available (for
> example, cron jobs).
> [3] Since we will be able to "switch" front ends, starting a stdio
> front end and then doing graphics later will not be the obstacle it
> has been in the past.
>
> That said, I would recommend changing
>
> JE calls input_jfe_'' for input
> 15!:18'' returns prompt
>
> JE calls output_jfe_'' for output
> 15!:19'' returns output string
> 15!:20'' returns output type (input, formatted, error, etc)
>
> to
>
> JE calls
>   input_jfe_ prompt
> for input
>
> JE calls
>  outputtype output_jfe_ outputstring
> for output.  outputtype may be input, formatted, error, etc.
>
> (i just now noticed the wiki page -- I read your letter and slept on
> it over night before responding, I will think about contributing on that
> wiki page in the future.)
>
> Thanks,
>
> --
> Raul
>  ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>

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

[Eric Iverson-3]

New files and jfiles scripts that use cd will solve much of the problem in
killing 1!: family. Care will be required to deal with platform
dependencies. There are already good examples in how to deal with these
issues in sockets and various addons.

The problem with 2!: is more difficult. There are enough differences between
platforms that there will probably be a set of task related scripts that are
platform specific. But I think it is very important to abstract the core
facilities that are most frequently required that can be specified in a
completely host independent way. The current 2!: specs aren't implemented
quite right, aren't specified quite right, and are only in Unix even though
they could be done pretty much the same way in windows. There is a bit of
design work required here.

On Thu, Oct 22, 2009 at 9:44 AM, Dan Bron <j@...> wrote:

> John Baker wrote:
> >  I am generally in favor of replacing native
> >  foreigns with cd calls but the potential
> >  removal of the 1!: and 2! families caught my eye.
>
> I think many Jers will be shielded from these changes, because a lot of us
> require 'files'  and use  fread  as opposed to native  1!:1  etc.
>
> -Dan
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>

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

[bill lam-2]

On Thu, 22 Oct 2009, Raul Miller wrote:
> I think that your stdio jfe will be useful for several reasons:

I'm not quite understand what will the difference between stdio jfe
and current jconsole.

--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

[Eric Iverson-3]

The current jconsole has compiled C code that does
fgets/fputs/readline/isatty and etc. This could stay this way as it seems to
work and isn't a source of problems.

But with the new JFE it would be possible to implement all that in J with cd
calls. That would mean that jconsole would become a dead simple binary that
had no host dependent code or any calls to host services. jconsole would
become je and would just load the JE shared library and with a suitable
starting script would provide a console front end as defined by a J
programmer.


On Thu, Oct 22, 2009 at 10:33 AM, bill lam <bbill.lam@...> wrote:

> On Thu, 22 Oct 2009, Raul Miller wrote:
> > I think that your stdio jfe will be useful for several reasons:
>
> I'm not quite understand what will the difference between stdio jfe
> and current jconsole.
>
> --
> regards,
> ====================================================
> GPG key 1024D/4434BAB3 2008-08-24
> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
>  ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>

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

[Zsbán Ambrus]

On the frontend, could you perhaps make (1!:1)1 and x(1!:2)2 work in
secure mode too?  The first one reads a line from input which you can
already do with the 0 :0 call, but you cannot easily write anything to
the output at any time, only the formatted output or error message of
executed statements are written.  Both of these call a callback of
whatever frontend is calling the j engine (just like the 11!:n calls)
so I think it would be safe to allow them.

Similarly, could you allow 0!:100 y and similar (but not 0!:0 y) in
secure mode as well?  This was allowed in j601 but forbidden in j602,
and I don't see what problem it could cause to allow it.

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

[Joey K Tuttle]

This sounds good - and if those of us who wrote our own 1!: 2!:
scripts 20 years ago (and never require 'files") are able to easily
retrofit them into the cd scheme, then I'm all for making the changes
being proposed. Sounds like exciting new possibilities.

At 11:17  -0400 2009/10/22, Eric Iverson wrote:

>The current jconsole has compiled C code that does
>fgets/fputs/readline/isatty and etc. This could stay this way as it seems to
>work and isn't a source of problems.
>
>But with the new JFE it would be possible to implement all that in J with cd
>calls. That would mean that jconsole would become a dead simple binary that
>had no host dependent code or any calls to host services. jconsole would
>become je and would just load the JE shared library and with a suitable
>starting script would provide a console front end as defined by a J
>programmer.
>
>
>On Thu, Oct 22, 2009 at 10:33 AM, bill lam <bbill.lam@...> wrote:
>
>>  On Thu, 22 Oct 2009, Raul Miller wrote:
>>  > I think that your stdio jfe will be useful for several reasons:
>>
>>  I'm not quite understand what will the difference between stdio jfe
>>  and current jconsole.
>>
>  > --

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

[Oleg Kobchenko]

A couple of points:

 - earlier 1!: 2!: had to be extended to support byte-for-byte
   non-converting IO which was necessary for JHP


 - still missing: streamed IO and related ReadLine() for
   files and console (and possibly sockets)

Hopefully, the new approach will address this more comprehensively.

> From: Joey K Tuttle <jkt@...>
>
> This sounds good - and if those of us who wrote our own 1!: 2!:
> scripts 20 years ago (and never require 'files") are able to easily
> retrofit them into the cd scheme, then I'm all for making the changes
> being proposed. Sounds like exciting new possibilities.
>
> At 11:17  -0400 2009/10/22, Eric Iverson wrote:
> >The current jconsole has compiled C code that does
> >fgets/fputs/readline/isatty and etc. This could stay this way as it seems to
> >work and isn't a source of problems.
> >
> >But with the new JFE it would be possible to implement all that in J with cd
> >calls. That would mean that jconsole would become a dead simple binary that
> >had no host dependent code or any calls to host services. jconsole would
> >become je and would just load the JE shared library and with a suitable
> >starting script would provide a console front end as defined by a J
> >programmer.
> >
> >
> >On Thu, Oct 22, 2009 at 10:33 AM, bill lam wrote:
> >
> >>  On Thu, 22 Oct 2009, Raul Miller wrote:
> >>  > I think that your stdio jfe will be useful for several reasons:
> >>
> >>  I'm not quite understand what will the difference between stdio jfe
> >>  and current jconsole.

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

[Joey K Tuttle]

My point was that I've always used

      fread =: 1!:1@<

and never use the one from 'files' - I wasn't paranoid that I
wouldn't be able to retrofit my simplistic definitions, just saying
.....

On the streamed IO and ReadLine() - I agree that could be really useful!


At 10:56  -0700 2009/10/22, Oleg Kobchenko wrote:

>A couple of points:
>
>  - earlier 1!: 2!: had to be extended to support byte-for-byte
>    non-converting IO which was necessary for JHP
>
>
>  - still missing: streamed IO and related ReadLine() for
>    files and console (and possibly sockets)
>
>Hopefully, the new approach will address this more comprehensively.
>

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

[Kip Murray]

If you've seen this before, skip to the closing paragraph.

Very elementary stuff: Integrated Use Environment (IUE).  What kind of
environment would suit the teacher and students in a class where J is used as a
programmable graphing calculator?

I imagine a two-pane environment with a note in the top pane: "Enter and edit
definitions here.  Type 'load definitions' in the execution window below to make
them available for use there."  The default would be a "loud load:" loaded items
are echoed in the execution window.  There, to discourage student "fudging",
only the command being entered would be editable.  (Homework, even tests, can
include printouts of parts of the execution window.  Ease of getting such
printouts is important.)

These items are far down the road: remember to keep them possible.  Moreover,
the whole approach imagined above may be out of date.  Some kind of Definition,
  Data, Answer, Save, Print form layout may be devised that would work well for
many end users.


Joey K Tuttle wrote:

> My point was that I've always used
>
>       fread =: 1!:1@<
>
> and never use the one from 'files' - I wasn't paranoid that I
> wouldn't be able to retrofit my simplistic definitions, just saying
> .....
>
> On the streamed IO and ReadLine() - I agree that could be really useful!
>
>
> At 10:56  -0700 2009/10/22, Oleg Kobchenko wrote:
>> A couple of points:
>>
>>  - earlier 1!: 2!: had to be extended to support byte-for-byte
>>    non-converting IO which was necessary for JHP
>>
>>
>>  - still missing: streamed IO and related ReadLine() for
>>    files and console (and possibly sockets)
>>
>> Hopefully, the new approach will address this more comprehensively.
>>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm

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

[Sherlock, Ric]

> From: Kip Murray
>
> Very elementary stuff: Integrated Use Environment (IUE).  What kind of
> environment would suit the teacher and students in a class where J is
> used as a
> programmable graphing calculator?
>
> I imagine a two-pane environment with a note in the top pane: "Enter
> and edit
> definitions here.  Type 'load definitions' in the execution window
> below to make
> them available for use there."  The default would be a "loud load:"
> loaded items
> are echoed in the execution window.  There, to discourage student
> "fudging",
> only the command being entered would be editable.  (Homework, even
> tests, can
> include printouts of parts of the execution window.  Ease of getting
> such
> printouts is important.)
>
> These items are far down the road: remember to keep them possible.
> Moreover,
> the whole approach imagined above may be out of date.  Some kind of
> Definition,
>   Data, Answer, Save, Print form layout may be devised that would work
> well for
> many end users.
>

The proposed browser interface may be useful for this type of scenario. Especially if the images generated by plot, viewmat etc. could be incorporated in/alongside the session output/log in the browser window.

Such a setup would probably have a lot of benefits over standalone installations both in terms of system management as well as tracking student progress.

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

[Björn Helgason]

> allow an http browser to use a J session (on a server or the same system) as a full J development system

Is it correct that J701 will allow browsers to call J and display the results?

Will it be possible to use a browser as a GUI for J?

If this is correct will it be possible to use any browser?

Will there be any special requirements for the browser like running cookies etc?


2009/10/21 Chris Burke <cburke@...>:
> Background info on IDE changes planned for J7 is at:
> http://www.jsoftware.com/papers/jfe.htm
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>



--
Björn Helgason, Verkfræðingur
Fugl&Fiskur ehf,
Þerneyjarsundi 23, Hraunborgum
Po Box 127,801 Selfoss ,
t-póst: gosinn@...
gsm: [phone]
Landslags og skrúðgarðagerð, gröfuþjónusta
http://groups.google.com/group/J-Programming


Tæknikunnátta höndlar hið flókna, sköpunargáfa er meistari einfaldleikans

góður kennari getur stigið á tær án þess að glansinn fari af skónum
          /|_      .-----------------------------------.
         ,'  .\  /  | Með léttri lund verður        |
     ,--'    _,'   | Dagurinn í dag                     |
    /       /       | Enn betri en gærdagurinn  |
   (   -.  |        `-----------------------------------'
   |     ) |         (\_ _/)
  (`-.  '--.)       (='.'=)   ♖♘♗♕♔♙
   `. )----'        (")_(") ☃☠
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm