q-lang-users — general discussion, questions, suggestions, etc.

Re: [q-lang-users] Association lists

[Albert G. <Dr....@t-...>]

Jir(í Spitz wrote:
> BTW I was a bit surprised, that this works:
> 
> ==> set::inserta emptyset 1
> (set [1],true)
> 
> I wuould expect, that private functions are not accesible at all, but 
> this may be an intention.

http://q-lang.sourceforge.net/qdoc/qdoc_4.html#SEC19

"Moreover, to facilitate testing and debugging, in the interpreter it is
possible to gain access to all public and private symbols of the program
(also in modules not directly imported in the main script) using
qualified identifiers."

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] Association lists

[Albert G. <Dr....@t-...>]

Jir(í Spitz wrote:
> However I fall in problems when using my libraries together. Whether it 
> works depends on the order in which I import them

That was one of the bugs I fixed. (You forgot the type guards on the
insert/delete interface functions, so the wrong equation would be
invoked.) Get the latest versions from cvs, they should be ok (except
for the key comparison issue, I still have to fix that one).

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] Association lists

[Jiří S. <jir...@bl...>]

Albert Graef wrote:
> Ok, thanks a lot. I did some more reformatting so that the layout is
> more in line with the rest of the library, and fixed a couple of minor
> bugs and typos. I also removed the do/map stuff in dict.q (while this
> might be useful, I'd prefer the new version to be a drop-in replacement
> for the old one for now). It is in cvs now.

OK.

> There's still a minor issue with the inserta/deletea operations,
> however. The problem is that you used syntactic equality (foo X X = ...)
> rather than (=) to decide equality of two key values. That will be ok in
> most cases (hdict should be fine as the real key there is always an
> integer), but for dict/bag/set you don't know what the actual key type
> is, it may be *any* ordered type, and some key types might well use a
> version of (=) which goes beyond simple syntactic equality, see
> "Non-Linear Equations" in the manual
> [http://q-lang.sourceforge.net/qdoc/qdoc_7.html#SEC42] for an explanation.
> I'll try to fix this (shouldn't be too difficult) and give it a first
> test drive with a couple of my programs. If that works ok I'll upload a
> new release candidate later today.

I see, you are right.

However I fall in problems when using my libraries together. Whether it 
works depends on the order in which I import them

Eg. if I do

import set, dict;

then I receive this conversation:

==> insert emptydict (1,1)
fst (set::inserta (dict []) (1,1))

and even with qualified call

==> dict::insert emptydict (1,1)
fst (set::inserta (dict []) (1,1))

When I change the import order, ten it is OK:

import dict, set;

==> insert emptydict (1,1)
dict [(1,1)]

==> insert emptyset 1
set [1]

Other two libraries behave similarly. I cannot find any bad declarations 
(eg. public instead of private). This may be related to the fact, that 
my versions of inserta have different arity for dict and set while your 
corresponding functions have the same arity.


BTW I was a bit surprised, that this works:

==> set::inserta emptyset 1
(set [1],true)

I wuould expect, that private functions are not accesible at all, but 
this may be an intention.

Regards,

Jiri

Re: [q-lang-users] Association lists

[Albert G. <Dr....@t-...>]

Jiri Spitz wrote:
> It is now reformatted. I hope the code is still reasonably readable and
> that I didn't introduce any error.

Ok, thanks a lot. I did some more reformatting so that the layout is
more in line with the rest of the library, and fixed a couple of minor
bugs and typos. I also removed the do/map stuff in dict.q (while this
might be useful, I'd prefer the new version to be a drop-in replacement
for the old one for now). It is in cvs now.

There's still a minor issue with the inserta/deletea operations,
however. The problem is that you used syntactic equality (foo X X = ...)
rather than (=) to decide equality of two key values. That will be ok in
most cases (hdict should be fine as the real key there is always an
integer), but for dict/bag/set you don't know what the actual key type
is, it may be *any* ordered type, and some key types might well use a
version of (=) which goes beyond simple syntactic equality, see
"Non-Linear Equations" in the manual
[http://q-lang.sourceforge.net/qdoc/qdoc_7.html#SEC42] for an explanation.

I'll try to fix this (shouldn't be too difficult) and give it a first
test drive with a couple of my programs. If that works ok I'll upload a
new release candidate later today.

Cheers,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] Association lists

[Jiri S. <jir...@bl...>]

Albert Graef napsal(a):

> Would it be possible to reformat the sources so that they fit into 80
> columns? I'd very much appreciate that, since I frequently read these
> files as documentation, sometimes on devices with small displays.

