Is there anyone that can think of a solution for this problem?
cc1: warnings being treated as errors
/Volumes/Scratch/monetdb/stable/monetdb/src/modules/plain/bat.mx: In function 'local_itoa':
/Volumes/Scratch/monetdb/stable/monetdb/src/modules/plain/bat.mx:1253: warning: format '%zd' expects type 'signed size_t', but argument 4 has type 'ssize_t'
I mean... is there a difference between "signed size_t" and "ssize_t"?
Ehrm.
[Orion:src/modules/plain] fabian% uname -a
Darwin Orion.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc PowerBook4,3 Darwin
[Orion:src/modules/plain] fabian% gcc --version
gcc (GCC) 4.0.1 (Apple Computer, Inc. build 5341)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Probably just need to compile without -Werror.
HowToStart-SQL-Win32.txt says
In case the install (i.e., prefix) directories of MonetDB and
MonetDB/SQL are identical, ...
However, it seems that prefix is fixed in NT/Makefile
prefix = $(MAKEDIR)
Would it be possible to control the prefix via an environment
variable?
Also, it seems that
CLIENTS_PREFIX
MONETDB4_PREFIX
MONETDB5_PREFIX
are required, but HowToStart-SQL-Win32.txt only mentions MONETDB_PREFIX.
And a related question: Is it possible to use a build directory outside of
the source tree (under Win32)?
Steffen Goeldner
HowToStart-*-Win32.txt lists bison from UnxUtils as prerequisite.
This version (1.28) seems too old:
monet_parse.tab.c
monet_parse.y(85) : error C2046: illegal case
monet_parse.y(86) : error C2043: illegal break
...
Version 2.1 from cygwin works.
Steffen Goeldner
I have been struggling with this problem for a couple of weeks. We
are using Monet 4.6.2 (I know, I know!) to power a web service
written in Java. When Monet is running on OS X, I can handle 200+
requests per second, but when I install it on a (much faster) Linux
machine, the app only gives me 20 requests per second.
The difference happens on the TCP/IP connection. I have the simplest
test:
var a:=bat(int,int).insert(1,1);
a.print();
This takes 4ms on OS X, but 40ms on Linux. I've traced down the
system calls, and what happens is that when the server is running on
OS X my client reads back the results in one or two calls to recv,
whereas when the server is on Linux the client only gets a couple of
bytes back from the server and then blocks until the rest arrives.
The following is a section of strace's output on the Java application:
$ strace -f -ttt java -cp test.java test
Monet running on OS X:
----------------------
send(5, "a.print();\n", 12, 0) = 12
recv(5, "#------------\n# h ....", 8192, 0) = 50
ioctl(5, FIONREAD, [45]) =
recv(5, " # type ....", 8192, 0) = 45
Monet running on Linux:
-----------------------
send(5, "a.print();\n", 12, 0) = 12
recv(5, "#-", 8192, 0)
ioctl(5, FIONREAD, [0]) =
recv(5, <unfinished...> ==> blocks
[... 40ms...]
<recv resumed "----------#\n# h ...", 8192, 0) = 93
The sockets are opened in the same way in both cases, just like the
MapiClient opens them:
connect(5, {sa_family=AF_INET, sin_port=htons(45678),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
setsockopt(5, SOL_SOCKET, SO_KEEPALIVE, [0], 4) = 0
setsockopt(5, SOL_IP, IP_TOS, [8], 4) = 0
setsockopt(5, SOL_TCP, TCP_NODELAY, [1], 4) = 0
This problem does not happen when I use Monet's MapiClient: the
response times on OS X and Linux are similar.
While inspecting the calls between the server and the MapiClient,
then, I realized that the handshake is different from the one used by
the Mapi.java class that comes with 4.6.2: the C client sets the
'blocked' flag on.
Turning the 'blocked' flag to true in the MapiClient.java class
doesn't work. Switching the C client's default mode to be non-blocked
(in src/mapi/clients/C/Mapi.mx) does indeed make the connection much
slower, as every single character is sent to the client in its own
packet (due to TCP_NODELAY?):
write(3, "print(a);\n", 10) = 10
read(3, "#", 1) = 1
read(3, "-", 1) = 1
read(3, "-", 1) = 1
...
read(3, "]", 1) = 1
read(3, "\n", 1) = 1
My question is then: is it possible to write a Java client that
communicates with the server using the blocked protocol? Do you think
that would solve my performance issues? If so, is there any
documentation/example code I can follow (since the actual protocol
seems to be different in both cases). I've looked at the latest CVS
checkins for the the Mapi protocol, and I see that the only option
now is the 'blocked' mode, so I guess it's possible to use it from
Java....
FYI, I am using
- Monet 4.6.2
- Java 5
- OS X 10.4.9
- Linux 2.6.9, 2.6.15, 2.6.17
Thank you very much,
-- Agustin
Hi Peter,
your checkin message does not match your checkin: your change only
ensures that the following four characters are not escaped anymore:
'\"', '\'', '\t', and '\\'.
Entities however were already escaped in the previous version.
Cheers,
Jan
On 03/16/2007 02:08 AM, Peter Boncz wrote with possible deletions:
> Update of /cvsroot/monetdb/pathfinder/runtime
> In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv18198
>
> Modified Files:
> serialize_dflt.mx
> Log Message:
> - XRPC strings should also escape entities
>
>
>
> Index: serialize_dflt.mx
> ===================================================================
> RCS file: /cvsroot/monetdb/pathfinder/runtime/serialize_dflt.mx,v
> retrieving revision 1.31
> retrieving revision 1.32
> diff -u -d -r1.31 -r1.32
> --- serialize_dflt.mx 15 Mar 2007 21:07:17 -0000 1.31
> +++ serialize_dflt.mx 16 Mar 2007 01:08:16 -0000 1.32
> @@ -1228,7 +1228,7 @@
> dflt_seqEmitBool,
> dflt_seqEmitInt,
> dflt_seqEmitDbl,
> - dflt_seqEmitStr,
> + dflt_handle_characters,
> dflt_handle_attribute,
> dflt_handle_characters,
>
> @@ -1264,7 +1264,7 @@
> dflt_seqEmitBool,
> dflt_seqEmitInt,
> dflt_seqEmitDbl,
> - dflt_seqEmitStr,
> + dflt_handle_characters,
> dflt_handle_attribute,
> dflt_handle_characters,
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Monetdb-pf-checkins mailing list
> Monetdb-pf-checkins(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins
>
--
Jan Rittinger
Database Systems
Technische Universität München (Germany)
http://www-db.in.tum.de/~rittinge/
Martin,
Please be more specific.
Peter
Message: 7
Date: Sat, 03 Mar 2007 07:53:28 +0100
From: Martin Kersten <Martin.Kersten(a)cwi.nl>
Subject: [Monetdb-developers] MonetDB/src/gdk gdk_posix.mx brook
testing
To: monetdb-developers(a)lists.sourceforge.net
Cc: Niels Nes <Niels.Nes(a)cwi.nl>, Fabian <Fabian.Groffen(a)cwi.nl>,
Sjoerd Mullender <Sjoerd.Mullender(a)cwi.nl>, Stefan Manegold
<Stefan.Manegold(a)cwi.nl>
Message-ID: <45E91B68.1080408(a)cwi.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Peter,
Good to see that you got old functionality in the
heart of the system working on Windows.
Its a pity that it completely broke tests on all
other platforms due to our strict compilation scheme :-(
A simple Mtest could have avoided it.
regards, Martin
On Fri, Mar 09, 2007 at 01:27:44PM +0000, Peter Boncz wrote:
> Update of /cvsroot/monetdb/pathfinder/compiler
> In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv5468/compiler
>
> Modified Files:
> Tag: XQuery_0-16
> compile.c
> Log Message:
> FIX #1677094: compiler warning an weird 'sigmod' code in mps
>
> (plus, some minor xprc stuff)
>
>
>
> Index: compile.c
> ===================================================================
> RCS file: /cvsroot/monetdb/pathfinder/compiler/compile.c,v
> retrieving revision 1.96.2.4
> retrieving revision 1.96.2.5
> diff -u -d -r1.96.2.4 -r1.96.2.5
> --- compile.c 17 Feb 2007 01:10:37 -0000 1.96.2.4
> +++ compile.c 9 Mar 2007 13:27:42 -0000 1.96.2.5
> @@ -196,26 +196,17 @@
> xmlParserInputBufferPtr buf;
> char *ret, url[1024];
>
> - /* support for the xrpc://x.y.z/URI naming scheme (maps to http://x.y.z:<xrpc_port>[/xrpc]/URI) */
> + /* support for the xrpc://x.y.z/URI naming scheme (maps to http://x.y.z:<xrpc_port>/URI) */
Hi Peter,
I don't understand this change. With "/xrpc" the request will be
directed to our own file request handler which retrieves 'URI' from MXQ,
instead of from disk. What is your intention here?
Jennie
> if (strncmp(uri, "xrpc://", 7) == 0) {
> - char *xrpc = "";
> char *p = strchr(uri+7, '/');
> char *q = strchr(uri+7, ':');
> int port = xrpc_port;
> - if (p) {
> - char *suffix = p + strlen(p) - 4;
> - if (suffix > p && !(strcmp(suffix,".xml") && strcmp(suffix,".XML"))) {
> - /* GET requests on XML get magically mapped on fn:doc(). Add xrpc/ to URI. */
> - xrpc = "/xrpc";
> - } /* else: request is simply redirected to xrpc HTTP server (file serving) */
> - *p = 0;
> - }
> - if (q) {
> + if (q && (p == NULL || p > q)) {
> /* if a specific port is omitted, we use the current xrpcd port number */
> port = atoi(q+1);
> *q = 0;
> }
> - snprintf(url, 1024, "http://%s:%d%s/%s", uri+7, port, xrpc, p?(p+1):"");
> + snprintf(url, 1024, "http://%s:%d/%s", uri+7, port, p?(p+1):"");
> if (p) *p = '/';
> if (q) *q = ':';
> } else {
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Monetdb-pf-checkins mailing list
> Monetdb-pf-checkins(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins