23-Apr-2024 20:15 GMT.		 UNDER CONSTRUCTION
Anonymous, there are 34 items in your selection
[Files] VIM 6.2.421 (MorphOS) releasedANN.lu
Posted on 31-Mar-2004 12:12 GMT by oGALAXYo34 comments
View flat
View list
This version of VIM adds a bunch of new overall patches provided by Bram Moolenar the author and maintainer of VIM as well contains a bunch of improvements of my own patches for MorphOS (a lot of simplifications this time).

The simplifications are:

- Proper tmpname handling through libnix. Instead of hacking in some own routines I now defined -DUSE_TMPNAM. Libnix understands this function which I wasn't aware of previously.
- The MorphOS libnix version doesn't have fdtofh and previous versions of my patches simply ignored calling this by simply if def'ing that stuff out. The missing fdtofh function has been tweaked in the VIM code now (it was just 3 lines anyways).
- The overall MorphOS patch is reduced to the necessary things only. Which is the Makefile, Shell syntaxcolor output and missing fdtofh routine. Everything else stays as the Amiga version of VIM.

Of course you can find VIM on my Homepage. VIM for MorphOS is also listed on the official VIM Homepage.

greetings,

oGALAXYo

VIM 6.2.421 (MorphOS) released : Comment 1 of 34ANN.lu
Posted by Anonymous on 31-Mar-2004 10:27 GMT
Ah well, for someone complaining ine should use the given standarts, (eg Mui) you are using a very uncommon packformat for Amiga/Morphos World.
I won`t care, I have xarc installed, but then after unzipping, there would be a 4110 Gigabyte big tar file left?! Whow.. that is compressed...
VIM 6.2.421 (MorphOS) released : Comment 2 of 34ANN.lu
Posted by Anonymous on 31-Mar-2004 10:29 GMT
nad btw.. where is Mui Vim? ;D
VIM 6.2.421 (MorphOS) released : Comment 3 of 34ANN.lu
Posted by oGALAXYo on 31-Mar-2004 10:33 GMT
In reply to Comment 1 (Anonymous):
I feel sorry if you have problems entering:

'gunzip vim-6.2.241.tar.gz' and 'tar xfv vim-6.2.241.tar'

In the MorphOS shell. Even 'tar xfzv vim-6.2.241.tar.gz' should work. You find these files in the GeekGadgets package for your development stuff. In worst case Aminet is your friend.
VIM 6.2.421 (MorphOS) released : Comment 4 of 34ANN.lu
Posted by oGALAXYo on 31-Mar-2004 11:16 GMT
Colors to be used in the MorphOS Shell. When using VIM in default colored MorphOS shell they look kinda useless. So you need to change the MorphOS Shell's default appearance to a more or less ANSI like appearance as known under Linux etc. I don't know if I hit the values 100% correctly but these do best for me and closely match the ones I use under Linux. To change to other colorschemes enter: 'colorscheme default' or 'colorscheme darkelf' etc. the same way you do on Linux.

;--- start s:color-sequence
echo "*E[0;000;000;000V" ; background
echo "*E[1;255;255;255V" ; foreground
echo "*E[2;000;255;000V" ; datatypes
echo "*E[3;200;200;000V" ; return
echo "*E[4;000;000;200V" ; preprocessor
echo "*E[5;200;000;200V" ; defines
echo "*E[6;000;200;000V" ; comments
echo "*E[7;255;255;255V" ; conditions
;--- end s:color-sequence

greetings,

oGALAXYo
VIM 6.2.421 (MorphOS) released : Comment 5 of 34ANN.lu
Posted by oGALAXYo on 31-Mar-2004 12:17 GMT
I have just updated the Screenshots of VIM again. Better coloring and better Syntax Highlighting. You see an ANSI colored MorphOS shell using the elflord colorscheme for VIM. The Screenshots can be found on my VIM page.

greetings,

oGALAXYo
VIM 6.2.421 (MorphOS) released : Comment 6 of 34ANN.lu
Posted by Kolbjørn Barmen on 31-Mar-2004 13:04 GMT
In reply to Comment 5 (oGALAXYo):
Ah, finally it looks "normal" :)
VIM 6.2.421 (MorphOS) released : Comment 7 of 34ANN.lu
Posted by Crumb // AAT on 31-Mar-2004 14:04 GMT
It may be a good idea to use LHA... it's the standard in the amiga world. And it would be a good idea to upload it with the sources to aminet
VIM 6.2.421 (MorphOS) released : Comment 8 of 34ANN.lu
Posted by oGALAXYo on 31-Mar-2004 14:17 GMT
In reply to Comment 7 (Crumb // AAT):
I am aware of what archivers are used in the Amiga world. I've been participating to it for nearly one decade before I magicly disappeared for Lunix. The reason why I have chosen TAR is simple - I do all packaging on my Lunix machine and updating my Webpage on my Lunix machine as well. I simply got used to using TAR. Not to mention that the required Runtime package is packaged in TAR as well (as found on ftp.vim.org).

And for Aminet. I don't think Aminet is the right place for files specially when they are a matter of being changed very often. The correct way of doing these releases is:

a) Working with the original maintainer and close with the main Source as possible to not do code fragmentation (as the MorphOS stuff made it into the ARCH system some mins ago).
b) When releasing something then release it on the Webpage of the person who does maintain it.

Putting all this on Aminet will only end in a big clusterfuck.
VIM 6.2.421 (MorphOS) released : Comment 9 of 34ANN.lu
Posted by Crumb // AAT on 31-Mar-2004 14:39 GMT
In reply to Comment 8 (oGALAXYo):
LHA is also available for linux.

The idea of having MOS support in the VIM official tree isn't bad but stable version should be released to aminet, simply because not everyone is linux-minded and needs to have the absolutely latest beta of a program.

What happens with programs not uploaded to aminet is that:
-the author of the program gets tired doesn't update the program and sooner or later the web page dissapears and the program will never be found again.
-in open source projects usually the person that maintains the port gets tired, doesn't update it and all the platform support is dropped from the main tree by the project admin in the next version.

The result is that the program no longer is available. Most of people don't care about having the latest version. Uploading a stable version would be enough. And aminet is far more popular than any author's webpage. People who doesn't know that there's a MOS VIM port may see it. Not everyone spends his time browsing trough news pages.

Why don't I upload the files instead of complaining? I only have internet at work and all the ports are closed (even e-mail). I only have web access.
VIM 6.2.421 (MorphOS) released : Comment 10 of 34ANN.lu
Posted by Gregg on 31-Mar-2004 14:41 GMT
In reply to Comment 8 (oGALAXYo):
First, I'd like to make it clear I appreciate your contributions; the following is not meant to be constructive, not critical :

1) The Aminet upload "Replaces:" keyword seems to work quite nicely; this can be used to help avoid version problems - just a suggestion.

Aminet Uploading Instructions

2) With regards to the archiving tool, consider the trade-off : If lha, one person (you) is inconvenienced a little, all downloaders already familiar with lha (surely a large majority) are not inconvenienced. If tgz, no inconvenience for you, a little inconvenience for every single downloader (probably the majority) who isn't familiar with, or doesn't even have, untgz tools.

In the grand scheme of things, lha seems less work.

Regards,

Gregg
VIM 6.2.421 (MorphOS) released : Comment 11 of 34ANN.lu
Posted by Gregg on 31-Mar-2004 14:42 GMT
In reply to Comment 10 (Gregg):
First, I'd like to make it clear I appreciate your contributions; the following is not meant to be constructive, not critical :

Bah! NOT the first not, please.

Gregg
VIM 6.2.421 (MorphOS) released : Comment 12 of 34ANN.lu
Posted by the man in the shadows on 31-Mar-2004 15:13 GMT
In reply to Comment 10 (Gregg):
I've got to agree with you gregg. I mean, I use tarballing for most of my archives as well but when it comes to working on the Amiga, it's LHA or LZX, any other format is converted accordingly (except ADF and DMS that is). I've got scripts I wrote to help convert archives, unfortunately they don't work 100% of the time. When you stop to think about it, tarball is for Linux, Zip is for Windows, StuffIT is for Mac, and LHA is for Amiga. I prefer LZX over LHA though, but the Aminet is mostly LHA so I'll live with it.
VIM 6.2.421 (MorphOS) released : Comment 13 of 34ANN.lu
Posted by Nicolas Sallin on 31-Mar-2004 15:19 GMT
Upload it on Aminet.
VIM 6.2.421 (MorphOS) released : Comment 14 of 34ANN.lu
Posted by Kolbjørn Barmen on 31-Mar-2004 16:05 GMT
In reply to Comment 8 (oGALAXYo):
You use a Lunix-machine for archiving? Amazing what those C64s can do! :)
VIM 6.2.421 (MorphOS) released : Comment 15 of 34ANN.lu
Posted by Kolbjørn Barmen on 31-Mar-2004 16:09 GMT
In reply to Comment 8 (oGALAXYo):
Anyways... tar on amiga filesystems is broken as it doesnt grasp the amiga filesystem protection bits properly.
VIM 6.2.421 (MorphOS) released : Comment 16 of 34ANN.lu
Posted by Anonymous on 31-Mar-2004 17:02 GMT
In reply to Comment 15 (Kolbjørn Barmen):
> Anyways... tar on amiga filesystems is broken as it doesnt grasp the amiga filesystem protection bits properly.

Another problem is that it attempts to rebuild softlinks which do not work with all Amigas (or rather emulated Amigas). Software for Amigas should be packed with lha/lzx and have an installation scipt, period.
VIM 6.2.421 (MorphOS) released : Comment 17 of 34ANN.lu
Posted by oGALAXYo on 31-Mar-2004 17:25 GMT
In reply to Comment 16 (Anonymous):
> Software for Amigas should be packed with lha/lzx and have an
> installation scipt, period.

I welcome you to volunteer for this job. If you want installer, then please write a script and sent it to me. I will be happy to include it the next time I release VIM.

I am a bit tired about all these whiners and complainers. The entire Amiga package of VIM as released by the maintainer and VIM author is packed with TAR. Now stop whining and use it the way I offer it.

My other projects will be offered with lha or lzx. If someone disagrees with the junk I do then please do not use it.
VIM 6.2.421 (MorphOS) released : Comment 18 of 34ANN.lu
Posted by Anonymous on 31-Mar-2004 17:38 GMT
In reply to Comment 17 (oGALAXYo):
well yes i won`t use it,very simple :-) if a programmer would just code for selfulfilling, well then don`t release it..
VIM 6.2.421 (MorphOS) released : Comment 19 of 34ANN.lu
Posted by oGALAXYo on 31-Mar-2004 17:42 GMT
In reply to Comment 18 (Anonymous):
Please excuse me for having offered you some of the work I participate in. You can be sure that I care less whether you use it or not. There are for sure enough people besides you who do honour the work I do.

And I already offered you to volunteer to write the Install script. It's not that I won't welcoem it. I simply have no time doing it - It's that simple.

You shouldn't expect that we developers stuff every shit with a golden spoon up your arse. You should get your lazy butt moving and try to help to change something that makes the 'so sad' situation become better for you and others. And a little tip asides. You should do something against your social manners. They simply suck.
VIM 6.2.421 (MorphOS) released : Comment 20 of 34ANN.lu
Posted by Lasse F. Pedersen on 31-Mar-2004 18:52 GMT
I like vim, sounds nice. :)

Use 'tar -xvzf <filename>' to extract - what's the problem?

Why the obsession with installer? To me, part of the coolness about Amiga software has always been the obvious use of the program directory for configuration files etc.

Last thing I'd like to see in AmigaOS [and clones] is a program registry, an installer that uses it, and "Uninstall" icons all over the place when "uninstalling" (read: removing) a program should simply be a matter of deleting it.

Useless abstractions are... useless.
VIM 6.2.421 (MorphOS) released : Comment 21 of 34ANN.lu
Posted by Anonymous on 31-Mar-2004 19:19 GMT
In reply to Comment 20 (Lasse F. Pedersen):
> when "uninstalling" (read: removing) a program should simply be a matter of deleting it.

Well, that just won't work except for simple programs that do not add to startup-serquence, do not set env variables, do not install shared components, etc. Re libs, catalogs, fonts and such, you have two choices: install everything locally (give up the benefits of central places, have many duplicates) or install everything centrally and let the system get chaotic. This is what we do and it only works because the OS and app development is pretty much dead. If Amiga was alive, a chaotic libs folder would not be tolerable: name conflicts, version conflicts, overflowing folders. We would have to come up with an effective system for shared components.
VIM 6.2.421 (MorphOS) released : Comment 22 of 34ANN.lu
Posted by brotheris on 31-Mar-2004 20:34 GMT
In reply to Comment 21 (Anonymous):
chaotic libs folder would not be tolerable: name conflicts, version conflicts

Name conflicts are developer problems.
Install scripts should check and not overwrite never versions with older. New AmigaOS libs by default are compatible with older versions. So no problems here. Most libs are used by other programs and custom one program libs usualy go to program subdrawer.

overflowing folders

this would be true.
On heavily used AmigaOS partitions biggest drawers usualy are Fonts: and Libs:
VIM 6.2.421 (MorphOS) released : Comment 23 of 34ANN.lu
Posted by Anonymous on 31-Mar-2004 20:58 GMT
In reply to Comment 22 (brotheris):
> Name conflicts are developer problems

Yes, they are. What's your point?

> Name conflicts are developer problems. Install scripts should check and not overwrite never versions with older

That's not a name conflict but version checking. A name conflict is if two developers accidentally pick the same name for a shared thingie. You inevitably have a name conflict problem on a system with shared places (env folder, libraries folder, user-startup section names etc). A proper system for shared components would include a registration authority for names.

> New AmigaOS libs by default are compatible with older versions

That has worked for AmigaOS because the OS was in a coma and has not matured much, it has been very static and it was very easy to maintain backwards-compatibility. That would not have been possible with an OS under serious development. I think OS4 addresses the isssue by implementing multiple interfaces in a library? An OS should have a system to simultaneously use different version of one library so that older programs don't break after a serious upgrade of shared components.

> Most libs are used by other programs and custom one program libs usualy go to program subdrawer

Again, what's your point? If you have shared places and shared components (at all), you can not uninstall apps by deleting them. Somebody above expressed his dislike for a central registry and formalized uninstallation but what's the alternative? I don't see any except laissez-faire and hoping for the best.
VIM 6.2.421 (MorphOS) released : Comment 24 of 34ANN.lu
Posted by brotheris on 31-Mar-2004 21:18 GMT
In reply to Comment 23 (Anonymous):
Yes, they are. What's your point?

Developers do not sit on their ears and eyes in cold, dark caves and know what is available around. I'm not saying that there were no name conflicts in the past, these very very minor problems.

That's not a name conflict but version checking

202.175.238.202 gave three problems and two of them weren't real. You can see linebreak, can't you ? :-)

That has worked for AmigaOS because the OS was in a coma and has not matured much

No, it works because it is designed this way.

I think OS4 addresses the isssue by implementing multiple interfaces in a library

Wrong again, new interface is needed for internal things, because of system limitation ppc progs can't use old interface and old 68k progs can't use new interface. It was born out of limitation. MorphOS does this different way.

Again, what's your point?

my point is: it is not bad as 202.175.238.202 painted it.

Somebody above expressed his dislike for a central registry and formalized uninstallation but what's the alternative?

Good installer which puts everything in right places ? Answer can't be that simple ? Or can it ? ;-)
VIM 6.2.421 (MorphOS) released : Comment 25 of 34ANN.lu
Posted by brotheris on 31-Mar-2004 21:20 GMT
In reply to Comment 24 (brotheris):
Argh, typo:
these very very minor problems shoyuld be these were very minor problems
VIM 6.2.421 (MorphOS) released : Comment 26 of 34ANN.lu
Posted by Lasse F. Pedersen on 31-Mar-2004 21:49 GMT
In reply to Comment 21 (Anonymous):
> We would have to come up with an effective system for shared components.

It would be very handy to be able to detect if, for example, a given shared library was actually referenced by something not in memory, yes. That would lead to a registry of some sorts, yes.

OTOH, how often do we want to actually delete a shared component?

I guess it's just a matter of opinion. While some wish for the OS to handle such things as program installation, configuration and uninstallation, while others still cling to the manual way of doing things.

Personally I prefer the manual way as I like to be in control.
VIM 6.2.421 (MorphOS) released : Comment 27 of 34ANN.lu
Posted by Anonymous on 31-Mar-2004 22:08 GMT
In reply to Comment 24 (brotheris):
> I'm not saying that there were no name conflicts in the past, these very very minor problems.

I agree, because the platform is dead. With a lively platform, you couldn't possibly have an overview of what other developers release and you need a formalized approach (registration?).

> Good installer which puts everything in right places ? Answer can't be that simple ? Or can it ? ;-)

Yes, that must be it (*sigh*). What has happend to brains? This sub-thread started with the issue of deinstallation. If you share places/components, you have to have a protocol for proper installation and removal OR install locally OR allow accumulation of crap and chaos and conflicts. That is just logic, not opinion.

>> That has worked for AmigaOS because the OS was in a coma and has not matured much
> No, it works because it is designed this way.

AmigaOS is designed what way? I take it you mean it's flexible? AmigaOS is quite static and difficult to upgrade: it exposes internal data in unacceptable ways and it has an inflexible API (somewhat mediated by tag lists, alas not used consistently and introduced as an afterthought). A better OS would have been designed with an object-oriented logic that encapsulates internal details. In the context of this discussion: the Amiga library system is flexible only in the sense that functions can be added to the end of the function table. A function, once added, is almost set in stone, in terms of functionality and parameters. This systems provides extremly limited flexibility. It only worked for us because AmigaOS was left alone for so long.

> Wrong again, new interface is needed for internal things, because of system limitation ppc progs can't use old interface

I'm not a beta tester, have no A1 and can only guess but I think you are wrong. A new library interface is NOT needed for mixing PPC code and 68k code. It's perfectly possible to use the existing interface (you just have to have a gate function). The reason for the new library interface and calling convention must be that it has inherent advantages, such as (a) allowing to load the "same" library multiple times without assigning to the library base pointer (useful for plug-ins) and (b) exposing different interfaces, thus providing an upgrade path. For example, if you create a new workbench library with a new API, the new workbench.library could also have the old interface (and an internal wrapper).
VIM 6.2.421 (MorphOS) released : Comment 28 of 34ANN.lu
Posted by Anonymous on 31-Mar-2004 22:21 GMT
In reply to Comment 26 (Lasse F. Pedersen):
> Personally I prefer the manual way as I like to be in control

Manual control is nice as long as it makes life easier, not more complicated. Deinstalling complex apps is not easy. Installing complex apps is not easy either. I have come to like the "Add/Remove software" dialog of XP. And I think that system, with a central database of installed shared components, actually works if the rules are strictly enforced.
VIM 6.2.421 (MorphOS) released : Comment 29 of 34ANN.lu
Posted by Francois Prowse on 01-Apr-2004 00:35 GMT
In reply to Comment 19 (oGALAXYo):
Galaxy - thanks for the extra effort to maintain this for us, I for one have downloaded and am using this. Please feel free to use TAR and GZIP, dosn't bother me

FP
VIM 6.2.421 (MorphOS) released : Comment 30 of 34ANN.lu
Posted by oGALAXYo on 01-Apr-2004 01:27 GMT
Hello,

I have updated the ANSI RGB colorvalues again and they now fit properly to what they should look now. Using them here on my System for a couple of mins now. The above ones are a bit inaccurate and I wanted to have them fixed. Either copy these lines into s:color-startup and call it up through s:shell-startup or put them in s:shell-startup as is.

;--- Begin s:color-startup ---
echo "*E[0;000;000;000V" ; black
echo "*E[1;255;255;255V" ; white
echo "*E[2;000;255;000V" ; green
echo "*E[3;255;255;000V" ; yellow
echo "*E[4;000;000;255V" ; blue
echo "*E[5;255;000;255V" ; magenta
echo "*E[6;000;255;255V" ; cyan
echo "*E[7;255;000;000V" ; red
;--- End s:color-startup ---

greetings,

oGALAXYo
VIM 6.2.421 (MorphOS) released : Comment 31 of 34ANN.lu
Posted by Lasse F. Pedersen on 01-Apr-2004 03:39 GMT
In reply to Comment 28 (Anonymous):
> a central database of installed shared components,
> actually works if the rules are strictly enforced.

Strictly enforced? Would that be like: Unless a component is registered it is not allowed into into any component directory (like LIBS: for a library) on a filesystem level?

If only the registry can touch component directories, what about us poor users who like to meddle with those things? It's hard to get both. WindowsXP does it, and it does it poorly, as the registry doesn't reflect changes "from outside" -> mess.

Anyway, off-topic I guess. Nice port. :)
VIM 6.2.421 (MorphOS) released : Comment 32 of 34ANN.lu
Posted by Anonymous on 01-Apr-2004 06:48 GMT
In reply to Comment 31 (Lasse F. Pedersen):
> Strictly enforced? Would that be like: Unless a component is registered it is not allowed into into any component directory

Well, that's unavoidable. There has to be a registration process. Make it a web page: you log in, enter the name of your component, get a handle in return and it's guaranteed that no conflict occurs. But actually I was thinking about the reference counter problem: that only works if installation and removal is properly reflected in the counter. Enforcement could be assured by purely technical means: do not allow installation and removal of shared components with AmigaDOS delete/copy commands but have dedicated commands in Installer that must be used to access protected directories.
VIM 6.2.421 (MorphOS) released : Comment 33 of 34ANN.lu
Posted by Gabriele Greco on 01-Apr-2004 10:31 GMT
In reply to Comment 17 (oGALAXYo):
Hi Galaxy...

You made a nice work, don't listen to whiners, these Amiga forums are full of them, the waste their time criticizing what programmers do, without doing anything really USEFUL themselves and with the only result of making more programmers stop supporting amigaos.

- If one wants an installer script: it can do it himself
- If one wants to upload to aminet the binaries: there is no rule about uploader == author
- If you want an lha or lzx archive online: repack it and place it online somewhere...

Bye,
Gabry
VIM 6.2.421 (MorphOS) released : Comment 34 of 34ANN.lu
Posted by Kolbjørn Barmen on 01-Apr-2004 18:24 GMT
In reply to Comment 28 (Anonymous):
What a strang discussion :)Did anyone here ever bother to check the log file option when installing "complex" (huh huh, as if) software using the installer? No? As for messy libs: - it is a system assign, treat it as such! There is no reason for it to be messy at all.
Anonymous, there are 34 items in your selection
Back to Top