It is now reformatted. I hope the code is still reasonably readable and 
that I didn't introduce any error.

> Also, it might be appropriate to add a link to SWI-Prolog to your
> comment at the beginning of the files.

Good idea - done.

Regards,

Jiri

Re: [q-lang-users] Association lists

[Albert G. <Dr....@t-...>]

Jiri Spitz wrote:
> You will find them all enclosed.

Thanks, that was quick. :) Great piece of work! One suggestion, though:
Would it be possible to reformat the sources so that they fit into 80
columns? I'd very much appreciate that, since I frequently read these
files as documentation, sometimes on devices with small displays.

Also, it might be appropriate to add a link to SWI-Prolog to your
comment at the beginning of the files.

> I tested them with a lot of both
> sequential and random updates and they seem to work. Of course, some
> testing in working applications would be appreciated.

I'll probably do another release candidate so that everybody can give it
a shot before the official 7.11 release. I have plenty of programs
making heavy use of these data types, so I hope that most kinds of bugs
would be shaken out pretty quickly.

Cheers,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] Association lists

[Jiri S. <jir...@bl...>]

Albert Graef napsal(a):
> that looks nice, thanks a lot. Do you have a sf.net account? Then I
> could give you wiki access so that you can upload and describe it there.

I have already created the ID and sent you an e-mail. I'll try to 
describe the algorithm there.

>Maybe we should redo bag, set and hdict, too, and replace the stdlib implementations...

You will find them all enclosed. I tested them with a lot of both 
sequential and random updates and they seem to work. Of course, some 
testing in working applications would be appreciated.


Regards,

Jiri

Re: [q-lang-users] Association lists

[Eddie R. <ed...@ri...>]

Great! I use those libraries very often. Making those libraries faster 
would definitely improve the execution of most (all?) of my programs.

Thanks Jiri!

Eddie Rucker

Albert Graef wrote:
> Hi Jiri,
> 
> that looks nice, thanks a lot. Do you have a sf.net account? Then I
> could give you wiki access so that you can upload and describe it there.
> 
> Indeed your implementation seems to be much faster than the one in the
> standard library (which was based on Bird/Wadler). Care to elaborate on
> the implementation tricks that make this happen? Maybe we should redo
> bag, set and hdict, too, and replace the stdlib implementations...
> 
> Albert
> 
> Jiri Spitz wrote:
>> I have ported and completed the association lists based on AVL trees
>> from the SWI-Prolog to Q. Enclosed you will find the dict.q rewritten to
>> use this algorithm. It is not as elegant as the current implementation
>> (it is rather tricky), but the tree updates are more than two times
>> faster for large dictionaries.
> 

Re: [q-lang-users] Association lists

[Albert G. <Dr....@t-...>]

Hi Jiri,

that looks nice, thanks a lot. Do you have a sf.net account? Then I
could give you wiki access so that you can upload and describe it there.

Indeed your implementation seems to be much faster than the one in the
standard library (which was based on Bird/Wadler). Care to elaborate on
the implementation tricks that make this happen? Maybe we should redo
bag, set and hdict, too, and replace the stdlib implementations...

Albert

Jiri Spitz wrote:
> I have ported and completed the association lists based on AVL trees
> from the SWI-Prolog to Q. Enclosed you will find the dict.q rewritten to
> use this algorithm. It is not as elegant as the current implementation
> (it is rather tricky), but the tree updates are more than two times
> faster for large dictionaries.

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

[q-lang-users] Association lists

[Jiri S. <jir...@bl...>]

Hello Q users,

I have ported and completed the association lists based on AVL trees 
from the SWI-Prolog to Q. Enclosed you will find the dict.q rewritten to 
use this algorithm. It is not as elegant as the current implementation 
(it is rather tricky), but the tree updates are more than two times 
faster for large dictionaries.

Enjoy.

Jiri

Re: [q-lang-users] ODBC connection with MS Access

[Tim H. <q...@st...>]

Albert Graef <Dr....@t-...> writes:

> Albert Graef wrote:
>> Tim Haynes wrote:
>>> Cool. The other thing you might find useful is exposing SQLGetTypeInfo() -
>>> at least so that folks can see the native type-names for use in
>>> create/alter statements.
>> 
>> Ok, I'll have a look at it.
>
> This is in cvs now (see odbc_typeinfo). I don't know how much of that
> information is actually useful or even supported on different ODBC
> implementations, but the function provides it all -- 19 different fields.
> ;-) I also added a bunch of symbolic constants (SQL_*) which should be
> useful when working with this function. (I transcribed these from the
> unixODBC headers, I hope that they are standardized so that they will
> work on all ODBC implementations.)

