Here we go again...
Version 0.1.2 is an RFC. Don't use it unless you are really adventurous.
The size of the tarball has grown by a factor of 6, mostly due to the
symbol files.
URLs:
http://www.bee.lk/people/anuradha/kernelconf/
http://www.lklug.pdn.ac.lk/~anuradha/kernelconf/
Getting menuconfig to work correctly is my first priority at this stage. Then
I will get to oldconfig. The menu style in this version is fixed. Pretty soon
the user will be able to set the look and feel. Yes. Including the good old
thing ;)
Derived values (such as turning on RTC when SMP is set) are working well, but
this is just a quick hack to test it. The `real' program will prompt the user
whether such changes are to be done or not.
CML1 config.in files were convereted to kernelconf format with a simple awk
script. There may be errors.
ChangeLog for 0.1.2:
- Moved lxdialog from scripts/ to conf/
- Values defined with "value:" are frozen
- Almost all the symbols for i386 in .conf files
- Reading config files
- Vi compatible up and down movements (j and k) in lxdialog (menuconfig)
- Integer, hex and character input/read/write
- Symbols and menu handling done with a single tree
- Made every tristate symbol's module value depend on CONFIG_MODULES
- Made expression evaluation more sane
- Better error handling
- Lots of code cleanups
Known issues:
- ttyconfig is broken in this version.
- Menuconfig has some problems when handling the last item.
Can do a quick and dirty fix, but I thought of addressing this
issue when working on style selection.
- Many symbols have duplicates. The reading routine handles most
of them properly, but eventually, these entries would unify.
- Some symbols (notably in framebuffer section) were not convereted
at all.
- Many quick hacks here and there to get the program "working".
Most of this code will disapper during the next week.
Anuradha
--
Debian GNU/Linux (kernel 2.4.16-xfs)
You are absolute plate-glass. I see to the very back of your mind.
-- Sherlock Holmes
On Thu, Jan 24, 2002 at 12:45:48PM +0600, Anuradha Ratnaweera wrote:
>
> Here we go again...
>
> Version 0.1.2 is an RFC. Don't use it unless you are really adventurous.
> The size of the tarball has grown by a factor of 6, mostly due to the
> symbol files.
Hi Anuradha.
I have not looked into the SRC, but IIRC you mentioned an interest in LEX/YACC for CML2.
Take a look at:
http://www.alphalink.com.au/~gnb/cml2
This is an incomplete implementation of a CML2 parser + semantic analysis in C utilising a bison parser.
Sam
Sam Ravnborg wrote:
> On Thu, Jan 24, 2002 at 12:45:48PM +0600, Anuradha Ratnaweera wrote:
>
>>Here we go again...
>>
>>Version 0.1.2 is an RFC. Don't use it unless you are really adventurous.
>>The size of the tarball has grown by a factor of 6, mostly due to the
>>symbol files.
>>
>
> Hi Anuradha.
> I have not looked into the SRC, but IIRC you mentioned an interest in LEX/YACC for CML2.
> Take a look at:
> http://www.alphalink.com.au/~gnb/cml2
>
> This is an incomplete implementation of a CML2 parser + semantic analysis in C utilising a bison parser.
Hmm. This is the 3rd C cml2 implementation I have heard. (+ non CML2 based Kernelconfig).
People, don't waste the time! Please merge the projects (They will be only one).
giacomo
PS: THe other projects are in sourceforge: one subproject in 'kbuild', and the
other is 'cml2config'.
Giacomo Catenazzi wrote:
>
> Sam Ravnborg wrote:
>
> > On Thu, Jan 24, 2002 at 12:45:48PM +0600, Anuradha Ratnaweera wrote:
> >
> >>Here we go again...
> >>
> >>Version 0.1.2 is an RFC. Don't use it unless you are really adventurous.
> >>The size of the tarball has grown by a factor of 6, mostly due to the
> >>symbol files.
> >>
> >
> > Hi Anuradha.
> > I have not looked into the SRC, but IIRC you mentioned an interest in LEX/YACC for CML2.
> > Take a look at:
> > http://www.alphalink.com.au/~gnb/cml2
> >
> > This is an incomplete implementation of a CML2 parser + semantic analysis in C utilising a bison parser.
>
> Hmm. This is the 3rd C cml2 implementation I have heard. (+ non CML2 based Kernelconfig).
>
> People, don't waste the time! Please merge the projects (They will be only one).
>
I took the time to download and look at Anuradha's work yesterday.
It seems nice, sensible and sane. I suspect it would have saved
Linus many hours work.
-
On Thu, Jan 24, 2002 at 11:47:04PM +0100, Sam Ravnborg wrote:
> On Thu, Jan 24, 2002 at 12:45:48PM +0600, Anuradha Ratnaweera wrote:
> >
> > Here we go again...
>
> I have not looked into the SRC, but IIRC you mentioned an interest in
> LEX/YACC for CML2. Take a look at:
>
> http://www.alphalink.com.au/~gnb/cml2
>
> This is an incomplete implementation of a CML2 parser + semantic analysis in
> C utilising a bison parser.
My program is not related to neither CML2 nor yacc nor bison.
Anuradha
--
Debian GNU/Linux (kernel 2.4.16-xfs)
Truly great madness can not be achieved without significant intelligence.
-- Henrik Tikkanen
On Fri, Jan 25, 2002 at 09:03:47AM +0100, Giacomo Catenazzi wrote:
> Sam Ravnborg wrote:
> >
> > This is an incomplete implementation of a CML2 parser + semantic analysis
> > in C utilising a bison parser.
>
> Hmm. This is the 3rd C cml2 implementation I have heard. (+ non CML2 based
> Kernelconfig).
This is not a CML2 implementation, it is not bison. It has entirely new,
simple config file format.
Anuradha
--
Debian GNU/Linux (kernel 2.4.16-xfs)
/earth is 98% full ... please delete anyone you can.
On Fri, Jan 25, 2002 at 04:07:34PM +0600, Anuradha Ratnaweera wrote:
> >
> > This is an incomplete implementation of a CML2 parser + semantic analysis in
> > C utilising a bison parser.
>
> My program is not related to neither CML2 nor yacc nor bison.
It was not obvious from the context but I was referring to a mail you
sent some time ago when you announced this project:
http://marc.theaimsgroup.com/?l=linux-kernel&m=101168996304715&w=2
"I'd love to write a CML2 compiler in
C, but it doesn't look like a viable alternative."
Following the discussion on LKML and the KBUILD list people
dislike the choice of Phython version 2.x for the actual
implementation of the CML2 "compiler" and frontends.
In general few people has argued against the language itself.
Therefore my intention was to point you in the direction of
an although incomplete implementation of a CML2 compiler
written in C.
This could give you the possibility to use the well documented
and by several people already accepted CML2 language, but at the
same time you had the flexibility to create your own front-end.
Sam
Hi,
The atachmend is a little beta/patch to your kernelconf.
It adds xconfig capability to kernelconf, by using Tcl/Tk scripts.
It's still a little bit beta, but the main parts like config file
loading/storing, menu-deps ... are implemented.
The main disatvantage for the moment: it doesn't looks like the original
xconfig, but i'm working on it.
MfG,Christian Koenig (and sorry for my poor english)
On Tue, Feb 05, 2002 at 09:01:17PM +0100, Christian Koenig wrote:
>
> The atachmend is a little beta/patch to your kernelconf. It adds xconfig
> capability to kernelconf, by using Tcl/Tk scripts. It's still a little bit
> beta, but the main parts like config file loading/storing, menu-deps ... are
> implemented.
Thanks.
I will include it _after_ the next release (0.1.3) which will come out within a
couple of days. Structure of kernelconf has changed a bit, so we will have to
do some sync. Also, binaries for each type of config are seperate.
BTW, seems as if you have forgotton to `make clean' before making the patch ;)
Anuradha
--
Debian GNU/Linux (kernel 2.4.17)
If you can't get your work done in the first 24 hours, work nights.
> Therefore my intention was to point you in the direction of
> an although incomplete implementation of a CML2 compiler
> written in C.
> This could give you the possibility to use the well documented
> and by several people already accepted CML2 language, but at the
> same time you had the flexibility to create your own front-end.
Sorry, but I cannot understand, if a new text parser is going to be
written. I tried to compare a parser, written by my self in C and
in lex+yacc. The second was 4 times quicker and 4 times easier to write,
so can I repeat the question:
how syntax is parsed ?