[john d] You should probably []NA to CreateProcess or WinExec...

[jim]  Thanks.  I never liked batch files anyway.

[jim]  By chance would the []NA incantation for either of those be simple enough
to post here?

[jim]  THANKS.

Given that the source for program "WheresMyReturnCode.exe" is:

using System;
     class Program
         {
         static int Main()
             {
             Console.WriteLine("OneTwoThree");
             return 123;
             }
         }
-------------------------------------------------------
And the source for batch file "runIt.bat"  is:

@rem runIt.bat
@echo off
echo here we go
Start %1 %2
echo %ERRORLEVEL%
echo there we went
--------------------------------------------------------
Running these at the command prompt yields:

C:\>WheresMyReturnCode
OneTwoThree

C:\>runIt WheresMyReturnCode
here we go
123
there we went
--------------------------------------------------------
Running the same thing with []CMD (V12.1 Unicode Version) yields:

[]CMD     'c:\runIt    c:\WheresMyReturnCode'
here we go
0
there we went
---------------------------------------------------------
Now what?

-----Alkuperäinen viesti-----
Lähettäjä: dyalogusers@yahoogroups.com [mailto:dyalogusers@yahoogroups.com]Puolesta Jim Goff
Lähetetty: 20. marraskuuta 2009 13:41
Vastaanottaja: dyalogusers@yahoogroups.com
Aihe: [dyalogusers] how to read a return code using []CMD

 

Given a trivial result returning non-apl program like:

    class Program

        {

        static int Main()

            {

             return 123;

            }

        }

What’s the []CMD syntax for getting the 123 into the Dyalog workspace?

A batch file would do it something like:

rem test.bat

@echo off

SimpleResultReturningPgm

@if "%ERRORLEVEL%" == "0" goto good

:fail

    echo Execution Failed

    echo return value = %ERRORLEVEL%

    goto end

:good

    echo Execution succeeded

    echo Return value = %ERRORLEVEL%

    goto end

:end

-----------------

Unfortunately, I’m not quite sure what mechanism test.bat is using.

Thanks for any advice,

J. Goff

Interesting questions... It is encouraging to see that the community is
building up enough experience to have discuss topics related to the design
of Object-Oriented solutions in APL – and have a bunch of different
opinions!



I can’t claim to know the answers, I suspect that there may not be any
“right” answers. Like so many other design issues, the most convenient
design depends on exactly what you are trying to do, and may change during
the life of a project. The most maintainable solution may be different for a
small application than it would be for an application with dozens of modules
and a lot of utility libraries.



I sometimes use the technique that Stefano Lanzavecchia mentions: Using a
“ref” to give me a short name to namespaces or classes that I use frequently
or might want to relocate – but this can occasionally come “unstuck”: If
you)copy the referenced namespaces or classes from another workspace, you
can end up with the new code in the “named” space and the old code still
around as an “anonymous” copy at the end of your old refs, which is
confusing, to say the least. If you use this technique, you need to make
sure that the refs get refreshed each time the application is reset.



I think I agree with Joakim Hårsman: We are missing one or two tools to make
this all work nicely. Note that SALT does have a syntax to declare
dependencies between source files, if you have



⍝∇:require pathname



… in a SALT file, SALT will also Load the named file. See page 13 of
http://www.dyalog.com/documentation/12.1/SALT.pdf for more information.



However, this does not solve the issue of how code references “other
components”. I DO find myself wishing that we had something which combined
[]PATH and []USING into a mechanism with “namespace scope”.  I think the
problems that Stephen Taylor describes would have been solved by such a
mechanism. We will take a look at extending []USING in v13 to allow
“traditional” using statements as if (for example) C# - for APL names as
well as external .NET names. And if we go ahead and build the basic SALT
functionality into the interpreter for v13 as planned, we’ll try to include
a mechanism for handling dependencies as well – either in the interpreter or
in a thin layer of SALT on top of it.



I think it is a good idea to group related classes (and namespaces) together
within container namespaces. This allows a family of “spaces” to mutually
use ## - as Phil Last suggests – assuming that although they may be
relocated, they should all be relocated to the same place as a group. Of
course, INSTANCES usually can NOT use ##, because this is as a reference to
the space where they were created, rather than the container within which
the class is defined.



I rarely feel comfortable putting anything in the root any longer, except
“Main” functions which start applications – and even these tend to be
called
“Application.Start” nowadays.



Although it may be advisable to embed classes within one or more namespaces,
this doesn’t mean they should all be in the same script, only that they
should get loaded into namespaces when the application starts. Regardless of
the workspace structure, I would ALWAYS use SALT to load my script files
into the workspace, rather than use a workspace as (permanent) storage for
namespaces and classes.



