On 22/07/2013 4:10 AM, Guenter Milde wrote:
On 2013-07-22, Josh Hieronymus wrote:
Second, is there a tutorial
serves as a gentle introduction to Python scripting for LyX? I've not
worked with Python and C++ in the same project before, so I'm not really
sure how to get th
On 2013-07-22, Josh Hieronymus wrote:
...
> Second, is there a tutorial
> serves as a gentle introduction to Python scripting for LyX? I've not
> worked with Python and C++ in the same project before, so I'm not really
> sure how to get them to work together, especially wh
Pavel Sanda wrote:
> we already have working library for zipping files as a part of LyX and commit
> history might even contain much more generic solution written some time back
> by
> Bo Peng as a part of bundled lyx format feature (and reverted later;).
You can check commits around
a095d0d785ca
Josh Hieronymus wrote:
> I was thinking of using the existing C++ routines to generate the XHTML,
> and then using Python to generate the additional necessary files, which are
> mostly XML files with metadata and manifest info, as well as to pack the
> files.
My point was just that you shouldn't u
On Sun, Jul 21, 2013 at 10:19 PM, Pavel Sanda wrote:
> Josh Hieronymus wrote:
> > Since an ePub file is pretty much a zipped file with XHTML and a few
> simple
> > files, I was thinking that it might be easiest to use Python to create
> > them.
>
> If it comes to packing you might be interested t
Josh Hieronymus wrote:
> Since an ePub file is pretty much a zipped file with XHTML and a few simple
> files, I was thinking that it might be easiest to use Python to create
> them.
If it comes to packing you might be interested to see our lyxpak.py script.
I'm not sure what you mean by 'create';
y help me have an easier time knowing how
>
> make doxydoc, if you have graphviz, you will get nice pictures as well.
>
> > the different parts of code are all related. Second, is there a tutorial
> > serves as a gentle introduction to Python scripting for LyX? I've no
you will get nice pictures as well.
> the different parts of code are all related. Second, is there a tutorial
> serves as a gentle introduction to Python scripting for LyX? I've not
No. What do you need python for btw?
Pavel
tutorial
serves as a gentle introduction to Python scripting for LyX? I've not
worked with Python and C++ in the same project before, so I'm not really
sure how to get them to work together, especially when you consider issues
like type checking, namespaces, header files, and so on.
Thanks,
Josh
On Fri, May 06, 2011 at 07:33:35PM +, Guenter Milde wrote:
> On 2011-05-06, venom00 wrote:
> >> >> Lua
> >> >>+ small and fast,
> >> >>+ used in LuaTeX, so it will become more common and known in the
> >> >> TeX community,
> >> >>+ a Lua interpreter can be embedded in LyX with
nd 17000 lines of C. Under Linux, the Lua interpreter
>> built with all standard Lua libraries takes 153K and the Lua library
>> takes 203K.
>> Compare this to a minimal Python installation or the size of the LyX
>> binary.
> We already require Python, that's a p
require Python, that's a point in its favour.
> > Or did I get it wrong? ;)
>
> The idea is to outsource¹ tasks. This would reduce the binary size and
> memory footprint even more. An example would be the parsing of the
> unicodesymbols file.
Weren't we talking about
e is numerical.
Moreover most of the LFUNs don't take arguments or frequently they're text. Do
we really want make such a big change just for LFUNs taking numbers?
Consider the following LFUN:
case LFUN_SET_COLOR: {
string lyx_name;
string const x11_name = split(to_utf8(cmd.argument()
and I think this is fundamental if we want to hope in
third party cooperation.
I had a similar idea to record/replay such LFUNs series,
especially for reproducing bug it could be useful.
Sure, scripting and macro are strictly related. Record a macro would be very
simple as each user interaction wit
this is fundamental if we want to hope in
> third party cooperation.
>
> I had a similar idea to record/replay such LFUNs series,
> especially for reproducing bug it could be useful.
Sure, scripting and macro are strictly related. Record a macro would be very
simple as each user i
On 05.05.2011 19:26, venom00 wrote:
Jean Marc said:
The problem with script plugins is that people seem to expect that by
linking LyX to python everybody will be able to write python scritps
that can manipulate LyX objects natively.
I may be missing most of current advancement in programming
to
Jean Marc said:
> The problem with script plugins is that people seem to expect that by
> linking LyX to python everybody will be able to write python scritps
> that can manipulate LyX objects natively.
>
> I may be missing most of current advancement in programming
> tools, but I
> do not see
On Sat, Nov 27, 2010 at 11:40 PM, wrote:
> Any other useful link?
>
http://www.lyx.org/Development
Regards
Liviu
> it means untrivial ditching into the dispatch mechanism, so this is for sure
not
> 2.0 business.
OK, then I'll just start thinking about it. Maybe a first release of the
scripting support could not have such events, but just keypresses as
notification in LyX server.
I don'
r such kind of rules. we just suggest that people hang around
for a while with small things to get idea about the code, otherwise big
parts of their code would need rewrite...
> So, my idea was to add python scripting in-process. The script should be able
> to
> register to an event, ca
be helpful!
So, my idea was to add python scripting in-process. The script should be able to
register to an event, call LFUN and receive responses, nothing more. Maybe we'll
need to add some LFUN to get the selected text, or the whole document source,
because I couldn't find such function
veno...@arcadiaclub.com wrote:
> Hello, LyX 2.0 is getting awesome, but I think there's just a last must-have
> feature missing: support for scripting.
to give you wider overview, i have been asking about must-have new features for
2.0 each month from early spring and formally close
On 2010-11-26, wrote:
> Hello, LyX 2.0 is getting awesome, but I think there's just a last
> must-have feature missing: support for scripting.
I wrote a Python package that provides an interface via the LyXserver
pipes. It's available for download via the LyX wiki
http://wi
On 11/26/2010 02:22 PM, veno...@arcadiaclub.com wrote:
Hello, LyX 2.0 is getting awesome, but I think there's just a last must-have
feature missing: support for scripting. I think implementing Python scripting
[1] wouldn't be that difficult, as all the functionalities (event no
Hello, LyX 2.0 is getting awesome, but I think there's just a last must-have
feature missing: support for scripting. I think implementing Python scripting
[1] wouldn't be that difficult, as all the functionalities (event notification,
commands, response and errors) are already impl
On Sun, Nov 08, 2009 at 11:19:55AM +0800, John McCabe-Dansted wrote:
> I have heard that some .h files include other .h files, but are not
> required to do so by POSIX etc. Thus removing them may harm
> portability.
This discussion is not much about C headers. They are comparatively
short and abov
On Sun, Nov 08, 2009 at 12:55:15AM +0100, Vincent van Ravesteijn wrote:
> Pavel Sanda schreef:
>> Vincent van Ravesteijn wrote:
>>
my draft implied one compilation per one #include in our sources, no
combinations. the only tweaking part was that detection in .h files
- one has
>>
On Sat, Nov 07, 2009 at 11:12:06PM +0100, Alex Fernandez wrote:
> On Sat, Nov 7, 2009 at 8:19 PM, Steve Litt wrote:
> > I'm wondering if there's a less compute intensive method than the brute
> > force
> > method of removing a #include from a .h, and then recompiling every .cpp
> > file.
>
> I
On Saturday 07 November 2009 13:37:30 Pavel Sanda wrote:
> hi,
>
> if there is somebody who would like to contribute to lyx and like to tackle
> with some python/bash scripting, consider fixing the bug
> http://www.lyx.org/trac/ticket/6305 .
>
> pavel
Angus has tackle
John McCabe-Dansted wrote:
> I have heard that some .h files include other .h files, but are not
> required to do so by POSIX etc. Thus removing them may harm
> portability. I am not sure how this could be detected automatically
we have to be careful about few headers like cstdlib. then i remember
November 2009 19:19
To: LyX devel
Subject: Re: Scripting fun - removing unneeded headers from source code
On Saturday 07 November 2009 08:37:30 Pavel Sanda wrote:
> hi,
>
> if there is somebody who would like to contribute to lyx and like to tackle
> with some python/bash scripti
I have heard that some .h files include other .h files, but are not
required to do so by POSIX etc. Thus removing them may harm
portability. I am not sure how this could be detected automatically
That said I don't know much about this. And even if this is a problem,
it presumably would help to kno
Pavel Sanda wrote:
> Vincent van Ravesteijn wrote:
> > I think you'll mostly remove includes that are redundant in some sense.
> > It's less likely there are huge amounts of costly includes.
>
> who knows. i believe that those 13 includes i removed from insetmathhull
> today were not just redunda
On Sat, Nov 7, 2009 at 11:12 PM, Alex Fernandez wrote:
> I thought about semantic processing: read all the prototypes in the
> .h, then see if they are actually used in the .cpp files. Remove those
> which aren't and try compiling; if the job has been well done then
> compilation should proceed wi
Vincent van Ravesteijn wrote:
> I think you'll mostly remove includes that are redundant in some sense.
> It's less likely there are huge amounts of costly includes.
who knows. i believe that those 13 includes i removed from insetmathhull
today were not just redundant of other headers.
pavel
Pavel Sanda schreef:
Vincent van Ravesteijn wrote:
my draft implied one compilation per one #include in our sources, no
combinations. the only tweaking part was that detection in .h files - one
has
to distinguish whether the compilation fails because of header
insuficiency in
.h or in cons
Vincent van Ravesteijn wrote:
>> my draft implied one compilation per one #include in our sources, no
>> combinations. the only tweaking part was that detection in .h files - one
>> has
>> to distinguish whether the compilation fails because of header
>> insuficiency in
>> .h or in consequent .cp
Pavel Sanda schreef:
Steve Litt wrote:
The part where you remove .h includes from .cpp is dead bang easy if rather
slow. Not so with the .h includes inside other .h files. For each #include
removal from a .h file, you'd have to compile every .cpp that includes the
including .h.
my d
Steve Litt wrote:
> The part where you remove .h includes from .cpp is dead bang easy if rather
> slow. Not so with the .h includes inside other .h files. For each #include
> removal from a .h file, you'd have to compile every .cpp that includes the
> including .h.
my draft implied one compila
On Sat, Nov 7, 2009 at 8:19 PM, Steve Litt wrote:
> I'm wondering if there's a less compute intensive method than the brute force
> method of removing a #include from a .h, and then recompiling every .cpp file.
I thought about semantic processing: read all the prototypes in the
.h, then see if th
On Saturday 07 November 2009 08:37:30 Pavel Sanda wrote:
> hi,
>
> if there is somebody who would like to contribute to lyx and like to tackle
> with some python/bash scripting, consider fixing the bug
> http://www.lyx.org/trac/ticket/6305 .
>
> pavel
Hi Pavel,
The par
hi,
if there is somebody who would like to contribute to lyx and like to tackle
with some
python/bash scripting, consider fixing the bug
http://www.lyx.org/trac/ticket/6305 .
pavel
On Sat, Jul 01, 2006 at 12:01:16PM +0200, Georg Baum wrote:
> Am Freitag, 30. Juni 2006 20:21 schrieb Enrico Forestieri:
> > What I mean is that I don't think that the renaming work I did can be
> > responsible for this one.
>
> IIRC it was more than renaming, otherwise I would not have mentioned
Am Freitag, 30. Juni 2006 20:21 schrieb Enrico Forestieri:
> What I mean is that I don't think that the renaming work I did can be
> responsible for this one.
IIRC it was more than renaming, otherwise I would not have mentioned it.
Georg
On Fri, Jun 30, 2006 at 06:51:32PM +0200, Enrico Forestieri wrote:
> On Fri, Jun 30, 2006 at 03:56:37PM +0200, Georg Baum wrote:
>
> > Edwin Leuven wrote:
> >
> > > atm i have troubles previewing the document and i somehow connected it
> > > to changing preferences (but i was wrong)
> > >
> > >
On Fri, Jun 30, 2006 at 03:56:37PM +0200, Georg Baum wrote:
> Edwin Leuven wrote:
>
> > atm i have troubles previewing the document and i somehow connected it
> > to changing preferences (but i was wrong)
> >
> > get an error message:
> >
> > file does not exist:
> > c:/tmp/lyx_tmpdir ... /C:_d
Edwin Leuven wrote:
> atm i have troubles previewing the document and i somehow connected it
> to changing preferences (but i was wrong)
>
> get an error message:
>
> file does not exist:
> c:/tmp/lyx_tmpdir ... /C:_data_newfile8.dvi
>
> it doesn't like the semicolon i guess, probably path conv
Juergen Spitzmueller wrote:
Edwin Leuven wrote:
here is a snippet:
What's wrong with this?
mmm, it seems i need another coffee
didn't look close enough
atm i have troubles previewing the document and i somehow connected it
to changing preferences (but i was wrong)
get an error message:
Edwin Leuven <[EMAIL PROTECTED]> writes:
| atm saved preferences end up in my lyx file!
|
| is this related to your recent changes bo?
|
| here is a snippet:
|
| #LyX 1.5.0svn created this file. For more info see http://www.lyx.org/
| \lyxformat 247
| \begin_document
| \begin_header
| \textclas
Edwin Leuven wrote:
> atm saved preferences end up in my lyx file!
I don't see any preferences there. If you meant the \font... settings: Have
a look at development/FORMAT.
Georg
Edwin Leuven wrote:
> here is a snippet:
What's wrong with this?
Jürgen
atm saved preferences end up in my lyx file!
is this related to your recent changes bo?
here is a snippet:
#LyX 1.5.0svn created this file. For more info see http://www.lyx.org/
\lyxformat 247
\begin_document
\begin_header
\textclass article
\language english
\inputencoding auto
\font_roman def
Bo Peng wrote:
The .lyx format is not really working. One can, e.g. not use
'real' text within math, which makes implementing e.g. \mbox
impossible.
There must be some good reasons to change .lyx format, and switch to
unicode. But those reasons are invisible to normal users like me. All
On Sat, Apr 01, 2006 at 09:13:17AM -0600, Bo Peng wrote:
> > The .lyx format is not really working. One can, e.g. not use
> > 'real' text within math, which makes implementing e.g. \mbox
> > impossible.
>
> There must be some good reasons to change .lyx format, and switch to
> unicode. But those r
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > The .lyx format is not really working. One can, e.g. not use
| > 'real' text within math, which makes implementing e.g. \mbox
| > impossible.
|
| There must be some good reasons to change .lyx format, and switch to
| unicode. But those reasons are invisib
> The .lyx format is not really working. One can, e.g. not use
> 'real' text within math, which makes implementing e.g. \mbox
> impossible.
There must be some good reasons to change .lyx format, and switch to
unicode. But those reasons are invisible to normal users like me. All
I can see is that I
On Fri, Mar 31, 2006 at 06:49:41AM -0600, Bo Peng wrote:
> > Think *unicode* and forget about this one for now.
>
> If you ask me what are the most important features I have in mind. I
> would say: NO more new features. If .lyx format is working, why XML?
> If current foreign language support is f
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> If current foreign language support is fine, why unicode?
The problem is that it is not fine, it is a hack.
JMarc
ode or scripting language support.
Just my two cents.
Bo
Charles de Miramon wrote:
> I'm not a developper but I'm wondering if you are not underestimating the
> complexity of going Unicode.
I don't think so.
> Changing the internal format to Unicode is
> maybe not that hard but having a fully Unicode editor is *very* complex.
And the latter is not t
On Fri, 2006-03-31 at 12:34 +0200, Charles de Miramon wrote:
> Lars Gullik Bjønnes wrote:
>
> >
> > Think *unicode* and forget about this one for now.
> >
>
> I'm not a developper but I'm wondering if you are not underestimating the
> complexity of going Unicode. Changing the internal format to
Lars Gullik Bjønnes wrote:
>
> Think *unicode* and forget about this one for now.
>
I'm not a developper but I'm wondering if you are not underestimating the
complexity of going Unicode. Changing the internal format to Unicode is
maybe not that hard but having a fully Unicode editor is *very* co
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > If we are going for this it will be a major new feature (IMHO) and
| > should then wait for 1.7.
|
| And it needs cleanup of classes like buffer. Anyway, the real
| implementation is *easy* so this feature is not that far away from us.
This feature has a
> If you want to wrap c++ to interface with python, I suggest boost::python.
> It's easy once you get over the learning curve, and we're already using
> boost.
That is true, but I only know SWIG. :-) While SWIG can wrap all the
classes automatically, boost::python need to write things manually
(an
Bo Peng wrote:
>> If we are going for this it will be a major new feature (IMHO) and
>> should then wait for 1.7.
>
> And it needs cleanup of classes like buffer. Anyway, the real
> implementation is *easy* so this feature is not that far away from us.
>
> Bo
If you want to wrap c++ to interfac
> If we are going for this it will be a major new feature (IMHO) and
> should then wait for 1.7.
And it needs cleanup of classes like buffer. Anyway, the real
implementation is *easy* so this feature is not that far away from us.
Bo
"Bo Peng" <[EMAIL PROTECTED]> writes:
| Dear list,
|
| I just read a bit about 'LyX Wanted Features list' and saw
|
| Scripting language: Support a scripting language to control various
| parts of LyX, this requires deciding on an official scripting
| language. The
Dear list,
I just read a bit about 'LyX Wanted Features list' and saw
Scripting language: Support a scripting language to control various
parts of LyX, this requires deciding on an official scripting
language. The idea is for non-core parts of LyX to be moved to the
scripting languag
On Tuesday 01 February 2005 15:10, G. Milde wrote:
>
> These are the first to spring into my mind. There are more to expect. But
> also, they (and the existing ones) must be documented in order to be
> usable.
>
> My goal is to get for lyx a broad base of user-provided extensions in the
> way we th
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "G" == G Milde <[EMAIL PROTECTED]> writes:
>
| G> The keybinding is not really needed. If the code becomes more clear
| G> and concise by removing, please do so.
>
| It does not really change the code. It is just a matter of design of
| the l
> "G" == G Milde <[EMAIL PROTECTED]> writes:
G> The keybinding is not really needed. If the code becomes more clear
G> and concise by removing, please do so.
It does not really change the code. It is just a matter of design of
the lyxsever protocol.
G> I thought to keep it for backwards comp
On 2.02.05, Jean-Marc Lasgouttes wrote:
> > "G" == G Milde <[EMAIL PROTECTED]> writes:
>
> G> Feature Request ===
>
> G> Could the lfun "server-notify" take an data argument, that is
> G> passed on to the lyxserver?
>
> Sure. And what about getting rid of the key binding too? Is
> "G" == G Milde <[EMAIL PROTECTED]> writes:
G> Feature Request ===
G> Could the lfun "server-notify" take an data argument, that is
G> passed on to the lyxserver?
Sure. And what about getting rid of the key binding too? Is it really
useful to the client?
JMarc
On 27.01.05, Jose' Matos wrote:
> This is something that I wanted to do for quite some time. :-)
So did I. That's why I'm glad I did it finally.
> PS: In another movement (no pun John ;-) to help python scripting for lyx
> the lyx2lyx program has become only a int
On Fri, Jan 28, 2005 at 09:01:04AM +, Angus Leeming wrote:
> > Super-glad to see Asger back into the fold. He can be a less hated me!!
> He's just got a thicker skin ;-) How the hell are you anyway?
Fine, insanity at work has mitigated into mere eccentricity. I might
even build a recent lyx s
John Levon wrote:
> Super-glad to see Asger back into the fold. He can be a less hated me!!
He's just got a thicker skin ;-) How the hell are you anyway?
--
Angus
On Thu, Jan 27, 2005 at 07:03:11PM +, Jose' Matos wrote:
> PS: In another movement (no pun John ;-) to help python scripting for lyx
Is this a test on whether I'm still listening? :)
Super-glad to see Asger back into the fold. He can be a less hated me!!
john
e is interest (and consent that
> this is the right place), I'd like to discuss this issue further.
Please do.
> GÃnter
PS: In another movement (no pun John ;-) to help python scripting for lyx
the lyx2lyx program has become only a interface to the new LyX.py module.
The main
On 19.01.05, Angus Leeming wrote:
> G. Milde wrote:
> > Dear LyXers,
> >
> > IMHO, LyX clearly lacks a decent support for a scripting language. As
> > this topic is not new but discussion about which language to choose is
> > endless, I tried to set up a s
I was wondering, is there a way that it could be possible to generate
box scripts. What I mean by this is, say there was a small feature that
I wanted to add, and it consisted of some latex code with arguments
passed to it. A good example would be this acronym feature. The box
script could l
At 15:04 18.02.02 +0100, you wrote:
>On Sat, Feb 16, 2002 at 03:18:41AM +0100, Florian Klaempfl wrote:
> > Is this still up-to-date?
>
>Fairly.
>
> > Or are there plans to do anything using the Lyx-Server? If not, I'd
> glad to
> > implement parts of the
&
On Mon, 18 Feb 2002, Andre Poenitz wrote:
> I'd like to have the decision on LyX's favourite scripting language first.
www.lua.org.
Greets,
Asger
> If I make patches to integrate Python directly into Lyx, is there a
> chance that they make it into the official sources? As I can see with my
> current knowledge about the lyx sources and the Python lib, the changes
> to the existing sources will be very little for basic scripting
On Sat, Feb 16, 2002 at 03:18:41AM +0100, Florian Klaempfl wrote:
> Is this still up-to-date?
Fairly.
> Or are there plans to do anything using the Lyx-Server? If not, I'd glad to
> implement parts of the
> the scripting capabilities into Lyx.
>
> Furhter, I would p
pipes in your favourite
scripting language, then that language sucks. It's not exactly a complicated
protocol.
> Further, the lyx server solution looks very home brewed to me,
> there are standard solutions like CORBA.
"Waiter there's a fly in my soup !"
"Ah let
At 02:28 16.02.02 +, you wrote:
>On Sat, Feb 16, 2002 at 03:18:41AM +0100, Florian Klaempfl wrote:
>
> > Or are there plans to do anything using the Lyx-Server? If not, I'd
> glad to
> > implement parts of the
> > the scripting capabilities into Lyx.
>
&
On Sat, Feb 16, 2002 at 03:18:41AM +0100, Florian Klaempfl wrote:
> Or are there plans to do anything using the Lyx-Server? If not, I'd glad to
> implement parts of the
> the scripting capabilities into Lyx.
the idea is to sort out the lyxfunc interface (what lyx server uses) so
Is this still up-to-date?
Scripting language
Support a scripting language to control various parts of LyX, this requires
deciding on an official scripting language. The idea is for non-core parts
of LyX to be moved to the scripting language and thus simplifying extension
and customization
to LyX, after all we want to move things that are currently implemented
in LyX core into the scripting languages. Specificaly things like
uppercase-word could be moved to script instead of cluttering the core.
--
Baruch Even
http://baruch.ev-en.org/
On Sun, 3 Jun 2001, Baruch Even wrote:
> There was a suggestion to do a shootout between scripting languages. It
> was mostly done already, though not in the context of an embedded
> editor.
>
> Check this site for comparisons: http://www.bagley.org/~doug/shootout/
>
>
There was a suggestion to do a shootout between scripting languages. It
was mostly done already, though not in the context of an embedded
editor.
Check this site for comparisons: http://www.bagley.org/~doug/shootout/
This is by no means complete or correct, the author says that many of
the
embedded
script as soon as the file is read.
My little analogy should demonstrate why "scripting language != Macro
Virus" in the Unix world. Only a blithering idiot would intentionally
design a program to auto-execute anything whatsoever. I'd like to
think that we on the LyX Team ar
d
to live without:
1) recordability: There should be some ability to record a sequence of
actions, save them in the scripting language, and make them
activatable. For example, a user would likely want to take the
sequence of actions which produce a 3x3 matrix with braces around it,
and the cu
Hi,
It's Friday, so I'll throw my tuppence-worth in here.
Candidates I would consider:
1. Perl. But only because it's free and people know it.
It's a great text-processing language, but it's not
really a control language, which I imagine is the
priority.
2. Javascript. It's pretty s
>
> However, we need to be careful about that new EU parentheses tax . . .
>
> :)
If I read the tax manual correctly, smilies count as 'half of a pair of
paranthesis' if imported from outside the EU. But if used in vegetarian
text, the tax is halved.
Anyway, I'd rather have something easy to r
lars lamented,
> *Mate Wierdl writes:
> | Ah, I read the thread. My question was what was the objection to
> | Scheme here on *this* list.
> I have none.
> Asger things it has complicated syntax for beginners.
The fact that I was able to sit down and start using it in an afternoon
sugges
*Mate Wierdl writes:
| Ah, I read the thread. My question was what was the objection to
| Scheme here on *this* list.
I have none.
Asger things it has complicated syntax for beginners.
Lgb
*Jean-Marc Lasgouttes writes:
| I am not against the principle of using something like python. The
| only thing that annoys me is that, according to what I read, next
| version will require:
|
| - python
|
| - something like t1lib to do Type1 fonts rendering, plus a bunch of
| TeX type1
On Fri, Dec 11, 1998 at 07:19:04PM -0500, Cedric Puddy wrote:
> On Fri, 11 Dec 1998, Mate Wierdl wrote:
> http://icemcfd.com/tcl/comparison.html
> >
> > Looks very interesting. The GNU people seem to have made up their mind(s).
> > What was the objection against scheme here?
> >
> > ---
>
cure!],
> > and lots of other very knowledgable people) about
> > Tcl VS. other scripting languages. Most heavily
> > featured as an alternative was scheme.
> >
> > The messages were all collected and arranged at:
> >
> > http://icemcfd.com/tcl/compa
1 - 100 of 110 matches
Mail list logo
