I wish a big bundle
-
- Posts: 252
- Joined: Mar 12, 2006 16:25
I wish a big bundle
I know it's a lot of work making a big bundle, with all libraries for various platforms. But lets see. I tried to get a static library of sqlite3 yesterday. It took me one hour to get a working dll.a out of the .def file from the website. It took me several hours to create the static lib. I am not a bloody beginner, but it's been a while I compiled / linked a C project under windows. I know if i try again in a year it will take at least an hour. FB has all features needed, so many .bi files, but there is a great lack of further integration. There are some small libraries like lua you would even under linux include as static libraray, but often it's not as easy as "apt-get install libsqlite3-dev".
My wishes:
There could be ONE powerful IDE for windows and linux. There could be a Windows package with all libraries included as static and dynamic version. For Linux the ide could be able to do some package magic ( apt / yum) making the use of libraries as easy as possible. Crosscompiling for x64/x86/arm or even for dos with common libraries could be as easy as selecting an entry from the combobox.
Now FB seems to be very stable, the release cycle is getting longer. Maybe it's better to wait a year, because of a new gcc version used? I am willing to help.
My wishes:
There could be ONE powerful IDE for windows and linux. There could be a Windows package with all libraries included as static and dynamic version. For Linux the ide could be able to do some package magic ( apt / yum) making the use of libraries as easy as possible. Crosscompiling for x64/x86/arm or even for dos with common libraries could be as easy as selecting an entry from the combobox.
Now FB seems to be very stable, the release cycle is getting longer. Maybe it's better to wait a year, because of a new gcc version used? I am willing to help.
Re: I wish a big bundle
Quite some wish ;) - but (IMO) the right one, to move FreeBasic forward...RockTheSchock wrote:I know it's a lot of work making a big bundle, with all libraries for various platforms. But lets see. I tried to get a static library of sqlite3 yesterday. It took me one hour to get a working dll.a out of the .def file from the website. It took me several hours to create the static lib. I am not a bloody beginner, but it's been a while I compiled / linked a C project under windows. I know if i try again in a year it will take at least an hour. FB has all features needed, so many .bi files, but there is a great lack of further integration. There are some small libraries like lua you would even under linux include as static libraray, but often it's not as easy as "apt-get install libsqlite3-dev".
My wishes:
There could be ONE powerful IDE for windows and linux. There could be a Windows package with all libraries included as static and dynamic version. For Linux the ide could be able to do some package magic ( apt / yum) making the use of libraries as easy as possible. Crosscompiling for x64/x86/arm or even for dos with common libraries could be as easy as selecting an entry from the combobox.
Now FB seems to be very stable, the release cycle is getting longer. Maybe it's better to wait a year, because of a new gcc version used? I am willing to help.
But there's a pressing necessity which has to be met beforehand:
FreeBasic needs Classes!
To make working with such a "big-default-bundle" easier, a well-suiting wrapper would have to come as a true "Class-Library"
(with stable Interfaces, so that Code-Examples will always perform the same - no matter if there was some (version)change
in an underlying "C-Flat-API", which could be easily fixed under the covers of the Class-Wrapper-lib).
I know that FB supports "kinda Classes" - but I mean "real ones" - with proper:
- "Reflection" (which materailizes itself also in a compiled "Class-Dll- or -*.so Binary" so that the Binary is "self-describing")
- proper RefCounting (to easier manage the life-cycle of such Class-instances)
- and last but not least - easy to manage Event-Support!
What I described above is basically what COM/ActiveX currently does on the MS-platforms -
and what glib-based Class-implementations support within the "GTK/GLib space"
I'd be willing to help (and already have a large, stable and well-tested framework available "for porting")
when such a "more complete Class-support" should be tackled by the FB-community first.
The current "Type-based Class-approach" of FB is not bad, and I think it could be the base for a more complete
Class-approach, which I'd recommend to tackle over a separate "Class-PreProcessor", which would recognize a
new *.cls (or *.bc or whatever) FileType (and performs its preprocessing only on these Files).
Within (and only within) that new *.cls FileType there could be some "new rules and keywords", which
only the new PreProcessor understands and recognizes - not clashing with the "normal FB-compiler",
which gets its input fed, only after the new Class-Preprocessor was "through with the *.cls" or "*.bc"...
As for the "big bundle" for windows - you could try one (vbRichClient5... 2.5MB zipped, but currently still as a COM-lib).
It contains a Form-, -Widget and graphics-Framework (cairo-based), as well as "ADO-like" SQLite-bindings,
XML- and JSON-support - etc.
I've tested the "FB-waters" with it already in this post here (writing small Wrapper-Objects with FBs current Type-based Classes):
http://www.freebasic.net/forum/viewtopi ... =6&t=24795
In case you want to try it out, there'd be nothing to "setup or register" - the Demos all work regfree -
the only necessity being a FB-32Bit-GAS compiler for Win (version >= 1.0.5)
As FB is (and works) currently, the porting-efforts (to FB) for this Class-Framework would be too big -
but I layed out the necessities already above... (offer for help included, should somebody (or a group
of somebodies) find the time - and want to "steer FB into that direction"...
Olaf
-
- Posts: 1186
- Joined: May 08, 2006 21:58
- Location: Crewe, England
Re: I wish a big bundle
Can't remember where it came from but there was a cartoon witsh two techies talking; in the first 2 frames the conversation was "There are 14 different IDEs out there ... what we need is a new, more powerful one."
The last picture showed them much later, saying "There are 15 different IDEs out there ...".
As far as classes are concerned, probably half the FB community struggle to find uses for what is already there - and looking at the current generated assembler code relative to what was there orignally, a great deal of safety measures are already cluttering thing up. But provided you don't break the current compiler, feel free to throw it in.
The last picture showed them much later, saying "There are 15 different IDEs out there ...".
As far as classes are concerned, probably half the FB community struggle to find uses for what is already there - and looking at the current generated assembler code relative to what was there orignally, a great deal of safety measures are already cluttering thing up. But provided you don't break the current compiler, feel free to throw it in.
Re: I wish a big bundle
The original is with "standards": https://xkcd.com/927/jevans4949 wrote:Can't remember where it came from but there was a cartoon witsh two techies talking; in the first 2 frames the conversation was "There are 14 different IDEs out there ... what we need is a new, more powerful one."
The last picture showed them much later, saying "There are 15 different IDEs out there ...".
-
- Posts: 1186
- Joined: May 08, 2006 21:58
- Location: Crewe, England
Re: I wish a big bundle
... and I remembered the numbers! What a sad case I am!marcov wrote:The original is with "standards": https://xkcd.com/927/jevans4949 wrote:Can't remember where it came from but there was a cartoon witsh two techies talking; in the first 2 frames the conversation was "There are 14 different IDEs out there ... what we need is a new, more powerful one."
The last picture showed them much later, saying "There are 15 different IDEs out there ...".
Re: I wish a big bundle
"Real" classes as defined by whom? Java? C++? Python? FB's OOP support is heavily influenced by C++. As near as I can tell, FB supports the idea of RAII: Resource acquasition is initialization. In other words when instances go out of scope its destructor is called, and memory cleaned up. FB very much supports "real" classes. As real as C++'s classes. FB just happens to use the same keyword for UDTs and classes. As for reference counting of dynamically-allocated instances, neither C++ nor FB offer this natively. C++ does have reference counting when you use smart pointers, which is something FB doesn't have because FB lacks templates. FB could gain templates I suppose.OSchmidt wrote:But there's a pressing necessity which has to be met beforehand:
FreeBasic needs Classes!
To make working with such a "big-default-bundle" easier, a well-suiting wrapper would have to come as a true "Class-Library"
(with stable Interfaces, so that Code-Examples will always perform the same - no matter if there was some (version)change
in an underlying "C-Flat-API", which could be easily fixed under the covers of the Class-Wrapper-lib).
I know that FB supports "kinda Classes" - but I mean "real ones" - with proper:
- "Reflection" (which materailizes itself also in a compiled "Class-Dll- or -*.so Binary" so that the Binary is "self-describing")
- proper RefCounting (to easier manage the life-cycle of such Class-instances)
- and last but not least - easy to manage Event-Support!
What I described above is basically what COM/ActiveX currently does on the MS-platforms -
and what glib-based Class-implementations support within the "GTK/GLib space"
I'm not sure what you mean when you talk about GTK/GLib, which is a C-based library that can easily be used from FB. GLib's GObject framework is powerful, but it's not dependent on these features you feel FB should add.
Re: I wish a big bundle
Your answer was already contained in this block here:caseih wrote: "Real" classes as defined by whom?
And no, I don't want to talk down the current Type-based FB-Classes... as I wrote in my first post above,OSchmidt wrote: What I described above is basically what COM/ActiveX currently does on the MS-platforms -
and what glib-based Class-implementations support within the "GTK/GLib space"
I consider them sufficient, to implement an "easier to use on the outside" Class-approach
(with less typing-efforts needed on the developers side, managed by a new "Class-PreProcessor").
I guess what I was trying to focus on in my posting (besides reducing some of the typing-efforts for Class-Definitions at the occasion),
was more in the realm of "ABI" (self-describing Dll-Binaries, which offer an "FB-standardized" instantiation-mechanism
for their contained Classes - as well as an "FB-standardized Enumeration-Mechanism" for a given Class-Types interface).
That would (besides other interesting things) e.g. offer IDE-implementors an easy way to describe
and use Class-based Dll-Plugins, as well as an easy way to populate "Lookup-Structures" with regards
to "Intellisense-Support for Classes".
Also with regards to the Event-Support for Classes, there's much room for improvements
(then requiring support for interface-matching-tests and for interface-implementation -
all available also "among and across compiled binaries").
I just didn't want to leave the term "MS-COM/ActiveX" standing in the room as the only approach to lookup in thesecaseih wrote: I'm not sure what you mean when you talk about GTK/GLib, which is a C-based library that can easily be used from FB. GLib's GObject framework is powerful, but it's not dependent on these features you feel FB should add.
regards (although it's the one I know most about) - since GLib/GObject covers many/most COM-features too:
https://wiki.gnome.org/action/show/Proj ... rospection
e.g. Vala (as a "C#-Clone without Garbage-Collector") is making good use of it in its own Class-implementations.
But an entirely self-implemented approach to the outlined requirements (Reflection, Interfaces/Implementation and Events)
within FB itself is also possible.
I'm arguing from an engineering-standpoint - being a big fan of "building blocks" aka "compiled binaries"
(which when they are stable and well-implemented, will not have to be touched anymore, lightening the amount
of code to parse by the compiler in any given, larger project - and nevertheless offering "automatic intellisense"
for their contained Class-Interfaces in a given IDE, after they were "checked in" (as a Dll, not as Code).
It's all about "tooling" these days - and successful (higher-level) languages come with integration-
helpers (IDEs), which make the "plumbing and glueing" of Code and Binaries easier.
My suggestions with regards to an "enhanced Class-System in FB" had that larger goal in mind
(Classes which "integrate better" in a new "tooling-system", being not only "easier to type" for the developer,
but at the same time also being "easier to use and wire" from a compiled binary)...
Olaf
Re: I wish a big bundle
I see, sort of. I'm not sure wanting COM as an object model for FB (or any language) is appropriate, though. COM is as much about protocol as it is about an object model. And COM objects can be created from a number of languages, including C++ which contains its own object model different from COM. COM is more about binding and glue between languages than it is about how a class should be.
Even the issue of introspection is as much about protocol as it is about the object system. GLib's introspection mechanism does not rely on the object model specifically supporting introspection. Instead you generate a GIR file that contains the interface definitions, which is, if I understand correctly, parsed from the c source code files themselves, and possibly getting annotations from specially-formatted comments. I've not worked with COM, but my understanding is that there are interface definition files, and a mechanism for registering interfaces with the system so that others can query and find them. None of this, as far as I can tell, has much to do with individual language's support for OOP.
Even the issue of introspection is as much about protocol as it is about the object system. GLib's introspection mechanism does not rely on the object model specifically supporting introspection. Instead you generate a GIR file that contains the interface definitions, which is, if I understand correctly, parsed from the c source code files themselves, and possibly getting annotations from specially-formatted comments. I've not worked with COM, but my understanding is that there are interface definition files, and a mechanism for registering interfaces with the system so that others can query and find them. None of this, as far as I can tell, has much to do with individual language's support for OOP.
Re: I wish a big bundle
Well, I'm sure that it offers the advantages I've outlined already.caseih wrote:I'm not sure wanting COM as an object model for FB (or any language) is appropriate, though.
As for your term "appropriate" (in case you meant it with "potential legal issues" in mind)... With regards to re-implementing
existing interfaces there's nothing "forbidden" - since Wine is implementing things entirely compatible with COM (per plain C) -
and Mozilla is using XPCOM (which in its base-interfaces, is ABI compatible with MS-COM on Windows), too.
https://developer.mozilla.org/en-US/doc ... Tech/XPCOM
Yep, that'd be another advantage, in case the FB-compiler would produce its Classes with appropriatecaseih wrote:... And COM objects can be created from a number of languages, ...
(COM-ABI-compatible) interfaces.
Not sure how you mean that, since COM describes quite clearly, what Interfaces a Class needs to support, forcaseih wrote:COM is more about binding and glue between languages than it is about how a class should be.
interaction with other languages (at the minimum this would involve, that the first three Methods in a given
VTable are compatible with IUnknown, which FB can easily accomplish with what it has built-in already).
One can create (and use) COM-compatible Class-instances completely without any *.idl Definitions or interactioncaseih wrote: I've not worked with COM, but my understanding is that there are interface definition files, and a mechanism for registering interfaces with the system so that others can query and find them.
with a "registry". Typelibs (*.tlb -files or -resources) - as well as "registry-entries" could be produced though
when needed - but they are not really necessary.
I was not talking about OOP - it's all just about interfaces and the "Binary-Format of Classes" the compiler produces finally ...caseih wrote: None of this, as far as I can tell, has much to do with individual language's support for OOP.
In case the VTable-members are filled with Pointers-to-Methods that are (at least for the base-interfaces) compatible to COM
(or XPCOM), then these Classes adhere to a standard, which allows them re-usage in other languages.
What default-methods "a-top the IUnknown-Members" (and maybe also IDispatch) are placed in a produced VTable,
would be up to the FB-compiler or -community, but I'd suggest a well-thought-out FB-Interface that allows for
reflection and easier Event-wiring as well.
Olaf
Re: I wish a big bundle
I see. So you're looking for a BASIC-like language with first-class COM support then. Because right now you can define and create COM objects from within FB that can be used by other applications.
You mentioned Glib and its object system. This is not really similar to COM. Glib combined with dbus might be the equivalent of COM. I'm pretty sure Qt can work with dbus too.
Anyway, many people have tried to create the universal object system over the years. There have been many attempts. COM, ActiveX, XPCOM, DCOP, Corba, and so forth. They all have strengths and weaknesses and none of them are universal. They all add layers of complexity and boiler plate. I'm not sure these features belong in a language definition.
You mentioned Glib and its object system. This is not really similar to COM. Glib combined with dbus might be the equivalent of COM. I'm pretty sure Qt can work with dbus too.
Anyway, many people have tried to create the universal object system over the years. There have been many attempts. COM, ActiveX, XPCOM, DCOP, Corba, and so forth. They all have strengths and weaknesses and none of them are universal. They all add layers of complexity and boiler plate. I'm not sure these features belong in a language definition.
Re: I wish a big bundle
No - I was making a suggestion with regards to the topic the OP brought up -caseih wrote:I see. So you're looking for a BASIC-like language with first-class COM support then.
and already "some very few COM-related things" (e.g. producing IUnknown-compatible FB-Classes would be dead-simple)
would be sufficient, to prepare FB to be able to produce shareable, selfdescribing Class-Library-Binaries,
in a platform-independent manner (in the beginning only being used within the FB-Community, to
support a larger, interface-wise selfdescribing class-runtime-lib - but with the potential to be used also
from other languages or environments -> as e.g. "providing Plugins for Mozillas Gecko-Engine").
You over-estimate the efforts needed, to accomplish that (there'd be no need to e.g. "re-invent CORBA" or something).
The goal of "Class-Library-Binaries for FB" is reachable already with a relative simple Class-PreProcessor -
which kicks in only on a new *.bc FileType, and which could address other things (redundancies) with
current "FB-Class-Typing-efforts" as well... (all that without affecting the current Type-based-Class mechanisms).
Reading this Forum for a while already - I gathered that not each and every FB-User is currently happy with the
typing-efforts for the actual Type-Based-FB-Classes.
Right - and it doesn't really need to be, but it *is* an "object-system" (I like that term you've just introduced)...caseih wrote: You mentioned Glib and its object system. This is not really similar to COM.
FB currently has *no* real "object system" at all - but it could introduce one in a quite simple manner -caseih wrote: Anyway, many people have tried to create the universal object system over the years.
and its implementation would not have to make an attempt to be: "universal"
We still talk "at cross-purposes" IMO - since I'm not suggesting any changes in the existing FB-compiler.caseih wrote: ...They all add layers of complexity and boiler plate. I'm not sure these features belong in a language definition.
What I have in mind could be accomplished in relative simple "PreBuild"- (and maybe "PostBuild"-) Operations
on the commandline (which an IDE-extension could address).
Olaf
Re: I wish a big bundle
Well you must be using the term different that I am. Because FB most certainly does have a real object system. I'll admit that when you compile everything down to binary bits, it's all just syntactic sugar.OSchmidt wrote:FB currently has *no* real "object system" at all - but it could introduce one in a quite simple manner -
and its implementation would not have to make an attempt to be: "universal"
You're quite correct that we are talking cross purposes. I'm not at all clear on what you are really wanting or proposing. You started out talking about reflection and introspection, which I can understand, but then brought COM into it and even mentioned Glib's gobject. The latter is no different in principle than an object model such as what C++ or FB provide. Quite confusing. And I'll apologize for taking the topic so far away from the original query about a universal bundle.We still talk "at cross-purposes" IMO - since I'm not suggesting any changes in the existing FB-compiler.caseih wrote: ...They all add layers of complexity and boiler plate. I'm not sure these features belong in a language definition.
What I have in mind could be accomplished in relative simple "PreBuild"- (and maybe "PostBuild"-) Operations
on the commandline (which an IDE-extension could address).
Re: I wish a big bundle
Yes. COM is interface based. In some cases type libraries work a bit as the description files, but that requires a generation step.caseih wrote: I've not worked with COM, but my understanding is that there are interface definition files, and a mechanism for registering interfaces with the system so that others can query and find them. None of this, as far as I can tell, has much to do with individual language's support for OOP.
The OP might mean ActiveX dispatch interface. Though strictly that is not introspection, but the ability to call any identifier on a olevariant containing a IDispatch, and then the IDispatch.Invoke method is called with the name of the functions and a list of parameters annotated with type info (array of variant).
This is nice to have as extra for bridging scripting languages, but it slows down the language too much if you try to base you object system on it.
I also wonder when introspection was required to have a "real" object system. I didn't get that memo.
-
- Posts: 2958
- Joined: Jun 02, 2015 16:24
Re: I wish a big bundle
From my point of view it seems clear that we need something overriding the order in which the objects are defined. A very simple additional layer, that could or not be called an object model, could be simply something that permits "natively" (with all the complexity hidden) each object to know about the other without any sense of declaration order. This tiny thing would already make life easier.caseih wrote:Well you must be using the term different that I am. Because FB most certainly does have a real object system.OSchmidt wrote:FB currently has *no* real "object system" at all - but it could introduce one in a quite simple manner -
and its implementation would not have to make an attempt to be: "universal"
I don't know if this is such a thing that OSchmidt includes in its description. But this would minimize the distance between FB and VB.net in term of ease of class development I think.
About the big bundle, sure we need it! The FBIDE bundle was very popular, something similar and going further would be warmly welcome.
Re: I wish a big bundle
The problem with bundles is that they become obsolete very quickly which is probably why we don't see any currently being offered. That's also the problem with including too many dependencies into the FB runtime library such as adding PNG support, etc.
Regarding VB.net, do you not have to include header files of some sort to access objects and classes? Even in C# we have to say "using some.package.path" which is the equivalent of a FB header file or a package import in Python. There's no magical every object knows about every other object stuff going on. The definitions have to be imported so the compiler knows what they are.
Honestly I get the impression that what many of you are looking for you might find in Python (except compiling to an optimized exe). I confess it is rather nice to import a package and then be able to list the contents of the package and list all the functions and classes right from the interactive console.
Regarding VB.net, do you not have to include header files of some sort to access objects and classes? Even in C# we have to say "using some.package.path" which is the equivalent of a FB header file or a package import in Python. There's no magical every object knows about every other object stuff going on. The definitions have to be imported so the compiler knows what they are.
Honestly I get the impression that what many of you are looking for you might find in Python (except compiling to an optimized exe). I confess it is rather nice to import a package and then be able to list the contents of the package and list all the functions and classes right from the interactive console.