> Sorry, but we will not accept old pragma format (as I said, is invalid… > and ugly ;) ).
But we will be able load old compiler (when it will be removed from standard image) to support such old code 2017-08-17 11:48 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>: > hi, > > Old way to do FFI calls is no longer supported on Pharo, but this > deprecation is very old (since Pharo 2). Now, in Pharo 4 we replaced the > compiler (for OpalCompiler) and we no longer supported “pragma-like” calls, > in part because they are “invalid” pragma calls (they do not agrees with > pragma syntax) and in part because the way to go in pharo is using UFFI > (before UFFI it was NB which was largely compatible). > > I don’t know why ZeroMQ bindings are made using old format, but the way to > advance them is to > > > On 16 Aug 2017, at 23:31, 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). > > 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. > > 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). > > 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. > > 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)? > > 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. > > Most of Pharo is largely compatible. Now, we cannot keep compatibility in > some areas more than a couple of versions back because the effort of > advance Pharo *and* keep compatibility is just too much. > - FFI changed a lot. > - Morphic changed something. > - Most of the rest is basically the same (just better). > > > 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? > > 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? If > > yes, how to "attach" the patch to Pharo 5? > > Pharo5 is history. > We keep one version back (now Pharo6) > Again, a matter of effort and resources. > > > 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. > > 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:) > > 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? > > Sorry, but we will not accept old pragma format (as I said, is invalid… > and ugly ;) ). > What I suggest is to rewrite the bindings of ZeroMQ to UFFI: it should be > very straight forward and you will be contributing to the community in a > way that will remain quite some years at least. > > > > 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. > > thing is… non OO programmers will have problems to understand a pure OO > language. > people working with Java, C#, C++ and others may think they do OO, but > they don’t most of the time… then, switching paradigms is hard work. > even worst, smalltalk syntax is considered “alien” to people used to > algol-based languages. > > but we cannot do much more than we are trying to achieve in this area: > make Pharo more compatible with “the rest of the world” when it make sense, > but strongly stay in our “alieness” when it has sense (syntax, pureness, > etc.). > > Esteban > > > > > 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. > > > > >
