OpenCL for Labview is now Open Source

Howdy,
I wrote OpenCLV (OpenCL for Labview) about a year ago and have decided to make it an Opensource project availible on GitHub. It contains all my C code to compile DLLs, all the Labview code, some pre-compiled x64 DLL code and a pre-built .vip project if you just want to download and install it.
https://github.com/amcelroy/OpenCLV.git
My email is in the GPL license header in the C code if you find any bugs or have any comments.
Austin

tst wrote:
While I don't have use for something like this myself, the willingness to share open source code is appreciated.
One problem I would have with this, though, is the license. I'm far from an expert on licensing, but my understanding is that the GPL license is infectious - if you use a component which uses it directly in your code, you have to make your own code GPL as well to adhere with the license and the only way around that is to separate the GPL component into a separate, dynamically linked, component which would allow the end user to replace it if they want. See their FAQ here - http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem
My understanding is that this is the reason that OpenG switched from GPL to BSD some years ago - BSD is more permissive and basically just requires you to place the copyright notice somewhere where the user can see it.
The strict interpretation of GPL prohibits integrating a GPL component into a non GPL software even dynamically. That is why there is a LGPL. And that was indeed why OpenG changed from LGPL (not GPL!) to BSD several years ago. Many of the most influencing OpenG supporters felt that it was rather cumbersome to use it in non (L)GPL software. The most prominent product of this nowadays is VIPM.
The only exception to that change are the shared library components of the libraries that I wrote. I didn't feel that there was any bad influence from integrating them as LGPL into any sort of LabVIEW application, as they are fully dynamic anyways and by the nature of LGPL have no viral effect on the application that uses them.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Similar Messages

Scene Builder is now Open Source

We're very happy to announce that Scene Builder is now open source, as a part of the OpenJFX project.
The whole Scene Builder functionality is provided, including the SB Kit API (designed for integration of SB features into third party tools) as well as the standalone SB application.
This code is made available under the terms of a BSD-style license, similar to JavaFX samples.
The only part of the product which remains closed is the native packaging/installer code.
Scene Builder source code is located in apps/scenebuilder/ in the OpenJFX repository.
Building and running the Scene Builder application from these sources can be done either of the following ways:
From NetBeans: open the SceneBuilderApp project and run it (you need a JDK 1.8 Java Platform configured)
From the command line:
$ cd SceneBuilderApp
$ ant -Dplatforms.JDK_1.8.home=<path_to_JDK_home> run
As usual your contribution and feedback are welcome.
The Scene Builder team.

Thank you for the nice feedback!
Beyond providing SB itself, we indeed hope very much that the code will more largely be useful to the community, as a big JavaFX sample application.
SceneBuilderKit contains the API allowing to integrate SB functionality into the GUI of a third party tool, such as an IDE.
As you probably know, with the 2.0 release, SB code base has been deeply re-factored to make it modular such that each of the Panels (Content, Inspector, Hierarchy, etc...) can be instantiated and brought up independently of the others. So, in a nutshell, the SB Kit API allows to orchestrate the editing of an FXML document and to control the various panels.
SceneBuilderApp contains the code of the SB standalone application. It is itself built on top of SceneBuilderKit, and will provide the all-in-one document window you are now familiar with, as well as top level menu bar, preview in a separate window, preference dialog (not quite there), about dialog, etc…

ActionScript 3 compiler, asc, is now open-source

In the latest nightly build of the Flex SDK is the as3
compiler code!
The ActionScript 3 compiler, asc, is now open-source! Added
the source code for Flex 3's asc.jar, at
branches/3.0.x/modules/asc. This code came from
ssh://asteam.macromedia.com/hg/asc-flex3 and is what built the
asc.jar that shipped with SDK 3.0.0.477, plus open-source copyright
changes. It requires Java 1.5 to build and is not integrated with
the build scripts for branched/3.0.x; this branch continues to have
a prebuilt asc.jar in 'lib'.

