> 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
>

Eh, sorry about that, ignore it. I shouldn't be sending email this late in the
day...

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
> Joakim Harsman
> Skickat: den 9 november 2009 17:47
> Till: dyalogusers@yahoogroups.com
> Kopia: Henrik Andersson
> �mne: SV: [dyalogusers] Performance gotchas of iota
>
> That's great news!
>
> Do you know when a version for AIX will be available so we can start
> testing there? And when issue 005280 will be patched in DSS? Can't really
> start testing without those two.
>
> 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
> > Morten Kromberg
> > Skickat: den 9 november 2009 12:20
> > Till: dyalogusers@yahoogroups.com
> > �mne: RE: [dyalogusers] Performance gotchas of iota
> >
> > Joakim,
> >
> > Thanks for reporting this: There is indeed a bug in 12.1 which means
> that
> > the composition of a left argument with the "matiota" idiom is not
> > retaining
> > the hash table. This will be the first official fix to version 12.1 -
> with
> > luck, you will be able to download this patch tomorrow (you'll need to
> > download the official 12.1 first in order to be able to apply it).
> >
> > Morten
> >
> > -----Original Message-----
> > From: Joakim Harsman [mailto:joakim.harsman@...]
> > Sent: 7. november 2009 11:47
> > To: dyalogusers@yahoogroups.com
> > Subject: SV: [dyalogusers] Performance gotchas of iota
> >
> >
> > Ah, can't believe I didn't think of making sure the right argument was a
> > matrix, of course that matters. The reason wew used this idiom and not a
> > straigt up composed iota is that we needed to keep the large char matrix
> > around for other things anyway and a vector of strings would eat up more
> > memory. Bu I guess we could use the vector just to build the hash table
> > and
> > still look things up in the matrix, that might work out nicely.
> >
> > Thanks for the analysis!
> >
> > -----Ursprungligt meddelande-----
> > Fr�n: dyalogusers@yahoogroups.com genom Morten Kromberg
> > Skickat: l� 2009-11-07 09:02
> > Till: dyalogusers@yahoogroups.com
> > �mne: RE: [dyalogusers] Performance gotchas of iota
> >
> > Joakim,
> >
> > Something is not right in v12.1 and we need to do more analysis to see
> > what
> > has come unstuck. However, a couple of comments right away:
> >
> > The reason why a single item is slow seems to be that this case is not
> > being
> > recognized as the "idiom case" because the right argument is a vector
> (see
> > the numbers below when I search for a one-row matrix instead). This is
> > true
> > in all versions, I think.
> >
> > We will investigate the problem and get back to you. But note that it is
> > faster (see calls to "find2" below) if you compose directly with iota...
> > Searching becomes so fast that you can hardly measure the CPU (the
> "split"
> > might hurt you if the right argument is a large character matrix to
> begin
> > with).
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

That's great news!

Do you know when a version for AIX will be available so we can start testing
there? And when issue 005280 will be patched in DSS? Can't really start testing
without those two.

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
> Morten Kromberg
> Skickat: den 9 november 2009 12:20
> Till: dyalogusers@yahoogroups.com
> �mne: RE: [dyalogusers] Performance gotchas of iota
>
> Joakim,
>
> Thanks for reporting this: There is indeed a bug in 12.1 which means that
> the composition of a left argument with the "matiota" idiom is not
> retaining
> the hash table. This will be the first official fix to version 12.1 - with
> luck, you will be able to download this patch tomorrow (you'll need to
> download the official 12.1 first in order to be able to apply it).
>
> Morten
>
> -----Original Message-----
> From: Joakim Harsman [mailto:joakim.harsman@...]
> Sent: 7. november 2009 11:47
> To: dyalogusers@yahoogroups.com
> Subject: SV: [dyalogusers] Performance gotchas of iota
>
>
> Ah, can't believe I didn't think of making sure the right argument was a
> matrix, of course that matters. The reason wew used this idiom and not a
> straigt up composed iota is that we needed to keep the large char matrix
> around for other things anyway and a vector of strings would eat up more
> memory. Bu I guess we could use the vector just to build the hash table
> and
> still look things up in the matrix, that might work out nicely.
>
> Thanks for the analysis!
>
> -----Ursprungligt meddelande-----
> Fr�n: dyalogusers@yahoogroups.com genom Morten Kromberg
> Skickat: l� 2009-11-07 09:02
> Till: dyalogusers@yahoogroups.com
> �mne: RE: [dyalogusers] Performance gotchas of iota
>
> Joakim,
>
> Something is not right in v12.1 and we need to do more analysis to see
> what
> has come unstuck. However, a couple of comments right away:
>
> The reason why a single item is slow seems to be that this case is not
> being
> recognized as the "idiom case" because the right argument is a vector (see
> the numbers below when I search for a one-row matrix instead). This is
> true
> in all versions, I think.
>
> We will investigate the problem and get back to you. But note that it is
> faster (see calls to "find2" below) if you compose directly with iota...
> Searching becomes so fast that you can hardly measure the CPU (the "split"
> might hurt you if the right argument is a large character matrix to begin
> with).
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Joakim,

