Fabian, thank you. I seem to remember that I didn't use --enable-optimise as it was advertised to take longer than the normal build. However, I have found one solution to my problem; if I type the left hand side, everything works: mal>b:bat[:int,:int] := bbp.bind("test"); mal>io.print(b); #-----------------# # h t # name # int int # type #-----------------# I will recompile without --enable-optimise. Thanks Kambiz ----- Original Message ----- From: "Fabian Groffen" To: monetdb-developers@lists.sourceforge.net Sent: Donnerstag, 11. Oktober 2007 17.45 Uhr (GMT+0100) Europe/Berlin Subject: Re: [Monetdb-developers] Simple bat operations On 11-10-2007 17:09:22 +0200, darabi@web.de wrote:

I have downloaded and compiled MonetDB-Mars-SuperBall-SR3.tar.bz2 on an Ubuntu i686 single cpu system running a 2.6.20 kernel.

...

user@host$ mserver5 --version MonetDB Server v5.0.0 Copyright (c) 1993-2007 CWI, all rights reserved Compiled by: sjoerd@localhost.localdomain Compilation: gcc -O2 -std=c99 -O6 -fomit-frame-pointer -finline-functions -falign-loops=4 -falign-jumps=4 -falign-functions=4 -fexpensive-optimizations -funroll-loops -frerun-cse-after-loop -frerun-loop-opt Linking: ld -IPA -m elf_x86_64

i686 != x86_64 However it appears you have -fomg-superfast + -O6 in your CFLAGS (probably injected) which may simply freak out on your system. You get those if you use --enable-optimise with the monetdb-install.sh script. You could try without to get a bit more reasonable CFLAGS and maybe a better working MonetDB. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers

Fabian Groffen wrote:

On 11-10-2007 17:45:46 +0200, darabi@web.de wrote:

...

Fabian,

thank you. I seem to remember that I didn't use --enable-optimise as it was advertised to take longer than the normal build.

However, I have found one solution to my problem; if I type the left hand side, everything works:

mal>b:bat[:int,:int] := bbp.bind("test");

yes that is necessary. In general the type of the bind can not be known. and MAL requires strongly typed instructions.

--enable-optimize does not play a role in this process.

...

mal>io.print(b); #-----------------# # h t # name # int int # type #-----------------#

I will recompile without --enable-optimise.

Try --enable-debug to make sure you aren't bitten by an insane default of --enable-optimise=yes.

------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers

b) or there must be a way of storing the type information in other BATs

Did I already apologise for my dumb questions? :-) I found bbp.getNames, getHeadType, getTailType and I think I see how I could extract the necessary information with them. However, the question remains as how to create a bat with specific head and tail types which are given as String type names (result of getHeadType and getTailType). In bat5.mal the following functions which would have solved this problem are commented out: #command bat(ht:int, tt:int) :bat[:any_1,:any_2] #address BKCnewBat #comment "Creates a new empty transient BAT with head- and tail-types # as indicated."; # #command bat(ht:int, tt:int, size:int) :bat[:any_1,:any_2] #address BKCnewBATint #comment "Creates a new empty BAT, allocating 'size' elements."; # #command bat(ht:int, tt:int, size:lng) :bat[:any_1,:any_2] #address BKCnewBATlng #comment "Creates a new empty BAT, allocating 'size' elements."; I think I'll try to understand the output of some simple 'explain SELECT' statements. Good night Kambiz

Stefan Manegold wrote:

On Thu, Oct 11, 2007 at 06:02:12PM +0200, Martin Kersten wrote:

...

...

On 11-10-2007 17:45:46 +0200, darabi@web.de wrote:

[...]

...

...

...

However, I have found one solution to my problem; if I type the left hand side, everything works:

mal>b:bat[:int,:int] := bbp.bind("test");

yes that is necessary. In general the type of the bind can not be known. and MAL requires strongly typed instructions.

======== user@host$ mclient -d demo -l mal mal>b:= bbp.bind("test"); mal>io.print(b); MAPI = monetdb@127.0.0.1:50001 QUERY = io.print(b); ERROR = !TypeException:user.main[1]:'b' may not be used before being initialized ========

Well, first of all, you have to be aware of the fact that you are working at the top level scope. This means that every statement is first packaged in a function main() and then executed. At the end of this call a decision should be made on what variables to retain. This is executed in MSresetvariables(). All temporary variables are removed immediately and also any variable for which we don't know its complete type. The latter is necessary to avoid errors to block re-use of the variable name in interactive mode. So in this example, where the underlying BAT exists, the instruction bbp.bind("test") succeeds, but leaves a partially typed object behind. This one is garbage collected, which means that io.print(b) references a variable that doesn't exist anymore. If you would have packaged both instructions in a function, it would work as expected, because io.print can handle any BAT thanks for being a 'pattern' function user.main():void; # 0 (main:void) b := bbp.bind("test"); # 1 CMDbbpbind (b:bat[:any,:any])<-(_2:str) io.print(b); # 2 IOprint_val (_3:void)<-(b:bat[:any,:any]) end main; These issues are discussed in the typing section of the MAL manual. http://monetdb.cwi.nl/projects/monetdb/MonetDB/Documentation/Type-Resolution...

A more informative error mesage might help --- from a user's point of view, variable 'b' has been initialized before it is used.

Not completely

In fact, the above b:bat[:int,:int] := bbp.bind("test"); is wrong --- or at least implies a silent cast from :oid to :int of the BAT's head --- since bind returns a bat[:oid,:any_1], i.e., only the tail type is "unknown" or "generic".

Here you have a point. The current impl of bbp.bind assumes correct specification/behavior. It should also check at runtime if the BAT is of the type expected.

Moreover, what's the actual problem with the io.print, here?

With the bbp.bind(), b get's bound to type :bat[:oid,:any], and pattern io.print(val:bat[:any_1,:any_2]):void is supposed to accept generic BATs with arbitrary head & tail types, right?

"Strict" typing should (IMHO) either (1) warn already with the bbp.bind call, respectively its assignment to b, that b's tail is not fully

As pointed out in the manual. The question is to what extend you want to support polymorphic behavior. In the example above live is 'easy' because the bat name is a constant.

specified, and hence should be specified explicitly, or (2) the error with io.print() should give some typing releated error message instead of complaining about a non-initialized variable that (froma user's point of view) has been initialized.

Just my humble suggestions ...

Stefan

...

--enable-optimize does not play a role in this process.

...

...

mal>io.print(b); #-----------------# # h t # name # int int # type #-----------------#

I will recompile without --enable-optimise.

Try --enable-debug to make sure you aren't bitten by an insane default of --enable-optimise=yes.

------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers

------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers

Sorry, I had sent out this mail, before I received Martin's mail with the clarifying information:

If you would have packaged both instructions in a function, it would work as expected, because io.print can handle any BAT thanks for being a 'pattern'

Thank you Kambiz ----- Original Message ----- From: darabi@web.de To: monetdb-developers@lists.sourceforge.net Cc: "Martin Kersten" Sent: Freitag, 12. Oktober 2007 17.05 Uhr (GMT+0100) Europe/Berlin Subject: Re: [Monetdb-developers] Simple bat operations

A more informative error mesage might help --- from a user's point of view, variable 'b' has been initialized before it is used.

I would second that.

In fact, the above b:bat[:int,:int] := bbp.bind("test"); is wrong --- or at least implies a silent cast from :oid to :int of the BAT's head --- since bind returns a bat[:oid,:any_1], i.e., only the tail type is "unknown" or "generic".

The type system seems to think that b is b:any and not b:bat[:any_1,:any_2]. When I do this: mal>n := bat.new(:void,:str); mal>bat.setName(n, "person_name"); mal>bat.setPersistent(n, true); mal>transaction.commit(); mal>\q then come back to bind person_name like this: mal>pn := bbp.bind("person_name"); mal>i := bat.info(pn); MAPI = monetdb@localhost:50000 QUERY = i := bat.info(pn); ERROR = !TypeException:user.main[1]:'bat.info' undefined in: i:any := bat.info(pn:any) !TypeException:user.main[1]:'pn' may not be used before being initialized the first error message sounds like the 'function dispatch mechanism' (whatever that might be) was searching for a function bat.info(pn:any) and didn't find it. Looking into the code, I see something which could possibly match in function typeChecker (MonetDB5-server/MonetDB5/src/mal/mal_resolve.mx line 644). So, bbp.bind(:str) didn't assign a bat to pn? Is there a way in mal to output the type of a variable? Thanks Kambiz ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers

On 12-10-2007 15:17:39 +0200, Stefan Manegold wrote:

...

...

I will recompile without --enable-optimise.

Try --enable-debug to make sure you aren't bitten by an insane default of --enable-optimise=yes.

Just for the sake of correctness of information:

--enable-debug does not disable --enable-optimize. In fact, the two do conflict. To disable the --enable-optimize (indeed default in offically released versions), use (following configure standards) --disable-optimize or --enable-optimize=no.

The monetdb-install.sh script makes sure --enable-optimize is set to "no" if --enable-debug is requested. It worries me that --enable-optimize is "default in offically released versions". It shouldn't.

On 12-10-2007 15:22:37 +0200, Niels Nes wrote:

On Fri, Oct 12, 2007 at 03:23:09PM +0200, Fabian Groffen wrote:

...

On 12-10-2007 15:17:39 +0200, Stefan Manegold wrote:

...

...

...

I will recompile without --enable-optimise.

Try --enable-debug to make sure you aren't bitten by an insane default of --enable-optimise=yes.

Just for the sake of correctness of information:

--enable-debug does not disable --enable-optimize. In fact, the two do conflict. To disable the --enable-optimize (indeed default in offically released versions), use (following configure standards) --disable-optimize or --enable-optimize=no.

The monetdb-install.sh script makes sure --enable-optimize is set to "no" if --enable-debug is requested.

It worries me that --enable-optimize is "default in offically released versions". It shouldn't.

why does it worry you and why do you think default should be debug ?

default should be optimize = no debug = no resulting in sane and default CFLAGS (autoconf uses -O2 -g IIRC). I've seen way too many bug reports (in a real world) where software caused random itches and glitches because of some pumped up CFLAGS.

Haha! that was a good joke:

...

user@host$ mserver5 --version MonetDB Server v5.0.0 Copyright (c) 1993-2007 CWI, all rights reserved Compiled by: sjoerd@localhost.localdomain Compilation: gcc -O2 -std=c99 -O6 -fomit-frame-pointer -finline-functions -falign-loops=4 -falign-jumps=4 -falign-functions=4 -fexpensive-optimizations -funroll-loops -frerun-cse-after-loop -frerun-loop-opt Linking: ld -IPA -m elf_x86_64

i686 != x86_64

After recompiling with --enable-debug, I get exactly the same version message. Then, I became suspicious because of the 'sjoerd' user and looked into mserver5.c: void monet_version() { printf("MonetDB Server v%s\n", VERSION); printf("Copyright (c) 1993-2007 CWI, all rights reserved\n"); printf("Compiled by: %s\n", "sjoerd@localhost.localdomain"); printf("Compilation: %s\n", "gcc -O2 -std=c99 -O6 -fomit-frame-pointer -finline-functions -falign-loops=4 -falign-jumps=4 -falign-functions=4 -fexp ensive-optimizations -funroll-loops -frerun-cse-after-loop -frerun-loop-opt "); printf("Linking: %s\n", "ld -IPA -m elf_x86_64 "); exit(0); } Duh! It's hard-coded! But, never mind. I think I needed --enable-debug anyway. ;-)

On Thu, Oct 11, 2007 at 07:46:02PM +0200, Fabian Groffen wrote:

On 11-10-2007 19:28:28 +0200, darabi@web.de wrote:

...

Haha!

that was a good joke:

...

...

user@host$ mserver5 --version MonetDB Server v5.0.0 Copyright (c) 1993-2007 CWI, all rights reserved Compiled by: sjoerd@localhost.localdomain Compilation: gcc -O2 -std=c99 -O6 -fomit-frame-pointer -finline-functions -falign-loops=4 -falign-jumps=4 -falign-functions=4 -fexpensive-optimizations -funroll-loops -frerun-cse-after-loop -frerun-loop-opt Linking: ld -IPA -m elf_x86_64

i686 != x86_64

After recompiling with --enable-debug, I get exactly the same version message. Then, I became suspicious because of the 'sjoerd' user and looked into mserver5.c:

void monet_version() { printf("MonetDB Server v%s\n", VERSION); printf("Copyright (c) 1993-2007 CWI, all rights reserved\n"); printf("Compiled by: %s\n", "sjoerd@localhost.localdomain"); printf("Compilation: %s\n", "gcc -O2 -std=c99 -O6 -fomit-frame-pointer -finline-functions -falign-loops=4 -falign-jumps=4 -falign-functions=4 -fexp ensive-optimizations -funroll-loops -frerun-cse-after-loop -frerun-loop-opt "); printf("Linking: %s\n", "ld -IPA -m elf_x86_64 "); exit(0); }

Duh! It's hard-coded!

But, never mind. I think I needed --enable-debug anyway.

RIGHT!!!!!!

WTF! That is completely b0rkened!

Obviously, having .mx.in files in the CVS sources does not make much sense, at least not in combination with source distributions (tarballs). ... Not that "obvious" --- well, maybe a short recap of the build process helps: 1) @...@ placeholdes in .in files are replace by configure. 2) .mx files are extracted/expanded by Mx when compiling from CVS sources. 3) tarballs are supposed to be compiled w/o Mx, hence, they contain the Mx-extracted/-expanded files ("obviously" including the "hard-wired" @...@ replacements as done by the configure of that preceeded the building of the source tarball). Stefan ps: MonetDB5/src/tools/mserver5.mx.in is the only .mx.in file in our code base. pps: non-.mx .in files do correctly end-up in the source tarballs and hence have their @...@ placeholders correctly replaced by the configure when compiling from the source tarball. -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

On 12-10-2007 15:16:46 +0200, Fabian Groffen wrote:

On 12-10-2007 15:11:34 +0200, Stefan Manegold wrote:

...

Obviously, having .mx.in files in the CVS sources does not make much sense, at least not in combination with source distributions (tarballs).

...

Not that "obvious" --- well, maybe a short recap of the build process helps:

1) @...@ placeholdes in .in files are replace by configure. 2) .mx files are extracted/expanded by Mx when compiling from CVS sources. 3) tarballs are supposed to be compiled w/o Mx, hence, they contain the Mx-extracted/-expanded files ("obviously" including the "hard-wired" @...@ replacements as done by the configure of that preceeded the building of the source tarball).

I recall that .in.mx didn't work out well for some reason. I'll try that out if/once I have time for it.

Ohw, I think it is/was because there is no way to do replacement at that time, because the file is only extracted after configure is run.