Hi in fact I was wrong we do not support pragma for FFI and we could have deprecated them but we did not.
Stef On Tue, Aug 22, 2017 at 5:15 PM, Stephane Ducasse <stepharo.s...@gmail.com> wrote: > Tx for the report > > > On Wed, Aug 16, 2017 at 11:31 PM, bdurin <bruno.du...@gmail.com> wrote: >> Hi, >> >> I stumbled upon what seems to me a strange issue in Pharo 5. The RBParser >> fails to correctly parse the legacy FFI pragmas. This completely breaks down >> the browser, the inspector and debugger (because as far as I understand all >> use RBParser to correctly highlight syntax). I had the image crashed and >> some red boxes at some point while insisting to inspect and debug. Overall >> this is not a big issue but it raises some more general bells to me. >> >> In order to reproduce this: >> - load the official Pharo 5 (curl get.pharo.org/50+vm | bash) >> - launch the image (./pharo-ui Pharo.image &) >> - add the following repository >> MCSmalltalkhubRepository >> owner: 'panuw' >> project: 'zeromq' >> user: '' >> password: '' >> - load the last versions of ZeroMQ and ConfigurationOfZeroMQ (not sure if >> the latter is needed) >> - open a Nautilus Browser and look at the class method apiZmqBind:to: of the >> ZmqApi class in the ZeroMQ package: you get a MessageNotUnderstood error >> (receiver of keywords is nil). You can get past this by clicking on >> "Abandon" but the source code is displayed in a corrupted way: >> apiZmqBind: s >> ocket to: endpoint <cdecl >> - repeat a few times by looking at other methods until you get a red box: >> then you cannot look at source code any more with this browser. If you are >> obstinate and "lucky" you will succeed in crashing the image. >> - you can pin the problem by running in a Playground >> RBParser parseFaultyMethod: 'apiZmqBind: socket to: endpoint >> <cdecl: long ''zmq_bind'' (ZmqApiSocket* char*) module:''zmq''> >> ^self externalCallFailed'. >> and you'll see that the pragmas is not correctly parsed. (The root cause is >> that the legacy adapter RBFFICallPragma does not follow the API defined by >> its super class RBPragmaNode (selector, arguments, positions) and so is not >> a properly defined node. I corrected the problem by computing and setting >> the corresponding instance variables.) > > > >> 1) As a beginner at Pharo, I find it difficult to deal with the various >> versions of Pharo. ZeroMQ is the (only) Smalltalk-Pharo binding for zmq. It >> dates back to Feb 2014 so I expected it to work in Pharo as of 3 years and a >> half later (Pharo 6 dates back to June 2017). > > We maintain actively 2 versions on 5 OSes. > On many system old libraries do not work on new versions. > By definition I never believe that a version of Mac OS 9 is working on > Mac OS 11 and Mac has a lot of money. > A lot more than us. > > >> I naively tried to load the package in a Pharo 6 image and it failed because >> of a syntax error. As I had read a lot about the various FFI mechanisms, I >> quickly understood that it must be because the FFI declarations in pragma >> are not supported anymore. > > They still are but you probably hit an edge case. > >> I then loaded the package in a Pharo 5 image and I got the error that I >> described. After finding the error and solving it, I guess that the FFI >> declaration in pragma was barely supported in Pharo 5, which has already >> switched to UFFI and that it is something dating back to Pharo 4. (I did not >> try with Pharo 4 as I do not want to work with versions before 5). > > Normally we took care to be backward compatible to ease moving from > one version to the other > one. Esteban was on vacation and I asked him to have a look. > > >> Is there a way to know for a package what the compatible Pharo version is? >> It seems that currently I have to look at dates, look at the features used >> by the package and look for the history of development (fortunately the >> mailing lists are easy to search) to understand which version is likely to >> work. > > People should > - publish their package in the catalog of a given version. > - have test > - have a configuration because this configuration list also the > version of Pharo. > > >> Are not deprecations a bit too fast if a package written 3 years ago cannot >> work in the latest Pharo version and trigger bugs in Pharo 5, which dates >> back to May 2016 (so only a bit more than 2 years after)? > > This is not a deprecation. This is probably just a case that was not handle. > We spent 8 months developing a new FFI and there is still points to be added. > >> I find it a bit too fast as compared to mainstream languages. To my mind, >> either deprecations should be slower or a version/dependencies system should >> be there to help users. > > Please do not generalise from one case. > We pay attention to make sure that people can move. Now > >> >> 2) Another question about versions: Pharo 6 is out since June, Pharo 7 is >> under development. What is the status of Pharo 5? Already history or still >> relevant? > > We do not actively back port fix to Pharo 50. But you can execute > Pharo 50 and we build regularly vms. > > > >> I am asking because I corrected the problem of FFI declaration in pragma, >> but it seems to me that it is not useful to publish this change as starting >> from Pharo 6 this way to do FFI is not supported. So should I contribute? > > Please send your fixes so that we can have a look at it. > >> yes, how to "attach" the patch to Pharo 5? > > You can > - open a bug entry and publish a slice in the Pharo50Inbox > - fileout your changes and send them to the mailing-list to start with. > > >> >> 3) As explained above, in Pharo 5, looking at the source trigger an error. >> Even if this looks like a rare corner case, I think that the developer tools >> should not trigger bugs when looking at source code, even less trigger a red >> box in the source code viewer (in the browser, but the problem also occurs >> --less strongly-- when looking at the object in an inspector: there should >> not be "error printing" when it is only a syntax highlight problem). If the >> code is malformed and the parser used to highlight syntax fails, there >> should be a fallback such as the source code being displayed without any >> highlight. It sends a very bad impression to have this kind of bugs when one >> simply wants to look at code, not even running it. > > Yes you are correct. > > >> I have not dug enough in this area of Pharo, but it seems to me that the >> parser that is used to build the AST for code execution / method compilation >> should not be the same as the parser used to highligh syntax. (Of course I >> am not saying that there should be 2 distincts code base for the 2 parsers, >> but they should at least run differently.) The first one must be strict with >> errors as a malformed AST cannot be executed. The second one must be >> lenient, as a malformed AST does not prevent to print the string of the >> source code. Of course, at the end if the code is malformed there will be an >> error at execution, but if the source code can be displayed even when it is >> malformed, at least I have the opportunity to correct it so that it runs >> correctly. (In this case, convert the old FFI pragma declaration into a >> fficall:) > > This is more than that. > A parser error should not blow up the UI. This is a problem in the > current architecture. > Pharo is not perfect but we are working on it. > > >> I may be missing something here but if this works the same in the most >> up-to-date version of Pharo, the same kind of error might appear again. >> What do you think? > > We have a long list of improvements that we should do. > Pharo is not perfect. It is what we have now and that we use daily, > improve daily > but developing robust and good quality software is taking a lot of time. > We have to prioritize for each version. > Now we make progress. Each version of Pharo is getting better. > > >> >> 4) A final remark: let us classify people as Beginner/Confirmed in >> programming and B/C in Pharo (A BB is a beginner in programming and in >> Pharo, a CC confirmed in both, a BC cannot exists and CB are those who >> discover Pharo while knowing well other languages). Pharo seems to be great >> for BB and CC. I went through the MOOC and the various books which are >> great. My first steps in Pharo environment were great. >> As a CC it seems to be great also as in the very small area of the system >> where I took the time to drill into all the details, I could very easily >> change things (and correct a bug), that would have been very difficult to >> understand and change in a lot of other languages. Even hacking the VM seems >> to be possible for a non-VM expert. >> But I consider myself rather as a CB. As such I tend to try and do complex >> things that I usually do in other languages and run into tricky problems. >> These problems are rather dealt with and corrected by Pharo developers but >> that as a user I would expect them to remain hidden to me or to be clearly >> advertised in the docs. As compared to a BB, a CB is not going to stay in a >> well delimited area where everything is smooth. >> True, in a way it is a very strong incentive to become a Pharo expert! But I >> am wondering if this aspect could be improved. > > Freedom of action is a two edge sword. > We are concerned by that aspect. Now often it is not easily to hide > and reveal on demand > a reflective system. > > Stef > > >> >> Thanks, >> Bruno >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Parser-failure-on-FFI-pragmas-declaration-in-Pharo-5-tp4961737.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>