Morten



From: Jim Goff [mailto:jgoff@...]
Sent: 11. november 2009 21:34
To: dyalogusers@yahoogroups.com
Subject: [dyalogusers] class of classes vs. namespace of classes





When doing Dyalog OO programming and building an application consisting of
many Classes (all the same level) which is preferable:

1) grouping them inside a containing Class, or

2) grouping them within a Namespace

What are the pros and cons?

What’s the recommended usage?



Thanks,

J. Goff

yh giangi quario wrote:
> I need some suggestions regarding  the exploitation of the []DF display form.
>
> Anyone can provide a tool for obtaining the <[]NL 9  name> of any  object
whose display form is know?
>
>
>
> Thank you for your attention.
>
> Gianluigi Quario


I should assume that in general the answer must be NO!

Any function can set the ⎕DF of any namespace it can see unless
constrained by privacy considerations. So it may be that every namespace
in the workspace has the same ⎕DF!

It would be possible to find a set of possible candidates for a ⎕DF of
'This', say, by doing something like (untried):

poss←'This'{⍵/⍨(⍕¨⍵)∊⊂⍺}refs #

where "refs" is the function of that name from the supplied dfns workspace.

You would then have to do something like:

{}poss.⎕DF ⎕NULL

to reset their display forms back to the default.

Then:

names←⍕¨poss

may possibly be the result you want.

Then:

poss.⎕DF⊂'This'

to re-instate.

!

> At first I replicated this structure in the workspace. It was
> workable, but I regretted it early enough to change to loading all
> classes into the root. (Apart from a small number of private classes
> defined within and used only by their containing classes.)
>
> Chief reason was references between classes. On the first scheme,
> using a class meant knowing its location in the hierarchy. So the
> hierarchy became a part of the definitions of the classes, which was
> too tangled for me. The class hierarchy quickly became awkward to
> change. I redefined all the classes into the root and the issue went
> away.

I remember having a discussion with Morten early on on this very issue.
Polluting the root means, effectively, that you can't share your code with
others. Not too bad if the application is self-contained, but one day you
might be your own enemy when you need to merge in the same workspace two
classes with the same name and different behaviour.

At the time Morten proposed the idea of assigning a namespace to reduce the
length of your class names. For instance: #.GUI<-#.WildHeart.Gui and then
you can []NEW #.GUI.Form instead of #.WildHeart.Gui.Form.

The "using" statement in C# serves exactly the purpose of giving the
impression that classes (more properly "types") in a nested structure of
namespaces are in the root namespace. This looks dangerously similar to
[]PATH, but somehow it scares me less in C#.

Your comments confirm my idea that something must be done to improve the
usage of classes in Dyalog APL...

--
Stefano

[[Omaeni aitai kono sabishisa wakachi aeru ---
   I want to see the one who can share this sadness]]

If you are willing to use .NET there's an FMOD .NET version here:
http://sourceforge.net/projects/fmodnet/

I haven't tried it, so I don't know how well it works or if it offers all
features of the original, but it should be easier to use.

Gil

--- In dyalogusers@yahoogroups.com, "Brooke" <mapledyalog@...> wrote:
>
> I don't know how to do a bleedin' thing with a computer unless it is in APL,
and yet I want to be able to play withFMOD, which is, according to their web
site:
>
> http://www.fmod.org/
>
> "The FMOD Ex Programmer's API and Designer are a world-leading library and
toolkit for the creation and playback of interactive audio."
>
> Has anyone used this?
> Has anyone used it with APL?
> Has anyone used it with Dyalog APL?
>
> Does anyone want to?
>
> If someone wants to propose creating an interface, I may be able to pay some
small amount ($1,000-$1,500 or so).
>
> Anyone have an interest?
>
> Brooke
>

--- In dyalogusers@yahoogroups.com, "Jim Goff" <jgoff@...> wrote:
>
> When doing Dyalog OO programming and building an application consisting of
many Classes (all the same level) which is preferable:
>
> 1) grouping them inside a containing Class, or

This make me shudder.

>
> 2) grouping them within a Namespace

This is what I do.

> What are the pros and cons?

Can't really articulate why. I think my maxim is never use a class when a
namespace will do.

In trying to present the choice in actual code, I think I’ve discovered the
optimal strategy. The choice was between “NestedClass” and
“JustNameSpace”.
I think the winner is “JustNameSpace”. I’ll leave it to someone else to
explain why. ☺