PHPAMF is not an Adobe product and for this you did not find anything here.
Amfphp can properly serialize and deserialize complex types. In addition to objects and arrays, it supports resources from database connections, which means you can simply return mysql_query from your remote method and amfphp will know what to do with it. If the platform supports it (currently, Flash Remoting only), it can handle circular references and typed objects. It also supports simple remote debugging. Finally, amfphp comes with a service browser which allows you to test your services before creating a frontend.
Regards, Giuseppe

Symbian now open sourced, n97 with symbian^2?

Symbian is now open sourced !!!
so now you can head over to www.symbian.org and download the source code for free and modify it in anyway, ofcourse you have to stick to the policies
But im just wondering, could the N97 get a symbian^2 update? cos its just more open sourced and there arn't that much changes to it then symbian^1?
btw apologies to the v21.0.045 disappearing thread, apparently my NSU had a problem with it's log file which i didn't think would ever happen :L
n97.

symbian will skip symbian^2 and will head to symbian^3 in q3 of 2010
-you can show appreciation to my posts if it helped or useful by pressing the green Kudo star beside my post that hepled
-if my answer was the solution , so click accept as solution button
Started From Nokia 3310 , Now with Nokia N97 v.22.0.110 + N900 PR1.2

Good site for Video Editing tools (open source)

I'm a recent convert to Mac, and I'm having a hard time finding comparable tools to what is available via open source on the Windows side. Specifially in the H.264 arena. There are a multitude of open source encoding tools for Windows. I'm sure there have to be some for Mac. Are there any good sites that list these? I'm tried versiontracker and The Mac Orchard, but I'm hoping for something more specific like VideoHelp.com
Any suggestions? I'm looking for encoding software that can do inverse telecine, import DivX/Xvid/DV, Trim video (to remove letterboxing), and encode to H.264.
Thanks!

Can't help with the video stuff, but since you're a newcomer to the Mac, see these:
Switching from Windows to Mac OS X,
Basic Tutorials on using a Mac,
MacFixIt Tutorials,
MacTips, and
Switching to the Mac: The Missing Manual, Leopard Edition.
And a link to open source software: http://sourceforge.net/ Search for *multimedia for Mac*.
Additionally, *Texas Mac Man* recommends:
Quick Assist.
Welcome to the Switch To A Mac Guides, and
A guide for switching to a Mac.

XGL is now OPEN-SOURCE!!!

David Reveman the dude from Novell just made the announcment.
http://lists.freedesktop.org/archives/x … 11922.html
Hey everyone,
my latest Xgl code is now available in a tarboll from here:
http://www.freedesktop.org/~davidr/
I'd like to get this code into freedesktop CVS asap. I suggest that we
put it in a xgl module for now as I'm guessing that it'll take some time
before everything can be merged into Xorg and I don't want to spend any
time merging the code back into the kdrive tree.
I can't wait to get my dirty hands on xcompmgr using opengl even with the ati drivers! 8)

Cam wrote:
Neuro wrote:I am looking forward to KDE4, as it promises to use all these fancy features for real things.
Do the KDE team have any examples of these "real things" or is it just a case of believing everything you read?
Well, what do you expect? KDE4 won't be released until propably late 2006/early 2007, so they obiously don't work on the effects yet. You can't expect them to show you the effects in action so what's wrong in reading about them?
What I am really looking forward to is:
- having real transparency in Konsole (not some pixmap workaround which is slow and uses a lot of memory) and other places like kicker etc
- having these nice 'notifications' the Appeal project is talking about
- making use of these 3d effects for things like slide-opening sidebars and such, which would really enhance the UI usability

DTrace is now open source

I'm proud to announce that, as of 1pm today, DTrace is open source. For the source code itself, go here:
http://opensolaris.org
I've put together some commentary here:
http://blogs.sun.com/roller/page/bmc/20050125#solaris_10_revealed
Enjoy,
Bryan
Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc

