- Pharo-users - lists.pharo.org

Dark Mode
by horrido Aug. 29, 2017

Aug. 29, 2017

I found this interesting article <https://hackernoon.com/apple-and-others-need-a-dark-mode-for-people-like-mo…> . I wanted to express my opinion... Dark mode looks cool and all, but it does have a downside. I was very happy with the normal Pharo 5.0 look, but when Pharo 6.0 came out with its dark theme, I was rather put off by it. For me, at least, the dark theme makes it harder to read the text. Too bad Pharo isn't themable. -- View this message in context: http://forum.world.st/Dark-Mode-tp4964409.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

16 39

constraining dragging movement of Morph Windows
by Peter UhnÃ¡k Aug. 28, 2017

Aug. 28, 2017

Hi, is it possible to somehow "constraint" the movement of windows (Nautilus, Playground, ..., SystemWindow, ...)? E.g. I want for them to only move (or "snap") only at steps of e.g. 20 pixels. So sort of snap-to-20-pixel-grid behavior. Thanks, Peter

2 1

[ANN] Pharo wiki , is here
by Dimitris Chloupis Aug. 28, 2017

Aug. 28, 2017

Many seemed to like the idea of a Pharo wiki , I like it too. I created one, can be found here and super easy to contribute to. https://github.com/SquareBracketAssociates/PharoWiki Will keep this thread for alerting for important updates to wiki. Have fun :)

6 39

Metalinks UI... ?
by Steven Costiou Aug. 28, 2017

Aug. 28, 2017

