February 2018 - Pharo-users

Re: [Pharo-users] Generate equality

by HernÃ¡n Morales Durand

Hi Herbert, How the "generate equality" behavior would be the default? Mechanically = non-interactive? Cheers, HernÃ¡n 2018-02-07 13:10 GMT-03:00 Herbert VojÄÃk <herby(a)mailbox.sk>: > Hi! > > Do you think it would be reasonable to have, a la "generate accessors" / > "generate initialize method", a "generate equality" thingie that would > generate #= and #hash for the method, mechanically? > > Just created a new "piece of data" class and felt like it would be helpful. > > Herby >

Feb. 8, 2018

[Newb Question] Single Nautilus window?

by Animosity

Is there a way to direct all Browse requests (context menu, Browse buttons in other dialogs, etc.) to a single Nautilus window instead of opening up a new one for each request? Thank you in advance. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 8, 2018

Re: [Pharo-users] [ANN] sentry.io (OSS error tracking platform) SDK

by Ben Coman

On 8 February 2018 at 03:26, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Thank you. It looks really nice. I enjoy every time I see Pharo integrated > with a "regular" tool for Devops. > > The only thing that concerns me is whether we should have a credentials > manager of some sort, I cannot stop worrying about saving the username and > password in plaintext, not only for Sentry. > Because of the way an Image persists data, leaking passwords and api keys when sharing an Image (e.g. for troubleshooting) is a concern. For my use case, since this api key is only sent to an ffi callout, my solution was to read the password from file into volatile memory so it disappears when the VM exits. See this line.... externalVolatileSecret := ExternalAddress gcallocate: externalSize . here... https://github.com/Traadh/bittrex/blob/master/src/Bittrex.package/BittrexAP… (of course, not my real api key) Such a custom solution is easy, but I've thought that something similar out of the box with a GUI tool to manage it would be valuable to many. cheers -ben > > Esteban A. Maringolo > > 2018-02-07 16:20 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >> Nice :) >> >> Do you send the stack? >> >> Stef >> >> On Tue, Feb 6, 2018 at 10:55 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >>> I guess the subject should say [ANN] too... :) >>> >>> >>> On Tue, Feb 6, 2018 at 10:55 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>> >>>> Hi, >>>> >>>> I've made an experimental SDK for sentry.io to track errors in >>>> end-user installations. >>>> >>>> Also usable as a Logger for Beacon (which I guess should be the primary >>>> way to use this). >>>> >>>> ... and as an extension for Debugger (basically a replacement for >>>> ShoreLine, which is too simplistic for my needs). >>>> >>>> https://github.com/peteruhnak/pharo-sentry >>>> >>>> [image: Inline image 1] >>>> >>>> Peter >>>> >>> >>> >> >

Feb. 8, 2018

Re: [Pharo-users] Workspace/Playground behavior change for unknown "bindings"?

by Holger Freyther

> On 7. Feb 2018, at 08:58, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Ok, pull request for Pharo7: > > https://github.com/pharo-project/pharo/pull/806 > > we should add that to Pharo6, too (Slice is already in the inbox) > lovely! Thank you!

Feb. 7, 2018

Re: [Pharo-users] [ANN] sentry.io (OSS error tracking platform) SDK

by Peter UhnÃ¡k

> Do you send the stack? yes, there is also option to send variable values, but it is not implemented yet > The only thing that concerns me is whether we should have a credentials manager of some sort, I cannot stop worrying about saving the username and password in plaintext, not only for Sentry. In case of sentry, there's also public DSN that I guess I should use instead... (I don't know if users can do anything destructive with the SDK password.) > For on-premise installations of sentry as well (probably yes, just asking to be sure - we use on-premise one, not cloud-hosted sentry.io directly). I assume their API is the same. I've used on-premises sentry (and wrote the SDK on day zero of using sentry.... so I am still learning how it even works :)) Peter On Wed, Feb 7, 2018 at 9:53 PM, Herbert VojÄÃk <herby(a)mailbox.sk> wrote: > > > Peter UhnÃ¡k wrote: > >> I guess the subject should say [ANN] too... :) >> >> On Tue, Feb 6, 2018 at 10:55 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com >> <mailto:i.uhnak@gmail.com>> wrote: >> >> Hi, >> >> I've made an experimental SDK for sentry.io <http://sentry.io> to >> track errors in end-user installations. >> > > For on-premise installations of sentry as well (probably yes, just asking > to be sure - we use on-premise one, not cloud-hosted sentry.io directly). > > Herby > > Also usable as a Logger for Beacon (which I guess should be the >> primary way to use this). >> >> ... and as an extension for Debugger (basically a replacement for >> ShoreLine, which is too simplistic for my needs). >> >> https://github.com/peteruhnak/pharo-sentry >> <https://github.com/peteruhnak/pharo-sentry> >> >> Inline image 1 >> >> Peter >> >> >> >

Feb. 7, 2018

Re: [Pharo-users] Generate equality

by Richard Sargent

