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
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 is a new version. If you have some time, please have a
> > 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 ;) to integrate a result
> into the
"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 ;) to integrate a result
> into the
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 are two implementati
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:
1) I don't want to have a big diff between my work on HEAD.
2) It needs to be tested.
3) People can start hack
26 matches
Mail list logo