Excellent.

Yes, they should be reasonably standardized. You can cross-reference
against sql*.h in iODBC if really desperate.

> I also fixed up the odbc_examp.q script, it now makes use of
> SQL_IDENTIFIER_QUOTE_CHAR and thus the function which initializes the
> tables of the sample menagerie database should work with MS Access and
> other strictly ANSI-compliant RDBMSs.

Cool :)

~Tim
-- 
<http://spodzone.org.uk/>

[q-lang-users] Q-CSV 0.1 is Available

[Eddie R. <ed...@ri...>]

Hi Everyone:

A new Q-CSV module for reading and writing comma separated values is 
available here 
http://sourceforge.net/project/showfiles.php?group_id=96881&package_id=262346. 
   The module is roughly equivalent to Python's CSV module, see 
http://docs.python.org/lib/module-csv.html, except that Q-CSV accepts 
quotes and field delimiters of more than one character as a means of 
handling Unicode. Currently, Q-CSV has three built in dialects, 
"RFC4180" standard, "UNIX" (RFC4180 without '\r's), and "EXCEL" but 
provides a simple user interface for creating new dialects. 
Documentation can be found in the examples provided and the csv.q file. 
Since the reading and conversion routines are written in C, operations 
are efficient.

Enjoy!

Eddie Rucker

Re: [q-lang-users] ODBC connection with MS Access

[Albert G. <Dr....@t-...>]

Albert Graef wrote:
> Tim Haynes wrote:
>> Cool. The other thing you might find useful is exposing SQLGetTypeInfo() -
>> at least so that folks can see the native type-names for use in
>> create/alter statements.
> 
> Ok, I'll have a look at it.

This is in cvs now (see odbc_typeinfo). I don't know how much of that
information is actually useful or even supported on different ODBC
implementations, but the function provides it all -- 19 different
fields. ;-) I also added a bunch of symbolic constants (SQL_*) which
should be useful when working with this function. (I transcribed these
from the unixODBC headers, I hope that they are standardized so that
they will work on all ODBC implementations.)

I also fixed up the odbc_examp.q script, it now makes use of
SQL_IDENTIFIER_QUOTE_CHAR and thus the function which initializes the
tables of the sample menagerie database should work with MS Access and
other strictly ANSI-compliant RDBMSs.

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] stream socket

[Albert G. <Dr....@t-...>]

Humbert Francis wrote:
> My socket first try does not work  (Windows Vista) :
> [...]
> ==> accept 336
> accept 336

Works fine on Windows XP (and on Linux):

==> def SERVER = ("localhost",2000)

==> def FD = socket AF_INET SOCK_STREAM 0

==> bind FD SERVER
()

==> listen FD 5
()

// open http://localhost:2000/ in Firefox

==> accept FD
(1784,("127.0.0.1",1058))

I think I read somewhere that MS rewrote the network stack for Vista,
could there be an ABI incompatibility? In that case a recompile of the
system module should fix it. Or maybe it's some security setting that
gets in the way?

Unfortunately, I don't have Vista to test. Anyone else here running Q on
Vista, who would be willing to try this out?

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] q-lang suitability for my project

[Albert G. <Dr....@t-...>]

Dave Joubert wrote:
> Is this project a candidate for a novice (to q-lang) to re-write in q-lang ?

Difficult to say without knowing a whole lot more about your project.
Have you used a functional programming language before? I think that in
any case you'll just have to learn a little Q so that you can decide
yourself.

> Would the deployment in q-lang be any easier, ie just a language engine
> download and an application download ?

Depends on the target system. Binary packages for Q are readily
available for SUSE, Fedora and Windows, and there is an OSX port in the
MacPorts collection. (The Fedora and MacPorts packages don't include the
OSC interface, but the OSC module is just plain Q, so no compilation is
required and you could also include it with your application.)

Caveat: Q isn't available for 64 bit systems yet. (I'm going to work on
that in the next few months, though.)

HTH,
Albert Graef

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] ODBC connection with MS Access

[Albert G. <Dr....@t-...>]

Tim Haynes wrote:
> Cool. The other thing you might find useful is exposing SQLGetTypeInfo() -
> at least so that folks can see the native type-names for use in
> create/alter statements.

Ok, I'll have a look at it. Any other stuff missing in the interface
that's badly needed?

