August 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Encoding Login information in your image (safely)

by Dimitris Chloupis

I am clueless when it comes to encryption and safety , so as you would expect I will offer my opinion on this. I do not think that encryption from the side of Pharo would be a good idea because having the image you have access to everything . Including any kind of context even its not stored in a variable. I think the safest way is not to use Pharo and do this in C and put this in a DLL which Pharo cannot access other than calling its functions. This way you can be certain that the user has no way to hack the data unless of course its disassemble the DLL and inspect the memory but that would be much harder than do it in Pharo. Of course an average Pharo user/coder does not have this technical knowledge , sometime we cannot even figure out UFFI problems but a determined hacker wont have an issue disassembling the DLL (reading the machine code). Of course you could use one of the countless security libraries for C from Pharo using UFFI. But yeah personally I would not allow Pharo to have any kind of access to that information just call DLL function that will reply only if a yes/no about the success of the login attempt. The rest I would leave it to my DLL and the C security library. But then I am not a believer of safety of any kind. Life is very unsafe but of course its wise to try to make it safer :) On Wed, Aug 16, 2017 at 7:55 PM Tim Mackinnon <tim(a)testit.works> wrote: > Hi - Iâm struggling to find something that I saw that discussed this issue > kind of. > > In my image (its actually a headless one - but this could apply to a fat > image too) - I build an application that needs access to a service (in > this case an S3 bucket). > > The AWS library Iâm using (but others are similar) has an AWSLogin class > singleton where I can specify a username and password. So in a playground I > can do that and test it all works etc. > > However, for deployment its never a good idea to encode this info into > your code (particularly if you use Iceberg and GitHub) - SO, I am using > secret variable support in GitLab - which Iâve seen many projects do in > other languages. This way, I type in those details into an encrypted place > in the CI and it then exposes them as temporary variables when I build my > system (so far so good). > > Now in my build - I run a little script like this and pass on those > variables (neatly, Gitlab doesnât show their values in its logs): > > ./pharo Pharo.image --no-default-preferences --save --quit st config.st \ > *"{**â**$USER'. â$PWD'}"* > > > In config.st I then extract these command line parameters (the ST handler > nicely exposes the extra parameter array so I didnât have to do anything > custom) > > "Expect image to be called with params as a last arg array" > config := Array readFrom: Smalltalk arguments last. > *user* := config at: 1. > *pwd* := config at: 2. > > DBConfig default > accessKey: user; > pKey: pwd; > yourself. > > So it all looks pretty good so far - however it occurs to me that if you get hold of a .image and were to browse all of the Strings - e.g. > > ./pharo Pharo.image eval "(ByteString allInstances)â > > I think you would ulimtately find those strings unless the Class encrypts them in some way right? > > So Iâm wondering why we donât have an EncryptedString object for just this (Iâve seen lots of cryptography libraries etc), but isnât this quite a common thing to deal with? And should Pharo provide something that library writers adopt to encourage better image safety? Or am I wrong in my analysis? > > > Tim > > >

Aug. 17, 2017

Re: [Pharo-users] Parser failure on FFI pragmas declaration in Pharo 5

by Denis Kudriashov

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(a)gmail.com>: > > > On Thu, Aug 17, 2017 at 1:09 PM, Denis Kudriashov <dionisiydk(a)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(a)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(a)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> >

Aug. 17, 2017

Re: [Pharo-users] Parser failure on FFI pragmas declaration in Pharo 5

by bdurin

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-… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 17, 2017

Loading and saving packages to filetree repos

by Luke Gorrie

Hoi, I want to have a quick "cheat mode" for loading and saving the Smalltalk packages in my project. This is to make life easy for newbies who are not very familiar with Monticello and Metacello. The "cheat" is to assume that there is one filetree:// repository that contains all of the relevant packages, and all we need to do is load or save each of those packages in that repository. I have the loading part working already: repo := MCFileTreeRepository new directory: '/foo/bar/baz' asFileReference. repo allFileNames do: [ :file | (repo versionFromFileNamed: file) load. ]. but now I am wondering how to do the saving part? That is, given a path to a filetree repo like '/foo/bar/baz', how do I save each package in that repo i.e. export the code in the image? Ideally I would like the same operation to skip metadata that is likely to cause conflicts when the code is checked into Git later e.g. package timestamps and versions. Tips would be appreciated :).

