Info-ZIP unzip included in sources and/or HardDisc4 image

If someone¹ could look at tidying and submitting Jeffrey’s ARMv7-safe ‘unzip’ source patches (referred to on his website ) then would it be possible to include it (and ‘zip’ too) within ROOL downloads?

• Can I use the Zip or UnZip source code or executables in my commercial product?
• Yes. See our new(er) open-source, BSD-style license for details.

¹ Jeffrey – if your source patches are understandable enough, perhaps someone could kindly volunteer to do this on your behalf.

Jeffrey – if your source patches are understandable enough…

They were understandable the last time I checked ;)

To be honest I’m not sure why I haven’t sent off the patches yet. I don’t think there’s anything that needs fixing or testing, so it must just be a case of forgetfulness/procrastination. If there’s nothing big which needs doing then I might be able to send the patches off tonight.

...forgetfulness/procrastination…

Or the small matter of doing so many other RISC OS things while trying to maintain your life and sanity at the same time.

...might be able to send the patches off…

And do you know if the licence conditions will be compatible for including the utility on this site? (Or is that for ROOL ppl to comment on?) Thanks.

And do you know if the licence conditions will be compatible for including the utility on this site? (Or is that for ROOL ppl to comment on?) Thanks.

Yes, the licence conditions are fine.

Also, zip/unzip strike me as things that might be better suited to being hosted on riscos.info rather than the ROOL site. They can both be easily built using the GCCSDK autobuilder (once my patches have gone through!), and there’s already a copy of zip available for download (although I don’t think it’s using the latest sources).

So unless you’ve got a good reason why unzip should be hosted on the ROOL site, I think I’ll just submit my patches to infozip and then send the GCC team some updated autobuilder recipes (I was planning on testing unzip using the autobuilder anyway, so it shouldn’t take too long to sort out both of them).

Ah, of course, there’s the most obvious reason for wanting unzip on the ROOL site – there needs to be at least one uncompressed copy available to download from somewhere, otherwise people without any copies of existing (ARMv7-safe) unzip tools won’t be able to unzip anything.

So yes, it would make sense to have a copy of unzip available to download from the ROOL site somewhere (either standalone or as part of the harddisc4 image?). But I’m also planning on sending the autobuilder scripts to the GCC team too :)

...at least one uncompressed copy available to download from somewhere…

Yes. I don’t see any real problem with the fact that people have to download from your site. However, for users new to RISC OS, it’s potentially an additional (although admittedly small) complication. “Here, why not come and try out RISC OS… oh and by the way, you’ll need to go elsewhere to execute even a commonplace task like unzipping…”

Even when ARMv7 SparkPlug becomes available (and assuming it’s a self-extracting version) I still think it would be good to include ‘unzip’ on the ROOL site, both for completeness and to slightly reduce the reasons for marginalising RISC OS as purely a “hobby OS” where basic expectations are unfulfilled.

And IMHO we have a similar case for egrep in that new users (developers?) need to go elsewhere before they can build the sources. But perhaps that should be another wishlist thread.

And IMHO we have a similar case for egrep in that new users (developers?) need to go elsewhere before they can build the sources. But perhaps that should be another wishlist thread.

No need for a wishlist thread if there’s already a bug report about it.

I’m not quite sure what testing process ROOL go through before updating any of the build tools – a while ago I checked in a fix for a bug in srcbuild, but left the decision of when to update the binary down to ROOL, in case they wanted to check I hadn’t broken anything. So if you’re looking for something to do then you could try dropping them an email, asking about when updated versions of srcbuild, egrep and the other tools are to be expected (although egrep is the only tool that’s currently known to crash on ARMv7, the others could probably do with recompiling just to make sure), or to make a quick trip to the forums/wiki to clarify who is/isn’t allowed to update the build tools (because if it’s just a case of checking in updated srcbuild & egrep binaries without doing excessive amounts of testing then that’s something I can easily do).

Hi guys. We recently pulled together a whole slew of changes to the C tools but there are still some extra bits – including the stuff Jeffrey mentions, that I’d like to add. Notably, we’ve made a whole pile of fixes to the C compiler which address all the known bugs and a few we didn’t know about until we started fixing stuff. Keep an eye on our news pages for a release soon.

Notably, we’ve made a whole pile of fixes to the C compiler which address all the known bugs

Including this, this, and this ? (since those aren’t marked as fixed yet)

Keep an eye on our news pages for a release soon.

Will do! Can you post a changelog this time as well? It’ll be good for people to know how much has changed between each release.

