Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
The current user archive has some CLI commands, which are not in the source tree. They are:
What's your take on this?
I think ArcDirList,Move were left there when we didn't have xadopus, but I think we need to remove them now. I don't need CDOpus,DOpusFuncs and I don't think we need assembler speedups for modern computers. However, removing them at this point isn't essential. I don't know about DopusPack_Main.
Personally, I don't think we should be including anything we don't have sources for and can't fix if something goes wrong. I think kasle has a different view but we'll see what he says.
Of course, it's not a high priority to remove them. I just wanted to sort this out, because non-m68k flavors of AROS have no means of running 68k executables besides UAE, and it might confuse users to have a bunch of 68k commands included. I'll look up the original AREXX scripts they are based on, because they provide some very useful commands to the CLI.
We can easily add a second base archive for AROS which doesn't have the 68k commands. That's one reason I moved the base archive to a directory. One base archive may not suit all platforms. If you let me know what you want removed, I'll add a base archive for AROS and modify the archive makefile code to use it.
Imho "ArcDirList, Move" can just be deleted from all, as we on xadmaster.
"CDOpus, DOpusFuncs" as far as i remember are in use by ppls and pretty good to have. We even have Help/DopusFuncs.guide and Help/CDOpus.guide where a lot about them and it looks like good to have stuff. Will be of course pretty cool to convert them to C and include to our repo as well.
And as for DOpusPack_Main, imho will be good to have sources of that compression.module, just in case. But if not, then not big deal and we can remove it for now.
In other words, imho i see only needs for "CDOpus, DOpusFuncs". Is anyone up for task to rewrite them from assembler to C , or just re-implement from scratch ?
Then we can just delete another ones from base archive, and include only CDOpus and DOpusFuncs (+ viewfont, dopusrt and loaddb)
Sources of DopusFuncs and CDOpus are there if anyone will be in interest http://aminet.net/package/biz/dopus/D51_NUSource.lha
It might be easier to start with the original AREXX scripts these commands are based on. The the asm programs use the same AREXX commands internally.
Which ARexx scripts in that archive correspond to assembler CDOpus & DOpusFuncs?? If the assembler versions just call Dopus5 ARexx commands there's no point in converting a bunch of assembler stuff. We can just use the ARexx versions.
EDIT: It looks like the ARexx scripts are already in the Dopus5 ARexx directory. It looks like all we need to do remove the commands from the Dopus5/C directory.
Unless you want to keep those 68k commands, I will remove them from the base archive (archive.lha).
CDOpus: CDO and OCD
DOpusFuncs: DirToDest, ParentToDest, WinCopy, and WinSwap
edit: Oops, I didn't read the end of your post. If the scripts are already there, then the 68k commands can go away.
My port of Dopus5RT binary totally broken. It needs to be reported from scratch from original. The binary uses in some parts, and its necessary to have it working in native form. Easy test to see if it start to works, its just run it from shell like "dopus5rt system:utilities/clock" and "clock" should runs. Then same as there should be no crash if we just run dopus5rt without arguments just as it.
I contacted Leo Davidson, and he sent me the source of compression.module. As XAD is for extraction only, this could still be useful with all the crunchers out there. I uploaded the sources here:
Will it give us ability to do so:
-- user dbl-click on archive, and it open a lister with content via xadopus.module
-- then user grab any file from any other lister, and drag/copy it to lister with archive content, and archive repacks
Definitely not, XAD is for extraction only.
I know that XAD for extraction only, i mean by that questions what the real benefits of having compression.module in end. I currently can pack any archives by command line tools with no probs, as well as our default config have lha add, lzx add in the user menu , etc. and users can add any other ones, just they need to have necessary binaries.
Do you think about just replacing xadopus.module with compress.module ?
I tried to found any documentation for that module, and all i found is that there is 3 functions : crunchprefs, crunch and decrunch.
There is one major benefit of using a module opposed to external commands
It works seamlessly inside the enviroment
you can have nice progress bars
you can probably dig inside one archive as a folder and do a job in there as if it was a normal folder (in other words work inside a tree structure)
Anybody keen to write a samba module ? for network neighbourhood type of thing similar to ftp module
The benefit is the XPK integration. I don't have any plans with it, just uploaded the sources.