Time to split the discussion?
I have now begun examining the source of the csh implementation and it does not look too bad. The thing that struck me, however is that we might wish to split the mailinglist in two - one for project related discussion and one for development discussion. The risk is of course that one of the lists will stagnate, but the risk of not doing so is to flood this list with messages which are largely irrelevant to any non-programmer. (But perhaps this will make everyone feel more "in the know"?) Well, we can discuss this on _monday_ :-) I just thought I would mention it so people have time to think about it. Now on to the csh status: 1) The issue of csh using SAS/C internal structures seems to be possible to work around using a combination of NameFromFH() or ExamineFH() with freopen(). Possibly there might be some problem if there is a file handle which does not have a name. (Does anyone know is this is so? E.g. will NameFromFH(pr_COS) return "CONSOLE:" on OS4 if called with the default pr_COS of a DOS process run from shell?) 2) Rewriting the internal command handling to accept unix-style paths seems easy enough, though it will take some time to do. 3) There is be a bunch of other dependencies, but most seem minor and should be possible to work around using standard C and AmigaOS 3.1 code. My working plan for now is to continue using SAS/C while removing all obvious incompatibilities and then move the code to gcc to see what further issues pop up. -Peter aka. Archprogrammer Reality is for people who cannot face ScienceFiction. Only lefthanded people are in their right minds.
Hi, Op 20-jan-05 om 03:08 heeft Peter Bengtsson het volgende geschreven:
I have now begun examining the source of the csh implementation and it does not look too bad.
Good news :)
The thing that struck me, however is that we might wish to split the mailinglist in two - one for project related discussion and one for development discussion. The risk is of course that one of the lists will stagnate, but the risk of not doing so is to flood this list with messages which are largely irrelevant to any non-programmer. (But perhaps this will make everyone feel more "in the know"?)
I was more considering using dev.amigaopenoffice.org for this, as it has task management, ticketing & fora that can be assigned to any project. My idea was to devide the dependencies into projects so that each dependency has it's own forum, taks & ticketing service. ---- Amon_Re Ochal Christophe Webmaster for: http://www.kefren.be http://www.metalfest.be http://amigadev.amigaworld.net
Ochal Christophe wrote:
Hi,
Op 20-jan-05 om 03:08 heeft Peter Bengtsson het volgende geschreven:
I have now begun examining the source of the csh implementation and it does not look too bad.
Good news :)
The thing that struck me, however is that we might wish to split the mailinglist in two - one for project related discussion and one for development discussion. The risk is of course that one of the lists will stagnate, but the risk of not doing so is to flood this list with messages which are largely irrelevant to any non-programmer. (But perhaps this will make everyone feel more "in the know"?)
I was more considering using dev.amigaopenoffice.org for this, as it has task management, ticketing & fora that can be assigned to any project.
My idea was to devide the dependencies into projects so that each dependency has it's own forum, taks & ticketing service.
Christophe, I would also suggest having a top level that is split by: Build environment (csh/bash etc) Libs/Dependencies (ie Sane etc) OpenOffice (the rest) so that we can see at a glance how close to be ready with each seperate section. Mark
Le 20/01/2005, Ochal Christophe a écrit :
Op 20-jan-05 om 03:08 heeft Peter Bengtsson het volgende geschreven:
The thing that struck me, however is that we might wish to split the mailinglist in two - one for project related discussion and one for development discussion. The risk is of course that one of the lists will stagnate, but the risk of not doing so is to flood this list with messages which are largely irrelevant to any non-programmer. (But perhaps this will make everyone feel more "in the know"?)
I was more considering using dev.amigaopenoffice.org for this, as it has task management, ticketing & fora that can be assigned to any project.
My idea was to devide the dependencies into projects so that each dependency has its own forum, taks & ticketing service.
I vote for this option. Too many mailing lists is a Bad Thing. I feel that in this case a forum is the best option: developers can communicate between themselves without bothering/being bothered by people working on another part of the project with totally different problems and priorites, with sections available to all (involved the the project, not the general public) for more general discussion. This list is probably best used for general day-to-day information and organisation, stuff that doesn't need to be preserved for posterity. Incidentally, has anyone yet been officially designated to talk to/work with the main Openoffice.org project? We need to be an official port, after all. Salutations -- Rose Humphrey /anarchic_teapot/
Hi. Peter Bengtsson wrote:
The thing that struck me, however is that we might wish to split the mailinglist in two - one for project related discussion and one for development discussion.
Why not prefix the subject with some keywords to discern different types of discussion ?
1) The issue of csh using SAS/C internal structures seems to be possible to work around using a combination of NameFromFH() or ExamineFH() with freopen(). Possibly there might be some problem if there is a file handle which does not have a name. (Does anyone know is this is so? E.g. will NameFromFH(pr_COS) return "CONSOLE:" on OS4 if called with the default pr_COS of a DOS process run from shell?)
I've asked on the OS4 developer list. Regards, -- Thomas Frieden <ThomasF@hyperion-entertainment.biz> Hyperion Entertainment - Naur dan i-deryg lhuin
participants (5)
-
Mark bond -
Ochal Christophe -
Peter Bengtsson -
Rose Humphrey -
Thomas Frieden