Pharo-dev
By thread
pharo-dev@lists.pharo.org
By month
Messages by month
- ----- 2026 -----
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- 5 participants
- 144618 messages
Catalog Browser timed out
by Ben Coman
When opening the Catalog Browser I am getting connection timed out.
Tested from two different Images:
* a fresh generator.image from running newImage.sh of the pharo-vm.
* my usual PharoLauncher image
cheers -ben
June 29, 2016
Re: [Pharo-dev] [squeak-dev] The .changes file should be bound to a single image
by David T. Lewis
Max,
Confirming on Linux and Squeak. See below.
On Wed, Jun 29, 2016 at 08:53:12AM +0200, Max Leske wrote:
>
> > On 29 Jun 2016, at 02:06, David T. Lewis <lewis(a)mail.msen.com> wrote:
> >
> > On Tue, Jun 28, 2016 at 04:47:00PM -0500, Chris Muller wrote:
> >>
> >> On Tue, Jun 28, 2016 at 5:04 AM, Max Leske <maxleske(a)gmail.com> wrote:
> >>> Hi,
> >>>
> >>> Opening the same image twice works fine as long as no writes to the .changes file occur. When both images write to the .changes file however it will be broken for both because the offsets for the changes are wrong. This can lead to lost data and predominantly to invalid method source code, which is a pain with Monticello.
> >>>
> >>> I suggest that we implement a kind of lock mechanism to ensure that only one image (the first one opened) can write to the .changes file.
> >>>
> >
> > If the offsets are wrong in this scenario, it's a bug in the image. The
> > image is supposed to seek to the end of the changes file before writing
> > the next chunk. While this sounds horrible in theory, in practice it works
> > remarkably well, and I have been happily surprised at how reliable it
> > is after many years of using and abusing the feature. That is a very
> > good thing.
> >
> > Adding a lock to prevent the scenario would be bad, because it would
> > surely break a number of other legitimate use cases.
> >
> >
> >>>
> >>> I???ve opened an issue for Pharo here: https://pharo.fogbugz.com/f/cases/18635/The-changes-file-should-be-bound-to…
> >>>
> >>
> >>
> >> I have several applications which launch multiple copies of the same
> >> image for multicore processing. The images do their work, commit it
> >> to database, then exit themselves without saving. Its a great
> >> feature.
>
> Doing work is not the problem. Modifying source code is the problem.
>
> >
> > That is consistent with my experience. I remember expecting horrible
> > things to happen if I had two images sharing a changes file, but nothing
> > bad ever happened. It just works.
> >
> >>
> >> I know OSProcess, when combined with CommandShell, has a RemoteTask
> >> which allows efficient forking of the image (via Linux copy-on-write
> >> memory sharing) and so a solution like what happens in Windows is not
> >> really good.
> >
> > My assumption with RemoteTask was that someone doing complex or long-running
> > jobs would more or less know what they were doing, and would have the good
> > sense to stop writing to the changes file from a bunch of forked images.
> > But in actual practice, I have never seen a problem related to this.
> > It just works.
> >
> >>
> >> Instead of putting a pop-up in front of the user, perhaps one way to
> >> solve the problem would be to, upon image save, simply goes through
> >> all the changes since the last save and re-flushes them to the
> >> .changes file.
> >>
> >> That way, if someone does want to save the same image on top of
> >> themself, at least it would be whichever saved last "wins"....
> >>
> >
> > There must be a problem somewhere, otherwise Max would not be raising
> > the issue. So whatever combination of operating system and image is
> > having a problem, I would be inclined fix that.
>
> :) Thanks Dave!
>
> >
> > Windows cannot be a problem, because the operating system will not
> > permit you to open the changes file twice. The Unix/Linux systems that
> > I have used all work fine.
> >
> > Max, which operating system/VM/image are you using? Is this on a Mac?
>
> Mac OS X 10.11.5,
> Pharo 6 (60086)
>
> >
> > Dave
> >
> >
>
> I actually didn???t open the issue for myself but because of a student who ran into this. I???ve been in the same situation before but I???m an experienced user while students at the research group sometimes just spend a couple of weeks with Pharo and then such things are a real problem.
>
> Interestingly the issue is, as you already suggested, pretty hard to reproduce i.e., modifying arbitrary methods in both images did not show the symptoms I was looking for.
>
> Here???s a reproducible case (at least on my machine):
>
> 1. create a new method in both images:
>
> foo
> ^ nil
>
> 2. Modify it in one image:
>
> foo
> "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum."
> ^ nil + 1
>
> 3. Modify it in the other image:
>
> foo
> ^ nil - 1 isEmpty ifTrue: [ "blah" nil ]
>
Confirmed on Linux + Squeak.
I did your test above using #forkSqueak so that I had two identical images
sharing the same changes file. In each image, I saved the #foo method. At
that point, the changes file conntained exactly what I would expect.
I then did a save and exit from the child image, followed by a save and exit
from the original image. I can see that the changes from the child image are
now overwriting the changes from the original parent image. Since the
parent image is the one that was saved last, its #foo method now has
corrupted source.
This is not a scenario that I have ever encountered, but I can see how
it might happen in a classroom setting.
I can't look into this further right now, but it seems possible that the
problem happens only when saving the image, in which case we could force
the changes file to seek to end of file before doing the save. But we'll
need to do some more testing to make sure that this is the only scenario
in which it happens.
Dave
> In my case saving in step three produces a syntax error when the source is loaded from file again. I don???t really have a clue as to what the underlying issue is, but I suspect it may have to do with comments and a particular situation in which the position is not being correctly updated before or after writing.
>
>
> I agree with Chris that locks may be problematic, it just seemed like the simplest obvious solution (although of course it gets complicated when an image crashes and doesn???t clean up the lock???).
>
> Cheers,
> Max
>
> >
>
June 29, 2016
[pharo-project/pharo-core]
by GitHub
Branch: refs/tags/60126
Home: https://github.com/pharo-project/pharo-core
June 29, 2016
[pharo-project/pharo-core] b5353c: 60126
by GitHub
Branch: refs/heads/6.0
Home: https://github.com/pharo-project/pharo-core
Commit: b5353c0c1e5a672f661df5c23e2a3af5488316c1
https://github.com/pharo-project/pharo-core/commit/b5353c0c1e5a672f661df5c2…
Author: Jenkins Build Server <board(a)pharo-project.org>
Date: 2016-06-29 (Wed, 29 Jun 2016)
Changed paths:
M Kernel.package/ManifestKernel.class/class/meta-data - dependency analyser/ignoredDependencies.st
A Kernel.package/Object.class/instance/message performing/perform_with_with_with_with_.st
M Kernel.package/PharoKernelAssembly.class/class/meta-data/parts.st
M Metacello-MC.package/MetacelloPackageSpec.class/instance/gofer/workingCopyNameFor_.st
A Rubric-Tests.package/RubAbstractTextAreaTest.class/README.md
A Rubric-Tests.package/RubAbstractTextAreaTest.class/definition.st
A Rubric-Tests.package/RubEditingAreaTest.class/README.md
A Rubric-Tests.package/RubEditingAreaTest.class/definition.st
A Rubric-Tests.package/RubEditingAreaTest.class/instance/convenience/sendDoubleClickAt_withShift_.st
A Rubric-Tests.package/RubEditingAreaTest.class/instance/convenience/sendMouseClickAt_withShift_.st
A Rubric-Tests.package/RubEditingAreaTest.class/instance/convenience/setSelectionFrom_to_text_.st
A Rubric-Tests.package/RubEditingAreaTest.class/instance/instance creation/newCharacterBlockIndex_text_.st
A Rubric-Tests.package/RubEditingAreaTest.class/instance/running/setUp.st
A Rubric-Tests.package/RubEditingAreaTest.class/instance/tests-accessing selection/testMarkBlockPointBlock.st
A Rubric-Tests.package/RubEditingAreaTest.class/instance/tests-accessing selection/testModifySelection.st
A Rubric-Tests.package/RubEditingAreaTest.class/instance/tests-accessing selection/testMouseClickShiftClick.st
A Rubric-Tests.package/RubEditingAreaTest.class/instance/tests-accessing selection/testMouseMoveAfterDoubleClick.st
M Rubric.package/RubAbstractTextArea.class/instance/event handling/mouseMove_.st
A SUnit-UITesting.package/extension/Morph/instance/simulateClickWith_position_.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60125.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60126.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60125.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60126.st
M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
Log Message:
-----------
60126
18624 SlotIntegrationTest>>testSlotScopeParallelism
https://pharo.fogbugz.com/f/cases/18624
18637 Do not use #name method call in MetacelloPackageSpec>>#workingCopyNameFor:
https://pharo.fogbugz.com/f/cases/18637
18634 add Object>>perform:with:with:with:with (4 arguments)
https://pharo.fogbugz.com/f/cases/18634
18347 Extending current selection after double click does not work
https://pharo.fogbugz.com/f/cases/18347
18604 update kernel manifest
https://pharo.fogbugz.com/f/cases/18604
http://files.pharo.org/image/60/60126.zip
June 29, 2016
[pharo-project/pharo-core]
by GitHub
Branch: refs/tags/60125
Home: https://github.com/pharo-project/pharo-core
June 29, 2016
[pharo-project/pharo-core] 04eff1: 60125
by GitHub
Branch: refs/heads/6.0
Home: https://github.com/pharo-project/pharo-core
Commit: 04eff10a77cbb9349621a50e67c776d751d45492
https://github.com/pharo-project/pharo-core/commit/04eff10a77cbb9349621a50e…
Author: Jenkins Build Server <board(a)pharo-project.org>
Date: 2016-06-29 (Wed, 29 Jun 2016)
Changed paths:
A AST-Core.package/RBMethodNode.class/instance/accessing/selectorAndArgumentNames.st
A AST-Core.package/RBProgramNode.class/instance/testing/isLastStatementInBlock.st
A AST-Tests-Core.package/RBMethodNodeTest.class/README.md
A AST-Tests-Core.package/RBMethodNodeTest.class/definition.st
A AST-Tests-Core.package/RBMethodNodeTest.class/instance/tests/testSelectorAndArgumentNames.st
A FileSystem-Core.package/FileLocator.class/class/origins/localDirectory.st
A FileSystem-Core.package/SystemResolver.class/class/accessing/defaultLocalDirectoryName.st
A FileSystem-Core.package/SystemResolver.class/class/accessing/userLocalDirectory.st
A FileSystem-Core.package/SystemResolver.class/class/accessing/userLocalDirectory_.st
A FileSystem-Core.package/SystemResolver.class/class/settings/settingsOn_.st
M FileSystem-Core.package/SystemResolver.class/definition.st
A FileSystem-Core.package/SystemResolver.class/instance/origins/localDirectory.st
M FileSystem-Core.package/SystemResolver.class/instance/resolving/supportedOrigins.st
A FileSystem-Tests-Core.package/FileLocatorTest.class/instance/resolution tests/testLocalDirectory.st
A FileSystem-Tests-Core.package/SystemResolverTest.class/instance/testing/testLocalDirectory.st
M GT-Playground.package/GTPlayBook.class/class/accessing-defaults/defaultCacheDirectory.st
M GT-Playground.package/GTPlayBook.class/class/accessing-defaults/defaultStashDirectory.st
A Glamour-Morphic-Brick.package/GLMBrick.class/instance/brick-structure-testing/isFirstInOwner.st
A Glamour-Morphic-Brick.package/GLMBrick.class/instance/brick-structure-testing/isLastInOwner.st
M Monticello.package/MCCacheRepository.class/class/defaults/defaultDirectory.st
M Ombu.package/OmSessionStore.class/class/accessing/defaultBaseLocator.st
A Refactoring-Critics.package/RBDeadBlockRule.class/README.md
A Refactoring-Critics.package/RBDeadBlockRule.class/class/accessing/uniqueIdentifierName.st
A Refactoring-Critics.package/RBDeadBlockRule.class/definition.st
A Refactoring-Critics.package/RBDeadBlockRule.class/instance/accessing/group.st
A Refactoring-Critics.package/RBDeadBlockRule.class/instance/accessing/name.st
A Refactoring-Critics.package/RBDeadBlockRule.class/instance/accessing/rationale.st
A Refactoring-Critics.package/RBDeadBlockRule.class/instance/accessing/severity.st
A Refactoring-Critics.package/RBDeadBlockRule.class/instance/initialization/initialize.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60124.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60125.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60124.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60125.st
M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
Log Message:
-----------
60125
18640 Rule for "Dead" Blocks
https://pharo.fogbugz.com/f/cases/18640
18613 New RBMethodNode method to return the selector and argument names portion of a method
https://pharo.fogbugz.com/f/cases/18613
18600 create "pharo-local" to concentrate pharo local files (package-cache, epicea-sessions, etc.)
https://pharo.fogbugz.com/f/cases/18600
http://files.pharo.org/image/60/60125.zip
June 29, 2016
Re: [Pharo-dev] Having comments for pragma?
by stepharo
On Tue, Jun 28, 2016 at 8:53 PM, stepharo <stepharo(a)free.fr> wrote:
>
>> When I implemented annotation support I was initially thinking the
>> same - let's create an instance of CoolAnnotationClass when the code
>> is accepted
>> and then one can add arbitrary code to his CoolAnnotationClass. I
>> quickly realized this is a (very) bad idea. Or, to be precise, it is
>> a bad idea given the
>> environment. So I'd be very careful..
> can you explain your statement?
Let me try, this is tricky for me as I'm not good at explaining :-)
The problems pop out when one need to load the code back. If <coolish:
100> gets parsed and stored in
an annotation container as instance of class Coolish (at compilation
time), this means that you just
introduced a dependency from package of the method which contains the
annotation to the package of
Coolish class. This is not (or rather was not in my case) desirable,
because I need/want to annotate
methods in kernel with annotations for tools. Kernel should not depend
or tools - I believe we agree on
that :-) Note, that this is less of a problem for Java since Java loads
all code lazily, on demand and in a defined
way. I personally found it very nice - though it has some (solvable?)
issues when this lazy loading is used in Smalltalkish
environment such as STX:LIBJAVA)
You can indeed parse them and store them as raw data and convert them
on demand in reflective
API. Then, if the class is not available what to do? Return an instance
of generic Pragma?
Throw an error? When one starts to put an arbitrary code into the
annotation object itself it's either
processing code only access data or it somehow fiddles about the
annotation itself and/or (worse!)
about the method itself. The latter results in difficult to debug
problems as the time the code is executed
is undefined (if you use lazy instantiation to avoid dependency
problem). This may be fine with
most Smalltalkers as there are other pieces of code that execute
randomly in an undefined order and still
very few complain :-) but I did not want to make things even worse.
For the former, mere data-accessing processing code, I don't see much
of a difference by putting it
somwhere else. Follows the same logic as visitor, instead of putting
code to nodes, you put them
to extra visitor class.
Eliot's design elegantly avoid these problems (the same way Java does
:-) by simply having one defined
structure which keeps the logical type of the annotation as data (the
selector of the message send).
It has other problems, but not the one above.
Not sure if it makes sense, but I did my best :-) I'm not saying it's
not solvable and you cannot have
class per annotation type, but it is not **that** easy to get it right.
This is my experience over the years.
HTH, Jan
>
>
> Stef
>
>
>>
>> Jan
>>
>> P.S.: As for "which always forced me to hate Java": I found myself a
>> very enlightening to think carefully about why somebody else
>> do things differently before I start to hate her/him. Besides,
>> there's whole lot of things that Java guys got right...
>>
>>
>
June 29, 2016
Re: [Pharo-dev] Become Identity Forward
by tesonep@gmail.com
Thanks for your answer, very clarifying.
On Mon, Jun 27, 2016 at 7:48 PM, Eliot Miranda <eliot.miranda(a)gmail.com>
wrote:
> Hi,
>
> I don't see the bug. Look at this example:
>
> | a b ha hb |
> a := Object new.
> b := Object new.
> ha := a identityHash.
> hb := b identityHash.
> a becomeForward: b copyHash: true.
> { ha = hb. a == b. a identityHash == ha }. #(false true true)
>
> So here a has indeed become b; all references to a are now references to
> b. But b's identityHash is now that of what a's was before the become.
> That's as specified.
>
> Let's extend the example:
>
> | a b ha hb is |
> a := Object new.
> b := Object new.
> is := IdentitySet new.
> *is add: b.*
> ha := a identityHash.
> hb := b identityHash.
> a becomeForward: b copyHash: true.
> { ha = hb. a == b. a identityHash == ha. *is includes: a* }. #(false true
> true false)
>
> This is correct; a (and b) is (are) now in the set at the old hash of b,
> which is no longer its hash. So...
>
> | a b ha hb is |
> a := Object new.
> b := Object new.
> is := IdentitySet new.
> is add: b.
> ha := a identityHash.
> hb := b identityHash.
> a becomeForward: b copyHash: true.
> *is rehash.*
> { ha = hb. a == b. a identityHash == ha. is includes: a }. #(false true
> true true)
>
> Good.
>
> So instead what you might have meant to say was
>
> | a b ha hb is |
> a := Object new.
> b := Object new.
> is := IdentitySet new.
> *is add: a.*
> ha := a identityHash.
> hb := b identityHash.
> a becomeForward: b copyHash: true.
> { ha = hb. a == b. a identityHash == ha. is includes: a }. #(false true
> true true)
>
> That looks good.
>
> On Mon, Jun 27, 2016 at 2:50 AM, tesonep(a)gmail.com <tesonep(a)gmail.com>
> wrote:
>
>> Hello,
>> I'm trying to become forward some objects, these objects are
>> stored in IdentitySets so I need to copy the identityHash of the older
>> objects to the new ones. So that the IdentitySets are still well
>> constructed.
>>
>> I have read the comments in Array >> elementsForwardIdentityTo: copyHash:
>> , and Array >> elementsForwardIdentityTo:, so I realise that the operation
>> I want to use is the first with copyHash in true or the later (that should
>> be doing the same, from the comments).
>>
>> But after trying it, it is not working as expected.
>>
>> If I try with:
>>
>> x := Object new.
>> y := Object new.
>> z := Object new.
>>
>> set := IdentitySet new.
>> set add: x.
>> set add: y.
>>
>> hash := x identityHash.
>> bhash := x basicIdentityHash.
>>
>> self assert:(set isHealthy).
>>
>> z becomeForward: x copyHash: true.
>>
>> set isHealthy "false"
>>
>> z basicIdentityHash = bhash. "false"
>> z identityHash = hash "false"
>>
>> It is not working, but if I changed the copyHash parameter to false, it
>> works.
>>
>> Something is not right (the comment or the implementation), because the
>> comment says:
>>
>> "If copyHash is true, the identityHashes remain with the pointers rather
>> than with the
>> objects so that the objects in the receiver should still be properly
>> indexed in any
>> existing hashed structures after the mutation. If copyHash is false,
>> then the hashes
>> of the objects in otherArray remain unchanged."
>>
>> Do I have understanded everything wrong or there is something that is not
>> working (or at least the comment is not clear)
>>
>> Is somebody using these operations? How do you expect to work?
>>
>> Maybe If you can help me to understand the situation I can fix the
>> comments.
>>
>> Thanks in advance.
>>
>> --
>> Pablo Tesone.
>> tesonep(a)gmail.com
>>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
--
Pablo Tesone.
tesonep(a)gmail.com
June 29, 2016
Re: [Pharo-dev] Random number generator bug?
by Sven Van Caekenberghe
I would also think we have some unit tests that validate the random generator.
> On 29 Jun 2016, at 10:07, Max Leske <maxleske(a)gmail.com> wrote:
>
> Same here of OS X 10.11 in Pharo 6. Not reproducible.
>
> Max
>
>> On 29 Jun 2016, at 09:34, Ben Coman <btc(a)openInWorld.com> wrote:
>>
>> On Windows 7, I tried two case and could not reproduce this.
>>
>> 1. Pharo-40611
>> C:\#Pharo\Pharo4.0\Pharo.exe
>> NBCoInterpreter NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid:
>> e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014
>> NBCogit NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid:
>> e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014
>>
>> Note the same VM as yours
>>
>> 2. Pharo-50554
>> C:\#Pharo\PharoSpur\Pharo.exe
>> CoInterpreter VMMaker.oscog-eem.1630 uuid:
>> 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 14 2016
>> StackToRegisterMappingCogit VMMaker.oscog-eem.1630 uuid:
>> 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 14 2016
>> https://github.com/estebanlm/pharo-vm.git Commit:
>> 21ec004cce7d26010c18d357c805a0e1a4ffe376 Date: 2016-01-14 11:42:33
>> +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #498
>>
>> Could you try some other combinations of machine/VM/image?
>>
>> cheers -ben
>>
>> On Wed, Jun 29, 2016 at 12:15 PM, Benoit St-Jean via Pharo-dev
>> <pharo-dev(a)lists.pharo.org> wrote:
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Benoit St-Jean <bstjean(a)yahoo.com>
>>> To: Pharo Development List <pharo-dev(a)lists.pharo.org>
>>> Cc:
>>> Date: Wed, 29 Jun 2016 04:13:57 +0000 (UTC)
>>> Subject: Random number generator bug?
>>> I'm having problems understanding why the Integer>>#atRandom sometimes return a number greater than the receiver.
>>>
>>> This problem only occurs when forking processes that generate random number using the above mentioned method. Obviously, all processes share the same RNG from the Collection class.
>>>
>>> Code below can reproduce (most of the time) the bug.
>>>
>>> | n |
>>> n := 3172918.
>>> 5 timesRepeat: [ [n timesRepeat: [ | alea |
>>> alea := n atRandom.
>>> (alea > n) ifTrue: [ self halt]]] forkAt: Processor userBackgroundPriority ].
>>>
>>> I'm on Windows 10, Pharo4.0 Latest update: #40627.
>>>
>>> Pertinent System Reporter info below:
>>>
>>> Virtual Machine
>>> ---------------
>>> F:\Pharo4\Pharo4.0\Pharo.exe
>>> NBCoInterpreter NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014
>>> NBCogit NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014
>>> https://github.com/pharo-project/pharo-vm.git Commit: 81b5d19917dcb78f22482a780deec48c53738396 Date: 2014-09-20 14:36:18 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14858
>>>
>>> Win32 built on Sep 25 2014 17:47:04 Compiler: 4.6.2
>>> VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: 81b5d19917dcb78f22482a780deec48c53738396 Date: 2014-09-20 14:36:18 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14858
>>> NBCoInterpreter NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014
>>> NBCogit NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014
>>>
>>> Loaded VM Modules
>>> -----------------
>>> B2DPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> BitBltPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> FT2Plugin Freetype-Plugin-IgorStasenko.64 (e)
>>> FilePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> FloatArrayPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> JPEGReadWriter2Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> Kernel32
>>> LargeIntegers v1.5 VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> LocalePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> Matrix2x3Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> MiscPrimitivePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> NativeBoostPlugin NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 (i)
>>> SecurityPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> ZipPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>>
>>> VM Built-in Modules
>>> -------------------
>>> ADPCMCodecPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> AsynchFilePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> B2DPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> B3DAcceleratorPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> BMPReadWriterPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> BitBltPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> CroquetPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> DSAPrims VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> DropPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> FFTPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> FilePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> FloatArrayPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> FloatMathPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> HostWindowPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> IA32ABI VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> JPEGReadWriter2Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> JPEGReaderPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> JoystickTabletPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> Klatt VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> LargeIntegers v1.5 VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> LocalePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> MIDIPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> Matrix2x3Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> MiscPrimitivePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> Mpeg3Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> NativeBoostPlugin NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 (i)
>>> RePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> SecurityPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> SerialPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> SocketPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> SoundCodecPrims VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> SoundPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> StarSqueakPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> SurfacePlugin Sep 25 2014 (i)
>>> UUIDPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> Win32OSProcessPlugin VMConstruction-Plugins-OSProcessPlugin.oscog-EstebanLorenzano.43 (i)
>>> ZipPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>>
>>> VM Configuration
>>> ----------------
>>> F:\Pharo4\Pharo4.0\Pharo.ini
>>> [Global]
>>> DeferUpdate=1
>>> ShowConsole=0
>>> DynamicConsole=1
>>> ReduceCPUUsage=0
>>> ReduceCPUInBackground=0
>>> 3ButtonMouse=0
>>> 1ButtonMouse=0
>>> UseDirectSound=1
>>> PriorityBoost=0
>>> B3DXUsesOpenGL=0
>>> CaseSensitiveFileMode=0
>>>
>>> Operating System/Hardware
>>> -------------------------
>>> Win32 6.2 IX86
>>>
>>> Hardware Details
>>> ----------------
>>> Hardware information:
>>> Manufacturer: Unknown
>>> Model: Unknown
>>> Number of processors: 4
>>> Page size: 4096
>>>
>>> Memory Information (upon launch):
>>> Physical Memory Size: 2097151 kbytes
>>> Physical Memory Free: 2097151 kbytes
>>> Page File Size: 4194303 kbytes
>>> Page File Free: 4194303 kbytes
>>> Virtual Memory Size: 2097024 kbytes
>>> Virtual Memory Free: 2015568 kbytes
>>> Memory Load: 45 percent
>>>
>>> Processor 0: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz
>>> Identifier: Intel64 Family 6 Model 94 Stepping 3
>>> ~MHZ: 2712
>>>
>>> Processor 1: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz
>>> Identifier: Intel64 Family 6 Model 94 Stepping 3
>>> ~MHZ: 2712
>>>
>>> Processor 2: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz
>>> Identifier: Intel64 Family 6 Model 94 Stepping 3
>>> ~MHZ: 2712
>>>
>>> Processor 3: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz
>>> Identifier: Intel64 Family 6 Model 94 Stepping 3
>>> ~MHZ: 2712
>>>
>>> Graphics Hardware Details
>>> -------------------------
>>> Display Information:
>>> Graphics adapter name: Intel(R) HD Graphics 530
>>> Primary monitor resolution: 1280 x 720
>>>
>>> Device: ???
>>> Adapter String: Intel(R) HD Graphics 530
>>> Bios String: Intel Video BIOS
>>> Chip Type: Intel(R) HD Graphics Family
>>> DAC Type: Internal
>>> Memory Size: 0x40000000
>>>
>>> Driver Versions:
>>> igdumdim64:
>>>
>>>
>>>
>>>
>>>
>>> -----------------
>>> Benoît St-Jean
>>> Yahoo! Messenger: bstjean
>>> Twitter: @BenLeChialeux
>>> Pinterest: benoitstjean
>>> Instagram: Chef_Benito
>>> IRC: lamneth
>>> Blogue: endormitoire.wordpress.com
>>> "A standpoint is an intellectual horizon of radius zero". (A. Einstein)
>>>
>>
>
>
June 29, 2016
Re: [Pharo-dev] Random number generator bug?
by Max Leske
> On 29 Jun 2016, at 10:07, Max Leske <maxleske(a)gmail.com> wrote:
>
> Same here of OS X 10.11 in Pharo 6. Not reproducible.
Same for Pharo 4. Are you sure thereâs not another process that uses the generator unprotected?
>
> Max
>
>> On 29 Jun 2016, at 09:34, Ben Coman <btc(a)openInWorld.com> wrote:
>>
>> On Windows 7, I tried two case and could not reproduce this.
>>
>> 1. Pharo-40611
>> C:\#Pharo\Pharo4.0\Pharo.exe
>> NBCoInterpreter NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid:
>> e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014
>> NBCogit NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid:
>> e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014
>>
>> Note the same VM as yours
>>
>> 2. Pharo-50554
>> C:\#Pharo\PharoSpur\Pharo.exe
>> CoInterpreter VMMaker.oscog-eem.1630 uuid:
>> 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 14 2016
>> StackToRegisterMappingCogit VMMaker.oscog-eem.1630 uuid:
>> 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 14 2016
>> https://github.com/estebanlm/pharo-vm.git Commit:
>> 21ec004cce7d26010c18d357c805a0e1a4ffe376 Date: 2016-01-14 11:42:33
>> +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #498
>>
>> Could you try some other combinations of machine/VM/image?
>>
>> cheers -ben
>>
>> On Wed, Jun 29, 2016 at 12:15 PM, Benoit St-Jean via Pharo-dev
>> <pharo-dev(a)lists.pharo.org> wrote:
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Benoit St-Jean <bstjean(a)yahoo.com>
>>> To: Pharo Development List <pharo-dev(a)lists.pharo.org>
>>> Cc:
>>> Date: Wed, 29 Jun 2016 04:13:57 +0000 (UTC)
>>> Subject: Random number generator bug?
>>> I'm having problems understanding why the Integer>>#atRandom sometimes return a number greater than the receiver.
>>>
>>> This problem only occurs when forking processes that generate random number using the above mentioned method. Obviously, all processes share the same RNG from the Collection class.
>>>
>>> Code below can reproduce (most of the time) the bug.
>>>
>>> | n |
>>> n := 3172918.
>>> 5 timesRepeat: [ [n timesRepeat: [ | alea |
>>> alea := n atRandom.
>>> (alea > n) ifTrue: [ self halt]]] forkAt: Processor userBackgroundPriority ].
>>>
>>> I'm on Windows 10, Pharo4.0 Latest update: #40627.
>>>
>>> Pertinent System Reporter info below:
>>>
>>> Virtual Machine
>>> ---------------
>>> F:\Pharo4\Pharo4.0\Pharo.exe
>>> NBCoInterpreter NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014
>>> NBCogit NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014
>>> https://github.com/pharo-project/pharo-vm.git Commit: 81b5d19917dcb78f22482a780deec48c53738396 Date: 2014-09-20 14:36:18 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14858
>>>
>>> Win32 built on Sep 25 2014 17:47:04 Compiler: 4.6.2
>>> VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: 81b5d19917dcb78f22482a780deec48c53738396 Date: 2014-09-20 14:36:18 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14858
>>> NBCoInterpreter NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014
>>> NBCogit NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014
>>>
>>> Loaded VM Modules
>>> -----------------
>>> B2DPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> BitBltPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> FT2Plugin Freetype-Plugin-IgorStasenko.64 (e)
>>> FilePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> FloatArrayPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> JPEGReadWriter2Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> Kernel32
>>> LargeIntegers v1.5 VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> LocalePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> Matrix2x3Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> MiscPrimitivePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> NativeBoostPlugin NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 (i)
>>> SecurityPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> ZipPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>>
>>> VM Built-in Modules
>>> -------------------
>>> ADPCMCodecPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> AsynchFilePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> B2DPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> B3DAcceleratorPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> BMPReadWriterPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> BitBltPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> CroquetPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> DSAPrims VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> DropPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> FFTPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> FilePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> FloatArrayPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> FloatMathPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> HostWindowPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> IA32ABI VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> JPEGReadWriter2Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> JPEGReaderPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> JoystickTabletPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> Klatt VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> LargeIntegers v1.5 VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> LocalePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> MIDIPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> Matrix2x3Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> MiscPrimitivePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> Mpeg3Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> NativeBoostPlugin NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 (i)
>>> RePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> SecurityPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> SerialPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> SocketPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> SoundCodecPrims VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> SoundPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> StarSqueakPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> SurfacePlugin Sep 25 2014 (i)
>>> UUIDPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>> Win32OSProcessPlugin VMConstruction-Plugins-OSProcessPlugin.oscog-EstebanLorenzano.43 (i)
>>> ZipPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i)
>>>
>>> VM Configuration
>>> ----------------
>>> F:\Pharo4\Pharo4.0\Pharo.ini
>>> [Global]
>>> DeferUpdate=1
>>> ShowConsole=0
>>> DynamicConsole=1
>>> ReduceCPUUsage=0
>>> ReduceCPUInBackground=0
>>> 3ButtonMouse=0
>>> 1ButtonMouse=0
>>> UseDirectSound=1
>>> PriorityBoost=0
>>> B3DXUsesOpenGL=0
>>> CaseSensitiveFileMode=0
>>>
>>> Operating System/Hardware
>>> -------------------------
>>> Win32 6.2 IX86
>>>
>>> Hardware Details
>>> ----------------
>>> Hardware information:
>>> Manufacturer: Unknown
>>> Model: Unknown
>>> Number of processors: 4
>>> Page size: 4096
>>>
>>> Memory Information (upon launch):
>>> Physical Memory Size: 2097151 kbytes
>>> Physical Memory Free: 2097151 kbytes
>>> Page File Size: 4194303 kbytes
>>> Page File Free: 4194303 kbytes
>>> Virtual Memory Size: 2097024 kbytes
>>> Virtual Memory Free: 2015568 kbytes
>>> Memory Load: 45 percent
>>>
>>> Processor 0: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz
>>> Identifier: Intel64 Family 6 Model 94 Stepping 3
>>> ~MHZ: 2712
>>>
>>> Processor 1: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz
>>> Identifier: Intel64 Family 6 Model 94 Stepping 3
>>> ~MHZ: 2712
>>>
>>> Processor 2: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz
>>> Identifier: Intel64 Family 6 Model 94 Stepping 3
>>> ~MHZ: 2712
>>>
>>> Processor 3: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz
>>> Identifier: Intel64 Family 6 Model 94 Stepping 3
>>> ~MHZ: 2712
>>>
>>> Graphics Hardware Details
>>> -------------------------
>>> Display Information:
>>> Graphics adapter name: Intel(R) HD Graphics 530
>>> Primary monitor resolution: 1280 x 720
>>>
>>> Device: ???
>>> Adapter String: Intel(R) HD Graphics 530
>>> Bios String: Intel Video BIOS
>>> Chip Type: Intel(R) HD Graphics Family
>>> DAC Type: Internal
>>> Memory Size: 0x40000000
>>>
>>> Driver Versions:
>>> igdumdim64:
>>>
>>>
>>>
>>>
>>>
>>> -----------------
>>> Benoît St-Jean
>>> Yahoo! Messenger: bstjean
>>> Twitter: @BenLeChialeux
>>> Pinterest: benoitstjean
>>> Instagram: Chef_Benito
>>> IRC: lamneth
>>> Blogue: endormitoire.wordpress.com
>>> "A standpoint is an intellectual horizon of radius zero". (A. Einstein)
>>>
>>
>
June 29, 2016