Georg Baum <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
|
| > Why a separate from_ascii really? If it is ascii, then it is also
| > utf-8.
|
| Sure. I made it separate because that makes the intention very clear: If we
| know that it is ASCII we don't need a more costly utf8 convers
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Fri, Sep 01, 2006 at 06:06:35PM +0200, Michael Gerz wrote:
| > Andre Poenitz schrieb:
| > >On Wed, Aug 30, 2006 at 10:28:54PM +0200, Michael Gerz wrote:
| > >
| > >>? chars-transpose- ???
| > >>
| > >
| > >'xp' in vi - swap two adjancent
When using autotools lyx2lyx_version.py is generated in lib/lyx2lyx
under the build directory. If you run lyx in place, this directory
is also taken into account and thus lyx2lyx_version.py is found:
I agree that this is convenient, but it is against the idea of
source/build separation. Right no
On Sun, Sep 03, 2006 at 09:25:48PM -0500, Bo Peng wrote:
> > When LyX is run in place, lyx2lyx_version.py should be found in the
> > build_support dir. IIRC, the build_support dir is not correctly spotted
> > in a native Windows build. Run "lyx -dbg init" to check it.
>
> I am not quite sure how
On Sun, Sep 03, 2006 at 09:47:50PM +0200, Georg Baum wrote:
> I believe that the attached patch should make the unicode conversions work
> on little and big endian machines, and removes the uncertainty whether
> UCS-4 is LE or BE.
Yep. With this patch I can load old LyX files when using the qt3
When LyX is run in place, lyx2lyx_version.py should be found in the
build_support dir. IIRC, the build_support dir is not correctly spotted
in a native Windows build. Run "lyx -dbg init" to check it.
I am not quite sure how autotools handle lyx2lyx_version.py but for
scons, it is generated from
On Mon, Sep 04, 2006 at 12:30:28AM +0200, Michael Gerz wrote:
> Hello,
>
> I think we should re-introduce the "Layout" menu which was dropped in
> the 1.4.X series. The main reason is that every word processor (even
> UltraEdit!) has such a menu. The additional menu item also reduces the
> si
On Sun, Sep 03, 2006 at 06:49:34PM +0100, José Matos wrote:
> On Sunday 03 September 2006 10:28, Abdelrazak Younes wrote:
> > So this means that neither scons nor autotools will work exclusively
> > with trunk/lib? I mean without a "make install"?
>
> They do, but I had not explored how they do
Hello,
I think we should re-introduce the "Layout" menu which was dropped in
the 1.4.X series. The main reason is that every word processor (even
UltraEdit!) has such a menu. The additional menu item also reduces the
size of the "Edit" menu.
Any comments?
Michael
# -*- text -*-
# file st
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Could you remove the separation between Header and Source files in the
different projects?
I've changed the cmake files. Now all headers and source files are in the
"The Golden Code" folder. ;)
The name could easily change
Bo Peng wrote:
If I understand correctly Andre and Georg report it seems that they do
not...
I run 'scons install' instead of 'scons lyx' or 'scons all' to test
lyx. This is safer although you can run scons install once to get the
lib files in place, and then 'scons lyx' to build lyx later.
W
I think the CMake support has a long way to go compared with Scons (for
now)
I think it can catch up quickly if more people use it and report bugs.
A detailed INSTALL.cmake would help. Current cmake readme seems
sketchy.
but I really like the fact that MSVC project are real projects.
This has
Georg Baum wrote:
There is something with the byte order I don't understand. I just found out
that with the iconv on my little endian linux box UCS-4 == UCS-4BE. That
means that the bytes coming from iconv are in big endian byte order. This
is reversed in bytes_to_ucs4:
Comments and tests o
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Could you remove the separation between Header and Source files in the
different projects?
I've changed the cmake files. Now all headers and source files are in the
"The Golden Code" folder. ;)
The name could easily changed by using the command lin
If I understand correctly Andre and Georg report it seems that they do
not...
I run 'scons install' instead of 'scons lyx' or 'scons all' to test
lyx. This is safer although you can run scons install once to get the
lib files in place, and then 'scons lyx' to build lyx later.
Note that scons in
Peter Kümmel wrote:
Edwin Leuven wrote:
Peter Kümmel wrote:
Do you use the files from zlib.net?
from gnuwin32
If not, no problem:
goto to the including of unistd.h in zconf.h, you will see
a #if block, just disable the including.
yes, that's what i ended up doing
it now compiles. if i run
Georg Baum wrote:
Am Donnerstag, 24. August 2006 18:47 schrieb Abdelrazak Younes:
Enrico Forestieri wrote:
I have compiled a Cygwin version of LyX/Qt4 using the native GUI (no
X11)
and now I see the chinese characters mentioned by Abdel when I load
an old document. I also get a lot of message
Am Donnerstag, 24. August 2006 18:47 schrieb Abdelrazak Younes:
> Enrico Forestieri wrote:
> > I have compiled a Cygwin version of LyX/Qt4 using the native GUI (no
X11)
> > and now I see the chinese characters mentioned by Abdel when I load
> > an old document. I also get a lot of messages on the
Peter Kümmel wrote:
It crashes? Here I've no problems.
that was a missing sysdir.
now it crashes when i open the document settings dialog and then close
it again
it all feels like black magic
things are so simple under linux, sigh
btw, is there a way to do a "make install"?
It is possi
José Matos wrote:
On Sunday 03 September 2006 10:28, Abdelrazak Younes wrote:
So this means that neither scons nor autotools will work exclusively
with trunk/lib? I mean without a "make install"?
They do, but I had not explored how they do it. :-)
If I understand correctly Andre and Georg
On Sunday 03 September 2006 19:37, Peter Kümmel wrote:
> > thanks again!
>
> I have to thank for the population of my empty cmake-universe. ;)
Please make sure that the documentation is more or less up to date. I will
try it on linux. (FC5 FWIW).
> --
> Peter
--
José Abílio
Edwin Leuven wrote:
> Peter Kümmel wrote:
>> Do you use the files from zlib.net?
>
> from gnuwin32
>
>> If not, no problem:
>> goto to the including of unistd.h in zconf.h, you will see
>> a #if block, just disable the including.
>
> yes, that's what i ended up doing
>
> it now compiles. if i ru
Abdelrazak Younes wrote:
> Could you remove the separation between Header and Source files in the
> different projects?
I've changed the cmake files. Now all headers and source files are in the
"The Golden Code" folder. ;)
The name could easily changed by using the command line option:
-DCODE_GRO
On Sunday 03 September 2006 10:28, Abdelrazak Younes wrote:
> So this means that neither scons nor autotools will work exclusively
> with trunk/lib? I mean without a "make install"?
They do, but I had not explored how they do it. :-)
--
José Abílio
Abdelrazak Younes wrote:
OK, now where do I have to install the dictionary so that aspell will
find it?
That's easy. The patched Aspell reads the location from the registry.
You can either install the dictionaries using the official 1.4.2
installer or download them at:
http://wiki.lyx.org/W
Peter Kümmel wrote:
Do you use the files from zlib.net?
from gnuwin32
If not, no problem:
goto to the including of unistd.h in zconf.h, you will see
a #if block, just disable the including.
yes, that's what i ended up doing
it now compiles. if i run the executable it crashes though
btw, i
Edwin Leuven wrote:
> Peter Kümmel wrote:
>> Maybe there was a compiler error while building
>> support.lib?
>
> it seems to compile fine. i do get the following error in boost_iostreams:
>
>
> 1>Compiling...
> 1>zlib.cpp
> 1>c:\programs\gnuwin32\include\zconf.h(289) : fatal error C1083: Cannot
Joost Verburg wrote:
Abdelrazak Younes wrote:
Yes, they are both there and found by scons and cmake. Interestingly,
with a full cmake rebuild the menu item is no more disabled. But when
pressing F7, I have now a message box saying:
The spellchecker could not be started
Native OS API not yet s
Peter Kümmel wrote:
Maybe there was a compiler error while building
support.lib?
it seems to compile fine. i do get the following error in boost_iostreams:
1>Compiling...
1>zlib.cpp
1>c:\programs\gnuwin32\include\zconf.h(289) : fatal error C1083: Cannot
open include file: 'unistd.h': No such
Am Sonntag, 3. September 2006 16:18 schrieb Abdelrazak Younes:
> Georg Baum wrote:
> > Am Sonntag, 3. September 2006 15:56 schrieb Abdelrazak Younes:
> >> Georg Baum wrote:
> >>> Am Sonntag, 3. September 2006 15:30 schrieb Abdelrazak Younes:
> Question first: std::tolower() is a template and c
Abdelrazak Younes wrote:
> Peter,
>
> Could you remove the separation between Header and Source files in the
> different projects?
>
> Abdel.
>
>
Yes, this is really annoying, but I was never "forced" to change it. ;)
--
Peter
Edwin Leuven wrote:
> Peter Kümmel wrote:
>> Done. Please update and try again.
>
> thanks, this now works
>
> compiling fails however:
>
> "cannot open file 'support.lib'"
>
>
Maybe there was a compiler error while building
support.lib?
--
Peter
Peter Kümmel wrote:
Done. Please update and try again.
thanks, this now works
compiling fails however:
"cannot open file 'support.lib'"
Peter,
Could you remove the separation between Header and Source files in the
different projects?
Abdel.
Georg Baum wrote:
Am Sonntag, 3. September 2006 15:56 schrieb Abdelrazak Younes:
Georg Baum wrote:
Am Sonntag, 3. September 2006 15:30 schrieb Abdelrazak Younes:
Question first: std::tolower() is a template and compiles fine with
char_type.
??? std::tolower comes from the C library (ctype.h) a
Am Sonntag, 3. September 2006 15:56 schrieb Abdelrazak Younes:
> Georg Baum wrote:
> > Am Sonntag, 3. September 2006 15:30 schrieb Abdelrazak Younes:
> >> Question first: std::tolower() is a template and compiles fine with
> >> char_type.
> >
> > ??? std::tolower comes from the C library (ctype.h
Georg Baum wrote:
Am Sonntag, 3. September 2006 15:30 schrieb Abdelrazak Younes:
Question first: std::tolower() is a template and compiles fine with
char_type.
??? std::tolower comes from the C library (ctype.h) and is defined like
this:
int tolower(int);
MSVC doc says:
Converts a charac
Also sprach Michael Gerz:
> > + // Fall through
> >
>
> Missing "break;" ???
No. See the "Fall through" comment.
Jürgen
Juergen Spitzmueller schrieb:
I'm presently committing the attached patch that disables inset-dissolve
correctly (preventing a crash in an invalid case) and also disables it for
table insets.
Great!
+ case LFUN_CHAR_DELETE_FORWARD:
+ if (!cur.selection() && cur.depth() >
Peter Kümmel wrote:
> Edwin Leuven wrote:
>> Peter Kümmel wrote:
>>> When you start LyX the dll must be found, so you must add
>>> the path to this dll to your PATH varable, eg:
>>> set PATH=%PATH%;c:\Programme\gnuwin32\bin
>> but there is only a libiconv2.dll there...
>>
>>
>
> I add libiconv2.dl
Am Sonntag, 3. September 2006 15:30 schrieb Abdelrazak Younes:
> Question first: std::tolower() is a template and compiles fine with
> char_type.
??? std::tolower comes from the C library (ctype.h) and is defined like
this:
int tolower(int);
> The cast is not useful here as the test above ensu
Georg Baum wrote:
Am Sonntag, 3. September 2006 15:20 schrieb Abdelrazak Younes:
Yes, it compiles. I will commit it with two more methods if that is fine
with you:
Why different casts?
Temporay code... Here is the correct version:
char_type lowercase(char_type c)
{
if (c >= 256)
Am Sonntag, 3. September 2006 15:20 schrieb Abdelrazak Younes:
> Yes, it compiles. I will commit it with two more methods if that is fine
> with you:
>
> char_type lowercase(char_type c)
> {
> if (c >= 256)
> return c;
>
> return tolower(static_cast(c));
> }
>
>
I'm presently committing the attached patch that disables inset-dissolve
correctly (preventing a crash in an invalid case) and also disables it for
table insets.
I have also integrated those changes to my (uncommitted) backport of the
feature to 1.4.
Jürgen
Index: src/insets/insettabular.C
===
Abdelrazak Younes wrote:
Georg Baum wrote:
Am Sonntag, 3. September 2006 14:48 schrieb Abdelrazak Younes:
Georg,
Your template solution for subst() doesn't please MSVC:
I almost expected that ;-) Does this patch work? If yes please commit it.
Yes, it compiles. I will commit it with two mor
Edwin Leuven wrote:
> Peter Kümmel wrote:
>> When you start LyX the dll must be found, so you must add
>> the path to this dll to your PATH varable, eg:
>> set PATH=%PATH%;c:\Programme\gnuwin32\bin
>
> but there is only a libiconv2.dll there...
>
>
I add libiconv2.dll as possible name.
--
Peter Kümmel wrote:
When you start LyX the dll must be found, so you must add
the path to this dll to your PATH varable, eg:
set PATH=%PATH%;c:\Programme\gnuwin32\bin
but there is only a libiconv2.dll there...
Georg Baum wrote:
Am Sonntag, 3. September 2006 14:48 schrieb Abdelrazak Younes:
Georg,
Your template solution for subst() doesn't please MSVC:
I almost expected that ;-) Does this patch work? If yes please commit it.
Yes, it compiles. I will commit it with two more methods if that is fine
Edwin Leuven wrote:
> Abdelrazak Younes wrote:
>> Edwin Leuven wrote:
>>> fails for me. anyone knows what is wrong here? i get the following
>>> error. thanks, ed.
>>
>> First "svn update" cause' Peter has done some recent correction and
>> then I just use:
>>
>> D:\devel\lyx\trunk\development\cmak
Abdelrazak Younes wrote:
Edwin Leuven wrote:
fails for me. anyone knows what is wrong here? i get the following
error. thanks, ed.
First "svn update" cause' Peter has done some recent correction and then
I just use:
D:\devel\lyx\trunk\development\cmake>cmake . -Dnls=1
-DGNUWIN32_DIR=D:\pro
Am Sonntag, 3. September 2006 14:48 schrieb Abdelrazak Younes:
> Georg,
>
> Your template solution for subst() doesn't please MSVC:
I almost expected that ;-) Does this patch work? If yes please commit it.
Georg
Index: src/support/lstrings.C
=
Am Sonntag, 3. September 2006 14:45 schrieb Andre Poenitz:
> Objections?
No. When I first looked at math stuff I was surprised by the heavy string
usage anyway, and we even introduced enums for new stuff like
MathFracInset::Kind.
> PS: Opening the current UserGuide with current LyX results in
[EMAIL PROTECTED] wrote:
Author: baum
Date: Sun Sep 3 09:02:38 2006
New Revision: 14871
URL: http://www.lyx.org/trac/changeset/14871
Log:
Fix clipboard/selection encoding
* src/frontends/qt[34]/qt_helpers.[Ch]
(toqstr): add variant for docstring
(qstring_to_ucs4): Use d
On Sun, Sep 03, 2006 at 02:45:01PM +0200, Andre' Poenitz wrote:
> - virtual std::string const & getType() const;
> + virtual HullType getType() const;
> /// change type
> - virtual void mutate(std::string const &) {}
> + virtual void mutate(HullType &) {}
Grmpf.
This should,
On Sun, Sep 03, 2006 at 12:21:51PM +0200, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
> >I just finished compiling the Qt4 frontend with Qt4.1.4/X11.
> >
> >I needed the following change:
> >
> >Index: config/qt.m4
> >===
>
> I th
On Sun, Sep 03, 2006 at 12:26:13PM +0200, Georg Baum wrote:
> This is old code. qt4.m4 is used now for qt4. Maybe your sources are not up
> to date?
I had a zero diff against current svn _and_ run autogen.sh.
There might have been some leftovers fromearlier builds, though..
Andre'
Abdelrazak Younes wrote:
I still have my linking errors:
Try a clean rebuild with the latest SVN version. Bo already fixed this
problem.
Joost
The attached patch replaces hull types like "simple", "eqnarray" with an
enum 'hullSimple', 'hullEqnArray' etc.
Should save a few CPU cycles, be more typesafe and prevent a controversy
in which string format the type should be stored.
Objections?
Andre'
PS: Opening the current UserGuide with c
Abdelrazak Younes wrote:
Yes, they are both there and found by scons and cmake. Interestingly,
with a full cmake rebuild the menu item is no more disabled. But when
pressing F7, I have now a message box saying:
The spellchecker could not be started
Native OS API not yet supported.
I guess I s
Abdelrazak Younes wrote:
> Edwin Leuven wrote:
>> fails for me. anyone knows what is wrong here? i get the following
>> error. thanks, ed.
>
> First "svn update" cause' Peter has done some recent correction and then
> I just use:
>
> D:\devel\lyx\trunk\development\cmake>cmake . -Dnls=1
> -DGNUWI
Edwin Leuven wrote:
fails for me. anyone knows what is wrong here? i get the following
error. thanks, ed.
First "svn update" cause' Peter has done some recent correction and then
I just use:
D:\devel\lyx\trunk\development\cmake>cmake . -Dnls=1
-DGNUWIN32_DIR=D:\program\GnuWin32
It should
fails for me. anyone knows what is wrong here? i get the following
error. thanks, ed.
C:\build\cmake>cmake -G "Visual Studio 8 2005" c:\svn\development\cmake
CMake Error: Error in cmake code at
c:/svn/development/cmake/modules/FindGNUWIN32.cmake:36:
MESSAGE Could NOT find GNUWIN32
Current CMa
Abdelrazak Younes wrote:
Side note: any key in a mathed inset is treated as a space now (with or
without the space).
hum... (with or without the _patch_).
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
Am Sonntag, 3. September 2006 12:11 schrieb Abdelrazak Younes:
This patch fixes the isDigit() MSVC warning in ControlSpellchecker.C.
If that is really the correct isDigit() check for unciode
My understanding is that ascii
Martin Vermeer wrote:
> Ah, great that you found that old one. Do I guess right from reading the
> patch that bug 1332 remains fixed, i.e., does not come unfixed?
Yes. I just restored to the old behaviour (not copying the layout for the
first paragraph in an empty target paragraph) in the case of
This patch converts MathMacroTemplate::prefix() to docstring.
Will commit soon.
Abdel.
Index: math_macrotemplate.C
===
--- math_macrotemplate.C(revision 14870)
+++ math_macrotemplate.C(working copy)
@@ -102,9 +102,10
Georg Baum wrote:
Am Sonntag, 3. September 2006 12:28 schrieb Abdelrazak Younes:
Georg Baum wrote:
Am Sonntag, 3. September 2006 12:11 schrieb Abdelrazak Younes:
This patch fixes the isDigit() MSVC warning in ControlSpellchecker.C.
If that is really the correct isDigit() check for unciode
My
Am Sonntag, 3. September 2006 12:28 schrieb Abdelrazak Younes:
> Georg Baum wrote:
> > Am Sonntag, 3. September 2006 12:11 schrieb Abdelrazak Younes:
> >> This patch fixes the isDigit() MSVC warning in ControlSpellchecker.C.
> >
> > If that is really the correct isDigit() check for unciode
>
> My
Am Sonntag, 3. September 2006 12:25 schrieb Andre Poenitz:
> Do you really want to start mixing different string types in the core?
Lars did that already, since he did introduce docstring only very
selectively.
> I'd rather store also LaTeX command names as dostrings...
LaTeX command names may
On Sat, Sep 02, 2006 at 04:30:04PM +0200, Juergen Spitzmueller wrote:
> Martin Vermeer wrote:
> > Fair enough... but could you put a link to this discussion
> > on bugzilla?
>
> Finally, I couldn't resist. See attached patch (against trunk). Please test
> someone.
> BTW this bug is a consequence
Abdelrazak Younes wrote:
Georg Baum wrote:
Am Sonntag, 3. September 2006 12:11 schrieb Abdelrazak Younes:
This patch fixes the isDigit() MSVC warning in ControlSpellchecker.C.
If that is really the correct isDigit() check for unciode
My understanding is that ascii is a subset of ucs4 so it
Georg Baum wrote:
Am Sonntag, 3. September 2006 12:11 schrieb Abdelrazak Younes:
This patch fixes the isDigit() MSVC warning in ControlSpellchecker.C.
If that is really the correct isDigit() check for unciode
My understanding is that ascii is a subset of ucs4 so it must work as is.
then you
Am Sonntag, 3. September 2006 12:16 schrieb Andre Poenitz:
>
> I just finished compiling the Qt4 frontend with Qt4.1.4/X11.
>
> I needed the following change:
>
> Index: config/qt.m4
> ===
> --- config/qt.m4 (revision 14458)
> +++
Am Sonntag, 3. September 2006 12:11 schrieb Abdelrazak Younes:
> This patch fixes the isDigit() MSVC warning in ControlSpellchecker.C.
If that is really the correct isDigit() check for unciode then you simply
could have changed the argument type of the existing function.
I did not touch this on
Andre Poenitz wrote:
I just finished compiling the Qt4 frontend with Qt4.1.4/X11.
I needed the following change:
Index: config/qt.m4
===
I thought Qt4 would use qt4.m4??
qt.m4 should probably be renamed qt3.m4, or perhaps deleted
On Sun, Sep 03, 2006 at 11:11:11AM +0200, Georg Baum wrote:
> Am Sonntag, 3. September 2006 10:50 schrieb Michael Gerz:
> > Hi,
> >
> > as far as I understand, all occurrences of std::string are supposed to
> > be replaced by docstring sooner or later.
>
> No. All occurrences of std::string that
On Fri, Sep 01, 2006 at 06:06:35PM +0200, Michael Gerz wrote:
> Andre Poenitz schrieb:
> >On Wed, Aug 30, 2006 at 10:28:54PM +0200, Michael Gerz wrote:
> >
> >>? chars-transpose- ???
> >>
> >
> >'xp' in vi - swap two adjancent characters.
> >
> >Andre'
> >
> Who needs such a functio
I just finished compiling the Qt4 frontend with Qt4.1.4/X11.
I needed the following change:
Index: config/qt.m4
===
--- config/qt.m4 (revision 14458)
+++ config/qt.m4 (working copy)
@@ -472,7 +472,7 @@
AC_SUBST(QT4_LDFLAGS)
d
This patch fixes the isDigit() MSVC warning in ControlSpellchecker.C.
Committing now...
Abdel.
Index: support/textutils.h
===
--- support/textutils.h (revision 14870)
+++ support/textutils.h (working copy)
@@ -15,6 +15,7 @@
#ifndef
Joost Verburg wrote:
Abdelrazak Younes wrote:
One question: where does the aspell libraries expect the
dictionnaries? Maybe that's the reason of the greying out?
When a dictionary is missing you will get a message box. The option
will not be grayed out.
If you are compiling a debug version
Georg Baum wrote:
> Am Sonntag, 3. September 2006 10:50 schrieb Michael Gerz:
>> Hi,
>>
>> as far as I understand, all occurrences of std::string are supposed to
>> be replaced by docstring sooner or later.
>
> No. All occurrences of std::string that store document content are supposed
> to be r
José Matos wrote:
On Saturday 02 September 2006 09:07, Abdelrazak Younes wrote:
ImportError: No module named lyx2lyx_version
This is with a CMake build, so maybe this explains that. Peter, any clue?
There is a file lyx2lyx_version.py.in that is converted with both autotools
and scons. The
Am Sonntag, 3. September 2006 10:50 schrieb Michael Gerz:
> Hi,
>
> as far as I understand, all occurrences of std::string are supposed to
> be replaced by docstring sooner or later.
No. All occurrences of std::string that store document content are supposed
to be replaced. There is no need to
Hi,
as far as I understand, all occurrences of std::string are supposed to
be replaced by docstring sooner or later.
A simple grep shows about 8000 (!) occurrences of std::string. I wonder
whether we should apply a global search&replace and fix the shard
afterwards...
Michael
Bo Peng wrote:
Sorry, forgot to tell you. SCons does indeed link statically by default.
Add CCFLAGS="/MD /TP /EHsc /nologo /O2" to the scons command line to get
dynamic linking.
I think dynamic linking should be the default. Bo, can you add the /MD
flag?
Done for both trunk and branch. Note t
Joost Verburg wrote:
Abdelrazak Younes wrote:
One question: where does the aspell libraries expect the
dictionnaries? Maybe that's the reason of the greying out?
When a dictionary is missing you will get a message box. The option
will not be grayed out.
If you are compiling a debug version
86 matches
Mail list logo