Aug. 17, 2017

Re: [Pharo-users] Parser failure on FFI pragmas declaration in Pharo 5

by Guillermo Polito

On Thu, Aug 17, 2017 at 1:09 PM, Denis Kudriashov <dionisiydk(a)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(a)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(a)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

Aug. 17, 2017

Re: [Pharo-users] Parser failure on FFI pragmas declaration in Pharo 5

by Denis Kudriashov

> 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(a)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(a)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. > > > > >

Aug. 17, 2017

Re: [Pharo-users] Preference to for not showing hidden files in the FileBrowser?

by Guillermo Polito

On Wed, Aug 16, 2017 at 1:26 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > Hello > > Is there a preference for not showing hidden files in the FileBrowser? > I don't think such preference exists, sorry... Maybe implementing it would not be so hard? > I checked menu 'System' -> 'Settings' searching for 'hidden'. > This is on Ubuntu, i.e. hidden files start with a dot. > > Thank you for the answer in advance > > Hannes > > -- 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

Aug. 17, 2017

Re: [Pharo-users] What is proper fix for this?

by Esteban Lorenzano

> On 17 Aug 2017, at 11:34, jtuchel(a)objektfabrik.de wrote: > > Am 17.08.17 um 11:31 schrieb Esteban Lorenzano: >>> On 17 Aug 2017, at 11:28, jtuchel(a)objektfabrik.de wrote: >>> >>> Herby, >>> >>> back when Alan was maintaining Glorp, he took care for portability, he even maintained the port to VA Smalltalk, IIRC. Niall and Tim(?) at Cincom also try not to break any dialect in their changes and they also work on keeping things portable. I am not sure there ever was any (semi-)automated process to keep ports in sync, my guess would be that that is not the case. >>> >>> What I am very sure of is that the ppl at Cincom would welcome any volunteers to support them in keeping things portable and improve the ecosystem for this. >>> Is any of you going to be at ESUG? >> I will, but I will not maintain Glorp portâ¦ I have just too much work :) > Same for me. I am not a regular Pharo user, so I cannot do it. yeahâ¦ too bad :( âunofficial maintainerâ of Glorp port is Esteban Maringolo. But since he has to make a living (and right now he is working on VW, not Pharo), he cannot do it but lightly. Other maintainers should be the people using it, so the addition of Herby is welcome (Esteban M. will check at when he has timeâ¦ but at least now is available for other people to check). I myself keep track of my own beast: Voyageâ¦ but thankfully I can just check time to time since we have a small but active community around it. Ideal situation for Glorp would be having the same. cheers! Esteban > > > Joachim > > >> > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > >

Aug. 17, 2017

Re: [Pharo-users] Parser failure on FFI pragmas declaration in Pharo 5

by Esteban Lorenzano

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(a)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-… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Aug. 17, 2017

Re: [Pharo-users] What is proper fix for this?

by jtuchel＠objektfabrik.de

Am 17.08.17 um 11:31 schrieb Esteban Lorenzano: >> On 17 Aug 2017, at 11:28, jtuchel(a)objektfabrik.de wrote: >> >> Herby, >> >> back when Alan was maintaining Glorp, he took care for portability, he even maintained the port to VA Smalltalk, IIRC. Niall and Tim(?) at Cincom also try not to break any dialect in their changes and they also work on keeping things portable. I am not sure there ever was any (semi-)automated process to keep ports in sync, my guess would be that that is not the case. >> >> What I am very sure of is that the ppl at Cincom would welcome any volunteers to support them in keeping things portable and improve the ecosystem for this. >> Is any of you going to be at ESUG? > I will, but I will not maintain Glorp portâ¦ I have just too much work :) Same for me. I am not a regular Pharo user, so I cannot do it. Joachim > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Aug. 17, 2017