I did introduce a performance bug in 12.1 where retained matrix iota
would rebuild the hash table at every call instead of reusing it. It has
been logged and fixed as issue 5349, and the fix should be in the next
DSS patch for 12.1.

And yes, the matrix iota idiom is "fast" only when both arguments are
matrices.

Thanks for the report,

Nicolas.




Joakim Harsman wrote:
>
>
> Ah, can't believe I didn't think of making sure the right argument was
> a matrix, of course that matters. The reason wew used this idiom and
> not a straigt up composed iota is that we needed to keep the large
> char matrix around for other things anyway and a vector of strings
> would eat up more memory. Bu I guess we could use the vector just to
> build the hash table and still look things up in the matrix, that
> might work out nicely.
>
> Thanks for the analysis!
>
> -----Ursprungligt meddelande-----
> Fr�n: dyalogusers@yahoogroups.com
> <mailto:dyalogusers%40yahoogroups.com> genom Morten Kromberg
> Skickat: l� 2009-11-07 09:02
> Till: dyalogusers@yahoogroups.com <mailto:dyalogusers%40yahoogroups.com>
> �mne: RE: [dyalogusers] Performance gotchas of iota
>
> Joakim,
>
> Something is not right in v12.1 and we need to do more analysis to see
> what has come unstuck. However, a couple of comments right away:
>
> The reason why a single item is slow seems to be that this case is not
> being recognized as the "idiom case" because the right argument is a
> vector (see the numbers below when I search for a one-row matrix
> instead). This is true in all versions, I think.
>
> We will investigate the problem and get back to you. But note that it
> is faster (see calls to "find2" below) if you compose directly with
> iota... Searching becomes so fast that you can hardly measure the CPU
> (the "split" might hurt you if the right argument is a large character
> matrix to begin with).
>
>

Joakim,

Thanks for reporting this: There is indeed a bug in 12.1 which means that
the composition of a left argument with the "matiota" idiom is not retaining
the hash table. This will be the first official fix to version 12.1 - with
luck, you will be able to download this patch tomorrow (you'll need to
download the official 12.1 first in order to be able to apply it).

Morten

-----Original Message-----
From: Joakim Harsman [mailto:joakim.harsman@...]
Sent: 7. november 2009 11:47
To: dyalogusers@yahoogroups.com
Subject: SV: [dyalogusers] Performance gotchas of iota


Ah, can't believe I didn't think of making sure the right argument was a
matrix, of course that matters. The reason wew used this idiom and not a
straigt up composed iota is that we needed to keep the large char matrix
around for other things anyway and a vector of strings would eat up more
memory. Bu I guess we could use the vector just to build the hash table and
still look things up in the matrix, that might work out nicely.

Thanks for the analysis!

-----Ursprungligt meddelande-----
Fr�n: dyalogusers@yahoogroups.com genom Morten Kromberg
Skickat: l� 2009-11-07 09:02
Till: dyalogusers@yahoogroups.com
�mne: RE: [dyalogusers] Performance gotchas of iota

Joakim,

Something is not right in v12.1 and we need to do more analysis to see what
has come unstuck. However, a couple of comments right away:

The reason why a single item is slow seems to be that this case is not being
recognized as the "idiom case" because the right argument is a vector (see
the numbers below when I search for a one-row matrix instead). This is true
in all versions, I think.

