object not found

[Jim Locker]

I *think* this is an error in the runtime system. At least, the error message is not terribly informative and I went round the horn on it for awhile before I figured it out. Take a function definition: function foo(string mystring) …blah blah blah … end function and invoke it in an event handler like this: foo(me.gettext()) and it works. Now, generalize foo a bit so it can handle different types of input: function foo(type(*) myvar) and invoke it the same way: foo(me.gettext()) and you get the runtime error “object not found” Doing it this way: mystr = me.gettext() foo(mystr) works fine. Similarly, if we define an array array myarray and initialize it, and put data in it, then the call foo(myarray[“mydata”]) also gives an object not found runtime error, and the solution is the same as the solution for the gettext. I don’t see why there should ever be an error given in this situation; foo is set to accept ANY type of input; the run time system should respect that, pass the result, then bomb if something totally off the wall happens. In my particular situation, the subroutine call had 6 variables passed and, since all of them existed, it took me quite awhile to tumble to the actual problem. I finally tried assigning a variable then passing it rather than passing an array member or a function return (I was doing both in different locations) because I realized that the one change I had made was to change the type definition in foo from a string to a type(*). Therefore, it had to be something to do with that. Also, as a general statement, I would like to be able to trap and display ALL runtime errors before bombing the program, without relying on the debugger to see them. The reason is fairly obvious; when I deploy this thing, if it bombs I’ll be getting support calls. If I have a useful runtime error message, at least I’ll know where to stop. Besides, the debugger is quite fragile. It crashes the IDE all the time, reporting unhandled exceptions. You built this with visual studio, I see.

[Jim Locker]

Neil Robinson wrote:

> Jim wrote:
>> I *think* this is an error in the runtime system. At least, the
>> error message is not terribly informative and I went round the horn
>> on it for awhile before I figured it out.
>>
>> Take a function definition:
>>
>> function foo(string mystring)
>>
>> …blah blah blah …
>>
>> end function
>>
>> and invoke it in an event handler like this:
>>
>> foo(me.gettext())
>>
>> and it works.
>>
>> Now, generalize foo a bit so it can handle different types of input:
>>
>> function foo(type(*) myvar)
>>
>> and invoke it the same way:
>>
>> foo(me.gettext())
>>
>> and you get the runtime error "object not found"
>>
>> Doing it this way:
>>
>> mystr = me.gettext() foo(mystr)
>>
>> works fine.

> There *is* a difference. me.gettext() returns a value, not an object.

But in simpol all datatypes are objects. So even when a value is
returned, it is assigned to an object in the call to the function.

>> Similarly, if we define an array
>>
>> array myarray
>>
>> and initialize it, and put data in it, then the call
>>
>> foo(myarray["mydata"])
>>

> Similarly, array elements containing value types, are not themselves
> objects.

> The problem you are haveing is that you have defined the argument to be
> a reference to any data type. You can pass any pre-existing object to
> this as an argument. If you want to use this in this way, and you are
> only passing values, then use the anytype object as your argument.

The history here had me changing this originally to type(=). I only
further generalized it while debugging.

>> also gives an object not found runtime error, and the solution is the
>> same as the solution for the gettext.
>>
>> I don't see why there should ever be an error given in this
>> situation; foo is set to accept ANY type of input; the run time
>> system should respect that, pass the result, then bomb if something
>> totally off the wall happens.

> No, foo is set to accept a *reference* to any type of object. You aren't
> passing a reference, you are passing what is effectively a value with no
> containing object. All you really need to do is:

> foo(string.new(me.gettext()))

OK. I see that.

>> In my particular situation, the subroutine call had 6 variables
>> passed and, since all of them existed, it took me quite awhile to
>> tumble to the actual problem.
>>
>> I finally tried assigning a variable then passing it rather than
>> passing an array member or a function return (I was doing both in
>> different locations) because I realized that the one change I had
>> made was to change the type definition in foo from a string to a
>> type(*). Therefore, it had to be something to do with that.
>>
>> Also, as a general statement, I would like to be able to trap and
>> display ALL runtime errors before bombing the program, without
>> relying on the debugger to see them. The reason is fairly obvious;
>> when I deploy this thing, if it bombs I'll be getting support calls.
>> If I have a useful runtime error message, at least I'll know where to
>> stop.

> Errors in the parameter list are almost untrappable except in debug
> mode. There is currently no exception handling built into the language.
> As for post-mortem, you could temporarily deploy the debug versions
> which in the case of these sorts of errors will output a result file
> that looks a bit like a disassembly dump with an arrow pointing to the
> offending line of reconsituted source.

I have not seen how to do that covered in the documentation. It is there?

>> Besides, the debugger is quite fragile. It crashes the IDE all the
>> time, reporting unhandled exceptions. You built this with visual
>> studio, I see.

> The only problem we have had with the IDE is that after breaking, upon
> restarting debugging when using wxWidgets components on certain systems
> this will result in a GPF. What we have been able to establish so far is
> that the wxWidgets side does not properly cleanup and then during
> reinitialization send through some bogus pointers.

