FreeBASIC 1.08 Development

General discussion for topics related to the FreeBASIC project or its community.
Post Reply
MrSwiss
Posts: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: FreeBASIC 1.08 Development

Post by MrSwiss »

MrSwiss wrote:Anyhow, separately compiled isn't the same as include-file (point at issue, right now!).
Lost Zergling
Posts: 534
Joined: Dec 02, 2011 22:51
Location: France

Re: FreeBASIC 1.08 Development

Post by Lost Zergling »

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.
Juergen Kuehlwein
Posts: 284
Joined: Mar 07, 2018 13:59
Location: Germany

Re: FreeBASIC 1.08 Development

Post by Juergen Kuehlwein »

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):

Code: Select all

  Dim As FBARRAY Ptr pa = ArrayDescriptorPtr(array())
or (with namespace prefix)

Code: Select all

  Dim As FBC.FBARRAY Ptr pa = FBC.ArrayDescriptorPtr(array())
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
Posts: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: FreeBASIC 1.08 Development

Post by MrSwiss »

Juergen Kuehlwein wrote:I already have developped similar (much more comprehensive) array ...
That others would likely call: BLOAT. (JK seems to only want "his own stuff", using any means
preferably without competition, see below for explanation)
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).
Red part is a straight lie: because I've clearly stated that my method does it "all in one".
(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)
Juergen Kuehlwein
Posts: 284
Joined: Mar 07, 2018 13:59
Location: Germany

Re: FreeBASIC 1.08 Development

Post by Juergen Kuehlwein »

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.

Code: Select all

Dim As FBC.FBARRAY Ptr pa = FBC.ArrayDescriptorPtr(array())
This is my last post to this topic.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: FreeBASIC 1.08 Development

Post by fxm »

I obviously agree.
That's how I use it already, and I'll use it later too.
(the simplest and the fastest)
MrSwiss
Posts: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: FreeBASIC 1.08 Development

Post by MrSwiss »

Obviously "other peoples arguments" don't seem to count at all.
Juergen Kuehlwein wrote:You don´t need a separate overloaded function for each type of array in this case.
You're right (I don't need it) but also wrong, most users demand "ease of use" and,
that is what it's all about (as Lost Zergling confirmed, in the post made).
Lost Zergling
Posts: 534
Joined: Dec 02, 2011 22:51
Location: France

Re: FreeBASIC 1.08 Development

Post by Lost Zergling »

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.
Lost Zergling
Posts: 534
Joined: Dec 02, 2011 22:51
Location: France

Re: FreeBASIC 1.08 Development

Post by Lost Zergling »

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.
paul doe
Moderator
Posts: 1730
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: FreeBASIC 1.08 Development

Post by paul doe »

coderJeff wrote:
Lost Zergling wrote:...(Dodicat, ..)...
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.
...
Of course we're offended! ;)

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
Would be super useful to have. Thanks in advance for your time, guys.
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC 1.08 Development

Post by coderJeff »

paul doe wrote:Of course we're offended! ;)
Dang it, of course you would jump on that one. ;)
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
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?

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.
paul doe
Moderator
Posts: 1730
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: FreeBASIC 1.08 Development

Post by paul doe »

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?
...
No. Have a look at this post:

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.
...
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?
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.

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.
...
Otherwise, seems straight forward to add a get-event-count and peek-event procedures.
Yes, I know. I don't usually ask for much, no? ;)
paul doe
Moderator
Posts: 1730
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: FreeBASIC 1.08 Development

Post by paul doe »

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 ;)
Iczer
Posts: 99
Joined: Jul 04, 2017 18:09

Re: FreeBASIC 1.08 Development

Post by Iczer »

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?
TeeEmCee
Posts: 375
Joined: Jul 22, 2006 0:54
Location: Auckland

Re: FreeBASIC 1.08 Development

Post by TeeEmCee »

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.
Post Reply