What functionality do you wish NetLinx had / What annoys you?
true
Posts: 307
After working on Big C hardware for a while, I am finding myself coming back to more and more AMX jobs, which is pleasing. I come from a programming background, though, and honestly, find a few of the quirks of AMX a bit annoying (usually not so much as Big C's raped gcc2.95 for SIMPL+, but...). Some is likely oversight, others are expected but odd functionality, but what about Netlinx makes you tick?
Personally, the biggest two for me are:
Lack of ternary operators (condition ? if true : if false)
Cases handled differently from any other language
There are others ... just can't think of them right now, and they're not as annoying as these
What quirks or oversights do you wish were looked into, or which functionality do you wish was added?
Personally, the biggest two for me are:
Lack of ternary operators (condition ? if true : if false)
Cases handled differently from any other language
There are others ... just can't think of them right now, and they're not as annoying as these
What quirks or oversights do you wish were looked into, or which functionality do you wish was added?
0
Comments
oh, and tab completion for parameters in modules...
In regard to modules why can't we pass a constant value? Why does it need to be a variable? But we can pass a constant array, does this make sense?
> No IP Notifications
> No ability to manage Oline/Offline messages in telnet (anyone have a program that constantly goes online to read RSS feeds, it's impossible to get anything else done inside telnet)
> A functioning GET_LAST feature for level events
> No ability to check to see if an IP devices (server or client) is online, why do we need to track the status ourselves?
> Can't use Un-Declared variables!!!
> No auto code crafting. (automatically space programming as you type it, similar to Flash)
> No native XML parsing (Parent.Child. etc..)
True multi-threading; no more system crawling to a halt and freezing because of a busy process.
Real OOD: ability to call internal module functions from the outside.
More robust debugger.
Better version management.
Not really as big a list as it could have been; I have workarounds for all of the above, so they are little more than annoyances.
On the hardware side, my main gripe is the IRIS. That dang thing desperately needs updating. It drives me absolutely crazy to have trouble capturing signals that a $50 remote has no trouble with.
> Having Persistent Variables be able to hold their values in modules
A couple more:
- No utility to go through and identify unused variables, constants, calls and functions.
- Lack of a true first_available_port function for setting up IP communications.
Jeff
- Notifications from IP devices
(maybe if we all write this one they will do it)
- Ability to view notifications/diagnostics with more than one instance of NS at a time
(let me get my money's worth out of my dual screen)
- More descriptive errors...
("Major system error during code generation" is not helpful)
- and the ability to show us more than one error at a time.
(CodeWarrior, the first C++ compiler I ever used, goes through your program and shows all the errors it finds. Sometimes (rarely) it will display "Confused by earlier errors, bailing out" and stop. With NetLinx Studio, it seems every error confuses it to the point of giving up.)
- Better documentation of the runtime errors NetLinx throws.
(Recently I called TS and asked about 2 errors:
1. Ref Error ? Index to large
2. StackAssignExpress Error Unsupported
For the first error I was told that there are a problem with one of my arrays but the compiler wasn't being nice and telling me which array it was. (turns out it was because the array was an unbounded array that was a function parameter and I was trying to access cell [3] of it, when the string passed was 'A0')
For the second error the tech didn't know, and the only case where it came up was a case where a guy was using too many if statements without {} brackets. If your language throws a runtime error, there should be intelligent documentation of the error and your techs should have access to it.)
- Support for multiple packets, so I can change the contents of a multidimensional array in the debugger.
- If I start a transfer, and one of the files in question is open, then give me an opportunity to cancel the operation!! You currently throw an error window saying 'Such file is in use and will not be transferred!' and you only give me an OK button. It's NOT okay. It puts me in a race condition where I have to right click and cancel the transfer before the token gets sent, when the master reboots and I have to wait for it before trying again. This is bad design!
- Switch/Case is a beautiful coding structure. Implement it the way the rest of the world does.
Something similar to javadoc, or phpdoc for code documentation.
REGEXP would be extrememly useful for string parsing and manipulation.
+1 for ternary operators as well.
Why do you care about the ternary operator? It is easily replaced with an if else statement. I am sure most compilers turn them into that anyway.
Paul
I wasn't directing the OO comment at any on this forum. The AMX promo guff and training materials call it OO.
@a_riot42
The request for a ternary operator is just to allow a bit more shorthand for simple logic statement, just a way to keep things neat and simplistic.
I have a feeling that this was left out on purpose. I understand how it can be nice once you get used to it, but for the multitude of people new to programming and those that don't code often, I feel that the shorthand can be confusing and far from simplistic. I understand that you don't have to use it, but even one of the Java books I was reading recently discourages their use because it is easier to read code without them.
Just personal opinion and observations. I honestly don't care if they add it, as I can understand it, but I would probably stick to if else myself.
Jeff
To me, object oriented means user defined classes with methods, inheritance and data encapsulation. Not just user defined types which are analagous to structures in C which is not OO.
Also the ability to overload functions would be useful. (sometimes)
What would you gain by doing this? That is a lot of unnecessary overhead for an RTOS.
Paul
Classes, like structures, can store their own status and other info, and using member functions (unlike structures) can act on that that info without having to use for example an array to track states and which zone is currently controlled etc.
And with member functions data can truly be encapsulated by declaring data to be private to each instance of a class. Then it can only be changed by public functions of that class which gives the class itself control over it's own data. This is less risky than using a globally declared variable, which isn't associated with your device other than by your say so, to track the status of your device.
Inheritance: Devices could inherit from more generalized devices. If every device you use is powered then you may have a very basic class that stores On/Off state and has a generic 'power on' function. Devices derived from this class then automatically have state variables and a function for powering on the device which may or may not need to be overriden.
I know about Cafe Duet and Java but it would be nice to have some of this functionality in NS IMO.
This is true, although I hadn't really noticed it before. From the Programmer II objectives:
Based on the context, I'd say somebody confused Object Oriented with Event Driven. NetLinx is about as object oriented as C.
So I would ask that AMX instead of modifying NetLinx anymore make Duet a true platform to program with.
Just my two (or ten) cents.
In what regards is Duet not a true platform to program? I've only seen Duet in PIII but I thought the pitch was that pretty much anything Netlinx can do can also be done with Duet.
After PIII I was all psyched to start using Duet, but didn't have the $1K to spend (or willingness to part with said $1K).
That's the way it is now isn't it?
The last couple of single room systems I have been hired to do have been programmed exclusively in Duet (why? just because), and at some point in the next little while I figure I'll try a larger distributed system - but not quite there yet.
NetLinx could be left as is for use as an entry into the AMX world. Those that don't have the time or money or want to, to learn Duet/Java can still program great stuff (we've all been doing it for years). But for those of us that want OOP why not have Duet be full blown.
Trust me I don't like the $1000 dollar price tag either. But I would be more willing to pay a fee for Duet if I knew that was the only language I would have to use. Right now I can't justify paying $1000 bucks just to write modules. I can write modules right now for free. Sure there are the added benefits of Duet but I want those benefits to spread across all of my code.
Duet is a platform for developing device communication modules, not for developing entire programs. Your system will still be written in NetLinx, Duet just means that you can write your own device communication modules. My understanding is that it was originally developed so equipment manufacturers could write their own modules with needing to have their programmers learn NetLinx.
I don't recommend trying to write the entire program in Duet, but if you did try, you would still have lots of NetLinx code to pass data back and forth between your devices and your Duet code.
I'm personally happy with NetLinx as a language, and that's why I've been quiet so far on this thread. Sure, it's missing stuff I would use, but that's true of every language. I think it's a good balance, and well designed for the application. It's also a niche language, so its syntax and compiler aren't going to receive the same amount of attention that C or another major language will.
All you need is the Netlinx stub that calls the Duet module (in this case module meaning the whole nine yards).
We wrote an entire program in Java in PIII. It still had to have a Netlinx Master file (to call the Java code) but it was essentially one line, if I remember correctly.
This is why I was excited. I'm definitely NOT going to write Java modules to get called from a standard Netlinx program. Developing the additional protocol (levels, channels, send_commands, send_strings, whatever) to talk between Netlinx and Java is not something I'm going to do. SNAPI is not an option for me.
If I can do my complete system in Java (I think it is technically possible) I'm on board and think it is the next logical step for someone wanting "more" as far as programming a Netlinx box.
Oh yeah, except for the $1K issue plus the learning curve time required...
Mostly, readability. But, also for situations like this
send_string 0, "'Hello, I am ', age > 30 ? 'an oldster' : 'a youngster'"
As it is, you can't even do this in netlinx - one would have to use a temporary variable. (Or am I wrong?)
NetLinx is like many other typed languages that have this requirement. Just define your variable.
What I do wish is that I didn't have to declare variables in a define_variable area...
Perhaps... but Duet is such a hackjob, and is slow. I'm also not much of a Java dev
Don't forget that you can have multiple DEFINE_VARIABLE sections. If you have a bunch of variables that logically belong in a certain section of the code, stick them in a new DEFINE_VARIABLE section. Just don't forget to put a DEFINE_EVENT below it.
Also don't forget that you can use STACK_VARs and LOCAL_VARs in functions and events where you need them to reduce the number of global variables you need.
I am curious about others ideas, so if I don't think they make sense or I don't understand them I ask questions to find out. Not sure why you view this as 'negative'. In the field of programming, such back and forth is good to knead the best ideas out, and also to make people think. Sorry if you or anyone else was offended.
Paul
1. Duet is not slow. String operations are I think around 10x faster than netlinx. Some very simple code might be slightly slower, but not on the level that is implied. The thing that makes duet slow is the SNAPI router. If code was written completely in Duet, it would not incur this penalty.
2. You can write a program entirely in Duet, but you do still need one line of netlinx code to tell the processor to load your Duet code.
3. The biggest problem with Duet seems to be documentation. Duet opens up a LOT of functionality and even more control of AMX hardware, but because of this increased capability, you have to do a couple of extra coding things. Like instead of having separate command, string and online sections in NetLinx, device communications all fire the same method in Java and it is up to you to handle them accordingly. (You do have an indication as to what type of event it is tho
On those notes, I would like to see NetLinx keep its simplicity so that I can use it when I have very simple systems that don't require the level of control offered by duet. I would also like to see some resource dedicated to making Duet a little more polished so that it can be used as a complete system a little easier.
Jeff