José Matos wrote:
Thanks for your answer.
These are the issues I remember, there others that I don't remember or
didn't understood :-). BTW I like Python. ;-)
I also vote for python.
YC
On Wednesday 26 February 2003 07:38, Yann COLLETTE wrote:
> Hello,
>
> Sorry for this late answer, but I was waiting for the lyx devel site to
> be reachable.
> When I was talking about scripting capabilities of lyx, I had in mind
> what is on the lyx devel web site:
>
>"Support a scripting
quot;
Your sincerely,
Yann COLLETTE
Angus Leeming wrote:
Yann COLLETTE wrote:
Hello,
I would like to have news about the possibilities to use a script
language to build an inset: Have you choose a language yet ?
* reLyX is written in perl but is probably going to be replaced by tex2lyx,
wr
Yann COLLETTE wrote:
> Hello,
>
> I would like to have news about the possibilities to use a script
> language to build an inset: Have you choose a language yet ?
* reLyX is written in perl but is probably going to be replaced by tex2lyx,
written in C++.
* lyx2lyx is written in p
Hello,
I would like to have news about the possibilities to use a script
language to build an inset: Have you choose a language yet ?
Your sincerely,
Yann COLLETTE
On Tue, Dec 15, 1998 at 11:27:07AM +0100, Jean-Marc Lasgouttes wrote:
> > "Jacek" == Jacek M Holeczek <[EMAIL PROTECTED]> writes:
>
> Jacek> Hi, I would again like to mention a nice embedable C/C++
> Jacek> interpreter called CINT. For details have a look at :
> Jacek> http://root.cern.ch/roo
On Sun, Dec 13, 1998 at 01:24:58PM +0100, Asger Alstrup Nielsen wrote:
>
> It's disputable how easy Scheme is to learn for users. But we know that at
> least that some of the developers like it, and programmers that have hacked
> Emacs will feel at home. Instantly, we gain a large market of pot
> "Jacek" == Jacek M Holeczek <[EMAIL PROTECTED]> writes:
>>> ... a nice embedable C/C++ http://root.cern.ch/root/Cint.html
>> Hmm, 8 lines of code is certainly a bit too much for bundling
>> the
Jacek> But for this price you get a very nice tool.
I agree that the tool is nice, but 800
>> ... a nice embedable C/C++ http://root.cern.ch/root/Cint.html
> Hmm, 8 lines of code is certainly a bit too much for bundling the
But for this price you get a very nice tool.
You can automatically generate a "dictionary" of C/C++functions and
classes which you can later use interactively fr
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
> *Alejandro Aguilar Sierra writes:
> | I don't know what is your idea but I think that we should not have
> | a function for each lyx command but just few of them. The most
> | important could be:
> |
> | (exec-lyx-command " [argument]")
> |
On 15 Dec 1998, Lars Gullik Bjønnes wrote:
> I don't agree with you. We should export the lyxfuncs so that they
> seem to be builtin-scheme functions:
>
> (buffer-open "test.lyx")
>
> Perhaps we should have a prefix: "lyx-", but I don't think so.
Ha! it's easier to try first my idea, for testi
*Alejandro Aguilar Sierra writes:
| I don't know what is your idea but I think that we should not have
| a function for each lyx command but just few of them. The most
| important could be:
|
| (exec-lyx-command " [argument]")
|
| or a shorter name. Some of the necessary new functions are
> "Jacek" == Jacek M Holeczek <[EMAIL PROTECTED]> writes:
Jacek> Hi, I would again like to mention a nice embedable C/C++
Jacek> interpreter called CINT. For details have a look at :
Jacek> http://root.cern.ch/root/Cint.html Do also have a look at how
Jacek> it is used as a scripting language
> You are right. It is not really what we are looking for. But maybe is
> it easy to declare a 'for' function in this setting.
After having a closer look, I think it's close to impossible..
However, doing a simple imperative language from scratch is not hard.
> Do you have a pointer for ELK?
h
Hi,
I would again like to mention a nice embedable C/C++ interpreter called
CINT. For details have a look at :
http://root.cern.ch/root/Cint.html
Do also have a look at how it is used as a scripting language in the ROOT
environment at :
http://root.cern.ch
Jacek.
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> Yes, I noticed this. It might be a good starting point, but
Asger> unfortunately it's not documented much. I think I might have
Asger> to try to dig out the article he has referenced to decipher the
Asger> parser and un
"Asger K. Alstrup Nielsen" wrote:
[snip]
> The point is that if we want to support non-interactive use, an easy
> way to implement this is with a scripting language.
> Users have requested the option of doing "lyx -export tex *.lyx" and
> similar things. A natural way to provide this functionali
> What about the pratt parser included with siod? It provides the same
> language in a script-like syntax. Example from the docs:
>
> #!/usr/local/bin/siod -v01,-m2 -*-mode:text;parser:pratt-*-
> main() :=
> {writes(nil,"Hello Scheme World.\n");
> fflush(nil);
> writes(nil,"fib(20) = ",fib(20)
> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> The progress in this discussion is not as fast as I'd hoped it
Asger> would be, but this demonstrates how hard a problem this is to
Asger> solve. I propose a solution in this mail, that I hope will
Asger> move the decision
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> | I thought you could connect several clients to the same
Lars> server... | I'll have to check this out.
Lars> But the server will never know which of the it speaks too. And
Lars> all the clients connecting will work on the
> > For instance, running LyX in batch mode:
> > Write a small script which will open all *.lyx documents in a directory
> > structure, and convert them to postscript.
>
> Could be done by 'make' if there was an command line switch for
> 'generate .tex only'. I conjecture most people use 'make' a
>
> > Might I ask, what are a few straightforward examples of the new capabilities
> > a scripting language will provide users of lyx?
That's what I was asking myself all the time but since I missed the
start of the thread I thought I should keep my mouth shut, but ...
> Of course, a scripting
On Sun, 13 Dec 1998, Asger Alstrup Nielsen wrote:
> The main remaining problems with the so far best candiate language, Python,
> are:
> 1) It's not bundable.
> 2) It's not clear how the security concern could be solved. (And this prevents
> us from using the external approach.)
Have you look
On Sun, 13 Dec 1998, Larry S. Marso wrote:
> I'm trying to catch up with the mail on this topic.
>
> Might I ask, what are a few straightforward examples of the new capabilities
> a scripting language will provide users of lyx?
Or: What capabilities is it that we want, that we can't get (at all
On 12 Dec 1998, Lars Gullik Bjønnes wrote:
> *Jean-Marc Lasgouttes writes:
> | Is there some places where I could read on the differences between
> | pipes/sockets/whatever? Or perhaps you could give me a short
> | tutorial?
> (and a lot more, this will not tell much about how to use)
There
> Might I ask, what are a few straightforward examples of the new capabilities
> a scripting language will provide users of lyx?
Of course, a scripting language will not provide anything that is not possible
if we wrote the stuff directly in C++, but the scripting language will
hopefully make thi
I'm trying to catch up with the mail on this topic.
Might I ask, what are a few straightforward examples of the new capabilities
a scripting language will provide users of lyx?
Best regards
--
Larry S. Marso
[EMAIL PROTECTED]
On Sun, 13 Dec 1998, Asger Alstrup Nielsen wrote:
> Therefor I propose that we do this:
>
> Make Scheme the primary candidate language, in the form of a very small and
> thus bundable scheme, like SIOD. So we would declare Scheme the "official"
> scripting language, that all LyX come with.
It
The progress in this discussion is not as fast as I'd hoped it would be, but
this demonstrates how hard a problem this is to solve. I propose a solution in
this mail, that I hope will move the decision a bit closer to reality.
We have a variety of criteria to the scripting language that need to
On Thu, Dec 10, 1998 at 01:13:38PM -0500, Amir Karger wrote:
> On Thu, Dec 10, 1998 at 06:36:12PM +0100, Lars Gullik Bjønnes wrote:
> > Imageine support for external BibTeX, therasarous(?), knowledege
>
> Theresaurus would be an animal living 165 million years ago that healed other
> animals or s
g the user that wants to use the Lyx script language will handle
that even if it is lisp.
| This problem of syntax is not easily "customized" away in Scheme.
IMO this is no problem.
| The other alternative is to design a mini-language for ourselves.
| While this would be a fun
*Jean-Marc Lasgouttes writes:
|
|| "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars| *Alejandro Aguilar Sierra writes: | Ahem, we have not yet
Lars| decided for phyton. The point of Lars post, | AIUI, is to
Lars| improve the lyxserver to be able to try it with more | script
Lars
*Jean-Marc Lasgouttes writes:
| (setq foo bar) (setq blah baz)
Why not? In the future the user will never see the contents of lyxrc
anyway, so we chose something that is easy to parse.
Asger| This problem of syntax is not easily "customized" away in
Asger| Scheme.
| Right.
(as said earlier:
*Asger K Alstrup Nielsen writes:
| - What technical approach should be adopt - embedment or external
| spawns with communication through pipes or sockets?
the LyX script language should _really_ _really_ be embedded into LyX.
Lgb
*Alejandro Aguilar Sierra writes:
| On 10 Dec 1998, Lars Gullik Bjønnes wrote:
|| I want it to be possible for several external programs to connect
|| to the LyX-server(s) at once. Will be similar to multipleviews.
|| (actually lyxserver will be a specialized BufferView)
| Rather BufferView sh
On Fri, 11 Dec 1998, Asger K. Alstrup Nielsen wrote:
> Alejandro disagrees until more research has been done.
> That makes sense to me, so Alejandro, what things do you
> think we should investigate now to progress further?
The first time we were considering to adopt a new gui toolkit to swit
"Asger K. Alstrup Nielsen" wrote:
>
> > A nice solution would be a scripting language which is small enough
> > to be included in the distribution without major bloat. Does such a
> > beast exist?
>
> The best candiate for this solution is SIOD: Scheme In One Defun.
> It's small and lean, and e
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> [I wrote about LyX document virus]
>> That's an interesting idea. This would happen if we allow the
>> documents themselves to contain macros. I think that this is a bad
>> idea at this point of time.
Asger> Yes, but I t
On Fri, Dec 11, 1998 at 12:01:09PM +0100, Andre' Poenitz wrote:
>
> I certainly have not read this list for a while... a newsreader within
> LyX? Are you serious? I was under the impression that LyX was intended
> to be an easy-to-use front end to LaTeX, not an 'eierlegende
> Wollmilchsau'... som
asger added,
> But a mail-sender component is not out of the question IMO.
it's already there :)
Export->custom, check postscript, and
a2ps -o -|uuencode | mail |someone@somewhere
sends things to my committee . . .
seriously, though, what more would we want than "mail this document to
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
>> A nice solution would be a scripting language which is small enough
>> to be included in the distribution without major bloat. Does such a
>> beast exist?
Asger> The best candiate for this solution is SIOD: Scheme In One
Asg
age.
Later, we extend the language with more advanced features,
data structures and libraries.
But I still think that it would be best if we could find
an existing language that fulfills all our requirements.
> If we use the second solution, I guess we should offer support for any
> script lan
> I certainly have not read this list for a while... a newsreader within
> LyX? Are you serious? I was under the impression that LyX was intended
> to be an easy-to-use front end to LaTeX, not an 'eierlegende
> Wollmilchsau'... some beast that produces eggs, wool, milk and
> meat at the same time.
> Lars> Still to be able to start arbitrary programs from inside lyx we
> Lars> need some scripting support. (pipes need to be setup from
> Lars> within: pipe(); fork(); exec() ) (and if we want to build a
> Lars> newsreader inside lyx we need a powerful scripting language)
I certainly have not r
[I wrote about LyX document virus]
> That's an interesting idea. This would happen if we allow the
> documents themselves to contain macros. I think that this is a bad
> idea at this point of time.
Yes, but I think we want to aim for this, and therefor, we should
consider this now.
> In fact, I'
t; - What technical approach should be adopt - embedment or
Asger> external spawns with communication through pipes or sockets?
Asger> The choice of scripting language depends on the second
Asger> question.
If we use the second solution, I guess we should offer support for any
script la
> I imagine that several of the functions in LyXFunc really should be
> written using the script language instead. So that we only have the
> basic commands implemented in C++ and the compound(?) ones written in
> scripts.
I like this approach too.
But for this to work, we need t
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> *Alejandro Aguilar Sierra writes: | Ahem, we have not yet
Lars> decided for phyton. The point of Lars post, | AIUI, is to
Lars> improve the lyxserver to be able to try it with more | script
Lars> languages.
Lars> AIUI?
Lars>
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> The main problem I see with this approach is that the we will
Asger> end up with something similar to handling CGI-scripts in
Asger> Web-servers: LyX has to spawn an external interpreter, and this
Asger> is slow and insec
> Ahem, excuse me to come abruptly in the discussion, but how far could
> we go by only using only the lyserver and libraries interacing to it
> from perl, python, sh, gnuplot, whatever? What would be real gain of
> an enbedded language, compared to the development cost (to make it
> really useful
On 10 Dec 1998, Lars Gullik Bjønnes wrote:
> I want it to be possible for several external programs to connect to
> the LyX-server(s) at once. Will be similar to multipleviews.
> (actually lyxserver will be a specialized BufferView)
Rather BufferView should be a specialized Buffer which base
cla
On Thu, 10 Dec 1998, Amir Karger wrote:
> > Ahem, we have not yet decided for phyton. The point of Lars post, AIUI,
> > is to improve the lyxserver to be able to try it with more script
> > languages.
>
> I agree! By the way, is AIUI spanish?
As I Understand It. :)
Alejandro
*Alejandro Aguilar Sierra writes:
|| To be able to test this, stuff in LyXView, BufferView, LyXText,
|| LyXParagraph (and others) needs to be fixed.
| Is the todo list updated?
Depends upon what you mean...
o better LyXServer support
- perhaps use UNIX sockets instead o
On Thu, Dec 10, 1998 at 12:30:20PM -0600, Alejandro Aguilar Sierra wrote:
> On Thu, 10 Dec 1998, Amir Karger wrote:
>
> Ahem, we have not yet decided for phyton. The point of Lars post, AIUI,
> is to improve the lyxserver to be able to try it with more script
> languages.
I agree! By the way, is
. (pipes need to be setup from within: pipe();
fork(); exec() ) (and if we want to build a newsreader inside
lyx we need a powerful scripting language)
The LyX server as present can be used to test whatever script
language you can imagine. (just not at the same time)
I want it to be possible for
On 10 Dec 1998, Lars Gullik Bjønnes wrote:
> I think a new lyxserver protocol should be made.
yes.
> To be able to test this, stuff in LyXView, BufferView, LyXText,
> LyXParagraph (and others) needs to be fixed.
Is the todo list updated?
Alejandro
*Alejandro Aguilar Sierra writes:
| On 10 Dec 1998, Lars Gullik Bjønnes wrote:
|| Concerning the lyx-server: to use this actively as a script/program
|| interface it needs rewritning. Currently it uses pipes and that
|| means that there is only one channel into lyx. We would need to
|| rewrite t
On Thu, 10 Dec 1998, Amir Karger wrote:
> > f.ex. the complete spellcheker support could be written in python.
>
> Would be neat, but only if we include python in the distribution!
> I think a lot of people want to use the spellchecker!
Ahem, we have not yet decided for phyton. The point of Lar
On 10 Dec 1998, Lars Gullik Bjønnes wrote:
> Concerning the lyx-server: to use this actively as a script/program
> interface it needs rewritning. Currently it uses pipes and that means
> that there is only one channel into lyx. We would need to rewrite the
> server too use sockets instead to get
On Thu, Dec 10, 1998 at 06:36:12PM +0100, Lars Gullik Bjønnes wrote:
> I imagine that several of the functions in LyXFunc really should be
> written using the script language instead. So that we only have the
> basic commands implemented in C++ and the compound(?) ones written in
that several of the functions in LyXFunc really should be
written using the script language instead. So that we only have the
basic commands implemented in C++ and the compound(?) ones written in
scripts.
f.ex. the complete spellcheker support could be written in python.
Concerning the lyx-server: to
*Amir Karger writes:
| It might be easy to add to 1.0, and a working graphical tutorial
| that came in the distribution w/out adding 1.5 MB would be killer,
| but I really think we should get 1.0 OUT there. We can always put
| it in 1.0.1. Even if it wouldn't postpone it much, it would still
lars lamented,
> *Asger Alstrup Nielsen writes:
> | The "only" serious problem is to decide whether Python should be
> | mandatory or optional. (We have to solve this problem for any
> | scripting language which can't be included in the distribution.)
> IMO that is bad. The scripting language
On Thu, Dec 10, 1998 at 01:01:41PM +0100, Asger Alstrup Nielsen wrote:
>
> The "only" serious problem is to decide whether Python should be mandatory
> or optional. (We have to solve this problem for any scripting language
> which can't be included in the distribution.)
>
I don't *really* thin
*Asger Alstrup Nielsen writes:
| The "only" serious problem is to decide whether Python should be
| mandatory or optional. (We have to solve this problem for any
| scripting language which can't be included in the distribution.)
IMO that is bad. The scripting language should be mandatory and
i
> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
>> Um, OK. This is above my head. Sounds like maybe Python and perl
>> would be equally difficult in this case?
Asger> Sounds like the vim people managed to solve the linking of
Asger> Python problem. I'll try to check that out.
> Um, OK. This is above my head. Sounds like maybe Python and perl would be
> equally difficult in this case?
Sounds like the vim people managed to solve the linking of Python problem.
I'll try to check that out. If the stuff is good, I think might have a winner:
Amir is starting to agree, Lgb
On Wed, Dec 09, 1998 at 10:03:44AM +0100, Asger K. Alstrup Nielsen wrote:
> > 1) Perl is much more widespread than python, and even more so compared to
> > guile and other languages that the non-computer science folks among us have
> > never heard of. (I've heard of SWIG, and I agree that it would
*Asger K Alstrup Nielsen writes:
| Once again, my perspective is not to get the scripting language I
| as a hacker would love, but rather what the novice users would be
| able to use. If I was to chose for myself, I would go for ML or
| scheme, but if we do that, we'll loose a great fraction o
Hello again,
just to point out that it's in variable "$mylyxpipe" that the name of
the pipe should be put. Also, if your perl is not in /usr/bin/perl, it
is better to do 'perl '.
And also to say that, as a lyx user, I afavor any easy-to-learn language.
If it's also easy to generate au
Hello,
here is sample perl code, to illustrate the debate : it prints itself
using the lyx server.
#!/usr/bin/perl -w
#
# Usage : Edit this file so that variable "$lyxpipe" is the name of
# the lyx pipe.
> I'm sure Asger was expecting some perl advocacy, so I'll throw in my two
> pfennings.
Of course.
> 1) Perl is much more widespread than python, and even more so compared to
> guile and other languages that the non-computer science folks among us have
> never heard of. (I've heard of SWIG, and
> *Mate Wierdl writes:
> | How about Icon? http://www.cs.arizona.edu/icon/index.htm
>
> You mean: "Why not a scripting language nobody has hard of, then there
> will be no language wars" :-)
>
> Seriously, no matter how nice icon may be (I have not looked at it) we
> should chose something tha
*Mate Wierdl writes:
| How about Icon? http://www.cs.arizona.edu/icon/index.htm
You mean: "Why not a scripting language nobody has hard of, then there
will be no language wars" :-)
I just mentioned Icon on an impulse: this is a TeX related list, and I
I first saw a reference for
On Tue, Dec 08, 1998 at 03:09:58PM -0600, Alejandro Aguilar Sierra wrote:
> On Tue, 8 Dec 1998, Asger Alstrup Nielsen wrote:
>
> > Another serious candidate is Perl, which is more widespread than Python,
> > but I fear the syntax of the language will scare people from trying to
> > use it.
>
>
*Mate Wierdl writes:
| How about Icon? http://www.cs.arizona.edu/icon/index.htm
You mean: "Why not a scripting language nobody has hard of, then there
will be no language wars" :-)
Seriously, no matter how nice icon may be (I have not looked at it) we
should chose something that is widely know
> My suggestion is that if you are going to add scripting support you do it in
> such a way that you can bind in any scripting lang easily, if this is
> possible.
> Then you can start off with some scripting language and if other really want
> scheme, python, perl or whatever support they can add
Alejandro Aguilar Sierra wrote:
> Are you sure it's enough stable? I can't run some not so old python
> programs because language version incompatibilities.
Python is stable in the sense that the basic programming language does not
change much. The libraries evolve however, and this can cause
i
How about Icon?
http://www.cs.arizona.edu/icon/index.htm
Mate
>On Tue, 8 Dec 1998, Asger Alstrup Nielsen wrote:
>
>> I vote for Python because it's easy to learn, has a natural syntax and
>> it's cross-platform.
>
>Are you sure it's enough stable? I can't run some not so old python
>programs because language version incompatibilities.
>
>> This is in contras
On Tue, 8 Dec 1998, Asger Alstrup Nielsen wrote:
> I vote for Python because it's easy to learn, has a natural syntax and
> it's cross-platform.
Are you sure it's enough stable? I can't run some not so old python
programs because language version incompatibilities.
> This is in contrast with G
81 matches
Mail list logo
