olafvdspek / ctemplate Goto Github PK
View Code? Open in Web Editor NEWLicense: BSD 3-Clause "New" or "Revised" License
License: BSD 3-Clause "New" or "Revised" License
I noticed that there are no plain C bindings for this project. Is that
something that the maintainers would be interested in? I can provide a
patch myself, however I would prefer not to maintain it moving forward if
any APIs are added, changed, or removed.
Original issue reported on code.google.com by [email protected]
on 2 May 2008 at 11:59
Hope this is right place for this. Could not find somewhere else to upload.
Attached is archive containing 64 bit ctemplate 0.93 , and
ctemplate-devel-0.93 rpms.
Original issue reported on code.google.com by [email protected]
on 3 Feb 2009 at 1:19
Attachments:
[ported from sourceforge, where it was submitted by sfdivan at
users.sourceforge.net]
Another step to windows and other platforms port is threads, locks, and so on.
This file contains 3 alternative threads-stuff:
1) threads_no: no locking is done (but now there is no need in #ifdef
anywhere else than threads.h)
2) threads_p: original pthreads locking (but now all locks are scoped, i.e.
wrapped in a class)
3) threads_b: wrapped boost::threads, so you'll need boost::thread lib
(which is available for win of course)
Original issue reported on code.google.com by [email protected]
on 26 Jan 2007 at 1:03
Attachments:
Noticed the following comment in template.cc:
// TODO(csilvers): have InsertLine take a size_t
I took a stab at it and figured it would be worthwhile to trace through the
warnings suppressed by pragma 4018 as well.
Original issue reported on code.google.com by [email protected]
on 15 Nov 2007 at 3:00
Attachments:
What steps will reproduce the problem?
1. configure and install ctemplate like this:
./configure --host=arm-none-linux-gnueabi \
CC=${CROSS_COMPILE}gcc \
CXX=${CROSS_COMPILE}g++ \
AR=${CROSS_COMPILE}ar \
RANLIB=${CROSS_COMPILE}ranlib \
STRIP=${CROSS_COMPILE}strip
make
make install-strip
where CROSS_COMPILE is cross compiler path
2. compile example from start page (http://code.google.com/p/google-ctemplate)
3. run the example, you'll get segmentation fault at
'dict.ShowSection("IN_CA");'
What is the expected output? What do you see instead?
expected output is HTML generated from template, what I see is
"segmentation fault" message
What version of the product are you using? On what operating system?
ctemplate-0.95 on machine at91sam9260ek
os - linux 2.6.27
Please provide any additional information below.
segmentation fault is arrised because ctemplate's arena object
is first returns address not multiple of 4 from 'GetMemory'
and then uses in in 'placement new' operator like this:
new (buff) T
which is not allowed on ARM.
To fix this, it mustn't return addresses not multiple of 4, because any
address returned by an arena object could be used in 'placement new',
to fix the problem, replace:
char* Alloc(const size_t size) {
return reinterpret_cast<char*>(GetMemory(size, 1));
}
with:
char* Alloc(const size_t size) {
return reinterpret_cast<char*>(GetMemory(size, kDefaultAlignment));
}
Original issue reported on code.google.com by [email protected]
on 24 Aug 2009 at 11:35
What steps will reproduce the problem?
1. write a simple tpl including like {{DATA}}
2. prepare a very large text file test.txt with size 10MB
3. expand {{DATA}} with content from test.txt.
What is the expected output? What do you see instead?
there should be a way to replace the template items directly by writing file.
What version of the product are you using? On what operating system?
ctemplate 0.93
os: Ubuntu 8.10
Please provide any additional information below.
I'm not sure if it supports the way of writing file directly when doing the
expand.
Thanks,
Eric
Original issue reported on code.google.com by [email protected]
on 4 Feb 2009 at 11:13
What steps will reproduce the problem?
1. Instantiate a TemplateDictionary
2. Add a bunch of Section Dictionaries
3. Watch memory be eaten up by a lot (almost an order of magnitude more
than clearsilver's HDF, which is not very efficient itself.)
What is the expected output? What do you see instead?
Less memory be used. Right now, it looks like each node has more than
3k of overhead, which is a heck of a lot.
What version of the product are you using? On what operating system?
ctemplate-0.90 on Ubuntu Linux 8.04 x64, up to date as of Jul 24, 2008.
Please provide any additional information below.
I've attached sample code that will generate dictionaries for
clearsilver's HDF format (for comparison purposes) and ctemplate's
TemplateDictionary, as well as sample output from 'pmap -d `pidof
$EXECUTABLE_NAME`'.
A Note from csilvers (see
http://groups.google.com/group/google-ctemplate/browse_thread/thread/9113ccc7086
8c03d
for the full thread):
There has been some talk of changing the TemplateDictionary
constructor so that variable_dict_, section_dict_, and include_dict_
are allocated lazily, rather than always being allocated in the
constructor. My guess -- untested -- is most of the space in a
TemplateDictionary is going to these hashtables, and lazy construction
could save about 50% of the space used. The cost is probably low in
terms of running time. If you'd like to play around with something
like that, feel free! It would be nice to get both timing effects and
space effects of such a change.
Original issue reported on code.google.com by [email protected]
on 25 Jul 2008 at 5:37
What steps will reproduce the problem?
1. Install gcc 4.4
2. Try to compille ctemplate
What is the expected output? What do you see instead?
Program will compile ok.
What version of the product are you using? On what operating system?
Found on ctemplate 0.92, patch applies correctly on 0.93 too. Testing on
openSUSE Linux.
Please provide any additional information below.
Attached patch fixes the issue by adding missing include.
Original issue reported on code.google.com by [email protected]
on 20 Feb 2009 at 1:25
Attachments:
I get this warning from the unused paramenters in MightModify
from /opt/ctemplate/include/ctemplate/template.h:48,
from Hello.cpp:8:
/opt/ctemplate/include/ctemplate/template_modifiers.h:116: warning: unused
parameter ‘per_expand_data’
/opt/ctemplate/include/ctemplate/template_modifiers.h:116: warning: unused
parameter ‘arg’
virtual bool MightModify(const PerExpandData* per_expand_data,
const std::string& arg) const {
return true;
}
It will be better to get rid of the name of the unused parameters to avoid
this warnning.
virtual bool MightModify(const PerExpandData*,
const std::string&) const {
return true;
}
Original issue reported on code.google.com by [email protected]
on 24 Nov 2009 at 10:47
What steps will reproduce the problem?
1. Try to compile ctemplate on ppc
What is the expected output? What do you see instead?
Expected result is to compile correctly. Make ends with:
src/template_string.cc:120: error: 'bswap32' was not declared in this scope
What version of the product are you using? On what operating system?
ctemplate 0.93 on openSUSE Linux
Please provide any additional information below.
According to the byteswap.h correct function should be byteswap_32. Patch
attached. Tested on i686, x86_64 too.
Original issue reported on code.google.com by [email protected]
on 20 Feb 2009 at 1:19
Attachments:
What steps will reproduce the problem?
1. write a simple template replacement program from the "example" in
"howto" document.
2. run it with valgrind
3. valgrind will show a warning like this:
==23223== Mismatched free() / delete / delete []
==23223== at 0x4024B4A: free (vg_replace_malloc.c:323)
==23223== by 0x404F43F: google::BaseArena::~BaseArena() (arena.cc:119)
==23223== by 0x406605C: google::UnsafeArena::~UnsafeArena() (arena.h:261)
==23223== by 0x405FAC9:
google::TemplateDictionary::~TemplateDictionary() (template_dictionary.cc:205)
....
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
ctemplate 0.93
os: ubuntu 8.10
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 5 Feb 2009 at 5:31
Attachments:
What steps will reproduce the problem?
1.
2.
3.
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 7 Aug 2009 at 7:02
Issue:
It is necessary to perform a conversion of the existing VS2003 solution in
order to build in 2005.
What could fix this:
If there was a VS2005 solution and associated project files that are VS2005
specific in the tree to support developers with this version of visual
studio (and associated compiler options determined to be best)
What this patch does:
- creates a google-ctemplate-vs8.sln in the root for VS2005 users.
- creates a vs8projects folder that mirrors that of vsprojects.
This is a straight-forward transition of the existing solution. I did not
tinker with any compiler options, so that this could be a clean starting
place for this to come to life.
How to use this patch:
1. Perform a clean check out of the following url at rev 29:
http://google-ctemplate.googlecode.com/svn/trunk
2. Apply the patch.
You should then be able to open up the google-ctemplate-vs8.sln in visual
studio 2005 from the root of the project.
Original issue reported on code.google.com by [email protected]
on 15 Nov 2007 at 12:46
Attachments:
What steps will reproduce the problem?
1. Perform SVN Checkout with TortoiseSVN on Windows. Repository URL:
http://google-ctemplate.googlecode.com/svn/trunk
What is the expected output? What do you see instead?
I expected to receive the latest bleeding edge CTemplate source code, but
all I got were documentation files.
What version of the product are you using? On what operating system?
I am using TortoiseSVN 1.4.1
Please provide any additional information below.
The file attached is the list of files, including the SVN files, that I got
from the checkout.
Original issue reported on code.google.com by [email protected]
on 4 Mar 2007 at 3:14
Attachments:
What steps will reproduce the problem?
Maybe its only for me reproducable. Here are my configurations
1. configure ctemplate 0.96/0.95 with ./configure --enable-static
--disable-shared (Host1, Host2 (see below))
What is the expected output? What do you see instead?
I expect a wondeful well formed xml file.
The template file has following structure: (sorry that I can not show the
original template file)
TemplateDictionary -> SectionDictionary -> SectionDictionary (Show/Hide
functionality)
-> SectionDictionary (Show/Hide
functionality)
-> SectionDictionary (Show/Hide
functionality)
-> SectionDictionary ->
SectionDictionary (Show/Hide functionality)
-> SectionDictionary (Show/Hide functionality) ->
SectionDictionary
In the section dicts always 1 or more vars.
What version of the product are you using? On what operating system?
ctemplate 0.95/0.96
Host 1: Linux version 2.6.27.38-170.2.113.fc10.i686 (gcc version 4.3.2
20081105 (Red Hat 4.3.2-7) (GCC) )
Host 2: Linux version 2.6.18-128.4.1.el5.centos.plus (gcc version 4.1.2
20080704 (Red Hat 4.1.2-44))
Please provide any additional information below.
The problem: When I start my program which was compiled on host 2, I get a
segmentation fault during expanding and/or dumping. On host 1, there is
absolutly no error without changing the code.
I debugged a little bit and here is a backtrace, maybe useful:
Program received signal SIGSEGV, Segmentation fault.
ctemplate::TemplateDictionary::DictionaryPrinter::DumpSectionDict
(this=0xbfd0f7ac, section_dict=@0x8e3720c)
at
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_iter
ator.h:650
650 in
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_iter
ator.h
(gdb) backtrace
#0 ctemplate::TemplateDictionary::DictionaryPrinter::DumpSectionDict
(this=0xbfd0f7ac, section_dict=@0x8e3720c)
at
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_iter
ator.h:650
#1 0x0812ee2c in
ctemplate::TemplateDictionary::DictionaryPrinter::DumpDictionary
(this=0xbfd0f7ac, dict=@0x8e37138) at src/template_dictionary.cc:786
#2 0x08130f86 in
ctemplate::TemplateDictionary::DictionaryPrinter::DumpSectionDict
(this=0xbfd0f7ac, section_dict=@0x8e370d0) at src/template_dictionary.cc:731
#3 0x0812ee2c in
ctemplate::TemplateDictionary::DictionaryPrinter::DumpDictionary
(this=0xbfd0f7ac, dict=@0x8ded288) at src/template_dictionary.cc:786
#4 0x081294d1 in ctemplate::TemplateDictionary::DumpToString
(this=0x8ded288, out=0xbfd0f9a8, indent=2) at src/template_dictionary.cc:731
row 826 in template_dictionary.cc: "for (DictVector::const_iterator it2 =
it->second->begin();"
I get the same error if using ctemplate 0.95
Generally:
I have six different template files which are similar to the example above.
Two of these template produce the segmentation fault but there are no
important differences
between them and the other templates. If I remove the first section
dictionary from the example above, the program runs greate, its very strange.
My template vars only consits of letters and "_". I tested the templates
without modifier too, the same error.
I have to compile the program on host 2 and there is no possibility to
update the gcc.
I hope these information are enought.
Regards, Tholmer
Original issue reported on code.google.com by [email protected]
on 18 Jan 2010 at 4:39
automake1.10 generates a Makefile.in that substantially differs from the
one created by 1.9, and causes failures compiling statemachine_test as a
result. Here's a small snippet of the failure:
/bin/bash ./libtool --tag=CXX --mode=link g++ -xc -g -O2 -o
statemachine_test statemachine_test.o statemachine_test-statemachine.o
g++ -xc -g -O2 -o statemachine_test statemachine_test.o
statemachine_test-statemachine.o
statemachine_test.o:1: error: stray '\177' in program
statemachine_test.o:1: error: stray '\1' in program
statemachine_test.o:1: error: stray '\1' in program
statemachine_test.o:1: error: stray '\1' in program
statemachine_test.o:1:8: warning: null character(s) ignored
I installed automake1.9 and invoked:
ACLOCAL=aclocal-1.9 AUTOMAKE=automake-1.9 autoreconf -i -s
Which generated a Makefile.in more closely matching the distributed one,
and the build succeeded.
Original issue reported on code.google.com by [email protected]
on 2 May 2008 at 10:43
This warning is reported when compiling with VS9. Removing the
Detect64BitPortabilityProblems="true" entries from the project files should
avoid this.
Original issue reported on code.google.com by olafvdspek
on 11 Jul 2009 at 4:00
Rev: 29
Issue: If you create a template with {{/__MAIN__}} anywhere in it, all
template processing on the template will be halted. If this was by design,
please ignore this issue.
Note: I did not really find much documentation on __MAIN__ outside of
digging through the code. This is where I realized __MAIN__ was special.
Recommendation: In the event that anyone was to inadvertently type this
into a template, it would probably be beneficial to have a warning issued
(unless this was done for good reason!)
Just glancing at it, I think this could probably be easily handled inside
of SectionTemplateNode::AddSubnode, case TOKENTYPE_SECTION_END.
Your thoughts?
Original issue reported on code.google.com by [email protected]
on 27 Nov 2007 at 9:23
What steps will reproduce the problem?
1. use template from file instead of string
2.
3.
What is the expected output? What do you see instead?
no mem leak. but using valgrind to check the status, a mem leak happened.
What version of the product are you using? On what operating system?
ctemplate: 0.93
os: ubuntu8.10
Please provide any additional information below.
in template.cc, global template_root_directory_ is allocated in
AssuredGlobalInitialized(), but looks no place to free it.
please check. maybe need an exit housekeeping action or use a smart pointer?
Original issue reported on code.google.com by [email protected]
on 10 Feb 2009 at 3:36
ctemlate 0.96 generates
#include <ctemplate/template_string.h>
static const StaticTemplateString kM_MenuItem =
STS_INIT_WITH_HASH(kM_MenuItem, "MenuItem", 12751148691163768839LLU);
It will be better if the is generated as
static const ctemplate::StaticTemplateString kM_MenuItem =
STS_INIT_WITH_HASH(kM_MenuItem, "MenuItem", 12751148691163768839LLU);
In that way i will be not forced to put "using namespace ctemplate;" before
include the generated file
Original issue reported on code.google.com by [email protected]
on 24 Nov 2009 at 8:00
[deleted issue]
At the moment code like 1 is required. Could you add operator[] so code
like 2 can be used? It seems a lot cleaner.
int pid;
dict.SetIntValue("pid", pid); // 1
dict["pid"] = pid; // 2
Original issue reported on code.google.com by olafvdspek
on 18 Jul 2009 at 4:21
What steps will reproduce the problem?
1. download the 386 deb package for a 64 bit PC
2. double click over the downloaded file
3. the lib cannot be installed: Wrong architecture 'i386'
What is the expected output? What do you see instead?
Expected output: package installed
Actual output: Wrong architecture 'i386'
What version of the product are you using? On what operating system?
version: latest
os: ubuntu hardy 64 bit
Please provide any additional information below.
N/A
Original issue reported on code.google.com by [email protected]
on 13 Oct 2008 at 3:45
I just started playing around with CTemplate, and I see that the examples
are oriented toward generating HTML or related stuff. However, if we were
to think about generating C or C++ with this tool, there would be the
issue of comma-separated lists - for class parents, constructor init
statements, enums, operation & template parameters, etc. Since I'm so new
to this tool, maybe there's simple way to generate these things that I've
overlooked, but I've so far been unable to find anything helpful in the
examples or documentation. Of course, the application can always handle
the comma logic and include commas or not in dictionary entries, but I
would hope for a more elegant solution. Anybody have any ideas or see
something I've missed?
Original issue reported on code.google.com by [email protected]
on 9 May 2007 at 5:34
[deleted issue]
[ported from sourceforge, where it was submitted by sfdivan at
users.sourceforge.net]
Minimalistic patch to build under win.
Unittests won't work for win(but i've added one working test test1.cc,
derived from template_unittest.cc), and make_tpl_varnames won't work too.
Also there is no support for multithreading, and absolute paths won't work ;)
Original issue reported on code.google.com by [email protected]
on 26 Jan 2007 at 1:07
Attachments:
I'm happy that there is a new feature, "separator" sections, is added
to the latest version. I want a similar section call "last", which is
only shown in the last section.
I currently write a C code generator using CTemplate. I wish my
template looks like following:
{{#CODE_SEC}}
{{#CODE_SEC_seperator}} case {{CASE_NUMBER}}:{{/CODE_SEC_seperator}}
{{#CODE_SEC_last}}default:{{/CODE_SEC_last}}
...
{{/CODE_SEC}}
Original issue reported on code.google.com by [email protected]
on 3 Sep 2008 at 12:08
The file src/windows/google/per_expand_data.h contains an "#ifdef WIN32"
which is problematic because WIN32 symbol is not always defined for WIN32
applications. It is defined for the projects created in MSVC IDE by default
but not if you create the projects yourself (e.g. using a tool such as
bakefile) or if you compile from the command line. The symbol _WIN32 is,
OTOH, always predefined by the compiler (see
http://msdn.microsoft.com/en-us/library/b0084kay.aspx) so it would be
better to test for it.
Or maybe you should test for _MSC_VER and not _WIN32 at all as I think the
code using stdext::hash_map<> is completely MSVC-specific. But currently if
a MSVC project doesn't define WIN32 you get several pages of not very
intelligible warnings which is not very user-friendly.
Thanks!
Original issue reported on code.google.com by [email protected]
on 20 Oct 2008 at 11:16
Can AddSectionDictionary return NULL? If so, when does it return NULL?
Original issue reported on code.google.com by olafvdspek
on 28 Jun 2009 at 6:43
What steps will reproduce the problem?
1. run .configure to get config.h
2. add files to eclipse IDE project
3. compile on ubuntu 8.04 64 bit. gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
What is the expected output? What do you see instead?
compile fails.
What version of the product are you using? On what operating system?
ubuntu 8.04 64 bit. gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
Using eclipse IDE.
Please provide any additional information below.
make all
Building file: ../source/template.cc
Invoking: GCC C++ Compiler
g++ -I"/home/jay/axion/ctemplate/source"
-I"/home/jay/axion/ctemplate/source/base"
-I"/home/jay/axion/ctemplate/source/google" -O0 -g3 -Wall -c
-fmessage-length=0 -MMD -MP -MF"source/template.d" -MT"source/template.d"
-o"source/template.o" "../source/template.cc"
In file included from
/home/jay/axion/ctemplate/source/google/template_dictionary.h:57,
from /home/jay/axion/ctemplate/source/google/template.h:51,
from ../source/template.cc:58:
/home/jay/axion/ctemplate/source/google/template_modifiers.h:289: error:
‘hash_compare’ was not declared in this scope
/home/jay/axion/ctemplate/source/google/template_modifiers.h:289: error:
template argument 3 is invalid
/home/jay/axion/ctemplate/source/google/template_modifiers.h:289: error:
expected unqualified-id before ‘,’ token
/home/jay/axion/ctemplate/source/google/template_modifiers.h:292: error:
‘DataMap’ does not name a type
In file included from /home/jay/axion/ctemplate/source/google/template.h:51,
from ../source/template.cc:58:
as provided the source code references missing include files.
Changed includes to
#include <ext/hash_set>
#include <ext/hash_map>
this defines hash_map but neither defines the compare operator.
Original issue reported on code.google.com by [email protected]
on 3 Nov 2008 at 5:04
Compiling src/tests/htmlparser_test.cc fails with undefined symbols strchr,
memchr, strlen due to header cleanup in gcc-4.3.x/glibc-2.8
Furthermore the project seems to use deprecated c++ headers in various places.
The attached patch fixes the compilation failure and replaces some of the
deprecated header-files in htmlparser_test.cc by the corresponding new ones.
Original issue reported on code.google.com by [email protected]
on 10 Aug 2008 at 1:46
Attachments:
The file src/template.cc uses static_cast and reinterpret_cast incorrectly
in 2 instances as these casts can't be used to remove "const". The attached
trivial patch fixes compilation with VC8 and VC9 (a.k.a. MSVS 2005 and
2008) without any ill effects on neither g++ nor VC7 (MSVS 2003) build.
Original issue reported on code.google.com by [email protected]
on 17 Oct 2008 at 4:43
Attachments:
What steps will reproduce the problem?
1.
2.
3.
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 7 Aug 2009 at 7:20
[ported from sourceforge, where it was submitted by sfdivan at
users.sourceforge.net]
Almost the final step is filesystem-stuff.
It's not complete, for example in what format would you prefer to use path:
os::native, posix, other?
Sad thing - we'll need to include another boost lib - boost::filesystem :)
Original issue reported on code.google.com by [email protected]
on 26 Jan 2007 at 1:05
Attachments:
This is more about what I did to make it work rather than a defect itself.
The goal was to compile against shared libgcc and libstdc++.dll with GCC
4.4.0 (MinGW stock). I would appreciate some assistance in figuring out why
the SCRIPTS test fails. The two outputs look the same on-screen, but I
cannot find where these files are actually layed out on-disk for comparison.
configure was run within MSYS with default options, and the following
environment variables set:
CXXLD=gcc
LDFLAGS="-shared-libgcc -Wl,--enable-auto-import
-Wl,--enable-auto-image-base -Wl,--export-all-symbols"
LIBS="-lstdc++_s -lsupc++"
Manually edit the resulting Makefile:
set line 311 to
CXXLD=gcc
set line 427 to
PTHREAD_LIBS=-mthreads
Near line 100, add libctemplate_la-port.lo to am_libctemplate_la_OBJECTS
Repeat for am_objects_2 am_objects_3 and am_objects_4.
Near line 1215, copy the definition of libctemplate_la-template.lo to
provide a rule for libctemplate_la-port.lo depending on src/windows/port.cc
Manually edit src/config.h:
#undef HAVE_RWLOCK
#undef HAVE_PTHREAD
#define PRIdS "Id"
#define PRIuS "Iu"
#define PRIxS "Ix"
#ifndef GOOGLE_CTEMPLATE_WINDOWS_CONFIG_H
#define GOOGLE_CTEMPLATE_WINDOWS_CONFIG_H
#include "windows/port.h"
#endif
Manually edit src/windows/port.h (see attached)
Compile the project with `make -j2`. Observe repeated warnings about
src/ctemplate/template_string.h:165 dereferencing pointer <anonymous> does
break strict-aliasing rules
Observe that libtool in its great idiocy on windows will refuse to link
DLL's against libsupc++.a. Therefore, manually link them as follows:
$ cd .libs
$ gcc -shared -shared-libgcc -mthreads -o ctemplate.dll
-Wl,--out-implib,libctemplate.a libctemplate_la*.o -lstdc++_s -lsupc++
-Wl,--enable-auto-image-base -Wl,--enable-auto-import -Wl,--export-all-symbols
$ # Repeat for the other 3 dll configurations
$ cp *.dll ../ && cd ../
Compile and run the test suite.
Remove the check_SCRIPTS task from check-am, near line 2135. This test
fails (due to line endings?) and inhibits further testing
$ PATH=/c/Python26:$PATH make check
===================
All 18 tests passed
===================
The resulting ctemplate.dll depends on libstdc++-6.dll libgcc_s_dw2-1.dll,
mingwm10.dll, and msvcrt.dll. I have attached all four DLLs. The
non-debug builds have been stripped.
Original issue reported on code.google.com by [email protected]
on 19 Nov 2009 at 7:40
Attachments:
In tpl-mode.el
http://code.google.com/p/google-ctemplate/source/browse/trunk/contrib/tpl-mode.e
l
There's a TODO for multiline comments,
;; TODO(tonyg) Figure out a way to support multiline comments.
(defconst tpl-mode-comment "\\({{!.*?}}\\)")
The repaired line could read
(defconst tpl-mode-comment "\\({{![^}]?}}\\)")
This is known to work.
See
http://code.google.com/p/hapax2/source/browse/support/emacs/tpl-mode.el
Original issue reported on code.google.com by john.douglas.pritchard
on 10 Oct 2009 at 1:20
When compiling a file that includes google/template.h,
I get warnings like this:
ctemplate-0.7/src/google/template_modifiers.h:169: warning: ‘class
google::template_modifiers::HtmlEscapeWithArg’ has virtual functions but
non-virtual destructor
Using g++ (g++ (GCC) 4.1.2), google-ctemplate version 0.7.
An easy fix is to add
virtual ~TemplateModifier() {}
to template_modifiers.h at line 95.
Original issue reported on code.google.com by [email protected]
on 20 Aug 2007 at 1:31
The ctemplate is great, but I met a problem when I try to expand the
template file with large data(up to 20M).
as I know, the procedure to expand a template is to: get tpl; set dict;
expand to string buffer; write buffer to dest file.
1. when data is very large, i.e. 10M, the dict is very large
2. the expanded buffer is very large.
is it possible a dict item referring to a external file?
is it possible directly expand tpl to file instead of totally in memory?
Thanks,
Eric
Original issue reported on code.google.com by [email protected]
on 4 Feb 2009 at 9:22
[ported from sourceforge, where it was submitted by sfdivan at
users.sourceforge.net]
Using that header will help to write msvc compatible port. Tested under g++
3.4.2+, msvc8 (in that case you should "#define HASH_NAMESPACE stdext" in
config.h)
Original issue reported on code.google.com by [email protected]
on 26 Jan 2007 at 1:00
Attachments:
Attached is 64 bit RPMs for ctemplate 0.92.
Original issue reported on code.google.com by [email protected]
on 2 Feb 2009 at 11:59
Attachments:
What steps will reproduce the problem?
1.
2.
3.
What is the expected output? What do you see instead?
Please use labels and text to provide additional information.
Original issue reported on code.google.com by [email protected]
on 28 Sep 2009 at 4:55
Looks like ctemplate uses a deprecated header somewhere.
In file included from /usr/include/c++/4.3/ext/hash_map:64,
from /usr/include/google/template_dictionary.h:55,
from /usr/include/google/template.h:48,
from /home/olaf/xcc/wol/Web Server/request_handler.cpp:6:
/usr/include/c++/4.3/backward/backward_warning.h:33:2: warning: #warning
This file includes at least one deprecated or antiquated header which may
be removed without further notice at a future date. Please use a
non-deprecated interface with equivalent functionality instead. For a
listing of replacement headers and interfaces, consult the file
backward_warning.h. To disable this warning use -Wno-deprecated.
$ g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-mpfr --enable-targets=all --enable-cld --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)
$ dpkg -l|grep ctem
ii libctemplate-dev 0.93-1
This package contains a library implementing
ii libctemplate0 0.93-1
This package contains a library implementing
Original issue reported on code.google.com by olafvdspek
on 14 Apr 2009 at 11:42
Only including the development packages in featured downloads isn't very
useful. I think it's better not to include them if there's not enough space
to also include the normal packages.
Original issue reported on code.google.com by olafvdspek
on 28 Jun 2009 at 6:15
Why is this project organized in such strange way, with multiple *.h.in
files which need to be preprocessed for Windows instead of a single
config.h (which would still need to be manually written for Windows but it
would be _one_ file only) included by all the files? This makes it more
painful than necessary to change anything when working under Windows as you
need to modify the .h.in file, preprocess it, test your changes, correct
them in .h.in file (and not in the .h file where the error occurs as
changes to it can't be easily backported to .h.in) and then make a patch
containing both changes.
It would be really much better if a single config.h could be used and
AFAICS there are no technical difficulties with this. I'd be willing to
provide a patch changing the build system to use config.h if you decide to
accept it.
Original issue reported on code.google.com by [email protected]
on 20 Oct 2008 at 11:19
Is there cookie support for this? Is there a mailing list or forum for
google-ctemplate? Thank you
Original issue reported on code.google.com by [email protected]
on 12 Nov 2009 at 4:40
It seems this needs to be in upstream. May be it is already but it would be
great if distributed tarball have these changes.
diff -Naur ctemplate-0.90.orig/src/tests/htmlparser_test.cc
ctemplate-0.90/src/tests/htmlparser_test.cc
--- ctemplate-0.90.orig/src/tests/htmlparser_test.cc 2008-08-10
15:33:53.000000000 +0200
+++ ctemplate-0.90/src/tests/htmlparser_test.cc 2008-08-10
15:35:10.000000000 +0200
@@ -62,9 +62,10 @@
// insert_text: Executes HtmlParser::InsertText() if the argument is true.
#include "config_for_unittests.h"
-#include <stdlib.h>
+#include <cstdlib>
#include <ctype.h>
-#include <assert.h>
+#include <cassert>
+#include <cstring>
#include <string>
#include <utility>
#include <vector>
Original issue reported on code.google.com by [email protected]
on 23 Aug 2008 at 9:13
Not that important, but should hardly take any time.
Original issue reported on code.google.com by [email protected]
on 5 Jan 2007 at 11:07
I have code that worked fine with 0.92 and in 0.93 either refuses to
compile or if compiled refuses to run.
What steps will reproduce the problem?
1. Create main.cpp and add the following
#include <google/template_dictionary.h>
#include "template.h"
using google::Template;
using google::TemplateDictionary;
TemplateDictionary * dict;
/*
*
*/
int main(int argc, char** argv)
{
dict = new TemplateDictionary("class");
return (EXIT_SUCCESS);
}
2. Try to compile with:
g++ -I/usr/local/include/google -lctemplate_nothreads main.cpp
What is the expected output? What do you see instead?
In 0.92 it would compile, instead with 0.93 I get the following:
/tmp/cc4izpr8.o: In function
`__static_initialization_and_destruction_0(int, int)':
main.cpp:(.text+0x28): undefined reference to
`google::StaticTemplateStringInitializer::StaticTemplateStringInitializer(google
::StaticTemplateString
const*)'
collect2: ld returned 1 exit status
With some fiddling I can get it to compile however when it does it produces
the following runtime error:
symbol lookup error: ./dist/Debug/test: undefined symbol:
_ZN6google31StaticTemplateStringInitializerC1EPKNS_20StaticTemplateStringE
What version of the product are you using? On what operating system?
0.93 Linux - SuSe 11.1 64 bit
Original issue reported on code.google.com by [email protected]
on 7 Feb 2009 at 5:32
The latest version of the library allocates template_string_set and arena
global variables in template_string.cc in AddToGlobalIdToNameMap(). This is
not really such a huge problem as these variables are only allocated once
and so, strictly speaking, it's not a memory leak but it's still annoying
when using any memory leak checker as it certainly detects it as one. This
includes the built-in MSVC CRT checker meaning that I get plenty of leak
reports (as it also finds the blocks allocated from these objects ctors)
whenever I run my application using the library.
So I fixed it in the simplest way I could think of:
--- lib/ctemplate/src/template_string.cc (revision 316)
+++ lib/ctemplate/src/template_string.cc (working copy)
@@ -238,6 +238,15 @@
TemplateStringSet* template_string_set;
UnsafeArena* arena;
+
+// Clean up the variables above when the program terminates.
+struct GlobalsCleanup {
+ ~GlobalsCleanup() {
+ delete template_string_set;
+ delete arena;
+ }
+} globalsCleanup;
+
} // namespace
I don't know if it would be better to provide an explicit cleanup function,
but at least this fixes the problem with memory leaks reports I had.
Thanks!
Original issue reported on code.google.com by [email protected]
on 11 Aug 2009 at 10:48
I have provided pkg-config support for ctemplate, to make it easier to
distribute and use this library in other projects. Attached is a patch to
the build system against the current (as of 2008-05-02) repository.
I wasn't sure how to handle the _nothreads case, so I include two separate
pkgconfig entries. Feel free to revise as you see fit.
Original issue reported on code.google.com by [email protected]
on 2 May 2008 at 11:19
Attachments:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.