April 2017 - Pharo-dev - lists.pharo.org

Help currency review
by Ben Coman April 17, 2017

April 17, 2017

At this late stage of Pharo 6 development, it might be good to do a pass at... World > Help > Help Browser content Epicea >Browsers - mentions two separate browser windows GT Debugger >> Actions - TODO GT Playground >> Overview - http://gt.moosetechnology.org redirects to http://gtoolkit.org/ and same for several GT entries Welcome > Getting Help says... - The "Pharo Users" mailing list: http://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org - The "Pharo Slack Team": http://slack4pharo.trentosur.com/ - The "Pharo IRC Channel": irc.freenode.net, #pharo channel - http://pharo.org/community So we should change from Slack to Discord. I can take care of this one but a couple questions... 1. I propose a Discord #Help channel to record here in the help browser. 2. I bumped into an interesting tip https://www.reddit.com/r/discordapp/comments/3yu1bh/server_vs_channel_invit… Thus I propose we have a #Welcome channel providing info like what the bot has been providing. Later it could be good to have a bot just in that channel, but not off someone's home server :) I would expect that channel to not need anyone lurking in it. Newcomers will jump immediately from there #Help or #General 3. How active is the IRC channel? Should we remove it from the help browser? The mention at http://pharo.org/community could be sufficient. 4. Should we backport this help info update to Pharo 5? cheers -ben

3 2

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install
by Esteban Lorenzano April 17, 2017

April 17, 2017

this belongs to pharo-dev, please continue there :) > On 15 Apr 2017, at 14:25, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > On Sat, Apr 15, 2017 at 02:14:26PM +0200, Luke Gorrie wrote: >> On 15 April 2017 at 11:53, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> (actually, I'm not sure why you're bothering since 6 should >> be out before the end of the month, but that's your choice :-)). >> >> >> I just want something stable and reasonably modern for running existing >> applications and building new ones. >> >> If that means waiting for Pharo 6.0 release then that is okay with me. >> >> >> The (V6) linux install relies on a number of bash scripts to launch pharo >> (bin/pharo, bin/pharo-ui and bin/pharo-vm/pharo). How are you producing >> these, or are you doing something else? >> >> >> Here is where those scripts are generated in the existing pharo-vm packaging: >> https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/pharo/vm/ >> build-vm.nix#L50-L70 > > Ahh, so Nix is doing its own thing, not using the ZeroConf scripts. > > >> (I didn't write the nix packaging code but I have volunteered to maintain it so >> if it's out of date then I should fix that.) > > It will be for V6. Esteban has changed the scripts to ensure that Pharo > versions of libraries are loaded (from memory)(this is also partly why I > would like to use the full build process). > > >> git clone https://github.com/pharo-project/pharo-vm.git <https://github.com/pharo-project/pharo-vm.git> >> git checkout <the stable code...> >> cd pharo-vm/opensmalltalk-vm/build.linux64x64/pharo.cog.spur/build >> ./mvm >> -- >> >> BTW: HEAD is currently eaf13db484ac87720d8454e66b5ce92f51c01036, and my >> experience is that it is significantly less stable than the latest >> binary, which is from 1c38b03fb043a2962f30f080db5b1292b5b7badb >> >> >> This is really the bleeding edge :-) both of those commits were pushed within >> the past three days! > > Yep, V6 is still in testing. :-) > > Cheers, > Alistair

3 2

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install
by Ben Coman April 17, 2017

April 17, 2017

On Sat, Apr 15, 2017 at 4:34 PM, Luke Gorrie <luke(a)snabb.co> wrote: > On 15 April 2017 at 10:08, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Grabbing the source directly from Git is attractive if (a) I know that I am > choosing a good version and (b) I am able to build it in a good way. > > Seems like a workable solution to (a) is to periodically check for a new > binary release, work out which commit it is based off, and build that. This > seems fairly reasonable and is probably also possible to automate. (I > suppose you got the commit-id from --version or from checking Jenkins.) > > I see (b) as problematic though. The source tarball releases have a simple > build procedure ("make") while the Git checkouts require a more involved one > (bootstrapping the VM from an existing Pharo image.) A historical perspective... Prior to this coming Release 6, Pharo had diverged from the parent build system used by OpenSmalltalk (nee Squeak-VM) such that (IIUC) it was driven from the Image generating the generated-C-sources plus the Cmake configuration. I guess this is what you describe as "bootstrap". However for Release 6 onwards, Pharo has returned to the fold and is directly using the OpenSmalltalk build system. The OpenSmalltalk build system does not require a build to invoke a Smalltalk image, and I notice elsewhere you've seen the ./mvm script. Eliot currently manually updates the checked-in generated-C-sources at times he considers them stably generated from VMMaker-Image, although I think I saw recently some mention of doing CI on each VMMaker check-in.. So the Pharo 5 in-Image CMake generation system is deprecated, and I guess there will not be much further development on the Pharo 5 VM. So I would consider *not* including the bootstrap as part of the nix process and manually perform the bootstrap per steps 1 to 3 here... * https://github.com/pharo-project/pharo-vm/tree/5.0-stable then archive those folders to create your own source-distribution Now it would be good to hear if Pharo might get a Pharo-5-stable-VM deployed from OpenSmalltalk? cheers -ben > So I would need to > revise the nix build scripts quite a bit if I want to build from Git instead > of the tarballs. However, it seems that on the master branch last week the > VM build procedure has been reworked so that it is _not_ necessary to run > the bootstrapping procedure anymore, which sounds great to me, except that I > understand this new build procedure to be quite bleeding edge and not yet > documented or used for a binary release (it's not included in the commit > that you cite above.) > > So what to make of all that? Just right now I see only bad alternatives: > sticking with the source release means not supporting Pharo 5.0, updating > the build scripts to do bootstrapping takes effort and is already obsoleted > by changes on the VM master branch, and shipping the VM master branch means > making a pseudo-release without any QA and potentially causing problems for > people downstream (there are lots of commits landing on that branch and I > have no idea which ones are important/stable.) > > So the most reasonable course of action from my point of view seems to be to > sit and wait for a better solution to come along e.g. a new source release > of the VM or a "blessed" Git commit ID that includes the updated build > scripts. The downside is that meanwhile NixOS users can't run the 5.0 image. > Could be that Pharo 6.0 will resolve this and that is fine for me -- but of > course I'd take a solution sooner if there is a simple one. > >