> I'm not aware of any such thing as part of the ODBC spec; quick
> consultation with one of the gurus here didn't produce any obvious links.

Doesn't surprise me, actually. On second thought it came to me that
"script tie-ins" in SQL statements can only be done on the server, not
the client side, both for efficiency and security considerations. So
ODBC has no business with that. SQLite is different, because it doesn't
have a server.

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

[q-lang-users] q-lang suitability for my project

[Dave J. <dav...@go...>]

Hi,

I have written a piece of software that acts as a gateway between OSC
packets,
and FreeWrl's External Authoring Interface. The project was written in TCL;
basically
I gave up on Java and C a long time ago.

The issue I now face is deployment. To deploy it on another machine, I need
to
download and complie the TCL-UDP library and TCLlib for checksums and UUIDs.

In total it is about 800 lines of TCL (apart from OSC liibrary I had to
write myself),
 and relies heavily of TCL features such as arrays with hashed character
keys,
freely moving between data types and the TCL event loop to handle both the
UDP (OSC)
datagrams and the TCP socket to the EAI.

Is this project a candidate for a novice (to q-lang) to re-write in q-lang ?
Would the deployment in q-lang be any easier, ie just a language engine
download and an application download ?

Dave Joubert

Re: [q-lang-users] ODBC connection with MS Access

[Tim H. <q...@st...>]

Albert Graef <Dr....@t-...> writes:

> Tim Haynes wrote:
>> SQLGetInfo(SQL_IDENTIFIER_QUOTE_CHAR) is your friend:
>
> Tim, that was very helpful, thanks a lot. I added a new odbc_getinfo
> function to the odbc module which provides a direct wrapper of
> SQLGetInfo(), so that I can now query all metadata. Fixing odbc_examp.q
> so that it works with different RDBMS should be a piece of cake now!

Cool. The other thing you might find useful is exposing SQLGetTypeInfo() -
at least so that folks can see the native type-names for use in
create/alter statements. (Does varchar need a max-size? Float or Double?
text or long varchar? As for date/time/datetime/timestamp, don't get me
started :)

> While I'm giving the odbc module a facelift... I'd also like to support
> user-defined functions written in Q (the sqlite3 interface already
> provides these and I find them pretty useful). By any chance, do you know
> whether ODBC provides an API for this kind of stuff? I'm looking for an
> ODBC function which would allow to register a C callback as a UDF to be
> called from SQL queries, which takes some SQL values as parameters and
> returns another SQL value as the result. Googling around didn't turn up
> anything useful so far.

I'm not aware of any such thing as part of the ODBC spec; quick
consultation with one of the gurus here didn't produce any obvious links. 

I would expect it to be outwith the general scope of ODBC as a portable
SQL-passing layer, because it would mandate direct intervention in the SQL
in transit as a matter of core compliance, BICBW.

~Tim
-- 
<http://spodzone.org.uk/>

Re: [q-lang-users] ODBC connection with MS Access

[Albert G. <Dr....@t-...>]

Tim Haynes wrote:
> SQLGetInfo(SQL_IDENTIFIER_QUOTE_CHAR) is your friend:

Tim, that was very helpful, thanks a lot. I added a new odbc_getinfo
function to the odbc module which provides a direct wrapper of
SQLGetInfo(), so that I can now query all metadata. Fixing odbc_examp.q
so that it works with different RDBMS should be a piece of cake now!

While I'm giving the odbc module a facelift... I'd also like to support
user-defined functions written in Q (the sqlite3 interface already
provides these and I find them pretty useful). By any chance, do you
know whether ODBC provides an API for this kind of stuff? I'm looking
for an ODBC function which would allow to register a C callback as a UDF
to be called from SQL queries, which takes some SQL values as parameters
and returns another SQL value as the result. Googling around didn't turn
up anything useful so far.

Thanks,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

[q-lang-users] stream socket

[Humbert F. <fh...@fr...>]

My socket first try does not work  (Windows Vista) :

==> def SERVER = ("localhost",2000)

==> socket AF_INET SOCK_STREAM 0
336

==> bind 336 SERVER
()

==> listen 336 5
()

/* Now I type http://localhost:2000 and CR in my browser URL field. The 
next accept does not work. */

==> accept 336
accept 336

Re: [q-lang-users] ODBC connection with MS Access

[Tim H. <q...@st...>]

Albert Graef <Dr....@t-...> writes:

