Hi Stef, Thank you for your explanations!
About deprecation, I found it fast because I think FFI as a key component of a language. I imagine similar problems could happen when going from Morphic to its successor (Bloc?). Even with a stable API, I expect some code to explicitely depends on Morphic and break in the next GUI framework. I do not think this can be avoided. I am aware that maintenance is very costly and that it is always hard to be sure new users do not get caught in this kind of change. (As far as I understand the old MVC framework was kept quite long along with the at-the-time new Morphic to ensure smooth transition.) Note that I am not trying to claim that Pharo generally is bad or worse than another language. As a new user, my expectations were quite high after spending a few weeks learning the language, going through the MOOC, being able to tinker with the UI (looking at everything, modifying the World Menu, etc.), looking into the details of the bytecode and the VM. All of these worked very well and I still do think that Pharo is a great of software as I wrote in a previous question. Even when facing the UI problem in Pharo 5 due to old FFI syntax, I was able to hack into the code and get it work. In another language hitting an "internal" problem often is a dead end. I cannot tackle the problems I highlighted by myself. But with the help of someone who knows how to address them in the Pharo's way, I am willing to help. About dependencies and version, I knew of Metacello configurations when I wrote my first message and I was thinking of Pharo version (more precisely the versions of core packages and dependencies as opposed to other external packages that should be loaded on top of a freshly downloaded image). I did not know that Pharo version was in configurations. So I had a look at ConfigurationOfZeroMQ and maybe it keeps on being an exception but I did not find any dependency on Pharo version in it. However it declares a dependency on FFI version 1.4, which eventually is better than explicitely setting a dependency on a Pharo version. I also had a look at the "validate" class method and its comment that mentions "MetacelloMCVersionValidator". How is this validation mechanism triggered? I could work on it and modify the source code loader(s) so that instead of getting a syntax error in Pharo 6 I get an error or a critical warning from the validator. (I loaded the package by adding the corresponding repository in the Monticello browser and loading ZeroMQ and ConfigurationOfZeroMQ last versions.) I eventually found what you talked about. In ConfigurationOfFFI, "stable:" method lists the FFI versions that Pharo versions supports. The convention for versioning is not clear to me: old FFI is supposed to work up to Pharo 4 and the spec says FFI should be 1.7 to 1.9, which would mean that if a package needs version x, any version y>=x is ok, but from Pharo 5 (which requires FFI 1.10.1) it should fail, which would mean that version x should be matched exactly (or an interval should be defined). In Pharo 6 ConfigurationOfUnifiedFFI>>version_0_26_8 declares a dependency on FFI-Kernel ‘FFI-Kernel-EstebanLorenzano.45’, which I do not understand. Maybe here I can remove FFI dependencies. (Is this what you meant when saying you could have deprecated it but did not do it?) Besides ConfigurationOfFFI is not included in a freshly downloaded Pharo image (I checked for Pharo 5), I found a reference to it in ConfigurationOfUnifiedFFI (in the "ffi:" method) and manually added the corresponding repository (MetaRepoForPharo50) in Monticello browser and loaded the last version of ConfigurationOfFFI. So it seems that the info is not available by default. I had also a look at FFI-Kernel package (the object as found by running "RPackageOrganizer default packages select: [:p | p name = #'FFI-Kernel’].") and could not find any version info. Is it correct that the version info of a package is only available through ConfigurationOf... and is not included in the package object? If I understand well, a way to correct the problem would be: - to ensure (or set it as an option for a start) that Metacello validation is triggered even when loading source code and let the user choose from an option whether it wants errors at loading stage or only warnings (and expect problems when running). - add all the ConfigurationOf that are in "Pharo/MetaRepoForPharo50/main" repository in the corresponding official image (maybe rather do this for Pharo60 which is still maintained) so that the validation gets all the needed info - as you mentioned in an earlier message ConfigurationOf for some "internal" packages (included in a freshly downloaded Pharo image) are missing, so add them, attribute them a version and set dependencies accordingly. (I can help, it is a good way to learn about the internals of the language.) Is it correct? (I can also work on the validator with some help.) About correcting the specific problem I had in Pharo 5. Esteban told me that it was not useful so I am confused now. About 0mq, I am not an expert of the (original) C library and of the python bindings. The library sets up sockets for communication between processes and even if you can serialize them apparently ZeroMQ is relatively brittle as regards initialization (and this is one of its flaws). The author of the ZeroMQ Pharo package was aware of the persistence problem and mentioned he could not solve it completely. This is not an easy problem apparently. About python bindings, they abstract initialization a bit and more importantly offer abstractions to process the messages through the sockets: integration with the async python 3 framework and with a popular event loop (python tornado library from Facebook) are offered. It is much easier to work with ZeroMQ this way as you do not have to care about low-level IO details. (I do not know how it is done in the python bindings but for example to listen to the socket either an event loop could take care of the regular polling of the sockets or one could set up a thread that listens to the socket through a blocking call.) The equivalent in Pharo might be to integrate ZeroMQ with the GUI event loop. (Not something I am able to do unfortunately.) Thanks, Bruno -- View this message in context: http://forum.world.st/Parser-failure-on-FFI-pragmas-declaration-in-Pharo-5-tp4961737p4963663.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
