parser-devel

[Parser-devel] Parser is ready

[Jinesh K J <jin...@gm...>]

Hi Noam,

So in the end, the parser library is ready to go. You might wanna go
to trunk/ and modify some stuff yourself. May be you wanna add your
name into the MAINTAINERS file or something else too.

One thing that you've not yet done is the documentation of the new
functions. If you like to do it, may be you can start learning
Doxygen. Let me know if you want me do it for you - if you are not
comfortable with code documentation.

Since all the functionalities are in place you might also wanna make
it (new functions) more modularised. Its up to you.

I'm waiting for your reply so that the next release can be made. Don't
worry, I'm not in a hurry.

Regards,

Jinesh.

Re: [Parser-devel] Parser is ready

[Noam P. <npo...@uw...>]

"Jinesh K J" <jin...@gm...> writes:

> I'm resending the mail - I believe your mail server did not accept the
> original one as given below:
Yes, I had a core dump file filling my quota.

> On 10/12/06, Jinesh K J <jin...@gm...> wrote:
>> Hi Noam,
>>
>> So in the end, the parser library is ready to go. You might wanna go
>> to trunk/ and modify some stuff yourself. May be you wanna add your
>> name into the MAINTAINERS file or something else too.
>>
>> One thing that you've not yet done is the documentation of the new
>> functions. If you like to do it, may be you can start learning
>> Doxygen. Let me know if you want me do it for you - if you are not
>> comfortable with code documentation.

I'll see if I can handle it, doesn't look too different from TeX.

>> Since all the functionalities are in place you might also wanna make
>> it (new functions) more modularised. Its up to you.

I guess there is a bit of duplication with copy stuff up to char X...

Do you think it would be worth making a gettoken_noalloc? It would
save one memory allocation in getgroup.

>> I'm waiting for your reply so that the next release can be made. Don't
>> worry, I'm not in a hurry.
>>
>> Regards,
>>
>> Jinesh.
>>

Re: [Parser-devel] Parser is ready

[Jinesh K J <jin...@gm...>]

On 10/14/06, Noam Postavsky <npo...@uw...> wrote:
> "Jinesh K J" <jin...@gm...> writes:
>
> > I'm resending the mail - I believe your mail server did not accept the
> > original one as given below:
> Yes, I had a core dump file filling my quota.
>
> > On 10/12/06, Jinesh K J <jin...@gm...> wrote:
> >> Hi Noam,
> >>
> >> So in the end, the parser library is ready to go. You might wanna go
> >> to trunk/ and modify some stuff yourself. May be you wanna add your
> >> name into the MAINTAINERS file or something else too.
> >>
> >> One thing that you've not yet done is the documentation of the new
> >> functions. If you like to do it, may be you can start learning
> >> Doxygen. Let me know if you want me do it for you - if you are not
> >> comfortable with code documentation.
>
> I'll see if I can handle it, doesn't look too different from TeX.
Its very simple. You can see the existing code for example.

>
> >> Since all the functionalities are in place you might also wanna make
> >> it (new functions) more modularised. Its up to you.
>
> I guess there is a bit of duplication with copy stuff up to char X...
>
> Do you think it would be worth making a gettoken_noalloc? It would
> save one memory allocation in getgroup.
It doesn't matter(atleast for the time being), even if we do
unnecessary memory allocations - what do need is to make sure that
there is no memory leak. We all know that getgroup() returns an
malloc'ed string upon success - but if gettoken() is called by
getgtroup(), then its the responsibility of getgroup() to free() it
before returning. If such things are made sure then I believe there's
nothing to worry.

If you think you can make more optimisations over the stuff, then we
can make a different branch for you to work on. After your tweaks, we
can merge it to the main trunk. What do you say?

PS : I have a major overhaul for the library in my mind - the API's
will change then. But your code will still remain the same(coz that's
the core) - so you can do your tweaking without affecting my work !

>
> >> I'm waiting for your reply so that the next release can be made. Don't
> >> worry, I'm not in a hurry.
> >>
> >> Regards,
> >>
> >> Jinesh.
> >>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Parser-devel mailing list
> Par...@li...
> https://lists.sourceforge.net/lists/listinfo/parser-devel
>

Re: [Parser-devel] Parser is ready

[Noam P. <npo...@uw...>]

"Jinesh K J" <jin...@gm...> writes:

> If you think you can make more optimisations over the stuff, then we
> can make a different branch for you to work on. After your tweaks, we
> can merge it to the main trunk. What do you say?

Yes, I want to do a few things, but already the old branch with the
test cases I was using is slightly out of date. So is there an
easy way to bring it up to date?

I was also wondering if there is an important reason to use char *
instead of const char * in my functions. I always though that a
function should declare char pointers const if it doesn't modify the
string...

Noam

Re: [Parser-devel] Parser is ready

[Jinesh K J <jin...@gm...>]

On 10/17/06, Noam Postavsky <npo...@uw...> wrote:
> "Jinesh K J" <jin...@gm...> writes:
>
> > If you think you can make more optimisations over the stuff, then we
> > can make a different branch for you to work on. After your tweaks, we
> > can merge it to the main trunk. What do you say?
>
> Yes, I want to do a few things, but already the old branch with the
> test cases I was using is slightly out of date. So is there an
> easy way to bring it up to date?
I didn't really understand what you meant by 'out if date'; which is
the updated one? So, you wish to work only on your functions(in
branches/np/) or the entire trunk/ ?

Also, kindly see whether your code can be made more readable - coz
that's very important as far as collaborative efforts are concerned.

>
> I was also wondering if there is an important reason to use char *
> instead of const char * in my functions. I always though that a
> function should declare char pointers const if it doesn't modify the
> string...
>
Yes. you're right. I just changed them to char * to remove a few
warnings (I dont really remember where they were). But we can surely
re-introduce the 'const' before the next release.

Also, in the mean time, I'm doing some serious rework over the
transform() function in the transform.c.

Jinesh.

Re: [Parser-devel] Parser is ready

[Noam P. <npo...@uw...>]

"Jinesh K J" <jin...@gm...> writes:

> I didn't really understand what you meant by 'out if date'; which is
> the updated one? So, you wish to work only on your functions(in
> branches/np/) or the entire trunk/ ?

'out of date' means not updated, or old. Basically I want to work on
the version of my functions from the trunk/ because they are the
updated ones, but I want to use the testcases from branches/np/

> Also, kindly see whether your code can be made more readable - coz
> that's very important as far as collaborative efforts are concerned.

I would like to make my code more readable, but the problem is that it
looks readable to me because I wrote it. I would greatly appreciate it
if you could tell me what makes it less readable and/or ways to make
it more readable.

>>
>> I was also wondering if there is an important reason to use char *
>> instead of const char * in my functions. I always though that a
>> function should declare char pointers const if it doesn't modify the
>> string...
>>
> Yes. you're right. I just changed them to char * to remove a few
> warnings (I dont really remember where they were). But we can surely
> re-introduce the 'const' before the next release.
>
> Also, in the mean time, I'm doing some serious rework over the
> transform() function in the transform.c.

Actually after I sent that, I thought of a reason to keep it as char*:
it would allow changing the implementation to one that modifies the
string. I guess we should figure out if transform() requires that the
string remains constant, after you finish your reworking of course.

Noam

Re: [Parser-devel] Parser is ready

[Jinesh K J <jin...@gm...>]

On 10/17/06, Noam Postavsky <npo...@uw...> wrote:
> "Jinesh K J" <jin...@gm...> writes:
>
> > I didn't really understand what you meant by 'out if date'; which is
> > the updated one? So, you wish to work only on your functions(in
> > branches/np/) or the entire trunk/ ?
>
> 'out of date' means not updated, or old. Basically I want to work on
> the version of my functions from the trunk/ because they are the
> updated ones, but I want to use the testcases from branches/np/
Then what you may do is:

svn copy trunk/file.c branches/np/
svn copy trunk/transform.c branches/np/

file.c contains puttoken() whereas the rest are in transform.c

You may then change the branches/np/Makefile to use these files
instead of token.c and comment.c. After each satisfactory
modifications you make, we will merge these files back into the
trunk/.

>
> > Also, kindly see whether your code can be made more readable - coz
> > that's very important as far as collaborative efforts are concerned.
>
> I would like to make my code more readable, but the problem is that it
> looks readable to me because I wrote it. I would greatly appreciate it
> if you could tell me what makes it less readable and/or ways to make
> it more readable.
Yes. I'll try to find out what all things could be done.

>
> >>
> >> I was also wondering if there is an important reason to use char *
> >> instead of const char * in my functions. I always though that a
> >> function should declare char pointers const if it doesn't modify the
> >> string...
> >>
> > Yes. you're right. I just changed them to char * to remove a few
> > warnings (I dont really remember where they were). But we can surely
> > re-introduce the 'const' before the next release.
> >
> > Also, in the mean time, I'm doing some serious rework over the
> > transform() function in the transform.c.
>
> Actually after I sent that, I thought of a reason to keep it as char*:
> it would allow changing the implementation to one that modifies the
> string. I guess we should figure out if transform() requires that the
> string remains constant, after you finish your reworking of course.

My work is now almost over - All my planned tasks have been completed.
Re-introduction of 'const' can be done along this process. Let me know
when you want the changes(in file.c and transform.c) to be merged.

Regards,
Jinesh.