Re: stream_cast and Re: LyXFunc/LyXAction

(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 16:49:54 +1000 (GMT+1000

Re: stream_cast and Re: LyXFunc/LyXAction

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

Re: stream_cast<> and Re: LyXFunc/LyXAction

string: string a = stream_cast<string, int>(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: LyXF

Re: stream_cast<> and Re: LyXFunc/LyXAction

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

Re: stream_cast and Re: LyXFunc/LyXAction

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

Re: stream_cast and Re: LyXFunc/LyXAction

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 signs

Re: stream_cast<> and Re: LyXFunc/LyXAction

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

Re: stream_cast<> and Re: LyXFunc/LyXAction

> 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

Re: stream_cast and Re: LyXFunc/LyXAction

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 time

Re: stream_cast<> and Re: LyXFunc/LyXAction

> 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

Re: stream_cast and Re: LyXFunc/LyXAction

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 list? Perhaps

Re: stream_cast and Re: LyXFunc/LyXAction

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

Re: stream_cast and Re: LyXFunc/LyXAction

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 agree

Re: stream_cast<> and Re: LyXFunc/LyXAction

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

Re: stream_cast<> and Re: LyXFunc/LyXAction

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

Re: stream_cast<> and Re: LyXFunc/LyXAction

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

Re: stream_cast and Re: LyXFunc/LyXAction

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 lisence

Re: stream_cast<> and Re: LyXFunc/LyXAction

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

Re: stream_cast and Re: LyXFunc/LyXAction

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.

Re: stream_cast and Re: LyXFunc/LyXAction

"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

Re: stream_cast and Re: LyXFunc/LyXAction

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 list

Re: stream_cast<> and Re: LyXFunc/LyXAction

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.

Re: stream_cast<> and Re: LyXFunc/LyXAction

"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

Re: stream_cast<> and Re: LyXFunc/LyXAction

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

Re: stream_cast and Re: LyXFunc/LyXAction

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 in the first

Re: stream_cast and Re: LyXFunc/LyXAction

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

Re: stream_cast<> and Re: LyXFunc/LyXAction

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

Re: stream_cast<> and Re: LyXFunc/LyXAction

> 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

Re: stream_cast and Re: LyXFunc/LyXAction

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

Re: stream_cast and Re: LyXFunc/LyXAction

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

Re: stream_cast and Re: LyXFunc/LyXAction

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

Re: stream_cast and Re: LyXFunc/LyXAction

"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 and

Re: stream_cast<> and Re: LyXFunc/LyXAction

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

Re: stream_cast<> and Re: LyXFunc/LyXAction

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

Re: stream_cast<> and Re: LyXFunc/LyXAction

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

Re: stream_cast<> and Re: LyXFunc/LyXAction

"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

Re: stream_cast and Re: LyXFunc/LyXAction

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. Well,

Re: stream_cast and Re: LyXFunc/LyXAction

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

Re: stream_cast and Re: LyXFunc/LyXAction

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_caststring, string will be a no op, as will stream_castint, int.

Re: stream_cast<> and Re: LyXFunc/LyXAction

> 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.

Re: stream_cast<> and Re: LyXFunc/LyXAction

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

Re: stream_cast<> and Re: LyXFunc/LyXAction

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

Re: stream_cast and Re: LyXFunc/LyXAction

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

Re: stream_cast and Re: LyXFunc/LyXAction

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

Re: stream_cast and Re: LyXFunc/LyXAction

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 context) So

Re: stream_cast and Re: LyXFunc/LyXAction

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 time? |

Re: stream_cast and Re: LyXFunc/LyXAction

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

Re: stream_cast and Re: LyXFunc/LyXAction

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 strings

Re: stream_cast and Re: LyXFunc/LyXAction

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 I getting

Re: stream_cast and Re: LyXFunc/LyXAction

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 strings in

Re: stream_cast and Re: LyXFunc/LyXAction

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

Re: stream_cast<> and Re: LyXFunc/LyXAction

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

Re: stream_cast<> and Re: LyXFunc/LyXAction

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

Re: stream_cast<> and Re: LyXFunc/LyXAction

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

Re: stream_cast<> and Re: LyXFunc/LyXAction

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

Re: stream_cast<> and Re: LyXFunc/LyXAction

> 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

Re: stream_cast<> and Re: LyXFunc/LyXAction

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

Re: stream_cast<> and Re: LyXFunc/LyXAction

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

Re: stream_cast<> and Re: LyXFunc/LyXAction

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

Re: stream_cast<> and Re: LyXFunc/LyXAction

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