@flash

Depending on the datatypes class in question those attributes may be filled in when the object is opened.

Quote:

Datatypes is already fairly high level in that is doesn't care what image type you load as long as there is datatype for it.

Depending what you are doing with you images bitmap.image might be a solution for higher level image loading.

There is also IIntuition->ObtainBitMapSourceA and ObtainBitMapInstanceA

Your first snippet of code has

if ((Depth == MIN_DEPTH) || (Depth == MAX_DEPTH))

should that not be

if ((Depth >= MIN_DEPTH) || (Depth <= MAX_DEPTH))

Quote:

So did you set this to TRUE to make it work? Or the other way round?

As to saving with custom chunks, there is no way to do this with datatypes. You could possibly save to a temp file then append your custom chnks to that file (updating the FORM size to match). That way you'd only jave to worry about saving your custom data and you could let picture.datatype handle the image saving.

@kas1e

Memory issues maybe? Depending how files are unpacked largere files might need lots of memory,

Hmmph, just checking the code and I see that AK-JFIF has two very simlar functions for loading image data, one I fixed up the other still rejects anything but DTST_FILE and obviously the unfixed one is the one called most often (the fixed one handles grayscale)

Should be fixed in the 54.16 build

@tomsoniq

I'm not sure why DTST_MEMORY isn't working in your context, but I did explicitly fix this for the AK-Datatypes.

The *old* AK-Datatypes package did all reopen the file passed to them rather than using the passed file handle, and explicitly rejected anything but DTST_FILE, but this has now been fixed up and *should* be working.

I know that it working for AK-PNG as the gadgetry in the mediadeck.gadget is loaded via DTSTMEMORY and that *is* working...

Can you confirm which versions you are using?

Honestly that's bad program design even in a linux environment, but given that....

Quote:

Why not? Surely you already ran the new copy before exiting? You would need to run the new copy asynchronously ofcourse. (which it looks like you do) Unless there is some code that stops more than one copy from running at a time?

Depending on the program design you *might* be able to just reinitialise the program without restarting. There was case in blender where it forked of a new copy to handle the video player, when actually theer was no need, the existing copy just waited for the new one to complete and so I just called the video player code directly in the same context.

Quote:

