|Anonymous | Login||01-23-2020 19:44 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Advanced Details [ Jump to Notes ]||[ View Simple ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0007393||[Squeak Packages] Cryptography||minor||always||09-02-09 15:12||03-11-11 01:41|
|Reporter||nicolas cellier||View Status||public|
|Summary||0007393: Avoid #mousePoint to make cryptography Pharo-friendly|
I suggest to replace:
so as to be Pharo-compatible.
|Steps To Reproduce|
|Attached Files||Cryptography-DanielLyons.37.mcz [^] (239,684 bytes) 03-11-11 01:40|
(0014060 - 2202 - 2610 - 2738 - 2738 - 2738 - 2738)
Any source for Entropy is optional. The more we have the better. You will notice that there are a number of different sources for entropy. #responsdsTo: is probably what you are looking for. Adding a source that is comparable in Pharo that is missed by Squeak and leaving one that works in Squeak that is missed by Pharo is a very good solution, in my opinion. Since the methods really only collect a seed they are called very infrequently. Adding a check for respondsTo: will not harm performance in any significant way.
All the best,
> -----Original Message-----
> From: Daniel Lyons [mailto:email@example.com]
> Sent: Thursday, March 10, 2011 2:10 AM
> To: Ron Teitelbaum
> Subject: Re: Cryptography package
> On Mar 9, 2011, at 9:22 PM, Ron Teitelbaum wrote:
> > Hi Daniel,
> > The issues is probably from the changes in Pharo vs. Squeak. I would
> > imagine that the change is in Random where we are gathering entropy to
> > try to seed the generator. The best thing to do is file a bug on
> > mantis at bugs.squeak.org. I'm not exactly sure how to tell if I'm on
> > Pharo or on Squeak but it would be nice to be able to support both.
> > You could upload your patch to the bug.
> There's already an issue for it: http://bugs.squeak.org/view.php?id=7393 [^]
> The code is in RandomGenerator as you supposed. I'll see if I can figure out
> how to tell which kind of image code is loaded into. Sensor cursorPoint
> doesn't do the same things as Sensor mousePoint, apparently, which is a
> shame because Squeak has this method too. I think the selector we actually
> want in Pharo is peekMousePt, which also returns a point that changes when
> I move the mouse. I don't know how to do this, but I believe it should be
> possible to look for the existence of this method and not the other at
> package load time and patch it.
> In thinking about it though, I'm not sure it's a good idea to rely on this
> anyway, since there's not going to be a mouse position in a headless session
> such as on a server anyway. Is there? Forgive me, I'm very new at Smalltalk!
> Thanks again!
> Daniel Lyons
(0014069 - 180 - 192 - 192 - 192 - 192 - 192)
This patch uses mousePoint if it can, or peekMousePt if that doesn't work. Otherwise it uses 0@0. That should make it reasonably portable.
Tested under Pharo 1.1 and Squeak 4.2.
|09-02-09 15:12||nicolas cellier||New Issue|
|03-10-11 14:44||Ron||Note Added: 0014060|
|03-11-11 01:40||DanielLyons||File Added: Cryptography-DanielLyons.37.mcz|
|03-11-11 01:41||DanielLyons||Note Added: 0014069|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
39 total queries executed.|
30 unique queries executed.