ShaunR

Ah, but 1 developer x many (small) projects that could use logging and it gets expensive.

Not if he gives them away free too

Sorry, I know little about the terminology of licensing. At a consulting firm I’m doing some work for, they would like a reusable error/debug logger for use in their many projects. I suggested your logger. But, if I read it right, the SQLite API has to be licensed for each project (each “product”), which isn’t going to fly. My other options are a non-database solution, using Saphir’s SmartSQLVIEW, or calling the SQLite all directly with SQL statements. I actually prefer the last option (even though it will be much more limited and less polished than your stuff) as I can then use it as a logger in my message/actor framework without inheriting any licensing issues. Need to polish up my SQL, anyway.

Indeed. Your mileage will depend on what you want. The advantage of the license/waiver is that it's not a per-seat license (effectively a site-wide license) so you can have lots of developers and install it on as many machines as you like (for developing that product) as well as no new fees for updates (of the toolkit) or periodic payments. 100 developersx1 product = about $1200 for the lifetime of the SQLite API (free upgrades).

And lets not forget that if you are using it internally (e.g for your production line) it's completely free. I prefer to think of it that businesses that are interested in using it for monetising are supporting the development so that everone can benefit (after all, if you are selling product, the commercial cost is passed on, is it not?).

The other way you have to pay per developer and everytime a new release (of the toolkit) comes out. 100 developersx1 product= about $69,900 every time you want to upgrade.

It always strikes me as funny (as in ha, ha) that Labview people are prepared to pay tens of thousands of dollars every year to NI (basically just to get bug fixes) but balk at trivial costs for anything non-NI.

I'm not making huge amounts off of it. But if others are, shouldn't a little bit of that come my way?

At the end of the day, though. It depends on how much you value your time. For the amount of time I have spent on the API, I would have quoted considerably more if a customer wanted it. (the gochtya are the dlls )

You've now heard the position of the "OO is bad" crowd.

Wow. I'm a crowd? I really can be in two places at once (multiple salaries )

So maybe I'll try a C++ .dll instead... sigh.

For raw speed. It's the only way. Labview is fast (in comparison to, say Java), but not the fastest. A dll call will probably only add about 1-3 usecs of overhead.

but not fair use to use in commerical apps?

Examples of fair use include commentary, criticism, news reporting, research, teaching, library archiving and scholarship

Common misunderstandings

• Any use that seems fair is fair use. In the law, the term fair use has a specific meaning that only partly overlaps the plain-English meaning of the words. While judges have much leeway in deciding how to apply fair use guidelines, not every use that is commonly considered "fair" counts as fair use under the law.
  

Source.

Hi Shaun,

Can you clarify the “fair use” of your database logger (and SQLite API)? I’d like to use it (or a modified version) as an error logger in custom software projects for clients.

— James

Well. The database logger is shipped, as an example, with the SQLite API now (so it is covered by the sqlite api license). But it's not a lot of good without the API. I suppose you could hack the api stuff out and use something else, but I think it would be a lot more complicated.

"Fair Use" is a bit moot since the SQLite API is distributed under a non-commercial share-alike license, so for evaluations, articles etc (where fair use is targeted) it is perfectly acceptable to use it under the current license.

Depending on Irrespective of the size of your point data, does it make sense to use LVOOP? I have no benchmarks to point to, but I imagine for small data, the overhead of LVOOP will outweigh the performance of, say, a cluster of {prev, data, next} for loop that you don't get the nice OOP-ness with. There will probably be more less legwork with that route (and you may won't have to be more careful with memory allocations) but I think for the performance spec you're looking to hit, the simple route may be more effective.

....and get rid of the queues.

So. Where can I download the IDE? (I like it!)

The example of an electrical circuit was the original premis of labview. We have had this sort of functionality since day dot (custom probes with a waveform graph). I think custom probes are generally underused and i'd love to see a custom probe pack with waveforms, plots etc.

hmmmmmmmmm sounds like a non-announcement announcement of an as yet unknown capability.

Naaah. He just means they've added more wizards

So.

Anyone offering the car wash and traffic lights?

(BTW ShaunR, I see u no longer have your "lvoop bugs" jingle. R u now a convert?)

Nope. Apart from the odd list encapsulation. I steer well clear of it unless dragged kicking and screaming.

However. LVPOOP is now a part of LabVIEW and the CLD exams are specified tasks with example answers. So for people learning LabVIEW (and have been infected with the OOP virus), they are an ideal way to learn the pro's and cons of adopting the paradigm. More importantaly though, they can show that elusive aspect of how to go about solving a specific task using LVPOOP rather than trying to review more complicated private projects (that have no exampled equivalence to classical LabVIEW) and then trying to figure out how to apply it to thier situation.

The CR/LF constant in labview is platform dependent. It also depends on which browser you are viewing in (some are happy with only one EOL char, others require both). You should use a constant string with "\r\n" which will work on all platforms and browsers.

I was thinking we could just make a new category in the code repository? That's essentially what we're talking about, after all, it just happens to be a specific implementation instead of reuse code.

I guess the choice will depend on if you want to track the code and related posts (comments etc...) or just the code.

Hmm.

The CR seems a bit "formal" to me but has the "pro" that each submitter is responsible for their submission so no centralised maintenance.

Not keen on the document idea which would basically be just a list of links that someone has to maintain.

I was thinking of just an extra category in the forums (like the Object-Oriented Programming, User Interface, Remote Control, Monitoring and the Internet, etc) that would just pull together the current posts and people could add theirs as and when they were created. People could also use that area for requests for code reviews of examples they want people to comment on.

