Hi!
So there are no more halting on assert. But precompiled bytecode still do not work properly. Looks like problem lies in imported functions. Somehow some function do not imported successfully from another module. This functions use shared classes as input and return value. In simple script i cannot reproduce problem. We have no choise expect drop off imported functions and use function pointers instead.
huge problems with precompilde byte code
Author
Hm, looks like function pointers is something strange. Imported functions are planned to deprecate in Angel Script 3.0 but i can't understend how modules can communicate using function pointers. So imported feature do not work and there are no another solution. We are stucked (((
Author
Hi!
So problem is - byte code can't load and it return -1 on loading. Error comes when loading shared constructors section.
This link http://www63.zippyshare.com/v/43593543/file.html leads to archive with modifaied sample "include" from angel code also archive contain scripts with leads to bug when loading shared classes.
So problem is - byte code can't load and it return -1 on loading. Error comes when loading shared constructors section.
This link http://www63.zippyshare.com/v/43593543/file.html leads to archive with modifaied sample "include" from angel code also archive contain scripts with leads to bug when loading shared classes.
I've reduced the problem to this script:
There is definitely something wrong with the combination of the shared enum and shared class.
I'll update when I have the fix.
shared enum ResourceType {}
shared class Resource
{
void getType(ResourceType) {}
}
There is definitely something wrong with the combination of the shared enum and shared class.
I'll update when I have the fix.
I've fixed the bug in revision 1444.
The problem was that the shared enums were not treated as shared when loading the bytecode, so each module got its own unique enum. This caused the other shared entities (classes, functions, etc) that used that enum to not match the original declaration, which is why the loading failed.
Thanks for the help in producing the code that allowed me to debug this.
The problem was that the shared enums were not treated as shared when loading the bytecode, so each module got its own unique enum. This caused the other shared entities (classes, functions, etc) that used that enum to not match the original declaration, which is why the loading failed.
Thanks for the help in producing the code that allowed me to debug this.
Author
Big big thanks 
this problem was gone but, but i found another bug.
This link to archive with problem code - http://www36.zippyshare.com/v/57990345/file.html
in sample fisrt loaded testbed.as and second goes second.as. BuildingDesc are included in testbed.as but not in second.as but comiler successfully find SBuldDesc when compiling second.as. When we try load bytecode for second.as complier can't find SBuldDesc and that is right. So problem is compiler find description of type that declared in another module but this must be are error as it is when loading bytecode or this should work and for byte code but i think is wrong becasu this no logical.
this problem was gone but, but i found another bug.
This link to archive with problem code - http://www36.zippyshare.com/v/57990345/file.html
in sample fisrt loaded testbed.as and second goes second.as. BuildingDesc are included in testbed.as but not in second.as but comiler successfully find SBuldDesc when compiling second.as. When we try load bytecode for second.as complier can't find SBuldDesc and that is right. So problem is compiler find description of type that declared in another module but this must be are error as it is when loading bytecode or this should work and for byte code but i think is wrong becasu this no logical.
You're right. The compilation of second.as should fail if it doesn't declare the shared SBuildingDesc. I'll look into this when I get home tonight.
The problem was with shared classes. When a shared class was found during compilation and it had already been compiled in a previous the members were not compiled again so it wasn't detected that they were using some types that were otherwise not declared in the script. When the script was then saved, the full declaration of the shared class was saved including the reference to the other types.
I've fixed this in revision 1445. The missing declaration will now be properly detected during compilation of the script.
I've fixed this in revision 1445. The missing declaration will now be properly detected during compilation of the script.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
