Frameworks and module dependencies

Started by SToS, November 22, 2024, 03:55:45

Previous topic - Next topic

SToS

I've tried to find an easy/lazy way to find them but....

When using a framework, all default module dependencies are ignored/erased and you have to add them as needed depending on what you use, right?

So...

Is there a way to know the dependencies of each module easily/lazily as the build errors are pretty useless and the runtime errors usually just give a null pointer exception?

For example, I recently used the SDL.gl2sdlmax2d framework and found I couldn't use TPixmap and trying to fathom out the module dependencies was tedious and a failure.  You'd think it was just BRL.Pixmap, but no!

Anyhow to cut a long story short after trudging the module code and adding dependencies I still was unable to resolve the dependencies needed.

So my initial question stands and is there a secret trick? Go on you can tell me, I won't tell another sole, honest! ;D

Baggey

Sadly this is the major let down with BlitzmaxNG.

It's gone open source. People add stuff and don't document what they've done properly. So how does one learn it? Let alone use it?

Having said that, I still go with it because of it's Sheer speed and the fact it being a Basic language that is.

Blitz needs better documentation and Examples to use. 

Loving your Examples by the way  ;D
Running a PC that just Aint fast enough!? i7 4Ghz Quad core 32GB ram  2x1TB SSD and NVIDIA Quadro K1200 on Acer 24" . DID Technology stop! Or have we been assimulated!

Windows10, Parrot OS, Raspberry Pi Black Edition! , ZX Spectrum 48k, C64, Enterprise 128K, The SID chip. Im Misunderstood!

Midimaster

#2
For finding the dependencies we would need a Dependency Browser tool.

This has nothing to do with a good documentation. A documentation cannot find dependencies.

This Dependency Browser would need to scan the bmx-files of your project and scan all commands and function calls you use. Then find out their source module and add this module to a list. But also those source modules can have dependencies (Import... Include...) to further modules. So the search goes deeper and deeper.

Some years ago somebody wrote something like that.


On the other side: Linking simply all modules to a EXE produces a file of 6MB for a "Hello World". 15 years ago this would have been a big app size, today is it closed to "nothing".

I simply always compile without any "Framework" considerations.


 
 

...back from North Pole.

Derron

#3
Using the framework command of course benefits from "experience". Once you "know your modules", then you often blindly type in all the imports you need.

So you import "sdl.gl2sdlmax2d". This imports, aside of opengl/opengles, also "brl.max2d" (the "2d renderer", and "sdl.sdlgraphics" -- to connect to the SDL-graphics-context-handler-thingy).

A TPixmap is just "pixel data", it is not a gpu texture or so (so is independent from backends like OpenGL, DirectX, ...).

BUT ... as TImage (defined inside of brl.max2d) bases on TPixmap, it of course also imports it (max2d.mod/driver.bmx -> import brl.pixmap).


- thus means, if you import sdl.gl2sdlmax2d you import also brl.max2d and thus you also import brl.pixmap automatically. You should not receive any error about TPixmaps.


The issue about the null pointers is more in the "factory" approach we see a lot in the modules.
So there is some "abstract" type with no proper implementation (eg a TImage).
If you just imported brl.max2d but no "backend" (like your sdl.gl2sdlmax2d) then the factory could not provide you with a "backend specific" TImage-variant. The backend specific part is responsible for "GLImage"-textures, or DirectX-textures creation and the likes.
So in that case you could see null pointers.

Some code is prepared to error out more "helpful" (eg. giving you the hint to import a specific random-number-generator, or system drivers ...). Some code is not prepared to do so and gives you less helpful null pointer segfaults...

Edit: so this does not work for you ?
SuperStrict
Framework SDL.gl2sdlmax2d
Import Brl.StandardIO

Local p:TPixmap = CreatePixmap(100, 100, PF_RGBA8888)
Print "w="+p.width+" h="+p.height


bye
Ron

SToS

Quote from: Derron on November 22, 2024, 12:33:25Edit: so this does not work for you ?
SuperStrict
Framework SDL.gl2sdlmax2d
Import Brl.StandardIO

Local p:TPixmap = CreatePixmap(100, 100, PF_RGBA8888)
Print "w="+p.width+" h="+p.height
Yes it works.
But when I was learning to fathom out the dependencies I was trying to load a BMP file using LoadPixmap and without knowing that BRL.BmpLoader is a dependency I got the null exception.

Afterall when the docs only state:

Function LoadPixmap:TPixmap(url:Object)

Returns: A pixmap object
Description: Load a pixmap

And does not at least state it NEEDS a loader for the type file format used then ???

Hence maybe it should say this depends on one of the load modules to be imported.

Derron

#5
You are right about the bitmap loader. This is another "factory" example.
Same happens for audio files etc. If you do not import a "loader" it should possibly not simply "segfault" but give you a hint ("Maybe you forgot to import a loader supporting the file format" or so). Will raise an issue.

Thanks for pointing that out.

Edit: hmm, I am not sure if we should really spit out a "hint". Other stuff "throws" an error if you missed to install a required module (eg brl.system ...)
But for images/audio it is not that the core knows what a "file.bmp" is. It simply asks all registered loaders to load that file until one succeeds (so first come, first served).
If we now gave users of "our program" the option to provide an image, and you try to load it ... without having a valid loader - it would throw an error to the user (about your code not importing something during compilation). This is not the best solution.

A TPixmap can be created "on the fly", there is no need to have "loader" at all. So raising an error there is also not an option.
I consider throwing an error if you try to load a pixmap without _any_ loader imported at all. But even this means you will spit out an error to the user of your program during runtime and not during compilation of the program.

So to sum up: TAudio(Sample) and TPixmap are not requiring any file format "knowledge", so just by using a TPixmap somewhere does not require a BMP/PNG/...loader. And thus simply importing brl.pixmap without also importing a loader should raise/throw an error.

And I am not sure, if the program should taint the "stdout" with warnings when loading (and failing) unsupported image/audio formats. I know libpng does (about the icc profiles...) but yeah - not sure if we should do to. Maybe via "debuglog" (so only spit out in debug builds)?


bye
Ron