Recent Posts

[not]

I think there is some confusion surrounding the Inq transaction model and (separately) what an eligibility expression is for.

First the transaction issue. Inq does not behave in the same way as (at least some) database servers do.
After you have called create() the instance you have submitted for creation will not be returned by subsequent read() calls until the transaction has successfully committed, so your first scenario is correct. Step 3 in the second scenario is incorrect - the instance you created will not be in the set. Inq only returns managed instances - that is ones that have been previously committed.

Secondly the eligibility expression. The purpose of an eligibility expression is to maintain cached key values and the instance(s) they map to when the underlying SQL contains an inequality. It is not (as you perhaps have misunderstood) intended to help Inq return instances awaiting formal creation when read() is called.

You might ask why doesn't Inq return to-be-created instances in a read() ? Well, once an instance has been submitted for creation Inq does not allow it to be changed. This is because Inq locks the unique key value(s) the instance represents to protect the transaction's integrity. More on transaction state can be found here: http://www.inqwell.com/primer/txn.html#manip

Hi !

I appreciate that I can:
1. Open a txn
2. Create an object
3. Commit the txn - object gets written to database.
4. Do a non-unique read such that the created object is expected to be part of the set. I assume Inq will call the database via a select-stmt.

Then the set will contain the object created in step2.

However, if I now do the:
1. Open a txn
2. Create an object
3. Do a non-unique read such that the created object is expected to be part of the set
4. Commit the txn

How will my set of read objects contain the created object from step2?

Should I use a eligible-clause in my i/o key defn ???

Ok, sorry, I started my tests too quickly ;) With the details in http://www.inqwell.com/examples/helloworld/runhello.html it is working under OS X. It was only necessary for me to precise an absolute path for the url parameter. But I think that this is due to the fact that I used a symbolic link to go into my inq directory.

Thank you for your help.

Fabrice

Phew. No worries! :-) I am really pleased the Inq HelloWorld worked for you as we were scratching our heads thinking we'd need to obtain OS X from somewhere!!
Just out of interest did you try the chat example ? (The instructions are almost exactly the same).

Bharat.

Ok, sorry, I started my tests too quickly ;) With the details in http://www.inqwell.com/examples/helloworld/runhello.html it is working under OS X. It was only necessary for me to precise an absolute path for the url parameter. But I think that this is due to the fact that I used a symbolic link to go into my inq directory.

Thank you for your help.

Fabrice

Fabrice: Thanks for trying out Inq.  Like Tom says we've not tried under OSX recently.

I just want to make sure you're following the instructions for the hello world app which are in: http://www.inqwell.com/examples/helloworld/runhello.html

I've installed inq1_0_2.jar into my home area /home/inqwell :-

1. Set up INQHOME:
export INQHOME=/home/inqwell/inq1_0_2

2. Set up the PATH so that the inq launcher script is found :
export PATH=$INQHOME/bin:$PATH

3. Change you directory to the INQHOME
cd $INQHOME

3. Run the inq server in background. Otherwise run the inq server in another window (remembering to do steps 1, 2 and 3 above):
inq -server &

You will see some output like:-
Inq Server
Copyright (c) InqWell Ltd 2002-2008
Java Compiler Compiler Version 3.2 Copyright (c) 2003 Sun Microsystems, Inc. All  Rights Reserved.
DeadlockScanner Started
Server Started
speakinq Socket Listener Started on port 6556

4.  Load the HelloSrv code into the inq server. Please note the "-url" is relative - this is why you must change directory in step 3 before starting the server:
inq -load -u admin -p inqwell -serverHost speakinq://localhost -package system.server -url file:examples/helloworld/helloSrv.inq

You will see some output from the inq server like:
speakinq Socket Listener accepted on socket Socket[addr=/127.0.0.1,port=38236,localport=6556]
Socket closed

5. Now start the GUI client. On my unbuntu box I get some GTK l&f exceptions so I start with the default java L&F:
inq -client -lookandfeel none

You will see some output like:
Inq Client
Copyright (c) InqWell Ltd 2002-2008
Java Compiler Compiler Version 3.2 Copyright (c) 2003 Sun Microsystems, Inc. All  Rights Reserved.
JDateChooser Copyright (c) Kai Toedter 1999 - 2006
AnyClient: Connecting by socket to speakinq://localhost
speakinq Socket Listener accepted on socket Socket[addr=/127.0.0.1,port=38244,localport=6556]


Does any of that help?

In the meantime, we'll have to retry Inq on OS X and get back to you...

nrg-b.

Something I forgot to mention - you need to use the -load option to load helloSrv.inq into the server before you try to login with inq -client

Regards,

