One slight awkwardness with the project manager is the name of the
project file itself, and the associated files for test and build. The
.ijp extension is used only for projects, though it is an ordinary
script file; while the test and build scripts cannot be distinguished
from other scripts in the project. In each case, any name can be chosen
for each of the files.
I suggest that the project extension be used for each of these files and
that the names be fixed. Specifically, project.ijp will be the project
configuration, test.ijp and build.ijp the test and build scripts.
Perhaps also run.ijp for a run script different from test.
Here the .ijp extension is re-used, since there is likely to be a
one-off conversion, and there is not much chance anyway of conflict -
but this is not really important, and another extension could be used.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
> One slight awkwardness with the project manager is the name of the
> project file itself, and the associated files for test and build. The
> .ijp extension is used only for projects, though it is an ordinary
> script file; while the test and build scripts cannot be distinguished
> from other scripts in the project. In each case, any name can be chosen
> for each of the files.
>
> I suggest that the project extension be used for each of these files and
> that the names be fixed. Specifically, project.ijp will be the project
> configuration, test.ijp and build.ijp the test and build scripts.
> Perhaps also run.ijp for a run script different from test.
>
> Here the .ijp extension is re-used, since there is likely to be a
> one-off conversion, and there is not much chance anyway of conflict -
> but this is not really important, and another extension could be used.
Did you mean project.ijp will be used for loading scripts in that
project?
--
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
bill lam wrote:
> Did you mean project.ijp will be used for loading scripts in that
> project?
It would be the project configuration file, same as the current xxx.ijp
file except with updated definitions.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
Whenever I have a new project, I would first create a new directory under the Projects directy. So for example, my new project is named FishingERD. I would create a new directory under that name in Projects which would essentiall go:
J602-Users/Projects/FishingERD
Then under that directory I would have the project file named: FishingERD.ijp
So are you suggesting that instead of having FishingERD.ijp, the PM would automatically create project.ijp and use that as the config file storage?
I guess it would work for me but how about users who does not create a new directory for each of their project?
Just wondering.
r/Alex
-----Original Message-----
From: beta-bounces@... [mailto:beta-bounces@...] On Behalf Of Chris Burke
Sent: Thursday, November 12, 2009 3:43 PM
To: Beta forum
Subject: Re: [Jbeta] Project Files
bill lam wrote:
> Did you mean project.ijp will be used for loading scripts in that
> project?
It would be the project configuration file, same as the current xxx.ijp
file except with updated definitions.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm ----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
> Hi,
>
> Let me clarify.
>
> Whenever I have a new project, I would first create a new directory
> under the Projects directy. So for example, my new project is named
> FishingERD. I would create a new directory under that name in
> Projects which would essentiall go: J602-Users/Projects/FishingERD
>
> Then under that directory I would have the project file named:
> FishingERD.ijp
>
> So are you suggesting that instead of having FishingERD.ijp, the PM
> would automatically create project.ijp and use that as the config
> file storage?
>
> I guess it would work for me but how about users who does not create
> a new directory for each of their project?
>
Normally I'll create a new directory for a new project. In case where
two projects are otherwise identical but differs by only a few files,
I'll put them into the same directory.
--
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
>
> One slight awkwardness with the project manager is the name of the
> project file itself, and the associated files for test and build. The
> .ijp extension is used only for projects, though it is an ordinary
> script file; while the test and build scripts cannot be distinguished
> from other scripts in the project. In each case, any name can be chosen
> for each of the files.
>
> I suggest that the project extension be used for each of these files and
> that the names be fixed. Specifically, project.ijp will be the project
> configuration, test.ijp and build.ijp the test and build scripts.
> Perhaps also run.ijp for a run script different from test.
>
> Here the .ijp extension is re-used, since there is likely to be a
> one-off conversion, and there is not much chance anyway of conflict -
> but this is not really important, and another extension could be used.
>
> From: Chris Burke <cburke@...>
>
> bill lam wrote:
> > Did you mean project.ijp will be used for loading scripts in that
> > project?
>
> It would be the project configuration file, same as the current xxx.ijp
> file except with updated definitions.
Another approach is have one project.ijp and have different targets in it
for build, test, run, etc.
Also for situation like "test", one may do without a target, but instead
having a naming convention like test.ijs, and a common harness to run it,
rather than duplicating the harnesses from project to project like it is
done now.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
bill lam wrote:
> Normally I'll create a new directory for a new project. In case where
> two projects are otherwise identical but differs by only a few files,
> I'll put them into the same directory.
This is the situation I wanted to avoid. The current design supports
more than one project in a directory. I myself have never used it, and
regard it as a nuisance. I am suggesting that there be at most one
project per directory - would this be a serious problem for you?
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
Oleg Kobchenko wrote:
> Another approach is have one project.ijp and have different targets in it
> for build, test, run, etc.
>
> Also for situation like "test", one may do without a target, but instead
> having a naming convention like test.ijs, and a common harness to run it,
> rather than duplicating the harnesses from project to project like it is
> done now.
Yes, this is equally possible. It just means that build.ijs, test.ijs,
run.ijs are special scripts within a project. I don't mind this
approach, as it is essentially what I do right now - the only difference
being that these names would be automatically used by a project, instead
of having to be defined manually. Of course, you could then not create a
project whose source scripts included one of build.ijs, test.ijs etc.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
I have an application that produces 4 J executables, used for different
things (the application is management of quiz tournaments, and there is
one application that runs individual matches, another to control the
pairings etc, another to take contestants' pictures, and another to
register teams as they arrive). There is much shared code between the
executables, to ensure that file and communication formats are compatible.
I have all this in one directory, for convenience, because when I build
the apps I build them all together & move them to the place where they
all run on game day; also because they share so much code.
I could split them, but that would be at least a minor nuisance.
Henry
Chris Burke wrote:
> bill lam wrote:
>> Normally I'll create a new directory for a new project. In case where
>> two projects are otherwise identical but differs by only a few files,
>> I'll put them into the same directory.
>
> This is the situation I wanted to avoid. The current design supports
> more than one project in a directory. I myself have never used it, and
> regard it as a nuisance. I am suggesting that there be at most one
> project per directory - would this be a serious problem for you?
>
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm >
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
On Thu, 12 Nov 2009, Oleg Kobchenko wrote:
> > It would be the project configuration file, same as the current xxx.ijp
> > file except with updated definitions.
>
> Another approach is have one project.ijp and have different targets in it
> for build, test, run, etc.
It's a good idea, just like there are multiple targets inside a
MakeFile, it can be called with optional arguments, such as
make
make clean
make install install-doc
It should be easily done with typing the these commands in jconsole.
However for a gui front-end with only one 'load' or 'test' button, it
need some method to pass these optional arguments.
--
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
On Fri, 13 Nov 2009, Chris Burke wrote:
> bill lam wrote:
> > Normally I'll create a new directory for a new project. In case where
> > two projects are otherwise identical but differs by only a few files,
> > I'll put them into the same directory.
>
> This is the situation I wanted to avoid. The current design supports
> more than one project in a directory. I myself have never used it, and
M$ used it in vista and win7. All versions of vista are in fact one
project but with minor configuration difference to produce array of
vista {entry/home/business/enterprise} {basic/premium/ultimate}
> regard it as a nuisance. I am suggesting that there be at most one
> project per directory - would this be a serious problem for you?
No problem, it only need to rewrite the path of source files inside
ijp file, or symlink common files as the last resort.
--
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
On Nov 12, 2009, at 5:05 PM, bill lam <bbill.lam@...> wrote:
On Thu, 12 Nov 2009, Oleg Kobchenko wrote:
It would be the project configuration file, same as the current xxx.ijp
file except with updated definitions.
Another approach is have one project.ijp and have different targets in it
for build, test, run, etc.
It's a good idea, just like there are multiple targets inside a
MakeFile, it can be called with optional arguments, such as
make
make clean
make install install-doc
It should be easily done with typing the these commands in jconsole.
However for a gui front-end with only one 'load' or 'test' button, it
need some method to pass these optional arguments.
In GUI, targets are selected: default for specific buttons or any from a list if
all targets.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
> From: bill lam <bbill.lam@...>
>
> On Fri, 13 Nov 2009, Chris Burke wrote:
> > bill lam wrote:
> > > Normally I'll create a new directory for a new project. In case where
> > > two projects are otherwise identical but differs by only a few files,
> > > I'll put them into the same directory.
> >
> > This is the situation I wanted to avoid. The current design supports
> > more than one project in a directory. I myself have never used it, and
>
> M$ used it in vista and win7. All versions of vista are in fact one
> project but with minor configuration difference to produce array of
>
> vista {entry/home/business/enterprise} {basic/premium/ultimate}
>
> > regard it as a nuisance. I am suggesting that there be at most one
> > project per directory - would this be a serious problem for you?
>
> No problem, it only need to rewrite the path of source files inside
> ijp file, or symlink common files as the last resort.
I support the idea of a single project per folder with multiple
targets, which could produce different deliverables.
A couple of things to note here:
- multiple targets will allow you to use the same sources for different
"builds" like in Henry's example
- there should be a mechanism of dependent projects or at least
"components" like a addons or scripts as a way to share reusable code
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
> From: Chris Burke <cburke@...>
>
> Oleg Kobchenko wrote:
> > Another approach is have one project.ijp and have different targets in it
> > for build, test, run, etc.
> >
> > Also for situation like "test", one may do without a target, but instead
> > having a naming convention like test.ijs, and a common harness to run it,
> > rather than duplicating the harnesses from project to project like it is
> > done now.
>
> Yes, this is equally possible. It just means that build.ijs, test.ijs,
> run.ijs are special scripts within a project. I don't mind this
> approach, as it is essentially what I do right now - the only difference
> being that these names would be automatically used by a project, instead
> of having to be defined manually. Of course, you could then not create a
> project whose source scripts included one of build.ijs, test.ijs etc.
"test.ijs" is THE tests themselves--the numerous little verbs with
asserts, not the harness. There aren't no "build.ijs or run.ijs etc--
these targets are defined in the project file (whichever the extension).
A target is either declaratively defined (no code or code in common harness
of the PM API), or consists of a single verb which has the action-sentences.
Bill is right, the project file is very similar to a Makefile.
(I re-respond to this message due to messed-up indents)
> From: bill lam <bbill.lam@...>
>
> On Thu, 12 Nov 2009, Oleg Kobchenko wrote:
> > > It would be the project configuration file, same as the current xxx.ijp
> > > file except with updated definitions.
> >
> > Another approach is have one project.ijp and have different targets in it
> > for build, test, run, etc.
>
> It's a good idea, just like there are multiple targets inside a
> MakeFile, it can be called with optional arguments, such as
>
> make
> make clean
> make install install-doc
>
> It should be easily done with typing the these commands in jconsole.
> However for a gui front-end with only one 'load' or 'test' button, it
> need some method to pass these optional arguments.
In GUI, targets are selected:
- for each short-cut button (Build, Run, Test):
a default target is assigned, but can be changed
- there is also a generic "Run Target" which allows
to pick any target for a single execution
Like in Xcode Organizer, there may be certain patterns to match
a selected file with a likely target. For example, if file is
called "test.ijs" or "xxx_test.ijs" to execute a "test" target
against it. Targets can also be non-J-specific, such as a shell
script, some kind of pre-processor etc.
In fact, targets could be business tasks, such as generate a report
using a report definition and the format/publish addon; or to run
a statistical processing on a data file, etc. Or those could be
actions in a larger target "dojob", etc.
Interestingly, the gui/jobs addon is similar to this project/task/operation
paradigm, except that it allows for additional UI for parameters
and viewing the results.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
> On Thu, 12 Nov 2009, Oleg Kobchenko wrote:
> > > It would be the project configuration file, same as the current xxx.ijp
> > > file except with updated definitions.
> >
> > Another approach is have one project.ijp and have different targets in it
> > for build, test, run, etc.
>
> It's a good idea, just like there are multiple targets inside a
> MakeFile, it can be called with optional arguments, such as
>
> make
> make clean
> make install install-doc
>
> It should be easily done with typing the these commands in jconsole.
> However for a gui front-end with only one 'load' or 'test' button, it
> need some method to pass these optional arguments.
I got a fancy idea. How about just use the real MakeFile and shell
execute 'make' to build target, test or install?
--
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
> I have an application that produces 4 J executables, used for different
> things (the application is management of quiz tournaments, and there is
> one application that runs individual matches, another to control the
> pairings etc, another to take contestants' pictures, and another to
> register teams as they arrive). There is much shared code between the
> executables, to ensure that file and communication formats are compatible.
>
> I have all this in one directory, for convenience, because when I build
> the apps I build them all together & move them to the place where they
> all run on game day; also because they share so much code.
>
> I could split them, but that would be at least a minor nuisance.
What I recommend is to build all the targets at the same time, since
building J apps should take a trivial amount of time. If so, there would
be no need to split up the directory.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
That would be OK with me. In fact, I would do that now if I could. Can
current PM have multiple targets?
Henry
Chris Burke wrote:
> Henry Rich wrote:
>> I have an application that produces 4 J executables, used for different
>> things (the application is management of quiz tournaments, and there is
>> one application that runs individual matches, another to control the
>> pairings etc, another to take contestants' pictures, and another to
>> register teams as they arrive). There is much shared code between the
>> executables, to ensure that file and communication formats are compatible.
>>
>> I have all this in one directory, for convenience, because when I build
>> the apps I build them all together & move them to the place where they
>> all run on game day; also because they share so much code.
>>
>> I could split them, but that would be at least a minor nuisance.
>
> What I recommend is to build all the targets at the same time, since
> building J apps should take a trivial amount of time. If so, there would
> be no need to split up the directory.
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm >
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
I have started putting the code I work on on a USB drive. This allows
me to work on it whether I am at home or at school, which speeds up
development enormously. There are some kinks that I am trying to work
around, and occurs to me that as long as we are discussing Project
Manager, maybe some of these problems can be addressed.
The environment is: code is on my USB drive; the resulting apps need to
be built on different machines with different targets: at school, a
network drive where all teachers can get to them, at home my home PC or
the USB drive itself.
The problems are:
0. You never know what disk letter a USB drive is going to get. Some
machines it is E, other H, others I. How do I set up the folder
containing the project so it can be seen on different machines? I have
a roaming profile so the J profile is the same everywhere; but this
means the folder's drive letter is wrong most places.
This is basically a deficiency in the folder system. I have worked
around it my having a program that sniffs out the drive that my stuff is
on, and modifies USERFOLDERS_j_. This is a kludge in that if I run
Edit|Configure, USERFOLDERS can get set back to its unmodified state. I
think I want some intelligent folder definition that works with USB drives.
1. The target varies from system to system. At school, I must build to
a subdirectory of X: which is our shared tools disk. At home, I would
be happy to build to the USB drive itself.
My workaround has been to create an X: drive at home. This is a
kludge, and not transferable to other environments. What is needed is a
general way to have the targets, and perhaps some of the sources, depend
on which machine I am on.
2. I need backup! I am getting old enough that remembering where I put
my keys is a challenge - what happens if I lose my USB drive? I back up
the drive by hand, but I think that a 'backup' target, that just saves
everything, might be a good idea. It might even be helpful to take
backup every time Project Manager starts.
Henry
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
> Henry Rich wrote:
> > I have an application that produces 4 J executables, used for different
> > things (the application is management of quiz tournaments, and there is
> > one application that runs individual matches, another to control the
> > pairings etc, another to take contestants' pictures, and another to
> > register teams as they arrive). There is much shared code between the
> > executables, to ensure that file and communication formats are compatible.
> >
> > I have all this in one directory, for convenience, because when I build
> > the apps I build them all together & move them to the place where they
> > all run on game day; also because they share so much code.
> >
> > I could split them, but that would be at least a minor nuisance.
>
> What I recommend is to build all the targets at the same time, since
> building J apps should take a trivial amount of time. If so, there would
> be no need to split up the directory.
For test/debug cycle, only one of the multiple targets is meant to be
load because there are different and conflicting scripts for each
target.
--
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