Question
Does this mean that we can port or fork DTrace?Yes, provided you abide by the terms of the CDDL. See http://opensolaris.org/faq/licensing_faq.html for answers to common questions about CDDL.
For example can I try to port DTrace to Linux?You would be in violation of the GPL. From http://www.gnu.org/philosophy/license-list.html:
"...a module covered by the GPL and a module covered by the CDDL cannot legally be linked together. "
Linux has some very murky policies regarded "tainted" kernels, however, so you should probably ask this question to a Linux authority. Point is: it's a GPL issue, not a CDDL issue.
- Bryan
Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc

Why is it good for java to be open source?

if java becomes open source, will people take java, put viruses into it and send it to people?
i have use red unix and it is not as good as windows, though it does have its uses for calulcations, but why would we want java to go down this road?

Stop trolling, "garish_shaboo".
~

A fundraiser for 0 A.D. (open-source strategy game)

Hi all!
Wildfire Games just launched a fundraiser for 0 A.D., a quite nice open source strategy game. For those that don't know it yet, I suggest to give it a try: it's in [community].
More info about the game on the official website: http://play0ad.com/
To contribute to the crowdfunding, go here: http://www.indiegogo.com/projects/suppo … ategy-game. IndieGoGo actually lets them keep the money even if the goal is not reached, so money sent their way won't be wasted even in case they don't get to 160.000$ (which was a bit of an overshoot, if you ask me...).
I just contributed (small amount, but that's what I can afford these days), so I thought I'd post here for those that didn't know about the fundraiser (or the game!).
Ciao!
Last edited by palmaway (2013-09-17 00:33:41)

As Software in the Public Interest is a Non-Profit, this falls just outside our solicitation guide: https://wiki.archlinux.org/index.php/Fo … licitation

Open sourcing the skype for linux UI AGAIN

i remember from some time ago i read something about the skype for linxu UI being open sourced to make supporting linux distro easier. but then microsoft bought skype. and now there is a closed source UI. please open source the UI so the comunity can fix the broken UI in skype for linux to a proper qt interface. the current qt web interface is annoying

It should look the same as all the other apps. Which is what most Linux users expect. Qt does offer on-the-fly theming, so if someone feels adventurous they can change it; and indeed the lack of 64 bit often results in some missing themes and Skype running in not exactly the same theme as the rest of the desktop. But otherwise, we shouldn't make Skype4Linux stick out like a sore thumb.

Is Solaris open source?

I have read many articles that said Solaris is now open source; however, it is impossible to find a link to download the code. In some forums it sounds like people have the source code. Can someone please tell me where or how I can get the source code?
Thanks for your help

if there is a market demand, corporations would respond accordingly in ideal. this is evidently not true, as can be seen in licensing costs for MS . However, there isnt that demand per se for clients of SUN asking for the source.
however, on hindsight, would the source code liberate or empower you where solaris 8 is concerned? I suspect that it would be liberating to capitalise on shell programming, and modify the shell to your needs.

�Is Sun System Instant Messaging a Multiplatform Open Source Application?

This Because I am searching a highly Compatible Open Source WEB Enable Client/Server Application or a robust Multiplaform Instant Messaging System for Academic Purposes.
I searching to obtain a WEB Enable Instant Messaging Application Open Source in Java like MSN Messenger Client/Server for Academic Purposes?
I find Jabber as an alternative Instant Messaging solution but the clients and servers Applications there aren't highly compatibles.
I thank in advance for their valuable time. And for the attention and the collaboration lent me.

I believe there are currently two open source J2EE 1.3 compliant appservers:
JOnAs http://jonas.objectweb.org/
JBoss http://www.jboss.org/
Both have beta versions of their J2EE 1.4 offers. If what you are looking for is not actually open source but simply free as in beer, then Sun's appserver is a rather attractive option. It's already J2EE 1.4 certified because it is the J2EE 1.4 reference implementation. You can download it as part of the J2EE SDK from here http://java.sun.com/j2ee/1.4/download-sdk.html

Adobe Open Source features in CS5

Adobe announces the issue of CS5, so what innovations in Open Source Technics will be included there? I asked Google for software consulting services http://www.google.com/search?hl=en&client=firefox-a&tbo=p&rls=org.mozilla%3Aen-US%3Aoffici al&tbs=blg%3A1&q=Adobe+Open+Source+Website+CS5&aq=f&aqi=&aql=&oq=&gs_rfai= as the result I found that Web Premium CS5 also features support for the most popular open source content management. But what's about more advanced features? Who knows?

Yes we use Suitcase Fusion.
Prior to updaing to CS5 we had an older version of suitcase fusion 12.xxxx
When we upgraded to CS5 we also upgraded to the current version of Suitcase Fusion 3 & updated it.
No specific plugins come to mind.
Tony.

Open Source releasing best practices?

Hello,
When creating open source software, I don't really know what the best way to release it (what kind of makefile, versioning system, etc...) is. It's also hard to find this info online, is there any good online info or book about this?
Here are some of my questions...
-How many operating systems should your makefile support? Should I make special cases for every single Linux distro and other OS in the makefile, or can I just put a generic "g++ *.cpp" in the makefile, and let each OS and distro's own package managers take care of tailoring it to their OS?
-For makefile complexity, I guess there is a scale ranging from a hack like just typing "g++ *.cpp" in it, through having nice sections, groups of files and definitions like "CFLAGS", all the way up to projects which have 20 different makefiles in them like "Makefile.in", "Makefile.pandora", etc.... Where on that scale should you ideally be?
-Makefiles of many projects look incredibly complex, why?
-What versioning system to use? When to make a 1.0.0? When to append "rc" at the end?
-When to tag stable versions? And when you change something in head, do you need to change version number every single time?
-When creating a dynamic library, and you tagged a stable version, and you then change something in head. Should in the makefile the version number of the library name be changed to something? If so, should it be changed to a next minor version, or to something with "-rc" at the end?
-What names should be used for tags of versions?
-Does there need to be both a zipped version of the source code and one under VCS, and if so why is that zipped version needed?
-Are there any naming conventions for output binaries and libraries?
-Are you supposed to let your makefile clean up .o files after compilation or not?
-Are there any conventions for makefiles for names of sections and variables in it? E.g. is it a good idea to have a "clean:" in your makefile to remove everything?
-When depending on another library which is hosted somewhere else, how to handle that? What when statically depending on it?
-Any other things I should know?
Thanks!
Last edited by aardwolf (2013-05-07 12:32:57)

aardwolf wrote:Hello,
Many of your questions have no single correct response. I'll reply with my own opinions and experiences, based on my release of two open source projects (GPT fdisk and rEFInd).
-How many operating systems should your makefile support? Should I make special cases for every single Linux distro and other OS in the makefile, or can I just put a generic "g++ *.cpp" in the makefile, and let each OS and distro's own package managers take care of tailoring it to their OS?
Ideally, a Makefile should build a package under every OS on the planet. In practice, this isn't always practical. Many developers use programs like Autotools to create Makefiles that are suited to a particular build environment. Other developers (myself included) create a handful of Makefiles for different environments -- for instance, my GPT fdisk has Makefiles for Linux, FreeBSD, OS X, and Windows. My rEFInd officially supports building only under Linux, although it supports two EFI toolkits (GNU-EFI and TianoCore EDK II) via a cascading set of Makefiles. Any of these Makefiles can require changes depending on the distribution and development environment in use, but that's not really my concern.
If a distribution requires changes, that type of change is generally best left to a build system like Autotools or to the person who builds or packages the program. IMHO, it's unreasonable to ask a developer to make minor tweaks to a static Makefile to support every minor Linux variant on the planet.
-For makefile complexity, I guess there is a scale ranging from a hack like just typing "g++ *.cpp" in it, through having nice sections, groups of files and definitions like "CFLAGS", all the way up to projects which have 20 different makefiles in them like "Makefile.in", "Makefile.pandora", etc.... Where on that scale should you ideally be?
This is very much a matter of personal preference and project complexity. Autotools or something similar will make it easy for users and distribution maintainers, but can be tricky to use for the developer. If your program is a simple single-file C program, you might forego a Makefile completely; but for something on the scale of the Linux kernel, a Makefile (or something equivalent) is absolutely required.
-Makefiles of many projects look incredibly complex, why?
Some projects are very complex, as in the Linux kernel itself. Other times, the Makefiles generated by automated systems like Autotools can be more complex than they might be if they were hand-crafted. In still other cases the developers like complexity or are barely competent at creating Makefiles and so create something that's more complex than it needs to be.
-What versioning system to use? When to make a 1.0.0? When to append "rc" at the end?
AFAIK, there are no standards on this. A 1.0 release denotes that something has moved beyond "beta test" status -- in other words, you think it's stable and usable for the masses. Open source software authors tend to be conservative in making that judgment, so pre-1.0 releases in the open source world are often as good as post-1.0 releases of commercial software. The bottom line, though, is that it is a judgment call -- what I consider "1.0" software you might consider well beyond that point and something else might consider pre-beta.
As to release candidate (RC), not all projects use that designation at all. It seems to me to be more common among large projects as they approach major release milestones, to denote something that is close to being finalized, but not quite -- essentially a sort of very late beta stage, even if the initial 1.0 release was made some time before.
-When to tag stable versions? And when you change something in head, do you need to change version number every single time?
If the code changes, you should definitely change the version number. Most developers accumulate several changes before making a new official release, though. Personally, I make full releases with three-digit numbers (like 0.8.6 or 0.6.10), and I upload minor changes to my project's git repository with four-digit numbers (like 0.8.6.1 or 0.6.10.2), but don't do full releases with tarballs and RPMs and whatnot for these, except in a limited way if I want specific people to test a recent change because they filed a bug report. Others have other systems.
-When creating a dynamic library, and you tagged a stable version, and you then change something in head. Should in the makefile the version number of the library name be changed to something? If so, should it be changed to a next minor version, or to something with "-rc" at the end?
The key difference with dynamic libraries is that the interfaces should not change with minor changes. IIRC, the second digit (like "2" in 1.2.3) is the cutoff point. In other words, a program that uses library version 1.2.3 should continue to work without changes or recompilation with library 1.2.4 or 1.2.2 (assuming no bugs). This enables users to upgrade the library (from 1.2.3 to 1.2.4 or the like) without upgrading every binary that relies on it. With version 1.3.0, though, the interface to the library might change in a way that would require recompilation of the program or even changes to the source code. Thus, changing the library from 1.2.4 to 1.3.0 will require the user to upgrade all the programs that use that dynamic library (or keep the old version around along with the new one). Note that I've never created a publicly-released library, and it's been a while since I've read up on this, so I might be a little off on these details.
-What names should be used for tags of versions?
I'm not sure what you mean by this.
-Does there need to be both a zipped version of the source code and one under VCS, and if so why is that zipped version needed?
You can do it any way you want; but as a general rule, you should provide source code in a tarball or .zip file because that's easier to download. Some package systems, such as RPM, require that a source package filename be specified, and so not providing source in such a package just complicates matters for packagers and therefore makes it less likely that they'll bother packaging your program at all. This in turn makes it harder for your users to use the program.
Note that most Linux programs' source code is provided as tarballs rather than as .zip files. Some cross-platform programs can be exceptions to this rule. For instance, I used .zip for rEFInd (a boot loader) because .zip is a little more common in Windows -- although I'm sure either would have worked fine, in practice.
You should probably provide binary builds of your software -- although in some cases this can be tricky because a binary built for Distribution A may not work on Distribution B because of library differences. The OpenSUSE Build Service (OBS) can help with this, although it's a bit of a pain to use.
-Are there any naming conventions for output binaries and libraries?
Not AFAIK, except of course for filename extensions like .so and .a.
-Are you supposed to let your makefile clean up .o files after compilation or not?
No, except for the "clean" target and anything else that's supposed to do this.
-Are there any conventions for makefiles for names of sections and variables in it? E.g. is it a good idea to have a "clean:" in your makefile to remove everything?
The "all" target builds everything, "clean" cleans up, "install" installs everything, and "uninstall" uninstalls everything. There's no law that says you have to have all of these, but they're common, particularly with big projects.
-When depending on another library which is hosted somewhere else, how to handle that? What when statically depending on it?
This type of thing is generally handled by packaging programs (pacman, rpm, dpkg, etc.), not by developers' Makefiles. That said, Makefile builders like Autotools should check for the relevant development libraries and stop if they aren't present. That will handle the static linking issue, as well as other problems. On another level, when using RPM, a source RPM will include dependencies on the relevant development libraries, and Debian source files have a similar feature. Putting these files together is the responsibility of distribution maintainers, not of program authors.
-Any other things I should know?
There's a huge range of acceptable practices on these issues. As a general rule, though, the smaller the package the more likely you are to find a simple Makefile that builds the whole project. Bigger projects are more likely to rely on multiple Makefiles, Autotools, or other complex pre-build software. More standardization emerges at the distribution level, in the form of source and binary RPMs, Debian packages, etc. You shouldn't need to worry too much about that. So long as your package builds with few or no changes on a variety of distributions, the distribution packagers can handle the rest. Build systems always support patches so that minor changes to Makefiles or whatnot can be incorporated. This frees you up to worry about other things rather than trying to support every minor variant distribution in existence.

DBAShell - New Open Source Project for Oracle DBA's

I'd like to have this project included in the Open Source Oracle tools list at: http://www.oracle.com/technology/community/opensource_projects.html
I've been an Oracle DBA for quite some time (since 7.0.13) and a developer for many years. One of the things I've always wished for was an easier way to set up environment variables for different Oracle Homes and a way to provide passwords to scripts without embedding them in plain-view.
About 3 years ago, I started a set of functions and scripts at my company that did exactly just that and provided many more functions for things like checking database status, running scripts quietly unless errors are detected, running actions in parallel (like fast shutdowns at once, or multiple analyzes), restarting databases in a guaranteed fashion, aliases to common folder locations, etc..
About a month ago, after putting all this time and effort into these scripts and using them in production all this time, I realized I wanted more out of the scripts like support for other databases and thought that it would be best if I gave it new life as an Open Source project.
So that is how http://sourceforge.net/projects/dbashell/ was started. Now its in a second release (DBAShell 0.85) that is more modular and would allow other people to easily add support for other OSs, other Shells, and other Databases.
Here is a description of the project from the latest news item:
DBAShell is a project based around Shell functions and scripts designed to make it easy for DBA's to use Databases in a command line environment. Currently supported is Oracle with ksh and bash on AIX, Solaris, Linux. The code base itself is 3 years old and has been in use in Production environments all of that time.
Features include:
* Automatic setting of all environment variables based on SID requested.
* Manage PATH's and other path like variables for each ORACLE_HOME needed.
* Run scripts with stored passwords (no more hard-coding of passwords!!)
* Automatically set SID based on Script location (makes it easier to share scripts between SID's)
* manage temporary script output and check for oracle errors in output
* check database status and versions from scripts
* stop/start databases in parallel (faster startup)
* compile all database objects
* analyze objects in parallel (Faster analyzes)
* set aliases and variables for common SID areas, etc..
* many helpful commands for common Oracle tasks
Over a thousand people have already downloaded the prior release and more are downloading every hour.
I'm seeking feedback from anybody that would be willing to take a look at the project, trying it out, give me any feedback you have on it, and perhaps even direct me to where I could best promote this project.
I wrote a tutorial that shows at a glance some of the more useful features of DBAShell:
http://sourceforge.net/docman/display_doc.php?docid=34041&group_id=170224
Main site:
http://sourceforge.net/projects/dbashell/
Documentation: http://sourceforge.net/docman/display_doc.php?docid=33704&group_id=170224
Download:
http://prdownloads.sourceforge.net/dbashell/dbashell-0.85.tar.gz?download

Always glad to have people thinking about the poor DBA's. Usually, the developers get most of the attention in open source.

OpenCL for Labview is now Open Source

Similar Messages

Maybe you are looking for