VFLib vs BEAST


#1

vinnie, do you still maintain VFLib, or should we move to beast ?


#2

I would be very interested to know the answer as well. As it seems, we can not simply replace VFLib with Beast. Last time i checked not all the classes where included. I'm diving, head first, deep into this library. I would really appreciate if Mr. Vinnie Falco, the author could share a little bit of his plans please?


#3

VFLib and Beast are two completely different things. VFLib is oriented towards a JUCE application, with a GUI. Beast is designed for server applications and peer to peer software.

 

I'm using Beast in Ripple (see my signature). Beast has a dependency on Boost, for the SSL support and the multi-protocol socket handshaking. And also, the HTTP Client. We dont want VFLib to have a dependency on Boost. They are two different libraries. In a few years when I revisit JUCE I will probably merge parts of the two libraries but for now they are completely separate and should be considered individually.

 

Do note that VFLib is GPL, while Beast is ISC Licensed.

 


#4

thanks for your answer.

>> Do note that VFLib is GPL

? it is said as MIT here : https://github.com/vinniefalco/VFLib  !

 

At the moment VFLib won't compile & work with the latest juce from git. What you would recommend to VFLib users ? How do you plan to maintain VFLib ?

On the other thread about VFLib missing decReferenceCountWithoutDeleting you advise me to look at SharedPtr, SharedObject, and SharedSingleton. But those are part of Beast no?

that's why I'm a bit confused..


#5

Thank you very much for answering. This is good to know and actually i'm very comfortable this way. I'm growing to like VFLib quite a lot!

I guess you mean VFLib is GPL when used with GPL-licenced JUCE, but MIT licenced when used with commercial JUCE license?

Maybe you want to mention in the documentation that VFLib requires VS 2010 or later, because of stdint.h and std:ref and other bind stuff not available prior to VS 2010,  whereas JUCE builds on earlier versions of VS.


#6

What I am saying is that Beast has diverged from VFLib. I dont have any active projects that use VFLib so I am not really maintaining it.


#7

Forget it...


#8

Is anyone else using VFLib? Are you stuck with version 2.1.1 of Juce like i'm, because the decReferenceCountWithoutDeleting broke VFLib? or have you managed to hack VFLib to build with the current Juce?


#9

I'm not using VFLib any more, but I did do a heinous hack to get it to compile so I could just use the FreeType stuff:

modules\vf_core\events\vf_OncePerSecond.cpp


old    new    
...    ...    @@ -33,7 +33,7 @@
33    33     class OncePerSecond::TimerSingleton
34    34       : public RefCountedSingleton <OncePerSecond::TimerSingleton>
35    35     {
36        -private:
    36    +public:
37    37       TimerSingleton ()
38    38         : RefCountedSingleton <OncePerSecond::TimerSingleton> (
39    39             SingletonLifetime::persistAfterCreation)
...    ...    @@ -49,6 +49,7 @@ private:
49    49         jassert (m_list.empty ());
50    50       }
51    51     
    52    +private:
52    53       void run ()
53    54       {
54    55         for(;;)

modules\vf_core\memory\vf_RefCountedSingleton.h


old    new    
...    ...    @@ -150,6 +150,11 @@ public:
150    150           destroySingleton ();
151    151       }
152    152     
    153    +  inline bool decReferenceCountWithoutDeleting() noexcept
    154    +  {
    155    +    return m_refs.release ();
    156    +  }
    157    +
153    158       // Caller must synchronize.
154    159       inline bool isBeingReferenced () const
155    160       {

There was also a fix for modules\vf_gui\mouse\vf_MouseEnterGroup.h

‚Äč
old    new    
...    ...    @@ -150,7 +150,7 @@ private:
150    150           mouseWasDragged = !e.mouseWasClicked ();
151    151         }
152    152     
153        -    MouseInputSource* source;
    153    +    const MouseInputSource* source;
154    154         Point <int>       position;
155    155         ModifierKeys      modifiers;
156    156         Component*        eventComponent;


#10

I had to also expose private destructors in two classes:


modules/vf_concurrent/memory/vf_GlobalFifoFreeStore.h

diff --git a/VFLib/modules/vf_concurrent/memory/vf_GlobalFifoFreeStore.h b/VFLib/modules/vf_concurrent/memory/vf_GlobalFifoFreeStore.h
index 1bb9bbc..3528180 100644
--- a/VFLib/modules/vf_concurrent/memory/vf_GlobalFifoFreeStore.h
+++ b/VFLib/modules/vf_concurrent/memory/vf_GlobalFifoFreeStore.h
@@ -67,6 +67,7 @@ private:
   {
   }
 
+public:
   ~GlobalFifoFreeStore ()
   {
   }

modules/vf_concurrent/memory/vf_GlobalPagedFreeStore.h

