Hi, Thank you Denis and Esteban for your help. I agree, the way to go is to rewrite correct UFFI bindings. Denis' solution seems fragile.
About my points 3 and 4 I think I was not clear. I did not want to force old FFI syntax. I explained why I thought that the way Pharo 5 was failing at deprecated code was very misleading and gave a bad impression. About developer tools in Pharo, as far as I understand ideally everything should be done in Pharo, we should not have to use a text editor to develop, etc. So we should be able to access legacy, deprecated source code from within Pharo. This could work if the source code viewer did not enforce strict parsing rules. In Pharo 5, it fails badly and late. In Pharo 6 it fails early with a nice syntax error but it still prevents me from getting the code into Pharo. ZeroMQ are just bindings that I can easily rewrite. But what if I get the .mcz file of an old package whose code I do not know? It would not load. To get its code, I would have to learn about the .mcz format, dig into the .mcz archive and open the right file in a text editor to get the code declarations one by one. (Or if I am smarter I could hack FileIn to get the code declarations as an array of strings with no attempt at compiling and then copy paste the pieces.) It would be nice to be able to load an old deprecated code, let it run and fail and correct it live in the debugger for example. It would be even nicer to have the old syntax recognized and explicit warnings (or even suggested rewriting). About item 4, I have no problem with Smalltalk syntax or it being OO down the line. When I say that Pharo could be hard for people with programming experience, I was refering to the fact that one get easily caught by version problems, by legacy stuff that seems to be maintained and at some point stop working (and unless you read a lot the mailing list, it can be quite difficult to understand the source of the problem). To put this into perspective, I can give 2 examples in python: numpy and pandas. Numpy is a very mature library with very few problems. Most users of python are CPython users (Python implemented in C) and uses numpy without wondering. But I remember looking at pypy as a drop-in replacement for cpython at a time when pypy was not very mature and it had not been easy to find out that numy could not work with pypy because numpy depends on the C-API (hence CPython). (Now pypy has a dedicated numpy project which is correctly advertised.) Pandas is a python library that changes a lot and is maintained by few people. Often API or function behaviour changes from one version to the next. But both the documentation and the code (which emits deprecation warning when it detects old uses) help a lot the user in switching from one version to the other or detecting potential problems with old code, often without a complete error. The idea is that we can deal with a dog that groans before biting and that we tends to avoid dogs that bites without groaning before. In Pharo, I understand that cleaning old code and getting things very robust is very time-consuming and would not be worth the effort but having a way to alert the user that something is legacy stuff would be great. Maybe something like having the list of all packages and their version included in a given image version on https://pharo.org could be useful. Or having a process that maintain the state of all known packages in the Smalltalk repositories: for example there would be 4 states, actively developed, maintained, legacy and deprecated. "Actively developed" would be manually set on all packages that are worked on for the new version (is Iceberg in Pharo 7 a good example?). "Maintained" would be set on all packages predating a given version but tested for the given version. "Legacy" would be automatically set on all packages predating a given version and not tested (so use at your own risk). "Deprecated" would be manually set on packages that are reported as failing and are known to fail because of new design (for example old FFI when UFFI comes). The largest part of the packages would be automatically flagged as "legacy" so the tagging work would not be too large. (Maybe to bootstrap the tagging system, all packages published after Pharo 7 release would be flagged as "maintained" and all others as "legacy".) With this system, ZeroMQ would have been flagged as "legacy" since Pharo 5 and I would have expected failure. So I am not really talking about something to change in the language but rather in the development process of the language. If it is possible to set up a simple reporting system, the tagging could be done fast by all users. (For example, if one loads a package in a given Pharo version, one can click on an entry in the WorldMenu which runs a form to report to a given server the successful load or the error and flag the package accordingly.) Another idea would be to formalize improvements with a Pharo version of PEPs (Python Enhancement Proposal). These technical reports are very useful when digging into the internals of python after a strange error or something similar. Thanks, Bruno -- View this message in context: http://forum.world.st/Parser-failure-on-FFI-pragmas-declaration-in-Pharo-5-tp4961737p4961881.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
