Pharo Issue Tracker - Manuscript (Case [Issue]22561) UnifiedFFI - uFFI should not require decompilation to extract sender selector

Manuscript Notification

	Guillermo Polito opened Case 22561: uFFI should not require decompilation to extract sender selector and assigned it to Esteban Lorenzano: Bug in UnifiedFFI: 1. Pharo Image • You are subscribed to this case

Right now, uFFI compiles a new version of the method when doing a callout for the first time.
When doing so, it stores in the newly compiled method the selector that was originally used to create the callout (ffiCall: nbffi:, etc), so it would appear in further searches for senders.

However, to extract that selector it is actually using `thisContext sender sender messageSends first selector` when it could use just `thisContext sender selector`.

The problem with the first one is that it forces a creation of the sender sender AST node and look it for the source code. This may produce further problems like infinite recurssions:
- when doing an ffi call, the ffi call requires the source code to get the AST
- to get the source code, some ffi calls may be required to get its location (e.g, the HOME env var)
- and loop

	Priority: 4 – Would be nice		Status: Work Needed
	Assigned to: Esteban Lorenzano		Milestone: Pharo7.0

Go to Case

No longer need updates? Unsubscribe from this case.

Don't want Manuscript notifications anymore? Update your preferences.

_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
https://lists.gforge.inria.fr/mailman/listinfo/pharo-bugtracker