yetanotherclib-devel

[Yetanotherclib-devel] Alpha Release

[Jeffrey B. <je...@e-...>]

Hello.

I believe it is time to make an alpha release of the library.  The purpose of such a release at the early development stage of this project is to encourage new development by providing a more constant and readily accessable code base than the concurrent versioning system repository.  The library is already very useful, and the ability for projects to depend on it squarely depends on a versioned release.  For example, AntiRight makes use of yetanother library functions if the library is detected as being installed.  Availability of recent development to the masses will creat a user base, from which developers will emerge.  

Regards,
Jeff

Re: [Yetanotherclib-devel] Library future.

[Jeffrey B. <je...@e-...>]

The following may also be useful for updating the ChangeLog, without the need for emacs:  cvs -d :pserver:ano...@cv...:/usr/local/cvs co cvs2cl

-Jeff

Re: [Yetanotherclib-devel] Library future.

[Jeffrey B. <je...@e-...>]

P.S.

I checked in HACKING two days ago, so simply update your copy of the tree.  Modify it as you see fit.   

Regards,
Jeff

Re: [Yetanotherclib-devel] Library future.

[Jeffrey B. <je...@e-...>]

Hello.

I am using emacs to update the ChangeLog.  The command sequence is C-x v a

-Jeff

Re: [Yetanotherclib-devel] Library future.

[Darek O. <ost...@2p...>]

Greetingz

Burak Gunusen wrote:

>Rewriting from scratch? Hmmm...the library is pretty good so far.
>Spending time to built from scratch must be the last thing to do unless the 
>new procedures provide better functionality.
>
>It will be better if we start  discussing coding conventions as soon as 
>possible, before the library becomes large enough...
>
>  
>
I've commited some code to cvs(list.h, list.c, pred.h), now you can have 
look at it and tell me what you think
about it. All functions are left for backward compatibility.
I have question, what tools are you using to generate ChangeLog file?

Best
Darek

Re: [Yetanotherclib-devel] Library future.

[Darek O. <ost...@2p...>]

Burak Gunusen wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Greetingz
>
>Rewriting from scratch? Hmmm...the library is pretty good so far.
>Spending time to built from scratch must be the last thing to do unless the 
>new procedures provide better functionality.
>
>It will be better if we start  discussing coding conventions as soon as 
>possible, before the library becomes large enough...
>
>
>And instead of adding functions to list, introducing a new member
>"stack" will be better i hope, so that list may pop the values based on FIFO 
>or FILO or whatever the principle developer wishes to use...
>I don't believe that the aim of a list is only a stack like thing..I used the 
>list as a string tokenizer lately and losing values as I pop is the worst 
>thing that could happen...This is why I believe keeping the base list as 
>clean as possible...
>
>Best Wishes
>
>  
>

Ok, I'm waiting for proposals, and HACKING document.
Best
Darek Ostolski

Re: [Yetanotherclib-devel] Library future.

[Jeffrey B. <je...@e-...>]

Hello.

There is an existing code base, which is readily usable and functional, so starting over is not the best thing to do.  The code that I usually work with, the list and the parsing routines, provide great utility and convenience for developers who decide to use the library.  If people want to use STL, they would program in C++, so differences from STL are not a deficiency.  The key is to have the functionality provided by STL, and any proceeding extensions and convenience routines.  For now, it may be best to implement the new containers alongside existing code.  There is nothing wrong with having duplicate functionality for the time being, as such is better than the absense of functionality that a rewrite can create.  

Revision of calling conventions, in an effort to unify the library, is a good idea.  Since C does not have a namespace feature, a prefix to all globals must serve this purpose, else the standard C namespace can become polluted due to the rather common names currently utilized by this project.  

I will write up a draft HACKING file, defining the coding and calling conventions, based on what you have proposed.  Long method names are usually not a problem, as a method name should give a distinct idea as to its purpose.  The GNU coding standards contain many good ideas in good design.  *This may not be the best name for the parameter of the container methods, as it has no meaning outside of an object oriented language.  Until (if such may be the case) an object system is put in place, the currently used *l should be fine and correct.  