If that is viable it would be more elegant, then you can send them a patch to fix their lazy code (Maybe not say that though

@Raziel

gcc will compile c++ if the file has a cpp extention but you will need to add -llibstdc++ to the link line.

@Futaura

That's cool. Saves abit of googling at lest

My server is working BTW

17.Programing:Projects/NetRexx> python test_ssl.py
OK 202


/C=UK/ST=United Kindom/CN=X1000/emailAddress=x1000@broad.ology.org.uk
/C=UK/ST=United Kindom/CN=X1000/emailAddress=x1000@broad.ology.org.uk
Wrote login

EXEC
AUTH: 9Pp59A3nJ2l30t9Qd9n3O0yXjCA26orX2Wow6tV1ijXgAmhPrPw31s7pX7I791bf
SIZE: 17
ADDRESS: WORKBENCH
RESULT: YES

WINDOW RAM:T OPEN

@billyfish

Yeah unfortunatly MVer finds all the broken datatypes with it's scanner which is pain in the initial upgrade

18.NGFSBoot:> version Classes:DataTypes/mpega.datatype full
mpega.datatype 54.10 (04/03/2021)
Copyright (c) 2016-2021 A-Eon Technology Limited

should work fine and is in the enhancer 2 distro

@thread

I think it's a little unfair to characterise the ak-datatypes as mature software due to the age of the original project as nothing much was done with it since the early 2000s

There was no suport forsome version 44 features like DTST_MEMORY and even DTST_RAM was unsupported even though that is trivial to support for an image class.

Work that has been done on them includes, upgrading the underlying libpng libjpeg libtiff to the latest (at time of build versions). I'm never convinced by version chasing with thse libraries, the formats have been stable for many years so unless you explictly need a bug fix or API feature there is little gain, *but* those libs were very out of date so might as well use the latest version to replace them.

Some pngs would not work due to mistakes in the png decoding API usage those are fixed, one or two could make it crash, due to testing the wrong pointer for NULL befor using a different one! (which was NULL and crashed)

Tiff support was also fixed up a bit, 1 colour tiffs (often used for Faxes) now work for example.

The datatypes now use the datatypes.library provided file handles and do not reopen there own files, thus fixing DTST_MEMORY in a single hit, DTDT_RAM is supported.

So a lot of work has been done, use them if you like but Olivers WarpDT collection will almost certainly out do them when it comes to decding peformance. Perhaps those who like to play at benchmarking can verify that....

Working on them did reveal so errors and wrong assumption in other components when for example AK-GIF promotes a multipalette gif to 24bit to cope with the colour range anim.gadget stopped working right WRT alpha, as it assumed that there is always a bitplane mask, but this isn't the case for 32bit images and the actual alpha channel must be extracted. That measn that animgadget now supports true alpha on any multiimage format that supports it. (anyone want to write an APNG picture datatype?)

@ktadd

There was originally a prefs file for each datatype, I merged those into one prefs file, there is an editor, didn't realise it hadn't been released. Your not missing much if your only using them for saving, and most of the options are classic with gfx card related anyway.

@Futaura

Thanks

Had to tweek the HOME path related bits and then the OpenSSL command stopped complaining and I got myself a cert and key

@ktadd

Quote:

When you say Warp do you mean the actuall WarpDT classes or the OS classes ? (which were contributed by the author of WarpDT but are not exactly the same as them).

I ask mainly for clarity but also as I don't recall the WarpDT ones having the save option

Quote:

Actually I can confirm this. This can't be related directly to the datatype classes thermselves though as they have no input on to which icon is saved.

Checking the code in MultiViewer I see that I have a specific function to put the icon that uses the basenam of the saving datatype to decide which icon to use. There was a reason for that but I forget what it was now. Perhaps because of a need to be 68k compatable I don't know.

I ought to be able to determine the icon from the saved file though... if you have the time could you submit a bug report against MultiViewer? (not akdatatypes the bug is defo Mvers)

Quote:

That's odd, both files are definetly PNGs? The might be small differences but the files are savee with libPNG in both cases as far as I know. Though I'm loath to go and compare the code!

@LiveForIt

Upstream mplayer has support for libva so should be able to reconfigured to use va.library

OpenSSL command line function ask for AmiSSL:openssl.cnf nut the is file does not exist.

I see fixed bug refering to the path to this file, ie so that it's correctly looked for at AmiSSL: not AmiSSL:/ but the file itself still does not exist.

Should this have been in the distro ? Can I drop in a generic one? From whence would the best template be found?

I want to create some local certs for a server program I'm working on, I did want to try TLS-PSK to avoid the difficulties of self signed certs but I realised that python doesn't support this and one of the potential clients was to be written in it.

@ktadd

AK-Datatypes has preference program.

If you have WarpDT I'd say you'd see little benefit in a switch to AK-Datatypes

@Spectre660

Quote:

THis is not exactly true, MultiViewer scans for *ALL* writable datatypes. Writable in context means that an empty object can be created with DTST_RAM and that the datatype supports DTST_WRITE. This means the datatype is suitable for file conversion allowing you to 'saveas' the new file type. Image and sound conversion is supported at present.

MultiViewer does this by scannng the classes available in Classes:Datatypes/ not by inspecting the list of installed Descriptors (in Devs:Datatypes) so you can use WarpDT for decoding and the OS datatypes or AK-Datatypes (or both) for writting.

@afxgroup

Use serial and higher debug level to see what elf library is doing in detail, I'm not sure exactly how high > 5 as a guess.

But actually elf.library does report unresolved symbols in a requester, what is more likely happening here is that the symbol was a NULL value and so is jumping to 0x00000000 when 'called'. This crashes and is why you get the unhelpul stack trace.

@TiredOfLife

Quote:

if you have old prfs saved for this try deleting them, old versions could save corrupt prefs to disk.

@TiredOfLife

Quote:

MVer uses no shared objects. You must have datatype installed that needs that sobj and have somehow removed the sobj but not the datatype