hla-stdlib-talk

[Hla-stdlib-talk] HLA StdLib project Task List

[Nathan B. <eve...@ya...>]

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. 

Re: [Hla-stdlib-talk] HLA StdLib project Task List

[<rh...@cs...>]

> 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

Re: [Hla-stdlib-talk] HLA StdLib project Task List

[Frank K. <fbk...@co...>]

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

Re: [Hla-stdlib-talk] HLA StdLib project Task List

[Nathan B. <eve...@ya...>]

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.

[Hla-stdlib-talk] Okay, it's about time to start posting code

[<rh...@cs...>]

Someone needs to explain to me how to use SourceForge (which I haven't
touched in about 3-4 years). I read that it supports SVN/Tortoise, which
is great as that is the source code control system I use to maintain HLA
and the HLA stdlib, but I don't have a clue how to connect my client up to
SourceForge.

I'm a bit busy right now making changes to the stdlib to prepare it for
uploading to SourceForge, so if someone has a few minutes to figure out
what I need to know, that would be a big help.

BTW, those who want to be able to work in the source tree ought to get
SVN/Tortoise. It's really an awesome SCC system.
Cheers,
Randy Hyde

Re: [Hla-stdlib-talk] Okay, it's about time to start posting code

[Nathan B. <eve...@ya...>]

1)  sign-up for a SF account
  2)  give either me or Sevag your account name so we can add you to the project
  3)  the instructions for subversion are on this page:
  
  http://sourceforge.net/docs/E09
  
  Subversion Server:
  https://svn.sourceforge.net
  
  Path to Repository:
  /svnroot/hla-stdlib
  
  Connection Information
  
  The following configuration settings are used to access a SourceForge.net-hosted SVN repository:
  
      * Hostname: svn.sourceforge.net
      * Port: 443
      * Protocol: HTTPS
      * Repository Path: /svnroot/PROJECTNAME (PROJECTNAME is the project's UNIX name)
      * Username: Your SourceForge.net username for SVN write operations, none will be requested otherwise.
      * Password: Your SourceForge.net user password for write operations, none will be requested otherwise.
  
  If you receive a 403 Forbidden error, either your password doesn't  match (it could be a sync issue, try changing your password and  attempting to access the service a few minutes later with the new  password) or your project administrator hasn't granted you SVN write  permissions (if you are the project admin, you must still grant  yourself that permission). Go to the members section of your project  admin pages to set this option.
  
  Firewalls and proxy servers may present a problem in using SVN. No  workarounds are provided as HTTPS should be passed without modification  from almost all ISPs world-wide. Should a firewall or proxy be causing  issues with your connection, contact your network administrator or ISP  for further assistance.
  

rh...@cs... wrote:  Someone needs to explain to me how to use SourceForge (which I haven't
touched in about 3-4 years). I read that it supports SVN/Tortoise, which
is great as that is the source code control system I use to maintain HLA
and the HLA stdlib, but I don't have a clue how to connect my client up to
SourceForge.

I'm a bit busy right now making changes to the stdlib to prepare it for
uploading to SourceForge, so if someone has a few minutes to figure out
what I need to know, that would be a big help.

BTW, those who want to be able to work in the source tree ought to get
SVN/Tortoise. It's really an awesome SCC system.
Cheers,
Randy Hyde



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Hla-stdlib-talk mailing list
Hla...@li...
https://lists.sourceforge.net/lists/listinfo/hla-stdlib-talk


 		
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates starting at 1¢/min.

Re: [Hla-stdlib-talk] Okay, it's about time to start posting code

[<rh...@cs...>]

> 1)  sign-up for a SF account
>   2)  give either me or Sevag your account name so we can add you to the
> project

rhydehla


Cheers,
Randy Hyde