diff --git a/VFLib/modules/vf_concurrent/memory/vf_GlobalPagedFreeStore.h b/VFLib/modules/vf_concurrent/memory/vf_GlobalPagedFreeStore.h
index 45adf22..1ae6049 100644
--- a/VFLib/modules/vf_concurrent/memory/vf_GlobalPagedFreeStore.h
+++ b/VFLib/modules/vf_concurrent/memory/vf_GlobalPagedFreeStore.h
@@ -47,9 +47,9 @@ class GlobalPagedFreeStore
 {
 private:
   GlobalPagedFreeStore ();
-  ~GlobalPagedFreeStore ();
 
 public:
+  ~GlobalPagedFreeStore ();
   inline size_t getPageBytes ()
   {
     return m_allocator.getPageBytes ();

At least it compiles now with Juce 3.0.0. Thank's a lot! [Edit: It compiles but at least the CallQueues are broken. Assertions go off when the memory management singletons under the hood are destroyed.]

I remember from some old posts that you were quite into VFLib. May I ask how and why you got rid of it?


#11

I used Vinnie's FreeType amalgam first and changed to VFLib when he moved FT into that. I got very interested in his method for updating between threads, but never got round to implementing it as a simple timer arrangement was sufficient for me. When he mentioned he had found a problem with the implementation but didn't detail it - and then there were the compile issues, it made it clear he had moved on and I couldn't expect any support.. So I decided to cut loose for now, which is a shame because there is a lot of cool stuff in there.

I still use FreeTypeFaces, and I might grab some of the other graphic stuff. But I'm wary of the MessageThread stuff as I don't understand the implementation well enough to dig myself out of a hole!


#12

Hi!

Only slightly off-topic: when you refer to "his method for updating between threads", it it the vf::ConcurrentState, vf::CallQueue etc classes that he made the SimpleDJ example for?

I just found your marathon thread http://www.juce.com/forum/topic/whats-best-practice-gui-change-notification, was it there he said that his implementation had a problem but didn't specify it? I think I should read that thread regardless!

I was just about to get into learning from the SimpleDJ example, but if there's a problem in the implementation now I get cold feet, since this is stuff I still only barely understand anyway :)

 


#13

I would recommend to forget all about VFLib for now. It has some really awesome stuff like the CallQueues! But the stuff is so complicated that i doubt anyone will ever maintain this library, unless Vinnie takes it up again, which at the moment he has clearly stated that he will not do.

I could compile VFLib after applying the above modifications, but the singletons in VFLib are broken. I'm back to Juce 2.1.1 and i'll rather loose VFLib at the first opportunity, than invest the time to teach myself the lib's sources from top to bottom in order to be able to fix these issues, being uncertain if that's even possible.

My adventure with VFLib was one of those Murphy moments. I got all exited about this library, spent about a week reimplementing the state management using CallQueues, and after another week or two, the library is broken and Vinnie throws in the towel. Quite frankly, i can't remember when was the last time i've felt so stupid. I'm literally banging my face with the keyboard .l isy öö oifg - auch! öoi shnhjklvfs - auch! :p


#14

To onar3D,

Yes - those methods may or may not be OK. Vinnie has gone quiet here and we haven't got any confirmation. All we've got is this: http://www.juce.com/forum/topic/vflib-significant-defects-found


#15

Thanks for the warning, I'll stay clear for now then!

Refactoring a program to make it multithreaded is hard enough, doing it with an unsupported library that uses things I've never heard of before (Functors...????) seems risky... :)

Too bad since it seemed to solve things in a neat way. Maybe Beast? But not right now...


#16

Disclaimer: My app relies almost completely on VFLib for managing concurrent state. It works great for me. What Vinnie has accomplished with VFLib is amazing.

Having said that I agree that its best not to start new projects using VFLib until it becomes maintained again. Vinnies remarks about bugs got me worried as well. In any case, with much help of Vinnie I started bringing over the for me most important pieces of VFLib to Beast. For the multi-threaded concurrent thread management only the ListenerList is missing: https://github.com/vinniefalco/rippled/tree/develop/src/beast/modules/beast_vflib

In the meantime, a proper quick fix to the compile problems of VFLib with the latest JUCE tip is to add template specializations of the ContainerDeletePolicy for the VFLibs singletons. Attached is a patch that adds these. Vinnie was very helpful creating these because my knowledge about template is small. As soon as I find time I’ll provide a pull request for https://github.com/vinniefalco/VFLib/tree/develop

PS: Jules, could you allow the file extension .patch for uploads? I had to rename the patch to .txt to upload it.


#17

I'm in the same boat. VFLib has been working fabulously for my concurrency needs, only problem being I'm stuck on JUCE 2.1.1.

It's a real shame that Vinne decided to discontinue developement - when I switched my app to use vf::concurrent instead of a timer approach it became much smoother and more responsive, which is important since it's a synthesiser. The problem of cross-thread communication is one of the few things that JUCE doesn't solve satisfactorily for me, and VFLib solved it beautifully.

I'd love to fork and maintain just the concurrency module from VFLib, but I don't believe I have the skill as a developer.

Anyway, many thanks for your patch, I'm going to apply that and see how I go with JUCE 3.0.

EDIT: Your patch works great! It's obviously a short term solution, but it's a big help for now, thank you.


#18

I have started with much help from Vinnie to work on bringing the concurrency module to beast: https://github.com/vinniefalco/rippled/tree/develop/src/beast/modules/beast_vflib

Before it is really usable the ListenerList must be implemented. As soon as time permits I'll give that a try. Its not a 100% drop in replacement but it will hopefully not take to much effort to switch over.

 


#19

I applied P4tr3ck's patch and made the transition to JUCE 3 very smoothly. After testing a while the call queues seem to be working fine. Updating to JUCE 3 has fixed a lot of host compatibility problems. I can't thank you enough P4tr3ck! Good luck with your effort to bring the call queues to Beast!