I posted the sprinkler controller here a while ago.

Sweet.

I wonder if we could get an "area" on Lava for these so they are all in one place and easy to find

Here you go:

http://lavag.org/top...abview-classes/

Great.

Traffic lights, car wash anyone?

It's still not clear to me what the overall goal is.

Well. I really can't think of any other ways to phrase it that I haven't already.....

then maybe some of the LVOOP gurus could post unofficial, demonstrative LVOOP implementations of the example exams (ATM, traffic lights etc).

To provide (unofficial, demonstration) LVOOP solutions of CLD example exams

for the benefit of potential CLDs

Think of it this way guys.

An architecture astronought has designed the system (no matter how crap it is) and supplied a spec for a contractor code-monkey to code against. It's not the code-monkeys remit to re-design the system and re-write the spec (that's what the astronought is paid for) - just code to spec. If you (not you specifically, but generally) cannot code to spec, then your not much use within a team of coders lead by an astronought (you could be considered argumentative). That's the first rung you have to master before you can climb to where the oxygen is thinner. That is where the CLD sits - can you follow instruction and documentation. It may not be glamorous, or exercise your artistic/thought provocative nature, but it can be hard and daunting for many-even in classical LabVIEW. When it comes to OOP, it's harder by 10-fold if you aren't of that mind-set and those that are, maybe unsure of how to achieve it in LabVIEW. Whether it is close to real or not is irrelevent. It's to help those at that level by giving examples (in LVOOP) that they can analyse and compare.

I'm just suggesting (with all the super-guru LVOOP talent in Lava) that perhaps if examples of the CLD practise exams where demonstrated with LVPOOP, then maybe a lot more people would grok and maybe ken the advantages/disadvantages and methods. Maybe on your efforts you might see all submissions in the future in LVOOP rather than classical. But if the thread goes in the direction of "it's too simple and uninteresting for LVOOP" or "it's not a real project therfore LVOOP isn't applicable" then those are just weasel words and LVOOP has already failed.

James.

The CLA exams don't target code (you can use the same UML for both right?) and I'm not sure what you could take away from it. But sure, if you have an example, post it.

Just curious... are you looking for a sample CLD solution, or a sample real-world application based on the requirements of a sample exam? They have different requirements and will result in different source code. (For me anyway.)

I'm thinking of sample CLD solutions. (i.e to the spec in the example exams). The point is to show that identical results can be achieved with both methodologies using the exisiting classical solution as a reference to understanding the LVOOP.

However. I don't descriminate between the two. The CLD exam IS a real world application (it has a spec and a deliverable).

For instance, menu buttons are not being released.

You have a race condition.

Try this.

Lava is obviously a great place to pick the brains of the Labview community elite. It is also more LVOOP centric than other labview sites and has some awsome LVOOP talent. However. Most of the LVOOP concepts discussed are very advanced for the average LabVIEW programmer and centered around a few personal projects with no real focus on deliverable code, rather frameworks and eosoteric concepts.

Quite often we see potential CLDs posting their code, for comment, as a prelude to taking the exams. All of these are written in classical LabVIEW. If the LVOOP community is adamant that LVOOP is the future, then maybe some of the LVOOP gurus could post unofficial, demonstrative LVOOP implementations of the example exams (ATM, traffic lights etc). This would then give a focus on using LVOOP to achieve specific end goals, with well defined specifications and exisiting solutions for comparison - it would allow those using classical LabVIEW techniques to comparitively understand LVOOP in context with the classical solutions.

Is anyone up to the challenge? To provide (unofficial, demonstration) LVOOP solutions of CLD example exams for the benefit of potential CLDs? We see many different approaches in classical LabVIEW to solving the examples. Would we see a similar plethora of innovative LVOOP solutions? Perhaps it could even be a collaborative effort to produce them and maybe , once refined they could be proffered to NI as a candidate for an official NI solution along side the classical one!

So you want a singleton?

I think most of our confusion (well, mine at least) arises from the fact you are trying to cast at all. I thought you were questioning why you get the parent after the cast rather than a child of the type you select.

What is wrong with

That's not exactly true in this case, yes there is a coercion dot but what you now have in run time polymorphism whereby the 'wire' is an array of Parent by the data in that array is still a mixture of Child classes.

I don't see the need for the upcast (does it generate an error when it runs?) as you can wire the output straight into the Parent methods and the Child classes and any DD methods of the children will run.

If you wanted to use any specific (static) child methods then yes, you would have to convert the Parent 'wire' to the Child.

You should check out the Factory Pattern.

Indeed. That is why the To More Specific "casts" it to the parent type (because that is what the type is on the wire, coerced by the array concatenation). The only way you can "extract" the contained class (as you point out) is via the invisible selection methods in the LVOOP system (the equivelent in my analogy of "extracting" the bits).

Hopefully the image explains my question pretty well. Can anyone tell me why this doesn't work?

Arrays have to be of a single type. The child classes get coerced to the parent since that is the only type for which they are all compatable to exist as a single type within the array (and why you have coercion dots).

If you think about adding a Uint32 to a DBL array, the Uint gets coerced to a DBL right? So do your classes.

It could be for the mouse wheel

WControl

Does the mouse wheel stop working if you disable it?

Oh. And as an after-thought (an after I can edit, thought ). The reason for posting wasn't to provide a "faster" version of the NI one (thats more by accident since I didn't benchmark it). Just a version that you could see the diagram - Jims request, Feel free to change the calls to UI if it makes you happier because with this offering you can