I grabbed SafeHtml.py out of the Clearsilver Python stuff and tried
out a very simple test:

SafeHtml.SafeHtmlString ("<b>foobar<script type='text/javascript'></b>")

I expected to get "<b>foobar</b>"

I got "<B>foobar".

This, obviously, is problematic for its purpose, since the closing
bold tag has been dropped...

Is anyone actively using this code?  If so, is there a newer version?
  I don't want to dip into trying to fix this if it's already been done.

...Paul

hmm, bad interaction between stripping the <script> and doing the
matching tag that's stripped.

The fix was pretty easy, available at
http://www.fiction.net/blong/programs/python/SafeHtml.py

Brandon

On 11/02/05 cryomax uttered the following other thing:
> I grabbed SafeHtml.py out of the Clearsilver Python stuff and tried
> out a very simple test:
>
> SafeHtml.SafeHtmlString ("<b>foobar<script type='text/javascript'></b>")
>
> I expected to get "<b>foobar</b>"
>
> I got "<B>foobar".
>
> This, obviously, is problematic for its purpose, since the closing
> bold tag has been dropped...
>
> Is anyone actively using this code?  If so, is there a newer version?
>  I don't want to dip into trying to fix this if it's already been done.
>
> ...Paul
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>

--
   "Also, of course, I'm not allowed to play favorites among my students,
    so y'know, if I plonked one, I'd have to do every man and woman in
    the class, and that could get tiring."  -- Todd Markle
                                            http://www.fiction.net/blong/

On Thu, 3 Nov 2005, Brandon Long wrote:
> hmm, bad interaction between stripping the <script> and doing the
> matching tag that's stripped.
>
> The fix was pretty easy, available at
> http://www.fiction.net/blong/programs/python/SafeHtml.py

Poifect, thanks!  :)

...Paul

       ** Read my Blog:  http://www.bloglines.com/blog/CryoMax **
    ** Visit Project Galactic Guide http://www.galactic-guide.com/ **
"One can never consent to creep when one feels an impulse to soar"
                            -- Helen Keller

--- In ClearSilver@yahoogroups.com, "e6l9jsac" <giulio.cesare@g...> wrote:
>
> By the way, I was trying to compile clearsilver in order to install
Trac (http://
> www.edgewall.com/trac/) on my system, as no x86_64 rps are available
for all the
> required dependency.

Giulio,