Maybe container structures should contain function pointers, so that one may do l->size(), or l->sort().  In this context the *This parameter would come into use (perhaps better spelled *this as only constants should contain capitals).   

I am interested in working on a string container.  I can integrate my parsing code into this.  

A doubly linked list, as such that is currently implemented, and the ability to insert at the beginning or end make the deque unnecessary.  Queue functions should be added to list.c:  yacl_list_push(struct list *l, void *data, size_t size) and yacl_list_pop(struct list *l).  These functions and functions with the _head suffix should be added.  The push functions would be aliases for the addElem functions.  The pop functions would return the data of the element at the end or beginning of the list and delete the element.  

I have already made the conversion to the ChangeLog.  

The library also works on NetBSD, as I have a computer that runs it.  

Since all currently appears to be in good condition in the library as it is, as far as usability goes, it may be a good idea to put out a 0.2.0 release.

Thanks for your time.

Regards,
Jeffrey Bedard

[Yetanotherclib-devel] Library future.

[darek <ch...@wp...>]

Hello!!!
I was on vacation last week so I can't reply to your emails. I have some 
new ideas about future development of  library.
1. I think we should start from scratch, that is we should start writing 
everything from beginnig and try to stay close to STL as much as possible.
2. What coding conventions we should use??
I think that for containers  functions could have name:

container_method_name(container *This,/* rest of parameters */);

For example:
list_size(list *This);
list_sort(list *This);
vector_size(vector *This);
vector_begin();
etc.??
Eventually:
yacl_list_size(list *This);
but I don't know that with this coding convention(with prefix 
yacl_container) function names wouldn't be too long??
I think that this is a good idea to make typedefs to struct rather than 
writing struct word before every function parameter.
If defines is simulating containers method it still should be in low 
letters for example:
vector_size()
in future it could be implemented as inline function.
What do you think about my new ideas??
If you like it please let me know and if you don't please let me know 
why you don't like it.

3. I think we should start from implementing containers in STL:
- list,
- vector,
- deque,
- set,
- multiset,
- map,
- multimap.
- string.

I've started implementing list container, I think it will be ready till 
next month.
I think that every developer should declare what kind of  container he 
would like to implement. Please send to list
email with such declaration. The sooner we get such declarations the 
sooner work can be done. In next week
I post some code on the list so you will have better picture of my ideas.

After that we could start to implement stack, queue, priority_queue.
After that we could start to implement algorithms.

4. I like very much idea with error codes as enumerations and I think 
error codes should have prefix yacl.

5. ChangeLog also good idea, I think we should remove all logs from 
source files to ChangeLog.

6. We should rename tab.c to vector.c.

7. If  I've forgotten something or you have some other ideas about 
future development of library please let me know.

8. Every comment about portability is very welcome I know two operating 
systems(Windows and Linux various compilers on them) and I feel that
some developers are more experienced with other OSes, so let us know if 
you've found some problems(dprintf is a good example).

Best and thanks for involvment in developing library.
Darek Ostolski

[Yetanotherclib-devel] dprintf namespace conflicts

[Jeffrey B. <je...@e-...>]

Hello.

The function dprintf() conflicts with a GNU extension of the same name.  This means that any program that links with yaclib and also uses GNU extensions will fail compilation with an error indicating a previous definition of dprintf at stdio.h.  The standard library includes a warn function with the same functionality, though it is not recommended as it is a BSD-specific function.  The most portable solution to this problem is an fprintf to stderr, as fprintf is of course a standard library function available everywhere.  Another idea to consider is the use of error(), though this solution is less likely as its availability across platforms may be limited.  The only convenience that the dprintf function included in YAclib provides is a call without the necessity of specification of stderr.  Therefore, for the usefulness of this library within projects utilizing the GNU extensions, I will replace instances of dprintf() with fprintf(stderr,).  

Regards,
Jeff

[Yetanotherclib-devel] ChangeLog as replacement for log in source headers.

[Jeffrey B. <je...@e-...>]

Hello.
I have generated a ChangeLog that serves as a global record of changes, which is useful for developers in quickly locating changes and for users in being able to differentiate between releases.  Some files contain logs in their headers.  The global ChangeLog contains all revisions since yaclib was imported onto the sourceforge CVS server, but not changes before that.  If you approve, I will manually add the changes that occurred before the sourceforge import to ChangeLog and remove the log headers from the files in question.  
Regards,
Jeffrey Bedard

Re: [Yetanotherclib-devel] Greetingz

[Jeffrey B. <je...@e-...>]

Hello.

The macros that you added are good and will enhance convenience of list access.  It is also a good idea to differentite the error codes, and many other globals, with the yacl_ or yaclib_ prefix (capitalized for constants).  The error codes should also be enumerations, rather than define statements.  I will make the conversion to enumerations, but I will hold back on adding the prefix until other developers share their thoughts on this.

Regards,
Jeffrey Bedard

Re: [Yetanotherclib-devel] Tools

[Darek O. <ost...@2p...>]

Jeffrey Bedard wrote:

>Hello.
>The build files of which you speak, unless they are not checked into the repository, are specific to Windows.  The Makefile
>
Yes you are right. This was just for your consideration, that we should 
be very carefull about warnings given with compilers.
I think that splint is very useful tool, it helps to catch bugs before 
program runs, so various extra warnings given by gcc, so I suggest you to
use splint and  all warnings turned on. It is very important espacially 
with C and pointers.

> that  I created in src allows the library to be built on unix.  I am familiar with use of splint, so I may add a target for such source checking.  Does your build environment on windows include ports of unix utilities (for example, cygwin)?  If so a unified Makefile can be created, along with a configuration script.  
>  
>

I'm currently using mingw+MinGW Developer Studio as IDE(I think there is 
port on Linux also), it can generate Makefiles, but as far as I know it 
can't generate configuration script(that is configure). In main 
directory there is yetanotherlib.msp this is project file used by this 
IDE. I'm currently using Linux at home as my OS, I have some experience 
with autotools(that is automake etc), but I'm not feel very comfortable 
with writing them, so I'm very happy to have developer with your skills 
in this matter.

Best
Darek

Re: [Yetanotherclib-devel] Tools

[Jeffrey B. <je...@e-...>]

Hello.
The build files of which you speak, unless they are not checked into the repository, are specific to Windows.  The Makefile that  I created in src allows the library to be built on unix.  I am familiar with use of splint, so I may add a target for such source checking.  Does your build environment on windows include ports of unix utilities (for example, cygwin)?  If so a unified Makefile can be created, along with a configuration script.  
Jeff

[Yetanotherclib-devel] Tools

[Darek O. <ost...@2p...>]

Hello!!!
I'm currently using such tools:
- splint for static source checking,
- sources are compiled with gcc with this options turned on:
    -Wall
    -W
    -pedantic-errors
    -Werror
- for generating documentation I'm currently using doxygen.


Best
Darek

[Yetanotherclib-devel] Future development.

[Jeffrey B. <je...@e-...>]

I am examining the code of the library piece by piece.  Today I have written a makefile for the src dir and I am working on parse code in the test directory.  It will be committed soon.  Today I hope to finish the generic string lexer and various string-specific convenience functions.  The purpose of a generic lexer is simply to split a string into a list of words.  Later parsing code will keep track of each command identifier string and its amount of parameters, allowing for quick creation of simple command languages.  Such features are useful in programs for interpretation, compilation, configuration, and extension.  It is such that I also hope to use in my AntiRight project to create a user interface definition language to replace the current practice of defining user interfaces at the arshell command line.