Jump to content

GOOP/OpenGOOP


Recommended Posts

I finally managed to install OpenGOOP, manually into LV 6... (Some VI was missing, which I found in the OGLIB_String package.)

I know GOOP 1.0 only was a bunch of shift registers, build arrays and such, and was quite slow, but is OpenGOOP faster?

And how is it compaired to GOOP 2.0?

BTW, how is it with OpenGOOP and named objects. I have used that with GOOP, so how do I do that in OpenGOOP?

Another thing I wonder about is: Why is the Default Data Cluster embedded in a VI?

Wouldn't a Default Data Type Definition.ctl do the same job.

The Default Data.vi seems quite obsolete. Why store almost nothing (as in this case) into a VI?

Shouldn't <Class> Data Core Task Enum.ctl be on the front panel of both <Class> Data Core.vi and <Class> Object Data Core.vi? There was no connection to the type def. on FP of one of those VIs, I don't remember which.

Link to comment
I finally managed to install OpenGOOP, manually into LV 6... (Some VI was missing, which I found in the OGLIB_String package.)

I know GOOP 1.0 only was a bunch of shift registers, build arrays and such, and was quite slow, but is OpenGOOP faster?

And how is it compaired to GOOP 2.0?

BTW, how is it with OpenGOOP and named objects.  I have used that with GOOP, so how do I do that in OpenGOOP?

4753[/snapback]

The attached spread sheet has some performance data on OpenGOOP, niGOOP (GOOP) and dqGOOP. I created dqGOOP for performance, but unfortunately it requires LabVIEW 7.0 or later (it sounds like you're using 6...). Mark Balla started a discussion on dqGOOP here:

http://forums.lavausergroup.org/index.php?...=1392#entry4739

The first post has a zip file GOOPTest.zip that has three test classes (LV 7.0) and a performance test VI for each (in the Testing folder). [Two weeks of discussion on dqGOOP was recently lost due to an attack on the LAVA discussion forums]

OpenGOOP doesn't support named objects, but since it is open you could add that functionality. dqGOOP uses LabVIEW native queues so it supports named objects, with the added advantage that unique references are created when you obtain a reference by name.

I have not been able to test GOOP 2.0 performance or the new GOOP developer posted by Kurt Friday at:

http://forums.lavausergroup.org/index.php?...=1355#entry4509

Brian

Link to comment
I couldn't edit my first post, so I add yet another question here:

I looked at the diagram of <Class> Open Object Reference.vi.

I'm no expert, so why is Flatten to String and then Flatten from String used in the diagram?

Wouldn't a Type Cast do the same job ???????

4761[/snapback]

Yes. in dqgoop it is done this way.

Also "OpenGOOP Data Core.vi" does the opposite conversion.

If you want you can make changes in the "_OpenGOOP_classtpt" folder.

The wizard uses these vis to create classes.

Link to comment
Yes. in dqgoop it is done this way.

Also "OpenGOOP Data Core.vi" does the opposite conversion.

If you want you can make changes in the "_OpenGOOP_classtpt" folder.

The wizard uses these vis to create classes.

4768[/snapback]

Yes dqGOOP uses the type cast, but LabVIEW doesn't allow a (reentrant?) VI refnum to be the input type to the type cast function. I remember reading that the flatten => unflatten was the "trick" needed to enable converting the Object refnun to the VI data store refnum.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.