- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Random is not random at startup

by stepharo

> > Though this only works on Unix, so on Windows it uses the current time > as a seed. It might get better results using #microsecondClockValue > instead of #millisecondClockValue. And I'd think about just taking the > microsecond value and sending it #hashMultiply instead of the weird > things it's doing now. (bitXor with the identity hash of the > UUIDGenerator instance? That depends on the randomness of identity > hashes, which may or may not be very good.) > It seems likely that Windows has a built-in random number generator, > as well, which would probably be better. > > While we're at it, the class Random is a Park-Miller generator, which > has quite poor randomness by modern standards. Most other Smalltalks > have upgraded -- GemStone uses CMWC (pure Smalltalk, very simple and > quite fast; I wrote that one), VW I believe uses Lagged Fibonacci, and > Squeak has moved to Mersenne Twister last I heard. I've tested all > three against statistical tests of randomness -- generated about 650GB > of random bytes from each, ran them through the tests (which require > that much data to get good statistics). > > All three are pretty good, only failing a few tests. The only > generator I tested that passed *all* tests was Linux /dev/urandom. > Which is also fast. If you're on Linux, and don't need a repeatable > random sequence, I'd use /dev/urandom. If you do need to be able to > have a repeatable sequence with good randomness properties, I'd use > one of the three generators I mentioned above. Of the three, the > simplest and fastest is CMWC. In Polymath random there are several alternate random generators but I do not if there is CMWC > > Regards, > > -Martin > >

May 21, 2016

Re: [Pharo-dev] the fastest way to load external code

by Peter UhnÃ¡k

