> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | What
Lars> about getting rid of it? Even if we decide to use it later,
Lars> we'll | have to seriously update it, no?
Lars> Yes.
Lars> nuke it.
Done.
JMarc
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| What about getting rid of it? Even if we decide to use it later, we'll
| have to seriously update it, no?
Yes.
nuke it.
--
Lgb
What about getting rid of it? Even if we decide to use it later, we'll
have to seriously update it, no?
JMarc
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Just face it, lyxstring is not created for use in modern c++
Lars> libs where several components are dependant upon the existance
Lars> of basci_string<>
OK, so how difficult would it be to use real string on all systems?
I'd
|
| We should probably apply two fixes -- one to XTL for namespace usage and
| one to LString.h to place lyxstring into std namespace if namespaces are
| being used.
On my system that would just give compilation errors.
the problem with std::overflow_exception is in my std lib the
that is beein
On Tue, 25 Apr 2000, Angus Leeming wrote:
> Allan, this one is for you I think.
>
> Attempting to compile the rae branch of CVS with gcc-2.95.2 and
> lyxstring I get the follwing at linking:
>
> Unresolved:
> overflow_error::overflow_error(lyxstring const &)
>
Allan, this one is for you I think.
Attempting to compile the rae branch of CVS with gcc-2.95.2 and lyxstring I get
the follwing at linking:
Unresolved:
overflow_error::overflow_error(lyxstring const &)
This makes sense. In xtl/objio.h we have:
class mem_buffer {
...
pu
simple(type const& data) { \
Angus> space(); \
Angus> unrequire(20-snprintf((char*)require(20), 20, form, data)); \
Angus> }
Lars> What kind of function is this unrequire?
Let's not delve too deep into the internals of xtl! require and unrequire
allows us to trav
Angus Leeming <[EMAIL PROTECTED]> writes:
| What do you use if snprintf() is not defined on your system?
Why will a stringstream not work?
|
| #define def_simple_output(type, form) \
| void output_simple(type const& data) { \
| space(); \
| unrequire(20-snprin
XTL's example code "xdr", designed to test XDR_format now compiles and runs on
Alphas without error using either gcc-2.95.2 or DEC cxx under both LinuxAlpha
and Tru64 unix. Hoorah!
xtl/text.h has problems still and so I have a question for the C gurus out
there:
What do you use i
ld just switch to XDR_format now.
> My plan at present is to use a xml-like format extended from the existing
> text_format. Something like and so on. I
> know it be nice to have the name of the appropriate variable in place of
> the data-type but it a heck of lot easier to write th
On Mon, 3 Apr 2000, Angus Leeming wrote:
> Illuminating, I think. We do indeed use raw_format.
>
> Allan, if we assume that raw_format will be removed from
> xtl at some stage, does that make life harder?
Not really. I wasn't planning on using raw_format forever. Only un
Illuminating, I think. We do indeed use raw_format.
Allan, if we assume that raw_format will be removed from
xtl at some stage, does that make life harder?
Angus
-- Forwarded Message --
Subject: Re: Unaligned access errors running LyX with XTL
Date: Mon, 03 Apr 2000 16:50:25
ines where integers can only be accessed
at two- or four-byte boundaries.
Angus
On Mon, 03 Apr 2000, you wrote:
> >>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> I thought I'd send this here before I post it to the xtl
&g
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
Lars> On a related note, I tried to compile with -frepo (gcc 2.95.2)
Lars> and it | did not work... Does anyone know how this is supposed
Lars> to be possible? | Currently, it
>>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> I thought I'd send this here before I post it to the xtl
Angus> mailing list. Is there anything further that might be useful to
Angus> them?
It looks reasonable... I would say that t
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| On a related note, I tried to compile with -frepo (gcc 2.95.2) and it
| did not work... Does anyone know how this is supposed to be possible?
| Currently, it seems to me that template code is duplicated an unknown
| number of times...
How do yo
I thought I'd send this here before I post it to the xtl
mailing list. Is there anything further that might be
useful to them?
Angus
XTL errors running LyX
=
I have come up against some unaligned access errors
when running a development version of LyX. (The "rae"
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> On 31 Mar 2000, Lars Gullik Bjønnes wrote:
>> Allan Rae <[EMAIL PROTECTED]> writes:
>>
>> | And compile times will increase by at least double. At least
>> that's my | experience so far -- assuming you have plenty of memory
>> and don
> I compile without -g and without optimization.
Whatever for? Surely, you'd want -g at the least to find those bugs
that the rest of us insert in the code to slow you down.
> | > Not only xtl requires exceptions, conforming omplementations of the
> | > C++ standard library also
Allan Rae <[EMAIL PROTECTED]> writes:
| On 30 Mar 2000, Jean-Marc Lasgouttes wrote:
|
| > > "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
| >
| > Allan> If we could compile without exceptions we'd be okay. The
| > Allan> problem is that gcc's header has a line: #include
| > Allan>
| >
Allan Rae <[EMAIL PROTECTED]> writes:
| And compile times will increase by at least double. At least that's my
| experience so far -- assuming you have plenty of memory and don't start
| swapping.
I compile without -g and without optimization.
|
| > Not only xtl
On 30 Mar 2000, Jean-Marc Lasgouttes wrote:
> > "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
>
> Allan> If we could compile without exceptions we'd be okay. The
> Allan> problem is that gcc's header has a line: #include
> Allan>
>
> But if you define __STRING__ before the #include , t
he
> | Lars> lyxstring and use what the system provides instead. Will require
> | Lars> some work, but not a lot. The the sstream problem would just go
> | Lars> away.
> |
> | Yes, we will probably be forced to do that. A consistent STL is
> | prefereable to more complete cla
> "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> Actually the use of streams reduce size (most of the
Lars> time), | Lars> container tend t
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> Actually the use of streams reduce size (most of the time),
| Lars> container tend to enlarge it a bit.
|
| So, where do the 350k of code and 150k of data come from. You
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Actually the use of streams reduce size (most of the time),
Lars> container tend to enlarge it a bit.
So, where do the 350k of code and 150k of data come from. You have not
been *this* busy, have you?
JMarc
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| What are the sections which are of interest? text?
All om them really, but dec most of all.
| fantomas: size lyx
| textdatabss dec hex
| 2760704 540672 123008 3424384 344080
|
| fantomas: size ~/.src/build/src/lyx
| textd
hex
2400256 524288 126416 3050960 2e8dd0
fantomas: size `which lyx`
textdatabss dec hex
2244608 475136 125312 2845056 2b6980
The first one is current cvs, the second 1.1.4fix3, and the third is
1.0.3. Isn't there some strange bloat going on in cvs version? Or is
it
quire
| Lars> some work, but not a lot. The the sstream problem would just go
| Lars> away.
|
| Yes, we will probably be forced to do that. A consistent STL is
| prefereable to more complete classes... However, if we do that and are
| forced by xtl to use exceptions, I fear that code size w
would just go
Lars> away.
Yes, we will probably be forced to do that. A consistent STL is
prefereable to more complete classes... However, if we do that and are
forced by xtl to use exceptions, I fear that code size will explode
for no practical result (do we need exception support from xtl?).
JMarc
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
|
| Allan> If we could compile without exceptions we'd be okay. The
| Allan> problem is that gcc's header has a line: #include
| Allan>
|
| But if you define __STRING__ before the #includ
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> If we could compile without exceptions we'd be okay. The
Allan> problem is that gcc's header has a line: #include
Allan>
But if you define __STRING__ before the #include , then the
include should have no effect... This solution is c
On 29 Mar 2000, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
>
> | src/frontends/xforms/FormPrint.h:
> | -#ifdef __GNUG__
> | -#pragma interface
> | -#endif
> | (These one allows the code to link)
>
> In stead of that you could try to add
> #ifdef __GNUG__
> #pragm
Angus Leeming <[EMAIL PROTECTED]> writes:
| src/frontends/xforms/FormPrint.h:
| -#ifdef __GNUG__
| -#pragma interface
| -#endif
| (These one allows the code to link)
In stead of that you could try to add
#ifdef __GNUG__
#pragma implementation
#endif
to FormPrint.C unless already present.
Ok, Allan, a final report before I go home.
I have managed to compile the "rae" branch of CVS making a
few v.small changes to do so. I can compile with lyxstring
using JMarc's suggested change to LString.h
Having compiled the branch as is, I then made four
tiny changes:
On Mon, 27 Mar 2000, Angus Leeming wrote:
> (Jean-Marc and Allan, there are questions for you buried
> within here ;-)
>
> Many thanks for forwarding my compile problems to the xtl
> list, Asger. Jose (Orlando Pereira) got in touch and
> suggested that the problem would b
tonight or tomorrow
night.
> If the idea of composite() is read from / write to "target" and
> "which_pages" then clearly the write to bit of this won't work with
> the change I've made as it is. An extra couple of lines are needed to
> pass t to target, etc.
I think we'll be better off with separate read/write or fixing xtl to
support enums. Again see my reply to your earlier email.
> NOTE 5. I'm going home!
> Have a good evening,
> Angus
>
Allan. (ARRae)
Hoorah! I have managed to compile the "rae" branch of CVS.
Many, many thanks to Jean-Marc for his suggestions about
integrating lyxstring with xtl, to Asger for passing my
problems with xtl to the xtl mailing list and to Jose
Orlando Pereira the xtl maintainer for his suggestions
Angus Leeming <[EMAIL PROTECTED]> writes:
| The following works:
| template
| void composite(Stream & stream)
| {
| + int t, wp;
| + t = static_cast(target);
| + wp = static_cast(which_pages);
Please use:
ions" causes
compilation to fall over in FormPrint with an internal
compiler error.
NOTE 2. The usual (default) "configure --with-included-string"
produces the following error:
In file included from /usr/local/egcs/include/g++/stdexcept:36,
from ../../../src/xtl/objio.h:3
(Jean-Marc and Allan, there are questions for you buried
within here ;-)
Many thanks for forwarding my compile problems to the xtl
list, Asger. Jose (Orlando Pereira) got in touch and
suggested that the problem would be trivial but that egcs
got confused by the error message.
So... I stripped
On Mon, Mar 27, 2000 at 10:10:41AM +1000, Allan Rae wrote:
> On Sun, 26 Mar 2000, Jose Abilio Oliveira Matos wrote:
>
> He too lives in Portugal. Scary isn't it? Two José's in the same country
> ;-)
Actually is a prety common name.
> (Universidade do Minho, Braga)
BTW that is my home to
On 26-Mar-2000 Jose Abilio Oliveira Matos wrote:
>> Asger
>> BTW: Are you coming to Norway?
>
> Now that you ask, yes I'm thinking very strongly about that.
> That week is the last of classes I need to have someone to replace me at
> the last one but that shouldn't be a problem.
Well this a
On Sun, 26 Mar 2000, Jose Abilio Oliveira Matos wrote:
> > The guy that maintains XTL is also called José.
>
> Brasilian?
>
> Or spanish speaking although this should be spelled in a different way.
He too lives in Portugal. Scary isn't it? Two Jos
On Sun, Mar 26, 2000 at 01:39:06PM +0200, Asger K. Alstrup Nielsen wrote:
> > I think you are confusing me with someone else, and certainly you are
> > refering to XML not to that XTL. ;)
>
> You are not the only José in the world ;-)
I think that I need to copy Allan&#
> I think you are confusing me with someone else, and certainly you are
> refering to XML not to that XTL. ;)
You are not the only José in the world ;-)
The guy that maintains XTL is also called José.
Greets,
Asger
BTW: Are you coming to Norway?
On Sat, Mar 25, 2000 at 03:40:55PM +0100, Asger K. Alstrup Nielsen wrote:
[...]
> XTL 1.3 is already more portable than XTL 1.2, and if we can help
> José with more platform specific patches, I'm sure XTL will be a
> good choice for us.
I think you are confusing me with som
> can you propose a (temporary?) hack to get around these xtl
> compile problems that I'm suffering from.
What errors do you get?
Greets,
Asger
> I can't remember why XTL insists on using long long -- the documentation
> is at my fingertips but I just can't seem to reach it... Just one of those
> long hot Australian summer days (but wait it's supposed to autumn now! --
> roll on global-warming!)
XTL does no
On 24 Mar 2000, Jean-Marc Lasgouttes wrote:
> >>>>> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
>
> Allan> JMarc, please try compiling at least src/frontends/xforms. It
> Allan> doesn't need xtl but does have a new scheme for the callba
Hi, Allan
can you propose a (temporary?) hack to get around these xtl
compile problems that I'm suffering from.
I can compile your code in FormPrint.C only by hacking the
guts out of PrinterParams.h
line18
//#include "support/lxtl.h"
line95,96
void set(int size, char * buf
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| >>>>> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
|
| Allan> JMarc, please try compiling at least src/frontends/xforms. It
| Allan> doesn't need xtl but does have a new scheme for the callbac
>>>>> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> JMarc, please try compiling at least src/frontends/xforms. It
Allan> doesn't need xtl but does have a new scheme for the callbacks:
Allan> friendly C functions. It works fine with gcc-2.9
On Tue, 21 Mar 2000, Allan == Allan Rae <[EMAIL PROTECTED]> wrote:
Allan> On Fri, 17 Mar 2000, Allan Rae wrote:
Allan> > Read the comments in the various files. Have fun I'm off to catch a bus.
Allan> Well I had a great weekend, reading my Guidebook to Europe, no thesis
Allan> work though. D
On Tue, 21 Mar 2000, Dr. Ing. Roland Krause wrote:
>
> On Mon, 20 Mar 2000, Allan Rae wrote:
> > On Fri, 17 Mar 2000, Allan Rae wrote:
> > > Read the comments in the various files. Have fun I'm off to catch a bus.
> >
> > Well I had a great weekend, reading my Guidebook to Europe, no thesis
>
On Mon, 20 Mar 2000, Allan Rae wrote:
> On Fri, 17 Mar 2000, Allan Rae wrote:
> > Read the comments in the various files. Have fun I'm off to catch a bus.
>
> Well I had a great weekend, reading my Guidebook to Europe, no thesis
> work though. Did anybody attempt to compile or read any of this
On Fri, 17 Mar 2000, Allan Rae wrote:
> Read the comments in the various files. Have fun I'm off to catch a bus.
Well I had a great weekend, reading my Guidebook to Europe, no thesis
work though. Did anybody attempt to compile or read any of this stuff?
Allan. (ARRae)
hat's in Buffer::Dispatch for LFUN_BUFFER_PRINT. (Angus, if you like,
you can try to complete this and maybe see if there's anything else to
improve -- I have a new conversion script but I forget to bring it with
me)
You'll need to get and install a copy of xtl yourselves (link
| There are other reasons for not using someone else's string. I don't like
| using SGI STL's string because it makes "-g" binaries about 5 times
| larger than every other STL's string does. It also requires up to 180MB
| to compile some of our files when exceptions
even though we've already done a typedef
> | lyxstring string;. Naturally, the compiler complains bitterly at this
> | point and refuses to compile any more code until this problem is fixed.
> |
> | If I compile with SGI's STL-3.2 the problem doesn't arise mainly because
refuses to compile any more code until this problem is fixed.
|
| If I compile with SGI's STL-3.2 the problem doesn't arise mainly because
| of the stl_string_fwd.h wrapper I added a couple of months ago. If we
| want to use xtl + --with-included-string + gcc-2.95.2's STL we need
e with SGI's STL-3.2 the problem doesn't arise mainly because
of the stl_string_fwd.h wrapper I added a couple of months ago. If we
want to use xtl + --with-included-string + gcc-2.95.2's STL we need to fix
one or more of the following:
1. XTL -- so it doesn't require exceptions
/* Test code for demonstrating 4 1/2 possible ways of using XTL to get/set
* the contents of a parameter class. In this case, PrinterParams -- not
* the real one but a simulated one.
*
* Compile with:
*-DMACROS -- use macros to setup member functions
*-DMIXIN
On Sat, Mar 04, 2000 at 10:02:50PM +0100, Lars Gullik Bj&resh;nnes wrote:
> Dekel Tsur <[EMAIL PROTECTED]> writes:
> |
> | If you want, I can do the changes (and also do the changes I suggested
> | for layout.C)
>
> Nooo! :-)
>
> I absolutely disagree with you ad. the parsing of layout files.
"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:
| [Rewrite the loading parsing logic]
| > If you want, I can do the changes (and also do the changes I suggested
| > for layout.C)
|
| When you volunteer, obviously it's a good idea to make the change.
| You won't find me arguing against tha
Dekel Tsur <[EMAIL PROTECTED]> writes:
| On Thu, Mar 02, 2000 at 12:09:18PM +0100, Asger K. Alstrup Nielsen wrote:
| > > Dekel> However, the real problem lies on parsing .lyx files at
| > > Dekel> Buffer::readLyXformat2 which is done using if-else statements
| > > Dekel> (... else if (token == "\
[Rewrite the loading parsing logic]
> If you want, I can do the changes (and also do the changes I suggested
> for layout.C)
When you volunteer, obviously it's a good idea to make the change.
You won't find me arguing against that ;-)
I'm sure the patch would be welcomed.
Maybe it's time for De
On Thu, Mar 02, 2000 at 12:09:18PM +0100, Asger K. Alstrup Nielsen wrote:
> > Dekel> However, the real problem lies on parsing .lyx files at
> > Dekel> Buffer::readLyXformat2 which is done using if-else statements
> > Dekel> (... else if (token == "\\emph") ... ) This is very
> > Dekel> inefficien
> Dekel> However, the real problem lies on parsing .lyx files at
> Dekel> Buffer::readLyXformat2 which is done using if-else statements
> Dekel> (... else if (token == "\\emph") ... ) This is very
> Dekel> inefficient!
>
> Yes, this code should use LyxLex correctly.
Actually, this is not a real
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Lars> Perhaps because the standard C++ library dioes not have hashed
| Lars> containers? (that is an sgi extension (among others))
|
| Lars> As for faster search times, these tables are som small that I
| Lars> don't think it would have made a d
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:
Dekel> However, the real problem lies on parsing .lyx files at
Dekel> Buffer::readLyXformat2 which is done using if-else statements
Dekel> (... else if (token == "\\emph") ... ) This is very
Dekel> inefficient!
Yes, this code should use Lyx
On Tue, Feb 29, 2000 at 12:58:20AM +0100, Lars Gullik Bj&resh;nnes wrote:
> | > Lars> Or we can just sort it... this will slow things down a tiny bit,
> | > Lars> but you will never be able you measure that. (manually)
> | >
> | > With an assertion, we are always sure that manual sorting will be
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Dekel Tsur <[EMAIL PROTECTED]> writes: | On Mon, Feb 28, 2000
Lars> at 02:21:12PM +0100, Jean-Marc Lasgouttes wrote: | > >
Lars> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | > | >
Lars> Lars> Or we can just s
Dekel Tsur <[EMAIL PROTECTED]> writes:
| On Mon, Feb 28, 2000 at 02:21:12PM +0100, Jean-Marc Lasgouttes wrote:
| > > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| >
| > Lars> Or we can just sort it... this will slow things down a tiny bit,
| > Lars> but you will never be able y
On Mon, Feb 28, 2000 at 02:21:12PM +0100, Jean-Marc Lasgouttes wrote:
> > "Lars" == Lars Gullik Bj&resh;nnes <[EMAIL PROTECTED]> writes:
>
> Lars> Or we can just sort it... this will slow things down a tiny bit,
> Lars> but you will never be able you measure that. (manually)
>
> With an asse
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Or we can just sort it... this will slow things down a tiny bit,
Lars> but you will never be able you measure that. (manually)
With an assertion, we are always sure that manual sorting will be
done. This is linear time, and on
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
|
| Asger> The LyXLex creature requires a list of keywords to function.
| Asger> This is a simple list of tokens, but it only works if it is
| Asger> sorted. Real life has show
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> The LyXLex creature requires a list of keywords to function.
Asger> This is a simple list of tokens, but it only works if it is
Asger> sorted. Real life has shown that this is hard. Last time, it
Asger> was Juergen who co
Andre Poenitz <[EMAIL PROTECTED]> writes:
| > is at easy if it can possibly get. But maybe you are right and XTL is
|
| Read:
|
| ..is as easy as it ...
|
| I think I'll have another beer to get sober...
Not, in Norway yet are you?
Lgb
one end of the interface sits a
> human. And this human is the weak link performance-wise.
Recall that Asger has already memntioned the text export and that XTL
supports several other formats for externalization (CORBA stuff and XDR).
If you really, really wanted to you could write support for anot
Lgb and everybody else that
has touched it has too sometime.
[Simple winged example of XTL power]
> No. If it is realy *that* easy it looks like a viable solution.
Thank you. Now, go back and drink some more beer.
> > If you think so, you must be drunk. Come to Norway and I'll buy
> is at easy if it can possibly get. But maybe you are right and XTL is
Read:
..is as easy as it ...
I think I'll have another beer to get sober...
Andre'
--
André Pönitz . [EMAIL PROTECTED]
> You argue that debugging is important. Three words: Debugging is boring.
I know. But sometimes necessary. Not that I try to code poorly just to
have the fun of debugging ;-|
> If we use XTL, there will be less debugging than if we have to write
> our own parser. Just take a lo
André argues that we should not use XTL because we can do things with
a string. He thinks that the added complexity of another library is
not worth the hassle -- after all a text format is well-known, and
if it is well encapsulated, it's no problem.
Surprise!
This is exactly what XTL i
Even if
LyX becomes more modular and some internal calls could be made through
this interface, this won't become overwhelming. After all, it's modular
then...
> The XTL library solves this problem for us in a clean, efficient, elegant,
> and extensible way.
This introduces another bi
[XTL]
> I did that too and I admit I dont get what this is suposed to do for LyX? Do
> you intend to have a new file format?
> Btw XDR is a platform independent format for binary representation. I use
> XDR a lot for numerical stuff. This XLT thing looks like XDR for structures
> On Wed, 23 Feb 2000, Asger K. Alstrup Nielsen wrote:
> > The best format is the raw format, since it's minimalistic and the
> > fastest. We don't need interoperability with external sources, so
> > the raw format is the best solution.
>
> That was what I thought the plain text was. The versio
On Wed, 23 Feb 2000, Asger K. Alstrup Nielsen wrote:
> The best format is the raw format, since it's minimalistic and the
> fastest. We don't need interoperability with external sources, so
> the raw format is the best solution.
That was what I thought the plain text was. The version I currentl
r own question in the previous paragraph.
Externalization. Whether its external to LyX or external to the core.
As you will have noticed in the XTL documentation the optimized code for
any of the fancier formats is no worse than about half the speed of a
memcpy but it can be used to communicate to
Hi,
On Tue, 22 Feb 2000, Allan Rae wrote:
> On Tue, 22 Feb 2000, Asger K. Alstrup Nielsen wrote:
>
> I've looked at the code and read the manual for it a couple of times on
> the bus. So I agree it's exactly what we need.
I did that too and I admit I dont get what this is suposed to do for LyX
> I am intending to make XTL a part of the rae branch sometime this week as
> I want to try it out communication with LyXFunc. I'll have to get the
> latest release to see what's new. The version I have exports to plain
> text but doesn't import from it. It seems
y elegant
> if you ask me.
I've looked at the code and read the manual for it a couple of times on
the bus. So I agree it's exactly what we need.
> Regarding how to realize this goal: I'm wondering if we should try a
> small experiment after 1.1.5 is out: Include the lat
Hi!
I just want to let you know that I've been in contact with the guy
behind XTL and he's interested in making XTL portable enough for use
with LyX. I even went as far to send him some patches, and subscribe
to the mailing list.
For those who do not know, XTL is a small l
94 matches
Mail list logo
