From eblevins at insight.rr.com Sun Feb 2 14:52:08 2003
From: eblevins at insight.rr.com (Eric L. Blevins)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Force Freetype1 problem, suggested change to configure.in
Message-ID: <008c01c2caf4$9246ce20$6405a8c0@piii933>
This is a multi-part message in MIME format.
------=_NextPart_000_0089_01C2CACA.A91ADDF0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
First I'll say that I am not very familiar with autoconf or even C =
programming.
I made some changes to the configure.in file that work much better for =
me and thought I would share them.
First I'll explain my particular problem and provide the solution that =
works on my system.
I am using FreeBSD 4.7
I have both freetype1 and freetype2 installed on my system from the =
freebsd ports.
the --enable-force-freetype1=3Dyes always detects that I have freetype2 =
and never sees freetype1
this part of the configure.in does not detect either library hence the =
reason it never finds freetype1 with --enable-force-freetype1
if test "$enable_force_freetype1" =3D "yes" ; then
dnl check for freetype1 first
AC_CHECK_LIB(ttf, TT_Init_FreeType, FT_LIB=3D"-lttf",
AC_CHECK_LIB(freetype, FT_Init_FreeType, =
FT_LIB=3D"-lfreetype",,) )
else
dnl check for freetype2 first
AC_CHECK_LIB(freetype, FT_Init_FreeType, FT_LIB=3D"-lfreetype",
AC_CHECK_LIB(ttf, TT_Init_FreeType, FT_LIB=3D"-lttf",,) )
fi
According to the autoconf documentation I read this should work but it =
does not for some strange reason.
So I did some copying and pasting in the configure.in and came up with =
these changes that do work for me.
now if I specify --enable-force-freetype1=3Dyes it detects freetype1 if =
I do not specify it it default to detecting freetype2
mapserver compiled fine and renders True Type fonts perfect with these =
changes.
FT_LIB=3D''
FT_BIN=3D''
FT_TYPE=3D''
+if test "$enable_force_freetype1" =3D "yes" ; then
+test -f $FT_DIR/lib/libttf.a -o -f $FT_DIR/lib/libttf.so -o -f =
$FT_DIR/lib/libttf.sl && FT_LIBDIR=3D"$FT_DIR/lib"
+ test -f $FT_DIR/libttf.a -o -f $FT_DIR/libttf.so -o -f =
$FT_DIR/libttf.sl && FT_LIBDIR=3D"$FT_DIR"
+ if test -n "$FT_LIBDIR" ; then
+ FT_TYPE=3D"-lttf"
+ fi
+
+else
test -x "$FT_DIR" -a "freetype-config" =3D "`basename $FT_DIR ''`" && =
FT_BIN=3D"$FT_DIR"
if test -n "$FT_LIBDIR" ; then
FT_TYPE=3D"-lttf"
fi
fi
fi
+fi
if test -n "$FT_LIBDIR" -a -z "$FT_BIN" ; then
--------------------------------------------------------
Eric L. Blevins www.WiFiMaps.com
--------------------------------------------------------
------=_NextPart_000_0089_01C2CACA.A91ADDF0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
First I'll say that I am not very =
familiar with=20
autoconf or even C programming.
I made some changes to the configure.in =
file that=20
work much better for me and thought I would share them.
First I'll explain my particular =
problem and=20
provide the solution that works on my system.
I am using FreeBSD 4.7
I have both freetype1 and freetype2 =
installed on my=20
system from the freebsd ports.
the --enable-force-freetype1=3Dyes =
always detects=20
that I have freetype2 and never sees freetype1
this part of the configure.in does not =
detect=20
either library hence the reason it never finds freetype1 with=20
--enable-force-freetype1
if test "$enable_force_freetype1" =3D =
"yes" ;=20
then
dnl check for freetype1 =
first
=20
AC_CHECK_LIB(ttf, TT_Init_FreeType,=20
FT_LIB=3D"-lttf",
=20
AC_CHECK_LIB(freetype, FT_Init_FreeType, FT_LIB=3D"-lfreetype",,) =
)
=20
else
dnl check for freetype2 =
first
=20
AC_CHECK_LIB(freetype, FT_Init_FreeType,=20
FT_LIB=3D"-lfreetype",
=20
AC_CHECK_LIB(ttf, TT_Init_FreeType, FT_LIB=3D"-lttf",,) )
=20
fi
According to the autoconf documentation =
I read this=20
should work but it does not for some strange reason.
So I did some copying and pasting in =
the=20
configure.in and came up with these changes that do work for =
me.
now if I specify =
--enable-force-freetype1=3Dyes it=20
detects freetype1 if I do not specify it it default to detecting=20
freetype2
mapserver compiled fine and renders =
True Type fonts=20
perfect with these changes.
FT_LIB=3D''
FT_BIN=3D''
FT_TYPE=3D''
+if test "$enable_force_freetype1" =3D =
"yes" ;=20
then
+test -f $FT_DIR/lib/libttf.a -o -f $FT_DIR/lib/libttf.so -o -f=20
$FT_DIR/lib/libttf.sl && FT_LIBDIR=3D"$FT_DIR/lib"
+ =
test -f=20
$FT_DIR/libttf.a -o -f $FT_DIR/libttf.so -o -f $FT_DIR/libttf.sl =
&&=20
FT_LIBDIR=3D"$FT_DIR"
+ if test -n "$FT_LIBDIR" ;=20
then
+ FT_TYPE=3D"-lttf"
+ fi
+
+else
test -x "$FT_DIR" -a =
"freetype-config" =3D=20
"`basename $FT_DIR ''`" && FT_BIN=3D"$FT_DIR"
if test -n =
"$FT_LIBDIR" ;=20
then
=20
FT_TYPE=3D"-lttf"
fi
=
fi
fi
+fi
if test -n "$FT_LIBDIR" -a -z "$FT_BIN" =
;=20
then
--------------------------------------------------------
Eric=
L.=20
Blevins www.WiFiMaps.com
----------------=
----------------------------------------
------=_NextPart_000_0089_01C2CACA.A91ADDF0--
From steve.lime at dnr.state.mn.us Mon Feb 3 23:13:37 2003
From: steve.lime at dnr.state.mn.us (Steve Lime)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] msBuildPath etc...
Message-ID:
Hi folks: I'd like to ditch passing shapepath around to msOpenLayer and
the shapefile routines. What's the best way to use the various
msBuildPath functions to do that? For the shapefile (and Xbase
functions) i'd like to simply pass the final file name. The logic (I
think) would be:
- if DATA or TABLE is full path, then use it
- if DATA or TABLE relative, and SHAPEPATH is valid then append it
- if SHAPEPATH relative, then append MAPPATH
If those that wrote those functions would help with their interpretation
that would be great.
steve
Stephen Lime
Data & Applications Manager
Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-297-2937
From morissette at dmsolutions.ca Mon Feb 3 23:38:32 2003
From: morissette at dmsolutions.ca (Daniel Morissette)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] msBuildPath etc...
References:
Message-ID: <3E3F43C8.851DE6FB@dmsolutions.ca>
Steve Lime wrote:
>
> Hi folks: I'd like to ditch passing shapepath around to msOpenLayer and
> the shapefile routines. What's the best way to use the various
> msBuildPath functions to do that? For the shapefile (and Xbase
> functions) i'd like to simply pass the final file name. The logic (I
> think) would be:
>
> - if DATA or TABLE is full path, then use it
> - if DATA or TABLE relative, and SHAPEPATH is valid then append it
> - if SHAPEPATH relative, then append MAPPATH
>
> If those that wrote those functions would help with their interpretation
> that would be great.
>
Hi Steve,
FYI msBuildPath() already contains logic to prevent concatenating two
absolute paths. There is also a msBuildPath3() function that takes 3
path components and combines them, so I believe you should be able to do
this:
char path_buffer[MS_MAXPATHLEN];
msBuildPath3(path_buffer, map_path, shape_path, data_filename);
Unless I'm mistaken, this call should do exactly what you proposed
above, i.e.
- if data_filename is an absolute path then map_path and shape_path
are ignored.
- if data_filename is relative then it is appended to shape_path
- if shape_path is absolute then map_path is ignored
- if shape_path is relative then it is appended to map_path.
- finally, if shape_path is null then it should be automatically
ignored and the result will be map_path appended to data_filename.
Oh, and if some error happens then the function returns NULL, otherwise
it will return a reference to path_buffer.
Julien, can you please confirm that this is the expected behavior?
Daniel
--
------------------------------------------------------------
Daniel Morissette morissette@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
From lacroix at dmsolutions.ca Tue Feb 4 09:51:12 2003
From: lacroix at dmsolutions.ca (Julien-Samuel Lacroix)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] msBuildPath etc...
References: <3E3F43C8.851DE6FB@dmsolutions.ca>
Message-ID: <3E3FD360.5030104@dmsolutions.ca>
You're perfectly right Daniel. I think the msBuildPath3 will do exactly
what you want, Steve.
Julien
Daniel Morissette wrote:
> Steve Lime wrote:
>
>>Hi folks: I'd like to ditch passing shapepath around to msOpenLayer and
>>the shapefile routines. What's the best way to use the various
>>msBuildPath functions to do that? For the shapefile (and Xbase
>>functions) i'd like to simply pass the final file name. The logic (I
>>think) would be:
>>
>> - if DATA or TABLE is full path, then use it
>> - if DATA or TABLE relative, and SHAPEPATH is valid then append it
>> - if SHAPEPATH relative, then append MAPPATH
>>
>>If those that wrote those functions would help with their interpretation
>>that would be great.
>>
>
>
> Hi Steve,
>
> FYI msBuildPath() already contains logic to prevent concatenating two
> absolute paths. There is also a msBuildPath3() function that takes 3
> path components and combines them, so I believe you should be able to do
> this:
>
> char path_buffer[MS_MAXPATHLEN];
> msBuildPath3(path_buffer, map_path, shape_path, data_filename);
>
> Unless I'm mistaken, this call should do exactly what you proposed
> above, i.e.
>
> - if data_filename is an absolute path then map_path and shape_path
> are ignored.
> - if data_filename is relative then it is appended to shape_path
> - if shape_path is absolute then map_path is ignored
> - if shape_path is relative then it is appended to map_path.
> - finally, if shape_path is null then it should be automatically
> ignored and the result will be map_path appended to data_filename.
>
> Oh, and if some error happens then the function returns NULL, otherwise
> it will return a reference to path_buffer.
>
> Julien, can you please confirm that this is the expected behavior?
>
> Daniel
--
------------------------------------------------------------
Julien-Samuel Lacroix lacroix@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
From steve.lime at dnr.state.mn.us Tue Feb 4 12:21:51 2003
From: steve.lime at dnr.state.mn.us (Steve Lime)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Force Freetype1 problem, suggested change
to configure.in
Message-ID:
Can those familiar with autoconf handle this one?
>>> "Eric L. Blevins" 02/02/03 01:52PM >>>
First I'll say that I am not very familiar with autoconf or even C
programming.
I made some changes to the configure.in file that work much better for
me and thought I would share them.
First I'll explain my particular problem and provide the solution that
works on my system.
I am using FreeBSD 4.7
I have both freetype1 and freetype2 installed on my system from the
freebsd ports.
the --enable-force-freetype1=yes always detects that I have freetype2
and never sees freetype1
this part of the configure.in does not detect either library hence the
reason it never finds freetype1 with --enable-force-freetype1
if test "$enable_force_freetype1" = "yes" ; then
dnl check for freetype1 first
AC_CHECK_LIB(ttf, TT_Init_FreeType, FT_LIB="-lttf",
AC_CHECK_LIB(freetype, FT_Init_FreeType, FT_LIB="-lfreetype",,)
)
else
dnl check for freetype2 first
AC_CHECK_LIB(freetype, FT_Init_FreeType, FT_LIB="-lfreetype",
AC_CHECK_LIB(ttf, TT_Init_FreeType, FT_LIB="-lttf",,) )
fi
According to the autoconf documentation I read this should work but it
does not for some strange reason.
So I did some copying and pasting in the configure.in and came up with
these changes that do work for me.
now if I specify --enable-force-freetype1=yes it detects freetype1 if I
do not specify it it default to detecting freetype2
mapserver compiled fine and renders True Type fonts perfect with these
changes.
FT_LIB=''
FT_BIN=''
FT_TYPE=''
+if test "$enable_force_freetype1" = "yes" ; then
+test -f $FT_DIR/lib/libttf.a -o -f $FT_DIR/lib/libttf.so -o -f
$FT_DIR/lib/libttf.sl && FT_LIBDIR="$FT_DIR/lib"
+ test -f $FT_DIR/libttf.a -o -f $FT_DIR/libttf.so -o -f
$FT_DIR/libttf.sl && FT_LIBDIR="$FT_DIR"
+ if test -n "$FT_LIBDIR" ; then
+ FT_TYPE="-lttf"
+ fi
+
+else
test -x "$FT_DIR" -a "freetype-config" = "`basename $FT_DIR ''`" &&
FT_BIN="$FT_DIR"
if test -n "$FT_LIBDIR" ; then
FT_TYPE="-lttf"
fi
fi
fi
+fi
if test -n "$FT_LIBDIR" -a -z "$FT_BIN" ; then
--------------------------------------------------------
Eric L. Blevins www.WiFiMaps.com
--------------------------------------------------------
From morissette at dmsolutions.ca Tue Feb 4 12:26:39 2003
From: morissette at dmsolutions.ca (Daniel Morissette)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Force Freetype1 problem, suggested changeto
configure.in
References:
Message-ID: <3E3FF7CF.A0B619B9@dmsolutions.ca>
Steve Lime wrote:
>
> Can those familiar with autoconf handle this one?
>
I gave this a try yesterday and couldn't understand why this would work
any better. Then looking at the configure script I started to notice
all sorts of potential problems and gave up thinking I needed some
sleep.
Not sure when, but I'll take care of this.
Daniel
> >>> "Eric L. Blevins" 02/02/03 01:52PM >>>
> First I'll say that I am not very familiar with autoconf or even C
> programming.
> I made some changes to the configure.in file that work much better for
> me and thought I would share them.
>
> First I'll explain my particular problem and provide the solution that
> works on my system.
>
> I am using FreeBSD 4.7
> I have both freetype1 and freetype2 installed on my system from the
> freebsd ports.
>
> the --enable-force-freetype1=yes always detects that I have freetype2
> and never sees freetype1
>
> this part of the configure.in does not detect either library hence the
> reason it never finds freetype1 with --enable-force-freetype1
>
> if test "$enable_force_freetype1" = "yes" ; then
> dnl check for freetype1 first
> AC_CHECK_LIB(ttf, TT_Init_FreeType, FT_LIB="-lttf",
> AC_CHECK_LIB(freetype, FT_Init_FreeType, FT_LIB="-lfreetype",,)
> )
> else
> dnl check for freetype2 first
> AC_CHECK_LIB(freetype, FT_Init_FreeType, FT_LIB="-lfreetype",
> AC_CHECK_LIB(ttf, TT_Init_FreeType, FT_LIB="-lttf",,) )
> fi
>
> According to the autoconf documentation I read this should work but it
> does not for some strange reason.
>
> So I did some copying and pasting in the configure.in and came up with
> these changes that do work for me.
> now if I specify --enable-force-freetype1=yes it detects freetype1 if I
> do not specify it it default to detecting freetype2
>
> mapserver compiled fine and renders True Type fonts perfect with these
> changes.
>
> FT_LIB=''
> FT_BIN=''
> FT_TYPE=''
>
> +if test "$enable_force_freetype1" = "yes" ; then
> +test -f $FT_DIR/lib/libttf.a -o -f $FT_DIR/lib/libttf.so -o -f
> $FT_DIR/lib/libttf.sl && FT_LIBDIR="$FT_DIR/lib"
> + test -f $FT_DIR/libttf.a -o -f $FT_DIR/libttf.so -o -f
> $FT_DIR/libttf.sl && FT_LIBDIR="$FT_DIR"
> + if test -n "$FT_LIBDIR" ; then
> + FT_TYPE="-lttf"
> + fi
> +
> +else
> test -x "$FT_DIR" -a "freetype-config" = "`basename $FT_DIR ''`" &&
> FT_BIN="$FT_DIR"
>
> if test -n "$FT_LIBDIR" ; then
> FT_TYPE="-lttf"
> fi
> fi
> fi
> +fi
>
> if test -n "$FT_LIBDIR" -a -z "$FT_BIN" ; then
>
> --------------------------------------------------------
> Eric L. Blevins www.WiFiMaps.com
> --------------------------------------------------------
From jgwinnup at mbvlab.wpafb.af.mil Tue Feb 4 13:20:05 2003
From: jgwinnup at mbvlab.wpafb.af.mil (Jeremy Gwinnup)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Force Freetype1 problem, suggested change
In-Reply-To: <20030204180004.20414.30582.Mailman@lists.gis.umn.edu>
Message-ID:
I saw someone suggesting changes to the configure.in script - Is there any
interest in converting the build script to use both Automake and Autoconf
to build the package on the Unix side? I've made a rudimentary attempt at
it, but it needs work. Let me know if anyone's interested in this.
-Jeremy
Jeremy Gwinnup
Software/Systems Engineer
Veridian Engineering
phone: (937) 904-9023
fax: (937) 656-7425
email: jgwinnup@mbvlab.wpafb.af.mil
From eblevins at insight.rr.com Tue Feb 4 14:07:56 2003
From: eblevins at insight.rr.com (Eric L. Blevins)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Force Freetype1 problem, suggested changeto configure.in
References: <3E3FF7CF.A0B619B9@dmsolutions.ca>
Message-ID: <024c01c2cc80$ba524830$6405a8c0@piii933>
This is a multi-part message in MIME format.
------=_NextPart_000_0249_01C2CC56.D11A7120
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
on freebsd after installing X freetype2 was installed
So I end up with
/usr/local/lib/libfreetype.*
and
/usr/local/include/freetype2/*
I installed freetype1 from the freebsd ports /usr/ports/print/freetype
then I end up with
/usr/local/lib/libttf.*
and
/usr/local/include/freetype1/*
So now my system has both freetype1 and freetype2
but the configure script always detects freetype2 regardless of
using --enable-force-freetype1=yes
this code in the configure script never finds either library
AC_CHECK_LIB(ttf, TT_Init_FreeType, FT_LIB="-lttf",
AC_CHECK_LIB(freetype, FT_Init_FreeType, FT_LIB="-lfreetype",,)
Since the configure script first detects the presence of freetype2
which it finds.
then runs the above code if -enable-force-freetype1=yes
the script never finds freetype1 because the above code does not find
freetype1
This code does detect freetype1:
dnl try freetype 1.x install lib name
test -f $FT_DIR/lib/libttf.a -o -f $FT_DIR/lib/libttf.so -o -f
$FT_DIR/lib/libttf.sl && FT_LIBDIR="$FT_DIR/lib"
test -f $FT_DIR/libttf.a -o -f $FT_DIR/libttf.so -o -f $FT_DIR/libttf.sl
&& FT_LIBDIR="$FT_DIR"
if test -n "$FT_LIBDIR" ; then
FT_TYPE="-lttf"
fi
But the above code never gets ran if freetype2 is installed because it
detects freetype2 then jumps over this code.
If I uninstall freetype2 with no changes to the configure script the above
code does indeed find freetype1
I made a quick diry change that does work and only changes the way things
are detected if -enable-force-freetype1 is used.
I attached the diffs to this e-mail if that will help anyone.
--------------------------------------------------------
Eric L. Blevins www.WiFiMaps.com
--------------------------------------------------------
----- Original Message -----
From: "Daniel Morissette"
To: "Steve Lime"
Cc: ;
Sent: Tuesday, February 04, 2003 12:26 PM
Subject: Re: [Mapserver-dev] Force Freetype1 problem, suggested changeto
configure.in
> Steve Lime wrote:
> >
> > Can those familiar with autoconf handle this one?
> >
>
> I gave this a try yesterday and couldn't understand why this would work
> any better. Then looking at the configure script I started to notice
> all sorts of potential problems and gave up thinking I needed some
> sleep.
>
> Not sure when, but I'll take care of this.
>
> Daniel
>
> > >>> "Eric L. Blevins" 02/02/03 01:52PM >>>
> > First I'll say that I am not very familiar with autoconf or even C
> > programming.
> > I made some changes to the configure.in file that work much better for
> > me and thought I would share them.
> >
> > First I'll explain my particular problem and provide the solution that
> > works on my system.
> >
> > I am using FreeBSD 4.7
> > I have both freetype1 and freetype2 installed on my system from the
> > freebsd ports.
> >
> > the --enable-force-freetype1=yes always detects that I have freetype2
> > and never sees freetype1
> >
> > this part of the configure.in does not detect either library hence the
> > reason it never finds freetype1 with --enable-force-freetype1
> >
> > if test "$enable_force_freetype1" = "yes" ; then
> > dnl check for freetype1 first
> > AC_CHECK_LIB(ttf, TT_Init_FreeType, FT_LIB="-lttf",
> > AC_CHECK_LIB(freetype, FT_Init_FreeType, FT_LIB="-lfreetype",,)
> > )
> > else
> > dnl check for freetype2 first
> > AC_CHECK_LIB(freetype, FT_Init_FreeType, FT_LIB="-lfreetype",
> > AC_CHECK_LIB(ttf, TT_Init_FreeType, FT_LIB="-lttf",,) )
> > fi
> >
> > According to the autoconf documentation I read this should work but it
> > does not for some strange reason.
> >
> > So I did some copying and pasting in the configure.in and came up with
> > these changes that do work for me.
> > now if I specify --enable-force-freetype1=yes it detects freetype1 if I
> > do not specify it it default to detecting freetype2
> >
> > mapserver compiled fine and renders True Type fonts perfect with these
> > changes.
> >
> > FT_LIB=''
> > FT_BIN=''
> > FT_TYPE=''
> >
> > +if test "$enable_force_freetype1" = "yes" ; then
> > +test -f $FT_DIR/lib/libttf.a -o -f $FT_DIR/lib/libttf.so -o -f
> > $FT_DIR/lib/libttf.sl && FT_LIBDIR="$FT_DIR/lib"
> > + test -f $FT_DIR/libttf.a -o -f $FT_DIR/libttf.so -o -f
> > $FT_DIR/libttf.sl && FT_LIBDIR="$FT_DIR"
> > + if test -n "$FT_LIBDIR" ; then
> > + FT_TYPE="-lttf"
> > + fi
> > +
> > +else
> > test -x "$FT_DIR" -a "freetype-config" = "`basename $FT_DIR ''`" &&
> > FT_BIN="$FT_DIR"
> >
> > if test -n "$FT_LIBDIR" ; then
> > FT_TYPE="-lttf"
> > fi
> > fi
> > fi
> > +fi
> >
> > if test -n "$FT_LIBDIR" -a -z "$FT_BIN" ; then
> >
> > --------------------------------------------------------
> > Eric L. Blevins www.WiFiMaps.com
> > --------------------------------------------------------
>
------=_NextPart_000_0249_01C2CC56.D11A7120
Content-Type: text/plain;
name="configure.in.diffs.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="configure.in.diffs.txt"
--- configure.in.orig =20
+++ configure.in=20
***************
*** 238,247 ****
--- 238,255 ----
AC_CHECKING(where FreeType is installed...)
FT_LIB=3D''
FT_BIN=3D''
FT_TYPE=3D''
+ if test "$enable_force_freetype1" =3D "yes" ; then
+ test -f $FT_DIR/lib/libttf.a -o -f $FT_DIR/lib/libttf.so -o -f =
$FT_DIR/lib/libttf.sl && FT_LIBDIR=3D"$FT_DIR/lib"
+ test -f $FT_DIR/libttf.a -o -f $FT_DIR/libttf.so -o -f =
$FT_DIR/libttf.sl && FT_LIBDIR=3D"$FT_DIR"
+ if test -n "$FT_LIBDIR" ; then
+ FT_TYPE=3D"-lttf"
+ fi
+
+ else
test -x "$FT_DIR" -a "freetype-config" =3D "`basename $FT_DIR ''`" && =
FT_BIN=3D"$FT_DIR"
test -x "$FT_DIR/freetype-config" && =
FT_BIN=3D"$FT_DIR/freetype-config"
test -x "$FT_DIR/bin/freetype-config" && =
FT_BIN=3D"$FT_DIR/bin/freetype-config"
if test "$with_freetype" =3D "yes" ; then
***************
*** 270,279 ****
--- 278,288 ----
test -f $FT_DIR/libttf.a -o -f $FT_DIR/libttf.so -o -f =
$FT_DIR/libttf.sl && FT_LIBDIR=3D"$FT_DIR"
if test -n "$FT_LIBDIR" ; then
FT_TYPE=3D"-lttf"
fi
fi
+ fi
fi
if test -n "$FT_LIBDIR" -a -z "$FT_BIN" ; then
FT_LIB=3D"-L$FT_LIBDIR $FT_TYPE"
------=_NextPart_000_0249_01C2CC56.D11A7120--
From morissette at dmsolutions.ca Tue Feb 4 16:36:53 2003
From: morissette at dmsolutions.ca (Daniel Morissette)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Force Freetype1 problem, suggested change
References:
Message-ID: <3E403275.70BEBB6E@dmsolutions.ca>
Jeremy Gwinnup wrote:
>
> I saw someone suggesting changes to the configure.in script - Is there any
> interest in converting the build script to use both Automake and Autoconf
> to build the package on the Unix side? I've made a rudimentary attempt at
> it, but it needs work. Let me know if anyone's interested in this.
>
Can you please describe the benefits that Automake would bring relative
to the current approach which is based purely on Autoconf and Makefile
templates?
BTW I agree that the current configure scripts and Makefiles aren't as
clean as they could be and could use some work (my bad in big part), so
if you know some ways to make them work better in some conditions where
they currently fail then your help would be welcome for sure. I would
also be open to seeing everything being replaced by a new system as long
as you can demonstrate that there is a benefit to making the switch, and
that you are prepared to support the new scripts and Makefiles at least
until they're proven to be as stable as the old ones.
--
------------------------------------------------------------
Daniel Morissette morissette@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
From steve.lime at dnr.state.mn.us Tue Feb 4 23:46:40 2003
From: steve.lime at dnr.state.mn.us (Steve Lime)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] msBuildPath etc...
Message-ID:
Well, I made the switch tonite. Shapepath is not passed as an argument
to msLayerOpen or msSHPOpenFile.
msLayerOpen now uses msBuildPath and msBuildPath3 to create a fully
pathed filename to pass to msSHPOpenFile. I'm hoping that the path
building functions equate NULL and "". This change required touching
many files although the vast majority of edits where trivial. I've
tested with the demo and that went fine. Tiled data raster or vector
have not been tested. Nor have I tested the various cases where
shapepath is unset, or when shapepath is set but the file exists
relative to mappath only.
I think this change makes the API make more sense and removes some of
the 3.4isms when shapefiles were king from the code.
Steve
Stephen Lime
Data & Applications Manager
Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-297-2937
>>> Daniel Morissette 02/03/03 22:40 PM >>>
Steve Lime wrote:
>
> Hi folks: I'd like to ditch passing shapepath around to msOpenLayer
and
> the shapefile routines. What's the best way to use the various
> msBuildPath functions to do that? For the shapefile (and Xbase
> functions) i'd like to simply pass the final file name. The logic (I
> think) would be:
>
> - if DATA or TABLE is full path, then use it
> - if DATA or TABLE relative, and SHAPEPATH is valid then append it
> - if SHAPEPATH relative, then append MAPPATH
>
> If those that wrote those functions would help with their
interpretation
> that would be great.
>
Hi Steve,
FYI msBuildPath() already contains logic to prevent concatenating two
absolute paths. There is also a msBuildPath3() function that takes 3
path components and combines them, so I believe you should be able to do
this:
char path_buffer[MS_MAXPATHLEN];
msBuildPath3(path_buffer, map_path, shape_path, data_filename);
Unless I'm mistaken, this call should do exactly what you proposed
above, i.e.
- if data_filename is an absolute path then map_path and shape_path
are ignored.
- if data_filename is relative then it is appended to shape_path
- if shape_path is absolute then map_path is ignored
- if shape_path is relative then it is appended to map_path.
- finally, if shape_path is null then it should be automatically
ignored and the result will be map_path appended to data_filename.
Oh, and if some error happens then the function returns NULL, otherwise
it will return a reference to path_buffer.
Julien, can you please confirm that this is the expected behavior?
Daniel
--
------------------------------------------------------------
Daniel Morissette morissette@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev@lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
From steve.lime at dnr.state.mn.us Tue Feb 4 23:52:56 2003
From: steve.lime at dnr.state.mn.us (Steve Lime)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] msBuildPath etc...
Message-ID:
Frank: You may want to have a look-see at mapraster.c in
msDrawRasterLayerLow to make sure I didn't screw anything up. I only
touched the tile checking code but see that the path building functions
are used lots of places. Note that the shapefile and dbf opening code
looks in shapepath, and if it doesn't exist there (even if shapepath
exists) in mappath. The raster code does not do that check. Perhaps we
don't want to do it for shapefiles either but that's how it's coded now.
Steve
Stephen Lime
Data & Applications Manager
Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-297-2937
>>> Daniel Morissette 02/03/03 22:40 PM >>>
Steve Lime wrote:
>
> Hi folks: I'd like to ditch passing shapepath around to msOpenLayer
and
> the shapefile routines. What's the best way to use the various
> msBuildPath functions to do that? For the shapefile (and Xbase
> functions) i'd like to simply pass the final file name. The logic (I
> think) would be:
>
> - if DATA or TABLE is full path, then use it
> - if DATA or TABLE relative, and SHAPEPATH is valid then append it
> - if SHAPEPATH relative, then append MAPPATH
>
> If those that wrote those functions would help with their
interpretation
> that would be great.
>
Hi Steve,
FYI msBuildPath() already contains logic to prevent concatenating two
absolute paths. There is also a msBuildPath3() function that takes 3
path components and combines them, so I believe you should be able to do
this:
char path_buffer[MS_MAXPATHLEN];
msBuildPath3(path_buffer, map_path, shape_path, data_filename);
Unless I'm mistaken, this call should do exactly what you proposed
above, i.e.
- if data_filename is an absolute path then map_path and shape_path
are ignored.
- if data_filename is relative then it is appended to shape_path
- if shape_path is absolute then map_path is ignored
- if shape_path is relative then it is appended to map_path.
- finally, if shape_path is null then it should be automatically
ignored and the result will be map_path appended to data_filename.
Oh, and if some error happens then the function returns NULL, otherwise
it will return a reference to path_buffer.
Julien, can you please confirm that this is the expected behavior?
Daniel
--
------------------------------------------------------------
Daniel Morissette morissette@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev@lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
From ed at topozone.com Wed Feb 5 08:49:31 2003
From: ed at topozone.com (Ed McNierney)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] msBuildPath etc...
Message-ID: <13858AA1A74F30419F319ACB66A9D1221F3C7B@mercator.topozone.com>
Steve -
Some of the oddest path behaviors were on Windows systems, especially
with UNC pathnames. 3.7 in general has been working quite nicely; I'll
rebuild today with your new changes and give it a Windows workout.
- Ed
Ed McNierney
President and Chief Mapmaker
TopoZone.com / Maps a la carte, Inc.
73 Princeton Street, Suite 305
North Chelmsford, MA 01863
Phone: (978) 251-4242 Fax: (978) 251-1396
ed@topozone.com
-----Original Message-----
From: Steve Lime [mailto:steve.lime@dnr.state.mn.us]
Sent: Tuesday, February 04, 2003 11:47 PM
To: morissette@dmsolutions.ca; mapserver-dev@lists.gis.umn.edu
Subject: Re: [Mapserver-dev] msBuildPath etc...
Well, I made the switch tonite. Shapepath is not passed as an argument
to msLayerOpen or msSHPOpenFile.
msLayerOpen now uses msBuildPath and msBuildPath3 to create a fully
pathed filename to pass to msSHPOpenFile. I'm hoping that the path
building functions equate NULL and "". This change required touching
many files although the vast majority of edits where trivial. I've
tested with the demo and that went fine. Tiled data raster or vector
have not been tested. Nor have I tested the various cases where
shapepath is unset, or when shapepath is set but the file exists
relative to mappath only.
I think this change makes the API make more sense and removes some of
the 3.4isms when shapefiles were king from the code.
Steve
Stephen Lime
Data & Applications Manager
Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-297-2937
>>> Daniel Morissette 02/03/03 22:40 PM >>>
Steve Lime wrote:
>
> Hi folks: I'd like to ditch passing shapepath around to msOpenLayer
and
> the shapefile routines. What's the best way to use the various
> msBuildPath functions to do that? For the shapefile (and Xbase
> functions) i'd like to simply pass the final file name. The logic (I
> think) would be:
>
> - if DATA or TABLE is full path, then use it
> - if DATA or TABLE relative, and SHAPEPATH is valid then append it
> - if SHAPEPATH relative, then append MAPPATH
>
> If those that wrote those functions would help with their
interpretation
> that would be great.
>
Hi Steve,
FYI msBuildPath() already contains logic to prevent concatenating two
absolute paths. There is also a msBuildPath3() function that takes 3
path components and combines them, so I believe you should be able to do
this:
char path_buffer[MS_MAXPATHLEN];
msBuildPath3(path_buffer, map_path, shape_path, data_filename);
Unless I'm mistaken, this call should do exactly what you proposed
above, i.e.
- if data_filename is an absolute path then map_path and shape_path
are ignored.
- if data_filename is relative then it is appended to shape_path
- if shape_path is absolute then map_path is ignored
- if shape_path is relative then it is appended to map_path.
- finally, if shape_path is null then it should be automatically
ignored and the result will be map_path appended to data_filename.
Oh, and if some error happens then the function returns NULL, otherwise
it will return a reference to path_buffer.
Julien, can you please confirm that this is the expected behavior?
Daniel
--
------------------------------------------------------------
Daniel Morissette morissette@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev@lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev@lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
From jgwinnup at mbvlab.wpafb.af.mil Wed Feb 5 09:23:12 2003
From: jgwinnup at mbvlab.wpafb.af.mil (Jeremy Gwinnup)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Force Freetype1 problem, suggested change
In-Reply-To: <3E403275.70BEBB6E@dmsolutions.ca>
References:
<3E403275.70BEBB6E@dmsolutions.ca>
Message-ID: <1044454991.28558.6.camel@gobbles.mbvlab.wpafb.af.mil>
One thing that you gain from the automake approach is automating/fixing
the install path bug - e.g. files want to be installed in /usr/local
instead of the directory specified in --prefix= .
Another way this may be useful - it allows us to easily build libmap as
a shared library (via automake's libtool support).
The file syntax is very easy. I'll email my working Makefile.am and
configure.in for your perusal. Anyone else interested, please email me
and I'll send them to you.
This isn't perfect (or done) but I think it addresses a couple issues
some people have building the software. The larger question is: Does it
make sense to totally disrupt the current Unix build process.
-Jeremy
On Tue, 2003-02-04 at 16:36, Daniel Morissette wrote:
> Jeremy Gwinnup wrote:
> >
> > I saw someone suggesting changes to the configure.in script - Is there any
> > interest in converting the build script to use both Automake and Autoconf
> > to build the package on the Unix side? I've made a rudimentary attempt at
> > it, but it needs work. Let me know if anyone's interested in this.
> >
>
> Can you please describe the benefits that Automake would bring relative
> to the current approach which is based purely on Autoconf and Makefile
> templates?
>
> BTW I agree that the current configure scripts and Makefiles aren't as
> clean as they could be and could use some work (my bad in big part), so
> if you know some ways to make them work better in some conditions where
> they currently fail then your help would be welcome for sure. I would
> also be open to seeing everything being replaced by a new system as long
> as you can demonstrate that there is a benefit to making the switch, and
> that you are prepared to support the new scripts and Makefiles at least
> until they're proven to be as stable as the old ones.
--
Jeremy Gwinnup
Veridian Engineering
From morissette at dmsolutions.ca Wed Feb 5 11:44:22 2003
From: morissette at dmsolutions.ca (Daniel Morissette)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] [Fwd: auto-build reminder?]
Message-ID: <3E413F66.4E958D61@dmsolutions.ca>
This is a multi-part message in MIME format.
--------------C91C8FAD555B1E66882A2F05
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
In case anyone is able to help... MapServer 3.7 now uses libcurl (a
great piece of software), so by helping the libcurl developers you would
be helping your own cause.
Daniel
--
------------------------------------------------------------
Daniel Morissette morissette@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
--------------C91C8FAD555B1E66882A2F05
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Received: from xcalibur.dmsolutions.ca (www2.dmsolutions.on.ca [209.217.116.146])
by in3.magma.ca (Magma's Mail Server) with ESMTP id h1582jFR027131
for ; Wed, 5 Feb 2003 03:02:45 -0500 (EST)
Received: from sc8-sf-list2.sourceforge.net (lists.sourceforge.net [66.35.250.206])
by xcalibur.dmsolutions.ca (8.11.2/8.11.2) with ESMTP id h1582it24930
for ; Wed, 5 Feb 2003 03:02:45 -0500
Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] helo=sc8-sf-list1.sourceforge.net)
by sc8-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian))
id 18gKVT-0006bx-00; Wed, 05 Feb 2003 00:02:07 -0800
Received: from linux3.contactor.se ([193.15.23.23])
by sc8-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian))
id 18gKUZ-00011D-00; Wed, 05 Feb 2003 00:01:11 -0800
Received: from localhost (dast@localhost)
by linux3.contactor.se (8.11.6/8.11.6) with ESMTP id h1580w303356;
Wed, 5 Feb 2003 09:00:58 +0100
X-Authentication-Warning: linux3.contactor.se: dast owned process doing -bs
From: Daniel Stenberg
X-X-Sender: dast@linux3.contactor.se
To: Curl Mailinglist ,
libcurl Mailing list
Subject: auto-build reminder?
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: curl-library-admin@lists.sourceforge.net
Errors-To: curl-library-admin@lists.sourceforge.net
X-BeenThere: curl-library@lists.sourceforge.net
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: curl-library@lists.sourceforge.net
List-Help:
List-Post:
List-Subscribe: ,
List-Id: libcurl development
List-Unsubscribe: ,
List-Archive:
X-Original-Date: Wed, 5 Feb 2003 09:00:58 +0100 (CET)
Date: Wed, 5 Feb 2003 09:00:58 +0100 (CET)
X-Mozilla-Status2: 00000000
Hi
I'm still very interested in getting people to run automatic tests on recent
curl code on platforms such as:
AIX, IRIX, HP-UX, Tru64, FreeBSD, NetBSD, OpenBSD, non-i386 based Linuxes
If you can help the project by setting up an automatic test (using our
provided script) on such a platform, please get in touch!
See the status of the currently running automatic builds here:
http://curl.haxx.se/auto/
We have Solaris, Linux i386, Linux Sparc and Mac OS X tests running right
now.
--
Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
--------------C91C8FAD555B1E66882A2F05--
From woodbri at swoodbridge.com Wed Feb 5 19:17:37 2003
From: woodbri at swoodbridge.com (woodbri@swoodbridge.com)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] compile problem with mswmslayer.c
Message-ID: <3E416351.7627.190EB72C@localhost>
Hi all,
While building ms 3.7 on Red Hat 8.0 I ran into a strange bug? code
issue in mswmslayer.c I was using a nighty from a couple of days ago.
Anyway, I got "_snprintf" as an undefined. I'm not sure why but the
code was actually calling "_snprintf", I changed that line to call
"snprintf" and added #include at the top to solve the
problem.
I'm not sure what was going on, I haven't had time to grab the latest
to see if it is still in there or was just a temporary issue.
-Steve W.
From morissette at dmsolutions.ca Wed Feb 5 17:12:19 2003
From: morissette at dmsolutions.ca (Daniel Morissette)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Force Freetype1 problem, suggested change
References:
<3E403275.70BEBB6E@dmsolutions.ca> <1044454991.28558.6.camel@gobbles.mbvlab.wpafb.af.mil>
Message-ID: <3E418C43.D2728030@dmsolutions.ca>
Jeremy Gwinnup wrote:
>
> The file syntax is very easy. I'll email my working Makefile.am and
> configure.in for your perusal. Anyone else interested, please email me
> and I'll send them to you.
>
> This isn't perfect (or done) but I think it addresses a couple issues
> some people have building the software. The larger question is: Does it
> make sense to totally disrupt the current Unix build process.
>
Hi Jeremy,
I had a look at the files you sent and this all looks very interesting.
However it looks to me like the configure.in will still be almost as
complex and messy as it used to be. For instance, we'll still have to
resolve the current issues with the Freetype1 vs Freetype2 problems,
etc.
One of the benefits is that the libtool approach should hopefully
resolve some issues we had figuring the linker command to use in
building php_mapscript.so for instance.
Anyway, if you're interested in pursuing this then I agree that it could
be a good idea, as long as you have the time to complete that work (I
don't have time for this now and I'm not sure if other developers do).
I don't think we can replace the old build system until we are sure that
the new one works for all configurations including the MapScripts (at
leat PHP MapScript). We could create a CVS branch just for the config
files (not branch the whole mapserver source tree, just the config
files) to allow you to commit development versions of your scripts and
provide easy access to those who want to test them. Let me know if you
want me to set that up for you.
Also it would be a nice plus to include the SWIG-based MapScripts in
this build system if you can. Perhaps you could get help for this from
the experts in each version of MapScript.
My 0.02$... BTW, I speak for myself only here, and opinions from the
other developers on this would be welcome.
Daniel
--
------------------------------------------------------------
Daniel Morissette morissette@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
From morissette at dmsolutions.ca Thu Feb 6 14:27:36 2003
From: morissette at dmsolutions.ca (Daniel Morissette)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Graticule layer
Message-ID: <3E42B728.A7C574CD@dmsolutions.ca>
Hi,
Back in december there were discussions between Steve and John Novak
about adding a new graticule layer type in MapServer. I see that a
function has been added to the source but it's still empty. Would it be
possible to get an update on the status of this, and how much control is
planned on this functionality. For instance, how much control would we
get on grid spacing? Would it support only lat/lon grids or could the
grid be in any projection?
Thanks
Daniel
--
------------------------------------------------------------
Daniel Morissette morissette@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
From steve.lime at dnr.state.mn.us Thu Feb 6 16:03:46 2003
From: steve.lime at dnr.state.mn.us (Steve Lime)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Graticule layer
Message-ID:
John's the ultimate source for this, but as I understand it the code is almost
complete and John will be handing it off to me for integration. I'll add him as
a CVS writer thereafter. If I recall correctly you get tons of control, and are
not limited to lat/lon grids.
Steve
>>> Daniel Morissette 02/06/03 01:27PM >>>
Hi,
Back in december there were discussions between Steve and John Novak
about adding a new graticule layer type in MapServer. I see that a
function has been added to the source but it's still empty. Would it be
possible to get an update on the status of this, and how much control is
planned on this functionality. For instance, how much control would we
get on grid spacing? Would it support only lat/lon grids or could the
grid be in any projection?
Thanks
Daniel
--
------------------------------------------------------------
Daniel Morissette morissette@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev@lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
From jnovak at novacell.com Fri Feb 7 02:05:09 2003
From: jnovak at novacell.com (Administrator)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Graticule layer
Message-ID: <41CC46B3925E384BA64B1FB5041C38FA49B8@www.novacell.com>
Daniel,
There are parameters that allow user specified grid spacing or automatic
grid scaling. Alternatively, you can specify the number of divisions
and the code will try to get close to that number.
You may also select labeled or unlabeled grid arcs, as well as the
number of subdivisions used to render each arc, a subdivision being a
straight line segment.
You may also specify a projection for the grid, and the units used to
specify spacing are in the coordinate system defined by the projection.
So, anything that PROJ4 supports is available to the user, assuming
PROJ4 support is included in the MapServer build, of course.
Steve,
I'll be bringing the code up to the latest CVS level this weekend and
I'll send it to you when I've tested it. It's been about 6 weeks since
I last merged, so I suspect I'm in for a really amusing time ;-O ...
John Novak
Novacell Technologies
-----Original Message-----
From: Steve Lime [mailto:steve.lime@dnr.state.mn.us]
Sent: Thursday, February 06, 2003 1:04 PM
To: morissette@dmsolutions.ca; mapserver-dev@lists.gis.umn.edu
Subject: Re: [Mapserver-dev] Graticule layer
John's the ultimate source for this, but as I understand it the code is
almost complete and John will be handing it off to me for integration.
I'll add him as a CVS writer thereafter. If I recall correctly you get
tons of control, and are not limited to lat/lon grids.
Steve
>>> Daniel Morissette 02/06/03 01:27PM >>>
Hi,
Back in december there were discussions between Steve and John Novak
about adding a new graticule layer type in MapServer. I see that a
function has been added to the source but it's still empty. Would it be
possible to get an update on the status of this, and how much control is
planned on this functionality. For instance, how much control would we
get on grid spacing? Would it support only lat/lon grids or could the
grid be in any projection?
Thanks
Daniel
--
------------------------------------------------------------
Daniel Morissette morissette@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev@lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev@lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
From sgillies at frii.com Fri Feb 7 13:51:54 2003
From: sgillies at frii.com (Sean Gillies)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Trouble with pointers to strings in mapserver
Message-ID: <39DD31DB-3ACD-11D7-9CC8-000393B98B56@frii.com>
Hi all,
I have adopted (through Bugzilla) the request for a msCopyMap function
and am having problems with the string properties of the objects. I'm
looking for some advice on the proper solution within the context of
the existing mapserver code.
The code I'm testing for msCopyMap starts like this:
int msCopyMap(mapObj *dstMap, mapObj *srcMap) {
...
copyStringProperty(dstMap->name, srcMap->name);
copyProperty(&(dstMap->status), &(srcMap->status), sizeof(int));
...
}
void copyProperty(void *dst, void *src, int size) {
if (src == NULL) dst = NULL;
else memcpy(dst, src, size);
}
void copyStringProperty(char *dst, char *src) {
if (src == NULL) dst = NULL;
else {
if (dst == NULL) dst = strdup(src);
else strcpy(dst, src);
}
}
I am using functions that test for NULL pointers and wrap memcpy
and strcpy. This code is working as I expect. Map names and
numeric properties are copied.
Next, I have started to write a msCopyLayer function which looks
like:
int msCopyLayer(layerObj *dstLayer, layerObj *srcLayer) {
...
copyProperty(&(dstLayer->index), &(srcLayer->index), sizeof(int));
copyProperty(&(dstLayer->map), &(srcLayer->map), sizeof(mapObj *));
copyStringProperty(dstLayer->classitem, srcLayer->classitem);
...
}
and I call this function from msCopyMap like:
int msCopyMap(mapObj *dstMap, mapObj *srcMap) {
...
copyStringProperty(dstMap->name, srcMap->name);
copyProperty(&(dstMap->status), &(srcMap->status), sizeof(int));
copyProperty(&(dstMap->height), &(srcMap->height), sizeof(int));
copyProperty(&(dstMap->width), &(srcMap->width), sizeof(int));
copyProperty(&(dstMap->numlayers), &(srcMap->numlayers), sizeof(int));
for (i = 0; i < dstMap->numlayers; i++) {
initLayer(&(dstMap->layers[i]), dstMap);
msCopyLayer(&(dstMap->layers[i]), &(srcMap->layers[i]));
}
...
}
The problem I experience is that copyStringProperty() isn't working
within msCopyLayer(). I stepped through the code using gdb and
discovered that when copyStringProperty() is called within
msCopyLayer(),
the source string passed to copyStringProperty is being nullified.
For example, in msCopyLayer, before this line
copyStringProperty(dstLayer->classitem, srcLayer->classitem);
is executed, I have srcLayer->classitem = "CO08_D00_". Inside
copyStringProperty, I have src = 0x0.
I'm stumped, and wishing that I was more of a real programmer and less
of a hacker. Why does copyStringProperty() work when called in
msCopyMap(), but not in msCopyLayer()? I have found one solution and
that
is to not call copyStringProperty() from msCopyLayer, but instead copy
its
code explicitly into msCopyLayer. I'd rather not if it wasn't
necessary.
I've looked through the rest of the MapServer code and the only similiar
code I found is in loadLayer() where we have
layer->name = getString()
getString is using the global string msyytext, and returning
return(strdup(msyytext))
but I don't think I should be using a global in msCopyMap.
Grateful for any advice,
Sean
From warmerdam at pobox.com Fri Feb 7 17:01:59 2003
From: warmerdam at pobox.com (Frank Warmerdam)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Re: 3.7 and native image rendering support
In-Reply-To:
References:
Message-ID: <3E442CD7.3010100@pobox.com>
Steve Lime wrote:
> Frank: What would you think about loosing all native raster support in favor
> of OGR? The only obstacle I see is the EPPL7 support but perhaps that could
> be added to OGR. It's a pretty straight forward format I think. I'm just
> thinking that simplifying the configuration options, not to mention the code
> maintenance, is a good idea at this point.
Steve,
I think this makes sense from a maintenance point of view, but I am concerned
that it makes it impossible to built a light version of mapserver with
raster input support.
I am thinking we should move the EPPL7 format into GDAL and then blow away
all format support except for PNG and GIF done using GD (pseudocolored only),
with world files. Furthermore I think we should only use these drivers if
GDAL is not enabled, and we would need to better clarify the limitations
of the non-GDAL drivers.
In particular, I would like to get rid of the existing TIFF driver which
has some significant flaws, and often gets used instead of GDAL.
I have cc:ed this to the developers list to see if anyone else has an
opinion on the importance of a "light" option for MapServer.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
From steve.lime at dnr.state.mn.us Fri Feb 7 17:27:48 2003
From: steve.lime at dnr.state.mn.us (Steve Lime)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Re: 3.7 and native image rendering support
Message-ID:
Currently a lite version requires libtiff anyway, and since you're distributing binaries it
doesn't seem that bad. Building GDAL from source may be a pain though. (Out of
curiosity does the default build support LZW TIFF or would that require a custom
build?)
My vote is for simplification...
Steve
>>> Frank Warmerdam 02/07/03 04:01PM >>>
Steve Lime wrote:
> Frank: What would you think about loosing all native raster support in favor
> of OGR? The only obstacle I see is the EPPL7 support but perhaps that could
> be added to OGR. It's a pretty straight forward format I think. I'm just
> thinking that simplifying the configuration options, not to mention the code
> maintenance, is a good idea at this point.
Steve,
I think this makes sense from a maintenance point of view, but I am concerned
that it makes it impossible to built a light version of mapserver with
raster input support.
I am thinking we should move the EPPL7 format into GDAL and then blow away
all format support except for PNG and GIF done using GD (pseudocolored only),
with world files. Furthermore I think we should only use these drivers if
GDAL is not enabled, and we would need to better clarify the limitations
of the non-GDAL drivers.
In particular, I would like to get rid of the existing TIFF driver which
has some significant flaws, and often gets used instead of GDAL.
I have cc:ed this to the developers list to see if anyone else has an
opinion on the importance of a "light" option for MapServer.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
From sgillies at frii.com Fri Feb 7 17:34:18 2003
From: sgillies at frii.com (Sean Gillies)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Re: 3.7 and native image rendering support
In-Reply-To: <3E442CD7.3010100@pobox.com>
Message-ID: <4B634D8D-3AEC-11D7-A416-000393B98B56@frii.com>
On Friday, February 7, 2003, at 03:01 PM, Frank Warmerdam wrote:
> Steve Lime wrote:
>> Frank: What would you think about loosing all native raster support
>> in favor
>> of OGR? The only obstacle I see is the EPPL7 support but perhaps that
>> could
>> be added to OGR. It's a pretty straight forward format I think. I'm
>> just
>> thinking that simplifying the configuration options, not to mention
>> the code
>> maintenance, is a good idea at this point.
>
> Steve,
>
> I think this makes sense from a maintenance point of view, but I am
> concerned
> that it makes it impossible to built a light version of mapserver with
> raster input support.
>
> I am thinking we should move the EPPL7 format into GDAL and then blow
> away
> all format support except for PNG and GIF done using GD (pseudocolored
> only),
> with world files. Furthermore I think we should only use these
> drivers if
> GDAL is not enabled, and we would need to better clarify the
> limitations
> of the non-GDAL drivers.
>
> In particular, I would like to get rid of the existing TIFF driver
> which
> has some significant flaws, and often gets used instead of GDAL.
>
> I have cc:ed this to the developers list to see if anyone else has an
> opinion on the importance of a "light" option for MapServer.
>
> Best regards,
>
Frank,
I think that the "light" option should also support JPEG through GD
so that users have an option for serving a large volume of compressed
RGB imagery. Am with you on the TIFF driver.
Sean
--
Sean Gillies
sgillies@frii.com
http://www.frii.com/~sgillies
From warmerdam at pobox.com Fri Feb 7 17:40:11 2003
From: warmerdam at pobox.com (Frank Warmerdam)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Re: 3.7 and native image rendering support
In-Reply-To:
References:
Message-ID: <3E4435CB.9020908@pobox.com>
Steve Lime wrote:
> Currently a lite version requires libtiff anyway, and since you're distributing binaries it
> doesn't seem that bad. Building GDAL from source may be a pain though. (Out of
> curiosity does the default build support LZW TIFF or would that require a custom
> build?)
Steve,
Why does a lite version require libtiff? The default build of GDAL's
internal libtiff TIFF driver supports decompressing LZW but not
compressing them.
> My vote is for simplification...
That's an important vote. When would we strip away stuff? Conservatively I
would like to see such a change happen post-3.7 though that puts us in the
ackward position of possible releasing a 3.7 with some buggy drivers.
Also, who would implement this? I guess if we just strip out everything
bug GDAL it wouldn't be a big job.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
From cgn at globexplorer.com Fri Feb 7 17:43:06 2003
From: cgn at globexplorer.com (Chris G. Nicholas)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Re: 3.7 and native image rendering support
Message-ID: <71E37EF6B7DCC1499CEA0316A2568328B62E80@loki.globexplorer.com>
It would be nice to keep the "native" .png support, with perhaps some hook for external synchronization. (use O_EXCL flag on open perhaps?)
For example, we at GlobeXplorer might want to dynamically generate a Mapfile on the fly and create a temporary /tmp/foo1234.png, where a thread would at least open that file with a lock, and fire off the back-end raster rendering in parallel with mapserver's main thread parsing the dynamic mapfile, which would turn around and try to open /tmp/foo1234.png, and hang until it was unlocked, etc.
just a thought...
Chris Nicholas
GlobeXplorer
-----Original Message-----
From: Sean Gillies [mailto:sgillies@frii.com]
Sent: Fri 2/7/2003 2:34 PM
To: Frank Warmerdam
Cc: Steve Lime; Mapserver-dev@lists.gis.umn.edu
Subject: Re: [Mapserver-dev] Re: 3.7 and native image rendering support
On Friday, February 7, 2003, at 03:01 PM, Frank Warmerdam wrote:
> Steve Lime wrote:
>> Frank: What would you think about loosing all native raster support
>> in favor
>> of OGR? The only obstacle I see is the EPPL7 support but perhaps that
>> could
>> be added to OGR. It's a pretty straight forward format I think. I'm
>> just
>> thinking that simplifying the configuration options, not to mention
>> the code
>> maintenance, is a good idea at this point.
>
> Steve,
>
> I think this makes sense from a maintenance point of view, but I am
> concerned
> that it makes it impossible to built a light version of mapserver with
> raster input support.
>
> I am thinking we should move the EPPL7 format into GDAL and then blow
> away
> all format support except for PNG and GIF done using GD (pseudocolored
> only),
> with world files. Furthermore I think we should only use these
> drivers if
> GDAL is not enabled, and we would need to better clarify the
> limitations
> of the non-GDAL drivers.
>
> In particular, I would like to get rid of the existing TIFF driver
> which
> has some significant flaws, and often gets used instead of GDAL.
>
> I have cc:ed this to the developers list to see if anyone else has an
> opinion on the importance of a "light" option for MapServer.
>
> Best regards,
>
Frank,
I think that the "light" option should also support JPEG through GD
so that users have an option for serving a large volume of compressed
RGB imagery. Am with you on the TIFF driver.
Sean
--
Sean Gillies
sgillies@frii.com
http://www.frii.com/~sgillies
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev@lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
From steve.lime at dnr.state.mn.us Fri Feb 7 17:47:46 2003
From: steve.lime at dnr.state.mn.us (Steve Lime)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Re: 3.7 and native image rendering support
Message-ID:
JPEG sucks as a spatial data format though, at least for random access. I'd rather not encourage its use...
>>> Sean Gillies 02/07/03 04:34PM >>>
On Friday, February 7, 2003, at 03:01 PM, Frank Warmerdam wrote:
> Steve Lime wrote:
>> Frank: What would you think about loosing all native raster support
>> in favor
>> of OGR? The only obstacle I see is the EPPL7 support but perhaps that
>> could
>> be added to OGR. It's a pretty straight forward format I think. I'm
>> just
>> thinking that simplifying the configuration options, not to mention
>> the code
>> maintenance, is a good idea at this point.
>
> Steve,
>
> I think this makes sense from a maintenance point of view, but I am
> concerned
> that it makes it impossible to built a light version of mapserver with
> raster input support.
>
> I am thinking we should move the EPPL7 format into GDAL and then blow
> away
> all format support except for PNG and GIF done using GD (pseudocolored
> only),
> with world files. Furthermore I think we should only use these
> drivers if
> GDAL is not enabled, and we would need to better clarify the
> limitations
> of the non-GDAL drivers.
>
> In particular, I would like to get rid of the existing TIFF driver
> which
> has some significant flaws, and often gets used instead of GDAL.
>
> I have cc:ed this to the developers list to see if anyone else has an
> opinion on the importance of a "light" option for MapServer.
>
> Best regards,
>
Frank,
I think that the "light" option should also support JPEG through GD
so that users have an option for serving a large volume of compressed
RGB imagery. Am with you on the TIFF driver.
Sean
--
Sean Gillies
sgillies@frii.com
http://www.frii.com/~sgillies
From steve.lime at dnr.state.mn.us Fri Feb 7 17:54:44 2003
From: steve.lime at dnr.state.mn.us (Steve Lime)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Re: 3.7 and native image rendering support
Message-ID:
The PNG and GIF support are pure fluff in my mind. I can't imagine people use them much.
I've always considered a base version of MapServer to be made up of GD and LibTiff and
perhaps Freetype. That's just my history I guess.
3.7 is not ready, so now's the time. I'm still fixing joins (almost done) but graticule code, oracle
spatial fixes and I imagine other stuff are still being finalized. EPPL7 OGR support would be
crucial for several groups here in MN.
I can ditch the old drivers and screw around with msDrawRasterLayer, as you know I'm not
afraid to dive right in. The 8-bit/24-bit stuff is complicated so this would have to make life
easier...
Steve
>>> Frank Warmerdam 02/07/03 04:40PM >>>
Steve Lime wrote:
> Currently a lite version requires libtiff anyway, and since you're distributing binaries it
> doesn't seem that bad. Building GDAL from source may be a pain though. (Out of
> curiosity does the default build support LZW TIFF or would that require a custom
> build?)
Steve,
Why does a lite version require libtiff? The default build of GDAL's
internal libtiff TIFF driver supports decompressing LZW but not
compressing them.
> My vote is for simplification...
That's an important vote. When would we strip away stuff? Conservatively I
would like to see such a change happen post-3.7 though that puts us in the
ackward position of possible releasing a 3.7 with some buggy drivers.
Also, who would implement this? I guess if we just strip out everything
bug GDAL it wouldn't be a big job.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
From woodbri at swoodbridge.com Fri Feb 7 19:25:58 2003
From: woodbri at swoodbridge.com (woodbri@swoodbridge.com)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Trouble with pointers to strings in mapserver
In-Reply-To: <39DD31DB-3ACD-11D7-9CC8-000393B98B56@frii.com>
Message-ID: <3E440846.24254.4C5DEE3@localhost>
Sean,
based on what you have described, I would recommend a make clean;
make and try it again. When pointers "magically" change from the
outside of a function all to the inside, it indicates that you have
obj files out of sync with one another and or the source. This could
be because you changed a header and did not recompile everything that
referenced it or that you are pulling in an object from a library
that is out of date or the like.
-Steve W.
On 7 Feb 2003 at 11:51, Sean Gillies wrote:
> Hi all,
>
> I have adopted (through Bugzilla) the request for a msCopyMap function
> and am having problems with the string properties of the objects. I'm
> looking for some advice on the proper solution within the context of
> the existing mapserver code.
>
> The code I'm testing for msCopyMap starts like this:
>
>
> int msCopyMap(mapObj *dstMap, mapObj *srcMap) {
> ...
> copyStringProperty(dstMap->name, srcMap->name);
> copyProperty(&(dstMap->status), &(srcMap->status), sizeof(int));
> ...
> }
>
> void copyProperty(void *dst, void *src, int size) {
> if (src == NULL) dst = NULL;
> else memcpy(dst, src, size);
> }
>
> void copyStringProperty(char *dst, char *src) {
> if (src == NULL) dst = NULL;
> else {
> if (dst == NULL) dst = strdup(src);
> else strcpy(dst, src);
> }
> }
>
>
> I am using functions that test for NULL pointers and wrap memcpy
> and strcpy. This code is working as I expect. Map names and
> numeric properties are copied.
>
> Next, I have started to write a msCopyLayer function which looks
> like:
>
>
> int msCopyLayer(layerObj *dstLayer, layerObj *srcLayer) {
> ...
> copyProperty(&(dstLayer->index), &(srcLayer->index), sizeof(int));
> copyProperty(&(dstLayer->map), &(srcLayer->map), sizeof(mapObj *));
> copyStringProperty(dstLayer->classitem, srcLayer->classitem); ...
> }
>
>
> and I call this function from msCopyMap like:
>
>
> int msCopyMap(mapObj *dstMap, mapObj *srcMap) {
> ...
> copyStringProperty(dstMap->name, srcMap->name);
> copyProperty(&(dstMap->status), &(srcMap->status), sizeof(int));
> copyProperty(&(dstMap->height), &(srcMap->height), sizeof(int));
> copyProperty(&(dstMap->width), &(srcMap->width), sizeof(int));
>
> copyProperty(&(dstMap->numlayers), &(srcMap->numlayers),
> sizeof(int));
>
> for (i = 0; i < dstMap->numlayers; i++) {
> initLayer(&(dstMap->layers[i]), dstMap);
> msCopyLayer(&(dstMap->layers[i]), &(srcMap->layers[i]));
> }
> ...
> }
>
>
> The problem I experience is that copyStringProperty() isn't working
> within msCopyLayer(). I stepped through the code using gdb and
> discovered that when copyStringProperty() is called within
> msCopyLayer(), the source string passed to copyStringProperty is being
> nullified.
>
> For example, in msCopyLayer, before this line
>
> copyStringProperty(dstLayer->classitem, srcLayer->classitem);
>
> is executed, I have srcLayer->classitem = "CO08_D00_". Inside
> copyStringProperty, I have src = 0x0.
>
> I'm stumped, and wishing that I was more of a real programmer and less
> of a hacker. Why does copyStringProperty() work when called in
> msCopyMap(), but not in msCopyLayer()? I have found one solution and
> that is to not call copyStringProperty() from msCopyLayer, but instead
> copy its code explicitly into msCopyLayer. I'd rather not if it
> wasn't necessary. I've looked through the rest of the MapServer code
> and the only similiar code I found is in loadLayer() where we have
>
> layer->name = getString()
>
> getString is using the global string msyytext, and returning
>
> return(strdup(msyytext))
>
> but I don't think I should be using a global in msCopyMap.
>
> Grateful for any advice,
> Sean
>
> _______________________________________________
> Mapserver-dev mailing list
> Mapserver-dev@lists.gis.umn.edu
> http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
>
From Norman Sat Feb 8 11:25:40 2003
From: Norman (Norman)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Native Win32 PostgreSQL libPQ
References:
Message-ID: <005b01c2cf8e$b966e870$406cba8c@sfdev3>
Hi all
I have placed an experimental packaging of libpq for Win32 at
http://www.vso.cape.com/~nhv/files/postgres/libpq.lib.tgz
This was built against PostgreSQL 7.3.1
using MingW32 and converted to MS library format
using the Microsoft Lib tool 'lib /machine:i386 /def:libpqdll.def'
The MingW version of the library this was built from works
fine for me and I see no reason why the MSVC version in this
tarball shouldn't allow a MSVC compiled mapserver to query
a PostGIS database.
I am hoping that by announcing this here instead of the users list
we can work out bugs and packaging issues
Cheers
Norman
From morissette at dmsolutions.ca Sat Feb 8 12:01:49 2003
From: morissette at dmsolutions.ca (Daniel Morissette)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] compile problem with mswmslayer.c
References: <3E416351.7627.190EB72C@localhost>
Message-ID: <3E4537FD.9CF43A09@dmsolutions.ca>
woodbri@swoodbridge.com wrote:
>
> While building ms 3.7 on Red Hat 8.0 I ran into a strange bug? code
> issue in mswmslayer.c I was using a nighty from a couple of days ago.
>
> Anyway, I got "_snprintf" as an undefined. I'm not sure why but the
> code was actually calling "_snprintf", I changed that line to call
> "snprintf" and added #include at the top to solve the
> problem.
>
The latest CVS version of mapwmslayer.c uses "snprintf", and Assefa
added the #include a few days ago. What I don't understand is
why you got this "_snprintf" in the code since I don't see it in any of
the recent CVS versions (after a quick check using cvs diff).
Anyway, sounds like this is fixed in CVS now.
Daniel
--
------------------------------------------------------------
Daniel Morissette morissette@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
From woodbri at swoodbridge.com Sat Feb 8 12:06:22 2003
From: woodbri at swoodbridge.com (woodbri@swoodbridge.com)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] nightly build problem with PHP/Mapscript
Message-ID: <3E44F2BE.19366.859C0C5@localhost>
Hi all,
This is probably for Daniel.
The last two nightly builds have two small problems with
PHP/Mapscript. mapscript/php3/mapscript_i.c needs the path argument
removed from the calls to msLayerOpen() and msSHPOpenFile()
-Steve W.
From morissette at dmsolutions.ca Sat Feb 8 14:06:25 2003
From: morissette at dmsolutions.ca (Daniel Morissette)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Native Win32 PostgreSQL libPQ
References: <005b01c2cf8e$b966e870$406cba8c@sfdev3>
Message-ID: <3E455531.E438A5F7@dmsolutions.ca>
Thanks for this Norman, timing is perfect for us as we were still
fighting to get the Cygwin version to work with MapServer! I'll try a
native Win32 build of MapServer using it later today and will keep the
list posted.
Daniel
Norman Vine wrote:
>
> Hi all
>
> I have placed an experimental packaging of libpq for Win32 at
> http://www.vso.cape.com/~nhv/files/postgres/libpq.lib.tgz
>
> This was built against PostgreSQL 7.3.1
> using MingW32 and converted to MS library format
> using the Microsoft Lib tool 'lib /machine:i386 /def:libpqdll.def'
>
> The MingW version of the library this was built from works
> fine for me and I see no reason why the MSVC version in this
> tarball shouldn't allow a MSVC compiled mapserver to query
> a PostGIS database.
>
> I am hoping that by announcing this here instead of the users list
> we can work out bugs and packaging issues
>
> Cheers
>
> Norman
> _______________________________________________
> Mapserver-dev mailing list
> Mapserver-dev@lists.gis.umn.edu
> http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
From sgillies at frii.com Sat Feb 8 15:29:59 2003
From: sgillies at frii.com (Sean Gillies)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Trouble with pointers to strings in mapserver
In-Reply-To: <39DD31DB-3ACD-11D7-9CC8-000393B98B56@frii.com>
Message-ID: <18045F9A-3BA4-11D7-A484-000393B98B56@frii.com>
Fixed it. Thanks for the suggestions.
S.
From morissette at dmsolutions.ca Sat Feb 8 17:29:16 2003
From: morissette at dmsolutions.ca (Daniel Morissette)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Rect in polygon function
Message-ID: <3E4584BC.D08C849@dmsolutions.ca>
Steve, all,
We are looking for a function that would tell us if a rectangle is
comprised completely inside a polygon, is such a function already
available in MapServer or anywhere else? What we're trying to do is
find out if the current map view (a rectangle), is completely contained
inside a polygon that represents available raster coverage. If the map
view is completely contained inside the raster coverage then we want to
use a raster layer as the map, otherwise we want to use vector data. We
want to avoid having both the raster and vector layers showing up in the
same map image, that's why we need this function to test if the current
map view is completely contained inside the polygon defining the raster
layer's coverage.
Thanks in advance for any help/pointers.
Daniel
--
------------------------------------------------------------
Daniel Morissette morissette@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
From woodbri at swoodbridge.com Sat Feb 8 19:59:21 2003
From: woodbri at swoodbridge.com (woodbri@swoodbridge.com)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Rect in polygon function
In-Reply-To: <3E4584BC.D08C849@dmsolutions.ca>
Message-ID: <3E456199.3510.A0AC918@localhost>
While I'm sure there are a bunch of ways to detect this, my first
thought is to do it like this:
1) check if any point is outside the polygon,
if yes done
2) check if any rect edge intersects the polygon boundary,
if yes done (there is a case where a polygon vertex lies on
an edge that you can treat is a none intersection)
3) else it is contained
-Steve W.
On 8 Feb 2003 at 17:29, Daniel Morissette wrote:
> Steve, all,
>
> We are looking for a function that would tell us if a rectangle is
> comprised completely inside a polygon, is such a function already
> available in MapServer or anywhere else? What we're trying to do is
> find out if the current map view (a rectangle), is completely
> contained inside a polygon that represents available raster coverage.
> If the map view is completely contained inside the raster coverage
> then we want to use a raster layer as the map, otherwise we want to
> use vector data. We want to avoid having both the raster and vector
> layers showing up in the same map image, that's why we need this
> function to test if the current map view is completely contained
> inside the polygon defining the raster layer's coverage.
>
> Thanks in advance for any help/pointers.
>
> Daniel
> --
> ------------------------------------------------------------
> Daniel Morissette morissette@dmsolutions.ca
> DM Solutions Group http://www.dmsolutions.ca/
> ------------------------------------------------------------
> _______________________________________________
> Mapserver-dev mailing list
> Mapserver-dev@lists.gis.umn.edu
> http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
>
From ed at topozone.com Sat Feb 8 20:22:18 2003
From: ed at topozone.com (Ed McNierney)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Rect in polygon function
Message-ID: <13858AA1A74F30419F319ACB66A9D1221F3CCF@mercator.topozone.com>
Daniel -
In addition, if you know that the polygon is convex, you can just look
to see if all four corners of the rectangle are inside it.
- Ed
-----Original Message-----
From: woodbri@swoodbridge.com [mailto:woodbri@swoodbridge.com]
Sent: Saturday, February 08, 2003 7:59 PM
To: Stephen Lime; mapserver-dev; Daniel Morissette
Subject: Re: [Mapserver-dev] Rect in polygon function
While I'm sure there are a bunch of ways to detect this, my first
thought is to do it like this:
1) check if any point is outside the polygon,
if yes done
2) check if any rect edge intersects the polygon boundary,
if yes done (there is a case where a polygon vertex lies on
an edge that you can treat is a none intersection)
3) else it is contained
-Steve W.
On 8 Feb 2003 at 17:29, Daniel Morissette wrote:
> Steve, all,
>
> We are looking for a function that would tell us if a rectangle is
> comprised completely inside a polygon, is such a function already
> available in MapServer or anywhere else? What we're trying to do is
> find out if the current map view (a rectangle), is completely
> contained inside a polygon that represents available raster coverage.
> If the map view is completely contained inside the raster coverage
> then we want to use a raster layer as the map, otherwise we want to
> use vector data. We want to avoid having both the raster and vector
> layers showing up in the same map image, that's why we need this
> function to test if the current map view is completely contained
> inside the polygon defining the raster layer's coverage.
>
> Thanks in advance for any help/pointers.
>
> Daniel
> --
> ------------------------------------------------------------
> Daniel Morissette morissette@dmsolutions.ca
> DM Solutions Group http://www.dmsolutions.ca/
> ------------------------------------------------------------
> _______________________________________________
> Mapserver-dev mailing list
> Mapserver-dev@lists.gis.umn.edu
> http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
>
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev@lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
From morissette at dmsolutions.ca Sat Feb 8 20:33:02 2003
From: morissette at dmsolutions.ca (Daniel Morissette)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Native Win32 PostgreSQL libPQ
References: <005b01c2cf8e$b966e870$406cba8c@sfdev3>
Message-ID: <3E45AFCE.F096B7A1@dmsolutions.ca>
Norman Vine wrote:
>
> Hi all
>
> I have placed an experimental packaging of libpq for Win32 at
> http://www.vso.cape.com/~nhv/files/postgres/libpq.lib.tgz
>
Woohoo! It works!!!!! Thanks a lot for this package. I have a
MapServer 3.6.4 mapserv.exe compiled using your libpq package that is
able to render PostGIS data. I haven't done much testing, but it works
great with the few layers I have in my mapfile.
The mapserver support libs on my Windows system are a bit outdated so I
won't distribute the executables that I have compiled, but I'll pass all
my config info to Assefa and finally we'll be able to produce Native
Win32 builds of MapServer and PHP MapScript with PostGIS support!
Beer time! :D
Daniel
--
------------------------------------------------------------
Daniel Morissette morissette@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
From woodbri at swoodbridge.com Sat Feb 8 22:06:57 2003
From: woodbri at swoodbridge.com (woodbri@swoodbridge.com)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Rect in polygon function
In-Reply-To: <3E456199.3510.A0AC918@localhost>
References: <3E4584BC.D08C849@dmsolutions.ca>
Message-ID: <3E457F81.25423.A7F9B67@localhost>
In addition step 2) can be done very fast using clipLine algorithm
with the rectangle as the clipping box. I should think the mapserver
already has this code somewhere. If you cycle through each line
segment of the polygon and if any are inside the box or are clipped
by the box then stop with a failure, if all are rejected as outside
the box then you have containment.
If you need code for the clipLine algorithm, I have some that could
easily be adapted.
-Steve W.
On 8 Feb 2003 at 19:59, woodbri@swoodbridge.com wrote:
> While I'm sure there are a bunch of ways to detect this, my first
> thought is to do it like this:
>
> 1) check if any point is outside the polygon,
> if yes done
> 2) check if any rect edge intersects the polygon boundary,
> if yes done (there is a case where a polygon vertex lies on
> an edge that you can treat is a none intersection)
> 3) else it is contained
>
> -Steve W.
>
> On 8 Feb 2003 at 17:29, Daniel Morissette wrote:
>
> > Steve, all,
> >
> > We are looking for a function that would tell us if a rectangle is
> > comprised completely inside a polygon, is such a function already
> > available in MapServer or anywhere else? What we're trying to do is
> > find out if the current map view (a rectangle), is completely
> > contained inside a polygon that represents available raster
> > coverage. If the map view is completely contained inside the raster
> > coverage then we want to use a raster layer as the map, otherwise we
> > want to use vector data. We want to avoid having both the raster
> > and vector layers showing up in the same map image, that's why we
> > need this function to test if the current map view is completely
> > contained inside the polygon defining the raster layer's coverage.
> >
> > Thanks in advance for any help/pointers.
> >
> > Daniel
> > --
> > ------------------------------------------------------------
> > Daniel Morissette morissette@dmsolutions.ca
> > DM Solutions Group http://www.dmsolutions.ca/
> > ------------------------------------------------------------
> > _______________________________________________
> > Mapserver-dev mailing list
> > Mapserver-dev@lists.gis.umn.edu
> > http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
> >
>
>
> _______________________________________________
> Mapserver-dev mailing list
> Mapserver-dev@lists.gis.umn.edu
> http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
>
From woodbri at swoodbridge.com Sun Feb 9 11:56:59 2003
From: woodbri at swoodbridge.com (woodbri@swoodbridge.com)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Labels that follow streets with bends
Message-ID: <3E46420B.23054.D77887B@localhost>
Hi all,
There has been some some discussion of have street labels follow
bends in the streets in the past. I have decided to take a pass at
implementing a routine to do this.
Here are my initial thoughts on this. I am looking for comments and
feedback.
My plan is to implement a function like this:
bchar *TextPath(
gdImagePtr im,
int *brect,
int fg,
char *fontname,
double ptsize,
int npts,
int *X,
int *Y,
char *string,
int flags);
most of these args are identical to the gdImageStingFT() call and
this function would work similarly to it if you pass it NULL for im.
The polyline would be passed in using the npts, X, Y args; and flags
I envision would be used to control the behavior of the function with
respect to
NO_PARTIAL - fail is polyline is too short to render the whole
string
TRUNCATE - trucate the string if it is too long
EXTEND - virtually extend the last segment to write the whole string
REVERSE - the direction of the polyline
AUTO - figure out the best placement of the text so it is most
readable
ABOVE|BELOW|CENTER the text on the polyline
My first pass at this will be straight forward if not brute force. I
will take each char in the string and see if I have enough room to
place it on the segment, if not place it on the next segment until I
run out of chars or segments. I will also probably ignore most of the
flags and implement it as flags = EXTEND|AUTO; I plan to write the
function to just call gdImageStringFTEx() to do the work, a later
optimization might be to clone the gdImageStringFTEx() source so I
can make some optimization.
This implementation has the advantage for me that I can dev and test
in a simplified GD only environment. On the down side real
performance will not be as easily tested until it is integrated into
mapserver.
If I implement as described above will it be easy to integrate into
mapserver? Issues? concerns?
-Steve W.
From jnovak at novacell.com Sun Feb 9 21:45:26 2003
From: jnovak at novacell.com (Administrator)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Graticule layer status update
Message-ID: <41CC46B3925E384BA64B1FB5041C38FA32EA@www.novacell.com>
Folks,
I've just passed a set of source files to Mr. Lime that implement the
Graticule functionality. They are current with the 3.7 CVS repository
as of about 10 minutes ago. I'm sure they'll be some bugs to flatten,
but hopefully we'll have bug free operation shortly.
Regards,
John Novak
Novacell Technologies
-----Original Message-----
From: Steve Lime [mailto:steve.lime@dnr.state.mn.us]
Sent: Thursday, February 06, 2003 1:04 PM
To: morissette@dmsolutions.ca; mapserver-dev@lists.gis.umn.edu
Subject: Re: [Mapserver-dev] Graticule layer
John's the ultimate source for this, but as I understand it the code is
almost complete and John will be handing it off to me for integration.
I'll add him as a CVS writer thereafter. If I recall correctly you get
tons of control, and are not limited to lat/lon grids.
Steve
>>> Daniel Morissette 02/06/03 01:27PM >>>
Hi,
Back in december there were discussions between Steve and John Novak
about adding a new graticule layer type in MapServer. I see that a
function has been added to the source but it's still empty. Would it be
possible to get an update on the status of this, and how much control is
planned on this functionality. For instance, how much control would we
get on grid spacing? Would it support only lat/lon grids or could the
grid be in any projection?
Thanks
Daniel
--
------------------------------------------------------------
Daniel Morissette morissette@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev@lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev@lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
From attila at prometheus.org.yu Mon Feb 10 08:47:17 2003
From: attila at prometheus.org.yu (Attila Csipa)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] WKB geometry in mappostgis.c
In-Reply-To: <3E46420B.23054.D77887B@localhost>
References: <3E46420B.23054.D77887B@localhost>
Message-ID: <200302101248.h1ACmka05796@tina2.tippnet.co.yu>
I'm looking at the mappostgis.c code and trying to implement WKB geometry for
the mysql module, but there are some interesting things. For one, the WKB as
used is NOT compliant to the WKB spec, as given in the SFSQL RFC. Since
postgis WKB seems to be working the question is if there are multiple
versions of WKB specifications floating around or am I just missing something
?
In the code below it is clearly visible that the type of WKB geoms is stored
for each geometry, and the first is located on byte 10 of the WKB. According
to SFSQL specs, this is not so - the type is defined only once, on byte 2
(except for special WKB types, line is not one of them). This is for
starters, there are other differences, too.
int force_to_lines(char *wkb, shapeObj *shape)
{
int offset =0;
int ngeoms, t ;
int type,nrings,npoints;
shape->type = MS_SHAPE_NULL; //nothing in it
memcpy( &ngeoms, &wkb[5], 4);
offset = 9; //were the first geometry is
for (t=0; t
References: <3E46420B.23054.D77887B@localhost> <200302101248.h1ACmka05796@tina2.tippnet.co.yu>
Message-ID: <200302101325.h1ADPBa12466@tina2.tippnet.co.yu>
On Monday 10 February 2003 14:47, Attila Csipa wrote:
> I'm looking at the mappostgis.c code and trying to implement WKB geometry
> for the mysql module, but there are some interesting things. For one, the
> WKB as used is NOT compliant to the WKB spec, as given in the SFSQL RFC.
Follow-up: it seems that it is implementing only the WKB geometry collection,
but has no separate processing for other WKB geometries. Am I right ? And the
question is - is this because of a feature of postgis (say, always returning
collections from queries), or something else ?
From pramsey at refractions.net Mon Feb 10 11:17:54 2003
From: pramsey at refractions.net (Paul Ramsey)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] WKB geometry in mappostgis.c
In-Reply-To: <200302101325.h1ADPBa12466@tina2.tippnet.co.yu>
References: <3E46420B.23054.D77887B@localhost>
<200302101248.h1ACmka05796@tina2.tippnet.co.yu>
<200302101325.h1ADPBa12466@tina2.tippnet.co.yu>
Message-ID: <3E47D0B2.3080109@refractions.net>
You might find the WKB processing example included in the postgis source
easier to read. It is under 'examples'.
Attila Csipa wrote:
> On Monday 10 February 2003 14:47, Attila Csipa wrote:
>
>>I'm looking at the mappostgis.c code and trying to implement WKB geometry
>>for the mysql module, but there are some interesting things. For one, the
>>WKB as used is NOT compliant to the WKB spec, as given in the SFSQL RFC.
>
>
> Follow-up: it seems that it is implementing only the WKB geometry collection,
> but has no separate processing for other WKB geometries. Am I right ? And the
> question is - is this because of a feature of postgis (say, always returning
> collections from queries), or something else ?
>
> _______________________________________________
> Mapserver-dev mailing list
> Mapserver-dev@lists.gis.umn.edu
> http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
--
__
/
| Paul Ramsey
| Refractions Research
| Email: pramsey@refractions.net
| Phone: (250) 885-0632
\_
From steve.lime at dnr.state.mn.us Mon Feb 10 12:47:02 2003
From: steve.lime at dnr.state.mn.us (Steve Lime)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Re: Rect in polygon function
Message-ID:
That specific function doesn't exists, but all the pieces do. It should
be easy, just 2 steps:
1) test each rectangle vertex with a point in polygon check
2) test each rectangle segment for intersection against all polygon segments
If a rectangle passes all those then it's completely inside the polygon. The point in
polygon and segment intersection functions have already been written and are
in mapsearch.c. There are also several functions in that same source file that
demonstrate looping through a shape's line segments.
Steve
>>> Daniel Morissette 02/08/03 04:29PM >>>
Steve, all,
We are looking for a function that would tell us if a rectangle is
comprised completely inside a polygon, is such a function already
available in MapServer or anywhere else? What we're trying to do is
find out if the current map view (a rectangle), is completely contained
inside a polygon that represents available raster coverage. If the map
view is completely contained inside the raster coverage then we want to
use a raster layer as the map, otherwise we want to use vector data. We
want to avoid having both the raster and vector layers showing up in the
same map image, that's why we need this function to test if the current
map view is completely contained inside the polygon defining the raster
layer's coverage.
Thanks in advance for any help/pointers.
Daniel
--
------------------------------------------------------------
Daniel Morissette morissette@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
From dblasby at refractions.net Mon Feb 10 13:11:26 2003
From: dblasby at refractions.net (David Blasby)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] WKB geometry in mappostgis.c
References: <3E46420B.23054.D77887B@localhost> <200302101248.h1ACmka05796@tina2.tippnet.co.yu>
Message-ID: <3E47EB4D.E768F169@refractions.net>
If you read the query portion, you'll see that the query that gets sent to
PostGIS looks like:
SELECT asbinary(force_collection(force_2d(the_geom)),'NDR'), .... FROM ...
This:
+ forces the geometry to a 2d representation (mapserver doesn't handle 3d
points,
the WKB for 3d geometries isn't well defined, and its a waste of
transferring data)
+ converts the geometry to geometry collection - this makes the WKB parser
much
easier - you dont have to have a MULTIPOINT, MULTILINESTRING, or
MULTIPOLYGON parser. Just a collection and point, linestring, and polygon
parser.
+ the as_binary converts the PostGIS geometry into WKB.
This means the transfer from postgresql to mapserver is [usually] efficient and
the parser can be very
simple. The parser also does some type conversion because mapserver requires
homogenous data
types (ie. all points, or all lines), while postgis can be heterogeneous.
dave
ps. there is a WKB parser in postgis_debug.c, but its extremely ugly!
From john_mapserver at hotmail.com Mon Feb 10 16:25:09 2003
From: john_mapserver at hotmail.com (John Newton)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Labels that follow streets with bends
References: <3E46420B.23054.D77887B@localhost>
Message-ID:
----- Original Message -----
From:
To: "mapserver-dev"
Sent: Sunday, February 09, 2003 8:56 AM
Subject: [Mapserver-dev] Labels that follow streets with bends
> Hi all,
>
> There has been some some discussion of have street labels follow
> bends in the streets in the past. I have decided to take a pass at
> implementing a routine to do this.
>
> Here are my initial thoughts on this. I am looking for comments and
> feedback.
>
> My plan is to implement a function like this:
>
> bchar *TextPath(
> gdImagePtr im,
> int *brect,
> int fg,
> char *fontname,
> double ptsize,
> int npts,
> int *X,
> int *Y,
> char *string,
> int flags);
>
> most of these args are identical to the gdImageStingFT() call and
> this function would work similarly to it if you pass it NULL for im.
> The polyline would be passed in using the npts, X, Y args; and flags
> I envision would be used to control the behavior of the function with
> respect to
> NO_PARTIAL - fail is polyline is too short to render the whole
> string
> TRUNCATE - trucate the string if it is too long
> EXTEND - virtually extend the last segment to write the whole string
> REVERSE - the direction of the polyline
> AUTO - figure out the best placement of the text so it is most
> readable
> ABOVE|BELOW|CENTER the text on the polyline
>
> My first pass at this will be straight forward if not brute force. I
> will take each char in the string and see if I have enough room to
> place it on the segment, if not place it on the next segment until I
> run out of chars or segments. I will also probably ignore most of the
> flags and implement it as flags = EXTEND|AUTO; I plan to write the
> function to just call gdImageStringFTEx() to do the work, a later
> optimization might be to clone the gdImageStringFTEx() source so I
> can make some optimization.
>
> This implementation has the advantage for me that I can dev and test
> in a simplified GD only environment. On the down side real
> performance will not be as easily tested until it is integrated into
> mapserver.
>
> If I implement as described above will it be easy to integrate into
> mapserver? Issues? concerns?
>
> -Steve W.
>
>
> _______________________________________________
> Mapserver-dev mailing list
> Mapserver-dev@lists.gis.umn.edu
> http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
>
From steve.lime at dnr.state.mn.us Mon Feb 10 17:50:36 2003
From: steve.lime at dnr.state.mn.us (Steve Lime)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Labels that follow streets with bends
Message-ID:
Lemme think. On the MapServer side there are a couple of issues. How to integrate the support into the map file and into the source itself.
For the mapfile it's probably as simple as adding a FLOW option to the POSITION parameter. Might need a couple of new options in the LABEL object if more control is desired but at first glance I would think that old parameters like MINFEATURESIZE can cover what we need. Could need a FLOW TRUE/FALSE option depending on how much POSITION is necessary.
In terms of the source the issues are larger. The current code generates a label point and you'd actually need the path (i.e. shapeObj) to operate on. I don't worry about non-cached labels since they could simply access a wrapper to the gd function anyway. We'd need to extend the labelCacheMemberObj to hold that path. Assuming we can store the path then the label cache operation is the part. The cache operates based on the outlines (bounding boxes) of labels and their associated markers (ANNOTATION layers). The current GD code coughs up the metrics and when combined with the position information gives us enough to do collision avoidance. In your case we need more. You can't use a single bounding rect for flowing text. It will over estimate the amount of space necessary. Instead you'd want a bounding rect for each character. The collision avoidance code is already setup for labels with multiple bounding polygons. It's hard, because with strings the size of the label with or without rotation is the same. So MapServer actually takes metrics from unrotated labels and then rotates them internally so that bounding polygons are tight to the label. With this application rotation is everything and the size of the label is not consistent with or without flowing. Your function is going to have to produce more detailed information it gives back. Even bounding rects for each rotated character would be workable (i.e. turn int *brect into int **brect). You first have to produce a placement without drawing and then evaluate that placement against the cache. That will be more expensive in this case.
Does this help/make sense?
Steve
>>> 02/09/03 10:56AM >>>
Hi all,
There has been some some discussion of have street labels follow
bends in the streets in the past. I have decided to take a pass at
implementing a routine to do this.
Here are my initial thoughts on this. I am looking for comments and
feedback.
My plan is to implement a function like this:
bchar *TextPath(
gdImagePtr im,
int *brect,
int fg,
char *fontname,
double ptsize,
int npts,
int *X,
int *Y,
char *string,
int flags);
most of these args are identical to the gdImageStingFT() call and
this function would work similarly to it if you pass it NULL for im.
The polyline would be passed in using the npts, X, Y args; and flags
I envision would be used to control the behavior of the function with
respect to
NO_PARTIAL - fail is polyline is too short to render the whole
string
TRUNCATE - trucate the string if it is too long
EXTEND - virtually extend the last segment to write the whole string
REVERSE - the direction of the polyline
AUTO - figure out the best placement of the text so it is most
readable
ABOVE|BELOW|CENTER the text on the polyline
My first pass at this will be straight forward if not brute force. I
will take each char in the string and see if I have enough room to
place it on the segment, if not place it on the next segment until I
run out of chars or segments. I will also probably ignore most of the
flags and implement it as flags = EXTEND|AUTO; I plan to write the
function to just call gdImageStringFTEx() to do the work, a later
optimization might be to clone the gdImageStringFTEx() source so I
can make some optimization.
This implementation has the advantage for me that I can dev and test
in a simplified GD only environment. On the down side real
performance will not be as easily tested until it is integrated into
mapserver.
If I implement as described above will it be easy to integrate into
mapserver? Issues? concerns?
-Steve W.
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev@lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
From woodbri at swoodbridge.com Mon Feb 10 22:26:28 2003
From: woodbri at swoodbridge.com (woodbri@swoodbridge.com)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Labels that follow streets with bends
In-Reply-To:
Message-ID: <3E482714.26873.14DD4442@localhost>
On 10 Feb 2003 at 16:50, Steve Lime wrote:
> So MapServer actually takes metrics from unrotated labels and then
> rotates them internally so that bounding polygons are tight to the
> label.
How do you do that? Store x,y,h,w,ang instead of the *brect
> Your function is
> going to have to produce more detailed information it gives back. Even
> bounding rects for each rotated character would be workable (i.e. turn
> int *brect into int **brect).
OK, this is no problem. Do we want to assume there are strlen(string)
entries in **brect, alternatively the array *brect could be
terminated with a null pointer which would make freeing it
independent of remembering strlen(string). I am prefer the later, but
what makes the most sense for mapserver?
> You first have to produce a placement
> without drawing and then evaluate that placement against the cache.
Yup, this was my plan, you pass in NULL for the image pointer and I
don't do the drawing only return **brect
On memory allocation, I assume I should alloc the memory and return a
pointer to in brect.
> That will be more expensive in this case.
Yup, that is why I'm thinking about a phase two redesign, but figure
it is best to get it working before trying to optimize it.
> Does this help/make sense?
Yes. See questions above.
-Steve W.
>
> Steve
>
> >>> 02/09/03 10:56AM >>>
> Hi all,
>
> There has been some some discussion of have street labels follow bends
> in the streets in the past. I have decided to take a pass at
> implementing a routine to do this.
>
> Here are my initial thoughts on this. I am looking for comments and
> feedback.
>
> My plan is to implement a function like this:
>
> bchar *TextPath(
> gdImagePtr im,
> int *brect,
> int fg,
> char *fontname,
> double ptsize,
> int npts,
> int *X,
> int *Y,
> char *string,
> int flags);
>
> most of these args are identical to the gdImageStingFT() call and this
> function would work similarly to it if you pass it NULL for im. The
> polyline would be passed in using the npts, X, Y args; and flags I
> envision would be used to control the behavior of the function with
> respect to NO_PARTIAL - fail is polyline is too short to render the
> whole string TRUNCATE - trucate the string if it is too long EXTEND -
> virtually extend the last segment to write the whole string REVERSE -
> the direction of the polyline AUTO - figure out the best placement of
> the text so it is most readable ABOVE|BELOW|CENTER the text on the
> polyline
>
> My first pass at this will be straight forward if not brute force. I
> will take each char in the string and see if I have enough room to
> place it on the segment, if not place it on the next segment until I
> run out of chars or segments. I will also probably ignore most of the
> flags and implement it as flags = EXTEND|AUTO; I plan to write the
> function to just call gdImageStringFTEx() to do the work, a later
> optimization might be to clone the gdImageStringFTEx() source so I can
> make some optimization.
>
> This implementation has the advantage for me that I can dev and test
> in a simplified GD only environment. On the down side real performance
> will not be as easily tested until it is integrated into mapserver.
>
> If I implement as described above will it be easy to integrate into
> mapserver? Issues? concerns?
>
> -Steve W.
>
>
> _______________________________________________
> Mapserver-dev mailing list
> Mapserver-dev@lists.gis.umn.edu
> http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
>
> _______________________________________________
> Mapserver-dev mailing list
> Mapserver-dev@lists.gis.umn.edu
> http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
>
From jnovak at novacell.com Tue Feb 11 02:49:03 2003
From: jnovak at novacell.com (Administrator)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Re: 3.7 and native image rendering support
Message-ID: <41CC46B3925E384BA64B1FB5041C38FA49BB@www.novacell.com>
This is a bit late, but...
I've been using nothing but PNG files as output, and I have local
changes that allow me to render layers with alpha blends.
What is the alternative to PNG output files if this support is
deprecated ?
IMHO, this seems like a rather large change to start at this late date
in the 3.7 development cycle, as it's core functionality.
John Novak
-----Original Message-----
From: Steve Lime [mailto:steve.lime@dnr.state.mn.us]
Sent: Friday, February 07, 2003 2:55 PM
To: warmerdam@pobox.com
Cc: Mapserver-dev@lists.gis.umn.edu
Subject: Re: [Mapserver-dev] Re: 3.7 and native image rendering support
The PNG and GIF support are pure fluff in my mind. I can't imagine
people use them much.
I've always considered a base version of MapServer to be made up of GD
and LibTiff and perhaps Freetype. That's just my history I guess.
3.7 is not ready, so now's the time. I'm still fixing joins (almost
done) but graticule code, oracle spatial fixes and I imagine other stuff
are still being finalized. EPPL7 OGR support would be crucial for
several groups here in MN.
I can ditch the old drivers and screw around with msDrawRasterLayer, as
you know I'm not
afraid to dive right in. The 8-bit/24-bit stuff is complicated so this
would have to make life easier...
Steve
>>> Frank Warmerdam 02/07/03 04:40PM >>>
Steve Lime wrote:
> Currently a lite version requires libtiff anyway, and since you're
> distributing binaries it doesn't seem that bad. Building GDAL from
> source may be a pain though. (Out of curiosity does the default build
> support LZW TIFF or would that require a custom
> build?)
Steve,
Why does a lite version require libtiff? The default build of GDAL's
internal libtiff TIFF driver supports decompressing LZW but not
compressing them.
> My vote is for simplification...
That's an important vote. When would we strip away stuff?
Conservatively I would like to see such a change happen post-3.7 though
that puts us in the ackward position of possible releasing a 3.7 with
some buggy drivers.
Also, who would implement this? I guess if we just strip out everything
bug GDAL it wouldn't be a big job.
Best regards,
--
---------------------------------------+--------------------------------
---------------------------------------+------
I set the clouds in motion - turn up | Frank Warmerdam,
warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev@lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
From steve.lime at dnr.state.mn.us Tue Feb 11 11:15:22 2003
From: steve.lime at dnr.state.mn.us (Steve Lime)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Re: 3.7 and native image rendering support
Message-ID:
John: What I'm proposing is not a modification of output formats, but in how raster input formats
are handled. At the moment there are several legacy raster drivers that, with the exception of one,
are handled by OGR. I propose retiring those drivers in favor of pure OGR raster support. The
exception would/could be GIF/PNG input, yup input, with world files via GD. The changes are
relatively minor- removing code rather then adding anything.
Steve
Stephen Lime
Data & Applications Manager
Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-297-2937
>>> "Administrator" 02/11/03 01:49AM >>>
This is a bit late, but...
I've been using nothing but PNG files as output, and I have local
changes that allow me to render layers with alpha blends.
What is the alternative to PNG output files if this support is
deprecated ?
IMHO, this seems like a rather large change to start at this late date
in the 3.7 development cycle, as it's core functionality.
John Novak
-----Original Message-----
From: Steve Lime [mailto:steve.lime@dnr.state.mn.us]
Sent: Friday, February 07, 2003 2:55 PM
To: warmerdam@pobox.com
Cc: Mapserver-dev@lists.gis.umn.edu
Subject: Re: [Mapserver-dev] Re: 3.7 and native image rendering support
The PNG and GIF support are pure fluff in my mind. I can't imagine
people use them much.
I've always considered a base version of MapServer to be made up of GD
and LibTiff and perhaps Freetype. That's just my history I guess.
3.7 is not ready, so now's the time. I'm still fixing joins (almost
done) but graticule code, oracle spatial fixes and I imagine other stuff
are still being finalized. EPPL7 OGR support would be crucial for
several groups here in MN.
I can ditch the old drivers and screw around with msDrawRasterLayer, as
you know I'm not
afraid to dive right in. The 8-bit/24-bit stuff is complicated so this
would have to make life easier...
Steve
>>> Frank Warmerdam 02/07/03 04:40PM >>>
Steve Lime wrote:
> Currently a lite version requires libtiff anyway, and since you're
> distributing binaries it doesn't seem that bad. Building GDAL from
> source may be a pain though. (Out of curiosity does the default build
> support LZW TIFF or would that require a custom
> build?)
Steve,
Why does a lite version require libtiff? The default build of GDAL's
internal libtiff TIFF driver supports decompressing LZW but not
compressing them.
> My vote is for simplification...
That's an important vote. When would we strip away stuff?
Conservatively I would like to see such a change happen post-3.7 though
that puts us in the ackward position of possible releasing a 3.7 with
some buggy drivers.
Also, who would implement this? I guess if we just strip out everything
bug GDAL it wouldn't be a big job.
Best regards,
--
---------------------------------------+--------------------------------
---------------------------------------+------
I set the clouds in motion - turn up | Frank Warmerdam,
warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev@lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev@lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
From attila at prometheus.org.yu Wed Feb 12 05:11:24 2003
From: attila at prometheus.org.yu (Attila Csipa)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Fwd: Re: MapServer MySQL interface
In-Reply-To: <3E357F73.2010908@pobox.com>
References: <3E357F73.2010908@pobox.com>
Message-ID: <200302120913.h1C9DEa29969@tina2.tippnet.co.yu>
On Monday 27 January 2003 19:50, you wrote:
> appreciate knowing when you have setup a web page or mailing list for
> your efforts. As practical I would be interested in making my OGR tools
> compatible with such an implemention.
I have a working prototype which handles (at the moment) only a subset of
SFSQL spec, but all the major things are in. You can check out a demo version
(about 40 layers with near 100.000 features) at
http://gis.manufacture.co.yu/sfsql/index_xml_debug.m if you like (omit
_debug if you do not want the queries to be displayed). It's not a speed
champion (never really ment to be), I wanted to have something that works
first and optimize later. If you need any details about the implementation,
just say it. The 2 limitations - it handles only wkb_collection type in
binary storage (mappostgis.c heritage) and tables with 2 coordinates when
using numerical storage (works with polygons, longer lines, etc, it's just
that there must be 2 points / SEQ).
From assefa at dmsolutions.ca Fri Feb 14 09:27:00 2003
From: assefa at dmsolutions.ca (Yewondwossen Assefa)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Add shape id's in the selection
Message-ID: <3E4CFCB3.97B8B92C@dmsolutions.ca>
Hi There,
I was looking into how to keep selected elements between page submits.
What I want is to be able to show the selections (using draw query)
after a page has submitted without doing each time a query. In some
applications, peopole want to do a query and do some panning, zooming
without their query being lost.
I was thinking of adding a couple of utility functions to add shpes
id's to a resultcached used during the query. It will be less costly in
time to use these functions instead of redoing the query every time.
Do You think It is a useful ? Any comments/objections ?
Later,
--
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst
Email: assefa@dmsolutions.ca
http://www.dmsolutions.ca/
Phone: (613) 565-5056 (ext 14)
Fax: (613) 565-0925
----------------------------------------------------------------
From cgn at globexplorer.com Fri Feb 14 10:18:16 2003
From: cgn at globexplorer.com (Chris G. Nicholas)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Add shape id's in the selection
Message-ID: <71E37EF6B7DCC1499CEA0316A2568328B62ECA@loki.globexplorer.com>
keep in mind that folks like us (GlobeXplorer) generally have a bank of machines front-ending traffic, being fed by a load balancer (such as: http://www.f5.com/f5products/bigip/)
therefore, don't assume that one click to the next hits the same machine...one would want to use an extensible session object something extensible that might have a default implementation in a RAM, but can definitely use a centralized db or nfs area...
Chris Nicholas
GlobeXplorer
-----Original Message-----
From: Yewondwossen Assefa [mailto:assefa@dmsolutions.ca]
Sent: Fri 2/14/2003 6:27 AM
To: Steve Lime
Cc: mapserver-dev
Subject: [Mapserver-dev] Add shape id's in the selection
Hi There,
I was looking into how to keep selected elements between page submits.
What I want is to be able to show the selections (using draw query)
after a page has submitted without doing each time a query. In some
applications, peopole want to do a query and do some panning, zooming
without their query being lost.
I was thinking of adding a couple of utility functions to add shpes
id's to a resultcached used during the query. It will be less costly in
time to use these functions instead of redoing the query every time.
Do You think It is a useful ? Any comments/objections ?
Later,
--
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst
Email: assefa@dmsolutions.ca
http://www.dmsolutions.ca/
Phone: (613) 565-5056 (ext 14)
Fax: (613) 565-0925
----------------------------------------------------------------
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev@lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
From steve.lime at dnr.state.mn.us Fri Feb 14 11:41:12 2003
From: steve.lime at dnr.state.mn.us (Steve Lime)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Re: Add shape id's in the selection
Message-ID:
That's exactly why cached queries exist. Id's are written out to a file
and then reused in lieu of doing
a new query. Have you looked into those? I've used them in a couple of
circumstances and they
work quite nicely.
Steve
>>> Yewondwossen Assefa 02/14/03 08:27AM >>>
Hi There,
I was looking into how to keep selected elements between page
submits.
What I want is to be able to show the selections (using draw query)
after a page has submitted without doing each time a query. In some
applications, peopole want to do a query and do some panning, zooming
without their query being lost.
I was thinking of adding a couple of utility functions to add shpes
id's to a resultcached used during the query. It will be less costly
in
time to use these functions instead of redoing the query every time.
Do You think It is a useful ? Any comments/objections ?
Later,
--
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst
Email: assefa@dmsolutions.ca
http://www.dmsolutions.ca/
Phone: (613) 565-5056 (ext 14)
Fax: (613) 565-0925
----------------------------------------------------------------
From steve.lime at dnr.state.mn.us Fri Feb 14 11:51:18 2003
From: steve.lime at dnr.state.mn.us (Steve Lime)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Re: Add shape id's in the selection
Message-ID:
With a centralized file area this will still work...
>>> "Steve Lime" 02/14/03 10:41AM >>>
That's exactly why cached queries exist. Id's are written out to a
file
and then reused in lieu of doing
a new query. Have you looked into those? I've used them in a couple of
circumstances and they
work quite nicely.
Steve
>>> Yewondwossen Assefa 02/14/03 08:27AM >>>
Hi There,
I was looking into how to keep selected elements between page
submits.
What I want is to be able to show the selections (using draw query)
after a page has submitted without doing each time a query. In some
applications, peopole want to do a query and do some panning, zooming
without their query being lost.
I was thinking of adding a couple of utility functions to add shpes
id's to a resultcached used during the query. It will be less costly
in
time to use these functions instead of redoing the query every time.
Do You think It is a useful ? Any comments/objections ?
Later,
--
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst
Email: assefa@dmsolutions.ca
http://www.dmsolutions.ca/
Phone: (613) 565-5056 (ext 14)
Fax: (613) 565-0925
----------------------------------------------------------------
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev@lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
From assefa at dmsolutions.ca Fri Feb 14 11:52:31 2003
From: assefa at dmsolutions.ca (Yewondwossen Assefa)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Re: Add shape id's in the selection
References:
Message-ID: <3E4D1ECF.E5F0FEFD@dmsolutions.ca>
I did not realize that there were functions to save and load a query. That
is exactly what I needed. I just need to expose these functions to
mapscripit and I will be able to use them.
Thanks,
Steve Lime wrote:
> That's exactly why cached queries exist. Id's are written out to a file
> and then reused in lieu of doing
> a new query. Have you looked into those? I've used them in a couple of
> circumstances and they
> work quite nicely.
>
> Steve
>
> >>> Yewondwossen Assefa 02/14/03 08:27AM >>>
> Hi There,
>
> I was looking into how to keep selected elements between page
> submits.
> What I want is to be able to show the selections (using draw query)
> after a page has submitted without doing each time a query. In some
> applications, peopole want to do a query and do some panning, zooming
> without their query being lost.
>
> I was thinking of adding a couple of utility functions to add shpes
> id's to a resultcached used during the query. It will be less costly
> in
> time to use these functions instead of redoing the query every time.
>
> Do You think It is a useful ? Any comments/objections ?
>
> Later,
>
> --
> ----------------------------------------------------------------
> Assefa Yewondwossen
> Software Analyst
>
> Email: assefa@dmsolutions.ca
> http://www.dmsolutions.ca/
>
> Phone: (613) 565-5056 (ext 14)
> Fax: (613) 565-0925
> ----------------------------------------------------------------
--
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst
Email: assefa@dmsolutions.ca
http://www.dmsolutions.ca/
Phone: (613) 565-5056 (ext 14)
Fax: (613) 565-0925
----------------------------------------------------------------
From havard.tveite at ikf.nlh.no Fri Feb 14 16:00:02 2003
From: havard.tveite at ikf.nlh.no (Havard Tveite)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Label rendering Mapserver 3.7 - problems
Message-ID: <3E4D58D2.D484BE83@ikf.nlh.no>
I have experienced some problems with label rendering for
cached labels.
I tried to inform the user-list some weeks ago (Thu, 23 Jan
2003 14:42:47 +0100), but I have so far not seen any replies.
The problem is that the label background and the lables are
not scaled correctly. If I include the label background
I can see that the label background is not the same size as
the label, and the there is also a misalignment on the left
end of the label.
I have tried to look at the source code, but there is a lot
of things going on inside msDrawLabelCacheGD (msGetLabelSize,
....., billboardGD, msDrawTextGD), gdImageStringFT, ....
I have not found out if the problem is with GD, Freetype or
Mapserver.
I guess there are others that have more experience with the
code out there.
Does anyone have an idea of what is going on?
Am I the only one having this problem?
Should I file this as a bug in Bugzilla?
My configuration is:
Mapserver 3.7, nightly 23. january.
(Solaris 2.5.1)
MapServer version 3.7 (development) OUTPUT=PNG OUTPUT=JPEG
OUTPUT=WBMP SUPPORTS=PROJ SUPPORTS=TTF SUPPORTS=WMS_SERVER
SUPPORTS=WMS_CLIENT SUPPORTS=GD2_RGB INPUT=EPPL7 INPUT=SDE
INPUT=POSTGIS INPUT=GDAL INPUT=SHAPEFILE
GDAL 1.1.8
GD 2.0.11
PostGIS 0.7.3
Freetype 2.1.2
You can see the output of one of my tests here (try to zooom in and out):
Everything seems work OK with bitmap fonts.
The mapfile producing this output:
*******************************************************
MAP
NAME labeltest
IMAGETYPE png # png24 gives the same results
SIZE 400 400
EXTENT 0 0 1000 1000
UNITS meters
FONTSET /home/www/lib/fonts/font.list
WEB
IMAGEPATH "/home/ikf/ikfht/pub_html/mapserver/tmp/"
IMAGEURL "/~ikfht/mapserver/tmp/"
TEMPLATE /home/ikf/ikfht/pub_html/mapserver/o-kart/labeltest.html
END #web
SYMBOL
NAME "circle"
TYPE ellipse
FILLED true
POINTS 1 1 END
END
LAYER
NAME fonttest
TYPE POINT
STATUS DEFAULT
LABELMINSCALE 1000 # This seems to have no effect on the label scaling
LABELMAXSCALE 100000 # This seems to have no effect on the label scaling
MINSCALE 500 # This seems to have no effect on the label scaling
SYMBOLSCALE 10000 # This has effect on label scaling
MAXSCALE 200000 # This seems to have no effect on the label scaling
FEATURE
POINTS 100 500 END
TEXT "test y"
END
CLASS
COLOR 255 0 0
SYMBOL "circle"
SIZE 10
LABEL
COLOR 0 0 0
BACKGROUNDCOLOR 200 200 100
POSITION UR
TYPE truetype
FONT arial
MINSIZE 10 # this has no effect on the label background scaling
SIZE 20
MAXSIZE 30 # this has no effect on the label background scaling
END
END # CLASS
END # LAYER
END
*******************************************************
--
Håvard Tveite Phone: +47 64948857
Department of Mapping Sciences Fax: +47 64948856
Agricultural University of Norway
POBox 5034, N-1432 Ås, NORWAY http://www.nlh.no/ikf/
From steve.lime at dnr.state.mn.us Sat Feb 15 14:26:07 2003
From: steve.lime at dnr.state.mn.us (Steve Lime)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Label rendering Mapserver 3.7 - problems
Message-ID:
have you tried a more recent build? I fixed some scaling issues in the
last couple of weeks and based on reports from a few testers all is
well.
Steve
Stephen Lime
Data & Applications Manager
Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-297-2937
>>> Havard Tveite 02/14/03 15:02 PM >>>
I have experienced some problems with label rendering for
cached labels.
I tried to inform the user-list some weeks ago (Thu, 23 Jan
2003 14:42:47 +0100), but I have so far not seen any replies.
The problem is that the label background and the lables are
not scaled correctly. If I include the label background
I can see that the label background is not the same size as
the label, and the there is also a misalignment on the left
end of the label.
I have tried to look at the source code, but there is a lot
of things going on inside msDrawLabelCacheGD (msGetLabelSize,
....., billboardGD, msDrawTextGD), gdImageStringFT, ....
I have not found out if the problem is with GD, Freetype or
Mapserver.
I guess there are others that have more experience with the
code out there.
Does anyone have an idea of what is going on?
Am I the only one having this problem?
Should I file this as a bug in Bugzilla?
My configuration is:
Mapserver 3.7, nightly 23. january.
(Solaris 2.5.1)
MapServer version 3.7 (development) OUTPUT=PNG OUTPUT=JPEG
OUTPUT=WBMP SUPPORTS=PROJ SUPPORTS=TTF SUPPORTS=WMS_SERVER
SUPPORTS=WMS_CLIENT SUPPORTS=GD2_RGB INPUT=EPPL7 INPUT=SDE
INPUT=POSTGIS INPUT=GDAL INPUT=SHAPEFILE
GDAL 1.1.8
GD 2.0.11
PostGIS 0.7.3
Freetype 2.1.2
You can see the output of one of my tests here (try to zooom in and
out):
Everything seems work OK with bitmap fonts.
The mapfile producing this output:
*******************************************************
MAP
NAME labeltest
IMAGETYPE png # png24 gives the same results
SIZE 400 400
EXTENT 0 0 1000 1000
UNITS meters
FONTSET /home/www/lib/fonts/font.list
WEB
IMAGEPATH "/home/ikf/ikfht/pub_html/mapserver/tmp/"
IMAGEURL "/~ikfht/mapserver/tmp/"
TEMPLATE /home/ikf/ikfht/pub_html/mapserver/o-kart/labeltest.html
END #web
SYMBOL
NAME "circle"
TYPE ellipse
FILLED true
POINTS 1 1 END
END
LAYER
NAME fonttest
TYPE POINT
STATUS DEFAULT
LABELMINSCALE 1000 # This seems to have no effect on the label
scaling
LABELMAXSCALE 100000 # This seems to have no effect on the label
scaling
MINSCALE 500 # This seems to have no effect on the label
scaling
SYMBOLSCALE 10000 # This has effect on label scaling
MAXSCALE 200000 # This seems to have no effect on the label
scaling
FEATURE
POINTS 100 500 END
TEXT "test y"
END
CLASS
COLOR 255 0 0
SYMBOL "circle"
SIZE 10
LABEL
COLOR 0 0 0
BACKGROUNDCOLOR 200 200 100
POSITION UR
TYPE truetype
FONT arial
MINSIZE 10 # this has no effect on the label background scaling
SIZE 20
MAXSIZE 30 # this has no effect on the label background scaling
END
END # CLASS
END # LAYER
END
*******************************************************
--
Håvard Tveite Phone: +47 64948857
Department of Mapping Sciences Fax: +47 64948856
Agricultural University of Norway
POBox 5034, N-1432 Ås, NORWAY http://www.nlh.no/ikf/
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev@lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
From steve.lime at dnr.state.mn.us Sat Feb 15 14:41:43 2003
From: steve.lime at dnr.state.mn.us (Steve Lime)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Label rendering Mapserver 3.7 - problems
Message-ID:
have you tried a more recent build? I fixed some scaling issues in the
last couple of weeks and based on reports from a few testers all is
well.
Steve
Stephen Lime
Data & Applications Manager
Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-297-2937
Stephen Lime
Data & Applications Manager
Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-297-2937
>>> Havard Tveite 02/14/03 15:02 PM >>>
I have experienced some problems with label rendering for
cached labels.
I tried to inform the user-list some weeks ago (Thu, 23 Jan
2003 14:42:47 +0100), but I have so far not seen any replies.
The problem is that the label background and the lables are
not scaled correctly. If I include the label background
I can see that the label background is not the same size as
the label, and the there is also a misalignment on the left
end of the label.
I have tried to look at the source code, but there is a lot
of things going on inside msDrawLabelCacheGD (msGetLabelSize,
....., billboardGD, msDrawTextGD), gdImageStringFT, ....
I have not found out if the problem is with GD, Freetype or
Mapserver.
I guess there are others that have more experience with the
code out there.
Does anyone have an idea of what is going on?
Am I the only one having this problem?
Should I file this as a bug in Bugzilla?
My configuration is:
Mapserver 3.7, nightly 23. january.
(Solaris 2.5.1)
MapServer version 3.7 (development) OUTPUT=PNG OUTPUT=JPEG
OUTPUT=WBMP SUPPORTS=PROJ SUPPORTS=TTF SUPPORTS=WMS_SERVER
SUPPORTS=WMS_CLIENT SUPPORTS=GD2_RGB INPUT=EPPL7 INPUT=SDE
INPUT=POSTGIS INPUT=GDAL INPUT=SHAPEFILE
GDAL 1.1.8
GD 2.0.11
PostGIS 0.7.3
Freetype 2.1.2
You can see the output of one of my tests here (try to zooom in and
out):
Everything seems work OK with bitmap fonts.
The mapfile producing this output:
*******************************************************
MAP
NAME labeltest
IMAGETYPE png # png24 gives the same results
SIZE 400 400
EXTENT 0 0 1000 1000
UNITS meters
FONTSET /home/www/lib/fonts/font.list
WEB
IMAGEPATH "/home/ikf/ikfht/pub_html/mapserver/tmp/"
IMAGEURL "/~ikfht/mapserver/tmp/"
TEMPLATE /home/ikf/ikfht/pub_html/mapserver/o-kart/labeltest.html
END #web
SYMBOL
NAME "circle"
TYPE ellipse
FILLED true
POINTS 1 1 END
END
LAYER
NAME fonttest
TYPE POINT
STATUS DEFAULT
LABELMINSCALE 1000 # This seems to have no effect on the label
scaling
LABELMAXSCALE 100000 # This seems to have no effect on the label
scaling
MINSCALE 500 # This seems to have no effect on the label
scaling
SYMBOLSCALE 10000 # This has effect on label scaling
MAXSCALE 200000 # This seems to have no effect on the label
scaling
FEATURE
POINTS 100 500 END
TEXT "test y"
END
CLASS
COLOR 255 0 0
SYMBOL "circle"
SIZE 10
LABEL
COLOR 0 0 0
BACKGROUNDCOLOR 200 200 100
POSITION UR
TYPE truetype
FONT arial
MINSIZE 10 # this has no effect on the label background scaling
SIZE 20
MAXSIZE 30 # this has no effect on the label background scaling
END
END # CLASS
END # LAYER
END
*******************************************************
--
Håvard Tveite Phone: +47 64948857
Department of Mapping Sciences Fax: +47 64948856
Agricultural University of Norway
POBox 5034, N-1432 Ås, NORWAY http://www.nlh.no/ikf/
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev@lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
From jnovak at novacell.com Sat Feb 15 22:45:00 2003
From: jnovak at novacell.com (Administrator)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Graticule support is checked in to CVS...
Message-ID: <41CC46B3925E384BA64B1FB5041C38FA49C1@www.novacell.com>
And here's the new GRID keyword documentation:
The layer definition
LAYER
NAME "SAMPLE GRID"
PROJECTION
"proj=latlong"
"ellps=WGS84"
"datum=WGS84"
END
TYPE LINE
STATUS DEFAULT
CLASS
COLOR 0 255 128
LABEL
TYPE BITMAP
SIZE MEDIUM
COLOR 255 128 89
END
END
FEATURE
GRID
END
END
END
Will generate a graticule with default arc spacing, arc color RGB 0 255
128 and labeled in decimal degrees with color RGB 255 128 89. Labels
will appear at all four of the image edges.
Each arc in the resulting grid is composed of 256 line segments. To
render grid arcs with a different number of segments, use the
MINSUBDIVIDE and MAXSUBDIVIDE keywords. Setting MINSUBDIVIDE ==
MAXSUBDIVIDE will always yield exactly the number of segments specified.
To set the format of the grid labels, specify a printf style format
string after the LABELFORMAT keyword. The default string is "%5.2f".
To get DMS labeling, enter "DDMMSS" as the LABELFORMAT string used by
the GRID, and for DM labeling, specify "DDMM".
The GRID feature
FEATURE
GRID
MINSUBDIVIDE 64
MAXSUBDIVIDE 64
LABELFORMAT "DDMMSS"
END
END
Yields a grid with 64 segments in every arc labeled with degrees,
minutes and seconds.
Other keywords behave similarly:
MININTERVAL and MAXINTERVAL allow a range to be set for grid spacing.
The interval is specified in the coordinate system of the grid. Since
PROJECTION is supported, if your mapserver has PROJ4, the grid may be in
any coordinate system supported by PROJ4, and will be projected into the
coordinate system of the generated image.
MINARCS and MAXARCS are hints to the code that generates grid intervals
regarding when to stop subdividing the range of an axis.
The subdivider will try to honor the range specified, or the min/max id
only one keyword is present.
Please let me know if there are bugs, questions or comments.
Regards,
John Novak
Novacell Technologies
www.novacell.com
From morissette at dmsolutions.ca Mon Feb 17 13:54:45 2003
From: morissette at dmsolutions.ca (Daniel Morissette)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] New msCloneLayerObj() function
Message-ID: <3E512FF5.F01E4C50@dmsolutions.ca>
Steve,
We are thinking of adding a new function to mapfile.c (and MapScript) to
initialize a new layer by creating a clone of an existing layer. This
would allow us to easily make copies of layers inside a single mapObj,
or to copy layers from one mapObj to another.
The C function prototype would be:
int msCloneLayerObj(mapObj *target_map, layerObj *src_layer);
which would create a new layer inside target_map which is a copy of
src_layer.
In PHP MapScript, the function ms_newMapObj() would be extended to take
an optional second argument that would be the layer to clone:
layerObj ms_newLayerObj(mapObj target_map [,layerObj layer_to_clone])
I don't think SWIG allows for optional arguments like we use in PHP, so
we would have to expose a separate function for msCloneLayerObj() in the
SWIG'd MapScript.
Is that OK with you? Any suggestions, comments?
Daniel
--
------------------------------------------------------------
Daniel Morissette morissette@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
From sgillies at frii.com Mon Feb 17 14:40:09 2003
From: sgillies at frii.com (Sean Gillies)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] New msCloneLayerObj() function
In-Reply-To: <3E512FF5.F01E4C50@dmsolutions.ca>
Message-ID: <9F5AB822-42AF-11D7-8CF3-000393B98B56@frii.com>
On Monday, February 17, 2003, at 11:54 AM, Daniel Morissette wrote:
> Steve,
>
> We are thinking of adding a new function to mapfile.c (and MapScript)
> to
> initialize a new layer by creating a clone of an existing layer. This
> would allow us to easily make copies of layers inside a single mapObj,
> or to copy layers from one mapObj to another.
>
> The C function prototype would be:
>
> int msCloneLayerObj(mapObj *target_map, layerObj *src_layer);
>
> which would create a new layer inside target_map which is a copy of
> src_layer.
>
> In PHP MapScript, the function ms_newMapObj() would be extended to take
> an optional second argument that would be the layer to clone:
>
> layerObj ms_newLayerObj(mapObj target_map [,layerObj layer_to_clone])
>
> I don't think SWIG allows for optional arguments like we use in PHP, so
> we would have to expose a separate function for msCloneLayerObj() in
> the
> SWIG'd MapScript.
>
> Is that OK with you? Any suggestions, comments?
>
> Daniel
> --
>
Daniel,
There was a request in Bugzilla for a msCopyMap() function that I
accepted as my first contribution to MapServer. I've nearly finished
it and it has what you are looking for.
int msCopyLayer(layerObj *dst, layerObj *src, mapObj *map);
I picked the argument order to resemble memcpy(). The mapObj is
needed as a final argument because the destination layer needs a
pointer to it's parent map. It's intended to copy layers
between maps, but could copy within a map as well.
In mapscript.i, I was planning to extend layerObj with a copy()
function which would be used like this Python example:
map1 = mapObj(mapfile) # contains a layer
lay1 = map1.getlayer(0)
lay2 = layerObj(map1)
lay2 = lay1.copy()
I'm reluctant to commit my code into mapfile.c since there's ~700 lines
(including functions to copy other map objects), so I was thinking
of a new file? mapcopy.c perhaps? I could commit this file to CVS if
you want to take a look.
Speaking of new features -- I've been wishing for functions to remove
layers and classes from mapObjs. I thought I might move on to that
next after finishing the ms*Copy stuff.
cheers,
Sean
--
Sean Gillies
sgillies@frii.com
http://www.frii.com/~sgillies
From jhart at frw.uva.nl Mon Feb 17 15:23:32 2003
From: jhart at frw.uva.nl (Jan Hartmann)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] New msCloneLayerObj() function
In-Reply-To: <9F5AB822-42AF-11D7-8CF3-000393B98B56@frii.com>
References: <9F5AB822-42AF-11D7-8CF3-000393B98B56@frii.com>
Message-ID: <3E5144C4.8010507@frw.uva.nl>
Sean Gillies wrote:
>
> int msCopyLayer(layerObj *dst, layerObj *src, mapObj *map);
>
> I picked the argument order to resemble memcpy(). The mapObj is
> needed as a final argument because the destination layer needs a
> pointer to it's parent map.
Sean,
The layerObj struct already has a pointer to its parent map (as well as
to its own index in the map->layers array). Almost all bookkeeping you
need is already available. I discovered this when implementing
connection pooling; most of my original code could be discarded after that.
Jan
From morissette at dmsolutions.ca Mon Feb 17 16:37:40 2003
From: morissette at dmsolutions.ca (Daniel Morissette)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] New msCloneLayerObj() function
References: <9F5AB822-42AF-11D7-8CF3-000393B98B56@frii.com>
Message-ID: <3E515624.49AA9F3F@dmsolutions.ca>
Sean Gillies wrote:
>
> In mapscript.i, I was planning to extend layerObj with a copy()
> function which would be used like this Python example:
>
> map1 = mapObj(mapfile) # contains a layer
> lay1 = map1.getlayer(0)
> lay2 = layerObj(map1)
> lay2 = lay1.copy()
>
Makes sense. We would have to apply the same logic in PHP MapScript.
> I'm reluctant to commit my code into mapfile.c since there's ~700 lines
> (including functions to copy other map objects), so I was thinking
> of a new file? mapcopy.c perhaps? I could commit this file to CVS if
> you want to take a look.
>
Perhaps a new mapcopy.c is what would make the most sense. In our case
we need this feature by Wednesday for something we are working on, so
the sooner you can commit the better. Assefa will be the first one to
test this from our end as he integrates it in PHP MapScript.
Thanks
Daniel
--
------------------------------------------------------------
Daniel Morissette morissette@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
From sauron29x at yahoo.com.ar Tue Feb 18 09:28:42 2003
From: sauron29x at yahoo.com.ar (=?iso-8859-1?q?jose=20ss?=)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] Hello
Message-ID: <20030218142842.97237.qmail@web13003.mail.yahoo.com>
I´m testing the list, sorry.
Ahora podés usar Yahoo! Messenger desde tu celular. Aprendé cómo hacerlo en Yahoo! Móvil: http://ar.mobile.yahoo.com/sms.html
From sgillies at frii.com Tue Feb 18 11:13:36 2003
From: sgillies at frii.com (Sean Gillies)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] New msCloneLayerObj() function
In-Reply-To: <3E5144C4.8010507@frw.uva.nl>
Message-ID:
On Monday, February 17, 2003, at 01:23 PM, Jan Hartmann wrote:
>
>
> Sean Gillies wrote:
>
>> int msCopyLayer(layerObj *dst, layerObj *src, mapObj *map);
>> I picked the argument order to resemble memcpy(). The mapObj is
>> needed as a final argument because the destination layer needs a
>> pointer to it's parent map.
>
> Sean,
>
> The layerObj struct already has a pointer to its parent map (as well
> as to its own index in the map->layers array). Almost all bookkeeping
> you need is already available. I discovered this when implementing
> connection pooling; most of my original code could be discarded after
> that.
>
> Jan
>
>
Jan,
Yes, you are right: initLayer() sets the map for a layer. Thanks for
the
advice.
I've committed mapcopy.c to CVS, as well as a copy() extension to mapObj
in mapscript.i and a unit testing script in mapscript/python/tests.
I've written further notes about my work in Bugzilla. See Bug 272.
Sean
--
Sean Gillies
sgillies@frii.com
http://www.frii.com/~sgillies
From steve.lime at dnr.state.mn.us Tue Feb 18 13:15:37 2003
From: steve.lime at dnr.state.mn.us (Steve Lime)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] New msCloneLayerObj() function
Message-ID:
I'm worried about moving the copying code out of mapfile.c or a least
away from other code
pertaining to a particular object type (i.e. layerObj). When making
changes it means you have
to make sure to remember to change mapfile.c and mapcopy.c, much nicer
to have all the
code together. If mapfile.c is getting bulky I might suggest busting it
into parts like:
mapfile_layerObj.c
mapfile_scalebarObj.c
with mapfile.c holding code for the main mapObj and the helper
functions. Just a thought.
Steve
>>> Daniel Morissette 02/17/03 03:37PM >>>
Sean Gillies wrote:
>
> In mapscript.i, I was planning to extend layerObj with a copy()
> function which would be used like this Python example:
>
> map1 = mapObj(mapfile) # contains a layer
> lay1 = map1.getlayer(0)
> lay2 = layerObj(map1)
> lay2 = lay1.copy()
>
Makes sense. We would have to apply the same logic in PHP MapScript.
> I'm reluctant to commit my code into mapfile.c since there's ~700
lines
> (including functions to copy other map objects), so I was thinking
> of a new file? mapcopy.c perhaps? I could commit this file to CVS
if
> you want to take a look.
>
Perhaps a new mapcopy.c is what would make the most sense. In our
case
we need this feature by Wednesday for something we are working on, so
the sooner you can commit the better. Assefa will be the first one to
test this from our end as he integrates it in PHP MapScript.
Thanks
Daniel
--
------------------------------------------------------------
Daniel Morissette morissette@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev@lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
From sgillies at frii.com Tue Feb 18 14:06:02 2003
From: sgillies at frii.com (Sean Gillies)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] New msCloneLayerObj() function
In-Reply-To:
Message-ID: <062C7F51-4374-11D7-BE35-000393B98B56@frii.com>
On Tuesday, February 18, 2003, at 11:15 AM, Steve Lime wrote:
> I'm worried about moving the copying code out of mapfile.c or a least
> away from other code
> pertaining to a particular object type (i.e. layerObj). When making
> changes it means you have
> to make sure to remember to change mapfile.c and mapcopy.c, much nicer
> to have all the
> code together. If mapfile.c is getting bulky I might suggest busting it
> into parts like:
>
> mapfile_layerObj.c
> mapfile_scalebarObj.c
>
> with mapfile.c holding code for the main mapObj and the helper
> functions. Just a thought.
>
> Steve
>
>
Steve,
I haven't revised mapfile.c.
The code in mapcopy.c _does_ use many of the functions in mapfile.c,
so maybe it belongs with that file. I made a new file only because
I didn't want to run roughshod over mapfile.c and because the stuff
I'm writing will likely never be used in mapserv itself.
Which leads me to a question: if it's only for mapscript users,
maybe the solution is a new swig interface file to accompany
mapscript.i?
I'm easy, and will readily go with your call. Wherever the code
goes, and whether we call the functions *Copy* or *Clone* (there's
already some precedence) is fine with me.
Sean
From steve.lime at dnr.state.mn.us Tue Feb 18 15:54:25 2003
From: steve.lime at dnr.state.mn.us (Steve Lime)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] New msCloneLayerObj() function
Message-ID:
I'm not ready to say it's just for MapScript users. Mapscript.i
definitely needs
to leverage your new stuff. As do folks writing C code (yes, there are
a few
out there, and PHP/MapScript. MapServer proper needs it for a true
fast-cgi
support to work. There's definitely an audience.
mapfile.c is kinda messy any how. Functions once intended for internal
use
only (e.g. initLayer()) are now used elsewhere so now might be the
time
to clean up. Move all object specific files to one spot, and rename
functions
to fit the rest of the system, msInitLayer(), msFreeLayer() and
msCloneLayer.
That's what I would suggest but I'd really like to hear from others on
the
topic.
Steve
Stephen Lime
Data & Applications Manager
Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-297-2937
>>> Sean Gillies 02/18/03 01:06PM >>>
On Tuesday, February 18, 2003, at 11:15 AM, Steve Lime wrote:
> I'm worried about moving the copying code out of mapfile.c or a
least
> away from other code
> pertaining to a particular object type (i.e. layerObj). When making
> changes it means you have
> to make sure to remember to change mapfile.c and mapcopy.c, much
nicer
> to have all the
> code together. If mapfile.c is getting bulky I might suggest busting
it
> into parts like:
>
> mapfile_layerObj.c
> mapfile_scalebarObj.c
>
> with mapfile.c holding code for the main mapObj and the helper
> functions. Just a thought.
>
> Steve
>
>
Steve,
I haven't revised mapfile.c.
The code in mapcopy.c _does_ use many of the functions in mapfile.c,
so maybe it belongs with that file. I made a new file only because
I didn't want to run roughshod over mapfile.c and because the stuff
I'm writing will likely never be used in mapserv itself.
Which leads me to a question: if it's only for mapscript users,
maybe the solution is a new swig interface file to accompany
mapscript.i?
I'm easy, and will readily go with your call. Wherever the code
goes, and whether we call the functions *Copy* or *Clone* (there's
already some precedence) is fine with me.
Sean
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev@lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
From morissette at dmsolutions.ca Tue Feb 18 17:42:09 2003
From: morissette at dmsolutions.ca (Daniel Morissette)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] New msCloneLayerObj() function
References:
Message-ID: <3E52B6C1.2606F950@dmsolutions.ca>
Steve Lime wrote:
>
> mapfile.c is kinda messy any how. Functions once intended for internal
> use
> only (e.g. initLayer()) are now used elsewhere so now might be the
> time
> to clean up. Move all object specific files to one spot, and rename
> functions
> to fit the rest of the system, msInitLayer(), msFreeLayer() and
> msCloneLayer.
>
> That's what I would suggest but I'd really like to hear from others on
> the
> topic.
>
I agree that it would be nice to eventually rework that part to keep
only the parser and the save functions in mapfile.c, and move the
various object constructor and destructor functions to separate files
with proper public function names as you suggested. However I'm not
convinced that now is a good time to do this if we want to release 3.7
some day. I would vote for keeping this as a post-3.7 work item as it
doesn't affect functionality of the software, but if someone has time to
tackle that then I have no real objection either. (Perhaps this should
be filed as a bugzilla enhancement bug?)
My 0.02$
Daniel
--
------------------------------------------------------------
Daniel Morissette morissette@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
From assefa at dmsolutions.ca Wed Feb 19 12:20:44 2003
From: assefa at dmsolutions.ca (Yewondwossen Assefa)
Date: Fri Feb 8 14:56:36 2008
Subject: [Mapserver-dev] class obj elements
Message-ID: <3E53BCEC.102E4366@dmsolutions.ca>
Hi There,
Is there any reason why we kept in the class object structure all
memers that are now part of the style obj (color, bacgoundcolor ...).
They do not seem to be used any more. If you do not see any inconvinece,
I would like to remove them.
Thanks
--
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst
Email: assefa@dmsolutions.ca
http://www.dmsolutions.ca/
Phone: (613) 565-5056 (ext 14)
Fax: (613) 565-0925
----------------------------------------------------------------
From ed at topozone.com Fri Feb 21 10:55:36 2003
From: ed at topozone.com (Ed McNierney)
Date: Fri Feb 8 14:56:37 2008
Subject: [Mapserver-dev] OUTPUTFORMAT selection and IMAGETYPE parameter
Message-ID: <13858AA1A74F30419F319ACB66A9D1221F3DE0@mercator.topozone.com>
This is a multi-part message in MIME format.
------_=_NextPart_001_01C2D9C1.AC928D21
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Frank -
I think Steve Woodbridge's problem with OUTPUTFORMAT selection will be =
fixed by the same code I sent you a few weeks ago to check in to =
implement the IMAGETYPE parameter on the CGI command line.
I've attached the original message with the code. I first implemented =
the querystring parameter and set the msObj->Map->imagetype to whatever =
string was passed in the IMAGETYPE=3Dxxx parameter. This didn't work, =
and a few folks pointed out that I call msSelectOutputFormat to make it =
work - that wasn't enough, either, because it simply returned the =
outputformat object without doing anything with it. I had to call =
msApplyOutputFormat, passing it the object returned by =
msSelectOutputFormat, to make it stick.
I was puzzled by Steve's bug (he wants the first OUTPUTFORMAT block in =
the file to be the default) because it works correctly on my build! I =
am now suspecting that the second half of my changed also fixes this =
problem. I'm *guessing* that msObj->Map->imagetype is ALWAYS being set =
at startup time, even if there is no IMAGETYPE statement in the map file =
or on the querystring. If that's the case, then my change forces the =
outputformat object associated with that imagetype label to be =
"applied", which was not being done before.
- Ed
Ed McNierney
President and Chief Mapmaker
TopoZone.com / Maps a la carte, Inc.
73 Princeton Street, Suite 305
North Chelmsford, MA 01863
ed@topozone.com
(978) 251-4242=20
------_=_NextPart_001_01C2D9C1.AC928D21
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----_=_NextPart_002_01C2CBCC.2AA56D66"
Subject: RE: [Mapserver-users] Querystring parameters for selecting OUTPUTFORMAT
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
Date: Mon, 3 Feb 2003 16:35:26 -0500
Message-ID: <13858AA1A74F30419F319ACB66A9D1221F3C5A@mercator.topozone.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Thread-Topic: [Mapserver-users] Querystring parameters for selecting OUTPUTFORMAT
Thread-Index: AcLJb1nlXCJaC1BdQ5eWmqXOGYltAwCXCNgQ
From: "Ed McNierney"
To: "Frank Warmerdam"
This is a multi-part message in MIME format.
------_=_NextPart_002_01C2CBCC.2AA56D66
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Frank -
Attached is a new mapserv.c that implements the IMAGETYPE querystring =
parameter. This is the only file changed; I just reapplied the changes =
to a fresh CVS checkout of mapserv.c.
The changes occur in two places.
First, the querystring parameter is checked in the usual manner:
/*
Allow selection of IMAGETYPE from the command line
*/
if(strncasecmp(msObj->ParamNames[i],"imagetype", 9) =3D=3D 0) { // =
select an image type defined by an OUTPUTFORMAT
msObj->Map->imagetype =3D strdup(msObj->ParamValues[i]);
continue;
}
This saves the string label for the imagetype in the =
msObj->Map->imagetype object, which is where it's stored when read from =
the MAP file.
Second, I had to make a larger change than you suggested to implement =
the output setting. You suggested calling msSelectOutputFormat with the =
new output imagetype string, but that seems to simply return a format =
object that matches the string - I then needed to pass that format =
object to msApplyOutputFormat in order to make it work. It seemed like =
the best place to do this was immediately after the loadForm call that =
would load the querystring parameter:
if(msObj->Map->imagetype !=3D NULL) { /* If imagetype is set =
from the MAP file or a form variable */=09
msApplyOutputFormat( &(msObj->Map->outputformat), /* Select the =
new output format from the table and apply it */
msSelectOutputFormat(msObj->Map, msObj->Map->imagetype), =
msObj->Map->transparent, msObj->Map->interlace, msObj->Map->imagequality =
);
}
Let me know if you have any questions - thanks!
- Ed
Ed McNierney
President and Chief Mapmaker
TopoZone.com / Maps a la carte, Inc.
73 Princeton Street, Suite 305
North Chelmsford, MA 01863
ed@topozone.com
(978) 251-4242=20
-----Original Message-----
From: Frank Warmerdam [mailto:warmerdam@pobox.com]
Sent: Friday, January 31, 2003 4:26 PM
To: Ed McNierney
Subject: Re: [Mapserver-users] Querystring parameters for selecting
OUTPUTFORMAT
Ed McNierney wrote:
> Frank -
>=20
> Thanks for the quick reply. Yes, this is to support regular CGI =
usage. I'm
> not comfortable committing code changes to CVS, but this should be a =
short
> snippet and I'll send it to you for checkin.
Ed,
Sure thing.
Later,
--=20
---------------------------------------+---------------------------------=
-----
I set the clouds in motion - turn up | Frank Warmerdam, =
warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
------_=_NextPart_002_01C2CBCC.2AA56D66
Content-Type: application/octet-stream;
name="mapserv.c"
Content-Transfer-Encoding: base64
Content-Description: mapserv.c
Content-Disposition: attachment;
filename="mapserv.c"
I2luY2x1ZGUgIm1hcHNlcnYuaCINCg0KI2lmZGVmIFVTRV9FR0lTIA0KI2luY2x1ZGUgPGVyckxv
Zy5oPiAgCS8vIGVnaXMgLSBpbmNsdWRlcw0KI2luY2x1ZGUgImVnaXMuaCINCiNpbmNsdWRlICJn
bG9iYWxTdHJ1Y3QuaCINCiNpbmNsdWRlICJlZ2lzSFRNTC5oIg0KDQovLyB0ZW1wbGF0ZSBzdHVm
Zg0KLy8jaW5jbHVkZSAibWFwdGVtcGxhdGUuYyINCg0KLy9PViAtZWdpcy0gZm9yIGxvY2FsIGRl
YnVnZ2luZywgaWYgc2V0IHZhcmlvdXMgbWVzc2FnZSB3aWxsIGJlIA0KLy8gcHJpbnRlZCB0byAv
dG1wL2VnaXNFcnJvci5sb2cNCg0KI2RlZmluZSBteURlYnVnIDAgDQojZGVmaW5lIG15RGVidWdI
dG1sIDANCg0KY2hhciBlcnJMb2dNc2dbODBdOwkvLyBlZ2lzIC0gZm9yIHN0b3JpbmcgYW5kIHBy
aW50aW5nIGVycm9yIG1lc3NhZ2VzDQojZW5kaWYNCg0KZXh0ZXJuIGRvdWJsZSBpbmNoZXNQZXJV
bml0WzZdOw0KDQptYXBzZXJ2T2JqKiBtc09iajsNCg0KaW50IHdyaXRlTG9nKGludCBzaG93X2Vy
cm9yKQ0Kew0KICBGSUxFICpzdHJlYW07DQogIGludCBpOw0KICB0aW1lX3QgdDsNCiAgY2hhciBz
elBhdGhbTVNfTUFYUEFUSExFTl07DQoNCiAgaWYoIW1zT2JqLT5NYXApIHJldHVybigwKTsNCiAg
aWYoIW1zT2JqLT5NYXAtPndlYi5sb2cpIHJldHVybigwKTsNCiAgDQogIGlmKChzdHJlYW0gPSBm
b3Blbihtc0J1aWxkUGF0aChzelBhdGgsIG1zT2JqLT5NYXAtPm1hcHBhdGgsIA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBtc09iai0+TWFwLT53ZWIubG9nKSwiYSIpKSA9PSBO
VUxMKSB7DQogICAgbXNTZXRFcnJvcihNU19JT0VSUiwgbXNPYmotPk1hcC0+d2ViLmxvZywgIndy
aXRlTG9nKCkiKTsNCiAgICByZXR1cm4oLTEpOw0KICB9DQoNCiAgdCA9IHRpbWUoTlVMTCk7DQog
IGZwcmludGYoc3RyZWFtLCIlcywiLGNob3AoY3RpbWUoJnQpKSk7DQogIGZwcmludGYoc3RyZWFt
LCIlZCwiLChpbnQpZ2V0cGlkKCkpOw0KICANCiAgaWYoZ2V0ZW52KCJSRU1PVEVfQUREUiIpICE9
IE5VTEwpDQogICAgZnByaW50ZihzdHJlYW0sIiVzLCIsZ2V0ZW52KCJSRU1PVEVfQUREUiIpKTsN
CiAgZWxzZQ0KICAgIGZwcmludGYoc3RyZWFtLCJOVUxMLCIpOw0KIA0KICBmcHJpbnRmKHN0cmVh
bSwiJXMsIixtc09iai0+TWFwLT5uYW1lKTsNCiAgZnByaW50ZihzdHJlYW0sIiVkLCIsbXNPYmot
Pk1vZGUpOw0KDQogIGZwcmludGYoc3RyZWFtLCIlZiAlZiAlZiAlZiwiLCBtc09iai0+TWFwLT5l
eHRlbnQubWlueCwgbXNPYmotPk1hcC0+ZXh0ZW50Lm1pbnksIG1zT2JqLT5NYXAtPmV4dGVudC5t
YXh4LCBtc09iai0+TWFwLT5leHRlbnQubWF4eSk7DQoNCiAgZnByaW50ZihzdHJlYW0sIiVmICVm
LCIsIG1zT2JqLT5NYXBQbnQueCwgbXNPYmotPk1hcFBudC55KTsNCg0KICBmb3IoaT0wO2k8bXNP
YmotPk51bUxheWVycztpKyspDQogICAgZnByaW50ZihzdHJlYW0sICIlcyAiLCBtc09iai0+TGF5
ZXJzW2ldKTsNCiAgZnByaW50ZihzdHJlYW0sIiwiKTsNCg0KICBpZihzaG93X2Vycm9yID09IE1T
X1RSVUUpDQogICAgbXNXcml0ZUVycm9yKHN0cmVhbSk7DQogIGVsc2UNCiAgICBmcHJpbnRmKHN0
cmVhbSwgIm5vcm1hbCBleGVjdXRpb24iKTsNCg0KICBmcHJpbnRmKHN0cmVhbSwiXG4iKTsNCg0K
ICBmY2xvc2Uoc3RyZWFtKTsNCiAgcmV0dXJuKDApOw0KfQ0KDQp2b2lkIHdyaXRlRXJyb3IoKQ0K
ew0KICBlcnJvck9iaiAqbXNfZXJyb3IgPSBtc0dldEVycm9yT2JqKCk7DQoNCiAgd3JpdGVMb2co
TVNfVFJVRSk7DQoNCiAgaWYoIW1zT2JqLT5NYXApIHsNCiAgICBwcmludGYoIkNvbnRlbnQtdHlw
ZTogdGV4dC9odG1sJWMlYyIsMTAsMTApOw0KICAgIHByaW50ZigiPEhUTUw+XG4iKTsNCiAgICBw
cmludGYoIjxIRUFEPjxUSVRMRT5NYXBTZXJ2ZXIgTWVzc2FnZTwvVElUTEU+PC9IRUFEPlxuIik7
DQogICAgcHJpbnRmKCI8IS0tICVzIC0tPlxuIiwgbXNHZXRWZXJzaW9uKCkpOw0KICAgIHByaW50
ZigiPEJPRFkgQkdDT0xPUj1cIiNGRkZGRkZcIj5cbiIpOw0KICAgIG1zV3JpdGVFcnJvcihzdGRv
dXQpOw0KICAgIHByaW50ZigiPC9CT0RZPjwvSFRNTD4iKTsNCiAgICBleGl0KDApOw0KICB9DQoN
CiAgaWYoKG1zX2Vycm9yLT5jb2RlID09IE1TX05PVEZPVU5EKSAmJiAobXNPYmotPk1hcC0+d2Vi
LmVtcHR5KSkgew0KICAgIG1zUmVkaXJlY3QobXNPYmotPk1hcC0+d2ViLmVtcHR5KTsNCiAgfSBl
bHNlIHsNCiAgICBpZihtc09iai0+TWFwLT53ZWIuZXJyb3IpIHsgICAgICANCiAgICAgIG1zUmVk
aXJlY3QobXNPYmotPk1hcC0+d2ViLmVycm9yKTsNCiAgICB9IGVsc2Ugew0KICAgICAgcHJpbnRm
KCJDb250ZW50LXR5cGU6IHRleHQvaHRtbCVjJWMiLDEwLDEwKTsNCiAgICAgIHByaW50ZigiPEhU
TUw+XG4iKTsNCiAgICAgIHByaW50ZigiPEhFQUQ+PFRJVExFPk1hcFNlcnZlciBNZXNzYWdlPC9U
SVRMRT48L0hFQUQ+XG4iKTsNCiAgICAgIHByaW50ZigiPCEtLSAlcyAtLT5cbiIsIG1zR2V0VmVy
c2lvbigpKTsNCiAgICAgIHByaW50ZigiPEJPRFkgQkdDT0xPUj1cIiNGRkZGRkZcIj5cbiIpOw0K
ICAgICAgbXNXcml0ZUVycm9yKHN0ZG91dCk7DQogICAgICBwcmludGYoIjwvQk9EWT48L0hUTUw+
Iik7DQogICAgfQ0KICB9DQoNCiAgLyoNCiAgKiogQ2xlYW4gVXANCiAgKi8NCiAgZnJlZShJdGVt
KTsNCiAgZnJlZShWYWx1ZSk7ICAgICAgDQogIGZyZWUoUXVlcnlGaWxlKTsNCiAgZnJlZShRdWVy
eUxheWVyKTsgICAgICANCiAgZnJlZShTZWxlY3RMYXllcik7DQoNCiAgbXNGcmVlTWFwU2Vydk9i
aihtc09iaik7DQoNCiAgZXhpdCgwKTsgLy8gYmFpbA0KfQ0KDQovKg0KKiogQ29udmVydHMgYSBz
dHJpbmcgKGUuZy4gZm9ybSBwYXJhbWV0ZXIpIHRvIGEgZG91YmxlLCBmaXJzdCBjaGVja2luZyB0
aGUgZm9ybWF0IGFnYWluc3QNCioqIGEgcmVndWxhciBleHByZXNzaW9uLiBEdW1wcyBhbiBlcnJv
ciBpbW1lZGlhdGVseSBpZiB0aGUgZm9ybWF0IHRlc3QgZmFpbHMuDQoqLw0Kc3RhdGljIGRvdWJs
ZSBnZXROdW1lcmljKHJlZ2V4X3QgcmUsIGNoYXIgKnMpDQp7DQogIHJlZ21hdGNoX3QgKm1hdGNo
Ow0KICANCiAgaWYoKG1hdGNoID0gKHJlZ21hdGNoX3QgKiltYWxsb2Moc2l6ZW9mKHJlZ21hdGNo
X3QpKSkgPT0gTlVMTCkgew0KICAgIG1zU2V0RXJyb3IoTVNfTUVNRVJSLCBOVUxMLCAiZ2V0TnVt
ZXJpYygpIik7DQogICAgd3JpdGVFcnJvcigpOw0KICB9DQogIA0KICBpZihyZWdleGVjKCZyZSwg
cywgKHNpemVfdCkxLCBtYXRjaCwgMCkgPT0gUkVHX05PTUFUQ0gpIHsNCiAgICBmcmVlKG1hdGNo
KTsNCiAgICBtc1NldEVycm9yKE1TX1RZUEVFUlIsIE5VTEwsICJnZXROdW1lcmljKCkiKTsgDQog
ICAgd3JpdGVFcnJvcigpOw0KICB9DQogIA0KICBpZihzdHJsZW4ocykgIT0gKG1hdGNoLT5ybV9l
byAtIG1hdGNoLT5ybV9zbykpIHsgLyogd2hvbGUgc3RyaW5nIG11c3QgbWF0Y2ggKi8gICAgDQog
ICAgZnJlZShtYXRjaCk7DQogICAgbXNTZXRFcnJvcihNU19UWVBFRVJSLCBOVUxMLCAiZ2V0TnVt
ZXJpYygpIik7IA0KICAgIHdyaXRlRXJyb3IoKTsNCiAgfQ0KICANCiAgZnJlZShtYXRjaCk7DQog
IHJldHVybihhdG9mKHMpKTsNCn0NCg0KLyoNCioqIEV4dHJhY3QgTWFwIEZpbGUgbmFtZSBmcm9t
IHBhcmFtcyBhbmQgbG9hZCBpdC4gIA0KKiogUmV0dXJucyBtYXAgb2JqZWN0IG9yIE5VTEwgb24g
ZXJyb3IuDQoqLw0KbWFwT2JqICpsb2FkTWFwKCkNCnsNCiAgaW50IGksaixrOw0KICBtYXBPYmog
Km1hcCA9IE5VTEw7DQogIGNoYXIgKnRtcHN0cjsNCg0KICBmb3IoaT0wO2k8bXNPYmotPk51bVBh
cmFtcztpKyspIC8vIGZpbmQgdGhlIG1hcGZpbGUgcGFyYW1ldGVyIGZpcnN0DQogICAgaWYoc3Ry
Y2FzZWNtcChtc09iai0+UGFyYW1OYW1lc1tpXSwgIm1hcCIpID09IDApIGJyZWFrOw0KICANCiAg
aWYoaSA9PSBtc09iai0+TnVtUGFyYW1zKSB7DQogICAgaWYoZ2V0ZW52KCJNU19NQVBGSUxFIikp
IC8vIGhhcyBhIGRlZmF1bHQgZmlsZSBoYXMgbm90IGJlZW4gc2V0DQogICAgICBtYXAgPSBtc0xv
YWRNYXAoZ2V0ZW52KCJNU19NQVBGSUxFIiksIE5VTEwpOw0KICAgIGVsc2Ugew0KICAgICAgbXNT
ZXRFcnJvcihNU19XRUJFUlIsICJDR0kgdmFyaWFibGUgXCJtYXBcIiBpcyBub3Qgc2V0LiIsICJs
b2FkTWFwKCkiKTsgLy8gbm8gZGVmYXVsdCwgb3V0dGEgaGVyZQ0KICAgICAgd3JpdGVFcnJvcigp
Ow0KICAgIH0NCiAgfSBlbHNlIHsNCiAgICBpZihnZXRlbnYobXNPYmotPlBhcmFtVmFsdWVzW2ld
KSkgLy8gYW4gZW52aXJvbm1lbnQgcmVmZXJlbmNlcyB0aGUgYWN0dWFsIGZpbGUgdG8gdXNlDQog
ICAgICBtYXAgPSBtc0xvYWRNYXAoZ2V0ZW52KG1zT2JqLT5QYXJhbVZhbHVlc1tpXSksIE5VTEwp
Ow0KICAgIGVsc2UNCiAgICAgIG1hcCA9IG1zTG9hZE1hcChtc09iai0+UGFyYW1WYWx1ZXNbaV0s
IE5VTEwpOw0KICB9DQoNCiAgaWYoIW1hcCkgd3JpdGVFcnJvcigpOw0KDQogIC8vIGNoZWNrIGZv
ciBhbnkgJXZhcmlhYmxlJSBzdWJzdGl0dXRpb25zIGhlcmUsIHdlIGRvIHRoaXMgaGVyZSBzbyBX
TVMvV0ZTIHNlcnZpY2VzIGNhbiB0YWtlIGFkdmFudGFnZSBvZiB0aGlzDQogIGZvcihpPTA7aTxt
c09iai0+TnVtUGFyYW1zO2krKykgew0KICAgIHRtcHN0ciA9IChjaGFyICopbWFsbG9jKHNpemVv
ZihjaGFyKSpzdHJsZW4obXNPYmotPlBhcmFtTmFtZXNbaV0pICsgMyk7DQogICAgc3ByaW50Zih0
bXBzdHIsIiUlJXMlJSIsIG1zT2JqLT5QYXJhbU5hbWVzW2ldKTsNCiAgICANCiAgICBmb3Ioaj0w
OyBqPG1hcC0+bnVtbGF5ZXJzOyBqKyspIHsNCiAgICAgIGlmKG1hcC0+bGF5ZXJzW2pdLmRhdGEg
JiYgKHN0cnN0cihtYXAtPmxheWVyc1tqXS5kYXRhLCB0bXBzdHIpICE9IE5VTEwpKSBtYXAtPmxh
eWVyc1tqXS5kYXRhID0gZ3N1YihtYXAtPmxheWVyc1tqXS5kYXRhLCB0bXBzdHIsIG1zT2JqLT5Q
YXJhbVZhbHVlc1tpXSk7DQogICAgICBpZihtYXAtPmxheWVyc1tqXS5jb25uZWN0aW9uICYmIChz
dHJzdHIobWFwLT5sYXllcnNbal0uY29ubmVjdGlvbiwgdG1wc3RyKSAhPSBOVUxMKSkgbWFwLT5s
YXllcnNbal0uY29ubmVjdGlvbiA9IGdzdWIobWFwLT5sYXllcnNbal0uY29ubmVjdGlvbiwgdG1w
c3RyLCBtc09iai0+UGFyYW1WYWx1ZXNbaV0pOw0KICAgICAgaWYobWFwLT5sYXllcnNbal0uZmls
dGVyLnN0cmluZyAmJiAoc3Ryc3RyKG1hcC0+bGF5ZXJzW2pdLmZpbHRlci5zdHJpbmcsIHRtcHN0
cikgIT0gTlVMTCkpIG1hcC0+bGF5ZXJzW2pdLmZpbHRlci5zdHJpbmcgPSBnc3ViKG1hcC0+bGF5
ZXJzW2pdLmZpbHRlci5zdHJpbmcsIHRtcHN0ciwgbXNPYmotPlBhcmFtVmFsdWVzW2ldKTsNCiAg
ICAgIGZvcihrPTA7IGs8bWFwLT5sYXllcnNbal0ubnVtY2xhc3NlczsgaysrKQ0KCWlmKG1hcC0+
bGF5ZXJzW2pdLmNsYXNzW2tdLmV4cHJlc3Npb24uc3RyaW5nICYmIChzdHJzdHIobWFwLT5sYXll
cnNbal0uY2xhc3Nba10uZXhwcmVzc2lvbi5zdHJpbmcsIHRtcHN0cikgIT0gTlVMTCkpIG1hcC0+
bGF5ZXJzW2pdLmNsYXNzW2tdLmV4cHJlc3Npb24uc3RyaW5nID0gZ3N1YihtYXAtPmxheWVyc1tq
XS5jbGFzc1trXS5leHByZXNzaW9uLnN0cmluZywgdG1wc3RyLCBtc09iai0+UGFyYW1WYWx1ZXNb
aV0pOw0KICAgIH0NCiAgICANCiAgICBmcmVlKHRtcHN0cik7DQogIH0NCg0KICByZXR1cm4gbWFw
Ow0KfQ0KDQovKg0KKiogUHJvY2VzcyBDR0kgcGFyYW1ldGVycy4NCiovDQp2b2lkIGxvYWRGb3Jt
KCkNCnsNCiAgaW50IGksaixuOw0KICBjaGFyICoqdG9rZW5zLCAqdG1wc3RyOw0KICByZWdleF90
IHJlOw0KICBpbnQgcm9zYV90eXBlPTA7DQoNCiAgaWYocmVnY29tcCgmcmUsIE5VTUVYUCwgUkVH
X0VYVEVOREVEKSAhPSAwKSB7IC8vIHdoYXQgaXMgYSBudW1iZXINCiAgICBtc1NldEVycm9yKE1T
X1JFR0VYRVJSLCBOVUxMLCAibG9hZEZvcm0oKSIpOyANCiAgICB3cml0ZUVycm9yKCk7DQogIH0N
Cg0KICBmb3IoaT0wO2k8bXNPYmotPk51bVBhcmFtcztpKyspIHsgLy8gbm93IHByb2Nlc3MgdGhl
IHJlc3Qgb2YgdGhlIGZvcm0gdmFyaWFibGVzDQogICAgaWYoc3RybGVuKG1zT2JqLT5QYXJhbVZh
bHVlc1tpXSkgPT0gMCkNCiAgICAgIGNvbnRpbnVlOw0KICAgIA0KICAgIGlmKHN0cmNhc2VjbXAo
bXNPYmotPlBhcmFtTmFtZXNbaV0sInF1ZXJ5ZmlsZSIpID09IDApIHsgICAgICANCiAgICAgIFF1
ZXJ5RmlsZSA9IHN0cmR1cChtc09iai0+UGFyYW1WYWx1ZXNbaV0pOw0KICAgICAgY29udGludWU7
DQogICAgfQ0KICAgIA0KICAgIGlmKHN0cmNhc2VjbXAobXNPYmotPlBhcmFtTmFtZXNbaV0sInNh
dmVxdWVyeSIpID09IDApIHsNCiAgICAgIG1zT2JqLT5TYXZlUXVlcnkgPSBNU19UUlVFOw0KICAg
ICAgY29udGludWU7DQogICAgfQ0KICAgIA0KICAgIC8qIEluc2VjdXJlIGFzIGltcGxlbWVudGVk
LCBuZWVkIHRvIHNhdmUgc29tZXBsYWNlIG5vbiBhY2Nlc3NpYmxlIGJ5IGV2ZXJ5b25lIGluIHRo
ZSB1bml2ZXJzZQ0KICAgICAgICBpZihzdHJjYXNlY21wKG1zT2JqLT5QYXJhbU5hbWVzW2ldLCJz
YXZlbWFwIikgPT0gMCkgeyAgICAgIA0KICAgICAgICAgbXNPYmotPlNhdmVNYXAgPSBNU19UUlVF
Ow0KICAgICAgICAgY29udGludWU7DQogICAgICAgIH0NCiAgICAqLw0KDQogICAgaWYoc3RyY2Fz
ZWNtcChtc09iai0+UGFyYW1OYW1lc1tpXSwiem9vbSIpID09IDApIHsNCiAgICAgIG1zT2JqLT5a
b29tID0gZ2V0TnVtZXJpYyhyZSwgbXNPYmotPlBhcmFtVmFsdWVzW2ldKTsgICAgICANCiAgICAg
IGlmKChtc09iai0+Wm9vbSA+IE1BWFpPT00pIHx8IChtc09iai0+Wm9vbSA8IE1JTlpPT00pKSB7
DQoJbXNTZXRFcnJvcihNU19XRUJFUlIsICJab29tIHZhbHVlIG91dCBvZiByYW5nZS4iLCAibG9h
ZEZvcm0oKSIpOw0KCXdyaXRlRXJyb3IoKTsNCiAgICAgIH0NCiAgICAgIGNvbnRpbnVlOw0KICAg
IH0NCg0KICAgIGlmKHN0cmNhc2VjbXAobXNPYmotPlBhcmFtTmFtZXNbaV0sInpvb21kaXIiKSA9
PSAwKSB7DQogICAgICBtc09iai0+Wm9vbURpcmVjdGlvbiA9IGdldE51bWVyaWMocmUsIG1zT2Jq
LT5QYXJhbVZhbHVlc1tpXSk7DQogICAgICBpZigobXNPYmotPlpvb21EaXJlY3Rpb24gIT0gLTEp
ICYmIChtc09iai0+Wm9vbURpcmVjdGlvbiAhPSAxKSAmJiAobXNPYmotPlpvb21EaXJlY3Rpb24g
IT0gMCkpIHsNCgltc1NldEVycm9yKE1TX1dFQkVSUiwgIlpvb20gZGlyZWN0aW9uIG11c3QgYmUg
MSwgMCBvciAtMS4iLCAibG9hZEZvcm0oKSIpOw0KCXdyaXRlRXJyb3IoKTsNCiAgICAgIH0NCiAg
ICAgIGNvbnRpbnVlOw0KICAgIH0NCg0KICAgIGlmKHN0cmNhc2VjbXAobXNPYmotPlBhcmFtTmFt
ZXNbaV0sInpvb21zaXplIikgPT0gMCkgeyAvLyBhYnNvbHV0ZSB6b29tIG1hZ25pdHVkZQ0KICAg
ICAgWm9vbVNpemUgPSBnZXROdW1lcmljKHJlLCBtc09iai0+UGFyYW1WYWx1ZXNbaV0pOyAgICAg
IA0KICAgICAgaWYoKFpvb21TaXplID4gTUFYWk9PTSkgfHwgKFpvb21TaXplIDwgMSkpIHsNCglt
c1NldEVycm9yKE1TX1dFQkVSUiwgIkludmFsaWQgem9vbSBzaXplLiIsICJsb2FkRm9ybSgpIik7
DQoJd3JpdGVFcnJvcigpOw0KICAgICAgfQkNCiAgICAgIGNvbnRpbnVlOw0KICAgIH0NCiAgICAN
CiAgICBpZihzdHJjYXNlY21wKG1zT2JqLT5QYXJhbU5hbWVzW2ldLCJpbWdleHQiKSA9PSAwKSB7
IC8vIGV4dGVudCBvZiBhbiBleGlzdGluZyBpbWFnZSBpbiBhIHdlYiBhcHBsaWNhdGlvbg0KICAg
ICAgdG9rZW5zID0gc3BsaXQobXNPYmotPlBhcmFtVmFsdWVzW2ldLCAnICcsICZuKTsNCg0KICAg
ICAgaWYoIXRva2Vucykgew0KCW1zU2V0RXJyb3IoTVNfTUVNRVJSLCBOVUxMLCAibG9hZEZvcm0o
KSIpOw0KCXdyaXRlRXJyb3IoKTsNCiAgICAgIH0NCg0KICAgICAgaWYobiAhPSA0KSB7DQoJbXNT
ZXRFcnJvcihNU19XRUJFUlIsICJOb3QgZW5vdWdoIGFyZ3VtZW50cyBmb3IgaW1nZXh0LiIsICJs
b2FkRm9ybSgpIik7DQoJd3JpdGVFcnJvcigpOw0KICAgICAgfQ0KDQogICAgICBtc09iai0+SW1n
RXh0Lm1pbnggPSBnZXROdW1lcmljKHJlLCB0b2tlbnNbMF0pOw0KICAgICAgbXNPYmotPkltZ0V4
dC5taW55ID0gZ2V0TnVtZXJpYyhyZSwgdG9rZW5zWzFdKTsNCiAgICAgIG1zT2JqLT5JbWdFeHQu
bWF4eCA9IGdldE51bWVyaWMocmUsIHRva2Vuc1syXSk7DQogICAgICBtc09iai0+SW1nRXh0Lm1h
eHkgPSBnZXROdW1lcmljKHJlLCB0b2tlbnNbM10pOw0KDQogICAgICBtc0ZyZWVDaGFyQXJyYXko
dG9rZW5zLCA0KTsNCiAgICAgIGNvbnRpbnVlOw0KICAgIH0NCg0KICAgIGlmKHN0cmNhc2VjbXAo
bXNPYmotPlBhcmFtTmFtZXNbaV0sInNlYXJjaG1hcCIpID09IDApIHsgICAgICANCiAgICAgIFNl
YXJjaE1hcCA9IE1TX1RSVUU7DQogICAgICBjb250aW51ZTsNCiAgICB9DQoNCiAgICBpZihzdHJj
YXNlY21wKG1zT2JqLT5QYXJhbU5hbWVzW2ldLCJpZCIpID09IDApIHsNCiAgICAgIHN0cm5jcHko
bXNPYmotPklkLCBtc09iai0+UGFyYW1WYWx1ZXNbaV0sIElEU0laRSk7DQogICAgICBjb250aW51
ZTsNCiAgICB9DQoNCiAgICBpZihzdHJjYXNlY21wKG1zT2JqLT5QYXJhbU5hbWVzW2ldLCJtYXBl
eHQiKSA9PSAwKSB7IC8vIGV4dGVudCBvZiB0aGUgbmV3IG1hcCBvciBxdWVyeQ0KDQogICAgICBp
ZihzdHJuY2FzZWNtcChtc09iai0+UGFyYW1WYWx1ZXNbaV0sInNoYXBlIiw1KSA9PSAwKQ0KICAg
ICAgICBtc09iai0+VXNlU2hhcGVzID0gTVNfVFJVRTsNCiAgICAgIGVsc2Ugew0KCXRva2VucyA9
IHNwbGl0KG1zT2JqLT5QYXJhbVZhbHVlc1tpXSwgJyAnLCAmbik7DQoJDQoJaWYoIXRva2Vucykg
ew0KCSAgbXNTZXRFcnJvcihNU19NRU1FUlIsIE5VTEwsICJsb2FkRm9ybSgpIik7DQoJICB3cml0
ZUVycm9yKCk7DQoJfQ0KCQ0KCWlmKG4gIT0gNCkgew0KCSAgbXNTZXRFcnJvcihNU19XRUJFUlIs
ICJOb3QgZW5vdWdoIGFyZ3VtZW50cyBmb3IgbWFwZXh0LiIsICJsb2FkRm9ybSgpIik7DQoJICB3
cml0ZUVycm9yKCk7DQoJfQ0KCQ0KCW1zT2JqLT5NYXAtPmV4dGVudC5taW54ID0gZ2V0TnVtZXJp
YyhyZSwgdG9rZW5zWzBdKTsNCgltc09iai0+TWFwLT5leHRlbnQubWlueSA9IGdldE51bWVyaWMo
cmUsIHRva2Vuc1sxXSk7DQoJbXNPYmotPk1hcC0+ZXh0ZW50Lm1heHggPSBnZXROdW1lcmljKHJl
LCB0b2tlbnNbMl0pOw0KCW1zT2JqLT5NYXAtPmV4dGVudC5tYXh5ID0gZ2V0TnVtZXJpYyhyZSwg
dG9rZW5zWzNdKTsJDQoJDQoJbXNGcmVlQ2hhckFycmF5KHRva2VucywgNCk7DQoJDQojaWZkZWYg
VVNFX1BST0oNCglpZihtc09iai0+TWFwLT5wcm9qZWN0aW9uLnByb2ogJiYgIXBqX2lzX2xhdGxv
bmcobXNPYmotPk1hcC0+cHJvamVjdGlvbi5wcm9qKQ0KICAgICAgICAgICAmJiAobXNPYmotPk1h
cC0+ZXh0ZW50Lm1pbnggPj0gLTE4MC4wICYmIG1zT2JqLT5NYXAtPmV4dGVudC5taW54IDw9IDE4
MC4wKSANCiAgICAgICAgICAgJiYgKG1zT2JqLT5NYXAtPmV4dGVudC5taW55ID49IC05MC4wICYm
IG1zT2JqLT5NYXAtPmV4dGVudC5taW55IDw9IDkwLjApKQ0KCSAgbXNQcm9qZWN0UmVjdCgmKG1z
T2JqLT5NYXAtPmxhdGxvbiksIA0KICAgICAgICAgICAgICAgICAgICAgICAgJihtc09iai0+TWFw
LT5wcm9qZWN0aW9uKSwgDQogICAgICAgICAgICAgICAgICAgICAgICAmKG1zT2JqLT5NYXAtPmV4
dGVudCkpOyAvLyBleHRlbnQgaXMgYSBpbiBsYXQvbG9uDQojZW5kaWYNCg0KCWlmKChtc09iai0+
TWFwLT5leHRlbnQubWlueCAhPSBtc09iai0+TWFwLT5leHRlbnQubWF4eCkgJiYgKG1zT2JqLT5N
YXAtPmV4dGVudC5taW55ICE9IG1zT2JqLT5NYXAtPmV4dGVudC5tYXh5KSkgeyAvLyBleHRlbnQg
c2VlbXMgb2sNCgkgIG1zT2JqLT5Db29yZFNvdXJjZSA9IEZST01VU0VSQk9YOw0KCSAgUXVlcnlD
b29yZFNvdXJjZSA9IEZST01VU0VSQk9YOw0KCX0NCiAgICAgIH0NCg0KICAgICAgY29udGludWU7
DQogICAgfQ0KDQogICAgaWYoc3RyY2FzZWNtcChtc09iai0+UGFyYW1OYW1lc1tpXSwibWlueCIp
ID09IDApIHsgLy8gZXh0ZW50IG9mIHRoZSBuZXcgbWFwLCBpbiBwaWVjZXMNCiAgICAgIG1zT2Jq
LT5NYXAtPmV4dGVudC5taW54ID0gZ2V0TnVtZXJpYyhyZSwgbXNPYmotPlBhcmFtVmFsdWVzW2ld
KTsgICAgICANCiAgICAgIGNvbnRpbnVlOw0KICAgIH0NCiAgICBpZihzdHJjYXNlY21wKG1zT2Jq
LT5QYXJhbU5hbWVzW2ldLCJtYXh4IikgPT0gMCkgeyAgICAgIA0KICAgICAgbXNPYmotPk1hcC0+
ZXh0ZW50Lm1heHggPSBnZXROdW1lcmljKHJlLCBtc09iai0+UGFyYW1WYWx1ZXNbaV0pOw0KICAg
ICAgY29udGludWU7DQogICAgfQ0KICAgIGlmKHN0cmNhc2VjbXAobXNPYmotPlBhcmFtTmFtZXNb
aV0sIm1pbnkiKSA9PSAwKSB7DQogICAgICBtc09iai0+TWFwLT5leHRlbnQubWlueSA9IGdldE51
bWVyaWMocmUsIG1zT2JqLT5QYXJhbVZhbHVlc1tpXSk7DQogICAgICBjb250aW51ZTsNCiAgICB9
DQogICAgaWYoc3RyY2FzZWNtcChtc09iai0+UGFyYW1OYW1lc1tpXSwibWF4eSIpID09IDApIHsN
CiAgICAgIG1zT2JqLT5NYXAtPmV4dGVudC5tYXh5ID0gZ2V0TnVtZXJpYyhyZSwgbXNPYmotPlBh
cmFtVmFsdWVzW2ldKTsNCiAgICAgIG1zT2JqLT5Db29yZFNvdXJjZSA9IEZST01VU0VSQk9YOw0K
ICAgICAgUXVlcnlDb29yZFNvdXJjZSA9IEZST01VU0VSQk9YOw0KICAgICAgY29udGludWU7DQog
ICAgfSANCg0KICAgIGlmKHN0cmNhc2VjbXAobXNPYmotPlBhcmFtTmFtZXNbaV0sIm1hcHh5Iikg
PT0gMCkgeyAvLyB1c2VyIG1hcCBjb29yZGluYXRlDQogICAgICANCiAgICAgIGlmKHN0cm5jYXNl
Y21wKG1zT2JqLT5QYXJhbVZhbHVlc1tpXSwic2hhcGUiLDUpID09IDApIHsNCiAgICAgICAgbXNP
YmotPlVzZVNoYXBlcyA9IE1TX1RSVUU7CQ0KICAgICAgfSBlbHNlIHsNCgl0b2tlbnMgPSBzcGxp
dChtc09iai0+UGFyYW1WYWx1ZXNbaV0sICcgJywgJm4pOw0KDQoJaWYoIXRva2Vucykgew0KCSAg
bXNTZXRFcnJvcihNU19NRU1FUlIsIE5VTEwsICJsb2FkRm9ybSgpIik7DQoJICB3cml0ZUVycm9y
KCk7DQoJfQ0KCQ0KCWlmKG4gIT0gMikgew0KCSAgbXNTZXRFcnJvcihNU19XRUJFUlIsICJOb3Qg
ZW5vdWdoIGFyZ3VtZW50cyBmb3IgbWFweHkuIiwgImxvYWRGb3JtKCkiKTsNCgkgIHdyaXRlRXJy
b3IoKTsNCgl9DQoJDQoJbXNPYmotPk1hcFBudC54ID0gZ2V0TnVtZXJpYyhyZSwgdG9rZW5zWzBd
KTsNCgltc09iai0+TWFwUG50LnkgPSBnZXROdW1lcmljKHJlLCB0b2tlbnNbMV0pOw0KCQ0KCW1z
RnJlZUNoYXJBcnJheSh0b2tlbnMsIDIpOw0KDQojaWZkZWYgVVNFX1BST0oNCglpZihtc09iai0+
TWFwLT5wcm9qZWN0aW9uLnByb2ogJiYgIXBqX2lzX2xhdGxvbmcobXNPYmotPk1hcC0+cHJvamVj
dGlvbi5wcm9qKQ0KICAgICAgICAgICAmJiAobXNPYmotPk1hcFBudC54ID49IC0xODAuMCAmJiBt
c09iai0+TWFwUG50LnggPD0gMTgwLjApIA0KICAgICAgICAgICAmJiAobXNPYmotPk1hcFBudC55
ID49IC05MC4wICYmIG1zT2JqLT5NYXBQbnQueSA8PSA5MC4wKSkNCgkgIG1zUHJvamVjdFBvaW50
KCYobXNPYmotPk1hcC0+cHJvamVjdGlvbiksIA0KICAgICAgICAgICAgICAgICAgICAgICAgICYo
bXNPYmotPk1hcC0+cHJvamVjdGlvbiksIA0KICAgICAgICAgICAgICAgICAgICAgICAgICZtc09i
ai0+TWFwUG50KTsgLy8gcG9pbnQgaXMgYSBpbiBsYXQvbG9uDQojZW5kaWYNCg0KCWlmKG1zT2Jq
LT5Db29yZFNvdXJjZSA9PSBOT05FKSB7IC8vIGRvbid0IG92ZXJyaWRlIHByZXZpb3VzIHNldHRp
bmdzIChpLmUuIGJ1ZmZlciBvciBzY2FsZSApDQoJICBtc09iai0+Q29vcmRTb3VyY2UgPSBGUk9N
VVNFUlBOVDsNCgkgIFF1ZXJ5Q29vcmRTb3VyY2UgPSBGUk9NVVNFUlBOVDsNCgl9DQogICAgICB9
DQogICAgICBjb250aW51ZTsNCiAgICB9DQoNCiAgICBpZihzdHJjYXNlY21wKG1zT2JqLT5QYXJh
bU5hbWVzW2ldLCJtYXBzaGFwZSIpID09IDApIHsgLy8gcXVlcnkgc2hhcGUNCiAgICAgIGxpbmVP
YmogbGluZT17MCxOVUxMfTsNCiAgICAgIGNoYXIgKip0bXA9TlVMTDsNCiAgICAgIGludCBuLCBq
Ow0KICAgICAgDQogICAgICB0bXAgPSBzcGxpdChtc09iai0+UGFyYW1WYWx1ZXNbaV0sICcgJywg
Jm4pOw0KDQogICAgICBpZigobGluZS5wb2ludCA9IChwb2ludE9iaiAqKW1hbGxvYyhzaXplb2Yo
cG9pbnRPYmopKihuLzIpKSkgPT0gTlVMTCkgew0KCW1zU2V0RXJyb3IoTVNfTUVNRVJSLCBOVUxM
LCAibG9hZEZvcm0oKSIpOw0KCXdyaXRlRXJyb3IoKTsNCiAgICAgIH0NCiAgICAgIGxpbmUubnVt
cG9pbnRzID0gbi8yOw0KDQogICAgICBtc0luaXRTaGFwZSgmKG1zT2JqLT5TZWxlY3RTaGFwZSkp
Ow0KICAgICAgbXNPYmotPlNlbGVjdFNoYXBlLnR5cGUgPSBNU19TSEFQRV9QT0xZR09OOw0KDQog
ICAgICBmb3Ioaj0wOyBqPG4vMjsgaisrKSB7DQoJbGluZS5wb2ludFtqXS54ID0gYXRvZih0bXBb
MipqXSk7DQoJbGluZS5wb2ludFtqXS55ID0gYXRvZih0bXBbMipqKzFdKTsNCg0KI2lmZGVmIFVT
RV9QUk9KDQoJaWYobXNPYmotPk1hcC0+cHJvamVjdGlvbi5wcm9qICYmICFwal9pc19sYXRsb25n
KG1zT2JqLT5NYXAtPnByb2plY3Rpb24ucHJvaikNCiAgICAgICAgICAgJiYgKGxpbmUucG9pbnRb
al0ueCA+PSAtMTgwLjAgJiYgbGluZS5wb2ludFtqXS54IDw9IDE4MC4wKSANCiAgICAgICAgICAg
JiYgKGxpbmUucG9pbnRbal0ueSA+PSAtOTAuMCAmJiBsaW5lLnBvaW50W2pdLnkgPD0gOTAuMCkp
DQoJICBtc1Byb2plY3RQb2ludCgmKG1zT2JqLT5NYXAtPmxhdGxvbiksIA0KICAgICAgICAgICAg
ICAgICAgICAgICAgICYobXNPYmotPk1hcC0+cHJvamVjdGlvbiksIA0KICAgICAgICAgICAgICAg
ICAgICAgICAgICZsaW5lLnBvaW50W2pdKTsgLy8gcG9pbnQgaXMgYSBpbiBsYXQvbG9uDQojZW5k
aWYNCiAgICAgIH0NCg0KICAgICAgaWYobXNBZGRMaW5lKCZtc09iai0+U2VsZWN0U2hhcGUsICZs
aW5lKSA9PSAtMSkgd3JpdGVFcnJvcigpOw0KDQogICAgICBtc0ZyZWUobGluZS5wb2ludCk7CQ0K
ICAgICAgbXNGcmVlQ2hhckFycmF5KHRtcCwgbik7DQoNCiAgICAgIFF1ZXJ5Q29vcmRTb3VyY2Ug
PSBGUk9NVVNFUlNIQVBFOw0KICAgICAgY29udGludWU7DQogICAgfQ0KDQogICAgaWYoc3RyY2Fz
ZWNtcChtc09iai0+UGFyYW1OYW1lc1tpXSwiaW1nLngiKSA9PSAwKSB7IC8vIG1vdXNlIGNsaWNr
LCBpbiBwaWVjZXMNCiAgICAgIG1zT2JqLT5JbWdQbnQueCA9IGdldE51bWVyaWMocmUsIG1zT2Jq
LT5QYXJhbVZhbHVlc1tpXSk7DQogICAgICBpZigobXNPYmotPkltZ1BudC54ID4gKDIqTVNfTUFY
SU1HU0laRSkpIHx8IChtc09iai0+SW1nUG50LnggPCAoLTIqTVNfTUFYSU1HU0laRSkpKSB7DQoJ
bXNTZXRFcnJvcihNU19XRUJFUlIsICJDb29yZGluYXRlIG91dCBvZiByYW5nZS4iLCAibG9hZEZv
cm0oKSIpOw0KCXdyaXRlRXJyb3IoKTsNCiAgICAgIH0NCiAgICAgIG1zT2JqLT5Db29yZFNvdXJj
ZSA9IEZST01JTUdQTlQ7DQogICAgICBRdWVyeUNvb3JkU291cmNlID0gRlJPTUlNR1BOVDsNCiAg
ICAgIGNvbnRpbnVlOw0KICAgIH0NCiAgICBpZihzdHJjYXNlY21wKG1zT2JqLT5QYXJhbU5hbWVz
W2ldLCJpbWcueSIpID09IDApIHsNCiAgICAgIG1zT2JqLT5JbWdQbnQueSA9IGdldE51bWVyaWMo
cmUsIG1zT2JqLT5QYXJhbVZhbHVlc1tpXSk7ICAgICAgDQogICAgICBpZigobXNPYmotPkltZ1Bu
dC55ID4gKDIqTVNfTUFYSU1HU0laRSkpIHx8IChtc09iai0+SW1nUG50LnkgPCAoLTIqTVNfTUFY
SU1HU0laRSkpKSB7DQoJbXNTZXRFcnJvcihNU19XRUJFUlIsICJDb29yZGluYXRlIG91dCBvZiBy
YW5nZS4iLCAibG9hZEZvcm0oKSIpOw0KCXdyaXRlRXJyb3IoKTsNCiAgICAgIH0NCiAgICAgIG1z
T2JqLT5Db29yZFNvdXJjZSA9IEZST01JTUdQTlQ7DQogICAgICBRdWVyeUNvb3JkU291cmNlID0g
RlJPTUlNR1BOVDsNCiAgICAgIGNvbnRpbnVlOw0KICAgIH0NCg0KICAgIGlmKHN0cmNhc2VjbXAo
bXNPYmotPlBhcmFtTmFtZXNbaV0sImltZ3h5IikgPT0gMCkgeyAvLyBtb3VzZSBjbGljaywgc2lu
Z2xlIHZhcmlhYmxlDQogICAgICBpZihtc09iai0+Q29vcmRTb3VyY2UgPT0gRlJPTUlNR1BOVCkN
Cgljb250aW51ZTsNCg0KICAgICAgdG9rZW5zID0gc3BsaXQobXNPYmotPlBhcmFtVmFsdWVzW2ld
LCAnICcsICZuKTsNCg0KICAgICAgaWYoIXRva2Vucykgew0KCW1zU2V0RXJyb3IoTVNfTUVNRVJS
LCBOVUxMLCAibG9hZEZvcm0oKSIpOw0KCXdyaXRlRXJyb3IoKTsNCiAgICAgIH0NCg0KICAgICAg
aWYobiAhPSAyKSB7DQoJbXNTZXRFcnJvcihNU19XRUJFUlIsICJOb3QgZW5vdWdoIGFyZ3VtZW50
cyBmb3IgaW1neHkuIiwgImxvYWRGb3JtKCkiKTsNCgl3cml0ZUVycm9yKCk7DQogICAgICB9DQoN
CiAgICAgIG1zT2JqLT5JbWdQbnQueCA9IGdldE51bWVyaWMocmUsIHRva2Vuc1swXSk7DQogICAg
ICBtc09iai0+SW1nUG50LnkgPSBnZXROdW1lcmljKHJlLCB0b2tlbnNbMV0pOw0KDQogICAgICBt
c0ZyZWVDaGFyQXJyYXkodG9rZW5zLCAyKTsNCg0KICAgICAgaWYoKG1zT2JqLT5JbWdQbnQueCA+
ICgyKk1TX01BWElNR1NJWkUpKSB8fCAobXNPYmotPkltZ1BudC54IDwgKC0yKk1TX01BWElNR1NJ
WkUpKSB8fCAobXNPYmotPkltZ1BudC55ID4gKDIqTVNfTUFYSU1HU0laRSkpIHx8IChtc09iai0+
SW1nUG50LnkgPCAoLTIqTVNfTUFYSU1HU0laRSkpKSB7DQoJbXNTZXRFcnJvcihNU19XRUJFUlIs
ICJSZWZlcmVuY2UgbWFwIGNvb3JkaW5hdGUgb3V0IG9mIHJhbmdlLiIsICJsb2FkRm9ybSgpIik7
DQoJd3JpdGVFcnJvcigpOw0KICAgICAgfQ0KDQogICAgICBpZihtc09iai0+Q29vcmRTb3VyY2Ug
PT0gTk9ORSkgeyAvLyBvdmVycmlkZSBub3RoaW5nIHNpbmNlIHRoaXMgcGFyYW1ldGVyIGlzIHVz
dWFsbHkgdXNlZCB0byBob2xkIGEgZGVmYXVsdCB2YWx1ZQ0KCW1zT2JqLT5Db29yZFNvdXJjZSA9
IEZST01JTUdQTlQ7DQoJUXVlcnlDb29yZFNvdXJjZSA9IEZST01JTUdQTlQ7DQogICAgICB9DQog
ICAgICBjb250aW51ZTsNCiAgICB9DQoNCiAgICBpZihzdHJjYXNlY21wKG1zT2JqLT5QYXJhbU5h
bWVzW2ldLCJpbWdib3giKSA9PSAwKSB7IC8vIHNlbGVjdGlvbiBib3ggKGVnLiBtb3VzZSBkcmFn
KQ0KICAgICAgdG9rZW5zID0gc3BsaXQobXNPYmotPlBhcmFtVmFsdWVzW2ldLCAnICcsICZuKTsN
CiAgICAgIA0KICAgICAgaWYoIXRva2Vucykgew0KCW1zU2V0RXJyb3IoTVNfTUVNRVJSLCBOVUxM
LCAibG9hZEZvcm0oKSIpOw0KCXdyaXRlRXJyb3IoKTsNCiAgICAgIH0NCiAgICAgIA0KICAgICAg
aWYobiAhPSA0KSB7DQoJbXNTZXRFcnJvcihNU19XRUJFUlIsICJOb3QgZW5vdWdoIGFyZ3VtZW50
cyBmb3IgaW1nYm94LiIsICJsb2FkRm9ybSgpIik7DQoJd3JpdGVFcnJvcigpOw0KICAgICAgfQ0K
ICAgICAgDQogICAgICBtc09iai0+SW1nQm94Lm1pbnggPSBnZXROdW1lcmljKHJlLCB0b2tlbnNb
MF0pOw0KICAgICAgbXNPYmotPkltZ0JveC5taW55ID0gZ2V0TnVtZXJpYyhyZSwgdG9rZW5zWzFd
KTsNCiAgICAgIG1zT2JqLT5JbWdCb3gubWF4eCA9IGdldE51bWVyaWMocmUsIHRva2Vuc1syXSk7
DQogICAgICBtc09iai0+SW1nQm94Lm1heHkgPSBnZXROdW1lcmljKHJlLCB0b2tlbnNbM10pOw0K
ICAgICAgDQogICAgICBtc0ZyZWVDaGFyQXJyYXkodG9rZW5zLCA0KTsNCg0KICAgICAgaWYoKG1z
T2JqLT5JbWdCb3gubWlueCAhPSBtc09iai0+SW1nQm94Lm1heHgpICYmIChtc09iai0+SW1nQm94
Lm1pbnkgIT0gbXNPYmotPkltZ0JveC5tYXh5KSkgeyAvLyBtdXN0IG5vdCBkZWdlbmVyYXRlIGlu
dG8gYSBwb2ludA0KCW1zT2JqLT5Db29yZFNvdXJjZSA9IEZST01JTUdCT1g7DQoJUXVlcnlDb29y
ZFNvdXJjZSA9IEZST01JTUdCT1g7DQogICAgICB9DQogICAgICBjb250aW51ZTsNCiAgICB9DQoN
CiAgICBpZihzdHJjYXNlY21wKG1zT2JqLT5QYXJhbU5hbWVzW2ldLCJpbWdzaGFwZSIpID09IDAp
IHsgLy8gc2hhcGUgZ2l2ZW4gaW4gaW1hZ2UgY29vcmRpbmF0ZXMNCiAgICAgIGxpbmVPYmogbGlu
ZT17MCxOVUxMfTsNCiAgICAgIGNoYXIgKip0bXA9TlVMTDsNCiAgICAgIGludCBuLCBqOw0KICAg
ICAgDQogICAgICB0bXAgPSBzcGxpdChtc09iai0+UGFyYW1WYWx1ZXNbaV0sICcgJywgJm4pOw0K
DQogICAgICBpZigobGluZS5wb2ludCA9IChwb2ludE9iaiAqKW1hbGxvYyhzaXplb2YocG9pbnRP
YmopKihuLzIpKSkgPT0gTlVMTCkgew0KCW1zU2V0RXJyb3IoTVNfTUVNRVJSLCBOVUxMLCAibG9h
ZEZvcm0oKSIpOw0KCXdyaXRlRXJyb3IoKTsNCiAgICAgIH0NCiAgICAgIGxpbmUubnVtcG9pbnRz
ID0gbi8yOw0KDQogICAgICBtc0luaXRTaGFwZSgmbXNPYmotPlNlbGVjdFNoYXBlKTsNCiAgICAg
IG1zT2JqLT5TZWxlY3RTaGFwZS50eXBlID0gTVNfU0hBUEVfUE9MWUdPTjsNCg0KICAgICAgZm9y
KGo9MDsgajxuLzI7IGorKykgew0KCWxpbmUucG9pbnRbal0ueCA9IGF0b2YodG1wWzIqal0pOw0K
CWxpbmUucG9pbnRbal0ueSA9IGF0b2YodG1wWzIqaisxXSk7DQogICAgICB9DQoNCiAgICAgIGlm
KG1zQWRkTGluZSgmbXNPYmotPlNlbGVjdFNoYXBlLCAmbGluZSkgPT0gLTEpIHdyaXRlRXJyb3Io
KTsNCg0KICAgICAgbXNGcmVlKGxpbmUucG9pbnQpOw0KICAgICAgbXNGcmVlQ2hhckFycmF5KHRt
cCwgbik7DQoNCiAgICAgIFF1ZXJ5Q29vcmRTb3VyY2UgPSBGUk9NSU1HU0hBUEU7DQogICAgICBj
b250aW51ZTsNCiAgICB9DQoNCiAgICBpZihzdHJjYXNlY21wKG1zT2JqLT5QYXJhbU5hbWVzW2ld
LCJyZWYueCIpID09IDApIHsgLy8gbW91c2UgY2xpY2sgaW4gcmVmZXJlbmNlIGltYWdlLCBpbiBw
aWVjZXMNCiAgICAgIG1zT2JqLT5SZWZQbnQueCA9IGdldE51bWVyaWMocmUsIG1zT2JqLT5QYXJh
bVZhbHVlc1tpXSk7ICAgICAgDQogICAgICBpZigobXNPYmotPlJlZlBudC54ID4gKDIqTVNfTUFY
SU1HU0laRSkpIHx8IChtc09iai0+UmVmUG50LnggPCAoLTIqTVNfTUFYSU1HU0laRSkpKSB7DQoJ
bXNTZXRFcnJvcihNU19XRUJFUlIsICJDb29yZGluYXRlIG91dCBvZiByYW5nZS4iLCAibG9hZEZv
cm0oKSIpOw0KCXdyaXRlRXJyb3IoKTsNCiAgICAgIH0NCiAgICAgIG1zT2JqLT5Db29yZFNvdXJj
ZSA9IEZST01SRUZQTlQ7DQogICAgICBjb250aW51ZTsNCiAgICB9DQogICAgaWYoc3RyY2FzZWNt
cChtc09iai0+UGFyYW1OYW1lc1tpXSwicmVmLnkiKSA9PSAwKSB7DQogICAgICBtc09iai0+UmVm
UG50LnkgPSBnZXROdW1lcmljKHJlLCBtc09iai0+UGFyYW1WYWx1ZXNbaV0pOyANCiAgICAgIGlm
KChtc09iai0+UmVmUG50LnkgPiAoMipNU19NQVhJTUdTSVpFKSkgfHwgKG1zT2JqLT5SZWZQbnQu
eSA8ICgtMipNU19NQVhJTUdTSVpFKSkpIHsNCgltc1NldEVycm9yKE1TX1dFQkVSUiwgIkNvb3Jk
aW5hdGUgb3V0IG9mIHJhbmdlLiIsICJsb2FkRm9ybSgpIik7DQoJd3JpdGVFcnJvcigpOw0KICAg
ICAgfQ0KICAgICAgbXNPYmotPkNvb3JkU291cmNlID0gRlJPTVJFRlBOVDsNCiAgICAgIGNvbnRp
bnVlOw0KICAgIH0NCg0KICAgIGlmKHN0cmNhc2VjbXAobXNPYmotPlBhcmFtTmFtZXNbaV0sInJl
Znh5IikgPT0gMCkgeyAvKiBtb3VzZSBjbGljayBpbiByZWZlcmVuY2UgaW1hZ2UsIHNpbmdsZSB2
YXJpYWJsZSAqLw0KICAgICAgdG9rZW5zID0gc3BsaXQobXNPYmotPlBhcmFtVmFsdWVzW2ldLCAn
ICcsICZuKTsNCg0KICAgICAgaWYoIXRva2Vucykgew0KCW1zU2V0RXJyb3IoTVNfTUVNRVJSLCBO
VUxMLCAibG9hZEZvcm0oKSIpOw0KCXdyaXRlRXJyb3IoKTsNCiAgICAgIH0NCg0KICAgICAgaWYo
biAhPSAyKSB7DQoJbXNTZXRFcnJvcihNU19XRUJFUlIsICJOb3QgZW5vdWdoIGFyZ3VtZW50cyBm
b3IgaW1neHkuIiwgImxvYWRGb3JtKCkiKTsNCgl3cml0ZUVycm9yKCk7DQogICAgICB9DQoNCiAg
ICAgIG1zT2JqLT5SZWZQbnQueCA9IGdldE51bWVyaWMocmUsIHRva2Vuc1swXSk7DQogICAgICBt
c09iai0+UmVmUG50LnkgPSBnZXROdW1lcmljKHJlLCB0b2tlbnNbMV0pOw0KDQogICAgICBtc0Zy
ZWVDaGFyQXJyYXkodG9rZW5zLCAyKTsNCiAgICAgIA0KICAgICAgaWYoKG1zT2JqLT5SZWZQbnQu
eCA+ICgyKk1TX01BWElNR1NJWkUpKSB8fCAobXNPYmotPlJlZlBudC54IDwgKC0yKk1TX01BWElN
R1NJWkUpKSB8fCAobXNPYmotPlJlZlBudC55ID4gKDIqTVNfTUFYSU1HU0laRSkpIHx8IChtc09i
ai0+UmVmUG50LnkgPCAoLTIqTVNfTUFYSU1HU0laRSkpKSB7DQoJbXNTZXRFcnJvcihNU19XRUJF
UlIsICJSZWZlcmVuY2UgbWFwIGNvb3JkaW5hdGUgb3V0IG9mIHJhbmdlLiIsICJsb2FkRm9ybSgp
Iik7DQoJd3JpdGVFcnJvcigpOw0KICAgICAgfQ0KICAgICAgDQogICAgICBtc09iai0+Q29vcmRT
b3VyY2UgPSBGUk9NUkVGUE5UOw0KICAgICAgY29udGludWU7DQogICAgfQ0KDQogICAgaWYoc3Ry
Y2FzZWNtcChtc09iai0+UGFyYW1OYW1lc1tpXSwiYnVmZmVyIikgPT0gMCkgeyAvLyByYWRpdXMg
KG1hcCB1bml0cyksIGFjdHVhbGx5IDEvMiBzcXVhcmUgc2lkZQ0KICAgICAgbXNPYmotPkJ1ZmZl
ciA9IGdldE51bWVyaWMocmUsIG1zT2JqLT5QYXJhbVZhbHVlc1tpXSk7ICAgICAgDQogICAgICBt
c09iai0+Q29vcmRTb3VyY2UgPSBGUk9NQlVGOw0KICAgICAgUXVlcnlDb29yZFNvdXJjZSA9IEZS
T01VU0VSUE5UOw0KICAgICAgY29udGludWU7DQogICAgfQ0KDQogICAgaWYoc3RyY2FzZWNtcCht
c09iai0+UGFyYW1OYW1lc1tpXSwic2NhbGUiKSA9PSAwKSB7IC8vIHNjYWxlIGZvciBuZXcgbWFw
DQogICAgICBtc09iai0+U2NhbGUgPSBnZXROdW1lcmljKHJlLCBtc09iai0+UGFyYW1WYWx1ZXNb
aV0pOyAgICAgIA0KICAgICAgaWYobXNPYmotPlNjYWxlIDw9IDApIHsNCgltc1NldEVycm9yKE1T
X1dFQkVSUiwgIlNjYWxlIG91dCBvZiByYW5nZS4iLCAibG9hZEZvcm0oKSIpOw0KCXdyaXRlRXJy
b3IoKTsNCiAgICAgIH0NCiAgICAgIG1zT2JqLT5Db29yZFNvdXJjZSA9IEZST01TQ0FMRTsNCiAg
ICAgIFF1ZXJ5Q29vcmRTb3VyY2UgPSBGUk9NVVNFUlBOVDsNCiAgICAgIGNvbnRpbnVlOw0KICAg
IH0NCiAgICANCiAgICBpZihzdHJjYXNlY21wKG1zT2JqLT5QYXJhbU5hbWVzW2ldLCJpbWdzaXpl
IikgPT0gMCkgeyAvLyBzaXplIG9mIGV4aXN0aW5nIGltYWdlIChwaXhlbHMpDQogICAgICB0b2tl
bnMgPSBzcGxpdChtc09iai0+UGFyYW1WYWx1ZXNbaV0sICcgJywgJm4pOw0KDQogICAgICBpZigh
dG9rZW5zKSB7DQoJbXNTZXRFcnJvcihNU19NRU1FUlIsIE5VTEwsICJsb2FkRm9ybSgpIik7DQoJ
d3JpdGVFcnJvcigpOw0KICAgICAgfQ0KDQogICAgICBpZihuICE9IDIpIHsNCgltc1NldEVycm9y
KE1TX1dFQkVSUiwgIk5vdCBlbm91Z2ggYXJndW1lbnRzIGZvciBpbWdzaXplLiIsICJsb2FkRm9y
bSgpIik7DQoJd3JpdGVFcnJvcigpOw0KICAgICAgfQ0KDQogICAgICBtc09iai0+SW1nQ29scyA9
IGdldE51bWVyaWMocmUsIHRva2Vuc1swXSk7DQogICAgICBtc09iai0+SW1nUm93cyA9IGdldE51
bWVyaWMocmUsIHRva2Vuc1sxXSk7DQoNCiAgICAgIG1zRnJlZUNoYXJBcnJheSh0b2tlbnMsIDIp
Ow0KICAgICAgDQogICAgICBpZihtc09iai0+SW1nQ29scyA+IE1TX01BWElNR1NJWkUgfHwgbXNP
YmotPkltZ1Jvd3MgPiBNU19NQVhJTUdTSVpFIHx8IG1zT2JqLT5JbWdDb2xzIDwgMCB8fCBtc09i
ai0+SW1nUm93cyA8IDApIHsNCgltc1NldEVycm9yKE1TX1dFQkVSUiwgIkltYWdlIHNpemUgb3V0
IG9mIHJhbmdlLiIsICJsb2FkRm9ybSgpIik7DQoJd3JpdGVFcnJvcigpOw0KICAgICAgfQ0KIA0K
ICAgICAgY29udGludWU7DQogICAgfQ0KDQogICAgaWYoc3RyY2FzZWNtcChtc09iai0+UGFyYW1O
YW1lc1tpXSwibWFwc2l6ZSIpID09IDApIHsgLy8gc2l6ZSBvZiBuZXcgbWFwIChwaXhlbHMpDQog
ICAgICB0b2tlbnMgPSBzcGxpdChtc09iai0+UGFyYW1WYWx1ZXNbaV0sICcgJywgJm4pOw0KDQog
ICAgICBpZighdG9rZW5zKSB7DQoJbXNTZXRFcnJvcihNU19NRU1FUlIsIE5VTEwsICJsb2FkRm9y
bSgpIik7DQoJd3JpdGVFcnJvcigpOw0KICAgICAgfQ0KDQogICAgICBpZihuICE9IDIpIHsNCglt
c1NldEVycm9yKE1TX1dFQkVSUiwgIk5vdCBlbm91Z2ggYXJndW1lbnRzIGZvciBtYXBzaXplLiIs
ICJsb2FkRm9ybSgpIik7DQoJd3JpdGVFcnJvcigpOw0KICAgICAgfQ0KDQogICAgICBtc09iai0+
TWFwLT53aWR0aCA9IGdldE51bWVyaWMocmUsIHRva2Vuc1swXSk7DQogICAgICBtc09iai0+TWFw
LT5oZWlnaHQgPSBnZXROdW1lcmljKHJlLCB0b2tlbnNbMV0pOw0KDQogICAgICBtc0ZyZWVDaGFy
QXJyYXkodG9rZW5zLCAyKTsNCiAgICAgIA0KICAgICAgaWYobXNPYmotPk1hcC0+d2lkdGggPiBN
U19NQVhJTUdTSVpFIHx8IG1zT2JqLT5NYXAtPmhlaWdodCA+IE1TX01BWElNR1NJWkUgfHwgbXNP
YmotPk1hcC0+d2lkdGggPCAwIHx8IG1zT2JqLT5NYXAtPmhlaWdodCA8IDApIHsNCgltc1NldEVy
cm9yKE1TX1dFQkVSUiwgIkltYWdlIHNpemUgb3V0IG9mIHJhbmdlLiIsICJsb2FkRm9ybSgpIik7
DQoJd3JpdGVFcnJvcigpOw0KICAgICAgfQ0KICAgICAgY29udGludWU7DQogICAgfQ0KDQogICAg
aWYoc3RybmNhc2VjbXAobXNPYmotPlBhcmFtTmFtZXNbaV0sImxheWVycyIsIDYpID09IDApIHsg
Ly8gdHVybiBhIHNldCBvZiBsYXllcnMsIGRlbGltaXRlZCBieSBzcGFjZXMsIG9uDQogICAgICBp
bnQgbnVtX2xheWVycz0wLCBsOw0KICAgICAgY2hhciAqKmxheWVycz1OVUxMOw0KDQogICAgICBs
YXllcnMgPSBzcGxpdChtc09iai0+UGFyYW1WYWx1ZXNbaV0sICcgJywgJihudW1fbGF5ZXJzKSk7
DQogICAgICBmb3IobD0wOyBsPG51bV9sYXllcnM7IGwrKykNCgltc09iai0+TGF5ZXJzW21zT2Jq
LT5OdW1MYXllcnMrbF0gPSBzdHJkdXAobGF5ZXJzW2xdKTsNCiAgICAgIG1zT2JqLT5OdW1MYXll
cnMgKz0gbDsNCg0KICAgICAgbXNGcmVlQ2hhckFycmF5KGxheWVycywgbnVtX2xheWVycyk7DQog
ICAgICBudW1fbGF5ZXJzID0gMDsNCiAgICAgIGNvbnRpbnVlOw0KICAgIH0NCg0KICAgIGlmKHN0
cm5jYXNlY21wKG1zT2JqLT5QYXJhbU5hbWVzW2ldLCJsYXllciIsIDUpID09IDApIHsgLy8gdHVy
biBhIHNpbmdsZSBsYXllci9ncm91cCBvbg0KICAgICAgbXNPYmotPkxheWVyc1ttc09iai0+TnVt
TGF5ZXJzXSA9IHN0cmR1cChtc09iai0+UGFyYW1WYWx1ZXNbaV0pOw0KICAgICAgbXNPYmotPk51
bUxheWVycysrOw0KICAgICAgY29udGludWU7DQogICAgfQ0KDQogICAgaWYoc3RyY2FzZWNtcCht
c09iai0+UGFyYW1OYW1lc1tpXSwicWxheWVyIikgPT0gMCkgeyAvLyBsYXllciB0byBxdWVyeSAo
aS5lIHNlYXJjaCkNCiAgICAgIFF1ZXJ5TGF5ZXIgPSBzdHJkdXAobXNPYmotPlBhcmFtVmFsdWVz
W2ldKTsNCiAgICAgIGNvbnRpbnVlOw0KICAgIH0NCg0KICAgIGlmKHN0cmNhc2VjbXAobXNPYmot
PlBhcmFtTmFtZXNbaV0sInFpdGVtIikgPT0gMCkgeyAvLyBhdHRyaWJ1dGUgdG8gcXVlcnkgb24g
KG9wdGlvbmFsKQ0KICAgICAgUXVlcnlJdGVtID0gc3RyZHVwKG1zT2JqLT5QYXJhbVZhbHVlc1tp
XSk7DQogICAgICBjb250aW51ZTsNCiAgICB9DQoNCiAgICBpZihzdHJjYXNlY21wKG1zT2JqLT5Q
YXJhbU5hbWVzW2ldLCJxc3RyaW5nIikgPT0gMCkgeyAvLyBhdHRyaWJ1dGUgcXVlcnkgc3RyaW5n
DQogICAgICBRdWVyeVN0cmluZyA9IHN0cmR1cChtc09iai0+UGFyYW1WYWx1ZXNbaV0pOw0KICAg
ICAgY29udGludWU7DQogICAgfQ0KDQogICAgaWYoc3RyY2FzZWNtcChtc09iai0+UGFyYW1OYW1l
c1tpXSwic2xheWVyIikgPT0gMCkgeyAvLyBsYXllciB0byBzZWxlY3QgKGZvciBmZWF0dXJlIGJh
c2VkIHNlYXJjaCkNCiAgICAgIFNlbGVjdExheWVyID0gc3RyZHVwKG1zT2JqLT5QYXJhbVZhbHVl
c1tpXSk7DQogICAgICBjb250aW51ZTsNCiAgICB9DQoNCiAgICBpZihzdHJjYXNlY21wKG1zT2Jq
LT5QYXJhbU5hbWVzW2ldLCJpdGVtIikgPT0gMCkgeyAvLyBzZWFyY2ggaXRlbQ0KICAgICAgSXRl
bSA9IHN0cmR1cChtc09iai0+UGFyYW1WYWx1ZXNbaV0pOw0KICAgICAgY29udGludWU7DQogICAg
fQ0KDQogICAgaWYoc3RyY2FzZWNtcChtc09iai0+UGFyYW1OYW1lc1tpXSwidmFsdWUiKSA9PSAw
KSB7IC8vIHNlYXJjaCBleHByZXNzaW9uDQogICAgICBpZighVmFsdWUpDQoJVmFsdWUgPSBzdHJk
dXAobXNPYmotPlBhcmFtVmFsdWVzW2ldKTsNCiAgICAgIGVsc2UgeyAvKiBuZWVkIHRvIGFwcGVu
ZCAqLw0KCXRtcHN0ciA9IHN0cmR1cChWYWx1ZSk7DQoJZnJlZShWYWx1ZSk7DQoJVmFsdWUgPSAo
Y2hhciAqKW1hbGxvYyhzdHJsZW4odG1wc3RyKStzdHJsZW4obXNPYmotPlBhcmFtVmFsdWVzW2ld
KSsyKTsNCglzcHJpbnRmKFZhbHVlLCAiJXN8JXMiLCB0bXBzdHIsIG1zT2JqLT5QYXJhbVZhbHVl
c1tpXSk7DQoJZnJlZSh0bXBzdHIpOw0KICAgICAgfQ0KICAgICAgY29udGludWU7DQogICAgfQ0K
DQojaWZkZWYgVVNFX0VHSVMNCg0KICAgIC8vIE9WIC0gZWdpcyAtIGFkZGl0aW9uYWwgdG9rZW4g
Im5vbmUiIGlzIGRlZmluZWQgdG8gY3JlYXRlIHNvbWV3aGF0DQogICAgLy8gbXV0dWFsIGV4Y3Vs
c2l2ZW5lc3MgYmV0d2VlbiBtYXBzZXJ2ZXIgYW5kIGVnaXMNCiANCiAgICBpZihzdHJjYXNlY21w
KG1zT2JqLT5QYXJhbU5hbWVzW2ldLCJlZ2lzIikgPT0gMCkNCiAgICB7DQogICAgICAgIGlmKHN0
cmNhc2VjbXAobXNPYmotPlBhcmFtVmFsdWVzW2ldLCJub25lIikgIT0gMCkNCiAgICAgICAgew0K
ICAgICAgICAgICAgICAgIG1zT2JqLT5Nb2RlID0gUFJPQ0VTU0lORzsNCiAgICAgICAgfQ0KICAg
ICAgICBjb250aW51ZTsNCiAgICB9DQojZW5kaWYNCg0KICAgIGlmKHN0cmNhc2VjbXAobXNPYmot
PlBhcmFtTmFtZXNbaV0sInNoYXBlaW5kZXgiKSA9PSAwKSB7IC8vIHVzZWQgZm9yIGluZGV4IHF1
ZXJpZXMNCiAgICAgIFNoYXBlSW5kZXggPSBnZXROdW1lcmljKHJlLCBtc09iai0+UGFyYW1WYWx1
ZXNbaV0pOw0KICAgICAgY29udGludWU7DQogICAgfQ0KICAgIGlmKHN0cmNhc2VjbXAobXNPYmot
PlBhcmFtTmFtZXNbaV0sInRpbGVpbmRleCIpID09IDApIHsNCiAgICAgIFRpbGVJbmRleCA9IGdl
dE51bWVyaWMocmUsIG1zT2JqLT5QYXJhbVZhbHVlc1tpXSk7DQogICAgICBjb250aW51ZTsNCiAg
ICB9DQoNCiAgICBpZihzdHJjYXNlY21wKG1zT2JqLT5QYXJhbU5hbWVzW2ldLCJtb2RlIikgPT0g
MCkgeyAvLyBzZXQgb3BlcmF0aW9uIG1vZGUNCiAgICAgIGZvcihqPTA7IGo8bnVtTW9kZXM7IGor
Kykgew0KCWlmKHN0cmNhc2VjbXAobXNPYmotPlBhcmFtVmFsdWVzW2ldLCBtb2RlU3RyaW5nc1tq
XSkgPT0gMCkgew0KCSAgbXNPYmotPk1vZGUgPSBqOw0KDQoJICBpZihtc09iai0+TW9kZSA9PSBa
T09NSU4pIHsNCgkgICAgbXNPYmotPlpvb21EaXJlY3Rpb24gPSAxOw0KCSAgICBtc09iai0+TW9k
ZSA9IEJST1dTRTsNCgkgIH0NCgkgIGlmKG1zT2JqLT5Nb2RlID09IFpPT01PVVQpIHsNCgkgICAg
bXNPYmotPlpvb21EaXJlY3Rpb24gPSAtMTsNCgkgICAgbXNPYmotPk1vZGUgPSBCUk9XU0U7DQoJ
ICB9DQoNCgkgIGJyZWFrOw0KCX0NCiAgICAgIH0NCg0KICAgICAgaWYoaiA9PSBudW1Nb2Rlcykg
ew0KCW1zU2V0RXJyb3IoTVNfV0VCRVJSLCAiSW52YWxpZCBtb2RlLiIsICJsb2FkRm9ybSgpIik7
DQoJd3JpdGVFcnJvcigpOw0KICAgICAgfQ0KDQogICAgICBjb250aW51ZTsNCiAgICB9DQoNCiAg
ICBpZihzdHJuY2FzZWNtcChtc09iai0+UGFyYW1OYW1lc1tpXSwibWFwXyIsNCkgPT0gMCkgeyAv
LyBjaGVjayB0byBzZWUgaWYgdGhlcmUgYXJlIGFueSBhZGRpdGlvbnMgdG8gdGhlIG1hcGZpbGUN
CiAgICAgIGlmKG1zTG9hZE1hcFN0cmluZyhtc09iai0+TWFwLCBtc09iai0+UGFyYW1OYW1lc1tp
XSwgbXNPYmotPlBhcmFtVmFsdWVzW2ldKSA9PSAtMSkNCgl3cml0ZUVycm9yKCk7DQogICAgICBj
b250aW51ZTsNCiAgICB9DQovKg0KCUFsbG93IHNlbGVjdGlvbiBvZiBJTUFHRVRZUEUgZnJvbSB0
aGUgY29tbWFuZCBsaW5lDQoqLw0KDQogICAgaWYoc3RybmNhc2VjbXAobXNPYmotPlBhcmFtTmFt
ZXNbaV0sImltYWdldHlwZSIsIDkpID09IDApIHsgLy8gc2VsZWN0IGFuIGltYWdlIHR5cGUgZGVm
aW5lZCBieSBhbiBPVVRQVVRGT1JNQVQNCiAgICAgIG1zT2JqLT5NYXAtPmltYWdldHlwZSA9IHN0
cmR1cChtc09iai0+UGFyYW1WYWx1ZXNbaV0pOw0KICAgICAgY29udGludWU7DQogICAgfQ0KDQov
KiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLSAqLw0KLyogICAgICBUaGUgZm9sbG93aW5nIGNvZGUgaXMgdXNlZCB0byBz
dXBwb3J0IHRoZSByb3NhIGFwcGxldCAoZm9yICAgICAgKi8NCi8qICAgICAgbW9yZSBpbmZvcm1h
dGlvbiBvbiBSb3NhLCBwbGVhc2UgY29uc3VsdCA6ICAgICAgICAgICAgICAgICAgICAgICovDQov
KiAgICAgIGh0dHA6Ly93d3cyLmRtc29sdXRpb25zLmNhL3dlYnRvb2xzL3Jvc2EvaW5kZXguaHRt
bCkgLiAgICAgICAgICAqLw0KLyogICAgICBUaGlzIGNvZGUgd2FzIHByb3ZpZGVkIGJ5IFRpbS5N
YWNrZXlAYWdzby5nb3YuYXUuICAgICAgICAgICAgICAgKi8NCi8qICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICovDQov
KiAgICAgIEZvciBBcHBsaWNhdGlvbiB1c2luZyBpdCBjYW4gYmUgc2VlbiBhdCA6ICAgICAgICAg
ICAgICAgICAgICAgICAqLw0KLypodHRwOi8vbWFwc2VydmVyLmdpcy51bW4uZWR1L3dpbG1hL21h
cHNlcnZlci11c2Vycy8wMDExL21zZzAwMDc3Lmh0bWwgKi8NCi8qICAgaHR0cDovL3d3dy5hZ3Nv
Lmdvdi5hdS9tYXAvcGlsYmFyYS8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICovDQov
KiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAqLw0KLyogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gKi8NCg0KICAgIGlmKHN0cmNhc2VjbXAo
bXNPYmotPlBhcmFtTmFtZXNbaV0sIklOUFVUX1RZUEUiKSA9PSAwKQ0KICAgIHsgLyogUm9zYSBp
bnB1dCB0eXBlICovDQogICAgICAgIGlmKHN0cmNhc2VjbXAobXNPYmotPlBhcmFtVmFsdWVzW2ld
LCJhdXRvX3JlY3QiKSA9PSAwKSANCiAgICAgICAgew0KICAgICAgICAgICAgcm9zYV90eXBlPTE7
IC8qIHJlY3RhbmdsZSAqLw0KICAgICAgICAgICAgY29udGludWU7DQogICAgICAgIH0NCiAgICAg
ICAgICAgIA0KICAgICAgICBpZihzdHJjYXNlY21wKG1zT2JqLT5QYXJhbVZhbHVlc1tpXSwiYXV0
b19wb2ludCIpID09IDApIA0KICAgICAgICB7DQogICAgICAgICAgICByb3NhX3R5cGU9MjsgLyog
cG9pbnQgKi8NCiAgICAgICAgICAgIGNvbnRpbnVlOw0KICAgICAgICB9DQogICAgfQ0KICAgIGlm
KHN0cmNhc2VjbXAobXNPYmotPlBhcmFtTmFtZXNbaV0sIklOUFVUX0NPT1JEIikgPT0gMCkgDQog
ICAgeyAvKiBSb3NhIGNvb3JkaW5hdGVzICovDQogDQogICAgICAgc3dpdGNoKHJvc2FfdHlwZSkN
CiAgICAgICB7DQogICAgICAgICBjYXNlIDE6DQogICAgICAgICAgICAgc3NjYW5mKG1zT2JqLT5Q
YXJhbVZhbHVlc1tpXSwiJWxmLCVsZjslbGYsJWxmIiwNCiAgICAgICAgICAgICAgICAgICAgJm1z
T2JqLT5JbWdCb3gubWlueCwmbXNPYmotPkltZ0JveC5taW55LCZtc09iai0+SW1nQm94Lm1heHgs
DQogICAgICAgICAgICAgICAgICAgICZtc09iai0+SW1nQm94Lm1heHkpOw0KICAgICAgICAgICAg
IGlmKChtc09iai0+SW1nQm94Lm1pbnggIT0gbXNPYmotPkltZ0JveC5tYXh4KSAmJiANCiAgICAg
ICAgICAgICAgICAobXNPYmotPkltZ0JveC5taW55ICE9IG1zT2JqLT5JbWdCb3gubWF4eSkpIA0K
ICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgbXNPYmotPkNvb3JkU291cmNlID0gRlJP
TUlNR0JPWDsNCiAgICAgICAgICAgICAgICAgUXVlcnlDb29yZFNvdXJjZSA9IEZST01JTUdCT1g7
DQogICAgICAgICAgICAgfQ0KICAgICAgICAgICAgIGVsc2UgDQogICAgICAgICAgICAgew0KICAg
ICAgICAgICAgICAgICBtc09iai0+Q29vcmRTb3VyY2UgPSBGUk9NSU1HUE5UOw0KICAgICAgICAg
ICAgICAgICBRdWVyeUNvb3JkU291cmNlID0gRlJPTUlNR1BOVDsNCiAgICAgICAgICAgICAgICAg
bXNPYmotPkltZ1BudC54PW1zT2JqLT5JbWdCb3gubWlueDsNCiAgICAgICAgICAgICAgICAgbXNP
YmotPkltZ1BudC55PW1zT2JqLT5JbWdCb3gubWlueTsNCgkgICB9DQogICAgICAgICAgIGJyZWFr
Ow0KICAgICAgICAgY2FzZSAyOg0KICAgICAgICAgICBzc2NhbmYobXNPYmotPlBhcmFtVmFsdWVz
W2ldLCIlbGYsJWxmIiwmbXNPYmotPkltZ1BudC54LA0KICAgICAgICAgICAgICAgICAgICZtc09i
ai0+SW1nUG50LnkpOw0KICAgICAgICAgICBtc09iai0+Q29vcmRTb3VyY2UgPSBGUk9NSU1HUE5U
Ow0KICAgICAgICAgICBRdWVyeUNvb3JkU291cmNlID0gRlJPTUlNR1BOVDsNCiAgICAgICAgICAg
YnJlYWs7DQogICAgICAgICB9DQogICAgICAgY29udGludWU7DQogICAgfSAgICANCi8qIC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tICovDQovKiAgICAgIGVuZCBvZiBjb2RlIGZvciBSb3NhIHN1cHBvcnQuICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAqLw0KLyogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gKi8NCg0KDQogIH0N
Cg0KICByZWdmcmVlKCZyZSk7DQoNCiAgaWYoWm9vbVNpemUgIT0gMCkgeyAvLyB1c2UgZGlyZWN0
aW9uIGFuZCBtYWduaXR1ZGUgdG8gY2FsY3VsYXRlIHpvb20NCiAgICBpZihtc09iai0+Wm9vbURp
cmVjdGlvbiA9PSAwKSB7DQogICAgICBtc09iai0+Zlpvb20gPSAxOw0KICAgIH0gZWxzZSB7DQog
ICAgICBtc09iai0+Zlpvb20gPSBab29tU2l6ZSptc09iai0+Wm9vbURpcmVjdGlvbjsNCiAgICAg
IGlmKG1zT2JqLT5mWm9vbSA8IDApDQoJbXNPYmotPmZab29tID0gMS4wL01TX0FCUyhtc09iai0+
Zlpvb20pOw0KICAgIH0NCiAgfSBlbHNlIHsgLy8gdXNlIHNpbmdsZSB2YWx1ZSBmb3Igem9vbQ0K
ICAgIGlmKChtc09iai0+Wm9vbSA+PSAtMSkgJiYgKG1zT2JqLT5ab29tIDw9IDEpKSB7DQogICAg
ICBtc09iai0+Zlpvb20gPSAxOyAvLyBwYW4NCiAgICB9IGVsc2Ugew0KICAgICAgaWYobXNPYmot
Plpvb20gPCAwKQ0KCW1zT2JqLT5mWm9vbSA9IDEuMC9NU19BQlMobXNPYmotPlpvb20pOw0KICAg
ICAgZWxzZQ0KCW1zT2JqLT5mWm9vbSA9IG1zT2JqLT5ab29tOw0KICAgIH0NCiAgfQ0KDQogIGlm
KG1zT2JqLT5JbWdSb3dzID09IC0xKSBtc09iai0+SW1nUm93cyA9IG1zT2JqLT5NYXAtPmhlaWdo
dDsNCiAgaWYobXNPYmotPkltZ0NvbHMgPT0gLTEpIG1zT2JqLT5JbWdDb2xzID0gbXNPYmotPk1h
cC0+d2lkdGg7ICANCiAgaWYobXNPYmotPk1hcC0+aGVpZ2h0ID09IC0xKSBtc09iai0+TWFwLT5o
ZWlnaHQgPSBtc09iai0+SW1nUm93czsNCiAgaWYobXNPYmotPk1hcC0+d2lkdGggPT0gLTEpIG1z
T2JqLT5NYXAtPndpZHRoID0gbXNPYmotPkltZ0NvbHM7DQoNCiAgDQp9DQoNCnZvaWQgc2V0RXh0
ZW50RnJvbVNoYXBlcygpIHsNCiAgaW50IGZvdW5kPTA7DQogIGRvdWJsZSBkeCwgZHksIGNlbGxz
aXplOw0KDQogIHJlY3RPYmogdG1wZXh0PXstMS4wLC0xLjAsLTEuMCwtMS4wfTsNCiAgcG9pbnRP
YmogdG1wcG50PXstMS4wLC0xLjB9Ow0KDQogIGZvdW5kID0gbXNHZXRRdWVyeVJlc3VsdEJvdW5k
cyhtc09iai0+TWFwLCAmKHRtcGV4dCkpOw0KDQogIGR4ID0gdG1wZXh0Lm1heHggLSB0bXBleHQu
bWlueDsNCiAgZHkgPSB0bXBleHQubWF4eSAtIHRtcGV4dC5taW55Ow0KIA0KICB0bXBwbnQueCA9
ICh0bXBleHQubWF4eCArIHRtcGV4dC5taW54KS8yOw0KICB0bXBwbnQueSA9ICh0bXBleHQubWF4
eSArIHRtcGV4dC5taW55KS8yOw0KICB0bXBleHQubWlueCAtPSBkeCpFWFRFTlRfUEFERElORy8y
LjA7DQogIHRtcGV4dC5tYXh4ICs9IGR4KkVYVEVOVF9QQURESU5HLzIuMDsNCiAgdG1wZXh0Lm1p
bnkgLT0gZHkqRVhURU5UX1BBRERJTkcvMi4wOw0KICB0bXBleHQubWF4eSArPSBkeSpFWFRFTlRf
UEFERElORy8yLjA7DQoNCiAgaWYobXNPYmotPlNjYWxlICE9IDApIHsgLy8gYXBwbHkgdGhlIHNj
YWxlIGFyb3VuZCB0aGUgY2VudGVyIHBvaW50ICh0bXBwbnQpDQogICAgY2VsbHNpemUgPSAobXNP
YmotPlNjYWxlL21zT2JqLT5NYXAtPnJlc29sdXRpb24pL2luY2hlc1BlclVuaXRbbXNPYmotPk1h
cC0+dW5pdHNdOyAvLyB1c2VyIHN1cHBsaWVkIGEgcG9pbnQgYW5kIGEgc2NhbGUNCiAgICB0bXBl
eHQubWlueCA9IHRtcHBudC54IC0gY2VsbHNpemUqbXNPYmotPk1hcC0+d2lkdGgvMi4wOw0KICAg
IHRtcGV4dC5taW55ID0gdG1wcG50LnkgLSBjZWxsc2l6ZSptc09iai0+TWFwLT5oZWlnaHQvMi4w
Ow0KICAgIHRtcGV4dC5tYXh4ID0gdG1wcG50LnggKyBjZWxsc2l6ZSptc09iai0+TWFwLT53aWR0
aC8yLjA7DQogICAgdG1wZXh0Lm1heHkgPSB0bXBwbnQueSArIGNlbGxzaXplKm1zT2JqLT5NYXAt
PmhlaWdodC8yLjA7DQogIH0gZWxzZSBpZihtc09iai0+QnVmZmVyICE9IDApIHsgLy8gYXBwbHkg
dGhlIGJ1ZmZlciBhcm91bmQgdGhlIGNlbnRlciBwb2ludCAodG1wcG50KQ0KICAgIHRtcGV4dC5t
aW54ID0gdG1wcG50LnggLSBtc09iai0+QnVmZmVyOw0KICAgIHRtcGV4dC5taW55ID0gdG1wcG50
LnkgLSBtc09iai0+QnVmZmVyOw0KICAgIHRtcGV4dC5tYXh4ID0gdG1wcG50LnggKyBtc09iai0+
QnVmZmVyOw0KICAgIHRtcGV4dC5tYXh5ID0gdG1wcG50LnkgKyBtc09iai0+QnVmZmVyOw0KICB9
DQoNCiAgLy8gaW4gY2FzZSB3ZSBkb24ndCBnZXQgIHVzYWJsZSBleHRlbnQgYXQgdGhpcyBwb2lu
dCAoaS5lLiBzaW5nbGUgcG9pbnQgcmVzdWx0KQ0KICBpZighTVNfVkFMSURfRVhURU5UKHRtcGV4
dC5taW54LCB0bXBleHQubWlueSwgdG1wZXh0Lm1heHgsIHRtcGV4dC5tYXh5KSkgew0KICAgIGlm
KG1zT2JqLT5NYXAtPndlYi5taW5zY2FsZSA+IDApIHsgLy8gdHJ5IHdlYiBvYmplY3QgbWluc2Nh
bGUgZmlyc3QNCiAgICAgIGNlbGxzaXplID0gKG1zT2JqLT5NYXAtPndlYi5taW5zY2FsZS9tc09i
ai0+TWFwLT5yZXNvbHV0aW9uKS9pbmNoZXNQZXJVbml0W21zT2JqLT5NYXAtPnVuaXRzXTsgLy8g
dXNlciBzdXBwbGllZCBhIHBvaW50IGFuZCBhIHNjYWxlDQogICAgICB0bXBleHQubWlueCA9IHRt
cHBudC54IC0gY2VsbHNpemUqbXNPYmotPk1hcC0+d2lkdGgvMi4wOw0KICAgICAgdG1wZXh0Lm1p
bnkgPSB0bXBwbnQueSAtIGNlbGxzaXplKm1zT2JqLT5NYXAtPmhlaWdodC8yLjA7DQogICAgICB0
bXBleHQubWF4eCA9IHRtcHBudC54ICsgY2VsbHNpemUqbXNPYmotPk1hcC0+d2lkdGgvMi4wOw0K
ICAgICAgdG1wZXh0Lm1heHkgPSB0bXBwbnQueSArIGNlbGxzaXplKm1zT2JqLT5NYXAtPmhlaWdo
dC8yLjA7DQogICAgfSBlbHNlIHsNCiAgICAgIG1zU2V0RXJyb3IoTVNfV0VCRVJSLCAiTm8gd2F5
IHRvIGdlbmVyYXRlIGEgdmFsaWQgbWFwIGV4dGVudCBmcm9tIHNlbGVjdGVkIHNoYXBlcy4iLCAi
bWFwc2VydigpIik7DQogICAgICB3cml0ZUVycm9yKCk7DQogICAgfQ0KICB9DQoNCiAgbXNPYmot
Pk1hcFBudCA9IHRtcHBudDsNCiAgbXNPYmotPk1hcC0+ZXh0ZW50ID0gbXNPYmotPlJhd0V4dCA9
IHRtcGV4dDsgLy8gc2F2ZSB1bmFkanVzdGVkIGV4dGVudA0KDQogIHJldHVybjsNCn0NCg0KDQov
KiBGSVg6IE5FRUQgRVJST1IgQ0hFQ0tJTkcgSEVSRSBGT1IgSU1HUE5UIG9yIE1BUFBOVCAqLw0K
dm9pZCBzZXRDb29yZGluYXRlKCkNCnsNCiAgZG91YmxlIGNlbGx4LGNlbGx5Ow0KDQogIGNlbGx4
ID0gTVNfQ0VMTFNJWkUobXNPYmotPkltZ0V4dC5taW54LCBtc09iai0+SW1nRXh0Lm1heHgsIG1z
T2JqLT5JbWdDb2xzKTsNCiAgY2VsbHkgPSBNU19DRUxMU0laRShtc09iai0+SW1nRXh0Lm1pbnks
IG1zT2JqLT5JbWdFeHQubWF4eSwgbXNPYmotPkltZ1Jvd3MpOw0KDQogIG1zT2JqLT5NYXBQbnQu
eCA9IE1TX0lNQUdFMk1BUF9YKG1zT2JqLT5JbWdQbnQueCwgbXNPYmotPkltZ0V4dC5taW54LCBj
ZWxseCk7DQogIG1zT2JqLT5NYXBQbnQueSA9IE1TX0lNQUdFMk1BUF9ZKG1zT2JqLT5JbWdQbnQu
eSwgbXNPYmotPkltZ0V4dC5tYXh5LCBjZWxseSk7DQoNCiAgcmV0dXJuOw0KfQ0KDQp2b2lkIHJl
dHVybkNvb3JkaW5hdGUoKQ0Kew0KICBtc1NldEVycm9yKE1TX05PRVJSLCANCiAgICAgICAgICAg
ICAiWW91ciBcIjxpPmNsaWNrPC9pPlwiIGNvcnJlc3BvbmRzIHRvIChhcHByb3hpbWF0ZWx5KTog
KCVnLCAlZykuIiwNCiAgICAgICAgICAgICBOVUxMLA0KICAgICAgICAgICAgIG1zT2JqLT5NYXBQ
bnQueCwgbXNPYmotPk1hcFBudC55KTsNCg0KI2lmZGVmIFVTRV9QUk9KDQogIGlmKG1zT2JqLT5N
YXAtPnByb2plY3Rpb24ucHJvaiAhPSBOVUxMICYmICFwal9pc19sYXRsb25nKG1zT2JqLT5NYXAt
PnByb2plY3Rpb24ucHJvaikgKSB7DQogICAgcG9pbnRPYmogcD1tc09iai0+TWFwUG50Ow0KICAg
IG1zUHJvamVjdFBvaW50KCYobXNPYmotPk1hcC0+cHJvamVjdGlvbiksICYobXNPYmotPk1hcC0+
bGF0bG9uKSwgJnApOw0KICAgIG1zU2V0RXJyb3IoIE1TX05PRVJSLCANCiAgICAgICAgICAgICAg
ICAiJXMgQ29tcHV0ZWQgbGF0L2xvbiB2YWx1ZSBpcyAoJWcsICVnKS5cbiIsIE5VTEwsIHAueCwg
cC55KTsNCiAgfQ0KI2VuZGlmDQoNCiAgd3JpdGVFcnJvcigpOw0KfQ0KDQoNCi8vIEZJWDogbmVl
ZCB0byBjb25zaWRlciBKT0lOUw0KLy8gRklYOiBuZWVkIHRvIGNvbnNpZGVyIDUlIHNoYXBlIGV4
dGVudCBleHBhbnNpb24NCg0KLyoNCioqDQoqKiBTdGFydCBvZiBtYWluIHByb2dyYW0NCioqDQoq
Lw0KaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkgew0KICAgIGludCBpLGo7DQogICAg
Y2hhciBidWZmZXJbMTAyNF07DQogICAgaW1hZ2VPYmogKmltZz1OVUxMOw0KICAgIGludCBzdGF0
dXM7DQoNCiAgICBtc09iaiA9IG1zQWxsb2NNYXBTZXJ2T2JqKCk7DQoNCiNpZmRlZiBVU0VfRUdJ
Uw0KICAgIC8vIE9WIC1lZ2lzLSBJbml0aWFsaXplIGVnaXMgZXJyb3IgbG9nIGZpbGUgaGVyZS4u
Lg0KICAgIGluaXRFcnJMb2coIi9leHBvcnQvaG9tZS90bXAvbXNFcnJvci5sb2ciKTsNCiAgICB3
cml0ZUVyckxvZygiRXJyb3JMb2dmaWxlIGlzIGluaXRpYWxpemVkXG4iKTsNCiAgICBmZmx1c2go
ZnBFcnJMb2cpOw0KI2VuZGlmDQoNCiAgICBpZihhcmdjID4gMSAmJiBzdHJjbXAoYXJndlsxXSwg
Ii12IikgPT0gMCkgew0KICAgICAgcHJpbnRmKCIlc1xuIiwgbXNHZXRWZXJzaW9uKCkpOw0KICAg
ICAgZmZsdXNoKHN0ZG91dCk7DQogICAgICBleGl0KDApOw0KICAgIH0NCiAgICBlbHNlIGlmKGFy
Z2MgPiAyICYmIHN0cmNtcChhcmd2WzFdLCAiLXQiKSA9PSAwKSANCiAgICB7DQogICAgICAgIGNo
YXIgKip0b2tlbnM7DQogICAgICAgIGludCBudW10b2tlbnM9MDsNCiAgICAgICAgaWYgKCh0b2tl
bnM9bXNUb2tlbml6ZU1hcChhcmd2WzJdLCAmbnVtdG9rZW5zKSkgIT0gTlVMTCkNCiAgICAgICAg
ew0KICAgICAgICAgICAgaW50IGk7DQogICAgICAgICAgICBmb3IoaT0wOyBpPG51bXRva2Vuczsg
aSsrKQ0KICAgICAgICAgICAgICAgIHByaW50ZigiJXNcbiIsIHRva2Vuc1tpXSk7DQogICAgICAg
ICAgICBtc0ZyZWVDaGFyQXJyYXkodG9rZW5zLCBudW10b2tlbnMpOw0KICAgICAgICB9DQogICAg
ICAgIGVsc2UNCiAgICAgICAgew0KICAgICAgICAgICAgd3JpdGVFcnJvcigpOw0KICAgICAgICB9
DQoNCiAgICAgIGV4aXQoMCk7DQogICAgfQ0KICAgIGVsc2UgaWYgKGFyZ2MgPiAxICYmIHN0cm5j
bXAoYXJndlsxXSwgIlFVRVJZX1NUUklORz0iLCAxMykgPT0gMCkgew0KICAgICAgLyogRGVidWdn
aW5nIGhvb2suLi4gcGFzcyAiUVVFUllfU1RSSU5HPS4uLiIgb24gdGhlIGNvbW1hbmQtbGluZSAq
Lw0KICAgICAgY2hhciAqYnVmOw0KICAgICAgYnVmID0gc3RyZHVwKCJSRVFVRVNUX01FVEhPRD1H
RVQiKTsNCiAgICAgIHB1dGVudihidWYpOw0KICAgICAgYnVmID0gc3RyZHVwKGFyZ3ZbMV0pOw0K
ICAgICAgcHV0ZW52KGJ1Zik7DQogICAgfQ0KDQogICAgc3ByaW50Zihtc09iai0+SWQsICIlbGQl
ZCIsKGxvbmcpdGltZShOVUxMKSwoaW50KWdldHBpZCgpKTsgLy8gYXNpZ24gbm93IHNvIGl0IGNh
biBiZSBvdmVycmlkZGVuDQoNCiAgICBtc09iai0+UGFyYW1OYW1lcyA9IChjaGFyICoqKSBtYWxs
b2MoTUFYX1BBUkFNUypzaXplb2YoY2hhciopKTsNCiAgICBtc09iai0+UGFyYW1WYWx1ZXMgPSAo
Y2hhciAqKikgbWFsbG9jKE1BWF9QQVJBTVMqc2l6ZW9mKGNoYXIqKSk7DQogICAgaWYgKG1zT2Jq
LT5QYXJhbU5hbWVzPT1OVUxMIHx8IG1zT2JqLT5QYXJhbVZhbHVlcz09TlVMTCkgew0KCW1zU2V0
RXJyb3IoTVNfTUVNRVJSLCBOVUxMLCAibWFwc2VydigpIik7DQoJd3JpdGVFcnJvcigpOw0KICAg
IH0NCg0KICAgIG1zT2JqLT5OdW1QYXJhbXMgPSBsb2FkUGFyYW1zKG1zT2JqLT5QYXJhbU5hbWVz
LCBtc09iai0+UGFyYW1WYWx1ZXMpOw0KICAgIG1zT2JqLT5NYXAgPSBsb2FkTWFwKCk7DQoNCiAg
ICAvKg0KICAgICoqIFN0YXJ0IGJ5IGNhbGxpbmcgdGhlIFdNUy9XRlMgRGlzcGF0Y2hlcnMuICBJ
ZiB0aGV5IGZhaWwgdGhlbiB3ZSdsbCANCiAgICAqKiBwcm9jZXNzIHRoaXMgYXMgYSByZWd1bGFy
IE1hcFNlcnZlciByZXF1ZXN0Lg0KICAgICovDQojaWYgZGVmaW5lZChVU0VfV01TX1NWUikgfHwg
ZGVmaW5lZChVU0VfV0ZTX1NWUikNCiAgICBpZiAoKHN0YXR1cyA9IG1zT1dTRGlzcGF0Y2gobXNP
YmotPk1hcCwgbXNPYmotPlBhcmFtTmFtZXMsIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBtc09iai0+UGFyYW1WYWx1ZXMsIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBtc09iai0+TnVtUGFyYW1zKSkgIT0gTVNfRE9ORSAgKSANCiAgICB7DQogICAgICAvKiBUaGlz
IHdhcyBhIFdNUy9XRlMgcmVxdWVzdC4uLiBjbGVhbnVwIGFuZCBleGl0IA0KICAgICAgICogQXQg
dGhpcyBwb2ludCBhbnkgZXJyb3IgaGFzIGFscmVhZHkgYmVlbiBoYW5kbGVkDQogICAgICAgKiBh
cyBhbiBYTUwgZXhjZXB0aW9uIGJ5IHRoZSBPR0Mgc2VydmljZS4NCiAgICAgICAqLw0KICAgICAg
bXNGcmVlTWFwKG1zT2JqLT5NYXApOw0KICAgICAgbXNGcmVlQ2hhckFycmF5KG1zT2JqLT5QYXJh
bU5hbWVzLCBtc09iai0+TnVtUGFyYW1zKTsNCiAgICAgIG1zRnJlZUNoYXJBcnJheShtc09iai0+
UGFyYW1WYWx1ZXMsIG1zT2JqLT5OdW1QYXJhbXMpOw0KICAgICAgIA0KICAgICAgZXhpdCgwKTsN
CiAgICB9DQojZW5kaWYNCg0KICAgIGxvYWRGb3JtKCk7DQogDQoJaWYobXNPYmotPk1hcC0+aW1h
Z2V0eXBlICE9IE5VTEwpIHsJCQkJCQkJCS8qIElmIGltYWdldHlwZSBpcyBzZXQgZnJvbSB0aGUg
TUFQIGZpbGUgb3IgYSBmb3JtIHZhcmlhYmxlICovCQ0KCSAgICBtc0FwcGx5T3V0cHV0Rm9ybWF0
KCAmKG1zT2JqLT5NYXAtPm91dHB1dGZvcm1hdCksCQkJLyogU2VsZWN0IHRoZSBuZXcgb3V0cHV0
IGZvcm1hdCBmcm9tIHRoZSB0YWJsZSBhbmQgYXBwbHkgaXQgKi8NCgkJCW1zU2VsZWN0T3V0cHV0
Rm9ybWF0KG1zT2JqLT5NYXAsIG1zT2JqLT5NYXAtPmltYWdldHlwZSksIG1zT2JqLT5NYXAtPnRy
YW5zcGFyZW50LCBtc09iai0+TWFwLT5pbnRlcmxhY2UsIG1zT2JqLT5NYXAtPmltYWdlcXVhbGl0
eSApOw0KCX0NCg0KICAgIGlmKG1zT2JqLT5TYXZlTWFwKSB7DQogICAgICBzcHJpbnRmKGJ1ZmZl
ciwgIiVzJXMlcy5tYXAiLCBtc09iai0+TWFwLT53ZWIuaW1hZ2VwYXRoLCBtc09iai0+TWFwLT5u
YW1lLCBtc09iai0+SWQpOw0KICAgICAgaWYobXNTYXZlTWFwKG1zT2JqLT5NYXAsIGJ1ZmZlcikg
PT0gLTEpIHdyaXRlRXJyb3IoKTsNCiAgICB9DQoNCiAgICBpZigobXNPYmotPkNvb3JkU291cmNl
ID09IEZST01JTUdQTlQpIHx8IChtc09iai0+Q29vcmRTb3VyY2UgPT0gRlJPTUlNR0JPWCkpIC8q
IG1ha2Ugc3VyZSBleHRlbnQgb2YgZXhpc3RpbmcgaW1hZ2UgbWF0Y2hlcyBzaGFwZSBvZiBpbWFn
ZSAqLw0KICAgICAgbXNPYmotPk1hcC0+Y2VsbHNpemUgPSBtc0FkanVzdEV4dGVudCgmbXNPYmot
PkltZ0V4dCwgbXNPYmotPkltZ0NvbHMsIG1zT2JqLT5JbWdSb3dzKTsNCg0KICAgIC8qDQogICAg
KiogRm9yIGVhY2ggbGF5ZXIgbGV0cyBzZXQgbGF5ZXIgc3RhdHVzDQogICAgKi8NCiAgICBmb3Io
aT0wO2k8bXNPYmotPk1hcC0+bnVtbGF5ZXJzO2krKykgew0KICAgICAgaWYoKG1zT2JqLT5NYXAt
PmxheWVyc1tpXS5zdGF0dXMgIT0gTVNfREVGQVVMVCkpIHsNCglpZihpc09uKG1zT2JqLCBtc09i
ai0+TWFwLT5sYXllcnNbaV0ubmFtZSwgbXNPYmotPk1hcC0+bGF5ZXJzW2ldLmdyb3VwKSA9PSBN
U19UUlVFKSAvKiBTZXQgbGF5ZXIgc3RhdHVzICovDQoJICBtc09iai0+TWFwLT5sYXllcnNbaV0u
c3RhdHVzID0gTVNfT047DQoJZWxzZQ0KCSAgbXNPYmotPk1hcC0+bGF5ZXJzW2ldLnN0YXR1cyA9
IE1TX09GRjsNCiAgICAgIH0gICAgIA0KICAgIH0NCg0KICAgIGlmKG1zT2JqLT5Db29yZFNvdXJj
ZSA9PSBGUk9NUkVGUE5UKSAvKiBmb3JjZSBicm93c2UgbW9kZSBpZiB0aGUgcmVmZXJlbmNlIGNv
b3JkcyBhcmUgc2V0ICovDQogICAgICBtc09iai0+TW9kZSA9IEJST1dTRTsNCg0KICAgIGlmKG1z
T2JqLT5Nb2RlID09IEJST1dTRSkgew0KDQogICAgICBpZighbXNPYmotPk1hcC0+d2ViLnRlbXBs
YXRlKSB7DQoJbXNTZXRFcnJvcihNU19XRUJFUlIsICJObyB0ZW1wbGF0ZSBwcm92aWRlZC4iLCAi
bWFwc2VydigpIik7DQoJd3JpdGVFcnJvcigpOw0KICAgICAgfQ0KDQogICAgICBpZihRdWVyeUZp
bGUpIHsNCglzdGF0dXMgPSBtc0xvYWRRdWVyeShtc09iai0+TWFwLCBRdWVyeUZpbGUpOw0KCWlm
KHN0YXR1cyAhPSBNU19TVUNDRVNTKSB3cml0ZUVycm9yKCk7DQogICAgICB9DQogICAgICANCiAg
ICAgIHNldEV4dGVudChtc09iaik7DQogICAgICBjaGVja1dlYlNjYWxlKG1zT2JqKTsNCiAgICAg
ICANCi8qIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tICovDQovKiAgICAgIGdlbmVyYXRlIG1hcCwgbGVnZW5kLCBzY2Fs
ZWJhciBhbmQgcmVmZXJuY2UgaW1hZ2VzLiAgICAgICAgICAgICAqLw0KLyogLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0g
Ki8NCiAgICAgIGlmIChtc0dlbmVyYXRlSW1hZ2VzKG1zT2JqLCBRdWVyeUZpbGUsIE1TX1RSVUUp
ID09IE1TX0ZBTFNFKQ0KICAgICAgICB3cml0ZUVycm9yKCk7DQogICAgICANCiAgICAgIGlmKFF1
ZXJ5RmlsZSkgew0KICAgICAgICAgIGlmIChtc1JldHVyblF1ZXJ5KG1zT2JqLCAidGV4dC9odG1s
IiwgTlVMTCkgIT0gTVNfU1VDQ0VTUykNCiAgICAgICAgICAgd3JpdGVFcnJvcigpOw0KICAgICAg
fSBlbHNlIHsNCglpZihURU1QTEFURV9UWVBFKG1zT2JqLT5NYXAtPndlYi50ZW1wbGF0ZSkgPT0g
TVNfRklMRSkgeyAvKiBpZiB0aGVycydzIGFuIGh0bWwgdGVtcGxhdGUsIHRoZW4gdXNlIGl0ICov
DQoJICBwcmludGYoIkNvbnRlbnQtdHlwZTogdGV4dC9odG1sJWMlYyIsIDEwLCAxMCk7IC8qIHdy
aXRlIE1JTUUgaGVhZGVyICovDQoJICBwcmludGYoIjwhLS0gJXMgLS0+XG4iLCBtc0dldFZlcnNp
b24oKSk7DQoJICBmZmx1c2goc3Rkb3V0KTsNCgkgIGlmIChtc1JldHVyblBhZ2UobXNPYmosIG1z
T2JqLT5NYXAtPndlYi50ZW1wbGF0ZSwgQlJPV1NFLCBOVUxMKSAhPSBNU19TVUNDRVNTKQ0KICAg
ICAgICAgd3JpdGVFcnJvcigpOw0KCX0gZWxzZSB7CQ0KCSAgaWYgKG1zUmV0dXJuVVJMKG1zT2Jq
LCBtc09iai0+TWFwLT53ZWIudGVtcGxhdGUsIEJST1dTRSkgIT0gTVNfU1VDQ0VTUykNCiAgICAg
ICAgIHdyaXRlRXJyb3IoKTsNCgl9DQogICAgICB9DQoNCiAgICB9IGVsc2UgaWYobXNPYmotPk1v
ZGUgPT0gTUFQIHx8IG1zT2JqLT5Nb2RlID09IFNDQUxFQkFSIHx8IG1zT2JqLT5Nb2RlID09IFJF
RkVSRU5DRSkgeyAvLyAiaW1hZ2UiIG9ubHkgbW9kZXMNCiAgICAgIHNldEV4dGVudChtc09iaik7
DQogICAgICBjaGVja1dlYlNjYWxlKG1zT2JqKTsNCiAgICAgIA0KICAgICAgc3dpdGNoKG1zT2Jq
LT5Nb2RlKSB7DQogICAgICBjYXNlIE1BUDoNCglpZihRdWVyeUZpbGUpIHsNCgkgIHN0YXR1cyA9
IG1zTG9hZFF1ZXJ5KG1zT2JqLT5NYXAsIFF1ZXJ5RmlsZSk7DQoJICBpZihzdGF0dXMgIT0gTVNf
U1VDQ0VTUykgd3JpdGVFcnJvcigpOw0KCSAgaW1nID0gbXNEcmF3UXVlcnlNYXAobXNPYmotPk1h
cCk7DQoJfSBlbHNlDQoJICBpbWcgPSBtc0RyYXdNYXAobXNPYmotPk1hcCk7DQoJYnJlYWs7DQog
ICAgICBjYXNlIFJFRkVSRU5DRToNCgltc09iai0+TWFwLT5jZWxsc2l6ZSA9IG1zQWRqdXN0RXh0
ZW50KCYobXNPYmotPk1hcC0+ZXh0ZW50KSwgbXNPYmotPk1hcC0+d2lkdGgsIG1zT2JqLT5NYXAt
PmhlaWdodCk7DQoJaW1nID0gbXNEcmF3UmVmZXJlbmNlTWFwKG1zT2JqLT5NYXApOw0KCWJyZWFr
OyAgICAgIA0KICAgICAgY2FzZSBTQ0FMRUJBUjoNCglpbWcgPSBtc0RyYXdTY2FsZWJhcihtc09i
ai0+TWFwKTsNCglicmVhazsNCiAgICAgIH0NCiAgICAgIA0KICAgICAgaWYoIWltZykgd3JpdGVF
cnJvcigpOw0KDQogICAgICBwcmludGYoIkNvbnRlbnQtdHlwZTogJXMlYyVjIixNU19JTUFHRV9N
SU1FX1RZUEUobXNPYmotPk1hcC0+b3V0cHV0Zm9ybWF0KSwgMTAsMTApOw0KICAgICAgaWYoIG1z
T2JqLT5Nb2RlID09IE1BUCApDQogICAgICAgICAgc3RhdHVzID0gbXNTYXZlSW1hZ2UobXNPYmot
Pk1hcCxpbWcsIE5VTEwpOw0KICAgICAgZWxzZQ0KICAgICAgICAgIHN0YXR1cyA9IG1zU2F2ZUlt
YWdlKE5VTEwsaW1nLCBOVUxMKTsNCiAgICAgICAgICANCiAgICAgIGlmKHN0YXR1cyAhPSBNU19T
VUNDRVNTKSB3cml0ZUVycm9yKCk7DQogICAgICANCiAgICAgIG1zRnJlZUltYWdlKGltZyk7DQog
ICAgfSBlbHNlIGlmIChtc09iai0+TW9kZSA9PSBMRUdFTkQpIHsNCiAgICAgICBpZiAobXNPYmot
Pk1hcC0+bGVnZW5kLnRlbXBsYXRlKSANCiAgICAgICB7DQogICAgICAgICAgY2hhciAqbGVnZW5k
VGVtcGxhdGU7DQoNCiAgICAgICAgICBsZWdlbmRUZW1wbGF0ZSA9IGdlbmVyYXRlTGVnZW5kVGVt
cGxhdGUobXNPYmopOw0KICAgICAgICAgIGlmIChsZWdlbmRUZW1wbGF0ZSkgew0KICAgICAgICAg
ICAgIHByaW50ZigiQ29udGVudC10eXBlOiB0ZXh0L2h0bWxcblxuJXMiLCBsZWdlbmRUZW1wbGF0
ZSk7DQoNCiAgICAgICAgICAgICBmcmVlKGxlZ2VuZFRlbXBsYXRlKTsNCiAgICAgICAgICB9DQog
ICAgICAgICAgZWxzZSAvLyBlcnJvciBhbHJlYWR5IGdlbmVyYXRlZCBieSAoZ2VuZXJhdGVMZWdl
bmRUZW1wbGF0ZSgpKQ0KICAgICAgICAgICAgd3JpdGVFcnJvcigpOzsNCiAgICAgICB9ICAgICAg
ICAgDQogICAgICAgZWxzZQ0KICAgICAgIHsNCiAgICAgICAgICBpbWcgPSBtc0RyYXdMZWdlbmQo
bXNPYmotPk1hcCk7DQogICAgICAgICAgaWYoIWltZykgd3JpdGVFcnJvcigpOw0KDQogICAgICAg
ICAgcHJpbnRmKCJDb250ZW50LXR5cGU6ICVzJWMlYyIsTVNfSU1BR0VfTUlNRV9UWVBFKG1zT2Jq
LT5NYXAtPm91dHB1dGZvcm1hdCksIDEwLDEwKTsNCiAgICAgICAgICBzdGF0dXMgPSBtc1NhdmVJ
bWFnZShOVUxMLCBpbWcsIE5VTEwpOw0KICAgICAgICAgIGlmKHN0YXR1cyAhPSBNU19TVUNDRVNT
KSB3cml0ZUVycm9yKCk7DQogICAgICAgICAgDQogICAgICAgICAgbXNGcmVlSW1hZ2UoaW1nKTsg
ICAgICAgICAgICANCiAgICAgICB9DQogICAgfSBlbHNlIGlmKG1zT2JqLT5Nb2RlID49IFFVRVJZ
KSB7IC8vIHF1ZXJ5IG1vZGVzDQoNCiAgICAgIGlmKFF1ZXJ5RmlsZSkgeyAvLyBhbHJlYWR5IGdv
dCBhIGNvbXBsZXRlZCBxdWVyeQ0KCXN0YXR1cyA9IG1zTG9hZFF1ZXJ5KG1zT2JqLT5NYXAsIFF1
ZXJ5RmlsZSk7DQoJaWYoc3RhdHVzICE9IE1TX1NVQ0NFU1MpIHdyaXRlRXJyb3IoKTsNCiAgICAg
IH0gZWxzZSB7DQoNCglpZigoUXVlcnlMYXllckluZGV4ID0gbXNHZXRMYXllckluZGV4KG1zT2Jq
LT5NYXAsIFF1ZXJ5TGF5ZXIpKSAhPSAtMSkgLyogZm9yY2UgdGhlIHF1ZXJ5IGxheWVyIG9uICov
DQoJICBtc09iai0+TWFwLT5sYXllcnNbUXVlcnlMYXllckluZGV4XS5zdGF0dXMgPSBNU19PTjsN
Cg0KICAgICAgICBzd2l0Y2gobXNPYmotPk1vZGUpIHsNCgljYXNlIElURU1GRUFUVVJFUVVFUlk6
DQogICAgICAgIGNhc2UgSVRFTUZFQVRVUkVOUVVFUlk6DQoJY2FzZSBJVEVNRkVBVFVSRVFVRVJZ
TUFQOg0KICAgICAgICBjYXNlIElURU1GRUFUVVJFTlFVRVJZTUFQOg0KCSAgaWYoKFNlbGVjdExh
eWVySW5kZXggPSBtc0dldExheWVySW5kZXgobXNPYmotPk1hcCwgU2VsZWN0TGF5ZXIpKSA9PSAt
MSkgeyAvKiBmb3JjZSB0aGUgc2VsZWN0aW9uIGxheWVyIG9uICovDQoJICAgIG1zU2V0RXJyb3Io
TVNfV0VCRVJSLCAiU2VsZWN0aW9uIGxheWVyIG5vdCBzZXQgb3IgcmVmZXJlbmNlcyBhbiBpbnZh
bGlkIGxheWVyLiIsICJtYXBzZXJ2KCkiKTsgDQoJICAgIHdyaXRlRXJyb3IoKTsNCgkgIH0NCgkg
IG1zT2JqLT5NYXAtPmxheWVyc1tTZWxlY3RMYXllckluZGV4XS5zdGF0dXMgPSBNU19PTjsNCg0K
CSAgaWYoUXVlcnlDb29yZFNvdXJjZSAhPSBOT05FICYmICFtc09iai0+VXNlU2hhcGVzKQ0KCSAg
ICBzZXRFeHRlbnQobXNPYmopOyAvKiBzZXQgdXNlciBhcmVhIG9mIGludGVyZXN0ICovDQoNCgkg
IGlmKG1zT2JqLT5Nb2RlID09IElURU1GRUFUVVJFUVVFUlkgfHwgbXNPYmotPk1vZGUgPT0gSVRF
TUZFQVRVUkVRVUVSWU1BUCkgew0KCSAgICBpZigoc3RhdHVzID0gbXNRdWVyeUJ5QXR0cmlidXRl
cyhtc09iai0+TWFwLCBTZWxlY3RMYXllckluZGV4LCBRdWVyeUl0ZW0sIFF1ZXJ5U3RyaW5nLCBN
U19TSU5HTEUpKSAhPSBNU19TVUNDRVNTKSB3cml0ZUVycm9yKCk7DQoJICB9IGVsc2Ugew0KCSAg
ICBpZigoc3RhdHVzID0gbXNRdWVyeUJ5QXR0cmlidXRlcyhtc09iai0+TWFwLCBTZWxlY3RMYXll
ckluZGV4LCBRdWVyeUl0ZW0sIFF1ZXJ5U3RyaW5nLCBNU19NVUxUSVBMRSkpICE9IE1TX1NVQ0NF
U1MpIHdyaXRlRXJyb3IoKTsNCgkgIH0NCg0KCSAgaWYobXNRdWVyeUJ5RmVhdHVyZXMobXNPYmot
Pk1hcCwgUXVlcnlMYXllckluZGV4LCBTZWxlY3RMYXllckluZGV4KSAhPSBNU19TVUNDRVNTKSB3
cml0ZUVycm9yKCk7DQoNCgkgIGJyZWFrOw0KICAgICAgICBjYXNlIEZFQVRVUkVRVUVSWToNCiAg
ICAgICAgY2FzZSBGRUFUVVJFTlFVRVJZOg0KCWNhc2UgRkVBVFVSRVFVRVJZTUFQOg0KICAgICAg
ICBjYXNlIEZFQVRVUkVOUVVFUllNQVA6DQoJICBpZigoU2VsZWN0TGF5ZXJJbmRleCA9IG1zR2V0
TGF5ZXJJbmRleChtc09iai0+TWFwLCBTZWxlY3RMYXllcikpID09IC0xKSB7IC8qIGZvcmNlIHRo
ZSBzZWxlY3Rpb24gbGF5ZXIgb24gKi8NCgkgICAgbXNTZXRFcnJvcihNU19XRUJFUlIsICJTZWxl
Y3Rpb24gbGF5ZXIgbm90IHNldCBvciByZWZlcmVuY2VzIGFuIGludmFsaWQgbGF5ZXIuIiwgIm1h
cHNlcnYoKSIpOyANCgkgICAgd3JpdGVFcnJvcigpOw0KCSAgfQ0KCSAgbXNPYmotPk1hcC0+bGF5
ZXJzW1NlbGVjdExheWVySW5kZXhdLnN0YXR1cyA9IE1TX09OOw0KCSAgDQoJICBpZihtc09iai0+
TW9kZSA9PSBGRUFUVVJFUVVFUlkgfHwgbXNPYmotPk1vZGUgPT0gRkVBVFVSRVFVRVJZTUFQKSB7
DQoJICAgIHN3aXRjaChRdWVyeUNvb3JkU291cmNlKSB7DQoJICAgIGNhc2UgRlJPTUlNR1BOVDoN
CgkgICAgICBtc09iai0+TWFwLT5leHRlbnQgPSBtc09iai0+SW1nRXh0OyAvKiB1c2UgdGhlIGV4
aXN0aW5nIG1hcCBleHRlbnQgKi8JDQoJICAgICAgc2V0Q29vcmRpbmF0ZSgpOw0KCSAgICAgIGlm
KChzdGF0dXMgPSBtc1F1ZXJ5QnlQb2ludChtc09iai0+TWFwLCBTZWxlY3RMYXllckluZGV4LCBN
U19TSU5HTEUsIG1zT2JqLT5NYXBQbnQsIDApKSAhPSBNU19TVUNDRVNTKSB3cml0ZUVycm9yKCk7
DQoJICAgICAgYnJlYWs7DQoJICAgIGNhc2UgRlJPTVVTRVJQTlQ6IC8qIG9ubHkgYSBidWZmZXIg
bWFrZXMgc2Vuc2UgKi8NCgkgICAgICBpZihtc09iai0+QnVmZmVyID09IC0xKSB7DQoJCW1zU2V0
RXJyb3IoTVNfV0VCRVJSLCAiUG9pbnQgZ2l2ZW4gYnV0IG5vIHNlYXJjaCBidWZmZXIgc3BlY2lm
aWVkLiIsICJtYXBzZXJ2KCkiKTsNCgkJd3JpdGVFcnJvcigpOw0KCSAgICAgIH0NCgkgICAgICBp
Zigoc3RhdHVzID0gbXNRdWVyeUJ5UG9pbnQobXNPYmotPk1hcCwgU2VsZWN0TGF5ZXJJbmRleCwg
TVNfU0lOR0xFLCBtc09iai0+TWFwUG50LCBtc09iai0+QnVmZmVyKSkgIT0gTVNfU1VDQ0VTUykg
d3JpdGVFcnJvcigpOw0KCSAgICAgIGJyZWFrOw0KCSAgICBkZWZhdWx0Og0KCSAgICAgIG1zU2V0
RXJyb3IoTVNfV0VCRVJSLCAiTm8gd2F5IHRvIHRoZSBpbml0aWFsIHNlYXJjaCwgbm90IGVub3Vn
aCBpbmZvcm1hdGlvbi4iLCAibWFwc2VydigpIik7DQoJICAgICAgd3JpdGVFcnJvcigpOw0KCSAg
ICAgIGJyZWFrOw0KCSAgICB9CSAgDQoJICB9IGVsc2UgeyAvKiBGRUFUVVJFTlFVRVJZL0ZFQVRV
UkVOUVVFUllNQVAgKi8NCgkgICAgc3dpdGNoKFF1ZXJ5Q29vcmRTb3VyY2UpIHsNCgkgICAgY2Fz
ZSBGUk9NSU1HUE5UOg0KCSAgICAgIG1zT2JqLT5NYXAtPmV4dGVudCA9IG1zT2JqLT5JbWdFeHQ7
IC8qIHVzZSB0aGUgZXhpc3RpbmcgbWFwIGV4dGVudCAqLwkNCgkgICAgICBzZXRDb29yZGluYXRl
KCk7DQoJICAgICAgaWYoKHN0YXR1cyA9IG1zUXVlcnlCeVBvaW50KG1zT2JqLT5NYXAsIFNlbGVj
dExheWVySW5kZXgsIE1TX01VTFRJUExFLCBtc09iai0+TWFwUG50LCAwKSkgIT0gTVNfU1VDQ0VT
Uykgd3JpdGVFcnJvcigpOw0KCSAgICAgIGJyZWFrOwkgDQoJICAgIGNhc2UgRlJPTUlNR0JPWDoN
CgkgICAgICBicmVhazsNCgkgICAgY2FzZSBGUk9NVVNFUlBOVDogLyogb25seSBhIGJ1ZmZlciBt
YWtlcyBzZW5zZSAqLw0KCSAgICAgIGlmKChzdGF0dXMgPSBtc1F1ZXJ5QnlQb2ludChtc09iai0+
TWFwLCBTZWxlY3RMYXllckluZGV4LCBNU19NVUxUSVBMRSwgbXNPYmotPk1hcFBudCwgbXNPYmot
PkJ1ZmZlcikpICE9IE1TX1NVQ0NFU1MpIHdyaXRlRXJyb3IoKTsNCgkgICAgZGVmYXVsdDoNCgkg
ICAgICBzZXRFeHRlbnQobXNPYmopOw0KCSAgICAgIGlmKChzdGF0dXMgPSBtc1F1ZXJ5QnlSZWN0
KG1zT2JqLT5NYXAsIFNlbGVjdExheWVySW5kZXgsIG1zT2JqLT5NYXAtPmV4dGVudCkpICE9IE1T
X1NVQ0NFU1MpIHdyaXRlRXJyb3IoKTsNCgkgICAgICBicmVhazsNCgkgICAgfQ0KCSAgfSAvKiBl
bmQgc3dpdGNoICovDQoJDQoJICBpZihtc1F1ZXJ5QnlGZWF0dXJlcyhtc09iai0+TWFwLCBRdWVy
eUxheWVySW5kZXgsIFNlbGVjdExheWVySW5kZXgpICE9IE1TX1NVQ0NFU1MpIHdyaXRlRXJyb3Io
KTsNCiAgICAgIA0KCSAgYnJlYWs7DQogICAgICAgIGNhc2UgSVRFTVFVRVJZOg0KCWNhc2UgSVRF
TU5RVUVSWToNCiAgICAgICAgY2FzZSBJVEVNUVVFUllNQVA6DQogICAgICAgIGNhc2UgSVRFTU5R
VUVSWU1BUDoNCg0KCSAgaWYoUXVlcnlDb29yZFNvdXJjZSAhPSBOT05FICYmICFtc09iai0+VXNl
U2hhcGVzKQ0KCSAgICBzZXRFeHRlbnQobXNPYmopOyAvKiBzZXQgdXNlciBhcmVhIG9mIGludGVy
ZXN0ICovDQoNCgkgIGlmKG1zT2JqLT5Nb2RlID09IElURU1RVUVSWSB8fCBtc09iai0+TW9kZSA9
PSBJVEVNUVVFUllNQVApIHsNCgkgICAgaWYoKHN0YXR1cyA9IG1zUXVlcnlCeUF0dHJpYnV0ZXMo
bXNPYmotPk1hcCwgUXVlcnlMYXllckluZGV4LCBRdWVyeUl0ZW0sIFF1ZXJ5U3RyaW5nLCBNU19T
SU5HTEUpKSAhPSBNU19TVUNDRVNTKSB3cml0ZUVycm9yKCk7DQoJICB9IGVsc2Ugew0KCSAgICBp
Zigoc3RhdHVzID0gbXNRdWVyeUJ5QXR0cmlidXRlcyhtc09iai0+TWFwLCBRdWVyeUxheWVySW5k
ZXgsIFF1ZXJ5SXRlbSwgUXVlcnlTdHJpbmcsIE1TX01VTFRJUExFKSkgIT0gTVNfU1VDQ0VTUykg
d3JpdGVFcnJvcigpOw0KICAgICAgICAgIH0NCg0KCSAgYnJlYWs7DQogICAgICAgIGNhc2UgTlFV
RVJZOg0KICAgICAgICBjYXNlIE5RVUVSWU1BUDoNCgkgIHN3aXRjaChRdWVyeUNvb3JkU291cmNl
KSB7DQoJICBjYXNlIEZST01JTUdQTlQ6CSAgDQoJICAgIHNldENvb3JkaW5hdGUoKTsNCgkgIA0K
CSAgICBpZihTZWFyY2hNYXApIHsgLy8gY29tcHV0ZSBuZXcgZXh0ZW50LCBwYW4gZXRjIHRoZW4g
c2VhcmNoIHRoYXQgZXh0ZW50DQoJICAgICAgc2V0RXh0ZW50KG1zT2JqKTsNCgkgICAgICBtc09i
ai0+TWFwLT5jZWxsc2l6ZSA9IG1zQWRqdXN0RXh0ZW50KCYobXNPYmotPk1hcC0+ZXh0ZW50KSwg
bXNPYmotPk1hcC0+d2lkdGgsIG1zT2JqLT5NYXAtPmhlaWdodCk7DQoJICAgICAgaWYoKHN0YXR1
cyA9IG1zQ2FsY3VsYXRlU2NhbGUobXNPYmotPk1hcC0+ZXh0ZW50LCBtc09iai0+TWFwLT51bml0
cywgbXNPYmotPk1hcC0+d2lkdGgsIG1zT2JqLT5NYXAtPmhlaWdodCwgbXNPYmotPk1hcC0+cmVz
b2x1dGlvbiwgJm1zT2JqLT5NYXAtPnNjYWxlKSkgIT0gTVNfU1VDQ0VTUykgd3JpdGVFcnJvcigp
Ow0KCSAgICAgIGlmKChzdGF0dXMgPSBtc1F1ZXJ5QnlSZWN0KG1zT2JqLT5NYXAsIFF1ZXJ5TGF5
ZXJJbmRleCwgbXNPYmotPk1hcC0+ZXh0ZW50KSkgIT0gTVNfU1VDQ0VTUykgd3JpdGVFcnJvcigp
Ow0KCSAgICB9IGVsc2Ugew0KCSAgICAgIG1zT2JqLT5NYXAtPmV4dGVudCA9IG1zT2JqLT5JbWdF
eHQ7IC8vIHVzZSB0aGUgZXhpc3RpbmcgaW1hZ2UgcGFyYW1ldGVycw0KCSAgICAgIG1zT2JqLT5N
YXAtPndpZHRoID0gbXNPYmotPkltZ0NvbHM7DQoJICAgICAgbXNPYmotPk1hcC0+aGVpZ2h0ID0g
bXNPYmotPkltZ1Jvd3M7DQoJICAgICAgaWYoKHN0YXR1cyA9IG1zQ2FsY3VsYXRlU2NhbGUobXNP
YmotPk1hcC0+ZXh0ZW50LCBtc09iai0+TWFwLT51bml0cywgbXNPYmotPk1hcC0+d2lkdGgsIG1z
T2JqLT5NYXAtPmhlaWdodCwgbXNPYmotPk1hcC0+cmVzb2x1dGlvbiwgJm1zT2JqLT5NYXAtPnNj
YWxlKSkgIT0gTVNfU1VDQ0VTUykgd3JpdGVFcnJvcigpOwkgDQoJICAgICAgaWYoKHN0YXR1cyA9
IG1zUXVlcnlCeVBvaW50KG1zT2JqLT5NYXAsIFF1ZXJ5TGF5ZXJJbmRleCwgTVNfTVVMVElQTEUs
IG1zT2JqLT5NYXBQbnQsIDApKSAhPSBNU19TVUNDRVNTKSB3cml0ZUVycm9yKCk7DQoJICAgIH0N
CgkgICAgYnJlYWs7CSAgDQoJICBjYXNlIEZST01JTUdCT1g6CSAgDQoJICAgIGlmKFNlYXJjaE1h
cCkgeyAvLyBjb21wdXRlIG5ldyBleHRlbnQsIHBhbiBldGMgdGhlbiBzZWFyY2ggdGhhdCBleHRl
bnQNCgkgICAgICBzZXRFeHRlbnQobXNPYmopOw0KCSAgICAgIGlmKChzdGF0dXMgPSBtc0NhbGN1
bGF0ZVNjYWxlKG1zT2JqLT5NYXAtPmV4dGVudCwgbXNPYmotPk1hcC0+dW5pdHMsIG1zT2JqLT5N
YXAtPndpZHRoLCBtc09iai0+TWFwLT5oZWlnaHQsIG1zT2JqLT5NYXAtPnJlc29sdXRpb24sICZt
c09iai0+TWFwLT5zY2FsZSkpICE9IE1TX1NVQ0NFU1MpIHdyaXRlRXJyb3IoKTsNCgkgICAgICBt
c09iai0+TWFwLT5jZWxsc2l6ZSA9IG1zQWRqdXN0RXh0ZW50KCYobXNPYmotPk1hcC0+ZXh0ZW50
KSwgbXNPYmotPk1hcC0+d2lkdGgsIG1zT2JqLT5NYXAtPmhlaWdodCk7DQoJICAgICAgaWYoKHN0
YXR1cyA9IG1zUXVlcnlCeVJlY3QobXNPYmotPk1hcCwgUXVlcnlMYXllckluZGV4LCBtc09iai0+
TWFwLT5leHRlbnQpKSAhPSBNU19TVUNDRVNTKSB3cml0ZUVycm9yKCk7DQoJICAgIH0gZWxzZSB7
DQoJICAgICAgZG91YmxlIGNlbGx4LCBjZWxseTsNCgkgICAgDQoJICAgICAgbXNPYmotPk1hcC0+
ZXh0ZW50ID0gbXNPYmotPkltZ0V4dDsgLy8gdXNlIHRoZSBleGlzdGluZyBpbWFnZSBwYXJhbWV0
ZXJzDQoJICAgICAgbXNPYmotPk1hcC0+d2lkdGggPSBtc09iai0+SW1nQ29sczsNCgkgICAgICBt
c09iai0+TWFwLT5oZWlnaHQgPSBtc09iai0+SW1nUm93czsNCgkgICAgICBpZigoc3RhdHVzID0g
bXNDYWxjdWxhdGVTY2FsZShtc09iai0+TWFwLT5leHRlbnQsIG1zT2JqLT5NYXAtPnVuaXRzLCBt
c09iai0+TWFwLT53aWR0aCwgbXNPYmotPk1hcC0+aGVpZ2h0LCBtc09iai0+TWFwLT5yZXNvbHV0
aW9uLCAmbXNPYmotPk1hcC0+c2NhbGUpKSAhPSBNU19TVUNDRVNTKSB3cml0ZUVycm9yKCk7CSAg
DQoJICAgIA0KCSAgICAgIGNlbGx4ID0gTVNfQ0VMTFNJWkUobXNPYmotPkltZ0V4dC5taW54LCBt
c09iai0+SW1nRXh0Lm1heHgsIG1zT2JqLT5JbWdDb2xzKTsgLy8gY2FsY3VsYXRlIHRoZSBuZXcg
c2VhcmNoIGV4dGVudA0KCSAgICAgIGNlbGx5ID0gTVNfQ0VMTFNJWkUobXNPYmotPkltZ0V4dC5t
aW55LCBtc09iai0+SW1nRXh0Lm1heHksIG1zT2JqLT5JbWdSb3dzKTsNCgkgICAgICBtc09iai0+
UmF3RXh0Lm1pbnggPSBNU19JTUFHRTJNQVBfWChtc09iai0+SW1nQm94Lm1pbngsIG1zT2JqLT5J
bWdFeHQubWlueCwgY2VsbHgpOwkgICAgICANCgkgICAgICBtc09iai0+UmF3RXh0Lm1heHggPSBN
U19JTUFHRTJNQVBfWChtc09iai0+SW1nQm94Lm1heHgsIG1zT2JqLT5JbWdFeHQubWlueCwgY2Vs
bHgpOw0KCSAgICAgIG1zT2JqLT5SYXdFeHQubWF4eSA9IE1TX0lNQUdFMk1BUF9ZKG1zT2JqLT5J
bWdCb3gubWlueSwgbXNPYmotPkltZ0V4dC5tYXh5LCBjZWxseSk7IC8vIHkncyBhcmUgZmxpcCBm
bG9wcGVkIGJlY2F1c2UgaW1nL21hcCBjb29yZGluYXRlIHN5c3RlbXMgYXJlDQoJICAgICAgbXNP
YmotPlJhd0V4dC5taW55ID0gTVNfSU1BR0UyTUFQX1kobXNPYmotPkltZ0JveC5tYXh5LCBtc09i
ai0+SW1nRXh0Lm1heHksIGNlbGx5KTsNCg0KCSAgICAgIGlmKChzdGF0dXMgPSBtc1F1ZXJ5QnlS
ZWN0KG1zT2JqLT5NYXAsIFF1ZXJ5TGF5ZXJJbmRleCwgbXNPYmotPlJhd0V4dCkpICE9IE1TX1NV
Q0NFU1MpIHdyaXRlRXJyb3IoKTsNCgkgICAgfQ0KCSAgICBicmVhazsNCgkgIGNhc2UgRlJPTUlN
R1NIQVBFOg0KCSAgICBtc09iai0+TWFwLT5leHRlbnQgPSBtc09iai0+SW1nRXh0OyAvLyB1c2Ug
dGhlIGV4aXN0aW5nIGltYWdlIHBhcmFtZXRlcnMNCgkgICAgbXNPYmotPk1hcC0+d2lkdGggPSBt
c09iai0+SW1nQ29sczsNCgkgICAgbXNPYmotPk1hcC0+aGVpZ2h0ID0gbXNPYmotPkltZ1Jvd3M7
DQoJICAgIG1zT2JqLT5NYXAtPmNlbGxzaXplID0gbXNBZGp1c3RFeHRlbnQoJihtc09iai0+TWFw
LT5leHRlbnQpLCBtc09iai0+TWFwLT53aWR0aCwgbXNPYmotPk1hcC0+aGVpZ2h0KTsNCgkgICAg
aWYoKHN0YXR1cyA9IG1zQ2FsY3VsYXRlU2NhbGUobXNPYmotPk1hcC0+ZXh0ZW50LCBtc09iai0+
TWFwLT51bml0cywgbXNPYmotPk1hcC0+d2lkdGgsIG1zT2JqLT5NYXAtPmhlaWdodCwgbXNPYmot
Pk1hcC0+cmVzb2x1dGlvbiwgJm1zT2JqLT5NYXAtPnNjYWxlKSkgIT0gTVNfU1VDQ0VTUykgd3Jp
dGVFcnJvcigpOw0KCSAgDQoJICAgIC8vIGNvbnZlcnQgZnJvbSBpbWFnZSB0byBtYXAgY29vcmRp
bmF0ZXMgaGVyZSAoc2VlIHNldENvb3JkaW5hdGUpDQoJICAgIGZvcihpPTA7IGk8bXNPYmotPlNl
bGVjdFNoYXBlLm51bWxpbmVzOyBpKyspIHsNCgkgICAgICBmb3Ioaj0wOyBqPG1zT2JqLT5TZWxl
Y3RTaGFwZS5saW5lW2ldLm51bXBvaW50czsgaisrKSB7DQoJICAgICAgICBtc09iai0+U2VsZWN0
U2hhcGUubGluZVtpXS5wb2ludFtqXS54ID0gTVNfSU1BR0UyTUFQX1gobXNPYmotPlNlbGVjdFNo
YXBlLmxpbmVbaV0ucG9pbnRbal0ueCwgbXNPYmotPk1hcC0+ZXh0ZW50Lm1pbngsIG1zT2JqLT5N
YXAtPmNlbGxzaXplKTsNCgkgICAgICAgIG1zT2JqLT5TZWxlY3RTaGFwZS5saW5lW2ldLnBvaW50
W2pdLnkgPSBNU19JTUFHRTJNQVBfWShtc09iai0+U2VsZWN0U2hhcGUubGluZVtpXS5wb2ludFtq
XS55LCBtc09iai0+TWFwLT5leHRlbnQubWF4eSwgbXNPYmotPk1hcC0+Y2VsbHNpemUpOw0KCSAg
ICAgIH0NCgkgICAgfQ0KCSAgDQoJICAgIGlmKChzdGF0dXMgPSBtc1F1ZXJ5QnlTaGFwZShtc09i
ai0+TWFwLCBRdWVyeUxheWVySW5kZXgsICZtc09iai0+U2VsZWN0U2hhcGUpKSAhPSBNU19TVUND
RVNTKSB3cml0ZUVycm9yKCk7DQoJICAgIGJyZWFrOwkgIA0KCSAgY2FzZSBGUk9NVVNFUlBOVDoN
CgkgICAgaWYobXNPYmotPkJ1ZmZlciA9PSAwKSB7DQoJICAgICAgaWYoKHN0YXR1cyA9IG1zUXVl
cnlCeVBvaW50KG1zT2JqLT5NYXAsIFF1ZXJ5TGF5ZXJJbmRleCwgTVNfTVVMVElQTEUsIG1zT2Jq
LT5NYXBQbnQsIG1zT2JqLT5CdWZmZXIpKSAhPSBNU19TVUNDRVNTKSB3cml0ZUVycm9yKCk7DQoJ
ICAgICAgc2V0RXh0ZW50KG1zT2JqKTsNCgkgICAgfSBlbHNlIHsNCgkgICAgICBzZXRFeHRlbnQo
bXNPYmopOw0KCSAgICAgIGlmKChzdGF0dXMgPSBtc1F1ZXJ5QnlSZWN0KG1zT2JqLT5NYXAsIFF1
ZXJ5TGF5ZXJJbmRleCwgbXNPYmotPk1hcC0+ZXh0ZW50KSkgIT0gTVNfU1VDQ0VTUykgd3JpdGVF
cnJvcigpOw0KCSAgICB9DQoJICAgIGJyZWFrOw0KCSAgY2FzZSBGUk9NVVNFUlNIQVBFOg0KCSAg
ICBzZXRFeHRlbnQobXNPYmopOw0KCSAgICBpZigoc3RhdHVzID0gbXNRdWVyeUJ5U2hhcGUobXNP
YmotPk1hcCwgUXVlcnlMYXllckluZGV4LCAmbXNPYmotPlNlbGVjdFNoYXBlKSkgIT0gTVNfU1VD
Q0VTUykgd3JpdGVFcnJvcigpOw0KCSAgICBicmVhazsJICANCgkgIGRlZmF1bHQ6IC8vIGZyb20g
YW4gZXh0ZW50IG9mIHNvbWUgc29ydA0KCSAgICBzZXRFeHRlbnQobXNPYmopOw0KCSAgICBpZigo
c3RhdHVzID0gbXNRdWVyeUJ5UmVjdChtc09iai0+TWFwLCBRdWVyeUxheWVySW5kZXgsIG1zT2Jq
LT5NYXAtPmV4dGVudCkpICE9IE1TX1NVQ0NFU1MpIHdyaXRlRXJyb3IoKTsNCgkgICAgYnJlYWs7
DQoJICB9ICAgICAgDQoJICBicmVhazsNCiAgICAgICAgY2FzZSBRVUVSWToNCiAgICAgICAgY2Fz
ZSBRVUVSWU1BUDoNCgkgIHN3aXRjaChRdWVyeUNvb3JkU291cmNlKSB7DQoJICBjYXNlIEZST01J
TUdQTlQ6DQoJICAgIHNldENvb3JkaW5hdGUoKTsNCgkgICAgbXNPYmotPk1hcC0+ZXh0ZW50ID0g
bXNPYmotPkltZ0V4dDsgLy8gdXNlIHRoZSBleGlzdGluZyBpbWFnZSBwYXJhbWV0ZXJzDQoJICAg
IG1zT2JqLT5NYXAtPndpZHRoID0gbXNPYmotPkltZ0NvbHM7DQoJICAgIG1zT2JqLT5NYXAtPmhl
aWdodCA9IG1zT2JqLT5JbWdSb3dzOw0KCSAgICBpZigoc3RhdHVzID0gbXNDYWxjdWxhdGVTY2Fs
ZShtc09iai0+TWFwLT5leHRlbnQsIG1zT2JqLT5NYXAtPnVuaXRzLCBtc09iai0+TWFwLT53aWR0
aCwgbXNPYmotPk1hcC0+aGVpZ2h0LCBtc09iai0+TWFwLT5yZXNvbHV0aW9uLCAmbXNPYmotPk1h
cC0+c2NhbGUpKSAhPSBNU19TVUNDRVNTKSB3cml0ZUVycm9yKCk7CSAJICANCgkgICAgaWYoKHN0
YXR1cyA9IG1zUXVlcnlCeVBvaW50KG1zT2JqLT5NYXAsIFF1ZXJ5TGF5ZXJJbmRleCwgTVNfU0lO
R0xFLCBtc09iai0+TWFwUG50LCAwKSkgIT0gTVNfU1VDQ0VTUykgd3JpdGVFcnJvcigpOw0KCSAg
ICBicmVhazsNCgkgIA0KCSAgY2FzZSBGUk9NVVNFUlBOVDogLyogb25seSBhIGJ1ZmZlciBtYWtl
cyBzZW5zZSwgRE9FUyBJVD8gKi8JDQoJICAgIHNldEV4dGVudChtc09iaik7CQ0KCSAgICBpZigo
c3RhdHVzID0gbXNRdWVyeUJ5UG9pbnQobXNPYmotPk1hcCwgUXVlcnlMYXllckluZGV4LCBNU19T
SU5HTEUsIG1zT2JqLT5NYXBQbnQsIG1zT2JqLT5CdWZmZXIpKSAhPSBNU19TVUNDRVNTKSB3cml0
ZUVycm9yKCk7DQoJICAgIGJyZWFrOw0KCSAgDQoJICBkZWZhdWx0Og0KCSAgICBtc1NldEVycm9y
KE1TX1dFQkVSUiwgIlF1ZXJ5IG1vZGUgbmVlZHMgYSBwb2ludCwgaW1neHkgYW5kIG1hcHh5IGFy
ZSBub3Qgc2V0LiIsICJtYXBzZXJ2KCkiKTsNCgkgICAgd3JpdGVFcnJvcigpOw0KCSAgICBicmVh
azsNCgkgIH0NCgkgIGJyZWFrOw0KICAgICAgICBjYXNlIElOREVYUVVFUlk6DQogICAgICAgIGNh
c2UgSU5ERVhRVUVSWU1BUDoNCgkgIGlmKChzdGF0dXMgPSBtc1F1ZXJ5QnlJbmRleChtc09iai0+
TWFwLCBRdWVyeUxheWVySW5kZXgsIFRpbGVJbmRleCwgU2hhcGVJbmRleCkpICE9IE1TX1NVQ0NF
U1MpIHdyaXRlRXJyb3IoKTsNCgkgIGJyZWFrOw0KICAgICAgICB9IC8vIGVuZCBtb2RlIHN3aXRj
aA0KICAgICAgfQ0KCSAgDQogICAgICBpZihtc09iai0+TWFwLT5xdWVyeW1hcC53aWR0aCAhPSAt
MSkgbXNPYmotPk1hcC0+d2lkdGggPSBtc09iai0+TWFwLT5xdWVyeW1hcC53aWR0aDsgLy8gbWFr
ZSBzdXJlIHdlIHVzZSB0aGUgcmlnaHQgc2l6ZQ0KICAgICAgaWYobXNPYmotPk1hcC0+cXVlcnlt
YXAuaGVpZ2h0ICE9IC0xKSBtc09iai0+TWFwLT5oZWlnaHQgPSBtc09iai0+TWFwLT5xdWVyeW1h
cC5oZWlnaHQ7DQoNCiAgICAgIGlmKG1zT2JqLT5Vc2VTaGFwZXMpDQoJc2V0RXh0ZW50RnJvbVNo
YXBlcygpOw0KDQogICAgICAvLyBqdXN0IHJldHVybiB0aGUgaW1hZ2UNCiAgICAgIGlmKG1zT2Jq
LT5Nb2RlID09IFFVRVJZTUFQIHx8IG1zT2JqLT5Nb2RlID09IE5RVUVSWU1BUCB8fCBtc09iai0+
TW9kZSA9PSBJVEVNUVVFUllNQVAgfHwgbXNPYmotPk1vZGUgPT0gSVRFTU5RVUVSWU1BUCB8fCBt
c09iai0+TW9kZSA9PSBGRUFUVVJFUVVFUllNQVAgfHwgbXNPYmotPk1vZGUgPT0gRkVBVFVSRU5R
VUVSWU1BUCB8fCBtc09iai0+TW9kZSA9PSBJVEVNRkVBVFVSRVFVRVJZTUFQIHx8IG1zT2JqLT5N
b2RlID09IElURU1GRUFUVVJFTlFVRVJZTUFQIHx8IG1zT2JqLT5Nb2RlID09IElOREVYUVVFUllN
QVApIHsNCg0KCWNoZWNrV2ViU2NhbGUobXNPYmopOw0KDQoJaW1nID0gbXNEcmF3UXVlcnlNYXAo
bXNPYmotPk1hcCk7DQoJaWYoIWltZykgd3JpdGVFcnJvcigpOw0KDQoJcHJpbnRmKCJDb250ZW50
LXR5cGU6ICVzJWMlYyIsTVNfSU1BR0VfTUlNRV9UWVBFKG1zT2JqLT5NYXAtPm91dHB1dGZvcm1h
dCksIDEwLDEwKTsNCglzdGF0dXMgPSBtc1NhdmVJbWFnZShtc09iai0+TWFwLCBpbWcsIE5VTEwp
Ow0KCWlmKHN0YXR1cyAhPSBNU19TVUNDRVNTKSB3cml0ZUVycm9yKCk7DQoJbXNGcmVlSW1hZ2Uo
aW1nKTsNCg0KICAgICAgfSANCiAgICAgICBlbHNlIHsgLy8gcHJvY2VzcyB0aGUgcXVlcnkgdGhy
b3VnaCB0ZW1wbGF0ZXMNCiAgICAgICAgICBpZiAobXNSZXR1cm5UZW1wbGF0ZVF1ZXJ5KG1zT2Jq
LCAidGV4dC9odG1sIikgIT0gTVNfU1VDQ0VTUykgd3JpdGVFcnJvcigpOw0KICAgICAgICAgIA0K
ICAgICAgICAgIGlmKG1zT2JqLT5TYXZlUXVlcnkpIHsNCiAgICAgICAgICAgICBzcHJpbnRmKGJ1
ZmZlciwgIiVzJXMlcyVzIiwgbXNPYmotPk1hcC0+d2ViLmltYWdlcGF0aCwgbXNPYmotPk1hcC0+
bmFtZSwgbXNPYmotPklkLCBNU19RVUVSWV9FWFRFTlNJT04pOw0KICAgICAgICAgICAgIGlmKChz
dGF0dXMgPSBtc1NhdmVRdWVyeShtc09iai0+TWFwLCBidWZmZXIpKSAhPSBNU19TVUNDRVNTKSBy
ZXR1cm4gc3RhdHVzOw0KICAgICAgICAgIH0NCiAgICAgICB9DQoNCiAgICB9IGVsc2UgaWYobXNP
YmotPk1vZGUgPT0gQ09PUkRJTkFURSkgew0KICAgICAgc2V0Q29vcmRpbmF0ZSgpOyAvLyBtb3Vz
ZSBjbGljayA9PiBtYXAgY29vcmQNCiAgICAgIHJldHVybkNvb3JkaW5hdGUobXNPYmotPk1hcFBu
dCk7DQogICAgfSBlbHNlIGlmKG1zT2JqLT5Nb2RlID09IFBST0NFU1NJTkcpIHsNCiNpZmRlZiBV
U0VfRUdJUw0KICAgICAgc2V0RXh0ZW50KG1zT2JqKTsNCiAgICAgIGVyckxvZ01zZ1swXSA9ICdc
MCc7DQogICAgICBzcHJpbnRmKGVyckxvZ01zZywgIk1hcCBDb29yZGluYXRlczogeCAlZiwgeSAl
ZlxuIiwgbXNPYmotPk1hcFBudC54LCBtc09iai0+TWFwUG50LnkpOw0KICAgICAgd3JpdGVFcnJM
b2coZXJyTG9nTXNnKTsNCiAgICAgIA0KICAgICAgc3RhdHVzID0gZWdpc2wobXNPYmotPk1hcCwg
RW50cmllcywgbXNPYmotPk51bVBhcmFtcywgbXNPYmotPkNvb3JkU291cmNlKTsNCiAgICAgIC8v
IHByaW50ZigiTnVtZXJpY2FsIFdpbmRvdyAtICVmICVmXG4iLCBtc09iai0+SW1nUG50LngsIG1z
T2JqLT5JbWdQbnQueSk7DQogICAgICBmZmx1c2goc3Rkb3V0KTsNCiAgICAgIA0KICAgICAgaWYg
KHN0YXR1cyA9PSAxKSB7DQoJLy8gd3JpdGUgTUlNRSBoZWFkZXINCglwcmludGYoIkNvbnRlbnQt
dHlwZTogdGV4dC9odG1sJWMlYyIsIDEwLCAxMCk7DQoJcmV0dXJuU3RhdGlzdGljcygibnVtd2lu
Lmh0bWwiKTsNCiAgICAgIH0gZWxzZSBpZihzdGF0dXMgPT0gMikgew0KCXdyaXRlRXJyTG9nKCJD
YWxsaW5nIHJldHVyblNwbG90KClcbiIpOw0KCWZmbHVzaChmcEVyckxvZyk7DQoJDQoJLy8gd3Jp
dGUgTUlNRSBoZWFkZXINCglwcmludGYoIkNvbnRlbnQtdHlwZTogdGV4dC9odG1sJWMlYyIsIDEw
LCAxMCk7DQoJcmV0dXJuU3Bsb3QoInNwbG90Lmh0bWwiKTsNCiAgICAgIH0gZWxzZSBpZihzdGF0
dXMgPT0gMykgew0KCXdyaXRlRXJyTG9nKCJDYWxsaW5nIHJldHVybkhpc3RvKClcbiIpOw0KCWZm
bHVzaChmcEVyckxvZyk7DQoJDQoJLy8gd3JpdGUgTUlNRSBoZWFkZXINCglwcmludGYoIkNvbnRl
bnQtdHlwZTogdGV4dC9odG1sJWMlYyIsIDEwLCAxMCk7DQoJcmV0dXJuSGlzdG8oImhpc3RvLmh0
bWwiKTsNCiAgICAgIH0gZWxzZSB7DQoJd3JpdGVFcnJMb2coIkVycm9yIHN0YXR1cyBmcm9tIGVn
aXNsKClcbiIpOw0KCWZmbHVzaChmcEVyckxvZyk7DQoJDQoJZXJyTG9nTXNnWzBdID0gJ1wwJzsN
CglzcHJpbnRmKGVyckxvZ01zZywgIlNlbGVjdCBJbWFnZSBMYXllclxuIik7DQoJDQoJbXNTZXRF
cnJvcihNU19JT0VSUiwgIjxicj5lR0lTIEVycm9yOiBDaG9vc2UgU3RhY2sgSW1hZ2U8YnI+Iiwg
ZXJyTG9nTXNnKTsNCgl3cml0ZUVycm9yKCk7DQogICAgICB9DQojZWxzZQ0KICAgICAgbXNTZXRF
cnJvcihNU19NSVNDRVJSLCAiRUdJUyBTdXBwb3J0IGlzIG5vdCBhdmFpbGFibGUuIiwgIm1hcHNl
cnYoKSIpOw0KICAgICAgd3JpdGVFcnJvcigpOw0KI2VuZGlmDQogICAgfQ0KDQogICAgd3JpdGVM
b2coTVNfRkFMU0UpOw0KICAgDQogICAgLyoNCiAgICAqKiBDbGVhbi11cA0KICAgICovDQogICAg
ZnJlZShJdGVtKTsgLy8gdGhlIGZvbGxvd2luZyBhcmUgbm90IHN0b3JlZCBhcyBwYXJ0IG9mIHRo
ZSBtc09iag0KICAgIGZyZWUoVmFsdWUpOyAgICAgIA0KICAgIGZyZWUoUXVlcnlMYXllcik7DQog
ICAgZnJlZShTZWxlY3RMYXllcik7DQogICAgZnJlZShRdWVyeUZpbGUpOyAgICANCiAgIA0KICAg
IG1zRnJlZU1hcFNlcnZPYmoobXNPYmopOw0KDQogICAgZXhpdCgwKTsgLy8gZW5kIE1hcFNlcnZl
cg0KfSANCg==
------_=_NextPart_002_01C2CBCC.2AA56D66--
------_=_NextPart_001_01C2D9C1.AC928D21--
From woodbri at swoodbridge.com Fri Feb 21 11:04:55 2003
From: woodbri at swoodbridge.com (woodbri@swoodbridge.com)
Date: Fri Feb 8 14:56:37 2008
Subject: [Mapserver-dev] OUTPUTFORMAT selection and IMAGETYPE parameter
Message-ID:
FYI, I filed a bug [Bug 285] New: Set default IMAGETYPE to 1st User defined OUTPUTFORMAT related to my problem with this.
-Steve
From steve.lime at dnr.state.mn.us Tue Feb 25 12:25:37 2003
From: steve.lime at dnr.state.mn.us (Steve Lime)
Date: Fri Feb 8 14:56:37 2008
Subject: [Mapserver-dev] New function, msWriteErrorImage()...
Message-ID:
Hi folks: I wanted to add in-image error reporting to the CGI
application so I pilfered that support from the WMS
code to create the function msWriteErrorImage. It's basically identical
to the WMS code so we should be able to
swap it out, and I'll use it in the CGI too. Might also be a nice to
have with MapScript although in that case it should
probably return an imageObj to let the script do the writing. Function
takes 3 arguments:
- a map file (although the size and format args could be passed)
- filename (NULL gets you stdout and a MIME type)
- blank (true/false, actually toggles writing in the image, WMS needs
that I guess)
I've just commited the function, haven't actually placed it anywhere.
Comments?
Steve
Stephen Lime
Data & Applications Manager
Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-297-2937
From morissette at dmsolutions.ca Tue Feb 25 15:02:05 2003
From: morissette at dmsolutions.ca (Daniel Morissette)
Date: Fri Feb 8 14:56:37 2008
Subject: [Mapserver-dev] New function, msWriteErrorImage()...
References:
Message-ID: <3E5BCBBD.99239EF0@dmsolutions.ca>
Steve Lime wrote:
>
> Hi folks: I wanted to add in-image error reporting to the CGI
> application so I pilfered that support from the WMS
> code to create the function msWriteErrorImage. It's basically identical
> to the WMS code so we should be able to
> swap it out, and I'll use it in the CGI too. Might also be a nice to
> have with MapScript although in that case it should
> probably return an imageObj to let the script do the writing. Function
> takes 3 arguments:
>
> - a map file (although the size and format args could be passed)
> - filename (NULL gets you stdout and a MIME type)
> - blank (true/false, actually toggles writing in the image, WMS needs
> that I guess)
>
> I've just commited the function, haven't actually placed it anywhere.
> Comments?
>
I think that's a great idea. In theory I think it would be better if
the function took (format,w,h) as arguments instead of a mapObj since we
may want to use it in contexts where we don't have a mapObj, but in
practice in MapScript (in PHP anyway) we need to create a mapObj in
order to create an outputFormatObj, so I guess we'll just keep things
like this for now.
To answer your other questions: yes, blank is for WMS, it allows a
client to request that in case of errors he gets a blank transparent
image that won't interefere with the main map.
With respect to exposing the function to MapScript, we could split
msWriteErrorImage() in two parts: the core of it could become a new
msGetErrorImage() that returns an imageObj. Then msWriteErrorImage()
would call msGetErrorImage() and write the image to the file.
FYI I have updated mapwms.c to use your function and it seems to work
fine for the WMS case.
Daniel
--
------------------------------------------------------------
Daniel Morissette morissette@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
From steve.lime at dnr.state.mn.us Wed Feb 26 16:38:43 2003
From: steve.lime at dnr.state.mn.us (Steve Lime)
Date: Fri Feb 8 14:56:37 2008
Subject: [Mapserver-dev] Simplifiying API's, yet another idea...
Message-ID:
Since we've got pointers from layerObj to the parent mapObj, and could
do the same for classObj etc... We could dramatically simplify the C and
MapScript API's by leveraging those relationships. What do folks think?
Yes, 3.7 is overdue but it's a major release so now might be the
time...
Steve
Stephen Lime
Data & Applications Manager
Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-297-2937
From steve.lime at dnr.state.mn.us Wed Feb 26 17:16:25 2003
From: steve.lime at dnr.state.mn.us (Steve Lime)
Date: Fri Feb 8 14:56:37 2008
Subject: [Mapserver-dev] Coding Standards
Message-ID:
Subject says it all. Depending on who wrote the code rumaging through
the source can be kinda trying. I'm thinking we need a document that
lays out coding standards, especially as the list of developers grows.
For example, I like the naming convension that some folks use for
function parameters and local variables and would like to adopt that
myself. However, I (personally) hate if-then's or function calls that
span multiple lines- have to scroll too much when editing. Thoughts?
Steve
Stephen Lime
Data & Applications Manager
Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-297-2937
From morissette at dmsolutions.ca Wed Feb 26 17:37:44 2003
From: morissette at dmsolutions.ca (Daniel Morissette)
Date: Fri Feb 8 14:56:37 2008
Subject: [Mapserver-dev] Coding Standards
References:
Message-ID: <3E5D41B8.836C687C@dmsolutions.ca>
Steve Lime wrote:
>
> Subject says it all. Depending on who wrote the code rumaging through
> the source can be kinda trying. I'm thinking we need a document that
> lays out coding standards, especially as the list of developers grows.
> For example, I like the naming convension that some folks use for
> function parameters and local variables and would like to adopt that
> myself. However, I (personally) hate if-then's or function calls that
> span multiple lines- have to scroll too much when editing. Thoughts?
>
Hi Steve,
I agree that a common coding style would be very welcome. I attached
below the bases of the coding style that we try to follow at DM
Solutions, it also matches what Frank uses for his libs (GDAL, OGR,
shapelib, etc.). You'll notice that it's extremely simple, just enough
to keep the code clean without making it too complicated for new
developers to learn and follow the rules.
I'm not saying MapServer-Dev should adopt this coding style, but of
course it would be easier for us if we did. ;) I'm sending it to the
group as a base for discussion.
I would like to elaborate more but I'm taking off right now and will be
back only on Monday. I'm sure others will have many ideas. Hopefully
Frank and Assefa will defend the value of this coding style in my
absence. ;)
Daniel
P.S. Contrary to you I have don't like if-then blocks that start at the
end of the line and I much prefer having brackets on separate lines, but
that's just a natural preference and I respect your choice.
--
------------------------------------------------------------
Daniel Morissette morissette@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
The rules that MUST be followed:
--------------------------------
1- Make our code fit in 80 columns unless it's not practical to do so
because of a long function name or an expression that would become
unreadable if broken on several lines.
2- NO TABS... set your editor to produce spaces instead of tabs...
that's because some editors use 4 chars tabs and some use 8 chars and
everything looks screwed up if you allow the use of tab chars.
#1 and #2 are also a requirement with some of our external clients like
Safe.
3- Brackets... we use this
if (...)
{
...;
}
else
{
...;
}
More flexible rules: (some may not apply depending on context)
--------------------
4- Indent is 4 chars usually. We've used 2 chars in some places but we
try to stick to 4.
5- Use hungarian notation for variables (makes more sense in C than in
PHP):
Prefix Description
------ ----------------------------
b Boolean
c Char
n Integer value
i Integer, used as a counter in a loop for instance
(we also often use the vars i, j, or k for counters)
f Float, single precision
d Double precision Float (we also use "df" sometimes)
sz String zero-terminated (a C string!)
by Byte
o Object
s Structure
fp FILE *
a Array of ...
p Pointer to ...
k Constant
m Class member variable (we also use "m_" sometimes)
g Global variable
Examples:
---------
char szFilename[100];
char *pszFilename;
int nProjectId;
int i, j, k;
int iField;
double dX, dY;
char **papszLines;
TABFile *poSrcFile;
GBool bSuccess;
6- Function and variable names use upper-lowercase combinations instead
of underscores, e.g. int nProjectId instead of project_id,
7- Filenames and directory names:
- Avoid spaces or special non-alphanumerical characters in
filenames.
The safe characters to use in filenames are "a-z", "0-9", "_" and
"."
- Avoid uppercases in filenames, except for special files that
should
show up at the top of a directory listing like README.TXT,
INSTALL.TXT, etc. For the rest try to stick to lowercase-only
filenames, that makes our lives much easier when porting code
between Windows and Unix.
8- Comments... quite flexible... we most of the time use something like
this for function headers:
/*****************************************************************
* MyFunction()
*
* This function will do something pretty cool. It expects numbers
* as arguments and returns a pointer to a buffer newly allocated.
*
* The caller should free the returned buffer. NULL is returned in
* case of error.
*****************************************************************/
and for comments inline, it's either a short one-line /*... */ thing, or
if it's longer then we sometimes use the following to also act as a
delimiter of an important part of a function:
/* --------------------------------------------------------------
* OK, this is an interesting comment...
* -------------------------------------------------------------- */
Some people (Frank and Assefa at least) use some Emacs macros
to automatically format these comments.
From warmerdam at pobox.com Thu Feb 27 10:45:41 2003
From: warmerdam at pobox.com (Frank Warmerdam)
Date: Fri Feb 8 14:56:37 2008
Subject: [Mapserver-dev] Coding Standards
In-Reply-To: <3E5D41B8.836C687C@dmsolutions.ca>
References: <3E5D41B8.836C687C@dmsolutions.ca>
Message-ID: <3E5E32A5.9060201@pobox.com>
Steve Lime wrote:
>>Subject says it all. Depending on who wrote the code rumaging through
>>the source can be kinda trying. I'm thinking we need a document that
>>lays out coding standards, especially as the list of developers grows.
>>For example, I like the naming convension that some folks use for
>>function parameters and local variables and would like to adopt that
>>myself. However, I (personally) hate if-then's or function calls that
>>span multiple lines- have to scroll too much when editing. Thoughts?
Steve,
I can't say that I am excited at the concept of setting out code style
guidelines for MapServer. While for some time I tried to fit into the
existing MapServer style, I see on review that have slipped into increasing
amounts of my own variable naming conventions in some modules.
So contrary to Daniel's position, I would be happy enough to have the issue
drop! My general position in GDAL has been, people should fit into the style
of the module (file) they are working on, and for new files they write, they
can do it in any reasonable style.
If we were to select one, it would seem expedient for it to match the
bulk of material already written by Steve rather than the PCI derived style
that Assefa, Daniel and I tend to use. I would add that I am not interested
in spending a bunch of time reworking styles.
I would like to suggest we develop a standard file header style, and for
this I *would* propose what Daniel, Assefa and I have been using. See
mapogr.cpp or mapresample.c as examples.
Furthermore, I would like to see CVS ids embedded in the object files.
In GDAL I do this by including the following macro in each source file,
just after the include files:
CPL_CVSID("$Id: gdalopen.cpp,v 1.18 2003/02/03 05:09:31 warmerda Exp $");
CPL_CVSID is defined as follows, but the idea is basically to create
a static variable in each module that contains the CVS $Id$ string. Then
the "ident" (or strings) program can be used to find the exact CVS version
of all source files used in a binary or shared library.
#ifndef DISABLE_CVSID
# define CPL_CVSID(string) static char cpl_cvsid[] = string; \
static char *cvsid_aw() { return( cvsid_aw() ? ((char *) NULL) : cpl_cvsid ); }
#else
# define CPL_CVSID(string)
#endif
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
From john_mapserver at hotmail.com Thu Feb 27 13:31:19 2003
From: john_mapserver at hotmail.com (John Newton)
Date: Fri Feb 8 14:56:37 2008
Subject: [Mapserver-dev] Thread safe issue
Message-ID:
In several version of gd.lib we have noticed that gdImageStringTTF() is not
thread safe due to font caching logic.
Could a new TLOCK be added to protect calls to gdImageStringTTF()?
thanks,
John Newton
From warmerdam at pobox.com Thu Feb 27 14:22:59 2003
From: warmerdam at pobox.com (Frank Warmerdam)
Date: Fri Feb 8 14:56:37 2008
Subject: [Mapserver-dev] Thread safe issue
In-Reply-To:
References:
Message-ID: <3E5E6593.9080602@pobox.com>
John Newton wrote:
> In several version of gd.lib we have noticed that gdImageStringTTF() is not
> thread safe due to font caching logic.
>
> Could a new TLOCK be added to protect calls to gdImageStringTTF()?
>
> thanks,
> John Newton
John,
Are you willing to test it if I commit changes to CVS to protect all
gdImageStringTTF calls with a lock? Note that thanks to Dylan we now have
a gd support contract, and if there are any threading issues in gd that people
need fixed we could pursue the issue with the maintainer. In this case, I
assume the problem is down in the freetype library, so it likely isn't worth
bugging the gd maintainer.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
From steve.lime at dnr.state.mn.us Thu Feb 27 15:59:31 2003
From: steve.lime at dnr.state.mn.us (Steve Lime)
Date: Fri Feb 8 14:56:37 2008
Subject: [Mapserver-dev] Thread safe issue
Message-ID:
It's an issue with John Ellson's GD/FreeType code. I remember it when
fixing a few things in his code. The font cache was definitely a global
structure.
>>> Frank Warmerdam 02/27/03 01:22PM >>>
John Newton wrote:
> In several version of gd.lib we have noticed that gdImageStringTTF()
is not
> thread safe due to font caching logic.
>
> Could a new TLOCK be added to protect calls to gdImageStringTTF()?
>
> thanks,
> John Newton
John,
Are you willing to test it if I commit changes to CVS to protect all
gdImageStringTTF calls with a lock? Note that thanks to Dylan we now
have
a gd support contract, and if there are any threading issues in gd that
people
need fixed we could pursue the issue with the maintainer. In this
case, I
assume the problem is down in the freetype library, so it likely isn't
worth
bugging the gd maintainer.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam,
warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for
Rent
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev@lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
From warmerdam at pobox.com Thu Feb 27 16:29:29 2003
From: warmerdam at pobox.com (Frank Warmerdam)
Date: Fri Feb 8 14:56:37 2008
Subject: [Mapserver-dev] Thread safe issue
In-Reply-To:
References:
Message-ID: <3E5E8339.7020805@pobox.com>
John,
OK, I have incorporated a TLOCK_TTF into MapServer 3.7, and modified
all calls to gdImageStringTTF() to go through a cover function,
msGDImageStringTTF() in mapgd.c that acquires and releases the lock.
Let me know if you encounter any problems with this change. I have test
built it, but not test run it.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
From jnovak at novacell.com Fri Feb 28 03:54:13 2003
From: jnovak at novacell.com (Administrator)
Date: Fri Feb 8 14:56:37 2008
Subject: [Mapserver-dev] Coding Standards
Message-ID: <41CC46B3925E384BA64B1FB5041C38FA3323@max.novacell.com>
OK, here my 0.02 worth.
I would like to see a more standardized coding style; but I'm not
particularly adamant about it.
What I would really like to see changed is indentation and curly braces
on the same line as the statement beginning a block. I am a fan of tabs
rather than spaces, at 4 characters, but if the majority of folks would
rather spaces then I can live with spaces. The curly brace thing really
is a biggie for me, though. I really struggle to figure out block
structure without it.
John Novak
Novacell Technologies
www.novacell.com
-----Original Message-----
From: Daniel Morissette [mailto:morissette@dmsolutions.ca]
Sent: Wednesday, February 26, 2003 2:38 PM
To: Steve Lime
Cc: mapserver-dev@lists.gis.umn.edu
Subject: Re: [Mapserver-dev] Coding Standards
Steve Lime wrote:
>
> Subject says it all. Depending on who wrote the code rumaging through
> the source can be kinda trying. I'm thinking we need a document that
> lays out coding standards, especially as the list of developers grows.
> For example, I like the naming convension that some folks use for
> function parameters and local variables and would like to adopt that
> myself. However, I (personally) hate if-then's or function calls that
> span multiple lines- have to scroll too much when editing. Thoughts?
>
Hi Steve,
I agree that a common coding style would be very welcome. I attached
below the bases of the coding style that we try to follow at DM
Solutions, it also matches what Frank uses for his libs (GDAL, OGR,
shapelib, etc.). You'll notice that it's extremely simple, just enough
to keep the code clean without making it too complicated for new
developers to learn and follow the rules.
I'm not saying MapServer-Dev should adopt this coding style, but of
course it would be easier for us if we did. ;) I'm sending it to the
group as a base for discussion.
I would like to elaborate more but I'm taking off right now and will be
back only on Monday. I'm sure others will have many ideas. Hopefully
Frank and Assefa will defend the value of this coding style in my
absence. ;)
Daniel
P.S. Contrary to you I have don't like if-then blocks that start at the
end of the line and I much prefer having brackets on separate lines, but
that's just a natural preference and I respect your choice.
--
------------------------------------------------------------
Daniel Morissette morissette@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------
The rules that MUST be followed:
--------------------------------
1- Make our code fit in 80 columns unless it's not practical to do so
because of a long function name or an expression that would become
unreadable if broken on several lines.
2- NO TABS... set your editor to produce spaces instead of tabs...
that's because some editors use 4 chars tabs and some use 8 chars and
everything looks screwed up if you allow the use of tab chars.
#1 and #2 are also a requirement with some of our external clients like
Safe.
3- Brackets... we use this
if (...)
{
...;
}
else
{
...;
}
More flexible rules: (some may not apply depending on context)
--------------------
4- Indent is 4 chars usually. We've used 2 chars in some places but we
try to stick to 4.
5- Use hungarian notation for variables (makes more sense in C than in
PHP):
Prefix Description
------ ----------------------------
b Boolean
c Char
n Integer value
i Integer, used as a counter in a loop for instance
(we also often use the vars i, j, or k for counters)
f Float, single precision
d Double precision Float (we also use "df" sometimes)
sz String zero-terminated (a C string!)
by Byte
o Object
s Structure
fp FILE *
a Array of ...
p Pointer to ...
k Constant
m Class member variable (we also use "m_" sometimes)
g Global variable
Examples:
---------
char szFilename[100];
char *pszFilename;
int nProjectId;
int i, j, k;
int iField;
double dX, dY;
char **papszLines;
TABFile *poSrcFile;
GBool bSuccess;
6- Function and variable names use upper-lowercase combinations instead
of underscores, e.g. int nProjectId instead of project_id,
7- Filenames and directory names:
- Avoid spaces or special non-alphanumerical characters in
filenames.
The safe characters to use in filenames are "a-z", "0-9", "_" and
"."
- Avoid uppercases in filenames, except for special files that
should
show up at the top of a directory listing like README.TXT,
INSTALL.TXT, etc. For the rest try to stick to lowercase-only
filenames, that makes our lives much easier when porting code
between Windows and Unix.
8- Comments... quite flexible... we most of the time use something like
this for function headers:
/*****************************************************************
* MyFunction()
*
* This function will do something pretty cool. It expects numbers
* as arguments and returns a pointer to a buffer newly allocated.
*
* The caller should free the returned buffer. NULL is returned in
* case of error.
*****************************************************************/
and for comments inline, it's either a short one-line /*... */ thing, or
if it's longer then we sometimes use the following to also act as a
delimiter of an important part of a function:
/* --------------------------------------------------------------
* OK, this is an interesting comment...
* -------------------------------------------------------------- */
Some people (Frank and Assefa at least) use some Emacs macros
to automatically format these comments.
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev@lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
From dgraham at i3.com Fri Feb 28 11:09:28 2003
From: dgraham at i3.com (David Graham)
Date: Fri Feb 8 14:56:37 2008
Subject: [Mapserver-dev] Coding Standards
References: <41CC46B3925E384BA64B1FB5041C38FA3323@max.novacell.com>
Message-ID: <3E5F89B8.4070104@i3.com>
Not sure how people feel about this, but I have been on projects where
each night before the daily build the entire tree is checked out.
"indent" is run with a set of project format rules. Then all the changes
are committed (only those that indent changed the format on). Then the
daily build is performed. And finally the unit tests are executed.
This ensures that all code ends up in the same format. Developers do
need to remember to update their CVS in the morning to get formatting
changes. This is actually quite important, otherwise you find yourself
doing a lot of CVS merge repairs (my biggest complaint of this
technique). As a result programmers start programming more to the
standard just to avoid problems with CVS merge failures.
Just a thought, of course I am not directly in the development circle
for this project so do what you want.
Dave Graham
Administrator wrote:
>OK, here my 0.02 worth.
>
>I would like to see a more standardized coding style; but I'm not
>particularly adamant about it.
>
>What I would really like to see changed is indentation and curly braces
>on the same line as the statement beginning a block. I am a fan of tabs
>rather than spaces, at 4 characters, but if the majority of folks would
>rather spaces then I can live with spaces. The curly brace thing really
>is a biggie for me, though. I really struggle to figure out block
>structure without it.
>
>John Novak
>Novacell Technologies
>www.novacell.com
>
>-----Original Message-----
>From: Daniel Morissette [mailto:morissette@dmsolutions.ca]
>Sent: Wednesday, February 26, 2003 2:38 PM
>To: Steve Lime
>Cc: mapserver-dev@lists.gis.umn.edu
>Subject: Re: [Mapserver-dev] Coding Standards
>
>
>Steve Lime wrote:
>
>
>>Subject says it all. Depending on who wrote the code rumaging through
>>the source can be kinda trying. I'm thinking we need a document that
>>lays out coding standards, especially as the list of developers grows.
>>
>>
>
>
>
>>For example, I like the naming convension that some folks use for
>>function parameters and local variables and would like to adopt that
>>myself. However, I (personally) hate if-then's or function calls that
>>span multiple lines- have to scroll too much when editing. Thoughts?
>>
>>
>>
>
>Hi Steve,
>
>I agree that a common coding style would be very welcome. I attached
>below the bases of the coding style that we try to follow at DM
>Solutions, it also matches what Frank uses for his libs (GDAL, OGR,
>shapelib, etc.). You'll notice that it's extremely simple, just enough
>to keep the code clean without making it too complicated for new
>developers to learn and follow the rules.
>
>I'm not saying MapServer-Dev should adopt this coding style, but of
>course it would be easier for us if we did. ;) I'm sending it to the
>group as a base for discussion.
>
>I would like to elaborate more but I'm taking off right now and will be
>back only on Monday. I'm sure others will have many ideas. Hopefully
>Frank and Assefa will defend the value of this coding style in my
>absence. ;)
>
>Daniel
>
>P.S. Contrary to you I have don't like if-then blocks that start at the
>end of the line and I much prefer having brackets on separate lines, but
>that's just a natural preference and I respect your choice.
>
>
--
David W. Graham
Director of Geospatial Applications Development
information integration and imaging, LLC
201 Linden St, Third Floor
Fort Collins, CO 80524
(970) 482-4400
dgraham@i3.com
http://www.i3.com
From nhv at cape.com Fri Feb 28 11:27:46 2003
From: nhv at cape.com (Norman Vine)
Date: Fri Feb 8 14:56:37 2008
Subject: [Mapserver-dev] Coding Standards
In-Reply-To: <3E5F89B8.4070104@i3.com>
Message-ID:
David Graham writes:
>
> Not sure how people feel about this, but I have been on projects where
> each night before the daily build the entire tree is checked out.
> "indent" is run with a set of project format rules. Then all the changes
> are committed (only those that indent changed the format on). Then the
> daily build is performed. And finally the unit tests are executed.
>
> This ensures that all code ends up in the same format. Developers do
> need to remember to update their CVS in the morning to get formatting
> changes. This is actually quite important, otherwise you find yourself
> doing a lot of CVS merge repairs (my biggest complaint of this
> technique). As a result programmers start programming more to the
> standard just to avoid problems with CVS merge failures.
If we want to use indent to enforce a common style, IMHO not a bad idea,
it is probably easier to set up a 'pre-commit' script on the server end that
runs indent on patched file at commit time. This minimises the changes
seen by the CVS clients and eliminates the need to update Daily for possible
format changes.
The primary reason I like using indent in this fashion is it allows
individual
developers to use a local filter so that they can work on files in their
prefered
format
http://www.loria.fr/~molli/fom-serve/cache/347.html
http://www.gnu.org/manual/cvs/html_chapter/cvs_21.html
Cheers
Norman
From warmerdam at pobox.com Fri Feb 28 15:57:21 2003
From: warmerdam at pobox.com (Frank Warmerdam)
Date: Fri Feb 8 14:56:37 2008
Subject: [Mapserver-dev] COLOR_MATCH_THRESHOLD
Message-ID: <3E5FCD31.9010804@pobox.com>
Folks,
I can't recall who brought up the issue of vectors being drawn in gray
when a grayscale image is drawn first (because it sucked up the colors).
Well, we discussed adding a mechanism to force raster layers to use less
colors here, and I have now implemented such a mechanism. Currently it is
implemented as the COLOR_MATCH_THESHOLD processing directive, such as shown
here:
LAYER
NAME grey
TYPE raster
PROCESSING "COLOR_MATCH_THRESHOLD=3"
STATUS default
DATA data/grey.tif
END
When looking for a matching color for a color entry in a raster layer, the
logic now is to compare the "distance" from the desired color to this
threshold. The details are in msAddColorGD() in mapraster.c but the gist
of it is that you should set the threshold to "3" to be allow a color 1 off
in each of red, green and blue to match.
The default threshold is zero, meaning an exact match is required if possible,
and if not a new color will be allocated. As before it will fall back to
using the nearest color if the colormap is full.
If we like this option we might want to promote it to having a proper keyword
in the mapfile, and ensure it works for the other raster layer types.
Currently it only works for GDAL rendered raster layers.
In fact, such a mechanism might be desirable for other color allocation such
as that occuring due to colors loaded from vector files using the OGR "AUTO
styling". However, that is a bigger effort than I am interested in pursuing
at this time.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
From morissette at dmsolutions.ca Fri Feb 28 16:17:59 2003
From: morissette at dmsolutions.ca (Daniel Morissette)
Date: Fri Feb 8 14:56:37 2008
Subject: [Mapserver-dev] COLOR_MATCH_THRESHOLD
References: <3E5FCD31.9010804@pobox.com> <3E5FD0B0.F9FDD91@dmsolutions.ca> <3E5FD134.2050106@pobox.com>
Message-ID: <3E5FD207.B48ADED0@dmsolutions.ca>
Frank Warmerdam wrote:
>
> Daniel Morissette wrote:
> > Frank Warmerdam wrote:
> >
> >>In fact, such a mechanism might be desirable for other color allocation such
> >>as that occuring due to colors loaded from vector files using the OGR "AUTO
> >>styling". However, that is a bigger effort than I am interested in pursuing
> >>at this time.
> >>
> >
> >
> > I didn't look at the code, but perhaps it would be enough to call
> > msAddColorGD() in the OGR code? If you think that would do the trick (I
> > can't see why not) then I'll have a look.
>
> Daniel,
>
> Well, we would need to get the color threshold value and pass it around too.
> The msAddColorGD() code does a few weird things, and it might needs some
> looking at before implementing.
>
You're right, it's quite possible that the OGR STYLEITEM AUTO code needs
some work, independently of this color thing. I'll add this to my list.
Daniel
--
------------------------------------------------------------
Daniel Morissette morissette@dmsolutions.ca
DM Solutions Group http://www.dmsolutions.ca/
------------------------------------------------------------