MrSwiss wrote:Anyhow, separately compiled isn't the same as include-file (point at issue, right now!).
FreeBASIC 1.08 Development
Re: FreeBASIC 1.08 Development
-
- Posts: 534
- Joined: Dec 02, 2011 22:51
- Location: France
Re: FreeBASIC 1.08 Development
I think fxm's solution shall be seen as strictly technical meaning not conceptual nor standing for or against JK proposal. I just see it as a technical opening. @Mr Swiss : indeed I agree your point of view about implementation.
-
- Posts: 284
- Joined: Mar 07, 2018 13:59
- Location: Germany
Re: FreeBASIC 1.08 Development
Why is this so hard to understand?
- MrSwiss posted code, which indeed works. It makes use of overloaded procedures, which are setup by default for the default variable type. For UDTs you must setup an appropriate function, before you can use it. A macro is supplied for this task. So far so good.
- my reply was, that all of this is possible without the need for a macro call. I already have developped similar (much more comprehensive) array extensions, which can do the same without the need for a setup macro by the user. Among other things it offers a dedicated function for retrieving each member of the array descriptor separately.
- MrSwiss replied, that my method would require 7 calls to get the full descriptor information (implying that his method is required to do that).
- I posted code, which shows a (already existing) method of retrieving the array descriptor of array of any kind (including UDTs). The decisive line is (using fbc):
or (with namespace prefix)
this code doesn´t need a setup macro for UDTs. It´s one single line and it works everwhere.
If you look at the declaration of ArrayDescriptorPtr in fbc-init\array.bi you will notice, that the array is declared "AS ANY", which doesn´t work for regular FB code (that is, as fxm, showed, it is possible, but only under certain circumstances). The RTL can accept arrays "AS ANY". Never wondered how RTL functions for arrays like UBOUND work - for all kinds of arrays?
So while MrSwiss´code works, there is an easier method.
- MrSwiss posted code, which indeed works. It makes use of overloaded procedures, which are setup by default for the default variable type. For UDTs you must setup an appropriate function, before you can use it. A macro is supplied for this task. So far so good.
- my reply was, that all of this is possible without the need for a macro call. I already have developped similar (much more comprehensive) array extensions, which can do the same without the need for a setup macro by the user. Among other things it offers a dedicated function for retrieving each member of the array descriptor separately.
- MrSwiss replied, that my method would require 7 calls to get the full descriptor information (implying that his method is required to do that).
- I posted code, which shows a (already existing) method of retrieving the array descriptor of array of any kind (including UDTs). The decisive line is (using fbc):
Code: Select all
Dim As FBARRAY Ptr pa = ArrayDescriptorPtr(array())
Code: Select all
Dim As FBC.FBARRAY Ptr pa = FBC.ArrayDescriptorPtr(array())
If you look at the declaration of ArrayDescriptorPtr in fbc-init\array.bi you will notice, that the array is declared "AS ANY", which doesn´t work for regular FB code (that is, as fxm, showed, it is possible, but only under certain circumstances). The RTL can accept arrays "AS ANY". Never wondered how RTL functions for arrays like UBOUND work - for all kinds of arrays?
So while MrSwiss´code works, there is an easier method.
Re: FreeBASIC 1.08 Development
That others would likely call: BLOAT. (JK seems to only want "his own stuff", using any meansJuergen Kuehlwein wrote:I already have developped similar (much more comprehensive) array ...
preferably without competition, see below for explanation)
Red part is a straight lie: because I've clearly stated that my method does it "all in one".Juergen Kuehlwein wrote:- MrSwiss replied, that my method would require 7 calls to get the full descriptor information (implying that his method is required to do that).
(Proof required? Just a single Sub retrieves all the header information.)
Your methods require 7 calls (one argument per call), mine does it "single-shot", all at once.
The remainder of the post is nothing but common knowledge ...
(The code is most likely just a "copy & paste" from my code. Seem to remember: pa)
-
- Posts: 284
- Joined: Mar 07, 2018 13:59
- Location: Germany
Re: FreeBASIC 1.08 Development
Sigh... i repeat what i already said above: why is this so hard to understand, that only one single line and nothing else is required to retrieve all information (=all in one) in an array´s descriptor? You don´t need a separate overloaded function for each type of array in this case.
This is my last post to this topic.
Code: Select all
Dim As FBC.FBARRAY Ptr pa = FBC.ArrayDescriptorPtr(array())
Re: FreeBASIC 1.08 Development
I obviously agree.
That's how I use it already, and I'll use it later too.
(the simplest and the fastest)
That's how I use it already, and I'll use it later too.
(the simplest and the fastest)
Re: FreeBASIC 1.08 Development
Obviously "other peoples arguments" don't seem to count at all.
that is what it's all about (as Lost Zergling confirmed, in the post made).
You're right (I don't need it) but also wrong, most users demand "ease of use" and,Juergen Kuehlwein wrote:You don´t need a separate overloaded function for each type of array in this case.
that is what it's all about (as Lost Zergling confirmed, in the post made).
-
- Posts: 534
- Joined: Dec 02, 2011 22:51
- Location: France
Re: FreeBASIC 1.08 Development
I m just watching around the ideas. Considering the idea seeing the preprocessor as an object. Considering the idea the linker could be seen as a conceptual layer in its own rights... I see these as possibilities. My idea the linker layer outside the Fb core, nevertheless inside the ecosystem.
-
- Posts: 534
- Joined: Dec 02, 2011 22:51
- Location: France
Re: FreeBASIC 1.08 Development
I think it might be possible to implement a specific prefix for features that use preprocessor specifications, which from the user's point of view could be manipulated a bit like a global object (pp_ARRAY, pp_VIDEO, and so on, a syntax close to pp.ARRAY, and so on). This would perhaps bring a dimension of ease to the use of the preprocessor : a conceptual standardization in phase with the technical framework. Regarding the question of the conceptual implementation of a module with separate compilation but still the same language, the user must be able to understand ergonomically if the language is strongly typed or not (and when?). There is a paradox here: to be both static and dynamically typed, a little like wanting to go beyond the framework of object design whereas almost everything can be programmed in object design. So I see automatic or dynamic typing as a conceptual "vertical" scope, and going down to the technical side, I'll see something like this:
VerticalScope UniversalTypes' All Types Ptr inherit from calling procedure
...
End VerticalScope
Thus, the ways of the ecosystem and as they provide technical openings, are intended to find a conceptual outlet. It's a kind of "inverted" way to see things evolve, but I'm just pragmatic in trying to translate and make a connection with the "hight level" in terms of implementation. From the "design" point of view, the "new eye" side is what I can bring, and so what I do not know is as important to me as what I already know, because once we know, we have fewer ideas to reinvent things, so I have to try to "know less" as long as possible, and compel myself to conceptualize. This to clarify my approach. My wish is not to say if this or that code is better than another, but to deepen the side "box ideas", open minded, knowing that it is not my role to program that and I m not even considering trying.
VerticalScope UniversalTypes' All Types Ptr inherit from calling procedure
...
End VerticalScope
Thus, the ways of the ecosystem and as they provide technical openings, are intended to find a conceptual outlet. It's a kind of "inverted" way to see things evolve, but I'm just pragmatic in trying to translate and make a connection with the "hight level" in terms of implementation. From the "design" point of view, the "new eye" side is what I can bring, and so what I do not know is as important to me as what I already know, because once we know, we have fewer ideas to reinvent things, so I have to try to "know less" as long as possible, and compel myself to conceptualize. This to clarify my approach. My wish is not to say if this or that code is better than another, but to deepen the side "box ideas", open minded, knowing that it is not my role to program that and I m not even considering trying.
Re: FreeBASIC 1.08 Development
Of course we're offended! ;)coderJeff wrote:lol, yes, the list of names looked like that in my head too. Dodicat is super handy to have here. I hope everyone included only by ", .." will not be offended.Lost Zergling wrote:...(Dodicat, ..)...
...
Little request, if I may: could any of the devs expose a simple function to retrieve the number of events in the FBGFX events queue, and another one to peek the events of the queue without dequeuing them? It could use the same function for both. For example:
Code: Select all
#include once "fbgfx.bi"
dim as Fb.Event ptr _
e
'' Fetch a pointer to the first element of the queue
dim as integer _
count => peekEvents( e )
/'
Then one can process the events without removing them from the
queue. This is useful when there's some code that needs to do
preprocessing of the events before the user code does (ie a
framework or, in my case, a windowing system).
'/
for _
i as integer => 0 _
to count - 1
if( e[ i ].type = Fb.EVENT_KEY_PRESS ) then
'' Handle the event here
end if
next
Re: FreeBASIC 1.08 Development
Dang it, of course you would jump on that one. ;)paul doe wrote:Of course we're offended! ;)
Internally, gfx lib locks the event list when adding or consuming events from the event list. After reading the number of events in the queue, potentially, more events could be added between the time the number of events queued are read and the operation that uses that count value. Not sure what you mean by preprocessing events -- modify the event data?Little request, if I may: could any of the devs expose a simple function to retrieve the number of events in the FBGFX events queue
I am curious and want to understand intent. What is the case where you want to examine the events queue, but not consume the gfx lib event in to your own event handling pipeline?
Otherwise, seems straight forward to add a get-event-count and peek-event procedures.
Re: FreeBASIC 1.08 Development
No. Have a look at this post:coderJeff wrote:...
Internally, gfx lib locks the event list when adding or consuming events from the event list. After reading the number of events in the queue, potentially, more events could be added between the time the number of events queued are read and the operation that uses that count value. Not sure what you mean by preprocessing events -- modify the event data?
...
viewtopic.php?f=15&t=27953&p=266287#p266287
As you can see, I can't implement a fully encapsulated class that's truly black-boxed, since event handling needs to be in-cooperated with the client code. This also adds an unwanted dependency on the abstraction and, worse still, makes it depend on an implementation detail. Compare the abstraction that uses multiKey() with the one that uses events: one is truly black-boxed, the other is not.
Support/framework code. Say, a windowing system or some other abstraction such as the one provided in the post above. The intent is just to examine the current queue, not actually modifying it. This would allow support code to preprocess events if needed, without disturbing the client's handling of them....
I am curious and want to understand intent. What is the case where you want to examine the events queue, but not consume the gfx lib event in to your own event handling pipeline?
If a simple minded approach like the one proposed gives too much trouble (due to threading issues, as you point out), have a look at how SDL2 implements it: SDL_PeepEvents. The approach is admittedly more cumbersome but at least it grants immutability.
Yes, I know. I don't usually ask for much, no? ;)...
Otherwise, seems straight forward to add a get-event-count and peek-event procedures.
Re: FreeBASIC 1.08 Development
On the other hand, the work might not be worth the trouble, since some OSses don't allow you to process events on another thread, just on the main one. Doing this differently may wreak havoc in those cases so perhaps it's best just to stick to the traditional update() pattern. Thanks for considering this anyway ;)
Re: FreeBASIC 1.08 Development
for now FreeBasic have #Inclib "" and #LibPath "" pair fo libraries, but there a no #includePath "" for #include "", only -i command line option, with I fail to make work...
is it possible to add something like #includePath "" to future FreeBasic 1.08?
is it possible to add something like #includePath "" to future FreeBasic 1.08?
Re: FreeBASIC 1.08 Development
I finally have a Mac (VM) at home and can work on the Mac port again.
SDL 1.2 C headers rename main to SDL_main and SDL provides its own main() function which does some initialisation. You can get away without calling SDL's main on Windows and Linux, but it's mandatory on OSX. SDL 2 does away with this, but nonetheless I want to support SDL 1.2 on Mac in FreeBASIC.
My solution to this (in my FB fork for Mac) was to add a commandline flag "-entry" which renames the main function. Should I keep this, or replace it with a new preprocessor builtin "#entry"? The advantage of switching to #entry is that it could be put in sdl.bi and you wouldn't have to manually add it to the commandline.
SDL 1.2 C headers rename main to SDL_main and SDL provides its own main() function which does some initialisation. You can get away without calling SDL's main on Windows and Linux, but it's mandatory on OSX. SDL 2 does away with this, but nonetheless I want to support SDL 1.2 on Mac in FreeBASIC.
My solution to this (in my FB fork for Mac) was to add a commandline flag "-entry" which renames the main function. Should I keep this, or replace it with a new preprocessor builtin "#entry"? The advantage of switching to #entry is that it could be put in sdl.bi and you wouldn't have to manually add it to the commandline.