Parser failure on FFI pragmas declaration in Pharo 5
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. 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? 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? 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. Thanks, Bruno -- View this message in context: http://forum.world.st/Parser-failure-on-FFI-pragmas-declaration-in-Pharo-5-t... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Hi. I think your problem related to the old FFI syntax. In Pharo UFFI is the way to do external calls. To enable old FFI syntax try to switch compiler: Smalltalk compilerClass: Compiler I used this trick to port some small library which was based on old FFI. I made migration manually but maybe there are tools to convert old FFI methods to new one. 2017-08-16 23:31 GMT+02:00 bdurin <bruno.durin@gmail.com>:
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.
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?
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?
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.
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.
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.durin@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-t... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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 <estebanlm@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.durin@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.
On Thu, Aug 17, 2017 at 1:09 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
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
But then you should compile such code with the old compiler, not make opal compatible, no?
2017-08-17 11:48 GMT+02:00 Esteban Lorenzano <estebanlm@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.durin@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-f
ailure-on-FFI-pragmas-declaration-in-Pharo-5-tp4961737.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
-- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
Yes. Also simple solution can be to override compiler of problem classes to return old compiler. I know it is better to rewrite code but it can be not simple task when there are a lot of ffi-methods. 2017-08-17 13:17 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com>:
On Thu, Aug 17, 2017 at 1:09 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
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
But then you should compile such code with the old compiler, not make opal compatible, no?
2017-08-17 11:48 GMT+02:00 Esteban Lorenzano <estebanlm@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.durin@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-f
ailure-on-FFI-pragmas-declaration-in-Pharo-5-tp4961737.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
--
Guille Polito
Research Engineer
French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr>
*Web:* *http://guillep.github.io* <http://guillep.github.io>
*Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
On 17. Aug 2017, at 19:37, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hey!
Yes.
Also simple solution can be to override compiler of problem classes to return old compiler.
I know it is better to rewrite code but it can be not simple task when there are a lot of ffi-methods.
I ran into this problem with the wonderful (as it had a SHA256 implementation) NaCl bindings. Pharo5: * RBParser still has the currentScope variable and can import it * Syntax highlighting ends in an exception (which I disabled) Pharo6: * RBParser doesn't have currentScope anymore so I patched it out * Syntax highlighting seems to work fine @Esteban: Would you accept a change to the FFI-Pharo5Compat to not use the currentScope variable/reduce error checking? Or would you accept it in a FFI-Pharo6Compat package? I think it would help to be able to load the Nacl code in Pharo6 and then fix it? what do you think? holger
@Esteban: Would you accept a change to the FFI-Pharo5Compat to not use the currentScope variable/reduce error checking? Or would you accept it in a FFI-Pharo6Compat package? I think it would help to be able to load the Nacl code in Pharo6 and then fix it?
But you can just switch default compiler. Is not works for you? 2017-08-18 10:20 GMT+02:00 Holger Freyther <holger@freyther.de>:
On 17. Aug 2017, at 19:37, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hey!
Yes.
Also simple solution can be to override compiler of problem classes to return old compiler.
I know it is better to rewrite code but it can be not simple task when there are a lot of ffi-methods.
I ran into this problem with the wonderful (as it had a SHA256 implementation) NaCl bindings.
Pharo5: * RBParser still has the currentScope variable and can import it * Syntax highlighting ends in an exception (which I disabled)
Pharo6: * RBParser doesn't have currentScope anymore so I patched it out * Syntax highlighting seems to work fine
@Esteban: Would you accept a change to the FFI-Pharo5Compat to not use the currentScope variable/reduce error checking? Or would you accept it in a FFI-Pharo6Compat package?
I think it would help to be able to load the Nacl code in Pharo6 and then fix it?
what do you think?
holger
On 18. Aug 2017, at 16:46, Denis Kudriashov <dionisiydk@gmail.com> wrote:
@Esteban: Would you accept a change to the FFI-Pharo5Compat to not use the currentScope variable/reduce error checking? Or would you accept it in a FFI-Pharo6Compat package? I think it would help to be able to load the Nacl code in Pharo6 and then fix it?
But you can just switch default compiler. Is not works for you?
yes. But I think it gets more difficult in Pharo7? So being able to load old code to rewrite it would be nice. :) holger
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-t... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
On 8/17/17, bdurin <bruno.durin@gmail.com> wrote: Hello Bruno
Hi,
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.
Good to know that you can easily rewrite the bindings. In this case I suggest you load the ZeroMQ [1] into the last Pharo version which supports both variants. Good to have several Pharo installations available for such purposes. They normally 'live' in a subdirectory. Fix it the Pharo version which easily supports it and save the mcz file. Then load it into Pharo 6. And learn how to submit it to the Pharo 6.0 catalog repository. The whole process is not a big deal. Your contribution to upgrade the library is welcome! Regards Hannes [1] http://zeromq.org/
Hi Hannes, Thanks for your help! I agree that loading in Pharo 4 (I guess) and following your recipe works and is easy. My concern is not specific to ZeroMQ though. In fact I discovered that ZeroMQ package is just a very low-level bindings of Zeromq C API whereas I thought it was something more like the python bindings of 0mq that provides higher-level abstractions that are more useful. Besides the problem of persisting the state of a 0mq application in the image is quite hard to solve (and this was noted by the author of the Zeromq package). So I probably shall go with python this time. Beyond the specific problem of Zeromq package, I think there is something inconsistent in trying to develop Smalltalk/Pharo as a self-contained environment and not being able to load old code. In other languages, text editor or IDE are external tools but they usually open any source code. (That is why the title of my note is "Parser failure on FFI pragmas declaration in Pharo 5" and not "Cannot load ZeroMQ package source code".) I also wanted to point out that for people that are used to programming and as such could rapidly wander in corner areas of the language, I felt a tool / a procedure to manage dependencies and versions was missing. Regards, Bruno -- View this message in context: http://forum.world.st/Parser-failure-on-FFI-pragmas-declaration-in-Pharo-5-t... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Bruno There was a huge change in the FFI (in fact it was rewritten from the ground) and you face a case where we were not backward compatible. Nobody reported it to us before. Now if you unzip the mcz you get the pharo text in plain mode. It does not solve the problem of parsing but in that case you are exactly in the same situation than other languages or I did not understand your problem. We are managing version and dependencies since years :) luckily. The part that is missing is that every package loaded in the pharo image cannot be used as dependent for external packages because of lack of metadata. We are working on having metadata for any package (being inside Pharo or external). I do not know what is used in ZeroMQ. Now two questions: - what are the abstractions that the python binding offers? - what is the state of a 0mq application? Because we can serialise and reload execution stack. So the only things that we cannot serialize are active process so far. Stef On Tue, Aug 22, 2017 at 4:35 PM, bdurin <bruno.durin@gmail.com> wrote:
Hi Hannes,
Thanks for your help! I agree that loading in Pharo 4 (I guess) and following your recipe works and is easy. My concern is not specific to ZeroMQ though. In fact I discovered that ZeroMQ package is just a very low-level bindings of Zeromq C API whereas I thought it was something more like the python bindings of 0mq that provides higher-level abstractions that are more useful. Besides the problem of persisting the state of a 0mq application in the image is quite hard to solve (and this was noted by the author of the Zeromq package). So I probably shall go with python this time. Beyond the specific problem of Zeromq package, I think there is something inconsistent in trying to develop Smalltalk/Pharo as a self-contained environment and not being able to load old code. In other languages, text editor or IDE are external tools but they usually open any source code. (That is why the title of my note is "Parser failure on FFI pragmas declaration in Pharo 5" and not "Cannot load ZeroMQ package source code".) I also wanted to point out that for people that are used to programming and as such could rapidly wander in corner areas of the language, I felt a tool / a procedure to manage dependencies and versions was missing.
Regards, Bruno
-- View this message in context: http://forum.world.st/Parser-failure-on-FFI-pragmas-declaration-in-Pharo-5-t... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
On Tue, Aug 22, 2017 at 4:35 PM, bdurin <bruno.durin@gmail.com> wrote:
Hi Hannes,
Thanks for your help! I agree that loading in Pharo 4 (I guess) and following your recipe works and is easy. My concern is not specific to ZeroMQ though. In fact I discovered that ZeroMQ package is just a very low-level bindings of Zeromq C API whereas I thought it was something more like the python bindings of 0mq that provides higher-level abstractions that are more useful. Besides the problem of persisting the state of a 0mq application in the image is quite hard to solve (and this was noted by the author of the Zeromq package). So I probably shall go with python this time. Beyond the specific problem of Zeromq package, I think there is something inconsistent in trying to develop Smalltalk/Pharo as a self-contained environment and not being able to load old code. In other languages, text editor or IDE are external tools but they usually open any source code. (That is why the title of my note is "Parser failure on FFI pragmas declaration in Pharo 5" and not "Cannot load ZeroMQ package source code".) I also wanted to point out that for people that are used to programming and as such could rapidly wander in corner areas of the language, I felt a tool / a procedure to manage dependencies and versions was missing.
I am working on and off on an experiment to allow to load (and compile!) syntactically wrong code. (the idea is that it compiles a runtime error what would normally be a static syntax error, this is available by turning on the "Allow code with syntax errorsâ Setting). This might not solve the FFI problem (need to look at that), but it will make loading strange code easier⦠Marcus
Hi Marcus, I would be happy to contribute to your experiment. Let me know. Bruno -- View this message in context: http://forum.world.st/Parser-failure-on-FFI-pragmas-declaration-in-Pharo-5-t... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Tx for the report On Wed, Aug 16, 2017 at 11:31 PM, bdurin <bruno.durin@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-t... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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.self@gmail.com> wrote:
Tx for the report
On Wed, Aug 16, 2017 at 11:31 PM, bdurin <bruno.durin@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-t... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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-t... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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-t... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
participants (8)
-
bdurin -
Denis Kudriashov -
Esteban Lorenzano -
Guillermo Polito -
H. Hirzel -
Holger Freyther -
Marcus Denker -
Stephane Ducasse