hefeix / szl Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/szl
License: Other
Automatically exported from code.google.com/p/szl
License: Other
In ProcessCommandLineArguments, strtol's endptr is checked for '\0' to make
sure the integer parsing didn't end on an error, but it doesn't check the
corner case that the string is entirely empty. Empty-string is not an integer.
On some platforms, errno is set to a nonzero value when this happens, but if
you want to rely on that, why use endptr at all?
The patch fixes it by entering the error branch if the value is the empty
string.
Original issue reported on code.google.com by aecolley
on 13 Nov 2010 at 2:12
Attachments:
I've extracted szl source and configured it. Then I tried top run `make'.
I expected to have szl compiled, but instead I 've seen the following:
engine/symboltable.cc:47:1: error: ‘sawzall::Proc::Proc’ names the
constructor, not the type
I've tried to compile szl on OpenSUSE 11.3 x86_64 (kernel 2.6.35) with gcc 4.5
and protoc 2.3.
When I edited engine/symboltable.cc (see attached patch), the code was compiled
successfully. I could not test if the compiler runs properly because I could
not find a single Sawzall tutorial on the web.
Original issue reported on code.google.com by [email protected]
on 4 Nov 2010 at 4:40
Attachments:
After modifying ``configure.ac`` and rerunning ``autoreconf -f``, ``svn``
reports the following:
$ svn status | grep ^M
M configure
M Makefile.in
M src/Makefile.in
M configure.ac
M aclocal.m4
All files above are generated from ``configure.ac``, so I think there's no need
to keep them in Subversion.
Original issue reported on code.google.com by [email protected]
on 5 Nov 2010 at 6:28
Compiling on Ubuntu 10.4 (32 bit):
make[3]: Entering directory `/home/carlos/src/szl-svn/protobuf-location/src'
/bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -pthread -I/opt/protobuf/2.3.0/include -pthread -g -O2 -g -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -DNDEBUG -pthread -O2 -DSZL_BIG_ENDIAN=1 -DSZL_LITTLE_ENDIAN=2 -DSZL_BYTE_ORDER=2 -g -O1 -pthread -g -O2 -g -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -DNDEBUG -MT analyzer.lo -MD -MP -MF .deps/analyzer.Tpo -c -o analyzer.lo `test -f 'engine/analyzer.cc' || echo './'`engine/analyzer.cc
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -pthread -I/opt/protobuf/2.3.0/include -pthread -g -O2 -g -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -DNDEBUG -pthread -O2 -DSZL_BIG_ENDIAN=1 -DSZL_LITTLE_ENDIAN=2 -DSZL_BYTE_ORDER=2 -g -O1 -pthread -g -O2 -g -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -DNDEBUG -MT analyzer.lo -MD -MP -MF .deps/analyzer.Tpo -c engine/analyzer.cc -fPIC -DPIC -o .libs/analyzer.o
In file included from ./engine/globals.h:20,
from engine/analyzer.cc:20:
./public/porting.h:51: error: conflicting declaration �typedef long unsigned int uintptr_t�
/usr/include/stdint.h:129: error: �uintptr_t� has a previous declaration as �typedef unsigned int uintptr_t�
make[3]: *** [analyzer.lo] Error 1
make[3]: Leaving directory `/home/carlos/src/szl-svn/protobuf-location/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/carlos/src/szl-svn/protobuf-location/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/carlos/src/szl-svn/protobuf-location'
make: *** [all] Error 2
The attached diff skips the typedef if ``stdint.h`` has been found: It seems
that C99 specifies that type (http://en.wikipedia.org/wiki/Stdint.h)
Original issue reported on code.google.com by [email protected]
on 5 Nov 2010 at 7:10
Attachments:
The default values for the --protocol_compiler and --protocol_compiler_plugin
path point to /usr/local. These paths should depend on the result of running
configure.
The attached patch achieves it.
Original issue reported on code.google.com by aecolley
on 17 Oct 2013 at 12:06
Attachments:
As of r33, the configure script asumes protobuf is installed on standard
locations (headers under /usr/include, libraries under /usr/bin).
If ``pkg-config`` is installed, one can always do the following:
$ env CPPFLAGS="$(pkg-config --cflags protobuf)" \
LIBS="$(pkg-config --libs protobuf)" \
./configure [..]
The attached diff eliminates the need to do that, and simplifies a bit
``configure.ac`` -- it also makes building ``szl`` depend on ``pkg-config``,
though.
Original issue reported on code.google.com by [email protected]
on 5 Nov 2010 at 6:24
Attachments:
elfgen_unittest.cc is hard-coded to expect 64-bit length addresses from objdump
text output. On 32-bit platforms the string is shorter and has leading zeros
and extra trailing garbage.
actual="094d5b3a l F "
expected="00000000094d5b3a "
Original issue reported on code.google.com by [email protected]
on 16 Nov 2010 at 5:26
Some of my testing environments are hitting this failed assertions in the
szlbootstrapsum unittest. I suspect this is due to direct equality comparison
of floating point values.
Original issue reported on code.google.com by [email protected]
on 16 Nov 2010 at 4:41
complie error
engine/code.cc: In static member function ‘static void
sawzall::Code::MemMapCode(sawzall::Instr*, size_t, sawzall::Instr**,
size_t*)’:
engine/code.cc:364:48: error: ‘getpagesize’ was not declared in this scope
make[3]: *** [code.lo] Error 1
make[3]: Leaving directory `/data/opencode/szl/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/data/opencode/szl/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/data/opencode/szl'
make: *** [all] Error 2
3.2.0-4-686-pae #1 SMP Debian 3.2.35-2 i686 GNU/Linux
gcc --version
gcc (Debian 4.7.2-5) 4.7.2
Original issue reported on code.google.com by [email protected]
on 6 Mar 2013 at 9:50
Ubuntu natty has changed the default ld flags to include --as-needed, which
only links in libraries detected as used:
https://lists.ubuntu.com/archives/ubuntu-devel/2010-November/031991.html
Consequently, szl's intrinsics and extensions libraries do not get linked in,
and you you get all kinds of errors:
$ src/szl -e 'emit stdout <- string(fabs(-1.1));'
<commandline>:1: fabs undeclared
To fix, I need to make autoconf detect GNU ld and add -Wl,--no-as-needed to the
LDFLAGS.
Original issue reported on code.google.com by [email protected]
on 19 Nov 2010 at 7:16
When szl is built with NDEBUG, it asserts:
lt-szl: engine/nativesupport.cc:1372: static void
sawzall::NSupport::AllocStatics(sawzall::Proc*, size_t): Assertion
`proc->state_.sp_ == proc->state_.fp_->stack()' failed.
e.g.:
$ src/szl -e 'emit stdout <- "Hello";'
(assertion)
Aborted
Original issue reported on code.google.com by [email protected]
on 15 Nov 2010 at 2:00
Hi,
You have a typo that isn't including malloc.h header in src/engine/memory.cc.
It should be HAVE_MALLINFO and not HAVE_MALLINGO.
src/engine/memory.cc:
[...]
#ifdef HAVE_MALLINGO
#include <malloc.h> // for mallinfo()
#endif
[...]
#ifdef HAVE_MALLINFO
struct mallinfo info = mallinfo();
// Ack, limited to 4GB. Stored as "int", make sure we use full 32 bits.
int64 freespace = static_cast<unsigned int>(info.fordblks);
// As we get closer to running out of process memory, get more aggressive
// about requiring that malloc space is available to minimize the chance
// that we will run out of process memory.
// (If we seem to have enough, do nothing and hope malloc succeeds.)
#else
int freespace = 0;
#endif
[...]
Original issue reported on code.google.com by [email protected]
on 5 Nov 2010 at 8:58
What steps will reproduce the problem?
1. Run the command: "src/szl example1.szl"
2.
3.
What is the expected output? What do you see instead?
I am intentionally not providing an input datafile; normally I'd expect a
syntax error, but instead I get a Segfault.
What version of the product are you using? On what operating system?
I am on Ubuntu 10.04, 32bit, Intel x86
Please provide any additional information below.
1)
The stacktrace is as follows:
#0 0x004b7fd3 in ?? ()
#1 0x00bb54d4 in sawzall::Proc::Execute (this=0x9f44168, max_steps=2147483647,
num_steps=0x0) at engine/proc.cc:403
#2 0x00bc08fe in sawzall::Process::Execute (this=0xbff18ca0,
max_steps=2147483647, num_steps=0x0) at engine/sawzall.cc:636
#3 0x00bc1488 in sawzall::Process::Run (this=0xbff18ca0, input_ptr=0x804de94 "
", input_size=0, key_ptr=0x804de94 " ", key_size=0) at engine/sawzall.cc:669
#4 0x00bc154e in sawzall::Process::RunOrDie (this=0xbff18ca0,
input_ptr=0x804de94 " ", input_size=0, key_ptr=0x804de94 " ", key_size=0) at
engine/sawzall.cc:689
2)
BTW, when I generated bytecode instead of native code it works fine. That is:
src/szl example1.szl -native=false
works correctly...
Original issue reported on code.google.com by [email protected]
on 7 Nov 2010 at 10:39
Attachments:
Their base class SzlTabEntry has member tot_elems_ so no need to redefine.
PATCH:
Index: src/emitters/szlmaximum.cc
===================================================================
--- src/emitters/szlmaximum.cc (revision 53)
+++ src/emitters/szlmaximum.cc (working copy)
@@ -91,7 +91,6 @@
return sizeof(SzlMaximumEntry) + heap_.Memory() + sizeof(SzlValueCmp);
}
- virtual int64 TotElems() const { return tot_elems_; }
virtual int TupleCount() { return heap_.nElems(); }
const SzlOps& weight_ops() const { return weight_ops_; }
@@ -103,9 +102,6 @@
// TODO: Add an iterator for sorted output to improve
// FlushForDisplay performance.
SzlHeap heap_;
-
- // Total elements ever added to the table.
- int64 tot_elems_;
};
};
Index: src/emitters/szlquantileresults.cc
===================================================================
--- src/emitters/szlquantileresults.cc (revision 53)
+++ src/emitters/szlquantileresults.cc (working copy)
@@ -89,14 +89,11 @@
virtual const vector<string>* Results() { return &quantiles_; }
- virtual int64 TotElems() const { return tot_elems_; }
-
private:
SzlType type_; // the type of the table
SzlOps ops_; // Operations on our element type, for parsing.
vector<string> quantiles_;
const int num_quantiles_;
- int64 tot_elems_;
void Clear() {
quantiles_.clear();
Original issue reported on code.google.com by [email protected]
on 19 Jan 2013 at 4:53
Please mention something like this on the first page.
$ szl --table_output='*' example.szl input.txt
Original issue reported on code.google.com by [email protected]
on 1 May 2012 at 4:48
The regression tests sort/sort_0{1,2,3,4}.szl all fail in -N (native) mode on
x86_64 Ubuntu 13.04 when compiled with -O1 or higher. Compiling
nativecodegen.cc with -O0 is a workaround.
The root cause appears to be that FunctionCall (a class defined in
nativecodegen.cc) copies a reference-typed constructor argument to a
reference-typed member variable, and then accesses it in ~FunctionCall after
the original constructor argument has been deallocated by the caller. To put it
another way, each FunctionCall retains a pointer to a stack object and
dereferences it after its lifetime has expired. The decision to use '&' instead
of '*' rendered the bug difficult to see on code review.
One-byte code patch attached, representing two days of debugging work. Two
days. One byte. This is why I hate C++.
Original issue reported on code.google.com by aecolley
on 20 Oct 2013 at 4:05
Attachments:
The szl_regtest.sh test base/include_b.szl is broken; it should not pass.
The szl_regtest.sh support script ./update has a bug which masks the brokenness.
The test apparently is intended to work like so:
- base/include_b.szl loads and executes base/include_dir/a.szl
- a.szl includes b.szl
- b.szl declares a variable x
- base/include_b.szl assigns to x (thereby checking that b.szl was successfully executed)
However, this cannot work as (apparently) intended because include_b.szl uses
the load() builtin to load a.szl, and load() does not attempt to execute or
otherwise interpret the bytes that it loads. Ref:
http://szl.googlecode.com/svn/doc/sawzall-intrinsics.html
The test harness support script src/engine/language_tests/update has a large
shell-case-statement with special settings for different test sources. The case
for base/include_b.szl inserts "base/include_dir/a.szl" into the $sources
variable. However, only the first word in that variable is used as the szl
program; subsequent words are used as input data filenames. The effect of all
this is that the test executes a.szl and ignores include_b.szl.
I am at a loss to recommend a fix, as the whole test appears to be a confusion
of ideas complicated by a confused idea. I recommend deleting all three files
unless the author has a better idea.
Original issue reported on code.google.com by aecolley
on 3 Jun 2014 at 3:15
OS : x86_64 GNU/Linux
App : szl 1.0 (http://code.google.com/p/szl/downloads/list)
Input :The input file is recordio format which is offer by szl, with 100
records in it. Each record has channel field, bug only 92 records have
refer_info.g_f.
Script : case_ok.szl, case_bad1.szl, base_bad2.szl
Question : the three cases are suppose to have same result , but it is not.
Case 1:
Input sawzall script :(case_ok.szl)
.....
1 proto "log_wap_access.proto"
2
3 pv_channel : table sum[channel:bytes] of int;
4
5 log : log_wap_access = input;
6 channel: bytes = ?{if(def(log.channel)) result log.channel; else result B"";};
7 emit pv_channel[channel] <- 1;
....
Input data :(input)
Run command :./szl case_ok.szl input --use_recordio=true --protocol_compiler=./protoc --protocol_compiler_plugin=./protoc-gen-szl --table_output=*
Result : pv_channel[WAP_SWEB_ACS] = 100
Case 2:
Input sawzall script :(case_bad1.szl)
....
1 proto "log_wap_access.proto"
2
3 pv_channel : table sum[channel:bytes] of int;
4
5 log : log_wap_access = input;
6 channel: bytes = ?{if(def(log.channel)) result log.channel; else result B"";};
7 emit pv_channel[channel] <- 1;
8
9 # this variable is not used
10 usless : uint = log.refer_info.g_f;
....
Input data :(input)
Run command :./szl case_bad1.szl input --use_recordio=true --protocol_compiler=./protoc --protocol_compiler_plugin=./protoc-gen-szl --table_output=*
Result: pv_channel[WAP_SWEB_ACS] = 92
pv_channel[] = 8
Case 3:
Input sawzall script :(case_bad2.szl)
....
1 proto "log_wap_access.proto"
2
3 pv_channel : table sum[channel:bytes] of int;
4
5 # this variable is not used
6 usless_table : table collection of log_wap_access;
7
8 log : log_wap_access = input;
9 channel: bytes = ?{if(def(log.channel)) result log.channel; else result B"";};
10 emit pv_channel[channel] <- 1;
....
Input data :(input)
Run command :./szl case_bad2.szl input --use_recordio=true --protocol_compiler=./protoc --protocol_compiler_plugin=./protoc-gen-szl --table_output=*
Result: pv_channel[WAP_SWEB_ACS] = 92
pv_channel[] = 8
Original issue reported on code.google.com by [email protected]
on 2 Mar 2012 at 11:31
Attachments:
What steps will reproduce the problem?
1. Run configuration script on Mac OS X with Xcode installed:
./configure
What is the expected output? What do you see instead?
Expecting ./configure generates Makefiles.
What version of the product are you using? On what operating system?
./configure failed with the following outputs:
checking for objdump... no
configure: error: in `/Users/wangyi/svnclient/szl-read-only':
configure: error: no objdump utility was found (required for elfgen_unittest)
Please provide any additional information below.
objdump is from GNU tools and mostly used with Linux, but Mac OS X inherits
user space programs from BSD. Is it possible to make configure choose otool,
instead of objdump, on Mac OS X?
Original issue reported on code.google.com by Yi.Wang.2005
on 4 Jul 2011 at 1:21
Here's an "svn diff" patch to fix the multiple minor problems (mostly
linuxisms) that stopped it from building on FreeBSD. With this patch, "gmake
check" passes. I've tried to rely on only standard features wherever possible,
but on some of the scripts I wussed out and said "run bash" instead.
Summary of changes:
- Prefer standard POSIX shell constructs where possible:
- Bash isn't necessarily in /bin (FreeBSD puts it in /usr/local/bin);
- expr-matching instead of grep <<< string;
- case-statement instead of == inside [[ ]];
- "foo()" instead of "function foo";
- "for (( s1; expr; s2 ))" is not supported;
- "$SZL" in command position isn't always expanded correctly [actually, I'm not sure about this since I found some instances of $"$SZL" that might explain the odd error messages]; and
- in test statements, "-eq" instead of "==".
- Detect at configure time whether va_copy is supported, and if so use it
instead of trying to use __va_copy.
- Use a union type to effect reinterpret-casting between double and unsigned
long long; the pointer-reinterpretation approach failed disastrously with the
requested -O2 -fstrict-aliasing flags, causing incorrect values to come out of
the cast.
- On systems without ieee754.h (e.g. FreeBSD), generate random floats and
doubles by multiplying the minimum representable value >1 by a random integer
to get an exactly-representable value. I microbenchmarked this and found it to
be a tiny bit faster than the existing
fill-a-struct-of-bitfields-and-reinterpret-cast approach. Oddly, it returned
the same values given the same random seed; you might consider using it even if
ieee754.h is available.
- An abs() call had an ambiguous type since it had definitions available for
int and long, but not for long long which was the actual arg type. Replaced
with llabs().
- The declaration of uintptr_t clashed with the slightly different declaration
in the standard library, so it was made conditional on an autoconf check.
- ACX_USE_SYSTEM_EXTENSIONS doesn't exist, and that first X is probably a typo.
Read the ./configure output next time! :-)
Happy patching!
--Adrian.
who/aecolley
Original issue reported on code.google.com by aecolley
on 8 Nov 2010 at 3:46
Attachments:
Full build log is attached, jump to the first check-TESTS reference.
I'm using a Debian sid chroot to build.
Original issue reported on code.google.com by [email protected]
on 5 Nov 2010 at 9:52
Attachments:
What steps will reproduce the problem?
1. ./configure
then broken
What is the expected output? What do you see instead?
error info:
checking protobuf header version... yes (2.3.0 or later)
checking for protobuf library... yes
checking for protocol compiler library... configure: error: in
`/home/xyz/code/szl':
configure: error: no working protocol compiler library was found
See `config.log' for more details.
but i have successfully installed protocol buffer in /usr/bin/protoc.
whereis protoc
protoc: /usr/bin/protoc /usr/local/bin/protoc /usr/share/man/man1/protoc.1.gz
What version of the product are you using? On what operating system?
szl-1.0.tar.gz ubuntu
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 6 Nov 2010 at 4:34
Attachments:
spelling error.
Original issue reported on code.google.com by [email protected]
on 10 Apr 2012 at 1:17
Attachments:
Native mode on linux x86_64 stack traces fail to terminate at the $main or
$init frame as documented; they continue and produce "no symbolic frame
information (initialization frame?)" for non-nativecodegen C++ stack frames.
The underlying problem is the incorrect assumption that the stack always grows
downward with the same layout. This assumption is made in frame.cc:
bool FrameIterator::is_valid() const {
if (native_)
return sp() <= proc()->native_bottom_sp();
[...]
}
In practice, the top szl frame has sp() == proc()->native_bottom_sp(), but
often the next few C++ frames have values in the "sp" slot which are
numerically less than the nativecodegen's bottom_sp. FrameIterator::is_valid
misidentifies them as valid szl native frames.
Walking through memory, deferencing pointers at random, seems dangerous in
itself. That's why this is a separate bug and not just part of issue 19.
Original issue reported on code.google.com by aecolley
on 13 Oct 2013 at 9:32
Attachments:
According to a comment in ``sawzall.h``, the following files are Sawzall's
public interface:
porting.h
sawzall.h
emitterinterface.h
szltype.h
szlvalue.h
szlresults.h
szlencoder.h
szldecoder.h
szlnamedtype.h
value.h
Some of those files, however, do a ``#include "public/szltype.h"``, which does
not work outside Sawzall's source tree.
The attached diff addresses this by removing the ``#include
"public/szltype.h"`` line from the header files, and adding it to the source
files that need it.
I don't like the fact that now the order of included files matters (you have to
include ``szltype.h`` before including ``szlresults.h``, for instance). Any
idea on a better approach?
Original issue reported on code.google.com by [email protected]
on 11 Nov 2010 at 7:15
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 3 Nov 2010 at 8:14
From a chroot:
# szl hw2.szl
[FATAL sysutils.cc:79] assertion failed: CHECKGE(fd,0)
Aborted
# mount -t proc proc /proc
# szl hw2.szl
Hello, World!
src/utilities/sysutils.cc:78
int fd = open("/proc/meminfo", O_RDONLY);
CHECK_GE(fd, 0);
I think something like the line below at 79 would work better:
CHECK_GE(fd,0) << ": Is proc mounted?";
Original issue reported on code.google.com by [email protected]
on 29 Nov 2010 at 7:20
Compiling with clang fails with:
engine/symboltable.cc:47:7: error: qualified reference to 'Proc' is a
constructor name rather than a type wherever a cons
Proc::Proc* SymbolTable::init_proc_ = NULL;
This patch fixes the issue, tested on OS X 10.9, Xcode 5.1:
diff --git a/src/engine/symboltable.cc b/src/engine/symboltable.cc
index 6d84592..71965f3 100644
--- a/src/engine/symboltable.cc
+++ b/src/engine/symboltable.cc
@@ -44,7 +44,7 @@ namespace sawzall {
// ------------------------------------------------------------------------------
// Implementation of SymbolTable
-Proc::Proc* SymbolTable::init_proc_ = NULL;
+Proc* SymbolTable::init_proc_ = NULL;
List<TableType*>* SymbolTable::table_types_ = NULL;
TableType* SymbolTable::collection_type_ = NULL;
Original issue reported on code.google.com by [email protected]
on 12 Apr 2014 at 9:44
I have get a new problem after run "./configure" successfully.
$ sudo make
make all-recursive
make[1]: Entering directory `/home/xyz/code/szl'
Making all in .
make[2]: Entering directory `/home/xyz/code/szl'
make[2]: Leaving directory `/home/xyz/code/szl'
Making all in src
make[2]: Entering directory `/home/xyz/code/szl/src'
make[3]: Entering directory `/home/xyz/code/szl'
make[3]: Leaving directory `/home/xyz/code/szl'
oldpwd=`pwd` && ( cd . && /usr/local/bin/protoc -I. --cpp_out=$oldpwd
emitvalues/sawzall.proto )
/usr/local/bin/protoc: error while loading shared libraries: libprotobuf.so.6:
cannot open shared object file: No such file or directory
make[2]: *** [emitvalues/sawzall.pb.cc] Error 127
make[2]: Leaving directory `/home/xyz/code/szl/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/xyz/code/szl'
make: *** [all] Error 2
$ whereis libprotobuf.so.6
libprotobuf.so: /usr/lib/libprotobuf.so.5 /usr/lib/libprotobuf.so
/usr/local/lib/libprotobuf.so.6 /usr/local/lib/libprotobuf.so
Original issue reported on code.google.com by [email protected]
on 6 Nov 2010 at 5:02
If you build a recent ICU4C library (4.8 or newer) with the recommended build
settings, szl will:-
1. Fail to build because:-
(a) the UnicodeString(const char *) constructor is now marked "explicit" in line with C++ good practice, so it now needs to be explicitly invoked in cases where implicit calls were made; and
(b) references to TimeZone and UnicodeString need to be qualified (i.e. icu::UnicodeString). This is an optional-but-recommended build setting in ICU.
2. Fail to run correctly because calls to icu::TimeZone::createTimeZone now
return the Etc/Unknown zone for unknown timezone IDs. Szl expects it to return
the GMT zone (which ICU hasn't done since 4.7).
The fixes are simple. A patch is attached to this bug report. The existing
engine/language_tests/intrinsics/time_01.szl test acts as a unit test. (It
fails with szl r53 and icu 4.8.)
Original issue reported on code.google.com by aecolley
on 13 Oct 2013 at 7:56
Attachments:
Consolidating various check-TESTS failures into a single issue:
* emitter/tables_misc_good.szl:
: due to output sorting order with different standard libraries
* [FATAL szlbootstrapsum_unittest.cc:141] assertion failed:
CHECK(original[offset + 1].real + update[1].real == table[offset + 1].real)
: due to float comparison with ==
* [FATAL elfgen_unittest.cc:99] assertion failed: CHECKEQ(actual,expected)
: on 32-bit platforms due to objdump text address output width
* intrinsics/resourcestats-32.szl
: due to .err file having unknown flag warning
* intrinsics/resourcestats-64.szl
> user CPU time variance percentage too high, actual: 112, expected range: [0,
100]
: (user reported, 64-bit Debian sid build)
Original issue reported on code.google.com by [email protected]
on 16 Nov 2010 at 6:26
The attached diff adds pkg-config files for Sawzall's three libraries. Once
applied, embedding Sawzall in programs like this one:
//
// test.cc
//
#include <google/szl/porting.h>
#include <google/szl/commandlineflags.h>
#include <google/szl/sawzall.h>
int main(int argc, char **argv) {
InitializeAllModules();
sawzall::Executable exe(argv[1], NULL, sawzall::kNormal);
}
is just a matter of running:
$ g++ $(pkg-config --cflags szl) \
szl-test.cc -o szl-test \
$(pkg-config --libs szl)
Original issue reported on code.google.com by [email protected]
on 10 Nov 2010 at 8:10
Attachments:
What steps will reproduce the problem?
1, code:
test_set: table set(1) of string;
emit test <- "A";
emit test <- "B";
What is the expected output? What do you see instead?
There is nothing output.
What version of the product are you using? On what operating system?
version 1.0.
Please provide any additional information below.
I saw this code of src/emitter/szlset.cc:
55 virtual int AddElem(const string& elem) {
56 tot_elems_++;
57 // Do not add if we are already full.
58 if (set_.size() > maxElems_) // Is this correct? Maybe '>='?
59 return 0;
60 if (set_.insert(elem).second)
61 return kNodeSize + elem.size();
62 return 0;
63 }
Original issue reported on code.google.com by [email protected]
on 25 Jan 2013 at 7:45
ProcessCommandLineArguments (in utilities/commandlineflags.cc) recognizes
"--no<flagname>" by comparing the known flagname with p[2..len+2], but it then
incorrectly goes on to compare "p[len] == '='" in the rest of the function as a
way of distinguishing "--flag=value" from "--flag value".
This goes wrong when the flag is boolean, "no" is present, and the "=value" is
also present. The handling of "false" and "true" for bool flags is intended to
be inverted when "no" is present. Unfortunately, the presence of "no" causes
the code to fail to find the '=', and so it proceeds as if the "=value" was
absent. When the value is "true" this works out, but not when it's "false".
The patch adds 2 to len when the flag was recognized as "no" + a bool flag (and
not, say, a bool flag happening to begin with no, such as "--notify").
Original issue reported on code.google.com by aecolley
on 13 Nov 2010 at 2:04
Attachments:
OpcodeFor in ir.cc scans a static array (opcodetab) looking for a sentinel that
isn't there. The upshot is memory corruption in --nonative mode.
I have no specific test for this, but the memory corruption problems suddenly
went away when I noticed and fixed this bug.
The patched code respects a proper array bound on the loop control variable.
Original issue reported on code.google.com by aecolley
on 13 Oct 2013 at 9:09
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.