LabVIEW
Slow TCP duplex handling on remote connections
Then I have probably used some of your LVPython code and zlib! 
The LV Pipe library, is that about named pipes? I was thinking of using some fast IPC mechanism for the sbrio project.
So nowadays you contribute nothing?
Roger
RogerI wrote:Then I have probably used some of your LVPython code and zlib!
The LV Pipe library, is that about named pipes? I was thinking of using some fast IPC mechanism for the sbrio project.
So nowadays you contribute nothing?
Roger
The LabVIEW pipe library is both about named and unnamed pipes. However it is mainly targeted at Windows computers since LabVIEW comes with a similar library for Unix platforms. I do actually doubt that VxWorks or the ETS RT OS used in the LabVIEW realtime targets do support pipes at all, so it is not likely going to be portable to those platforms. But I can't be sure and I can't afford the VxWorks development license just to check that.
As to your other questions: I'm still fairly active on various LabVIEW forums. I also actively maintain the ZIP library and many of our companies projects and follow the zlib development mailing list and have recently just submitted a patch or two to the ZIP library in there for the new upcoming release of that.
As for Wine it has reached a majority that makes getting fixes in very hard. I simply can't spend as much time anymore on computers, since family does have some requirements too, and i have to do paying work too for the company.
But at least in the LabVIEW world I doubt there are many people who have provided as much Open Source code as me and I feel it is time that other newcomers get a chance to pick up the baton after almost 20 years of active participation in the LabVIEW world 
@rolfk wrote:
RogerI wrote:
Then I have probably used some of your LVPython code and zlib!
The LV Pipe library, is that about named pipes? I was thinking of using some fast IPC mechanism for the sbrio project.
So nowadays you contribute nothing?
Roger
The LabVIEW pipe library is both about named and unnamed pipes. However it is mainly targeted at Windows computers since LabVIEW comes with a similar library for Unix platforms. I do actually doubt that VxWorks or the ETS RT OS used in the LabVIEW realtime targets do support pipes at all, so it is not likely going to be portable to those platforms. But I can't be sure and I can't afford the VxWorks development license just to check that.
As to your other questions: I'm still fairly active on various LabVIEW forums. I also actively maintain the ZIP library and many of our companies projects and follow the zlib development mailing list and have recently just submitted a patch or two to the ZIP library in there for the new upcoming release of that.
As for Wine it has reached a majority that makes getting fixes in very hard. I simply can't spend as much time anymore on computers, since family does have some requirements too, and i have to do paying work too for the company.
But at least in the LabVIEW world I doubt there are many people who have provided as much Open Source code as me and I feel it is time that other newcomers get a chance to pick up the baton after almost 20 years of active participation in the LabVIEW world
Long time no see this thread. 😉
Well, I've picked up the baton with some community example code and a GPL/LGPL (mostly LVOOP) library that I call "labqt" (in the spirit of Diga's Qt C++ middleware frameworks).
http://decibel.ni.com/content/people/RogerIsaksson?view=documents
http://gitorious.org/labqt/labqt
http://gitorious.org/riopilot/riopilot/
Br,
/Roger
