On 04/07/2015 07:51 PM, Holger Hans Peter Freyther wrote: > On Tue, Apr 07, 2015 at 06:24:15PM +0200, Roland Plüss wrote: > >> I sure can decide the return type. I just considered it quite quick and >> easy if I could return an #int if I link to a function actually >> returning an integer. I certainly could return nil but then I have no >> idea what error really happened nor can I properly catch it (well... >> besides ifNotNil: ). Since Smalltalk has already an exception/error >> system why not using it? I don't like wrangling a language unless >> there's no other choice. > It is a matter of how much time you have. In most cases I don't > think we want code like: > > Smalltalk code... > C-code > C-code > Exception > Smalltalk code... > > This will be problematic with native code.. we will do a longjmp > through it or such. So what we can do is that the "next" execution > context can be set once the process returns to Smalltalk. We are > not many but if you want to implement it I am happy to help you. Unfortunately I don't have time at the time being... at last not for a Smalltalk VM endeavour. But once I'm done with the current work load it's certainly an option. I could imagine something like having an exception holder somewhere so if an exception happens the exception object (which exists already in Smalltalk) is placed in a specific place in the VM context. Once the cCall returns it can look if there is an OOP stashed away and if so call in the current execution context "ExceptionOOP signal". We would be in a valid Smalltalk execution context and it would act like an exception signaled just in that place from inside Smalltalk. This would be in my opinion a very small change like 2 VM functions added: void gst_set_ccall_error(OOP exception) and OOP gst_get_ccall_error(). Then inside the ccall function in the VM just add a check to see if that OOP is set and get rolling. Theoretically this could even be done in the Smalltalk side after finishing processing the ccall by checking if the OOP is set in the VM and processing it. Would be close to your ErrNo solution but instead of an integer it would be an OOP instead.
>> And as far as I know I can't include any code into a <primitive> >> declared method. >> >> I once did the trick with errno type error handling in a module I made >> for Smalltalk but it's cumbersome to use and error prone. > <primitive> will execute the Smalltalk code in case the primtive > failed. E.g. for the Array > > kernel/Array.st- at: anIndex ifAbsent: aBlock [ > kernel/Array.st- "Answer the index-th indexed instance variable of the > receiver" > kernel/Array.st- > kernel/Array.st- <category: 'built ins'> > kernel/Array.st: <primitive: VMpr_Object_basicAt> > kernel/Array.st- ^self checkIndexableBounds: anIndex ifAbsent: aBlock > kernel/Array.st- ] > When exactly does a primitive fail and how can I trigger this from inside a cCall? This might actually be abused for a little trick if working right. -- Mit freundlichen Grüssen Plüss Roland Leader und Head Programmer - Game: Epsylon ( http://www.indiedb.com/games/epsylon ) - Game Engine: Drag[en]gine ( http://www.indiedb.com/engines/dragengine , http://dragengine.rptd.ch/wiki ) - Normal Map Generator: DENormGen ( http://epsylon.rptd.ch/denormgen.php ) - Sowie verschiedene Blender Export-Skripts und Game-Tools
signature.asc
Description: OpenPGP digital signature
_______________________________________________ help-smalltalk mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-smalltalk