I need a clearsilver x86_64 RPM for the same reason (trac on a CentOS
4.2 x86_64 box.

Did you get any further with this?

R.

I've done a search of the archive of this list and thus far have come
up empty - I'm trying to build ClearSilver 0.10.1 with python support
for installing trac on Solaris 9, and have run into the previously
reported linker errors - specifically the "ld: fatal: relocations
remain against allocatable but non-writable section" errors.

I've at least gotten around the first failure of building static.cso
by hacking the rules.mk to include "-mimpure-text" - not sure if this
would break anything, figured I'd give it a go.  However the python
build still breaks.  I don't know python (yet anyway) but I notice the
'setup.py' only parses out a few variables from rules.mk .

###---> Are there any lines that can be added to setup.py force the
gcc linker to use "-mimpure-text" ?  Or any other suggestions?

My environment: I've built Python 2.3 to make sure it's not a 2.4
problem.  I've also installed the gnu versions of "find" and "diff"
(since the install uses non-Solaris compatable flags for those
programs).  Finally, I went back and installed the gnu "binutils" to
get the gnu version of ld, and rebuilt python 2.3 with it just to be
safe.  My gnu is 3.4.2; I'm digging up a 2.95 to see if that helps.

Summary compile output follows (*without* -mimpure-text hack - in that
instance static.cso did build but I get the same python build error).

Cheers,
Erik

##########################################################

silica% uname -a
SunOS silica 5.9 Generic_118558-11 sun4u sparc SUNW,Ultra-5_10

silica% gcc -v
Reading specs from /usr/dist/lib/gcc/sparc-sun-solaris2.9/3.4.2/specs
Configured with: ./configure --prefix=/usr/dist
--with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls
Thread model: posix
gcc version 3.4.2

silica% python -V
Python 2.3.5

silica% ./configure --disable-apache --disable-perl --disable-ruby
--disable-java --disable-csharp --with-python=/usr/local/bin/python
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... gcc -E
checking whether ln -s works... yes
checking for ar... ar
checking for ranlib... ranlib
checking whether make sets $(MAKE)... yes
checking for a BSD-compatible install... ./install-sh -c
checking for Neotonic Paths... not found
checking for dirent.h that defines DIR... yes
checking for library containing opendir... none required
checking for egrep... egrep
checking for ANSI C header files... yes
checking for sys/wait.h that is POSIX.1 compatible... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... no
checking for unistd.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking stdarg.h usability... yes
checking stdarg.h presence... yes
checking for stdarg.h... yes
checking varargs.h usability... no
checking varargs.h presence... no
checking for varargs.h... no
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking for strings.h... (cached) yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking for an ANSI C-conforming const... yes
checking for mode_t... yes
checking for off_t... yes
checking for pid_t... yes
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for struct tm.tm_zone... no
checking for tzname... yes
checking return type of signal handlers... void
checking for strftime... yes
checking for vprintf... yes
checking for _doprnt... yes
checking for wait3 that fills in rusage... yes
checking for gettimeofday... yes
checking for mktime... yes
checking for putenv... yes
checking for strerror... yes
checking for strspn... yes
checking for strtod... yes
checking for strtol... yes
checking for strtoul... yes
checking for random... yes
checking for rand... yes
checking for drand48... yes
Disabling wdb code
checking for lockf... yes
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking build system type... sparc-sun-solaris2.9
checking host system type... sparc-sun-solaris2.9
checking for snprintf... yes
checking for vsnprintf... yes
checking for localtime_r... yes
checking whether localtime_r is declared... no
checking whether localtime_r with -D_REENTRANT is declared... yes
checking for gmtime_r... yes
checking whether gmtime_r is declared... no
checking whether gmtime_r with -D_REENTRANT is declared... yes
checking for strtok_r... yes
checking whether strtok_r is declared... no
checking whether strtok_r with -D_REENTRANT is declared... yes
checking for mkstemp... yes
checking for regexec... yes
checking for deflate in -lz... yes
Disabling Apache 1.3.x Module
checking for python includes... found /usr/local/include/python2.3
Disabling perl module
Disabling ruby module
Disabling java module
Disabling csharp module
configure: creating ./config.status
config.status: creating rules.mk
config.status: creating cs_config.h

silica% make
*******************************************
** Building Dependencies
** OSNAME: SunOS
** (done)
make[1]: Entering directory
`/silica2/build_sw/subversion/clearsilver-0.10.1/util'
*******************************************
** Building Dependencies
** OSNAME: SunOS
** (done)
make[1]: Leaving directory
`/silica2/build_sw/subversion/clearsilver-0.10.1/util'
make[1]: Entering directory
`/silica2/build_sw/subversion/clearsilver-0.10.1/cs'
*******************************************
** Building Dependencies
** OSNAME: SunOS
** (done)
make[1]: Leaving directory
`/silica2/build_sw/subversion/clearsilver-0.10.1/cs'
make[1]: Entering directory
`/silica2/build_sw/subversion/clearsilver-0.10.1/cgi'
*******************************************
** Building Dependencies
** OSNAME: SunOS
** (done)
make[1]: Leaving directory
`/silica2/build_sw/subversion/clearsilver-0.10.1/cgi'
make[1]: Entering directory
`/silica2/build_sw/subversion/clearsilver-0.10.1/python'
*******************************************
** Building Dependencies
** OSNAME: SunOS
** (done)
make[1]: Leaving directory
`/silica2/build_sw/subversion/clearsilver-0.10.1/python'
make[1]: Entering directory
`/silica2/build_sw/subversion/clearsilver-0.10.1/util'
gcc -g -O2 -Wall -I../  -D_REENTRANT -o neo_err.o -c neo_err.c
gcc -g -O2 -Wall -I../  -D_REENTRANT -o neo_files.o -c neo_files.c
gcc -g -O2 -Wall -I../  -D_REENTRANT -o neo_misc.o -c neo_misc.c
neo_misc.c: In function `ne_vwarn':
neo_misc.c:41: warning: subscript has type `char'
gcc -g -O2 -Wall -I../  -D_REENTRANT -o neo_rand.o -c neo_rand.c
gcc -g -O2 -Wall -I../  -D_REENTRANT -o ulist.o -c ulist.c
gcc -g -O2 -Wall -I../  -D_REENTRANT -o neo_hdf.o -c neo_hdf.c
neo_hdf.c: In function `parse_attr':
neo_hdf.c:1358: warning: subscript has type `char'
neo_hdf.c:1366: warning: subscript has type `char'
neo_hdf.c:1370: warning: subscript has type `char'
neo_hdf.c:1374: warning: subscript has type `char'
neo_hdf.c:1452: warning: subscript has type `char'
neo_hdf.c: In function `_hdf_read_string':
neo_hdf.c:1480: warning: subscript has type `char'
neo_hdf.c:1505: warning: subscript has type `char'
neo_hdf.c:1506: warning: subscript has type `char'
neo_hdf.c:1515: warning: subscript has type `char'
neo_hdf.c:1590: warning: subscript has type `char'
neo_hdf.c: In function `hdf_read_file_fp':
neo_hdf.c:1676: warning: subscript has type `char'
neo_hdf.c:1716: warning: subscript has type `char'
neo_hdf.c:1717: warning: subscript has type `char'
neo_hdf.c:1730: warning: subscript has type `char'
gcc -g -O2 -Wall -I../  -D_REENTRANT -o neo_str.o -c neo_str.c
neo_str.c: In function `neos_strip':
neo_str.c:39: warning: subscript has type `char'
neo_str.c:41: warning: subscript has type `char'
neo_str.c: In function `neos_rstrip':
neo_str.c:50: warning: subscript has type `char'
neo_str.c: In function `repr_string_alloc':
neo_str.c:536: warning: subscript has type `char'
neo_str.c:559: warning: subscript has type `char'
gcc -g -O2 -Wall -I../  -D_REENTRANT -o neo_date.o -c neo_date.c
gcc -g -O2 -Wall -I../  -D_REENTRANT -o wildmat.o -c wildmat.c
gcc -g -O2 -Wall -I../  -D_REENTRANT -o neo_hash.o -c neo_hash.c
gcc -g -O2 -Wall -I../  -D_REENTRANT -o ulocks.o -c ulocks.c
gcc -g -O2 -Wall -I../  -D_REENTRANT -o rcfs.o -c rcfs.c
gcc -g -O2 -Wall -I../  -D_REENTRANT -o skiplist.o -c skiplist.c
gcc -g -O2 -Wall -I../  -D_REENTRANT -o dict.o -c dict.c
gcc -g -O2 -Wall -I../  -D_REENTRANT -o filter.o -c filter.c
gcc -g -O2 -Wall -I../  -D_REENTRANT -o neo_net.o -c neo_net.c
gcc -g -O2 -Wall -I../  -D_REENTRANT -o neo_server.o -c neo_server.c
ar cr ../libs/libneo_utl.a neo_err.o neo_files.o neo_misc.o neo_rand.o
ulist.o neo_hdf.o neo_str.o neo_date.o wildmat.o neo_hash.o ulocks.o
rcfs.o skiplist.o dict.o filter.o neo_net.o neo_server.o
ranlib ../libs/libneo_utl.a
make[1]: Leaving directory
`/silica2/build_sw/subversion/clearsilver-0.10.1/util'
make[1]: Entering directory
`/silica2/build_sw/subversion/clearsilver-0.10.1/cs'
gcc -g -O2 -Wall -I../  -D_REENTRANT -I../ -o csparse.o -c csparse.c
csparse.c: In function `cs_parse_string':
csparse.c:443: warning: subscript has type `char'
csparse.c: In function `parse_tokens':
csparse.c:765: warning: subscript has type `char'
csparse.c: In function `each_with_parse':
csparse.c:2311: warning: subscript has type `char'
csparse.c:2336: warning: subscript has type `char'
csparse.c: In function `def_parse':
csparse.c:2516: warning: subscript has type `char'
csparse.c:2552: warning: subscript has type `char'
csparse.c: In function `call_parse':
csparse.c:2686: warning: subscript has type `char'
csparse.c:2722: warning: subscript has type `char'
csparse.c: In function `loop_parse':
csparse.c:2982: warning: subscript has type `char'
csparse.c:3007: warning: subscript has type `char'
ar cr ../libs/libneo_cs.a csparse.o
ranlib ../libs/libneo_cs.a
gcc -g -O2 -Wall -I../  -D_REENTRANT -I../ -o cstest.o -c cstest.c
gcc -o cstest cstest.o -lz -L../libs/ -lneo_cs -lneo_utl  # -lefence
gcc -g -O2 -Wall -I../  -D_REENTRANT -I../ -o cs.o -c cs.c
gcc -o cs cs.o -lz -L../libs/ -lneo_cs -lneo_utl  # -lefence
Running cs regression tests
Passed
make[1]: Leaving directory
`/silica2/build_sw/subversion/clearsilver-0.10.1/cs'
make[1]: Entering directory
`/silica2/build_sw/subversion/clearsilver-0.10.1/cgi'
gcc -g -O2 -Wall -I../  -D_REENTRANT -o cgiwrap.o -c cgiwrap.c
gcc -g -O2 -Wall -I../  -D_REENTRANT -o cgi.o -c cgi.c
gcc -g -O2 -Wall -I../  -D_REENTRANT -o html.o -c html.c
gcc -g -O2 -Wall -I../  -D_REENTRANT -o date.o -c date.c
date.c: In function `later_than':
date.c:146: warning: subscript has type `char'
date.c:149: warning: subscript has type `char'
gcc -g -O2 -Wall -I../  -D_REENTRANT -o rfc2388.o -c rfc2388.c
rfc2388.c: In function `_header_value':
rfc2388.c:39: warning: subscript has type `char'
rfc2388.c:41: warning: subscript has type `char'
rfc2388.c: In function `_header_attr':
rfc2388.c:72: warning: subscript has type `char'
rfc2388.c:76: warning: subscript has type `char'
rfc2388.c:81: warning: subscript has type `char'
rfc2388.c:106: warning: subscript has type `char'
rfc2388.c: In function `_read_header_line':
rfc2388.c:198: warning: subscript has type `char'
rfc2388.c:199: warning: subscript has type `char'
rfc2388.c:214: warning: subscript has type `char'
rfc2388.c:216: warning: subscript has type `char'
ar cr ../libs/libneo_cgi.a cgiwrap.o cgi.o html.o date.o rfc2388.o
ranlib ../libs/libneo_cgi.a
gcc -g -O2 -Wall -I../  -D_REENTRANT -o static.o -c static.c
gcc -o static.cgi static.o -L../libs/ -lneo_cgi -lneo_cs -lneo_utl  -lz
gcc -shared -fPIC -o static.cso static.o -L../libs/ -lneo_cgi -lneo_cs
-lneo_utl  -lz
Text relocation remains                         referenced
     against symbol                  offset      in file
<unknown>                           0x1574
../libs//libneo_cgi.a(html.o)
<unknown>                           0x1578
../libs//libneo_cgi.a(html.o)
<unknown>                           0x157c
../libs//libneo_cgi.a(html.o)
<unknown>                           0x1580
../libs//libneo_cgi.a(html.o)
<unknown>                           0x1584
../libs//libneo_cgi.a(html.o)
[ 5866 lines deleted ]
<unknown>                           0xbc
/usr/dist/lib/gcc/sparc-sun-solaris2.9/3.4.2/../../../libz.a(compress.o)
ld: fatal: relocations remain against allocatable but non-writable
sections
collect2: ld returned 1 exit status
make[1]: *** [static.cso] Error 1
make[1]: Leaving directory
`/silica2/build_sw/subversion/clearsilver-0.10.1/cgi'
make[1]: Entering directory
`/silica2/build_sw/subversion/clearsilver-0.10.1/python'
rm -f neo_cgi.so
/usr/local/bin/python setup.py build_ext --inplace
adding inc_path $(NEOTONIC_ROOT)
adding lib_path $(LIB_DIR)
adding lib z
running build_ext
building 'neo_cgi' extension
creating build
creating build/temp.solaris-2.9-sun4u-2.3
gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-fPIC -I../ -I/usr/local/include/python2.3 -c neo_cgi.c -o
build/temp.solaris-2.9-sun4u-2.3/neo_cgi.o
gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-fPIC -I../ -I/usr/local/include/python2.3 -c neo_util.c -o
build/temp.solaris-2.9-sun4u-2.3/neo_util.o
gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-fPIC -I../ -I/usr/local/include/python2.3 -c neo_cs.c -o
build/temp.solaris-2.9-sun4u-2.3/neo_cs.o
gcc -shared build/temp.solaris-2.9-sun4u-2.3/neo_cgi.o
build/temp.solaris-2.9-sun4u-2.3/neo_cs.o
build/temp.solaris-2.9-sun4u-2.3/neo_util.o -L../libs -lz -lneo_cgi
-lneo_cs -lneo_utl -o neo_cgi.so
Text relocation remains                         referenced
     against symbol                  offset      in file
<unknown>                           0x1574
../libs/libneo_cgi.a(html.o)
<unknown>                           0x1578
../libs/libneo_cgi.a(html.o)
<unknown>                           0x157c
../libs/libneo_cgi.a(html.o)
<unknown>                           0x1580
../libs/libneo_cgi.a(html.o)
<unknown>                           0x1584
../libs/libneo_cgi.a(html.o)
[ 5735 lines deleted ]
neo_seed_rand                       0x40
../libs/libneo_utl.a(neo_rand.o)
ld: fatal: relocations remain against allocatable but non-writable
sections
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
make[1]: *** [neo_cgi.so] Error 1
make[1]: Leaving directory
`/silica2/build_sw/subversion/clearsilver-0.10.1/python'
make: *** [cs] Error 2

silica%

Axel Thimm wrote:
> On Mon, Nov 14, 2005 at 11:02:02PM +0000, Robin Bowes wrote:
>>Did you ever get any further with this?
>
> No, gcc4 and 64bits seem to break clearsilver.
>
>>I'm running into the same problem - I need clearsilver on FC4
>>x86_64.
>
> I finally just used the FC3/x86_64 packages (and dropped them into the
> FC4 repo). Not that the error was introduced by gcc4, it was rather
> unearthed, but it doesn't seem to really bother trac, so I'm happy.

Hmmm. Do they work with FC4/x86_64 ? I couldn't get them to work.

Perhaps I'll have another go.

>>I've managed to get some sort of binary by compiling from the source
>>tarball but I see loads of warnings (mainly the signedness) and the
>>regression tests fail.
>
> I would be happier, of course, if I would have a patch for fixing
> this.

Me too :)

R.

Axel Thimm wrote:
> I finally just used the FC3/x86_64 packages (and dropped them into the
> FC4 repo). Not that the error was introduced by gcc4, it was rather
> unearthed, but it doesn't seem to really bother trac, so I'm happy.

Ah, that was it. There's no neo_cgi.so in the FC3/x86_64 package. Am I
missing something?

R.

Axel Thimm wrote:
> On Mon, Nov 14, 2005 at 11:31:11PM +0000, Robin Bowes wrote:

>>Hmmm. Do they work with FC4/x86_64 ? I couldn't get them to work.
>
>
> Yes, they do, all you have to do is
>
> smart install trac
>
> with smart configured to use ATrpms' FC4/x86_64 repo.

Sorry - what's smart? I generally use "yum".

R.

On Mon, Nov 14, 2005 at 11:02:02PM +0000, Robin Bowes wrote:
> Axel Thimm wrote:
> > there has been a similar report by Jiann-Ming Su.
> >
> > http://groups.yahoo.com/group/ClearSilver/message/272
> >
> > He was having trouble with a 64 bit Debian Alpha system, while I'm on
> > a FC4/x86_64. Like Jiann-Ming Su I have no trouble building on 32 bits
> > (i386). So I assume this is a bug in pointer size matching?
> >
> > Comparing the buildlogs for i386 vs x86_64 I see one more warning for
> > the latter:
> >
> > neo_hash.c: In function 'ne_hash_int_hash':
> > neo_hash.c:292: warning: cast from pointer to integer of different size
> >
> > There are also several "pointer targets in passing argument 3 of
> > ... differ in signedness" in both builds. I can mail the buildlogs to
> > anyone interested (150kB).
> >
> > Any pointers/help is greatly appreciated. I'd like to get trac running
> > on this system, and need clearsilver to proceed. Thanks!
>
> Axel,
>
> Did you ever get any further with this?

No, gcc4 and 64bits seem to break clearsilver.

> I'm running into the same problem - I need clearsilver on FC4
> x86_64.

I finally just used the FC3/x86_64 packages (and dropped them into the
FC4 repo). Not that the error was introduced by gcc4, it was rather
unearthed, but it doesn't seem to really bother trac, so I'm happy.

> I've managed to get some sort of binary by compiling from the source
> tarball but I see loads of warnings (mainly the signedness) and the
> regression tests fail.

I would be happier, of course, if I would have a patch for fixing
this.
--
Axel.Thimm at ATrpms.net

> > gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5)
> >
> > It's the current default in Fedora Core.
> >
>
> I've fixed the bad pointer warnings (those warning of different
> pointer size) both manually (there was an int somewhere that was used
> as a pointer) and by defining UINT32 and friends as long instead of
> int.
> AFAIK the signed-ness is irrelevant, what's important is that pointers
> don't get cut down to 32-bit ints (long is promoted to 64-bit on
> x86_64 with most compilers (msvc is an exception here)).
>
> Having done this I see that all C tests pass (except the slice one!)
> and also all the ruby test. Before doing the changes, it would crash
> in either ruby or java.
>
> Any ideas ?

You seem to have solved everything, so my only idea is to submit the
patches to the project. :)
--
Axel.Thimm at ATrpms.net

On Mon, Nov 14, 2005 at 11:31:11PM +0000, Robin Bowes wrote:
> Axel Thimm wrote:
> > On Mon, Nov 14, 2005 at 11:02:02PM +0000, Robin Bowes wrote:
> >>Did you ever get any further with this?
> >
> > No, gcc4 and 64bits seem to break clearsilver.
> >
> >>I'm running into the same problem - I need clearsilver on FC4
> >>x86_64.
> >
> > I finally just used the FC3/x86_64 packages (and dropped them into the
> > FC4 repo). Not that the error was introduced by gcc4, it was rather
> > unearthed, but it doesn't seem to really bother trac, so I'm happy.
>
> Hmmm. Do they work with FC4/x86_64 ? I couldn't get them to work.

Yes, they do, all you have to do is

smart install trac

with smart configured to use ATrpms' FC4/x86_64 repo.
--
Axel.Thimm at ATrpms.net

Axel Thimm wrote:
> Hi,
>
> there has been a similar report by Jiann-Ming Su.
>
> http://groups.yahoo.com/group/ClearSilver/message/272
>
> He was having trouble with a 64 bit Debian Alpha system, while I'm on
> a FC4/x86_64. Like Jiann-Ming Su I have no trouble building on 32 bits
> (i386). So I assume this is a bug in pointer size matching?
>
> Comparing the buildlogs for i386 vs x86_64 I see one more warning for
> the latter:
>
> neo_hash.c: In function 'ne_hash_int_hash':
> neo_hash.c:292: warning: cast from pointer to integer of different size
>
> There are also several "pointer targets in passing argument 3 of
> ... differ in signedness" in both builds. I can mail the buildlogs to
> anyone interested (150kB).
>
> Any pointers/help is greatly appreciated. I'd like to get trac running
> on this system, and need clearsilver to proceed. Thanks!

Axel,

Did you ever get any further with this?

I'm running into the same problem - I need clearsilver on FC4 x86_64.

I've managed to get some sort of binary by compiling from the source
tarball but I see loads of warnings (mainly the signedness) and the
regression tests fail.

Cheers,

R.

On Mon, Nov 14, 2005 at 11:34:18PM +0000, Robin Bowes wrote:
> Axel Thimm wrote:
> > I finally just used the FC3/x86_64 packages (and dropped them into the
> > FC4 repo). Not that the error was introduced by gcc4, it was rather
> > unearthed, but it doesn't seem to really bother trac, so I'm happy.
>
> Ah, that was it. There's no neo_cgi.so in the FC3/x86_64 package. Am I
> missing something?

No, neo_cgi.so is there.

$ rpm -qf /usr/lib64/python2.4/site-packages/neo_cgi.so
clearsilver-0.10.1-3.rhfc3.at
--
Axel.Thimm at ATrpms.net

Axel Thimm said the following on 15/11/2005 01:13:
> On Mon, Nov 14, 2005 at 11:34:18PM +0000, Robin Bowes wrote:
>
>>Axel Thimm wrote:
>>
>>>I finally just used the FC3/x86_64 packages (and dropped them into the
>>>FC4 repo). Not that the error was introduced by gcc4, it was rather
>>>unearthed, but it doesn't seem to really bother trac, so I'm happy.
>>
>>Ah, that was it. There's no neo_cgi.so in the FC3/x86_64 package. Am I
>>missing something?
>
>
> No, neo_cgi.so is there.
>
> $ rpm -qf /usr/lib64/python2.4/site-packages/neo_cgi.so
> clearsilver-0.10.1-3.rhfc3.at

Aha! I was trying to rebuild the FC3 SRPM on FC4. I didn't think to
install the FC3 x86_64 RPM.

Thanks for the help,

R.
--
http://robinbowes.com

If a man speaks in a forest,
and his wife's not there,
is he still wrong?

On Tue, Nov 15, 2005 at 09:28:20AM +0000, Robin Bowes wrote:
> Axel Thimm said the following on 15/11/2005 01:13:
> > On Mon, Nov 14, 2005 at 11:34:18PM +0000, Robin Bowes wrote:
> >
> >>Axel Thimm wrote:
> >>
> >>>I finally just used the FC3/x86_64 packages (and dropped them into the
> >>>FC4 repo). Not that the error was introduced by gcc4, it was rather
> >>>unearthed, but it doesn't seem to really bother trac, so I'm happy.
> >>
> >>Ah, that was it. There's no neo_cgi.so in the FC3/x86_64 package. Am I
> >>missing something?
> >
> >
> > No, neo_cgi.so is there.
> >
> > $ rpm -qf /usr/lib64/python2.4/site-packages/neo_cgi.so
> > clearsilver-0.10.1-3.rhfc3.at
>
> Aha! I was trying to rebuild the FC3 SRPM on FC4. I didn't think to
> install the FC3 x86_64 RPM.

The FC3 src.rpm and the one for FC4 are identical. It isn't the
sources, it's the environment (64 bits & gcc4) that break the build.

So rebuilding the FC3 src.rpm on FC4 won't make it magically work. :(
--
Axel.Thimm at ATrpms.net

Hi,

I tried to install ClearSilver 0.9.14 (Python API only) on HP Tru64 Unix. I
encoutered several problems that I was able to fix. Attached are the mods I
made. These changes should be backward compatible, just adding flexibility
for support of other platforms.

I tested these patches on 0.10.1. Basically they work, except that for some
files, the offset of the chunk has changed and thus patch fails. You need
to apply them manually in this case.


Problem encoutered are :

- On Tru64, we use cc instead of gcc to compile such products. gcc use was
hardcoded for dependency generation in rules.mk.in. And flag -fPIC is not
available on Tru64. The same remark applies to cxx but the fix I did is not
complete (cxx is not used with Python)

- native diff options are not compliant with GNU diff. I added to configure
and rules.mk the support for a non standard diff specification (default to
diff)

- At LAL, we install everything in non standard location to be able to
install several versions at a time. That means we want to use a non default
value for PYTHON_SITE. Support has been added in configure and rules.mk.

- In neo_err.h, syntax '#define macro(a,b,c...)' is used. On Tru64 (and as
far as I know in strict C99 dialect), the equivalent syntax is '#define
macro(a,b,...)' (c should not be specified).


It would be nice if these changes were integraded in standard distribution
if they produce no conflict.

Cheers,

Michel

ps : by the way, is 0.10.1  a production version or a beta (what is the
most stable version) ?

      *************************************************************
      * Michel Jouvin                 Email : jouvin@... *
      * LAL / CNRS                    Tel : +33 1 64468932        *
      * B.P. 34                       Fax : +33 1 69079404        *
      * 91898 Orsay Cedex                                         *
      * France                                                    *
      *************************************************************

Thanks for the patches, I'll see about integrating them.

Each version is "production", in that there are sites with millions of
hits a day using them.  I should be better about naming versions, and I
should probably define what we need for 1.0.

The biggest problem people have is compiling for 64 bits, or non-gcc
platforms, or for gcc4.  I have limited access to these platforms, so I
haven't been able to fix them.

I'll see if I can put together the time to make a new release with a
bunch of fixes for those problems.

Brandon

On 11/16/05 Michel Jouvin uttered the following other thing:
> Hi,
>
> I tried to install ClearSilver 0.9.14 (Python API only) on HP Tru64 Unix. I
> encoutered several problems that I was able to fix. Attached are the mods I
> made. These changes should be backward compatible, just adding flexibility
> for support of other platforms.
>
> I tested these patches on 0.10.1. Basically they work, except that for some
> files, the offset of the chunk has changed and thus patch fails. You need
> to apply them manually in this case.
>
>
> Problem encoutered are :
>
> - On Tru64, we use cc instead of gcc to compile such products. gcc use was
> hardcoded for dependency generation in rules.mk.in. And flag -fPIC is not
> available on Tru64. The same remark applies to cxx but the fix I did is not
> complete (cxx is not used with Python)
>
> - native diff options are not compliant with GNU diff. I added to configure
> and rules.mk the support for a non standard diff specification (default to
> diff)
>
> - At LAL, we install everything in non standard location to be able to
> install several versions at a time. That means we want to use a non default
> value for PYTHON_SITE. Support has been added in configure and rules.mk.
>
> - In neo_err.h, syntax '#define macro(a,b,c...)' is used. On Tru64 (and as
> far as I know in strict C99 dialect), the equivalent syntax is '#define
> macro(a,b,...)' (c should not be specified).
>
>
> It would be nice if these changes were integraded in standard distribution
> if they produce no conflict.
>
> Cheers,
>
> Michel
>
> ps : by the way, is 0.10.1  a production version or a beta (what is the
> most stable version) ?
>
>      *************************************************************
>      * Michel Jouvin                 Email : jouvin@... *
>      * LAL / CNRS                    Tel : +33 1 64468932        *
>      * B.P. 34                       Fax : +33 1 69079404        *
>      * 91898 Orsay Cedex                                         *
>      * France                                                    *
>      *************************************************************
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>






--
  "Moral indignation is jealousy with a halo." -- H. G. Wells
                                            http://www.fiction.net/blong/

Hi,
I'm new in ClearSilver; can anyone give me an example code of using c in
clearsilver ?

Thanks

In the clearsilver distribution, there is an example program in the imd
directory.  Its a very simple image server.

There's also static.c in the cgi directory, for an even simpler example.

Brandon

On 11/17/05 mohamadsb uttered the following other thing:
> Hi,
> I'm new in ClearSilver; can anyone give me an example code of using c in
> clearsilver ?
>
> Thanks
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>

--
     "A front-line tech support specialist who has 'had enough' will buy
      a bow and 'go elven postal' after watching 'The Two Towers'."
                       http://ars.userfriendly.org/cartoons/?id=20030105

Hi guys,

I've problems reading out HTTP Cookies within an Clearsilver templates?
Can u tell me what to do, I don't find any fitting information.
The only thing I found is this:

  <?cs each:cookie = Request.Cookie ?>
     <?cs if:cookie.name == "preference" ?>
        <?cs var:cookie.value ?>
     <?cs /if ?>
  <?cs /each ?>


But this doesnt work :-/

Thx for ur help,

Cu

Hi guys,

I've problems reading out HTTP Cookies within an Clearsilver templates?
Can u tell me what to do, I don't find any fitting information.
The only thing I found is this:

  <?cs each:cookie = Request.Cookie ?>
     <?cs if:cookie.name == "preference" ?>
        <?cs var:cookie.value ?>
     <?cs /if ?>
  <?cs /each ?>

But this doesnt work :-/

Thx for ur help,

Cu
7
______________________________________________________________________
XXL-Speicher, PC-Virenschutz, Spartarife & mehr: Nur im WEB.DE Club!
Jetzt gratis testen! http://freemail.web.de/home/landingpad/?mc=021130

Well, it depends on what is populating your HDF.

With the included CGI kit (C or Python) the cookies are actually stored
at Cookie, so the equivalent would be:

<?cs each:cookie = Cookie ?>
   <?cs if:name(cookie) == "preference" ?>
     <?cs var:cookie ?>
   <?cs /if ?>
<?cs /each ?>

Or just:
<?cs var:Cookie.preference ?>

If you're using something else to populate your HDF, then it depends on
what you're using.

Brandon

On 11/19/05 md_xlhost uttered the following other thing:
> Hi guys,
>
> I've problems reading out HTTP Cookies within an Clearsilver templates?
> Can u tell me what to do, I don't find any fitting information.
> The only thing I found is this:
>
>  <?cs each:cookie = Request.Cookie ?>
>     <?cs if:cookie.name == "preference" ?>
>        <?cs var:cookie.value ?>
>     <?cs /if ?>
>  <?cs /each ?>
>
>
> But this doesnt work :-/
>
> Thx for ur help,

--
   "Cynic, n.: A blackguard whose faulty vision sees things as they are, not
	       as they ought to be.  Hence the custom among the Scythians
	       of plucking out a cynic's eyes to improve his vision."
                                 -- Ambrose Bierce, "The Devil's Dictionary"
                                        http://www.fiction.net/blong/

I finally finished up a clearsilver module for pike
(http://pike.ida.liu.se/).  It only does the HDF and template side of
things, none of the cgikit stuff.  You can get it here:
http://www.siriushosting.com/pike/clearsilver.html but I don't have much
for docs yet.

Any chance we'll see a way to register scripting language functions
sometime soon?  I think that's the only thing missing right now.

Adam

-- Adam Montague wrote:
> I finally finished up a clearsilver module for pike
> (http://pik­e.ida.liu.s­e/).  It only does the HDF and template side of
> things, none of the cgikit stuff.  You can get it here:
> http://www.­siriushosti­ng.com/pike­/clearsilve­r.html but I don't have much
> for docs yet.

That's great! We'll try to incorporate this into the main clearsilver release
sometime soon.

> Any chance we'll see a way to register scripting language functions
> sometime soon?  I think that's the only thing missing right now.

Can you explain what you mean here? The C interface allows you to register
functions to use in clearsilver expressions. In thinking about this problem, I
suppose that in order to register scripting functions as a response, we need to
allow you to provide an opaque data structure with the callback registration so
you can map this back to a specific pike function using a single generic C
callback. Is this what you mean?

Has anyone here had a positive experience with a documentation generation
format? It would be nice if it were easier for new documentation to be part of
a coherent whole, and it seems like a text-based doc format integrated into the
build would be an easy way for this to happen.

I'm pretty happy with the python online documentation, which I think uses
latek2html. Anyone have experience with other formats? PyDoc? docbook?
latek2html?

- David

On 11/29/05 David Jeske uttered the following other thing:
> -- Adam Montague wrote:
> > I finally finished up a clearsilver module for pike
> > (http://pik?e.ida.liu.s?e/).  It only does the HDF and template side of
> > things, none of the cgikit stuff.  You can get it here:
> > http://www.?siriushosti?ng.com/pike?/clearsilve?r.html but I don't have much
> > for docs yet.
>
> That's great! We'll try to incorporate this into the main clearsilver release
> sometime soon.
>
> > Any chance we'll see a way to register scripting language functions
> > sometime soon?  I think that's the only thing missing right now.
>
> Can you explain what you mean here? The C interface allows you to register
> functions to use in clearsilver expressions. In thinking about this problem, I
> suppose that in order to register scripting functions as a response, we need
to
> allow you to provide an opaque data structure with the callback registration
so
> you can map this back to a specific pike function using a single generic C
> callback. Is this what you mean?

Yes, that's probably what he means, others have asked before.  I
originally specifically didn't include that because I didn't want people
making complicated callbacks which did real work and could have
side-effects, but its probably a requirement to be able to register
scripting language functions.

There is support in the internal interface for this, so its not hard.  I
just need to clean up the internal interface and expose it.

Brandon
--
   "Also, of course, I'm not allowed to play favorites among my students,
    so y'know, if I plonked one, I'd have to do every man and woman in
    the class, and that could get tiring."  -- Todd Markle
                                            http://www.fiction.net/blong/

On Tue, 29 Nov 2005 21:49:27 -0000 "David Jeske" <jeske@...> wrote:

> -- Adam Montague wrote:
> > I finally finished up a clearsilver module for pike
> > (http://pik_e.ida.liu.s_e/).  It only does the HDF and template
> > side of things, none of the cgikit stuff.  You can get it here:
> > http://www._siriushosti_ng.com/pike_/clearsilve_r.html but I don't
> > have much for docs yet.
>
> That's great! We'll try to incorporate this into the main clearsilver
> release sometime soon.

There's basic docs now too:
http://modules.gotpike.org/display_docs.pike/Public.Parser.ClearSilver/1.1/29

> > Any chance we'll see a way to register scripting language functions
> > sometime soon?  I think that's the only thing missing right now.
>
> Can you explain what you mean here? The C interface allows you to
> register functions to use in clearsilver expressions. In thinking
> about this problem, I suppose that in order to register scripting
> functions as a response, we need to allow you to provide an opaque
> data structure with the callback registration so you can map this
> back to a specific pike function using a single generic C callback.
> Is this what you mean?

Exactly.

Adam

On Tue, Nov 29, 2005 at 09:56:50PM -0000, David Jeske wrote:
> Has anyone here had a positive experience with a documentation generation
> format? It would be nice if it were easier for new documentation to be part of
> a coherent whole, and it seems like a text-based doc format integrated into
the
> build would be an easy way for this to happen.
>
> I'm pretty happy with the python online documentation, which I think uses
> latek2html. Anyone have experience with other formats? PyDoc? docbook?
> latek2html?

I'm a fan of DocBook. The work flow and setup takes a little getting
into but, as with most things, is fine once you get the hang of it. It
has been flexible enough to cope with everything I've needed it for
(Technical API documentation and user oriented manuals). I haven't had
much experience outputting in anything other than HTML and PDF, but
was happy with the way I could customise the XSLT stylesheets. Being
XML, it is quite easy to populate the documentation automatically
where required.

I find a good XML editor is essential, however, if you're to make the
most of it. My personal preference is emacs coupled with the excellent
nxml-mode (http://www.emacswiki.org/cgi-bin/wiki/NxmlMode). This comes
with built-in autocompletion/validation for the DocBook schema.

I hope that helps!

Kind regards,

Homme Zwaagstra

On Thu, Dec 01, 2005 at 11:03:08AM +0000, hrz@... wrote:
> I find a good XML editor is essential, however, if you're to make the
> most of it. My personal preference is emacs coupled with the excellent
> nxml-mode (http://www.emacswiki.org/cgi-bin/wiki/NxmlMode). This comes
> with built-in autocompletion/validation for the DocBook schema.

Swetland just pointed me at this: http://www.methods.co.nz/asciidoc/
which is pretty sweet.

Apparently it's being used for the git docs, among other things.