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
= 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
> 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
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
Allan Rae <[EMAIL PROTECTED]> writes:
| just another consideration). With regard to the speed arguement though,
| when using a single string there is the added costs of parsing which Lars'
| solution, FuncSlot, avoids since all argements must conform to some
| preordained order.
Yes, also note
> 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
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
> 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
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
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
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
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> I want to convert a string to int:
|
| Lars> int a = stream_cast("123");
|
| Lars> or a int to string:
|
| Lars> string a = stream_cast(123);
|
| This looks interestin
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> I want to convert a string to int:
Lars> int a = stream_cast("123");
Lars> or a int to string:
Lars> string a = stream_cast(123);
This looks interesting indeed. The name is a bit weird, since it is
not clear where the strea
32 matches
Mail list logo