> BTW, does anyone here know a _portable_ way to quote column names which
> are also SQL keywords? (MS SQL doesn't like these.) ANSI SQL mandates
> double quotes, which works with both Access and PostgreSQL out of the
> box, but not with MySQL. :(

SQLGetInfo(SQL_IDENTIFIER_QUOTE_CHAR) is your friend:

| SQL_IDENTIFIER_QUOTE_CHAR(ODBC 1.0)
| 
|     The character string that is used as the starting and ending
|     delimiter of a quoted (delimited) identifier in SQL statements.
|     (Identifiers passed as arguments to ODBC functions do not have to be
|     quoted.) If the data source does not support quoted identifiers, a
|     blank is returned.
| 
|     This character string can also be used for quoting catalog function
|     arguments when the connection attribute SQL_ATTR_METADATA_ID is set
|     to SQL_TRUE.
| 
|     Because the identifier quote character in SQL-92 is the double
|     quotation mark ("), a driver that conforms strictly to SQL-92 will
|     always return the double quotation mark character.

<http://msdn2.microsoft.com/en-us/library/ms711681(VS.85).aspx>

Beware that, in m$loth terminology, "a blank" means either NULL or a space
character depending what they were smoking at the time.

HTH :)

~Tim
-- 
<http://spodzone.org.uk/>

Re: [q-lang-users] ODBC connection with MS Access

[Albert G. <Dr....@t-...>]

Jiri Spitz wrote:
> I tried the new release candidate and it works now fine with both NULLs 
> and empty strings in parametrized queries.

Great. I also tested the new version with MySQL and PostgreSQL and the
workaround doesn't seem to cause any hiccups there, so I hope that we
can consider this solved.

I still have to fix up the "menagerie" example (odbc_examp.q), so that
it works with Access without any ado, but that will be in the final release.

BTW, does anyone here know a _portable_ way to quote column names which
are also SQL keywords? (MS SQL doesn't like these.) ANSI SQL mandates
double quotes, which works with both Access and PostgreSQL out of the
box, but not with MySQL. :(

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

[q-lang-users] Q 7.11 RC2 available

[Albert G. <Dr....@t-...>]

Q 7.11 RC2 is now available in testing:
http://sourceforge.net/project/showfiles.php?group_id=96881&package_id=188958

The source tarball is available along with a Windows MSI package and
RPMs for SUSE 10.1. (SUSE 10.3 RPMs will be provided for the final release.)

This is slated to become the official 7.11 release if there are no more
bug reports in the course of the next few days.

RC2 is essentially the same as RC1, but with some additional bugfixes in
the ODBC module to make it work better with MS Access. Also, the binary
packages now include the latest versions of Pd/Q, Q-Audio, Qt/Q and
QCalc, as well as Eddie Rucker's new CSV module to read and write comma
separated value data. The source tarball for Q-CSV 0.1 has also been
released and is available here:
http://sourceforge.net/project/showfiles.php?group_id=96881&package_id=262346

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] ODBC connection with MS Access

[Jiri S. <jir...@bl...>]

Dear Albert,

I tried the new release candidate and it works now fine with both NULLs 
and empty strings in parametrized queries.

Many thanks,

Jiri

Albert Graef napsal(a):
> Jiri, could you please try the Qpad-7.11rc2.msi in testing and see
> whether it works for you? You can download the msi here:
> http://sourceforge.net/project/showfiles.php?group_id=96881&package_id=188958&release_id=568981
> 

Re: [q-lang-users] ODBC connection with MS Access

[Albert G. <Dr....@t-...>]

Tim Haynes wrote:
> The error code, HY104, is `Invalid precision or scale value'; `The value
> specified for the argument ColumnSize or DecimalDigits was outside the
> range of values supported by the data source for a column of the SQL data
> type specified by the ParameterType argument'. So what it's saying is when
> you're binding to a char field, a length of 0 is not permitted.

Tim, you hit the nail on the head there! :)

Access doesn't like a zero precision, not even for NULL parameter
values. This is clearly an Access-specific problem, MySQL and PostgreSQL
both work fine. I also digged through the ODBC docs, but nowhere does it
say that a NULL or empty string parameter is supposed to need a nonzero
precision, so I consider this a bug in the Access ODBC driver.

Anyway, I worked around the bug by adding an extra dummy byte for both
strings and () values, so that the precision value is never zero now.
Seems to work fine so far. I'm currently uploading a new release
candidate (7.11rc2) so that you can give it a whirl.

Jiri, could you please try the Qpad-7.11rc2.msi in testing and see
whether it works for you? You can download the msi here:
http://sourceforge.net/project/showfiles.php?group_id=96881&package_id=188958&release_id=568981

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag