Load() examples: '[' expected: depth == nDimensions


I tried the two load() examples in the AIL/DDL documentation section 2, and for both load() calls I get:
’[’ expected: depth == nDimensions

Also, if I try load() on a file name that doesn’t exist, there is no error and this is returned:

I am using iquery for all of the AIL commands–is that correct?

Nassib Nassar



Thank you for letting us know. If you can, please register at trac.scidb.org/register and open a new ticket, this will let you trac the status of this issue. If you prefer we will open a ticket.



Jacek, thanks. The link you gave for registering redirects me to trac.scidb.org/prefs/account for the scidb_05 user. I haven’t been able to figure out how to register.



I just realized that I should log out first and then register. However, when I tried to do this, I got the following error:

Trac detected an internal error:
AttributeError: ‘AccountChangeNotification’ object has no attribute ‘smtp_server’

There was an internal error in Trac. It is recommended that you notify your local Trac administrator with the information needed to reproduce the issue.

To that end, you could Create a ticket.

The action that triggered the error was:

POST: /register


Sorry for the flurry of messages. I am now able to log in and enter tickets. Just to let you know, these new tickets do not show up under My Tickets. They do show up under some of the other choices like Active Tickets Mine First (though only after sorting by creation date) and All Tickets By Milestone. This had me confused for a while, and I think I’ve accidentally entered the tickets multiple times.



Also I should mention that I can’t access PrivateArea when logged in as myself. I have to log out and back in as scidb_05.



Nassib -

i. Thanks for the bug. This looks to be a docs issue. I’ll look into it.

ii. We’re … a little shy about the PrivateArea stuff. We’ve been given some use-cases which are “sensitive” (the originator doesn’t want them broadcast) and we haven’t had the resources to go through some of he stuff with the quality comb. But we also want to be as open as possible. So we compromised, and let everyone who has the user_id/passwd look at everything.

Without making too many overly-bold predictions, we’ll be loosening these restrictions up as we get more comfortable. The day to day mechanics of “open source” development are a bit new to many of us.




Thanks! I’m not concerned about it; just wanted to let you know some user experiences in case you weren’t aware of them.