Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
152 user(s) are online (89 user(s) are browsing Forums)

Members: 1
Guests: 151

VooDoo, more...

Headlines

Forum Index


Board index » All Posts (broadblues)




Re: Enhancer Software v2.0 Released
Home away from home
Home away from home


@daveyw

Quote:

Stack trace:
    module CLASSES:datatypes/drawing.datatype at 0x7C2DB7B8 (section 0 @ 0x1794)


Go get the latest version of this from aminet. 53.7 ? Earlier versions are broken when it comes to testing them for DTM_WRITE by creating a temp object from DTST_RAM


Go to top


Re: ELF and shared objects headache
Home away from home
Home away from home


@afxgroup

Quote:

The symbol was _init

i've reworked all the code and now everything works correctly.
However print the symbol that is not found would help a lot..


But it can't can it, because the stack trace value 0x00000000 has no symbol.

Go to top


Re: ELF and shared objects headache
Home away from home
Home away from home


Also up the kernel debug level to 5 or more and see whats on serial.

Go to top


Re: ELF and shared objects headache
Home away from home
Home away from home


Also up the kernel debug level to 5 or more and see whats on serial.

Go to top


Re: ELF and shared objects headache
Home away from home
Home away from home


@afxgroup

only libc.so not libgcc.so or other compiler related one?

What if you add DebugPrintF() into the __shlib_call_constructors function? You can tell if it's really called (stack traces are not always accurate / complete) and what it calls

and unitialised constructor functions?

Go to top


Re: ELF and shared objects headache
Home away from home
Home away from home


@afxgroup

Is it possible that the shared object in question has an unititialised __shlib_call_constructors function pointer?


Go to top


Re: Porting to AmigaOS4 thread
Home away from home
Home away from home


@Raziel

Quote:

Should it work by renaming Seek() to lseek()?


No Seek() works on AmigaDOS filehandles (BPTR) and lseek() works on c library file descriptors, these are not interchangable.

lseek() and Seek() also are not drop in replacements.function wise.

Quote:


And is Seek() also obsolete in AmigaOS3?


No, it's obsolete in AmigaOS4 (and has been for a long time) because it doesn't support greater than signed int32 bit file sizes (up to 2Gb) ChangeFilePosition() supports int64

Quote:

..is it normal to get thrown back to such noob errors/questions all the time?
Is the SDK development moving faster than trying to catch up to and grab that moving train...or is it just me?


You have probably been ignoring or overrideing the deprectated function warnings and thus got caught out when the function name was changed to force devs to update their code.

Also there hasn't been SDK releases for ages so you got hit with a llot in one go,.when the dos sdk was updated in FE Update 2


Go to top


Re: Porting to AmigaOS4 thread
Home away from home
Home away from home


@Raziel



Seek() is a dos.library function and is deprecated in favour of ChangeFilePosition()



In the latest SDK the obsolete status has been made a a bit more forced
by changing the name to OBSOLETESeek()

If you really need Seek() and not lseek() or fseek() then include <dos/obsolete.h>

Go to top


Re: Third Mouse button
Home away from home
Home away from home


@Templario

Not sure what to suggest, there aren't normally settigs for third button as it should just work...

I've had an HP mouse that worked, but every model is different.

If you have MultiViewer then you should be able to test third button by loading a large image, setting the zoom to 1:1 and dragging with the middle mouse button.


Go to top


Re: Third Mouse button
Home away from home
Home away from home


@Templario

The third mouse button should 'just work' with the majority of USB mice.

AmigaOS has always had threebutoon mice LMB MMB and RMB even though ironically the class mice had only two buttons.

Not so many programs use it by default though. AWeb can be configured to use it for middle clicking on links.

Blender uses it big time.

What mouse do you have? How are you testing whether it works?

Go to top


Re: ILBM 8/24bit bitmap save function
Home away from home
Home away from home


@flash

ImageFX will save out 24bit ILBMs not so sure about inserting custom chunks though.

Likewise datatypes will too. MultiView(er) will save out 32bit ILBMs under OS4

Go to top


Re: ILBM 8/24bit bitmap save function
Home away from home
Home away from home


@NinjaCyborg

ILBM handles 24/32 images and has done for quite some time.


Go to top


Re: Amiga coder wanted for contract work
Home away from home
Home away from home


@NinjaCyborg

Perhaps I should have expended my point a little more, the baseline of most if not all systems are not object orientated, that has no bearing on whether you can do object orientated programming on it.

Go to top


Re: Amiga coder wanted for contract work
Home away from home
Home away from home


@NinjaCyborg

Quote:

Amiga API is of course not object oriented,


No, but neither is posix

Go to top


Re: Amiga coder wanted for contract work
Home away from home
Home away from home


@LiveForIt

Quote:

The thing is that C++ programs can use C libs, but C++ libs can’t be used by C programs.


A library is just a library, many libraries writte in C++ have C interfaces too.

Quote:

Anyway if you compile a amiga .library with C++, then AmigaOS does not find the symbols, ramlib does not support it.


That's not really the problem, you can easily make C stub functions to wrap a C++ library into an amiga.library in the same way as you do for a static library. ramiib does not use symbols to find libraries, nor is there any symbol searching done to find function offsets.

The problem is more creating a amiga style .library from C++ classes that can then be used from C++ . Because C++ uses 'mangled' function names to handle calls with varying numbers of arguments with varying argument types there is no easy one vector per function interface, This is where shared objects come into play.

Go to top


Re: OS4 Reaction programming question (beginner)
Home away from home
Home away from home


@trixie

Quote:

The difference between the two BOOPSI setter functions is that SetGadgetAttrs() also triggers the GM_RENDER method to update the gadget imagery, while SetAttrs() simply sets the new value without the redraw. Typically, you'll use SetGadgetAttrs() in a live window to get immediate visual response, and SetAttrs() before the window opens (or when it's iconified).


That's not actually true.

The difference is that SetGadgetAttrs() populates the GadgetInfo entry in the opSet message (OM_SET)

struct opSet
{
    
ULONG             MethodID;
    
struct TagItem    *ops_AttrList/* new attributes */
    
struct GadgetInfo *ops_GInfo;    /* always there for gadgets,
                                      * when SetGadgetAttrs() is used,
                                      * but will be NULL for OM_NEW
                                      */
};


In reponse to the values of some attributes some but not all gadgets may trigger a GM_RENDER . A very rough rule of thumb is that simple gadgets will render straight away, more complex ones may not. (but might still perform setup based on the GadgetInfo)

@Jabirulo

The difference with RefreshSetGadgetAttrs() is that it will *always* force a render of the gadget if SetGadgetAttrs() would have returned a non zero value.

It's equivelent of

if(SetGadgetAttrs()) RefreshGList() .

[edit]markdown and adding that the refresh only occurs if SetGadgetAttrs() would return non zero

Go to top


Re: OS4 Reaction programming question (beginner)
Home away from home
Home away from home


@NinjaCyborg

window.class objects do not need to be destroyed or reinsitialised from scrtach when closing the (workbench) screen. they can also jump from screen to screem

In fact the window.class object will send a WMHI_ICONIFY and WMHI_UNICONIFY message to the application, which should then close and reopen the window in response. Or a WMHI_JUMPSCREEN

This is how AmigaOS4 avoids (or at least reduces the frequency of) the annoying can't close workbench screen messages when change prefs settings. Most apps will close automatically.

Some restup may be required if your gadgets needed certain pen colours or other screen specific attributes as the previous data will now be invalid.

SetGadgetAttrs() needs the window pointer and very rarely the requester pointer ( very few modern amiga programs use requesters in the original sense, most modern requesters are actually windows) to provide rendering context to the gadgets. These gadgets are often but need not be associated with a window.class object.


Go to top


Re: OS4 Reaction programming question (beginner)
Home away from home
Home away from home


It's worth noting that if the window has not yet been opened then the window argument should be NULL too.


Go to top


Re: gcc 9 and 10
Home away from home
Home away from home


@Raziel

RE make GCC and STACK cookies.

These tools do not need very high stacks when compiling simpler projects, but can do when compiling very complex porjects. This means there is no reasonable stack cookie.

My shell stack is typically set to 200K and for nearly everything that's enough. But IIRC I needed more for blender (2Mb for safety IIRC) but setting a stack cookie so high would be very wasteful for most projects.


The thing is make is akind of programming language in a sense so stack usage will depend on complexity of program.

Since th system doesn't have autoextending stacks and these are develeopement tools you just have to think like develeoper and make reasonable assesments of your needed stack.

This also goes for langauges like perl and python, even AWeb can burn through it's stack if you design an eveil enough nested table web page ( was an old test we used to "fuzz" it).

STACK cookies are useful in predicatable user applications, but not a total solution.


Go to top


Re: python3.8 AmigaOS4 in development
Home away from home
Home away from home


@NinjaCyborg

Quote:

Since SObjs aren't shared why even bother to use instead os static link? Or write wrappers to turn them into proper .library ?


For languages like python, perl and guile they enable you to do run time loading of modules and will work in exactly the way that those languages expect (most significant being that symbols are visible to all other plugins / modules)

Back with my first very early port of perl to OS4 we had no shared objacts yet and I created a simple library based plugin system. I did a port of perl SDL but ti didn't work properly as when I created game like Bubbles it couldn't see the SDL lib so I had to compile it into the submodule. That doesn't happen with proper dynamicly linked plugins.

For other apps, yes I somewhat agree, blender is dynamicaly linked for the python parts but also has library based plugins and many libs are builtin too.

Not every library converts to an amiga style shared library as well I you might like, they have a habbit of chnage APIs and also sharing data, C++ support is also more tricky.

Go to top



TopTop
« 1 ... 4 5 6 (7) 8 9 10 ... 114 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project