On Fri, Aug 16, 2002 at 06:31:24PM +0100, Angus Leeming wrote:
> This sounds like xtl to me. Would FuncRequest not benefit from this?
Overkill IMNSHO.
_Please_ let's see how far we come using the int,int,button,string
approach.
> unscrambling of stringifications...
We certainly do not do much
On Fri, Aug 16, 2002 at 06:26:35PM +0100, Angus Leeming wrote:
> -- Forwarded Message --
>
> Subject: LyXFunc/LyXAction
> Date: 13 Oct 2000 15:48:08 +0200
> From: [EMAIL PROTECTED] (Lars Gullik Bjønnes)
> To: [EMAIL PROTECTED]
>
> We should make a wa
= stream_cast(123);
This could easily be used for the FuncSlot.
Lgb
---
and I also found Allan's follow up
-- Forwarded Message --
Subject: Re: stream_cast<> and Re: LyXFunc/LyXAction
Date: Thu, 19 Oct 2000
/wanted? Is their an implementation?
Angus
-- Forwarded Message --
Subject: LyXFunc/LyXAction
Date: 13 Oct 2000 15:48:08 +0200
From: [EMAIL PROTECTED] (Lars Gullik Bjønnes)
To: [EMAIL PROTECTED]
We should make a way to ensure that LyXFunc are called with the
correct number of
> However, I don't think XML is a good solution to internal communication,
> and that was what we were discussing at that point.
>
> Do you think so?
I actually prefer some sort of string based "command line interface"
internally (more or less how LyXFunc works today). However, if there were
sig
On Wed, 25 Oct 2000, Andre Poenitz wrote:
> Right. That's why we have been smart in the beginning and chosen some
> format that can be extended. Like
I agree that XML is the better format for external stuff, like the
document format, configuration files, and such. (My primary motivation for
this
> Suppose we have a class with the members variable1 and variable2.
> This is great, and we live with this class for a year, and use the
> layout of it indirectly through XTL.
> Now, it turns out we need a variable3, so what are we to do? We would
> like to support the old layout, but at the same
On 24 Oct 2000, Lars Gullik Bjønnes wrote:
> Allan Rae <[EMAIL PROTECTED]> writes:
>
> | XTL via lyxfunc works (or worked) very nicely. Then the external scripts
> | can call lyxfunc with data directly.
>
> In essence this is passing a complex structure to the lyxfunc, and I
> am not sure if I
Allan Rae <[EMAIL PROTECTED]> writes:
| > You seem to forget that we want access to internal/user visible data
| > structures to be handled through lyxfunc. (and passing structs to
| > lyxfunc (in whatever form) is not nice).
|
| XTL via lyxfunc works (or worked) very nicely. Then the external
Not gone yet but very soon...
On 23 Oct 2000, Lars Gullik Bjønnes wrote:
> Allan Rae <[EMAIL PROTECTED]> writes:
>
> | On 22 Oct 2000, Lars Gullik Bjønnes wrote:
> |
> | > "Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:
> | >
> | > Do you know if anyone has mentioned xtl on the boost
Allan Rae <[EMAIL PROTECTED]> writes:
| On 22 Oct 2000, Lars Gullik Bjønnes wrote:
|
| > "Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:
| >
| > Do you know if anyone has mentioned xtl on the boost list? Perhaps
| > that should be done?
| >
| > Of course to include the xtl in boost the
On 22 Oct 2000, Lars Gullik Bjønnes wrote:
> "Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:
>
> Do you know if anyone has mentioned xtl on the boost list? Perhaps
> that should be done?
>
> Of course to include the xtl in boost the lisence has to change.
Asger sent an email to the XTL
"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:
Do you know if anyone has mentioned xtl on the boost list? Perhaps
that should be done?
Of course to include the xtl in boost the lisence has to change.
(btw. I have serious dubts if xtl is the right thing for lyx
internals.)
Lgb
On Sat, 21 Oct 2000, Andre Poenitz wrote:
(comparision of stream_cast and XTL)
> I did that indeed, but with an eye on the specific environment "LyX".
> The places where (XTL|stream_cast) has to be used are not the performance
> critical parts of LyX nor have I seen the need for nesting so far.
> My point is exactly that you can not directly compare stream_cast and
> XTL. Andre P. did that, and seemed to conclude that XTL was inferior
> to stream_cast.
I did that indeed, but with an eye on the specific environment "LyX".
The places where (XTL|stream_cast) has to be used are not the per
On 19 Oct 2000, Lars Gullik Bjønnes wrote:
> What I'd like to know is how XTL solve:
>
> string line;
> cin >> line;
> int a = stream_cast(line);
>
> or
>
> int b = stream_cast("123");
>
> I do not thing xtl is suited fot that specific task, which was the
> reason why i mentioned stream_cast
"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:
| On 13 Oct 2000, Lars Gullik Bjønnes wrote:
|
| > And the idea to use strings in these places is not really new, either.
| > IIRC the last proposal to use XTL was more or less a direct reaction to
| > this idea, based on the (unvalidated an
On 13 Oct 2000, Lars Gullik Bjønnes wrote:
> And the idea to use strings in these places is not really new, either.
> IIRC the last proposal to use XTL was more or less a direct reaction to
> this idea, based on the (unvalidated and IMNSHO unjustified) assumption
> that using strings might be too
Allan Rae <[EMAIL PROTECTED]> writes:
| On 14 Oct 2000, Lars Gullik Bjønnes wrote:
| [...]
| > more on FuncSlot... when I first though of this it was as a direct
| > replacement for the string that we pass to dispatch now, it is not too
| > hard to create a FuncSlot that can transfere the type un
On 14 Oct 2000, Lars Gullik Bjønnes wrote:
[...]
> more on FuncSlot... when I first though of this it was as a direct
> replacement for the string that we pass to dispatch now, it is not too
> hard to create a FuncSlot that can transfere the type untranslated.
> It would be a larger implementation
John Levon <[EMAIL PROTECTED]> writes:
| On 17 Oct 2000, Lars Gullik Bjønnes wrote:
|
| > LyXAction deals with lookup of LFUNS, LyXFunc deals with execution of
| > LFUNS.
| >
|
| right. I guess one of the things I should do is fill out the src
| documentation !
It is clear from the code :-)
On 17 Oct 2000, Lars Gullik Bjønnes wrote:
> LyXAction deals with lookup of LFUNS, LyXFunc deals with execution of
> LFUNS.
>
right. I guess one of the things I should do is fill out the src
documentation !
> | What are the plans for the lyxfunc redesign ? Can we encapsulate every
> | funct
n for this...first we
| > change the LyXFunc::dispatch to a different type of arg...
| >
|
| I was trying to read the core code this weekend, and I got confused
| between the the two classes LyXFunc/LyXAction. What is their relation ?
| They seem very similar ...
LyXAction deals with
to a different type of arg...
>
I was trying to read the core code this weekend, and I got confused
between the the two classes LyXFunc/LyXAction. What is their relation ?
They seem very similar ...
What are the plans for the lyxfunc redesign ? Can we encapsulate every
function into a certain
Andre Poenitz <[EMAIL PROTECTED]> writes:
| > There is more to externalising than speed.
|
| Agreed. And the string solution is not even slow...
ad. the stream_cast: it is even possible to specialize this if wanted
so that stream_cast will be a no op, as will
stream_cast.
alos stream_cast and
nd FuncSlot
| as XTL would require (although it'll be less than converting everything by
| hand... perhaps).
In the case of the Minibuffer proposal, the LyXFunc/LyXAction +
FuncSlot stream_cast will be the glue and will as far as I can see not
add any bloat at all. Of course if your case is dialogs an
Allan Rae <[EMAIL PROTECTED]> writes:
| On 13 Oct 2000, Lars Gullik Bjønnes wrote:
|
| > Angus Leeming <[EMAIL PROTECTED]> writes:
| >
| > | On Fri, 13 Oct 2000, Jean-Marc Lasgouttes wrote:
| > | > > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| > | >
| > | > Lars> You mean so
> There is more to externalising than speed.
Agreed. And the string solution is not even slow...
> ...
> You would have done better to argue for a strstream solution in your
> original proposal so we could just add a strstream operator<< and
> operator>> for data objects like PrinterParams etc.
On 13 Oct 2000, Lars Gullik Bjønnes wrote:
> Also remember that most of the arguments to lyxfuncs are strings,
> (actually to few of the lyxfuncs take arguments...)
That's only true because that's all that was able to be passed.
Everything else required calling some global function until we in
On Fri, 13 Oct 2000, Andre Poenitz wrote:
> > Am I right in saying that together they effectively give us the functionality
> > of XTL? Or am I getting excited and being stupid at the same time?
>
> No, that's basically what XTL would do - at least in this place.
>
> And the idea to use string
On 13 Oct 2000, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | On Fri, 13 Oct 2000, Lars Gullik Bjønnes wrote:
> | > Angus Leeming <[EMAIL PROTECTED]> writes:
> | > | Am I right in saying that together they effectively give us the
> | > | functionality of XTL? Or am
On 13 Oct 2000, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | On Fri, 13 Oct 2000, Jean-Marc Lasgouttes wrote:
> | > > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
> | >
> | > Lars> You mean so that we can have a centralized testing at the top of
>
On 13 Oct 2000, Lars Gullik Bjønnes wrote:
> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
> |
> | Lars> You mean so that we can have a centralized testing at the top of
> | Lars> the function?
> |
> | I'm not sure what I
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> One other idea togeter with this is to have all the lyxfuncs
| Lars> dynamically loadable...
|
| Or have a proper script language which does that for us?
That is also po
Andre Poenitz <[EMAIL PROTECTED]> writes:
| >
| > You mean so that we can have a centralized testing at the top of the
| > function?
| >
| > dispatch(..)
| > string string_arg
| > char char_arg;
| > ..
| > if (lyxaction.func(LFUN_BUFFER_NEW).arg1 == type_info)
| > string_arg
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> One other idea togeter with this is to have all the lyxfuncs
Lars> dynamically loadable...
Or have a proper script language which does that for us?
JMarc
Angus Leeming <[EMAIL PROTECTED]> writes:
| On Fri, 13 Oct 2000, Jean-Marc Lasgouttes wrote:
| > > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| >
| > Lars> You mean so that we can have a centralized testing at the top of
| > Lars> the function?
| >
| > I'm not sure what I mean
>
> You mean so that we can have a centralized testing at the top of the
> function?
>
> dispatch(..)
> string string_arg
> char char_arg;
> ..
> if (lyxaction.func(LFUN_BUFFER_NEW).arg1 == type_info)
> string_arg = stream_castfuncslot[1]
> .
>
> unless you have a bette
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> You mean so that we can have a centralized testing at the top of
| Lars> the function?
|
| I'm not sure what I mean exactly, but we could declare the arguments
| of the f
On Fri, 13 Oct 2000, Jean-Marc Lasgouttes wrote:
> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
> Lars> You mean so that we can have a centralized testing at the top of
> Lars> the function?
>
> I'm not sure what I mean exactly, but we could declare the arguments
> of the func
Andre Poenitz <[EMAIL PROTECTED]> writes:
| > Am I right in saying that together they effectively give us the functionality
| > of XTL? Or am I getting excited and being stupid at the same time?
|
| No, that's basically what XTL would do - at least in this place.
|
| And the idea to use string
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> You mean so that we can have a centralized testing at the top of
Lars> the function?
I'm not sure what I mean exactly, but we could declare the arguments
of the function so that there type can be checked by dispatch, and the
t
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> What do we need it for?
|
| Lars> Ok, we can get a bit better error reporting but thats about it.
|
| Isn't it better than testing all argument in each case LFUN_xxx?
Y
> Am I right in saying that together they effectively give us the functionality
> of XTL? Or am I getting excited and being stupid at the same time?
No, that's basically what XTL would do - at least in this place.
And the idea to use strings in these places is not really new, either.
IIRC the l
Angus Leeming <[EMAIL PROTECTED]> writes:
| On Fri, 13 Oct 2000, Lars Gullik Bjønnes wrote:
| > Angus Leeming <[EMAIL PROTECTED]> writes:
| > | Am I right in saying that together they effectively give us the
| > | functionality of XTL? Or am I getting excited and being stupid at the
| > | same ti
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> What do we need it for?
Lars> Ok, we can get a bit better error reporting but thats about it.
Isn't it better than testing all argument in each case LFUN_xxx?
JMarc
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
| Lars> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | |
| Lars> Lars> We should make a way to ensure
On Fri, 13 Oct 2000, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> | Am I right in saying that together they effectively give us the
> | functionality of XTL? Or am I getting excited and being stupid at the
> | same time?
>
> Yes, I think they do. (at least in this conte
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
Lars> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | |
Lars> Lars> We should make a way to ensure that LyXFunc are called
Lars> with the | Lars> correct numb
Angus Leeming <[EMAIL PROTECTED]> writes:
| Am I right in saying that together they effectively give us the functionality
| of XTL? Or am I getting excited and being stupid at the same time?
Yes, I think they do. (at least in this context)
Lgb
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> We should make a way to ensure that LyXFunc are called with the
| Lars> correct number of arguments and also that the arguments are of
| Lars> the correct type. I think I
Am I right in saying that together they effectively give us the functionality
of XTL? Or am I getting excited and being stupid at the same time?
A
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> We should make a way to ensure that LyXFunc are called with the
Lars> correct number of arguments and also that the arguments are of
Lars> the correct type. I think I have a nice solution for
Lars> this...first we change the Ly
We should make a way to ensure that LyXFunc are called with the
correct number of arguments and also that the arguments are of the
correct type. I think I have a nice solution for this...first we
change the LyXFunc::dispatch to a different type of arg...
LyXFunc::dispatch(FuncSlot const & funcsl
54 matches
Mail list logo