5 21

Esteban's ChangeLog week of 10 April 2017
by estebanlm＠gmail.com April 17, 2017

April 17, 2017

Hello! This is my weekly ChangeLog, from 10 April 2017 to 16 April 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=10/4/2017&to=16/4/2017 ChangeLog ========= 13 April 2017: -------------- * After spending again far too much time trying to get a compilation of +libgit2 v0.23+ on macOS 64bits (for some misterious reason is very hard... I guess is because is an old version), I decided to go the other way: migrate libgit2 bindings to the latest version (something that we needed to do anyway). So far, I got a version working on macOS 32bits (I needed to change some structures, but not as many as I thought). Anyway, tomorrow I will test linux and windows and we'll see 64bits later :) 12 April 2017: -------------- * I updated [zeroconf](http://get.pharo.org/64) with 64bits support! It is still a "preview" (stable version is still not final :P), but is there to test :) I recommend to test: ---- curl get.pharo.org/64/60+vmLatest | bash ---- *REMEMBER:* Windows 64bits is still not supported. * Just fixed a small bug on [iceberg](http://github.com/npasserini/iceberg) : it was missing comparison of locations when mixing absolute and relative paths, even if pointing to same place. * I worked on fix [case: 19891](https://pharo.fogbugz.com/f/cases/19891) and [case: 19890](https://pharo.fogbugz.com/f/cases/19890). Second one took more than expected even if is so trivial just because I was in the middle of another problem with VM :) * I spent some time updating [http://pharo.org/community](http://pharo.org/community) page (not much there, just making shure people will come to the right place when asking for help), and fixing a couple of annoying issues in +/news+. cheers! Esteban

1 0

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install
by Ben Coman April 16, 2017

April 16, 2017

Whoops, now copied to pharo-dev to continue discussion there. On Sun, Apr 16, 2017 at 9:13 PM, Ben Coman <btc(a)openinworld.com> wrote: > On Sat, Apr 15, 2017 at 12:43 PM, Luke Gorrie <luke(a)snabb.co> wrote: >> >> On 14 April 2017 at 22:20, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >>> This is what we always have when we release and we freeze it. >>> The vm 60 will be compatible with latest pharo 60 image. >> >> >> It is possible that I have misunderstood the whole situation and there is no problem at all. That would be awesome. Let's check :-) here is my understanding of the state of the world right now: >> >> The latest stable image release is Pharo-50771.image. >> The latest stable VM source release is pharo-vm-2016.02.18. >> These two releases are not compatible: This interpreter (vers. 6505) cannot read image file (vers. 6521). >> >> So the problem is that if a distribution packages the latest VM source release then the users won't be able to run the Pharo 5 VM that they download from pharo.org or via the pharo-launcher image. >> >> Is that correct? If so that's fine and hopefully we can fix it for Pharo 6.0. But if I am misunderstanding and a fix is available today that would also be good to know. >> >> I am looking for the "latest VM source release" in http://files.pharo.org/vm/src/vm-unix-sources/ > >> and assuming that non-spur is the stable option for pre-6.0 images. > > That is not correct. Pharo 5 used a Spur-VM since build 50496 circa 2015-12-14. > * http://files.pharo.org/image/50-preSpur/ > * http://files.pharo.org/image/50/ > > cheers -ben