Hi, i think somebody told me (i do not remember who) that an other somebody (whose name i don't remember either) made a very basic UI for metalink creation or management. Would somebody know of such project and where to find it ? Thanks, Steven.

2 5

How do I get at the Morphic halos in Pharo 6.0?
by H. Hirzel Aug. 28, 2017

Aug. 28, 2017

On 8/28/17, phil(a)highoctane.be <phil(a)highoctane.be> wrote: .... > > Dark theme : can code for hours without any trouble. > > At the office I am at now 90% of coders are using dark themes. > > Indeed the windows buttons are annoying, I have my own little hack to make > them better. > When a control bugs you, bring a halo and try to reverse the form, usually > makes things readable. > > Phil Phil, I was not aware that it is still possible to get Morphic halos in Pharo 6.0? How do I get at them? Regards Hannes

3 3

Re: [Pharo-users] Validate password with PBKDF2
by Udo Schneider Aug. 28, 2017

Aug. 28, 2017

Francis, I can relate to the idea of easily embedding PBKDF2/bcrypt into your code. However the functionality of /managing/ the salt is not specificed in PBKDF2. The spec only covers the actual the hashing part. However wrapping it into a simple to use wrapper is pretty simple. The code below is something I use in my code for example: "Create a new password instance" pwd := KNPassword fromPlaintext: 'secret'. "Now store that instance. It encapsulates hash, generated salt and the load parameter. Because all the load parameters are accessed via methods you can also back them with ivars and have different instances with different load parameters. E.g. for adapting to advances in hash cracking." pwd verify: 'secret'. "Verify the password" CU, Udo 'From Pharo5.0 of 16 April 2015 [Latest update: #50772] on 1 July 2017 at 10:01:05.207245 am'! Object subclass: #KNPassword instanceVariableNames: 'salt hash' classVariableNames: 'PRNG' poolDictionaries: '' category: 'ThreatNews-Core'! !KNPassword methodsFor: 'accessing' stamp: 'UdoSchneider 5/26/2017 11:48'! salt ^ salt ifNil: [ salt := ((1 to: self saltLength) collect: [ :each | self class prng nextInt: 255 ]) asByteArray ]! ! !KNPassword methodsFor: 'accessing' stamp: 'UdoSchneider 7/1/2017 09:58'! iterations ^ 1000! ! !KNPassword methodsFor: 'accessing' stamp: 'UdoSchneider 7/1/2017 09:58'! length ^ 64! ! !KNPassword methodsFor: 'accessing' stamp: 'UdoSchneider 7/1/2017 09:58'! saltLength ^ 16! ! !KNPassword methodsFor: 'accessing' stamp: 'UdoSchneider 7/1/2017 09:57'! hashClass ^ SHA256! ! !KNPassword methodsFor: 'as yet unclassified' stamp: 'UdoSchneider 5/26/2017 11:51'! setPlaintext: aString hash := self hashString: aString! ! !KNPassword methodsFor: 'as yet unclassified' stamp: 'UdoSchneider 5/26/2017 11:52'! verify: aString ^ (self hashString: aString) = hash! ! !KNPassword methodsFor: 'as yet unclassified' stamp: 'UdoSchneider 5/26/2017 11:51'! hashString: aString ^ PBKDF2 derivedKeyHashFunction: self hashClass password: aString salt: self salt iterations: self iterations length: self length! ! "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! KNPassword class instanceVariableNames: ''! !KNPassword class methodsFor: 'as yet unclassified' stamp: 'UdoSchneider 5/26/2017 11:49'! reset PRNG := nil! ! !KNPassword class methodsFor: 'as yet unclassified' stamp: 'UdoSchneider 5/26/2017 11:49'! fromPlaintext: aString ^ self new setPlaintext: aString; yourself! ! !KNPassword class methodsFor: 'as yet unclassified' stamp: 'UdoSchneider 5/26/2017 11:49'! prng ^ PRNG ifNil: [ PRNG := Random new ]! !

3 4

Pharo Group for System Browser
by Trussardi Dario Romano Aug. 28, 2017

Aug. 28, 2017

Ciao, i work with Pharo 4.0 and with the relative System Browser. My goal is to define a group where i add all definition: Package ( CMD n-e-p ) Class ( CMD n-e-c ) Protocol ( CMD n--e-t ????? ) Method ( CMD n-e-m ) relative to a specific problematic ( when i development - management it ). Into Pharo 4.0 this command works with some problem ( they do not always work as you expect ) I do some test with the Pharo 6.1 and seems that the group handle only the Package reference add. Anyone can give me directions about it? How i can 'group' some reference ( Package - Class - Method ) into the System Browser to have control to all the method relative a specific problematic ? I forget something? Thanks, Dario

1 0

This sentence made my day [WAS] Re: Dark Mode
by Mariano Martinez Peck Aug. 28, 2017

Aug. 28, 2017

On Sun, Aug 27, 2017 at 6:50 PM, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > I agree with Dimitris - it is all a matter of preference - not all eyes > are the same. For myself, I find the default dark theme in Pharo very > uncomfortable. On my system, some elements have a black foreground on a > dark grey background, which is almost impossible to see. This is always > true of the maximise/minimise/close buttons, but sometimes also of text > fields in a playground. Whenever I download a new image, I immediately > switch to the Watery theme, with light background and nice coloured buttons > on the windows. > > Of course, my eyes may not be typical. I am now aged 84, and I have had > cataract operations on both eyes. My sight is actually quite good - my > optometrist confirms that I am legal to drive without spectacles - but my > adverse reaction to dark mode is strong and immediate. > > Sometimes is hard to explain to someone outside the community why Smalltalkers love they language so much. I think above paragraph says it all. It made my day. I wish I can follow that path! hahaha. > Just my 2p worth > > Peter Kenny > > -----Original Message----- > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf > Of stephan > Sent: 27 August 2017 21:46 > To: pharo-users(a)lists.pharo.org > Subject: Re: [Pharo-users] Dark Mode > > On 27-08-17 22:37, Dimitris Chloupis wrote: > > White or dark is a matter of preference. But the matter of preference > > is also a matter of biology . Not all eyes are same. > > The research is pretty clear: a large majority of developers does better > with light themes. I have been sufficiently clear on the choice to make > Pharo6 theme dark default > > Stephan > > > > -- Mariano http://marianopeck.wordpress.com

1 0

Parser failure on FFI pragmas declaration in Pharo 5
by bdurin Aug. 27, 2017

Aug. 27, 2017

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.

8 18

Copy bitmap to clipboard
by Hilaire Aug. 27, 2017

Aug. 27, 2017

Hi, A Dr. Geo user asked me about copying a DrGeo canvas view in the system clipboard, to past it in other tools as a text writer or any other editing tool. I looked in Pharo3 and Pharo6, I found text clipboard operation but it is not clear if there is support for other format? What about primAddClipboardData:data:dataFormat: I would like to copy and paste the DrGeo canvas as PNG content. -- Dr. Geo http://drgeo.eu

3 2