FreeBASIC 1.08 Development

For other topics related to the FreeBASIC project or its community.
MrSwiss
Posts: 3634
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: FreeBASIC 1.08 Development

Postby MrSwiss » Nov 10, 2019 22:35

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

Re: FreeBASIC 1.08 Development

Postby Lost Zergling » Nov 10, 2019 22:50

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

Postby Juergen Kuehlwein » Nov 11, 2019 9:53

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: 3634
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: FreeBASIC 1.08 Development

Postby MrSwiss » Nov 11, 2019 15:17

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

Postby Juergen Kuehlwein » Nov 11, 2019 16:41

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
Posts: 9986
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: FreeBASIC 1.08 Development

Postby fxm » Nov 11, 2019 17:01

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

Re: FreeBASIC 1.08 Development

Postby MrSwiss » Nov 11, 2019 17:08

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: 335
Joined: Dec 02, 2011 22:51
Location: France

Re: FreeBASIC 1.08 Development

Postby Lost Zergling » Nov 11, 2019 18:13

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: 335
Joined: Dec 02, 2011 22:51
Location: France

Re: FreeBASIC 1.08 Development

Postby Lost Zergling » Nov 12, 2019 10:10

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
Posts: 1315
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: FreeBASIC 1.08 Development

Postby paul doe » Nov 28, 2019 16:02

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: 3342
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC 1.08 Development

Postby coderJeff » Nov 30, 2019 14:02

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
Posts: 1315
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: FreeBASIC 1.08 Development

Postby paul doe » Nov 30, 2019 15:19

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:

https://www.freebasic.net/forum/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
Posts: 1315
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: FreeBASIC 1.08 Development

Postby paul doe » Dec 05, 2019 21:30

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: 60
Joined: Jul 04, 2017 18:09

Re: FreeBASIC 1.08 Development

Postby Iczer » Dec 20, 2019 18:01

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: 300
Joined: Jul 22, 2006 0:54
Location: Auckland

Re: FreeBASIC 1.08 Development

Postby TeeEmCee » Dec 23, 2019 4:25

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.

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 1 guest