1 0

Parser for mongodb queries in javascript notations
by chrismihaylyk April 16, 2017

April 16, 2017

Hello! I'm creating MongoDBBrowser that have all CRUD operations and I need a parser that translates javascript queries in MongoDB to the queries, for making selects, inserts etc. using Mongo class. For example, I have query db.SomeCollection.find( {$or: [ { name: { $regex: /test/i } }, { description: { $regex: /test/i } } ] } ) that is manually rewriting into someCollection select: { '$or' -> { { 'name' -> { '$regex' -> 'test' . '$options' -> 'i' } asDictionary } asDictionary. { 'description' -> { '$regex' -> 'test' . '$options' -> 'i' } asDictionary } asDictionary } } asDictionary But I need to have a parser that will do it automatically. Maybe there are already exist one? If not, how to write my own? Please help. Thanks a lot, Khrystyna=) -- View this message in context: http://forum.world.st/Parser-for-mongodb-queries-in-javascript-notations-tp… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

1 0

patching vmmaker
by K K Subbu April 15, 2017

April 15, 2017

Hi, While building the VM from generator.image through eval handler, I noticed spurious blank lines in the log output. I created a changeset that removes these and creates a compact log (all in VMMaker package). My generator.image only throws up local repos for MC. smalltalkhub.com seems to be down. How do I upload the patch to VMMaker mainline? Regards .. Subbu

2 1

why all technical discussions suddenly moved to pharo-users?
by Esteban Lorenzano April 15, 2017

April 15, 2017

that :) I think most discussions now happening on pharo-users belongs here (pharo-users was supposed to help people to achieve their goals with Pharo, not to discuss Pharo implementation;) cheers! Esteban

1 0

April 14, 2017

Hi all, I am trying to investigate performance overhead in benchmarks to improve the VM performance. In a benchmark strings are used as dictionary keys, which seems to be an OK pattern to me that may be actually used in real code from time to time. Something stroke me: *the hash function of a string is actually iterating over the whole string. * As a result, I get something like this: #( 'String size: 0, Hash function performance: 17,817,776 per second' 'String size: 1, Hash function performance: 15,395,388 per second' 'String size: 3, Hash function performance: 14,853,109 per second' 'String size: 4, Hash function performance: 15,151,954 per second' 'String size: 5, Hash function performance: 14,139,881 per second' 'String size: 10, Hash function performance: 11,545,749 per second' 'String size: 65, Hash function performance: 3,431,067 per second' 'String size: 130, Hash function performance: 1,879,047 per second' 'String size: 520, Hash function performance: 511,934 per second' ) This means that if a hash of a 1MB String is computed it takes a hell of a time. I wonder why we don't compute the string hash from a small number of inner characters taken randomly but deterministically from the String. From example, for all strings longer than 5 characters, one could pick only 5 characters in the String to compute its hash. The hash function is this way decent enough and the performance does not drop for large strings. One implementation could be to replace: 1 to: stringSize do: [:pos | by: 1 to: stringSize by: stringSize // 5 do: [:pos | in: ByteString>>stringHash: aString initialHash: speciesHash Then we need to rehash the whole image. What do you think ? Is there a hash expert around that can confirm this is a good idea ?

4 3

Remove all Configurations in the Pharo 6 release?
by Pavel Krivanek April 14, 2017

April 14, 2017

Hi, in Pharo 7 all configurations will be removed and replaced with the baselines. The bootstrapped image itself does not load the configurations at all. Most of them is now outdated and old versions of configurations in the standard Pharo image can cause problems for users of newer versions semi-internal packages (like Moose-Algos). So we, me and Cyril think that we should remove all current Configurations from the image just before the Pharo 6 release. Do you see any disadvantages of this step? Cheers, -- Pavel

3 4