This problem certainly does seem to be associated with wxwidgets.

[Michael]

Jim wrote:
> I *think* this is an error in the runtime system. At least, the
> error message is not terribly informative and I went round the horn
> on it for awhile before I figured it out.
>
> Take a function definition:
>
> function foo(string mystring)
>
> …blah blah blah …
>
> end function
>
> and invoke it in an event handler like this:
>
> foo(me.gettext())
>
> and it works.
>
> Now, generalize foo a bit so it can handle different types of input:
>
> function foo(type(*) myvar)
>
> and invoke it the same way:
>
> foo(me.gettext())
>
> and you get the runtime error "object not found"
>
> Doing it this way:
>
> mystr = me.gettext() foo(mystr)
>
> works fine.

There *is* a difference. me.gettext() returns a value, not an object.

> Similarly, if we define an array
>
> array myarray
>
> and initialize it, and put data in it, then the call
>
> foo(myarray["mydata"])
>

Similarly, array elements containing value types, are not themselves
objects.

The problem you are haveing is that you have defined the argument to be
a reference to any data type. You can pass any pre-existing object to
this as an argument. If you want to use this in this way, and you are
only passing values, then use the anytype object as your argument.

> also gives an object not found runtime error, and the solution is the
> same as the solution for the gettext.
>
> I don't see why there should ever be an error given in this
> situation; foo is set to accept ANY type of input; the run time
> system should respect that, pass the result, then bomb if something
> totally off the wall happens.

No, foo is set to accept a *reference* to any type of object. You aren't
passing a reference, you are passing what is effectively a value with no
containing object. All you really need to do is:

foo(string.new(me.gettext()))

> In my particular situation, the subroutine call had 6 variables
> passed and, since all of them existed, it took me quite awhile to
> tumble to the actual problem.
>
> I finally tried assigning a variable then passing it rather than
> passing an array member or a function return (I was doing both in
> different locations) because I realized that the one change I had
> made was to change the type definition in foo from a string to a
> type(*). Therefore, it had to be something to do with that.
>
> Also, as a general statement, I would like to be able to trap and
> display ALL runtime errors before bombing the program, without
> relying on the debugger to see them. The reason is fairly obvious;
> when I deploy this thing, if it bombs I'll be getting support calls.
> If I have a useful runtime error message, at least I'll know where to
> stop.

Errors in the parameter list are almost untrappable except in debug
mode. There is currently no exception handling built into the language.
As for post-mortem, you could temporarily deploy the debug versions
which in the case of these sorts of errors will output a result file
that looks a bit like a disassembly dump with an arrow pointing to the
offending line of reconsituted source.

> Besides, the debugger is quite fragile. It crashes the IDE all the
> time, reporting unhandled exceptions. You built this with visual
> studio, I see.

The only problem we have had with the IDE is that after breaking, upon
restarting debugging when using wxWidgets components on certain systems
this will result in a GPF. What we have been able to establish so far is
that the wxWidgets side does not properly cleanup and then during
reinitialization send through some bogus pointers.

Ciao, Neil

[Michael]

Jim wrote:
> Neil Robinson wrote:
>> There *is* a difference. me.gettext() returns a value, not an
>> object.
>
> But in simpol all datatypes are objects. So even when a value is
> returned, it is assigned to an object in the call to the function.

That is true, in the main. I think the problem that you are hitting is
this object is not anchored anywhere, so it immediately vanishes. This
wouldn't matter if only the value were being transmitted, but both
type(*) and type(=) require an object (the type of the object is
restricted to one of the value types with type(=), but it still must be
an object). I tend to use anyvalue for most of these things myself. You
don't need an object a value being assigned will work as well.

>> The problem you are haveing is that you have defined the argument
>> to be a reference to any data type. You can pass any pre-existing
>> object to this as an argument. If you want to use this in this way,
>> and you are only passing values, then use the anytype object as
>> your argument.
>
> The history here had me changing this originally to type(=). I only
> further generalized it while debugging.

The only difference between the two in their behavior is that type(=) is
more restrictive.

>> Errors in the parameter list are almost untrappable except in debug
>> mode. There is currently no exception handling built into the
>> language. As for post-mortem, you could temporarily deploy the
>> debug versions which in the case of these sorts of errors will
>> output a result file that looks a bit like a disassembly dump with
>> an arrow pointing to the offending line of reconsituted source.
>
> I have not seen how to do that covered in the documentation. It is
> there?

I think so, but probably in no obvious place. This stuff is really old
(it pre-dates debugging in the IDE).

Basically, when tracking this sort of thing down, run from a command
prompt. Run the program using smpd1_32.exe. If it crashes on an
unhandled error, the chances are relatively good that it will give you a
dump of the reconsitituted source of the offending function with an
arrow pointing at the line that failed.

Usually, running in the debugger is still more effective though.

Ciao, Neil

[Author]

Posts