Vesa Jääskeläinen <[EMAIL PROTECTED]> writes:
Hi Vesa,
> I was playing a bit with grub.cfg and following crashes my vmware
> session... :)... I know I didn't remember first that there were
> syntaxtical changes in there, but even after correcting my mistake, it
> doesn't allow me move it with cur
Hi,
I was playing a bit with grub.cfg and following crashes my vmware
session... :)... I know I didn't remember first that there were
syntaxtical changes in there, but even after correcting my mistake, it
doesn't allow me move it with cursor keys, not in console or in video
mode. Pressing enter co
On Nov 8, 2005, at 12:24 PM, Marco Gerards wrote:
Hollis Blanchard <[EMAIL PROTECTED]> writes:
On Nov 6, 2005, at 4:26 PM, Marco Gerards wrote:
Please test if everything still works. Of course I took great care
in
testing and implementing, but a lot changed and I am not perfect.
This week
Hollis Blanchard <[EMAIL PROTECTED]> writes:
> On Nov 6, 2005, at 4:26 PM, Marco Gerards wrote:
>>
>> Please test if everything still works. Of course I took great care in
>> testing and implementing, but a lot changed and I am not perfect.
>> This week I will have some time, so if there are any
On Nov 6, 2005, at 4:26 PM, Marco Gerards wrote:
Please test if everything still works. Of course I took great care in
testing and implementing, but a lot changed and I am not perfect.
This week I will have some time, so if there are any problems
reported, they should be fixed in no time.
Cou
Marco Gerards <[EMAIL PROTECTED]> writes:
> Marco Gerards <[EMAIL PROTECTED]> writes:
>
> Hi,
>
>> Here is the patch I promised last week. It is far from perfect and
>> will most likely break one or two things, but I think it is worth the
>> trouble to add it for the following reasons:
>
> Here i
"adrian15" <[EMAIL PROTECTED]> writes:
>> > I think also. Because theese modifications are lost after boot they >
>> are generally modified only to boot one time an OS with specifical >
>> parameters and you don't need scripts for this.
>>
>> Right. The only reason I see for editing the script i
' was removed for now. I will restore it, but for now you
> have to use `set foo=bar'.
>
> - The syntax it supports is not loose enough yet. For example, this
> does not work:
>
> if [ $a=foo ]; then ls else help fi
This is somewhat improved.
Thanks,
Marco
200
> > I think also. Because theese modifications are lost after boot they >
> are generally modified only to boot one time an OS with specifical >
> parameters and you don't need scripts for this.
>
> Right. The only reason I see for editing the script in general is to
> edit some menu generation r
On Tuesday 01 November 2005 08:06 pm, Marco Gerards wrote:
> To which value should grub_err_t be set on function return in the case
> of the test command? I could add a new error `GRUB_ERR_TEST_RESULT'
> and make it 1. I would prefer some better suggestion though :).
Vladimir used GRUB_ERR_TEST_
Marco Gerards <[EMAIL PROTECTED]> writes:
> "Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes:
>
>> On Sunday 30 October 2005 10:04 pm, Marco Gerards wrote:
>>> > I really don't like that each command has to explicitly set RESULT. As
>>> > you note, it would be better if the return code from the com
"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes:
> On Sunday 30 October 2005 10:04 pm, Marco Gerards wrote:
>> > I really don't like that each command has to explicitly set RESULT. As
>> > you note, it would be better if the return code from the command were
>> > automatically placed into the stat
On Sunday 30 October 2005 10:04 pm, Marco Gerards wrote:
> > I really don't like that each command has to explicitly set RESULT. As
> > you note, it would be better if the return code from the command were
> > automatically placed into the status environment variable.
>
> Most command return grub_e
On Sunday 30 October 2005 03:41 pm, Vladimir Serbinenko wrote:
> After discussion with Marco on IRC we decided that his code is better
> for the core features and other things are fast to implement.
I feel very happy with that both of you have agreed.
Okuji
_
Hollis Blanchard <[EMAIL PROTECTED]> writes:
> I don't have many comments, since I'm not familiar with lexing and
> parsing. Just a couple small comments:
>
> On Oct 29, 2005, at 4:41 PM, Marco Gerards wrote:
>>
>> `if' accepts any command. I showed the example of using the `['
>> command. It ca
I don't have many comments, since I'm not familiar with lexing and
parsing. Just a couple small comments:
On Oct 29, 2005, at 4:41 PM, Marco Gerards wrote:
`if' accepts any command. I showed the example of using the `['
command. It can be made similar to the `[' command of coreutils.
This co
Vladimir Serbinenko <[EMAIL PROTECTED]> writes:
> Marco Gerards wrote:
>
>>Vladimir Serbinenko <[EMAIL PROTECTED]> writes:
>>
>>So the problem with approach #1 is doing double work, less obvious
>>integration with the rest of the parser and memory leakage.
>>
>>
> Of course in real code it would b
Marco Gerards wrote:
Vladimir Serbinenko <[EMAIL PROTECTED]> writes:
So the problem with approach #1 is doing double work, less obvious
integration with the rest of the parser and memory leakage.
Of course in real code it would be freed. It was just schemathical
Right. The only reason I
Vladimir Serbinenko <[EMAIL PROTECTED]> writes:
>>I think you have to parse it immediately and both store parsed and the
>>unparsed code. After editing you do the same again.
>>
> I see 2 approaches:
> 1) Parse menu commands right before executing
> 2) Parse them directly and reparse after editin
Marco Gerards wrote:
I didn't know that bison had such buffer.
It doesn't. This buffer is created by lexer in my example.
And menu is always stored unparsed and parsed only just before
execution. Than editing is no problem.
I think you have to parse it immediately and both store p
Vladimir Serbinenko <[EMAIL PROTECTED]> writes:
> But the next questions are menu entries. I propose the following syntax:
> menu [arguments] name
> {
> Commands
> }
>
> arguments can be --default, --fallback perhaps some more in the future.
>
> But the main question is about realization. We n
After discussion with Marco on IRC we decided that his code is better
for the core features and other things are fast to implement.
But the next questions are menu entries. I propose the following syntax:
menu [arguments] name
{
Commands
}
arguments can be --default, --fallback perhaps some m
"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes:
> On Sunday 30 October 2005 10:45 am, Marco Gerards wrote:
>> Right, I felt it hard to explain the direction I'd like to take on
>> this list. So I have implemented the core functionality because that
>> definitely has to be right.
>
> I don't know
On Sunday 30 October 2005 10:45 am, Marco Gerards wrote:
> Right, I felt it hard to explain the direction I'd like to take on
> this list. So I have implemented the core functionality because that
> definitely has to be right.
I don't know what direction you would like yet. It is hard to figure o
"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes:
> Now, both Marco and Vladimir work on the scripting support separately, and
> I'm
> glad to see the development going well. However, we must choose either of
> them (or even none of them, if both are not good
"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes:
> Now, both Marco and Vladimir work on the scripting support separately, and
> I'm
> glad to see the development going well. However, we must choose either of
> them (or even none of them, if both are not good
Now, both Marco and Vladimir work on the scripting support separately, and I'm
glad to see the development going well. However, we must choose either of
them (or even none of them, if both are not good ;) to integrate a result
into the official code.
I understand that there ar
ail.
I don't think I will work on lsb.c or on the language constructs
itself, unless no comes up with something I like. :-)
Thanks,
Marco
2005-10-29 Marco Gerards <[EMAIL PROTECTED]>
Add initial scripting support.
* commands/lsb.c: New file.
* conf/i386-pc.r
On Saturday 22 October 2005 04:46 pm, Vladimir Serbinenko wrote:
> I propose the following argorithm. Bison parser transforms the text-form
> to internal form of a linked list of commands with some special commands
> like jump if last value was true, ... . Think about assembler. Then it's
> execute
Vladimir Serbinenko <[EMAIL PROTECTED]> writes:
>>I think we first have to determine:
>>
>>1) Which commands should be supported.
>>
>>
> What about && || ! case do done elif else esac fi for function if in
> then until while { } [[ ]]
This sounds fine to me. Although I don't remember !, { } and
I have in
mind. It is not that much work. The hard part is "filling in" the
framework so you get scripting support. Please tell me what you
think, or we could talk about it on IRC.
Thanks,
Marco
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Marco Gerards wrote:
Vladimir Serbinenko <[EMAIL PROTECTED]> writes:
I think we first have to determine:
1) Which commands should be supported.
What about
&& || ! case do done elif else esac fi for function if in then until
while { } [[ ]]
in scripting engine. I think that time is co
Vladimir Serbinenko <[EMAIL PROTECTED]> writes:
>>That can be translated into some kind of pseudo language:
>>
>>1: list = 1 2 3
>>2: read i, list
>>3: echo $i
>>4: check list
>>5: je 2
>>
>>I know it's stupid and kind of silly like this. But we have to define
>>a language. It's important to dis
Hello
In bash when you define a function it appears under environment
variables. IMHO it's useless to store completely the source code as an
environment variables. I propose that the functions will be preparsed
(converted to internal format ready for execution) because it will
gretelya simp
Vladimir Serbinenko <[EMAIL PROTECTED]> writes:
Hi Vladimir,
>>Last days I have been thinking about scripting support. With my last
>>patch it should be easy to implement. I hope Vladimir is still
>>interested in this.
>>
>>
> Yes. Exactly now I'm on
Marco Gerards wrote:
Hi,
Last days I have been thinking about scripting support. With my last
patch it should be easy to implement. I hope Vladimir is still
interested in this.
Yes. Exactly now I'm on holiday so I have a lot of time. And also I have
some ideas for some new GRUB fea
Hi,
Last days I have been thinking about scripting support. With my last
patch it should be easy to implement. I hope Vladimir is still
interested in this.
The most important is the general design. I think we shouldn't put
too much in the core and not even in normal mode. This is the
37 matches
Mail list logo
