hla-stdlib-talk Mailing List for HLA Standard Library (Page 3)
Brought to you by:
evenbit
Menu
▾
▴
hla-stdlib-talk — Talk about HLA StdLib issues
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(2) |
Jun
(2) |
Jul
(5) |
Aug
(8) |
Sep
|
Oct
|
Nov
(3) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
(3) |
Feb
(7) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(13) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Nathan B. <eve...@ya...> - 2006-08-04 18:59:46
|
rh...@cs... wrote:Also, fileio.cd, .gwd, .delete, .size, and several others are being deprecated and moved into a new "filesys" namespace. It would be nice to have a *lot* of new routines added to the filesys module. In particular, one that would be nice to have *immediately* is a directory iterator that returns strings containing all the filenames in a given directory. Well this will provide some interesting research and experimentation. Looking at the source code of some Unix commands might be of some help. In other news: I am working away on the fileio module right now, doing a lot of clean up. I'm hoping that in about a week I'll be able to post the code and we can get started on the multi-lingual header files and unit tests for that module. I would advise against *any* modifications to the existing library code. Almost every routine is going to have at least minor changes when I begin posting new code. That means that any effort expended right now may be wasted. Well my concern is to get the conversation, research, and experimentation started early. When v2.0 "hits the stands" it'll feel better to say "someone is working on that issue" than to point everyone to the 1.81 download. Nathan. --------------------------------- Do you Yahoo!? Get on board. You're invited to try the new Yahoo! Mail Beta. |
|
From: Frank K. <fbk...@co...> - 2006-08-03 00:54:21
|
rh...@cs... wrote: >>To get things kind of organized, we might want to put together a "task >>list" of items that project participants could work on. Some items that >>have come up recently: >> >> 1) fileio.append implementation not consistent > > Yes. Consistently raises an exception, actually. The constant exists (for Linux), but isn't checked for in the open routine. I can see three approaches to this. 1) Remove it, 'cause it isn't portable. If we do this with every new OS that's added, we'll soon have a very small standard library. Easy to maintain! :) 2) Let it work for Linux, and raise an exception for Windows. Not very portable. :( 3) *Make* it portable! The Windows API apparently hasn't got an "open for append" option (dos didn't - my 8-bit Atari did... Progress!). H:A can accept that option, open the file (read/write, I guess - open for append for readonly isn't too useful), and "seek" (SetFilePointer) to the end of it - "SetFilePointer (handle, 0, 0, w.FILE_END);", as a guess. Unless there are issues I don't see, this shouldn't be hard. >> 2) fileio.eof code is "crufty" according to Frank :) > > The whole concept of how testing for end of file needs to be rethought. We > may want to clean this up a tiny bit and then develop a new fileio package > that does I/O completely differently. FWIW, I withdraw my objection to that. "feof" isn't too pretty, but I don't see how else you'd do it. I was under the impression that "fread" *didn't* return the number of bytes read. I don't know if I misunderstood what I was looking at, or if it's been changed, but it *does* return the number of bytes read. So we don't need to do... read one or more bytes maybe process 'em write one or more bytes check for EOF if not, do more ... which is what I thought was "crufty". We can: read one or more bytes if zero, goto we_be_done process? write do more ... so we can "just don't do it". There's a lot of example code that *does* do it. Not a library problem. >> 3) Windows-only functions (fileio.move and copy, etc) being removed >>from the library. Randy, could you give us a complete list of these? > > > conv.cstr and conv.a_cstr are being deprecated. Though there are > equivalent routines in the str package. > > Also, fileio.cd, .gwd, .delete, .size, and several others are being > deprecated and moved into a new "filesys" namespace. It would be nice to > have a *lot* of new routines added to the filesys module. In particular, > one that would be nice to have *immediately* is a directory iterator that > returns strings containing all the filenames in a given directory. I smiled when I heard you were working on a "findfirst" and "findnext" for Linux :) We've got readdir (89) and getdents (141). I started out with getdents, which reads a buffer-full of dirents*, since readdir, which just gets one, is "obsolete". This introduced another "loop" into what was a recursive routine anyway... I think readdir would have been easier. (* actually, seems to read some maximum number of entries, no matter how big your buffer is) (note: the dirent structure is one of the things that *is* different in BSD - joy!) > In other news: I am working away on the fileio module right now, doing a > lot of clean up. I'm hoping that in about a week I'll be able to post the > code and we can get started on the multi-lingual header files and unit > tests for that module. > > I would advise against *any* modifications to the existing library code. > Almost every routine is going to have at least minor changes when I begin > posting new code. That means that any effort expended right now may be > wasted. In the event that the new code introduces bugs (I've heard of this happening), you'll wish you had the changes documented in a CVS repository, or some such... Best, Frank |
|
From: <rh...@cs...> - 2006-08-02 21:15:12
|
> To get things kind of organized, we might want to put together a "task > list" of items that project participants could work on. Some items that > have come up recently: > > 1) fileio.append implementation not consistent Yes. > 2) fileio.eof code is "crufty" according to Frank :) The whole concept of how testing for end of file needs to be rethought. We may want to clean this up a tiny bit and then develop a new fileio package that does I/O completely differently. > 3) Windows-only functions (fileio.move and copy, etc) being removed > from the library. Randy, could you give us a complete list of these? conv.cstr and conv.a_cstr are being deprecated. Though there are equivalent routines in the str package. Also, fileio.cd, .gwd, .delete, .size, and several others are being deprecated and moved into a new "filesys" namespace. It would be nice to have a *lot* of new routines added to the filesys module. In particular, one that would be nice to have *immediately* is a directory iterator that returns strings containing all the filenames in a given directory. In other news: I am working away on the fileio module right now, doing a lot of clean up. I'm hoping that in about a week I'll be able to post the code and we can get started on the multi-lingual header files and unit tests for that module. I would advise against *any* modifications to the existing library code. Almost every routine is going to have at least minor changes when I begin posting new code. That means that any effort expended right now may be wasted. Cheers, Randy Hyde |
|
From: Nathan B. <eve...@ya...> - 2006-08-02 02:45:03
|
[ cc'ed from MASM32 forum ]
Re: Porting the HLA stdlib
« Reply #4 on: August 01, 2006, 10:04:17 pm »
Well, here's the current status of the porting project.
I'm currently in the middle of reorganizing the directories and files that make up the HLA Standard Library. Originally, what I had planned to do was move all the OS dependent files to one directory (to make porting to new OSes easier). However, as I started playing around with the files, I figured it would be a great idea to merge certain source files that were tiny into appropriate file combinations. For example, the stdout.puti8 routine is just a few lines of code and it calls stdout.puti32 (after sign extensions). Likewise, stdout.puti16 is just a few lines of code, which also calls stdout.puti32 (after a sign extension). Because the linker will add up to 15 bytes of padding between separate modules it links together, you wind up wasting a lot of space in the executable if you're linking together a bunch of tiny object modules.
Once I get the current phase done, my next step will be to get the automatic make system I've designed (which automatically generates all the make files to build the stdlib) operational under Linux (yeah, I know that doesn't apply to MASM, but before I can post the new version of the HLA stdlib code, I've got to have the Linux port operational).
Once the above is complete, the *real* fun can begin. And this is where I can use some help. As I mentioned, there's a lot of work creating MASM, NASM, FASM, and GoAsm header files. I'm assuming I'll be able to get a little bit of help (at least on the MASM header files) around here. The other big task is going to be writing unit tests for all the stdlib modules. What I'll probably do is write a test in HLA and then ask for help writing comparable modules for other assemblers (and for those who don't know HLA syntax, you can always use the output from HLA in MASM/FASM/Gas syntax as a guide).
Cheers,
Randy Hyde
P.S. Evenbit, go ahead and cross-post this to the mailing list.
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min. |
|
From: Nathan B. <eve...@ya...> - 2006-08-02 02:41:33
|
To get things kind of organized, we might want to put together a "task list" of items that project participants could work on. Some items that have come up recently: 1) fileio.append implementation not consistent 2) fileio.eof code is "crufty" according to Frank :) 3) Windows-only functions (fileio.move and copy, etc) being removed from the library. Randy, could you give us a complete list of these? Also, if you happen to be decent at creating web pages, the project lacks a "front door" at SourceForge. Nathan. --------------------------------- Groups are talking. We´re listening. Check out the handy changes to Yahoo! Groups. |
|
From: <rh...@cs...> - 2006-07-31 23:58:46
|
> << I am copying these to the list to spur discussion and to keep a record > of the issues -- Nathan. >> > > Well, get ready. Because perhaps the biggest change to the stdlib since the port to Linux is happening right now. I'm completely reorganizing the stdlib to make it easier to port to other OSes (FreeBSD at the moment) and my plans are to supply header files for NASM, FASM, MASM, and GoAsm while doing this (and I'll be looking for lots of help in this latter project!) Cheers, Randy Hyde |
|
From: Frank K. <fbk...@co...> - 2006-07-28 22:16:10
|
Randall Hyde wrote: > Like file.move, this went bye-bye. > The problem is that these two routines were win32 only and the library > routines were not portable. > If you want FileMove and FileCopy operations under Windows, you can call > the Win32 APIs to do these tasks. Cop out! If Nick wants to do it on Linux or BSD he's out of luck? (I assume he's using Windows, but maybe would like it to be "portable"?) A simple one-to-one rename like Nick wants is trivial in Linux, but I assume the Windows APIs handle such things as "wildcards", and recursive copying of subdirectories and stuff that's not so trivial. (a comment in "cp.asm" in asmutils says, "recursive copy is a bitch, but what the hell, we're ASM programmers!") I'd hate to wake up in the morning and read in the paper, "Portable Library stopped dead in its tracks by file copy!". You don't mean "gone bye-bye", you mean "the portable version is not available *yet*"... doncha? Best, Frank |
|
From: Frank K. <fbk...@co...> - 2006-07-28 21:57:55
|
hmmm, I cc'd this to hla-stdlib-talk, but it didn't show up... well, that's the "SourceForge way" - ya gotta do everything twice... since this was intended more as a "topic for discussion" on this list, than for aoaprogramming per se, I'll try it again... Randall Hyde wrote: > Like file.move, this went bye-bye. > The problem is that these two routines were win32 only and the library > routines were not portable. > If you want FileMove and FileCopy operations under Windows, you can call > the Win32 APIs to do these tasks. Cop out! If Nick wants to do it on Linux or BSD he's out of luck? (I assume he's using Windows, but maybe would like it to be "portable"?) A simple one-to-one rename like Nick wants is trivial in Linux, but I assume the Windows APIs handle such things as "wildcards", and recursive copying of subdirectories and stuff that's not so trivial. (a comment in "cp.asm" in asmutils says, "recursive copy is a bitch, but what the hell, we're ASM programmers!") I'd hate to wake up in the morning and read in the paper, "Portable Library stopped dead in its tracks by file copy!". You don't mean "gone bye-bye", you mean "the portable version is not available *yet*"... doncha? Best, Frank |
|
From: Nathan B. <eve...@ya...> - 2006-07-28 21:05:41
|
ran...@ea... wrote: > Hi All, > I'm going to start posting HLA standard library routines for code > review here. We can discuss design decisions concerning each of the > routines (go for space, speed, readability, whatever) as well as come > up with the header file information for various assemblers to link in > these modules. > > This first routine is the bit.cnt function (counts the number of set > bits in a dword). I suspect there won't be too much discussion of this > one as it's just the translation of comparable code from the AMD > optimization manual. Never the less, here it is: > > > // I, Randall Hyde, hereby agree to waive all claim of copyright > (economic > // and moral) in all content contributed by me, the user, and > immediately > // place any and all contributions by me into the public domain; I > grant > // anyone the right to use my work for any purpose, without any > // conditions, to be changed or destroyed in any manner whatsoever > // without any attribution or notice to the creator. I also absolve > myself > // of any responsibility for the use of this code, the user assumes all > // responsibilities for using this software in an appropriate manner. > > > > unit bitsUnit; > > #includeonce( "bits.hhf" ); > > > // bitCount- > // > // Counts the number of "1" bits in a dword value. > // This function expects the dword value in EAX. > > procedure bits.cnt( BitsToCnt:dword in eax ); @noframe; > > const > EveryOtherBit := $5555_5555; > EveryAlternatePair := $3333_3333; > EvenNibbles := $0f0f_0f0f; > > begin cnt; > > push( edx ); > mov( eax, edx ); > > // Compute sum of each pair of bits > // in EAX. The algorithm treats > // each pair of bits in EAX as a two > // bit number and calculates the > // number of bits as follows (description > // is for bits zero and one, it generalizes > // to each pair): > // > // EDX = BIT1 BIT0 > // EAX = 0 BIT1 > // > // EDX-EAX = 00 if both bits were zero. > // 01 if Bit0=1 and Bit1=0. > // 01 if Bit0=0 and Bit1=1. > // 10 if Bit0=1 and Bit1=1. > // > // Note that the result is left in EDX. > > shr( 1, eax ); > and( EveryOtherBit, eax ); > sub( eax, edx ); > > // Now sum up the groups of two bits to > // produces sums of four bits. This works > // as follows: > // > // EDX = bits 2,3, 6,7, 10,11, 14,15, ..., 30,31 > // in bit positions 0,1, 4,5, ..., 28,29 with > // zeros in the other positions. > // > // EAX = bits 0,1, 4,5, 8,9, ... 28,29 with zeros > // in the other positions. > // > // EDX+EAX produces the sums of these pairs of bits. > // The sums consume bits 0,1,2, 4,5,6, 8,9,10, ... 28,29,30 > // in EAX with the remaining bits all containing zero. > > mov( edx, eax ); > shr( 2, edx ); > and( EveryAlternatePair, eax ); > and( EveryAlternatePair, edx ); > add( edx, eax ); > > // Now compute the sums of the even and odd nibbles in the > // number. Since bits 3, 7, 11, etc. in EAX all contain > // zero from the above calcuation, we don't need to AND > // anything first, just shift and add the two values. > // This computes the sum of the bits in the four bytes > // as four separate value in EAX (AL contains number of > // bits in original AL, AH contains number of bits in > // original AH, etc.) > > mov( eax, edx ); > shr( 4, eax ); > add( edx, eax ); > and( EvenNibbles, eax ); > > // Now for the tricky part. > // We want to compute the sum of the four bytes > // and return the result in EAX. The following > // multiplication achieves this. It works > // as follows: > // (1) the $01 component leaves bits 24..31 > // in bits 24..31. > // > // (2) the $100 component adds bits 17..23 > // into bits 24..31. > // > // (3) the $1_0000 component adds bits 8..15 > // into bits 24..31. > // > // (4) the $1000_0000 component adds bits 0..7 > // into bits 24..31. > // > // Bits 0..23 are filled with garbage, but bits > // 24..31 contain the actual sum of the bits > // in EAX's original value. The SHR instruction > // moves this value into bits 0..7 and zeroes > // out the H.O. bits of EAX. > > intmul( $0101_0101, eax ); > shr( 24, eax ); > > pop( edx ); > ret(); > > end cnt; > > end bitsUnit; > > > > ----------------------------- > > For HLA, the external declaration is: > > procedure cnt( BitsToCnt:dword in eax ); > @returns( "eax" ); > @external( "BITS_CNT" ); > > For MASM, the external declaration is > > bits_cnt proto near32 pascal,d:dword > bitcnt macro d > invoke bits_cnt,d > endm > > etc. > > For most assemblers, what I'm interested in doing is providing an > external declaration to the name (e.g., BITS_CNT) and then supplying a > macro that passes the parameter(s) to the call. > Cheers, > Randy Hyde --------------------------------- Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less. |
|
From: Nathan B. <eve...@ya...> - 2006-07-28 20:57:12
|
<< I am copying these to the list to spur discussion and to keep a record of the issues -- Nathan. >>
Re: [aoaprogramming] fileio.move("combolist1.txt","combolist.txt");
Randall Hyde wrote:
> Like file.move, this went bye-bye.
> The problem is that these two routines were win32 only and the library
> routines were not portable.
> If you want FileMove and FileCopy operations under Windows, you can call
> the Win32 APIs to do these tasks.
Cop out!
If Nick wants to do it on Linux or BSD he's out of luck? (I assume he's
using Windows, but maybe would like it to be "portable"?)
A simple one-to-one rename like Nick wants is trivial in Linux, but I
assume the Windows APIs handle such things as "wildcards", and recursive
copying of subdirectories and stuff that's not so trivial. (a comment in
"cp.asm" in asmutils says, "recursive copy is a bitch, but what the
hell, we're ASM programmers!")
I'd hate to wake up in the morning and read in the paper, "Portable
Library stopped dead in its tracks by file copy!". You don't mean "gone
bye-bye", you mean "the portable version is not available *yet*"... doncha?
Best,
Frank
---------------------------------
Groups are talking. We´re listening. Check out the handy changes to Yahoo! Groups. |
|
From: Nathan B. <eve...@ya...> - 2006-06-26 04:19:50
|
Frank Kotler <fbk...@co...> wrote: <<SNIP>>
>
> I agreed to set-up the SourceForge site for the library -- didn't say
> that I would fix the code! ;-)
Okay. I didn't mean that you had to fix it personally. Just a potential
item for discussion.
NB - Yes, a good place to start.
<<SNIP>>
Question is, what's the "best" way for hlalib to handle this? One option
- the current situation, apparently - is to simply not implement it in
Linux either. Another option would be to implement it in Linux, and in
Windows, provide a "sorry, only available in Linux" message.
NB - *I* do not like that option.
"fileio.copy" and "fileio.move" do this to Linux users (last time I
looked).
NB - I did not know that.
The most "full-featured" way (is that "best"?) would be to add
the functionallity to the Windows version, too. As you say, it's easy
enough to do.
NB - Now, I *like* that. Any other votes?
Beyond this particular issue, it's a philosophical question. I'm apt to
claim that "portable" necessarily implies "lowest common denominator".
But "open for append" - and the "copy" and "move" functions, going the
other way - are cases where we could bring the less-featured interface
up to match the more-featured interface. Is this what we ("we" being HLA
users, not necessarily including me) want to do?
NB - I leave that up to Randy and/or the folks who join the project.
Does hlalib propose to provide a routine for "everything in the world
you could possibly imagine"? It's already far more than "the minimum set
of routines needed for portability". Is there an identifiable
stopping-point, beyond which another feature is "one too many"?
NB - One can *never* have _too much_ of something! ;-)
There's a discussion on a.l.a. about library routines, and whether they
should be concerned about "security junk". The idea (in one camp) being
that it's the caller's job to "protect" any unsafe library routine, and
"security junk" doesn't belong in a library routine. Recent versions of
gcc yell at ya if you use "gets()" (but not "sprintf()" which is just as
bad). I'm not aware of any buffer overruns in the current code, and I
assume we're not supposed to introduce any. There are more sophisticated
security issues, too. Do we have/want/need a "specification" on that?
NB - Well, if the library is widely used -- plus, since HLA is aimed at beginners -- I think it should have a modicum of security built-in.
Another issue that appears in that thread involves "side effects". Is it
okay to alter the original command line in the course of parsing the
command line, for example?
NB - My vote is for not altering anything like that. What if you've got another thread going and it wants to look at the command line too? We want it to see the original also, don't we?
Just some possible topics for discussion... Personally I'm apt to just
start coding and see what it turns out to be. I'm told that you can get
better results by deciding what you intend to do *before* you start.
Might be worth a try. :)
Best,
Frank
NB - Thanks for the start!
Nathan.
---------------------------------
Do you Yahoo!?
Get on board. You're invited to try the new Yahoo! Mail Beta. |
|
From: Frank K. <fbk...@co...> - 2006-06-24 19:24:18
|
evenbitnb wrote:
> --- In aoa...@ya..., Frank Kotler <fbkotler@...> wrote:
>
>>Randall Hyde wrote:
>>
>>>I take it you're programming under Windows. "a" is defined only in
>
> Unix,
>
>>>apparently:
>>>
>>>#if( @global:os.win32 )
>>>
>>> const
>>> r := $8000_0000; // Open file for reading.
>>> w := $4000_0000; // Open file for writing.
>>> rw := r | w; // Open file for reading and writing.
>>>
>>>#elseif( @global:os.linux )
>>> const
>>> r := 0; // Open file for reading.
>>> w := 1; // Open file for writing.
>>> rw := 2; // Open file for reading and writing.
>>> a := 3; // Open file for append (write)
>>>
>>>#endif
>>
>>Implemented anywhere? I'm looking at fileio/fopen.hla...
>>
>
> {{SNIP}}
>
>>Nathan! Nathan! We may have a live one! :)
>>
>
>
> I agreed to set-up the SourceForge site for the library -- didn't say
> that I would fix the code! ;-)
Okay. I didn't mean that you had to fix it personally. Just a potential
item for discussion.
> Don't know about appending a file on Linux, but for Windows, IIRC, it
> depends on a parameter that you pass to CreateFile. One way, if it
> sees the file already exists, then it gives you an error; the other
> way, it opens the file... probably just adjust the current position to
> the end of the file to make sure that anything written gets appended.
To be honest, I didn't realize that "O_APPEND" existed on Linux until I
read this question - but it does...
On my old 8-bit Atari, "open for append" was an option. In dos, and
apparently 'doze, no. We have to open the file, and then seek to the end
of it. I imagine that's exactly what "O_APPEND" does, somewhere in the
bowels of the kernel code. Just a "convenience function" that Linux
provides... and Windows doesn't(?). Usually it's the other way around.
Question is, what's the "best" way for hlalib to handle this? One option
- the current situation, apparently - is to simply not implement it in
Linux either. Another option would be to implement it in Linux, and in
Windows, provide a "sorry, only available in Linux" message.
"fileio.copy" and "fileio.move" do this to Linux users (last time I
looked). The most "full-featured" way (is that "best"?) would be to add
the functionallity to the Windows version, too. As you say, it's easy
enough to do.
Beyond this particular issue, it's a philosophical question. I'm apt to
claim that "portable" necessarily implies "lowest common denominator".
But "open for append" - and the "copy" and "move" functions, going the
other way - are cases where we could bring the less-featured interface
up to match the more-featured interface. Is this what we ("we" being HLA
users, not necessarily including me) want to do?
Does hlalib propose to provide a routine for "everything in the world
you could possibly imagine"? It's already far more than "the minimum set
of routines needed for portability". Is there an identifiable
stopping-point, beyond which another feature is "one too many"?
There's a discussion on a.l.a. about library routines, and whether they
should be concerned about "security junk". The idea (in one camp) being
that it's the caller's job to "protect" any unsafe library routine, and
"security junk" doesn't belong in a library routine. Recent versions of
gcc yell at ya if you use "gets()" (but not "sprintf()" which is just as
bad). I'm not aware of any buffer overruns in the current code, and I
assume we're not supposed to introduce any. There are more sophisticated
security issues, too. Do we have/want/need a "specification" on that?
Another issue that appears in that thread involves "side effects". Is it
okay to alter the original command line in the course of parsing the
command line, for example?
Just some possible topics for discussion... Personally I'm apt to just
start coding and see what it turns out to be. I'm told that you can get
better results by deciding what you intend to do *before* you start.
Might be worth a try. :)
Best,
Frank
|
|
From: Nathan B. <eve...@ya...> - 2006-05-18 13:48:47
|
Here is a list describing the functions of different project roles: Project Admins (bold) can access this page and other project administration pages Release Technicians can make the file releases (any project admin also a release technician) Snapshot Managers can produce file snapshot releases if this feature has been enabled by site admins Tool Technicians (T) can be assigned Bugs/Tasks/Patches Tool Admins (A) can make changes to a Bugs/Tasks/Patches Tracker as well as make settings changes to that Tracker Tool No Permission (N/A) Developer doesn't have specific permission (currently equivalent to '-') Moderators (forums) can delete messages from the project forums Editors (doc. manager) can update/edit/remove documentation from the project. Project web space write access can be restricted using the "Allow access to shell server group space" option. CVS Repository Write Access can be restricted on a per-user, per-module, per-branch basis using the cvs_acls script Nathan. --------------------------------- Sneak preview the all-new Yahoo.com. It's not radically different. Just radically better. |
|
From: Nathan B. <eve...@ya...> - 2006-05-18 13:46:13
|
For those joining, here is a complete list of project roles. Just let me know what role, tasks, and duties you are interested in taking on so that I can set up your membership/permissions accordingly. Developer Project Manager Unix Admin Doc Writer Tester Support Manager Graphic/Other Designer DBA (Database Administrator) Editorial/Content Writer Packager (.rpm, .deb etc) Analysis / Design Advisor/Mentor/Consultant Distributor/Promoter Content Management Requirements Engineering Web Designer Porter (Cross Platform Devel.) Undefined All-hands Person No specific role Nathan. --------------------------------- Blab-away for as little as 1¢/min. Make PC-to-Phone Calls using Yahoo! Messenger with Voice. |
|
From: <nb...@wi...> - 2006-04-28 12:58:54
|
I am waiting for the release of HLA 1.82 before dumping any source on the CVS, however, all
interested parties are invited to join the project {{ just let me know in what capacity --
developer, technician, project admin, etc. -- you wish to participate in }} to "kick
around" your ideas and just generally get things started.
Nathan.
|