> For example, one place I look at is SystemAnnouncer uniqueInstance, and I know that I should have no Nautilus open and that I can disable Renraku and GTExample: You can just do this and not worry about subscribers SystemAnnouncer uniqueInstance suspendAllWhile: (I was trying to speed up code generation so I did some benchmarks last year http://forum.world.st/fast-subclassing-class-creation-in-tests-tp4857779p48… ) Also couple weeks back I found out that adding instance variable to a class is extremely slow and it's best to add them during the initial setup, but maybe that isn't a problem here. Peter On Sat, May 21, 2016 at 9:50 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I am looking for ways to make loading of code from an st file faster. To > this end, I would like to find in-image mechanisms that are not mandatory > for obtaining a functional image. > > For example, one place I look at is SystemAnnouncer uniqueInstance, and I > know that I should have no Nautilus open and that I can disable Renraku and > GTExample: > > ReRuleManager uniqueInstance unsubscribe. > GTExampleOrganizer instance stopSystemAnnouncements. > > What else do you see around? > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "Don't give to get. Just give." > > > > > > > >

May 21, 2016

Re: [Pharo-dev] TEXT drag and drop

by stepharo

Le 21/5/16 Ã 16:02, Thierry Goubier a Ã©crit : > Le 21/05/2016 15:58, stepharo a Ã©crit : >> How can I see the effects of your changes? > > Install both packages that are in that smalltalkhub archive, I did that even before asking. > and try dragging a text selection. I have no idea how to do this. > > At least, that process works for PluggableTextMorph. > > Nice demonstration of both the drag and drop api and the text api, > because it's even nicely undoable in the editor :) > > Thierry > >> >> Stef >> >> >> Le 18/5/16 Ã 19:09, lb a Ã©crit : >>> Hi, >>> I have made a little tool for draging and dropping text selection. >>> like windows Word. >>> It can work in Pharo 40 50 and 60. >>> >>> Have a fun! >>> >>> LiangBing >>> >>> MCHttpRepository >>> location: >>> 'http://www.smalltalkhub.com/mc/liangbing/Text-DragDrop/main' >>> user: '' >>> password: '' >>> >>> >>> >> > > >

May 21, 2016

Re: [Pharo-dev] Should we updated UpdatedPharoByExample for Pharo 5?

by stepharo

but the current version is not about pharo40 but 50. Le 21/5/16 Ã 18:29, Cyril Ferlicot D. a Ã©crit : > Le 21/05/2016 15:56, stepharo a Ã©crit : >> Hi cyril >> >> >> I think that we should find the right balance between details that are >> specific to a version and stable parts. >> >> Now I target Pharo 50. I think that the focus of Pharo 60 should be on >> external (new tools) but on stabilisation, speed up and >> >> cleanup (and internal things like bootstrap). >> >> Stef >> > Ok, so if nobody disagree I think we should tag the current version as > Pharo 4. Mark the current Jenkins build as "Always keep artefact" and > publish a link on the book's page. > > I can do the two first steps but not the last. >

May 21, 2016

the fastest way to load external code

by Tudor Girba

Hi, I am looking for ways to make loading of code from an st file faster. To this end, I would like to find in-image mechanisms that are not mandatory for obtaining a functional image. For example, one place I look at is SystemAnnouncer uniqueInstance, and I know that I should have no Nautilus open and that I can disable Renraku and GTExample: ReRuleManager uniqueInstance unsubscribe. GTExampleOrganizer instance stopSystemAnnouncements. What else do you see around? Cheers, Doru -- www.tudorgirba.com www.feenk.com "Don't give to get. Just give."

May 21, 2016

Re: [Pharo-dev] [Vm-dev] Aw: Minutes of the Meeting to Discuss Moving Cog to Github

by Eliot Miranda

On Fri, May 20, 2016 at 6:22 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > > Cool to see that happen now. Future now looks even brighter. > Big, big thanks to anyone who was/is involved!!! > > Some questions: > > 1. Whoever has access for Squeak: is it planned to update > http://www.squeakvm.org with that info? > Thanks for the reminder. We will make that happen. > 2. Will http://www.mirandabanda.org/files/Cog/VM/ stay and get updated > with binaries or will > these be hosted on GitHub in the future as well? > I expect everything will migrate to Github. But hopefully links can be designed so that links from mirandabanda.org point to the relevant artefacts on github.com/OpenSmalltalk/vm. > 3. Is there any effect on http://files.pharo.org/vm/ ? > > Bye > T. > > *Gesendet:* Freitag, 20. Mai 2016 um 19:28 Uhr > *Von:* "Eliot Miranda" <eliot.miranda(a)gmail.com> > *An:* "Squeak Virtual Machine Development Discussion" < > vm-dev(a)lists.squeakfoundation.org> > *Cc:* "newspeaklanguage(a)googlegroups.com" < > newspeaklanguage(a)googlegroups.com>, "Discussion of Cuis Smalltalk" < > cuis-dev(a)cuis-smalltalk.org>, "Discusses Development of Pharo" < > pharo-dev(a)lists.pharo.org>, "The general-purpose Squeak developers list" < > squeak-dev(a)lists.squeakfoundation.org> > *Betreff:* [Pharo-dev] Minutes of the Meeting to Discuss Moving Cog to > Github > Hi All, > > here are the minutes of, and action items arising from, the meeting on > Wednesday 18th of May to discuss moving the Cog svn repository to Github. > Please read if you're interested and discuss on vm-dev. The major decision > for the community to participate in is when to make the change, which we > hope will happen in the next few weeks. Thanks to all who attended the > meeting and to all who have helped in making this a reality. This is > exciting! > > > VM Move to Github Meeting Notes > > The name of the organisation and repository was agreed to be, and has been > created as > > Organisation name: OpenSmalltalk > > Repository name: vm > > URL: github.com/OpenSmalltalk/vm > > > Administration duties: > > - > > Tim Felgentreff, David Lewis, Esteban Lorenzano, Eliot Miranda > > > > We decided to have everyone who currently has access to SVN also get write > access to the new repository. > > > There will be a master branch that is stable and from which releases are > made using tags. Only administrators integrate into that branch. Ongoing > development will be on a âdevâ branch. This should also be kept stable for > collaboration purposes, but breakage can happen occasionally. Contributors > working on larger changes will do so on separate branches to avoid > conflicts/breaking other peopleâs code. > > > Every commit will be tested by Travis (and Appveyor for Windows). Builds > and tests will be run for Windows, Linux, and OS X, both on 32-bit, 64-bit, > and ARM (as applicable). The master will only ever be merged with green > commits. The dev branch should be green, and if something breaks, but the > committer has no access or no time to fix it, we agreed that any > administrator may roll back the breaking change using git revert. This way, > the breaking change is preserved in the history, but the current HEAD is > green. We will also disable âforce-pushingâ to the repository to ensure > that no commit history can be tampered with. > > > In case of any disagreements about reverting other peopleâs code, we > declared Eliot (*) to be the arbiter. > > > Release tags on the master will trigger Travis to build release artifacts, > including debian packages. > > > To have incremental monotonic, human-readable version identifiers, we > decided to use timestamps in the form YYYYMMDDHHmm in UTC. In order to > ensure these timestamps are included in the sources, we will have a commit > script in the repository that any contributor must use to update the dev > and master branches (**). The checkout command for any version then becomes > âgit checkout branch@{timestamp}â. Both the built VMs via a -version > flag, and sources via a header file, will be marked with these timestamps. > > > It was decided to leave the build system as-is using GNU Makefiles where > available with a commitment to move to GNU Makefiles on Linux. We will use > CMake to produce per-platform config files that identify platform > facilities (such as epoll(2) vs kqueue(2) vs poll(s) vs select(3)). > > We discussed ethics, which derive from the âif you break it, you fix itâ > philosophy and distilled it into the âadministrators may revertâ policy > above. We donât want to prevent breakages, nor make people afraid of > breaking things. We merely want to prevent other people being affected by > breakages, especially those that may be operating under production or time > constraints. > > > We will integrate the Github commit notifications with a Codespeed > instance that will test commits for performance regressions. > > > Action Items > > > - > > Write the commit script > - > > Set a date for the move (sooner rather than later) > - > > Move the repository > - > > Enable automatic builds for all the platforms > - > > Write GNU makefiles for unix/linux > - Make WebHooks for Commit Notifications available to anyone who wants > them. > - Write CMake code to generate per-platform headers (***) > > > > _,,,^..^,,,_ > best, Eliot > > (*) under protest > (**) use whatever versioning you want on your own versions, but the > versions in OpenSmalltalk/vm will use this convention exclusively > (***) which will /not/ be called "config.h", but e.g. "ostvmConfig.h", so > as to avoid conflicts with other packages using autoconf and CMake > > -- _,,,^..^,,,_ best, Eliot

May 21, 2016

Re: [Pharo-dev] Should we updated UpdatedPharoByExample for Pharo 5?

by Cyril Ferlicot D.

Le 21/05/2016 15:56, stepharo a Ã©crit : > Hi cyril > > > I think that we should find the right balance between details that are > specific to a version and stable parts. > > Now I target Pharo 50. I think that the focus of Pharo 60 should be on > external (new tools) but on stabilisation, speed up and > > cleanup (and internal things like bootstrap). > > Stef > Ok, so if nobody disagree I think we should tag the current version as Pharo 4. Mark the current Jenkins build as "Always keep artefact" and publish a link on the book's page. I can do the two first steps but not the last. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

May 21, 2016

Re: [Pharo-dev] TEXT drag and drop

by Thierry Goubier

Le 21/05/2016 15:58, stepharo a Ã©crit : > How can I see the effects of your changes? Install both packages that are in that smalltalkhub archive, and try dragging a text selection. At least, that process works for PluggableTextMorph. Nice demonstration of both the drag and drop api and the text api, because it's even nicely undoable in the editor :) Thierry > > Stef > > > Le 18/5/16 Ã 19:09, lb a Ã©crit : >> Hi, >> I have made a little tool for draging and dropping text selection. >> like windows Word. >> It can work in Pharo 40 50 and 60. >> >> Have a fun! >> >> LiangBing >> >> MCHttpRepository >> location: >> 'http://www.smalltalkhub.com/mc/liangbing/Text-DragDrop/main' >> user: '' >> password: '' >> >> >> >

May 21, 2016

Re: [Pharo-dev] TEXT drag and drop

by stepharo

How can I see the effects of your changes? Stef Le 18/5/16 Ã 19:09, lb a Ã©crit : > Hi, > I have made a little tool for draging and dropping text selection. > like windows Word. > It can work in Pharo 40 50 and 60. > > Have a fun! > > LiangBing > > MCHttpRepository > location: > 'http://www.smalltalkhub.com/mc/liangbing/Text-DragDrop/main' > user: '' > password: '' > > >

May 21, 2016

Re: [Pharo-dev] Should we updated UpdatedPharoByExample for Pharo 5?

by stepharo

Hi cyril I think that we should find the right balance between details that are specific to a version and stable parts. Now I target Pharo 50. I think that the focus of Pharo 60 should be on external (new tools) but on stabilisation, speed up and cleanup (and internal things like bootstrap). Stef Le 21/5/16 Ã 15:00, Cyril Ferlicot D. a Ã©crit : > Currently all issues are opened to update PBE for Pharo4. Since Pharo5 > is out should we give up on Pharo4 version and focus on Pharo5? > > Since we don't have enough man power to do both I think we should just > tag the current version with a Pharo4 tag even if everything is not up > to date and begin to adapt it for Pharo5. >

May 21, 2016