We will certainly be posting a change log.

As for the issues you’ve raised:

1. We need to look into it to see if it is indeed a bug
2. We are aware of and have plans to address
3. Will be retested on our latest version of the tools – it may well be fixed

OK, cheers!

Number 3 is fixed in our latest version of the tools. I’ll make the announcement and release notes soon.

Why is it that I can’t get any unzip tool to work? Setting infozip/bin to &FFC results in “internal error: branch through zero” and unzip/bin gives “no memory in that area”. Could it be that Windows corrupts the file on download? It always suggests that *.bin files are Amstrad CPC ones.

Setting infozip/bin to &FFC results in “internal error: branch through zero” and unzip/bin gives “no memory in that area”.

Check this post (I’ll put a note now in the ‘once you’re up and running’ section on the getting started page )

Cheers for that! Still have problems with infozip which seem to be related to the screen resolution used but Jeffrey’s unzip tool works fine.

Have you also put ‘unzip’ into <Boot$Path>Library, which will simplify things?

I think infozip is likely to be a file of type &FF8 (Absolute) rather than &FFC (Utility).

Could the default Next slot size be changed from 640KB to say 4MB? That would avoid the sort of problems Patric had with infozip.

640KB was presumably chosen back when the Archimedes had 1MB of memory!

We could/should also integrate Absolutely’s functionality with the OS, since that fixes most instances of problems caused by the wimpslot being too small.

...recently pulled together a whole slew of changes to the C tools… whole pile of fixes to the C compiler…

As the tools are a commercial product, perhaps Castle are paying for this work to be done – presumably they still have a small income stream from the sales which ROOL manages for them. And if ROOL is being contracted to do the work, then will that income be available for spending on the RISC OS source or other costs such as licensing ?

Fantastic! I just wrote a long post to answer your question but my session expired and it’s all been lost.

So the short answer is:

• The tools are a commercial product
• ROOL own the tools – we took them over from Castle a couple of years ago
• The cash goes towards the ROOL activities – like attending shows
• We don’t pay ourselves for the work we do (even on the tools)
• They don’t make a great deal of money anyway

...long post… session expired…

You could always try applying Terje’s page refreshing technique to long forum posts. Thanks very much for going to the trouble anyway.

ROOL own the tools

My misunderstanding – I’d thought they were still owned by Castle. Thanks for the clarification.

Since you are talking with C compiler bugs, I just trigerred a compiler bug in old CC 5.61. So I was wondering if it was a known bug or if I should report it with the sources.

for (i = 0; i < player->no_of_requests; i++)
{
  memcpy( player->dma_drain[i].address
        , player->dma_source[i].address
        , player->dma_source[i].size
        );
}

R0 = load(player address + offset of dma_drain in player + sizeof(dma_transfer_t) * i + 0)
R1 = load(player address + offset of dma_source in player + sizeof(dma_transfer_t) * i + 0)
R2 = load(player address + offset of dma_source in player + sizeof(dma_transfer_t) * i + 4)

tmp = player address + sizeof(dma_transfer_t) * i
R0 = load(tmp + offset of dma_drain in player + 0)
R1 = load(tmp + offset of dma_source in player + 0)
R2 = load(tmp + offset of dma_source in player + 4)

However this becomes (R4 = player address, R5 = i, sizeof(dma_transfer_t) = 8):

ADD   R0,R4,R5,LSL #3
ADD   R0,R0,#&0800
ADD   R0,R0,#&01A4
LDMIA R0!,{R1,R2}
ADD   R0,R0,#&8000
SUB   R0,R0,#&0308
LDR   R0,[R0,#&CF8]

The change below corrects the behaviour:

for (i = 0; i < player->no_of_requests; i++)
{
  dma_transfer_t psource = &player->dma_source[i];

  memcpy( player->dma_drain[i].address
        , psource->address
        , psource->size
        );
}

ADD   R0,R4,R5,LSL #3
ADD   R1,R0,#&0800
ADD   R1,R1,#&01A4
ADD   R0,R0,#&8000
LDR   R2,[R1,#4]
LDR   R0,[R0,#&6A4]
LDR   R1,[R1,#0]

Hi. This one is new to us. Can you try building the problem code with #pragma no_optimise_cse so that we can narrow-down where the bug lies?

The code looks correct when use the #pragma no_optimise_cse.

I have opened ticket 258 with a minimal code required to produce the problem. The formatting is all wrong, so I presume that the ticketing system doesn’t use Texile.