Library Wishlist
Items that would be useful in the common library. Note that these must
not require changes to VEE itself. If you should happen to have a little time
and interest, here's some ideas! Posted in chronological order with no
ranking.
- Description - create an interface to Python . Presumably
similar to the Matlab Script object
- Posted - 4OCT2015 by Stan Bischof
- Estimated Difficulty - medium - interface is very well
documented and supported
- Estimated Value - high - could open up the whole Python
world within VEE
- Notes/References - Python provides a C API replete with
header files, docs and everything else needed. The basic interface should be
simple (see Python
Embedding) though may depend upon choosing a particular Python
distribution in order to deal with details.
Stumbling block may be in dealing with data types, passing data. Ideally would
be able to write Python scripts in VEE and execute them similarly to the way "Matlab
Script" deals with Matlab scripts. Unlike Matlab, Python is free so readily
available in its full capabilities, not a restricted subset. Python is very
widely used and well supported, so a Python interface could well lead to a very
wide range of extended capabilities. Probably makes sense to include the def
file in VEE so that it doesn't have to be kept track of - use importCLib().
Eventually want to pass variables by reference for efficiency and data size
reasons, but pass by value is more likely first step.
- Progress
- Description - Place help in the function ( and maybe
object) "Description" fields for the various function. This to augment the
web-based help
- Posted - 7OCT2015 by William Drago
- Estimated Difficulty - low but tedious
- Estimated Value - medium
- Notes/References - The "Description" field is available to
both User Objects and User Functions. For UO's it is accessed form the object
menu. For UO's it is also available for us in the Function and Object Browser.
Where this becomes a pain is that the Description field is, as of VEE7, RTF, but
the Function and Object Browser not only doesn't recognize RTF, but it also
doesn't recognize windows-style EOL. At the same time, if the description is
added via the GUI, then it is always RTF. Due to the RTF and EOL issues, the
text shown in Function and Object Browser becomes ugly and largely unreadable.
Workaround would be to create the description field with correct EOL and then
splice it into the library files manually. Simple enough but enough details that
it is tedious to do, not to mention the usual danger of manually modifying VEE
source. Clean way to do this may be to write a VEE program to automate as much
as possible (perhaps read the source HTML, generate the "description" lines
automatically with right EOL, then manually drop them into the lib files).
Another alternative is to modify the development VEE install to default to plain
text rather than RTF (as with VEE6 and before), which takes care of the RTF
issue. Then for the EOL issue use unix editor, or VEE program ,or quote each
line and be careful of the Description2 <linecount> syntax. Anyhow- need to work
out process before jumping into this one.
- Progress
- Description - Presently have downloaded HTML help. Would be
useful to have the help self-contained so that browser not needed to view it.
- Posted - 7OCT2015 by William Drago
- Estimated Difficulty - low but maybe tricky
- Estimated Value - low
- Notes/References - real trick here would be to choose the
right tools. Presumably one could find a tool that converts all of the library
documentation to a single PDF doc in an automated fashion. With this in place it
could be added to makeRelease so that there would be no manual steps. CHM would
be handled also in same manner. Once automated process in place this would be a
no-brainer. So- look for right tools to built completely automated process.
- Progress
09OCT2015 - take a stab at PDF referenceGuide using Acrobat. This seems
to work OK but would really like to have automated process if possible. Post
this one to the web for now as some might find it useful.
17OCT2015 - automated solution not yet found. It turns out that Acrobat ha an
OLE interface but documentation is not apparent and experimentation did not
yield success. Also other automation avenues didn't pan out- largely because
most would not maintain links within the end PDF. At this point it only takes a
few minutes to manually generate using Acrobat, so stay that route for now. CHM
appears to be more work since additional pages (index et al) need to be
generated.
- Description - Would like function to send email from VEE.
Once this is in place can also use it to send Text messages.
- Posted - 17OCT2015 by Stan Bischof
- Estimated Difficulty - medium low or high depending upon
implementation
- Estimated Value - medium
- Notes/References - In the "old" days it was very easy to
fire up SMTP on port 25 of a server and send email. This has been around since
the 90's in VEE's examples. While it will still function in some cases, in most
cases it will not since the bulk of mail servers have tightened up security and
use secure sockets (SSL or TLS) and in some cases alternate ports. One approach
would be to incorporate openSSL into VEE (probably as an imported library) and
then implement SMTPS. This would likely be a fair amount of effort. An
alternative- and likely far simpler- approach would be to choose one of the
various command-line mail tools that are available and send email by writing to
a file and then firing up the command-line tool. That way the vagarities of
ports and secure transfer are handled independently.
- Progress
- Description - Add AES encryption and decryption capability
- Posted - 20OCT2015 by Kjeld Alexander
- Estimated Difficulty - low to medium
- Estimated Value - low
- Notes/References - Could be added as a call to an external
program which would be quick and easy and likely makes sense since one usually
encrypts/decrypts files. Hardest part would be selecting which external program
to use and making distribution as invisible as possible. Or take approach of a
DLL and hence pass data direct to a function that would return the
encrypted (or decrypted) data. This would be useful if one wants to do the
encryption right inside VEE. Third route is to use David Watling's code
from 2007, though since it relies on kernel calls it would be less
portable/flexible.
- Progress
- Description - implement a probability "quantile" function.
- Posted - 21OCT2015 by Detlef Baranski
- Estimated Difficulty - low to medium
- Estimated Value - low to medium
- Notes/References - this would probably be best done as part
of a more general modern math library. As such it would be easy to implement,
likely requiring very little individual effort.
- Progress
- Description - create a waterfall plot to augment the
existing displays.
- Posted - - 21OCT2015 by Detlef Baranski
- Estimated Difficulty - medium
- Estimated Value - low to medium
- Notes/References - This has been on enhancement lists for 2
decades or more so is obviously non-trivial. The hard part of waterfalls is the
hidden-line removal. In this case almost certainly requires compiled code and
may require new display object completely. It is indeed possible to "fake" a
waterfall plot using the existing XY plot and redrawing lines, but while
visually it is not too bad, it lacks any ability to use markers or otherwise
identify data.
- Progress
- Description - veeos function names collide with user's
function names
- Posted - 02NOV2015 by Detlef Baranski
- Estimated Difficulty - low
- Estimated Value - high
- Notes/References - Anytime one has multiple locations where
functions can be found, one can (and likely will) have namespace collisions when
calling those functions. One way to address this is to use fully qualified
function names, and this approach was taken by initial Alpha veeos. However, as
Detlef points out, this helps prevent veeos from colliding with user's
functions, it does nothing to help the opposite problems: user's calls
accidentally seeing veeos functions.
- Progress - 04NOV2015: Alpha 2 version restructures the
library and redoes all function calls by adding a prefix ("o_") to all veeos
function names. (Actually there's one exception:
bootstrapLib doesn't add prefix to its functions, but that's for good
reasons). At the same time, the calls are changed to un-qualified which has the
advantage of being immune to future changes in veeos library names or content.
- Description - IEEE sets a universally-used standard
(IEEE-754) for representing floating point numbers. This is coded in virtually
every program including VEE that has to deal with floats, yet VEE has no exposed
method for converting to and from floats except for during IO. This is
occasionally useful inside of VEE but also when doing IO directly to memory such
as with register-based instrument control. Also, VEE only understands 32 and
64-bit floats, and not the 128-bit floats added well after VEE became "stable".
- Posted - 25JAN2016
- Estimated Difficulty - low
- Estimated Value - low
- Notes/References - IEEE-754 is well defined. Implement by
grabbing the standard and implementing. Likely a half dozen functions for
to/from 32,64 and 128-bit floats (4,8,16 bytes respectively).
- Progress
Issue
- Description -
- Posted -
- Estimated Difficulty -
- Estimated Value -
- Notes/References -
- Progress
© 2015.
All Rights Reserved.
Stan Bischof (stan@worldbadminton.com).
Last updated
10 November 2016 10:50.