:Namespace JustNamespace
     :Class MainClass
         ∇ Main
           :Access Public Shared
           inst←⎕NEW SiblingClass
           ⎕←inst.jMethod
         ∇
     :EndClass

     :Class SiblingClass
         ∇ r←jMethod
           :Access Public
           r←'hello world'
         ∇
     :EndClass
:EndNamespace

JustNamespace.MainClass.Main
hello world

-------------------

:Class NestedClass
:Class MainClass
:Access Public
∇ Main
:Access Public Shared
inst←⎕NEW SiblingClass
⎕←inst.jMethod
∇
:EndClass

:Class SiblingClass
∇ r←jMethod
:Access Public
r←'hello world'
∇
:EndClass
:EndClass


j←⎕new NestedClass
j.MainClass.Main
hello world

--------------

In trying to present the choice in actual code, I think I’ve discovered the
optimal strategy.  The choice was between “NestedClass” and
“JustNameSpace”.
I think the winner is “JustNameSpace”.  I’ll leave it to someone else to
explain why. ☺

:Class NestedClass
     :Class MainClass
     :Access Public
         ∇ Main
           :Access Public Shared
            inst←⎕NEW SiblingClass
           ⎕←inst.jMethod
         ∇
     :EndClass

     :Class SiblingClass
         ∇ r←jMethod
           :Access Public
           r←'hello world'
         ∇
     :EndClass
:EndClass


        j←⎕new  NestedClass
        j.MainClass.Main
hello world

  -------------

:Class NestedClass
     :Class MainClass
     :Access Public
         ∇ Main
           :Access Public Shared
           inst←⎕NEW SiblingClass
           ⎕←inst.jMethod
         ∇
     :EndClass

     :Class SiblingClass
         ∇ r←jMethod
           :Access Public
           r←'hello world'
         ∇
     :EndClass
:EndClass

       JustNamespace.MainClass.Main
hello world

--------------

I've always found ## the best tool for managing hierarchies of
namespaces. Having a source know the relative position of another target
namespace and making all external calls as ##.whatever allows the
sub-tree that contains source & target to be slotted in anywhere within
a larger unknown one.

To keep the paths short within code, at the start of a function or in a
class script define a namespace variable or class field to contain a ref
to the target.

We can use this technique incrementally so that nothing ever needs to
know even the relative whereabouts of anything but parent or sibling.

acre code management system can be imported into and run from anywhere
within the namespace tree.

Using these techniques, if I locate it in the root and generate a list
that contains its entire namespace tree, then:

        list+.='.'
1 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 4 3 3 3 3

It has 22 sub-nss to a depth of 4 and no-where does it so much as name
itself.

If I located it in namespace #.Tools.Code then we would merely add 2 to
the above without changing any code.

Phil

I think Dyalog APL desperately needs a module system. Just some way to say
inside a namespace that it depends on some other namespace and a way to alter
name resolution so that you don't have to fully qualify everything all the time.

If []PATH had namespace scope, that would probably be enough to build on.

We have sort of a hacked together module system where a global function import
can be called with a module name to import that modules functions into global
scope. This predates namespaces so all functions inside a module are prefixed
with the module name, and each module has a special function __on_import__ that
get's called whenever it's imported and that contains calls to import whatever
it needs.

It works, but it's cumbersome to have to write out the full path to everything
all the time, have things in namespaces (although probably only one level deep)
would be nicer.

In conclusion, I wouldn't nest namespaces but I would group classes or functions
that belong together in namespaces.

Joakim Hårsman

Head of development, Profdoc Care
+46-8 440 93 78
http://www.profdoc.se

