Differences between revisions 22 and 25 (spanning 3 versions)
Revision 22 as of 2008-10-03 06:27:59
Size: 2110
Editor: KaiJaeger
Comment:
Revision 25 as of 2008-12-15 17:57:45
Size: 1537
Editor: KaiJaeger
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
= APL Application Programming Library (APL) = = APL Application Programming Library (APLAPL) =
Line 4: Line 4:
At the time being, everything here refers to Dyalog APL. That might change sometime, but as long as no other stuff turns up here it keeps things simple. Note that this is a pure Dyalog project. Note also that by definition only classes can be part of APLAPL.
Line 6: Line 6:
All classes published here '''must''' be part of '''"The Open Source APL Project"''' in short '''[[OpenSourceAplProject|TOSAP]]'''. Yes, classes, so it has to be at least version 11 of Dyalog APL you are working with. The basic idea behind APLAPL is to provide classes for every-day-problems programmers typically come across.
Line 8: Line 8:
The idea behind TOSAP is to provide classes ready for usage for every-day-problems programmers typically come across.

Note that there is a significant difference between downloading a script from the wiki and checking out the associated project from !SubVersion:

 * The wiki download contains the script and maybe something else you need to run the script.
 * The subproject comes with more stuff, especially with a development workspace which '''must''' contain a test suite. Only fully tested scripts should offered to the public for download.
To become part of the APLAPL project, one must ensure that proper testcases are written and executed before the class is published.
Line 20: Line 15:
||[[APLTeamsUtil]]||General utilities||Dyalog||APL Team||'''No'''|| ||[[APLTeamUtils]]||General utilities||Dyalog||APL Team||'''No'''||

APL Application Programming Library (APLAPL)

Note that this is a pure Dyalog project. Note also that by definition only classes can be part of APLAPL.

The basic idea behind APLAPL is to provide classes for every-day-problems programmers typically come across.

To become part of the APLAPL project, one must ensure that proper testcases are written and executed before the class is published.

Many but not all classes do not use .NET at all. That might look strange: there are tons of useful .NET classes available, and they are free, so why not using them? Well, it all depends. Try to get a directory listing of a directory which contains 100,000 files and you know what I mean.

Name

Description

Type

Originator

Needs .NET

APLTeamUtils

General utilities

Dyalog

APL Team

No

ADOC

Automated Documentation Generation

Dyalog

APL Team

No

Hash

Managing key/value-pairs

Dyalog

APL Team

No

IniFiles

Dealing with INI files

Dyalog

APL Team

No

Logger

Writing Log Files

Dyalog

APL Team

No

WindowsEventLog

Dealing with the Windows Event Log

Dyalog

APL Team

Yes

WinFile

Dealing with files and directories

Dyalog

APL Team

No

WinReg

Dealing with the Windows Registry

Dyalog

APL Team

No


CategoryAplApl CategoryOpenSourceApl

CategoryAplTree (last edited 2018-03-04 12:46:55 by KaiJaeger)