@VooDooQuote:
I did play it a LOT.. many nights/weeks/months lost back in the day :) It was when there wasn't a public release, but in beta stage... I think the public version got a bit too bloated and started to have more lag etc and I lost the best interest then.

Quote:
I guess it would be fun to try after a very long time, and setting a date/time would be the best shot nowadays.

Cubic IDE is pretty sweet for HTML too.

I've been using Magellan2 since 1998, so I don't remember if DOpus4 had configurable columns (or even per dir ones). And if the original doesn't, I also don't know if this feature has been added to newer open source ones... sorry.

I just have the Version column enabled for Libs:, C:, and such directories in DOpus... and then you can print the directory to a file with it too :)

@tekmageQuote:
I bet the actual bug happens on all setups, but it might be just pure luck if it becomes a visible/fatal issue. For example, if it trashes memory, it trashes it every time, but how it shows up depends on what contents it trashed. Maybe X5000 just happens to have some crucial data (drivers or so) on the affected area more likely than some other setup.

The bug I reported is reproducible on both WinUAE and X5000, but at least on WinUAE it's random and you'll have to try to trigger it a bit more before it actually crashes.

Quote:
Hollywood used to create these temp files if a 3rd party application was compiled to link plugins in the executable (this is why I didn't link plugins in my programs but included them in the progdir). Hollywood cleared these temp files when you quitted the program, but files were left there if you rebooted or crashed without quitting the program.

This has improved in Hollywood 9.0 and you can avoid temp files creation even when linking plugins. This is the changelog entry:
Quote:


Quote:
This looks a bit like the issue I have with mui.CreateObject with Hollywood on OS4, I don't know if the same function is used in Pixy. Anyway if you do dynamic runtime object creation on OS4, it seems to be a problem. This doesn't happen on any other platforms, but only on OS4.. so probably codesets.library or OS4's MUI implementation issue. Here's more information about my findings: link

@SkatemanQuote:
You probably remember wrong, because labeling to MOSSYS: will break things. MorphOS has the MOSSYS: assign which points to the SYS:MorphOS/ directory (MorphOS separates OS files from user files, and OS files reside in this assign). So, relabeling a drive would collide with it.

To avoid confusion I would change the device names of partitions manually to something more explanatory rather than letting OS name them as .1 etc. It's best to do this before or immediatelly after installing the OS, before any applications or configs start pointing with device names (which is a bad practise anyway, but some will do it anyway).


SYS: is always automatically assigned to the partition that system was booted from, so this works correctly always and no need to worry about it, and never try to change it in any case.

I probably would rename device names of MorphOS partitions, for example, to MDH0:, MDH1:, MDH2: etc.

By default the volume name for the system partition is Workbench: on AmigaOS and System: on MorphOS, so this doesn't clash and you can leave them on those names.

Other partitions like Work: can be relabeled as you wish. For example, MOSWork: would work :)

Well.. I combined this with another script I've made earlier, and here's the result: download

Features:
- Creates separate archives of directories from the source dir
- Adds directory icons into the archives if found
- Handles spaces in dir names
- Progress output on the shell
- If there were errors while archiving, it informs on which dirs it happened
- Can be used with DOpus ("Execute S:archive_dirs.script {s} {d}", output to window)

Usage:
- Execute archive_dirs.script SOURCE DEST
- Important: DEST must end to : or /



Hope it doesn't contain much bugs :)

@CagemanQuote:
Heh, yeah, but you got an ugly solution ;) Why to use 3rd party tools when you can do it in OS, and I also think that the solution you got doesn't work when there are spaces in directory names.

@Cageman

This can be done in the Shell quite easily, for example, like this:


This works if you CD into the corresponding dir first, and it creates archives in the same dir. But you could expand this to a better script which would take source and destination directories as arguments.

Hmm.. I don't remember I've changed anything related in the code, on purpose at least, but I'll try to check it... thanks for the report anyway.

@TSK

Quote:
Amiga filesystems (like SFS) have traditionally recommended to use block size of 512, which is basically good for small files and it wastes less space from the disk. But if you want to speed up handling of big files (like media files, archives, etc), then you might want to consider using bigger values... 1024 as a moderate compromise, 2048 for focusing more on the speed, or even 4096.

The bigger the value is, the more it consumes memory (buffers * blocksize bytes for each partition, 500 buffers with 1024 bs would consume 500kB of memory) and more you waste disk space (if you have a 20 bytes config file, it will take 4096 bytes from hd with 4096 bytes block size). So, I wouldn't recommend big block sizes for a boot partition, which contains thousands of small files.

In my opinion buffers have actually bigger impact on speed with many real world operations (like when deleting/scanning files) than the blocksize. So if you don't have that much memory, I would use small blocksize, but at least moderate amount of buffers. IIRC HDToolbox on 3.x had default value of 60 or 80, or something like that under 100, for buffers. IIRC SFS documentation recommended to use 128 buffers or so, and I've felt that it's quite good to have it over 100 or couple hundreds on classics. On NG I personally have raised buffers to 4096 on partitions I have lots of small files and I need to delete large amounts of files regularly, and 2048 on other partitions. It really shows in speed when you delete, for example, a system backup directory.

As said, buffers can be changed easily, but changing the block size will need a re-format of the partition. So it'd be more important to decide the block size before taking a new disk in use.

@Steady

Hmmm... why would disk space affect to memory consumption? Isn't it mostly Buffers * Blocksize in this case? On NG machines people might use buffers as hundreds or even thousands, because memory isn't an issue there, but on classics I'd stay somewhere like 128 or so. And keep blocksize as 512 if there isn't a good reason and memory to make it bigger.

Buffers can be set in HDToolbox or checked (or modified temporarily) by the AddBuffers command.

I once made a file size based counter ;) I don't know if there would be other way, but if you don't have the ForEach command (on OS3, for example), then you could hack it like this (modified it to do what you asked) :P



And that would output:

AHI's mixing routines are quite primitive and if you increase channels, playback quality decreases even if you aren't playing concurrent sounds.

I would advice to set channels as few as you still find comfortable in your use.

I've noticed that I don't use more than two programs that output audio at once pretty much ever, so I've set my channels to two. This still allows me to play something like video clips or test a game while listening music on the background, but keeping the quality quite good.

This is why AHI has the Music Unit, which overrides anything else playing to keep the quality at max in certain cases. But if you want to let everything (including the Music Unit) to play simultanously, you can forward the Music Unit to other unit, but especially in this case I would really keep amount of the channels low.

@AmigaSociety

Or you could use bigger image on PPaint, but then cut out a 256x192 sized brush and save that. Draw a frame for your image or something like that to make cutting easier.

@Skateman

Thanks!

@Skateman

Yes, or actually this has been the case for three years already. I tried to submit my first program for xmas 2017. At first the communication seemed to work and promises were made, but then it faded and it's been harder and harder to get replies, and now nothing for a long time. At one point it was explained that it got under other work, I think it was around the a.org rebuild, or so... This just seems to be too hard and I don't know if I even want them there anymore if offered... what would happen with updates etc? It's just better to look elsewhere now, even though the original idea was to support this ecosystem too and to get at least some compensation for my hard coding work.

@benny

Nope, I've given up with that now. I'll have to think other solutions at some point, but if someone really needs it, please contact me privately.

Ok, thanks. And yes, I posted it first time Jul 30th, and when it didn't appear, but someone else's news item was published after it, I tried to post it again few days later.. maybe a week ago now.