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

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

by Herby VojÄÃk

jtuchel(a)objektfabrik.de wrote: > Herby, > > my ccomments were not meant to say you are not competent enough to fix > Glorp. I know you have been active as the maintainer of Amber for quite > a while now and know you are an experienced Smalltalker. So this is not Not really. Actually, never did any production-ready project in Smalltalk. The one I do now is the first time. > an attempt to make you look incompetent or "unqualified". > > I just wanted to point out that > > * I think that if there is a bug in Glorp, it should be communicated > to the maintainers in order to make sure the fix is making it into > newer Glorp versions and from there to all dialects that have a port Yeah, sure. But Esteban's mail suggested that it is a long process, so maybe it _is_ beneficial to try to shortcut the fix at Pharo side. Don't know the local politics, so can't say myself. > of Glorp (Smalltalk is too much of a niche to be able to stand more > and more niche-ification of forks and stuff, esp. for such a central > part as Glorp which are way too important to only be maintained by > one or two developers - which they unfortunately are, at least to my > knowledge) :-( > * I am not sure if anybody from Cincom is listening here looking for > Glorp problems, so I saw/see the danger of "private" fixes / forks > * I fixed a few bugs in Glorp in the past just to find out that the > concept was correct but the place to fix it was wrong (or at least > would not heal all related problems). Glorp is complex and it has > lots of layers. It is a good example of the "avoid responsibility" > concept that was once (what a coincidence) formulated by Alan Knight > in an article named "All I've learned about object orientation I > learnt from Dilbert" (or similar) - so I was gad Niall looked into Yeah, the classic (that is, for me; lots of ppl out there do not know it, though they should). > these and gave me feedback as well as a "full" fix Yeah, that would be nice. > So I mainly ask you to post your fix and problem description to the > Glorp Mailing list / Google group. It would be a pity if your fix is I posted (that is, I tried to; I hope it got there). Maybe I should reply there with a few more words... or find out if it got there in the first place. > buried in some fork of Glorp. > > Joachim Herby

Aug. 17, 2017

Re: [Pharo-users] GTInspect auto-update in raw view?

by Esteban Lorenzano

> On 17 Aug 2017, at 01:02, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Hello Esteban, > > You can enable auto-refresh with: GTInspector enableStepRefresh > For performance reasons it is disabled by default. If you are curious why I think Andrei could explain a bit more :) I want to know why is disabled and more than that, when will we be able to make it enabled by default, as before. Esteban > > Cheers, > Alex > > On 17 August 2017 at 00:56, Esteban A. Maringolo <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> wrote: > Hi all, > > Is there a way to enable the auto-update of instance variables display in the GTInspector? > > There are cases where the instance is nil, I then initialize it somehow, but the variable is still displayed as nil. > > I know there is an "Update" button, which BTW should be labeled "refresh" instead, to do it manually, but hey, this is Smalltalk, we invented MVC :D > > We can consider the previous as a feature, but what I think it is a bug is that if the variable is nil, and later it is initialized, nil is still displayed, but when clicked the nodes below it shows the variables of the new object in the instance variable. > > E.g. > <image.png> > > Is this a bug or a feature? > > Regards! > > Esteban A. Maringolo >

Aug. 17, 2017

Re: [Pharo-users] Loading PharoJS Re: PharoJS

by Nicolai Hess

Hi Pierce 2017-06-25 13:07 GMT+02:00 Pierce Ng <pierce(a)samadhiweb.com>: > Just tried loading PharoJS with this snippet: > > Gofer it > smalltalkhubUser: 'noury' project: 'PharoJS'; > configuration; > loadStable > > Loaded cleanly on a fresh 32-bit Pharo-50772 image. Ran almost half the > tests > during which it created/deleted tabs on my open Chromium browser > repeatedly. > Then the tests started a new instance of my default browser (which happens > to > be Midori) and here seemingly the web socket stuff didn't work so well, so > I > aborted the tests, but this I attribute to Midori not PharoJS. > > On a fresh 64-bit Pharo-60501 image, while loading > PharoJSBridge-NouryBouraqadi-120, error encountered: > > SyntaxError: Variable or expression expected > Object as yet unclassified makeInspect > > makeInspect. > Variable or expression expected-><javascript: 'blah blah > blah blah > }'> > > I think the problem is the '.' dot after the selector name. This is not valid code for a method definition. I think this was an error on this parser to allow the code in the first place. Now we "fixed" the parser to indicate this as an error. Of course it would be good to replace / fix the method definition right on this debugger window, and move on with loading th code. But I am afraid this does not work. So, someone (with an older Pharo version where this code gets compiled) need to load the package and fix the method > Closing the error alert box brought up a debugger at > RBParser>>parserError:. > > Any idea what to fix, anyone? > > Pierce > > >

Aug. 17, 2017

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

by jtuchel＠objektfabrik.de

