> 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.)
For Morphic I think that we will see but Bloc should not be killed on the altar of Morphic compatibility. We do not have much to keep from Morphic. > > 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. Esteban told me that it was decided that the parser was not maintain for the ffi. Now what would be great is to port the library to Pharo and newFFI. > 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. it is normal because we do not have yet metadata for loaded packages 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. That I do not know :) > 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.) I do not know . What I would do for now is - port the library to latest Pharo stable - make sure that you are succesful with your project - Of course you can help by fixing some aspects of Pharo you want to see improved :) I hope that we will deliver package metadata and the tooling. > > 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.) Thanks for the description. > 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. >