On Wed, Feb 7, 2018 at 12:51 PM, Herbert VojÄÃk <herby(a)mailbox.sk> wrote: > > > Esteban A. Maringolo wrote: > >> I wouldn't start a flamewar on this, but being able to separate >> equality and identity is important. >> >> Otherwise we should have to remove #= or #== since of either is >> redundant. :) >> >> If you're dealing with ORM having a good implementation of #= is >> important, since you might have several instances representing the >> same "abstraction" (I wouldn't call it an object). Then you have to >> implement #hash as well. >> >> What is wrong most of the times is the implementation of #= and #hash >> itself. >> I remember that Eclipse for Java provides Herbert's required feature, >> where it can coherent equals() and hashcode() functions based on the >> attributes of your choice. >> >> Regards! >> >> Esteban A. Maringolo >> >> >> 2018-02-07 17:09 GMT-03:00 Norbert Hartl<norbert(a)hartl.name>: >> >>> I think that implementing = and hash is almost always wrong. So I guess >>> the answer is no :) >>> >> > Just as mechanically generated initializers / accessors are not always > directly what you want, you then change them later, but: it is helpful to > be able to generate the default version of them. > > I though the same for the #=/#hash pair. > > Never thought it would cause a flame (just a "is it important enough" > discussion)... > I agree it is important to have tools that help with commonly done operations. So, I'm generally in favour of making such a tool *available*. By default, generate comparisons of all the class's instance variables, inheriting non-Object implementations via super, when there are any. If there exists metadata for the instance variables, perhaps that metadata could be augment to indicate which instance variables are relevant to the object's uniqueness. And in such a case, the generator could restrict itself to such instance variables, by default. > > Herby > > Norbert >>> >>> Am 07.02.2018 um 17:10 schrieb Herbert VojÄÃk<herby(a)mailbox.sk>: >>>> >>>> Hi! >>>> >>>> Do you think it would be reasonable to have, a la "generate accessors" >>>> / "generate initialize method", a "generate equality" thingie that would >>>> generate #= and #hash for the method, mechanically? >>>> >>>> Just created a new "piece of data" class and felt like it would be >>>> helpful. >>>> >>>> Herby >>>> >>> >> >

Feb. 7, 2018

Re: [Pharo-users] [ANN] sentry.io (OSS error tracking platform) SDK

by Herbert VojÄÃk

Peter UhnÃ¡k wrote: > I guess the subject should say [ANN] too... :) > > On Tue, Feb 6, 2018 at 10:55 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com > <mailto:i.uhnak@gmail.com>> wrote: > > Hi, > > I've made an experimental SDK for sentry.io <http://sentry.io> to > track errors in end-user installations. For on-premise installations of sentry as well (probably yes, just asking to be sure - we use on-premise one, not cloud-hosted sentry.io directly). Herby > Also usable as a Logger for Beacon (which I guess should be the > primary way to use this). > > ... and as an extension for Debugger (basically a replacement for > ShoreLine, which is too simplistic for my needs). > > https://github.com/peteruhnak/pharo-sentry > <https://github.com/peteruhnak/pharo-sentry> > > Inline image 1 > > Peter > >

Feb. 7, 2018

Re: [Pharo-users] Generate equality

by Herbert VojÄÃk

Esteban A. Maringolo wrote: > I wouldn't start a flamewar on this, but being able to separate > equality and identity is important. > > Otherwise we should have to remove #= or #== since of either is redundant. :) > > If you're dealing with ORM having a good implementation of #= is > important, since you might have several instances representing the > same "abstraction" (I wouldn't call it an object). Then you have to > implement #hash as well. > > What is wrong most of the times is the implementation of #= and #hash itself. > I remember that Eclipse for Java provides Herbert's required feature, > where it can coherent equals() and hashcode() functions based on the > attributes of your choice. > > Regards! > > Esteban A. Maringolo > > > 2018-02-07 17:09 GMT-03:00 Norbert Hartl<norbert(a)hartl.name>: >> I think that implementing = and hash is almost always wrong. So I guess the answer is no :) Just as mechanically generated initializers / accessors are not always directly what you want, you then change them later, but: it is helpful to be able to generate the default version of them. I though the same for the #=/#hash pair. Never thought it would cause a flame (just a "is it important enough" discussion)... Herby >> Norbert >> >>> Am 07.02.2018 um 17:10 schrieb Herbert VojÄÃk<herby(a)mailbox.sk>: >>> >>> Hi! >>> >>> Do you think it would be reasonable to have, a la "generate accessors" / "generate initialize method", a "generate equality" thingie that would generate #= and #hash for the method, mechanically? >>> >>> Just created a new "piece of data" class and felt like it would be helpful. >>> >>> Herby >

Feb. 7, 2018

Re: [Pharo-users] Generate equality

by Esteban A. Maringolo

I wouldn't start a flamewar on this, but being able to separate equality and identity is important. Otherwise we should have to remove #= or #== since of either is redundant. :) If you're dealing with ORM having a good implementation of #= is important, since you might have several instances representing the same "abstraction" (I wouldn't call it an object). Then you have to implement #hash as well. What is wrong most of the times is the implementation of #= and #hash itself. I remember that Eclipse for Java provides Herbert's required feature, where it can coherent equals() and hashcode() functions based on the attributes of your choice. Regards! Esteban A. Maringolo 2018-02-07 17:09 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: > I think that implementing = and hash is almost always wrong. So I guess the answer is no :) > > Norbert > >> Am 07.02.2018 um 17:10 schrieb Herbert VojÄÃk <herby(a)mailbox.sk>: >> >> Hi! >> >> Do you think it would be reasonable to have, a la "generate accessors" / "generate initialize method", a "generate equality" thingie that would generate #= and #hash for the method, mechanically? >> >> Just created a new "piece of data" class and felt like it would be helpful. >> >> Herby >

Feb. 7, 2018

Re: [Pharo-users] Generate equality

by Norbert Hartl

I think that implementing = and hash is almost always wrong. So I guess the answer is no :) Norbert > Am 07.02.2018 um 17:10 schrieb Herbert VojÄÃk <herby(a)mailbox.sk>: > > Hi! > > Do you think it would be reasonable to have, a la "generate accessors" / "generate initialize method", a "generate equality" thingie that would generate #= and #hash for the method, mechanically? > > Just created a new "piece of data" class and felt like it would be helpful. > > Herby

Feb. 7, 2018