Herby, my ccomments were not meant to say you are not competent enough to fix Glorp. I know you have been active as the maintainer of Amber for quite a while now and know you are an experienced Smalltalker. So this is not an attempt to make you look incompetent or "unqualified". I just wanted to point out that * I think that if there is a bug in Glorp, it should be communicated to the maintainers in order to make sure the fix is making it into newer Glorp versions and from there to all dialects that have a port of Glorp (Smalltalk is too much of a niche to be able to stand more and more niche-ification of forks and stuff, esp. for such a central part as Glorp which are way too important to only be maintained by one or two developers - which they unfortunately are, at least to my knowledge) * I am not sure if anybody from Cincom is listening here looking for Glorp problems, so I saw/see the danger of "private" fixes / forks * I fixed a few bugs in Glorp in the past just to find out that the concept was correct but the place to fix it was wrong (or at least would not heal all related problems). Glorp is complex and it has lots of layers. It is a good example of the "avoid responsibility" concept that was once (what a coincidence) formulated by Alan Knight in an article named "All I've learned about object orientation I learnt from Dilbert" (or similar) - so I was gad Niall looked into these and gave me feedback as well as a "full" fix So I mainly ask you to post your fix and problem description to the Glorp Mailing list / Google group. It would be a pity if your fix is buried in some fork of Glorp. Joachim Am 16.08.17 um 20:02 schrieb Herby VojÄÃk: > Esteban A. Maringolo wrote: >> Herby, >> >> Please apologize I can't take the time to look into your code. > > Np, if someone eventually will. > >> I granted you write access to >> <http://smalltalkhub.com/#!/~DBXTalk/Glorp/>, could you upload your >> latter version to it? > > Uploaded. > >> Regards! >> Esteban A. Maringolo > > P.S.: I did not gain understanding of Glorp innards in that small > amount of time, of course, but I went by the intuition that at the > place I made the fix, the normal (base class, Mapping >>) behaviour is > to convert the right sides of the relation, and the only subclass > which has it overridden, namely DirectMapping, seems to do the same > thing (when looking at the code), just in an optimized way. Except, it > does not convert, which I believe, strongly, to be a bug left out > while doing that optimization. > > Herby > > -- ----------------------------------------------------------------------- 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] GTInspect auto-update in raw view?

by Aliaksei Syrel

Hello Esteban, You can enable auto-refresh with: GTInspector enableStepRefresh For performance reasons it is disabled by default. If you are curious why I think Andrei could explain a bit more :) Cheers, Alex On 17 August 2017 at 00:56, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Hi all, > > Is there a way to enable the auto-update of instance variables display in > the GTInspector? > > There are cases where the instance is nil, I then initialize it somehow, > but the variable is still displayed as nil. > > I know there is an "Update" button, which BTW should be labeled "refresh" > instead, to do it manually, but hey, this is Smalltalk, we invented MVC :D > > We can consider the previous as a feature, but what I think it is a bug is > that if the variable is nil, and later it is initialized, nil is still > displayed, but when clicked the nodes below it shows the variables of the > new object in the instance variable. > > E.g. > [image: ImÃ¡genes integradas 1] > > Is this a bug or a feature? > > Regards! > > Esteban A. Maringolo >

Aug. 16, 2017

GTInspect auto-update in raw view?

by Esteban A. Maringolo

Hi all, Is there a way to enable the auto-update of instance variables display in the GTInspector? There are cases where the instance is nil, I then initialize it somehow, but the variable is still displayed as nil. I know there is an "Update" button, which BTW should be labeled "refresh" instead, to do it manually, but hey, this is Smalltalk, we invented MVC :D We can consider the previous as a feature, but what I think it is a bug is that if the variable is nil, and later it is initialized, nil is still displayed, but when clicked the nodes below it shows the variables of the new object in the instance variable. E.g. [image: ImÃ¡genes integradas 1] Is this a bug or a feature? Regards! Esteban A. Maringolo

Aug. 16, 2017

Parser failure on FFI pragmas declaration in Pharo 5

by bdurin

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

Aug. 16, 2017

Re: [Pharo-users] How to find where pharo is killing processor power?

by Sven Van Caekenberghe

Are you using VNC ? > On 16 Aug 2017, at 21:03, sergio ruiz <sergio.rrd(a)gmail.com> wrote: > > > hey all.. my current pharo implementation is running super serious processor power, but it shouldnât be doing much. > > <Activity_Monitor__All_Processes__and_Pharo_image.jpg> > > how would I go about tracking this inside the pharo image? > > Thanks! > > > ---- > peace, > sergio > photographer, journalist, visionary > > Public Key: http://bit.ly/29z9fG0 > #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV > http://www.Village-Buzz.com > http://www.ThoseOptimizeGuys.com > http://www.coffee-black.com > http://www.painlessfrugality.com > http://www.twitter.com/sergio_101 > http://www.facebook.com/sergio101

Aug. 16, 2017

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

by Tim Mackinnon

Todd, i think you are right, I can't get around it - I need to pass something from my live environment (where it's kept encrypted) into my image. I can however potentially simplify the setup by passing a single key that I can use to unlock a PasswordVault in my image and it can have multiple values which I can then use for my different api keys. When creating my image, I can encode those values in a less hostile environment and pass them through like I do now, where they get stored in the PasswordVault. This seems pretty simple now I talk it through. Thanks to everyone for additional ideas - it's useful to know it's not a simple X thing that I've missed. Tim Sent from my iPhone > On 16 Aug 2017, at 19:41, Todd Blanchard <tblanchard(a)mac.com> wrote: > > I do a lot of deployments on AWS elastic beanstalks. > > I put the credentials into environment variables on the beanstalk. > > When running locally, the credentials are in the environment on my machine. > >> On Aug 16, 2017, at 9:55 AM, 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. 16, 2017

How to find where pharo is killing processor power?

by sergio ruiz

hey all.. my current pharo implementation is running super serious processor power, but it shouldnât be doing much. how would I go about tracking this inside the pharo image? Thanks! ---- peace, sergio photographer, journalist, visionary Public Key:Â http://bit.ly/29z9fG0 #BitMessageÂ BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.Village-Buzz.com http://www.ThoseOptimizeGuys.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

Aug. 16, 2017