> -----Ursprungligt meddelande-----
> Från: dyalogusers@yahoogroups.com [mailto:dyalogusers@yahoogroups.com] För
> sjt52
> Skickat: den 12 november 2009 10:00
> Till: dyalogusers@yahoogroups.com
> Ämne: [dyalogusers] Re: class of classes vs. namespace of classes
>
> Jim
>
> I wrote Dyalog's Customer Relationship Management (CRM) system entirely in
> Dyalog 12 and salted scripts.
>
> At first I supposed I would take the approach you describe, and keep all
> classes in some kind of container. I recall wanting to keep the root free,
> perhaps a nostalgia for the Sharp 666 MAILBOX workspace.
>
> The class scripts are organised in filesystem folders, something like:
>
> lib
> lib/gui
> lib/gui/controls
> lib/gui/forms
> lib/gui/views
> lib/tools
> lib/tools/…
>
> At first I replicated this structure in the workspace. It was workable,
> but I regretted it early enough to change to loading all classes into the
> root. (Apart from a small number of private classes defined within and
> used only by their containing classes.)
>
> Chief reason was references between classes. On the first scheme, using a
> class meant knowing its location in the hierarchy. So the hierarchy became
> a part of the definitions of the classes, which was too tangled for me.
> The class hierarchy quickly became awkward to change. I redefined all the
> classes into the root and the issue went away.
>
> I considered and rejected enclosing the classes in a container. They
> might, for instance, have been enclosed in a root namespace Lib. That
> would have been slightly tidier, but would have changed every class
> reference from #.MyClass to #.Lib.MyClass: the tidiness didn't seem worth
> even that reduction of readability.
>
> Private classes could be invoked by their parents using relative names, so
> no hierarchy issue there.
>
> With *very* many more classes, I would reconsider.
>
> With collections of classes imported from some library, I would
> reconsider. Is there a way to define a group of classes in a container
> whose name you can choose? For example, suppose related library classes A,
> B and C all call each other. To avoid clashing with other class names,
> they are encapsulated in a container, say, Z. Can I choose a different
> name for Z in my app?
>
> An instance of #.Z.A refers to B. Can it do so using local name B, or must
> it use the fully-qualified name #.Z.B? If the latter, then #.Z. becomes
> part of the class definitions and the collection can be defined in the
> workspace only in that name. So, not Z or the name of your choice, but the
> KindaNameYouSeeInDotNetAssemblies, and no option.
>
> Alternatively the #.Z.A instance can refer to #.Z.B as B provided the
> *instance* is itself defined within #.Z.
>
> This stuff gets ugly fast. Defining all classes in the root is a
> considerable simplification.
>
> I suppose a hierarchy of classes routine in say Java projects. But then
> it's a virtue of APL that it lets me elide annoying loops; why not this
> too? CRM is a non-trivial application, but doesn't have too many classes
> to define in the root.
>
> HTH
>
> Stephen
>
>
>
> --- In dyalogusers@yahoogroups.com, "Jim Goff" <jgoff@...> wrote:
> >
> > [Graeme] Why not put them all in the Root (#)?
> >
> > [Jim]  Because that would limit you to one group of Classes per
> workspace.  Previously we could only group things using Namespaces.  Since
> we now can use either Namespaces or Classes, I wonder which is better?
> >
> > From: dyalogusers@yahoogroups.com [mailto:dyalogusers@yahoogroups.com]
> On Behalf Of Jim Goff
> > Sent: 11 November 2009 20:34
> > To: dyalogusers@yahoogroups.com
> > Subject: [dyalogusers] class of classes vs. namespace of classes
> >
> > When doing Dyalog OO programming and building an application consisting
> of many Classes (all the same level) which is preferable:
> > 1) grouping them inside a containing Class, or
> > 2) grouping them within a Namespace
> >
> > What are the pros and cons?
> > What’s the recommended usage?
> >
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Jim

I wrote Dyalog's Customer Relationship Management (CRM) system entirely in
Dyalog 12 and salted scripts.

At first I supposed I would take the approach you describe, and keep all classes
in some kind of container. I recall wanting to keep the root free, perhaps a
nostalgia for the Sharp 666 MAILBOX workspace.

The class scripts are organised in filesystem folders, something like:

lib
lib/gui
lib/gui/controls
lib/gui/forms
lib/gui/views
lib/tools
lib/tools/�

At first I replicated this structure in the workspace. It was workable, but I
regretted it early enough to change to loading all classes into the root. (Apart
from a small number of private classes defined within and used only by their
containing classes.)

Chief reason was references between classes. On the first scheme, using a class
meant knowing its location in the hierarchy. So the hierarchy became a part of
the definitions of the classes, which was too tangled for me. The class
hierarchy quickly became awkward to change. I redefined all the classes into the
root and the issue went away.

I considered and rejected enclosing the classes in a container. They might, for
instance, have been enclosed in a root namespace Lib. That would have been
slightly tidier, but would have changed every class reference from #.MyClass to
#.Lib.MyClass: the tidiness didn't seem worth even that reduction of
readability.

Private classes could be invoked by their parents using relative names, so no
hierarchy issue there.

With *very* many more classes, I would reconsider.

With collections of classes imported from some library, I would reconsider. Is
there a way to define a group of classes in a container whose name you can
choose? For example, suppose related library classes A, B and C all call each
other. To avoid clashing with other class names, they are encapsulated in a
container, say, Z. Can I choose a different name for Z in my app?

An instance of #.Z.A refers to B. Can it do so using local name B, or must it
use the fully-qualified name #.Z.B? If the latter, then #.Z. becomes part of the
class definitions and the collection can be defined in the workspace only in
that name. So, not Z or the name of your choice, but the
KindaNameYouSeeInDotNetAssemblies, and no option.

Alternatively the #.Z.A instance can refer to #.Z.B as B provided the *instance*
is itself defined within #.Z.

This stuff gets ugly fast. Defining all classes in the root is a considerable
simplification.

I suppose a hierarchy of classes routine in say Java projects. But then it's a
virtue of APL that it lets me elide annoying loops; why not this too? CRM is a
non-trivial application, but doesn't have too many classes to define in the
root.

HTH

Stephen



--- In dyalogusers@yahoogroups.com, "Jim Goff" <jgoff@...> wrote:
>
> [Graeme] Why not put them all in the Root (#)?
>
> [Jim]  Because that would limit you to one group of Classes per workspace. 
Previously we could only group things using Namespaces.  Since we now can use
either Namespaces or Classes, I wonder which is better?
>
> From: dyalogusers@yahoogroups.com [mailto:dyalogusers@yahoogroups.com] On
Behalf Of Jim Goff
> Sent: 11 November 2009 20:34
> To: dyalogusers@yahoogroups.com
> Subject: [dyalogusers] class of classes vs. namespace of classes
>
> When doing Dyalog OO programming and building an application consisting of
many Classes (all the same level) which is preferable:
> 1) grouping them inside a containing Class, or
> 2) grouping them within a Namespace
>
> What are the pros and cons?
> What’s the recommended usage?
>

I spoke to them and they will not be able to do this at this time.

--- In dyalogusers@yahoogroups.com, "neeraj_gupta_us" <neeraj_gupta_us@...>
wrote:
>
> I am forwarding your request to somebody who is doing some APL work for me. I
will get back to you.
>
> --- In dyalogusers@yahoogroups.com, "Brooke" <mapledyalog@> wrote:
> >
> > I don't know how to do a bleedin' thing with a computer unless it is in APL,
and yet I want to be able to play withFMOD, which is, according to their web
site:
> >
> > http://www.fmod.org/
> >
> > "The FMOD Ex Programmer's API and Designer are a world-leading library and
toolkit for the creation and playback of interactive audio."
> >
> > Has anyone used this?
> > Has anyone used it with APL?
> > Has anyone used it with Dyalog APL?
> >
> > Does anyone want to?
> >
> > If someone wants to propose creating an interface, I may be able to pay some
small amount ($1,000-$1,500 or so).
> >
> > Anyone have an interest?
> >
> > Brooke
> >
>

Security features I read of introduced by Vista included:

� an unpublished digital-rights management (DRM) algorithm with which the OS
assesses whether a file contains 'proprietary material' protected by copyright;
my neighbours report Vista assesses their home movies to be proprietary;

� a certification program for peripherals to assure the OS a device complies
with its policy of degrading output quality for proprietary material for which
the OS finds no licence; uncertified devices simply get disabled for unlicensed
material; certification (for eg your expensive HD television) can be withdrawn
via software updates;

� bus-level encryption to prevent anyone hacking their way past the DRM; users
have reported this drawing so much CPU some new machines with Vista were unable
to play DVDs smoothly;

Does anyone know whether these features made it into Windows 7?

Stephen



--- In dyalogusers@yahoogroups.com, "Michael Hughes" <Michael@...> wrote:
>
> Vista introduced extra security features so I don't think its as easy as
> that
>
>
>
> From: dyalogusers@yahoogroups.com [mailto:dyalogusers@yahoogroups.com] On
> Behalf Of PMHager
> Sent: 09 November 2009 17:49
> To: dyalogusers@yahoogroups.com
> Subject: RE: [dyalogusers] Re: APL/W and Windows 7?
>
>
>
>
>
> As I as well have never installed a Vista, just a stupid question for me to
> understand:
>
> I always did assume Vista would make use of the NTFS file access rights to
> protect
>
> applications in the "program files" and just changing the user rights of an
> .ini file from
>
> read-only to r/w would be sufficient. (Might be, also r/w for the containing
> needs to be
>
> enabled if creating/deleting an .ini file shall be permitted.)
>
> Am I wrong?
>
>
>
>   _____
>
>  Michael Huges wrote:
>
> "The problems I have had with Vista were trying to install software under
> c:\program files\........ no ini file would update because of the UAC.   I
> had to get my users to install my programs under a directory off root.  Took
> me ages to realise that it was windows Vista having different rules for
> different directories.  "
>
>
>
>
>
> __________ Information from ESET Smart Security, version of virus signature
> database 4580 (20091106) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>