Re: [Monetdb-developers] Simple bat operations
Hello Nils,
OK, then something doesn't work.
When I try your suggestion, I get this:
user@host$ mclient -d demo -l mal mal>b := bat.new(:int,:int); mal>io.print(b); #-----------------# # h t # name # int int # type #-----------------# mal>bat.setName(b,"test"); mal>bat.setPersistent(b,true); mal>transaction.commit(); mal>\q
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 mal>\q
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$ ps auxwww | grep mserver user 12072 0.0 4.3 133232 67268 ? Ssl Oct10 0:01 /opt/monetdb/bin/mserver5 --dbfarm=/opt/monetdb/var/MonetDB5/dbfarm --set daemon yes --set monet_welcome no --dbname=voc --config=/opt/monetdb/var/MonetDB5/dbfarm/voc/.monetdb.conf /opt/monetdb/var/MonetDB5/dbfarm/voc/.mserver5.dbinit user 12479 0.0 3.9 109320 61760 ? Ssl Oct10 0:00 /opt/monetdb/bin/mserver5 --dbfarm=/opt/monetdb/var/MonetDB5/dbfarm --set daemon yes --set monet_welcome no --dbname=demo --config=/opt/monetdb/var/MonetDB5/dbfarm/demo/.monetdb.conf
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
I already tried 'mclient -l sql' without any apparent problems, so it appeared unlikely that there were bigger issues.
I will try to run the test suite(s).
Thank you very much
Kambiz
----- Original Message ----- From: "Niels Nes" Niels.Nes@cwi.nl To: darabi@web.de Sent: Donnerstag, 11. Oktober 2007 16.24 Uhr (GMT+0100) Europe/Berlin Subject: Re: [Monetdb-developers] Simple bat operations
On Thu, Oct 11, 2007 at 02:34:15PM +0200, darabi@web.de wrote:
In the meantime, I have also tried all the bbp functions which I could think of:
bbp.find bbp.bind bbp.take
But none of them gives me a bat which I can use. Strangely, none of them says anything about whether the function call succeeded or not.
okay here a small example then
b := bat.new(:int,:int); io.print(b); bat.setName(b,"test"); bat.setPersistent(b,true); transaction.commit();
# after server restart the following should work. b:= bbp.bind("test"); io.print(b);
Niels
Kambiz
----- Original Message ----- From: darabi@web.de To: monetdb-developers@lists.sourceforge.net Cc: "Niels Nes" Niels.Nes@cwi.nl Sent: Donnerstag, 11. Oktober 2007 9.47 Uhr (GMT+0100) Europe/Berlin Subject: Re: [Monetdb-developers] Simple bat operations
Niels,
thank you very much for your help.
How can I access this bat, when I start a new session?
bat.load("person_name");
doesn't seem to work. io.print(n):
ERROR = !TypeException:user.main[1]:'n' may not be used before being initialized
Thanks
Kambiz
----- Original Message ----- From: "Niels Nes" To: darabi@web.de Cc: monetdb-developers@lists.sourceforge.net Sent: Donnerstag, 11. Oktober 2007 9.38 Uhr (GMT+0100) Europe/Berlin Subject: Re: [Monetdb-developers] Simple bat operations
On Thu, Oct 11, 2007 at 08:00:36AM +0200, darabi... wrote:
Hello,
sorry for asking so many dumb questions, but I don't seem to be able to find the answers in the docs.
I try to create and persist a bat:
(mclient -d demo -l mal)
n := bat.new(:oid,:str); bat.setName(n, "person_name"); bat.setPersistent(n, true);
bat.append(n, "John", true); bat.append(n, "James", true);
replace this save
bat.save(n);
by
transaction.commit();
Niels
(ps later you probably want to switch to subcommit, ie only commit those bat that changed, for this see the documenation in the transaction module (src/modules/mal/transaction.mx)
But this doesn't seem to be sufficient.
Or at least I then don't know how to load this bat the next time I start mclient.
Is there a file (one of the tests or sth.) which contains such basic tests? I tried to find-grep over them, but didn't succeed in finding what I was looking for.
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
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.
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" Fabian.Groffen@cwi.nl 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
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"); 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.
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
Hello Martin,
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.
thank you for the information, but then, a question arises as how to bootstrap the loading of BATs.
If the type information is necessary to be able to access the bat, then
a) either one has to keep the type information of the BATs outside the database,
b) or there must be a way of storing the type information in other BATs
The type system doesn't seem to know a type 'type'. Is it possible to convert e. g. the string "str" to the type :str ?
Something along these lines must be present, as it is necessary to be able to store the DB schema, isn't it?
Thank you
Kambiz
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
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 ========
A more informative error mesage might help --- from a user's point of view, variable 'b' has been initialized before it is used.
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".
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 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
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
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
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" Martin.Kersten@cwi.nl 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 Thu, Oct 11, 2007 at 05:57:31PM +0200, 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"); 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.
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.
However, as Martin already pointed out, all this is irrelevant to the actual problem discussed here.
Stefan
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 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 ?
Niels
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: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.
I found a log file which is apparently created by monetdb-install.sh:
called with arguments: --build=/opt/monetdb/src --prefix=/opt/monetdb --enable-sql --enable-xquery --enable-debug
So, is --enable-optimise the default?
----- Original Message ----- From: darabi@web.de 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
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" Fabian.Groffen@cwi.nl 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
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 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!
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.
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:
- @...@ placeholdes in .in files are replace by configure.
- .mx files are extracted/expanded by Mx when compiling from CVS sources.
- 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.
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:
- @...@ placeholdes in .in files are replace by configure.
- .mx files are extracted/expanded by Mx when compiling from CVS sources.
- 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.
participants (6)
-
darabi＠web.de -
Fabian Groffen -
Kambiz Darabi -
Martin Kersten -
Niels Nes -
Stefan Manegold