Ok, after reading the "Execution modes" page of the documentation, I understand now that with the -server and -client options, this doesn't launch the Hello World application. I modified the launch script to print the command executed. If i'm typing "inq helloSrv.inq" I get:
"java -Dsun.java2d.nodddraw=true -Dinq.home=/Users/fjossinet/inq1_0_2 com.inqwell.any.parser.Inq helloSrv.inq"

If i'm typing "inq helloClient.inq", I get:
"java -Dsun.java2d.nodddraw=true -Dinq.home=/Users/fjossinet/inq1_0_2 com.inqwell.any.parser.Inq helloClient.inq"

So I think that the command line generated by the script is ok. But, in both cases, nothing happened. BTW, my version of java is 1.5.0_13.

In both these cases, as you can see from your modified script, the shell script is launching the com.inqwell.any.parser.Inq class. This is the so-called "interactive" mode. You are using Inq like perl, say, just as a plain scripting language and not client server.

If I'm doing "inq -in helloSrv.inq", the application exit with this message:
Inq done

The Inq (parser) has just parsed the file in the local environment, not loaded it into any long-running server. Since it doesn't produce any output that's all you get. You have defined the functions and typedef but then your parser terminates.

If I'm doing "inq -in helloClient.inq", I got a stacktrace for these exceptions:
Inq done
Operand $root.ochannel could not be resolved
com.inqwell.any.AnyRuntimeException: Operand $root.ochannel could not be resolved

Again, by launching the parser (as opposed to the client startup) you have no connection to the server and therefore no channel connecting you to anything. The helloClient.inq script tries to to the send initHello(); statement at line 41 and fails.

Then i decided to test the C2F example by typing "inq -in C2F.inq". Then I got a stacktrace for these exceptions:
java.net.UnknownHostException: Users

and

i18n is en
com.inqwell.any.AnyRuntimeException: Operand $catalog.{$root.i18n}.title could not be resolved

May be this is a better place to start - especially as we are OSX-lite...

I think the UnknownHostException is coming from inq's attempt to process the #include line. Perhaps you can provide the full stack trace. It carries on anyway but the files en.inq and fr.inq define the language strings including title, which it then falls over on...incidentally, if you add "-i18n fr" you get the French strings.

As a brutal fix, comment out the #include line and paste the lines from fr.inq in its place.

Inq forms a URL based on whatever was resolved for C2F.inq. This will be a file: URL and it seems to be getting confused about the "host" and path components. You could try something like
inq -in file:/Users/fjossinet/..../examples/C2F.inq (or whatever works) to help it along. This is a platform issue, I think, so I need to check it out on OSX.

But I just want to precise that several examples are working quite well, like:

inq -in doc1.inq
inq -in sum.inq
inq -in datechooser.inq

Fabrice

Ok, after reading the "Execution modes" page of the documentation, I understand now that with the -server and -client options, this doesn't launch the Hello World application. I modified the launch script to print the command executed. If i'm typing "inq helloSrv.inq" I get:
"java -Dsun.java2d.nodddraw=true -Dinq.home=/Users/fjossinet/inq1_0_2 com.inqwell.any.parser.Inq helloSrv.inq"

If i'm typing "inq helloClient.inq", I get:
"java -Dsun.java2d.nodddraw=true -Dinq.home=/Users/fjossinet/inq1_0_2 com.inqwell.any.parser.Inq helloClient.inq"

So I think that the command line generated by the script is ok. But, in both cases, nothing happened. BTW, my version of java is 1.5.0_13.

If I'm doing "inq -in helloSrv.inq", the application exit with this message:
Inq done

If I'm doing "inq -in helloClient.inq", I got a stacktrace for these exceptions:
Inq done
Operand $root.ochannel could not be resolved
com.inqwell.any.AnyRuntimeException: Operand $root.ochannel could not be resolved

Then i decided to test the C2F example by typing "inq -in C2F.inq". Then I got a stacktrace for these exceptions:
java.net.UnknownHostException: Users

and

i18n is en
com.inqwell.any.AnyRuntimeException: Operand $catalog.{$root.i18n}.title could not be resolved

Thanx for your help,

Fabrice

Hi Fabrice

Thanks for trying Inq.

I have to say that at this time we haven't run Inq on OSX since launch, though we did try it to see what it looked like a few months prior...

Anyway, yes, readlink - I was a bit suspicious about that one. Of course, it's better to require INQHOME to be in the environment and not be too clever trying to set it. We'll fix that.

I think from what you say about launching the client and server that there is something else OSX doesn't like about the inq launch script. The arguments you add (helloClient/helloSrv) don't do anything but may be OSX doesn't like the shift statement? That's all I can think of.

Regards