We will investigate the problem and get back to you. But note that it is
faster (see calls to "find2" below) if you compose directly with iota...
Searching becomes so fast that you can hardly measure the CPU (the "split"
might hurt you if the right argument is a large character matrix to begin
with).

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

Yahoo! Groups Links

In fact you can upgrade to W7 from Vista and only from Vista.
There is NO upgrade path from any XP version.
However, when installating over XP you can keep you hard disk.

There is also a little tool available from Microsoft supporting XP users:
Although you must install all you applications under W7, this tool is able to
save all the registry settings. One does not have to reconfigure the software
after the installation. Works best with Microsoft software.

Kai

--- In dyalogusers@yahoogroups.com, Dick Bowman <dick@...> wrote:
>
> I believe that upgrading from Vista is supported by Microsoft (they
> certainly offer it as an option on the upgrade disk).  I think the
> "little trick" is about upgrading from beta/RC versions of Windows 7.
>
> I've never been sure what "all the problems faced with Vista" are
> supposed to be - all that's ever hit me is that UAC is a pest (but I
> only ever really meet it when installing software) and that early in its
> life it was sluggish (at best) copying files across a network (but that
> was fixed a while ago).  Maybe I live a too-sheltered life.
>
> I'm no fan of Microsoft - but I do get puzzled when I encounter the "do
> a clean install every few months" crowd.
>
> So far the only beef I have with Windows 7 - and it's nothing to do with
> APL - is that whatever I try it won't restore my desktop layout after a
> shutdown and restart (shows all the folders in a  jumbled heap).
>
> Michael Hughes wrote:
> >
> >
> > I heard that if you upgrade from Vista then you continue with all the
> > problems faced with Vista.
> >
> > A clean install of Windows 7 is needed to avoid this.  That's probably
> > why Microsoft wont support the upgrade.
> >
> >
> >
> > *From:* dyalogusers@yahoogroups.com
> > [mailto:dyalogusers@yahoogroups.com] *On Behalf Of *martinsq
> > *Sent:* 08 November 2009 20:34
> > *To:* dyalogusers@yahoogroups.com
> > *Subject:* [dyalogusers] Re: APL/W and Windows 7?
> >
> >
> >
> >
> >
> > --- In dyalogusers@yahoogroups.com
> > <mailto:dyalogusers%40yahoogroups.com>, "Stefano Lanzavecchia"
> > <stf@> >wrote:
> >
> > > I have recently upgraded to the final release of Windows 7 as well
> > >(with a little trick since the upgrade path is not officially
> > >supported by Microsoft).
> > > Stefano
> > >
> >
> > Hi,
> > could you please let us know the 'little trick' or point us to it ?
> > Don't fancy reloading all of my programs again...
> > Thanks, regards,
> > Martin
> >
> >
> >
> >
>

November meeting of BAA-London

As previously announced to the group on the evening of the previous
meeting, we are pleased to announce that the next meeting of BAA-London
will be at the Knights Templar on Friday 27 November 2009 at 14.00.

We have a quiet room (before we arrive) with free secure broadband and a
good selection of beverages (not free).

http://maps.google.co.uk/maps?hl=en&ie=UTF8&ll=51.515313,-0.112031&spn=0.003472,\
0.010375&t=h&z=17

Look at http://groups.google.com/group/baa-london/topics here for more
discussion regarding on-going projects and agenda for November.

I heard that if you upgrade from Vista then you continue with all the problems faced with Vista.

A clean install of Windows 7 is needed to avoid this.  That’s probably why Microsoft wont support the upgrade.

 

From: dyalogusers@yahoogroups.com [mailto:dyalogusers@yahoogroups.com] On Behalf Of martinsq
Sent: 08 November 2009 20:34
To: dyalogusers@yahoogroups.com
Subject: [dyalogusers] Re: APL/W and Windows 7?

 

 

--- In dyalogusers@yahoogroups.com, "Stefano Lanzavecchia" <stf@...> >wrote:

> I have recently upgraded to the final release of Windows 7 as well >(with a little trick since the upgrade path is not officially >supported by Microsoft).
> Stefano
>

Hi,
could you please let us know the 'little trick' or point us to it ?
Don't fancy reloading all of my programs again...
Thanks, regards,
Martin