- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Call of projects of open-dev lectures

by phil＠highoctane.be

MongoTalk improvements: GridFS, Replicasets, multi server. Useful, "fancy" tech, can make a difference. Phil On Sat, Jan 7, 2017 at 1:52 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > Le 06/01/2017 Ã 23:51, Damien Pollet a Ã©crit : > > On 6 January 2017 at 21:04, Hilaire > > <hilaire(a)drgeo.eu > > <mailto:hilaire@drgeo.eu>> wrote: > > > > How should I understand 12 * 4 hours? > > 12 hours by student in a team of four? > > > > > > Ten weeks with 4 dedicated hours every friday afternoon, in groups of 3 > to 5 > > Do the students have background on Pharo, if yes what is it? > > Ok, so it is more than understood. I guess the group will spend one or > two Friday afternoons brainstorming the environment and application. > > I will try my best to dedicate time to communicate regularly with the > students. > > -- > Dr. Geo > http://drgeo.eu > > >

Jan. 7, 2017

Re: [Pharo-dev] Call of projects of open-dev lectures

by Hilaire

So 18h to 21h per student dedicated to collaborate to a Pharo based project of the community? Le 07/01/2017 Ã 15:11, Damien Pollet a Ã©crit : > > They have at least a semester of Java, but it's their first experience > with Pharo, I believe. Stef will have them spend the first 3-4 fridays > learning and going through the books and MOOC. -- Dr. Geo http://drgeo.eu

Jan. 7, 2017

Re: [Pharo-dev] ***Important*** Snapcraft pharo package for Pharo 50

by philippe.back＠highoctane.be

There are docker images for Pharo already. E.g. https://hub.docker.com/r/geraudster/docker-pharo/~/dockerfile/ Phil Le 6 janv. 2017 19:11, "Damien Pollet" <damien.pollet(a)gmail.com> a Ã©crit : > Docker seems pretty nice as well, with the added bonus that it can be > hosted on Mac and Windows, and is probably a bit lighter since containers > are not full-system. > > About installing Pharo, I'd guess that the adhoc install procedure is a > problem. Whatever the dependencies, it's easier for admins to install stuff > if it's just another package that fits with the rest of their distribution. >

Jan. 7, 2017

Re: [Pharo-dev] Call of projects of open-dev lectures

by Damien Pollet

On 7 January 2017 at 13:52, Hilaire <hilaire(a)drgeo.eu> wrote: > Do the students have background on Pharo, if yes what is it? > They have at least a semester of Java, but it's their first experience with Pharo, I believe. Stef will have them spend the first 3-4 fridays learning and going through the books and MOOC. -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Jan. 7, 2017

Re: [Pharo-dev] Call of projects of open-dev lectures

by Hilaire

Le 06/01/2017 Ã 23:51, Damien Pollet a Ã©crit : > On 6 January 2017 at 21:04, Hilaire > <hilaire(a)drgeo.eu > <mailto:hilaire@drgeo.eu>> wrote: > > How should I understand 12 * 4 hours? > 12 hours by student in a team of four? > > > Ten weeks with 4 dedicated hours every friday afternoon, in groups of 3 to 5 Do the students have background on Pharo, if yes what is it? Ok, so it is more than understood. I guess the group will spend one or two Friday afternoons brainstorming the environment and application. I will try my best to dedicate time to communicate regularly with the students. -- Dr. Geo http://drgeo.eu

Jan. 7, 2017

Integer arithmetic and bit operations in Squeak and Pharo (32bit & 64bit)

by Benoit St-Jean

Hello guys, A few questions/comments/remarks about integer arithmetic and bit operations.Â And I guess many of my interrogations most likely concern the guys building the VM/primitives... I'm working on a chess engine that will rely heavily on bitboard manipulations, i.e. lots of integer arithmetic with bit operations.Â I was comparing the 32bit & 64bit Spur VM for Squeak & Pharo (I want the chess engine to be portable on Squeak & Pharo).Â As I pointed out earlier on on the Squeak-devÂ mailing list in october 2016, there are a few things that look strange to me and/or that I do not understand. 1) #bitXor: performs the same on the 32bit & 64bit VM for LargePositiveInteger.Â BUT, on average, #bitXor: is 15 (fifteen) times *slower* on LargePositiveInteger than with SmallInteger, for both 32 & 64 bit VM/Image. Besides, with SmallInteger, #bitXor: is 4.5 faster on 32bit as compared to 64bit!!Â You can test (on 32bit & 64bit) that with the following snippet: | small1 small2 small3 large1 large2 n timeSmall timeLarge | small1 := 2r1111111111111111. "65535,Â (1<<16)-1" small2 := (1 << 30) - 1. "Largest SmallInteger on 32bit VM/Image, SmallInteger maxVal" small3 :=Â 1152921504606846975. "Largest Integer on 64bit VM/Image, SmallInteger maxVal" large1 := (1 << 64)-1. "64 bits set to 1" large2 := (1 << 80)-1. "80 bits set to 1" n := 100000000. timeSmall := Time millisecondsToRun: [n timesRepeat: [ small1 bitXor:Â small2]]. timeLarge := Time millisecondsToRun: [n timesRepeat: [ large1 bitXor:Â large2]]. Transcript cr;show: 'Time LargePositiveInteger : ', timeLarge printString. Transcript cr;show: 'Time SmallInteger : ', timeSmall printString. As was pointed out by Nicolas Cellier in a private communication, one workaround is to add the method #bitXor: in the class LargePositiveInteger to get a 3x performance boost.Â Nicolas recommended the following code: LargePositiveInteger>>bitXor: arg Â Â Â <primitive:36> Â Â Â ^super bitXor: arg Â Â Â It's all good and nice (and I do get a 3x speedup, in 32&64 bit) but then I wonder in which respect primitive 36 is different from the one LargePositiveInteger usually inherits from Integer : (Integer>>bitXor:) <primitive: 'primDigitBitXor' module:'LargeIntegers'> Why does Nicolas' workaround is able to do the job (calling primitive 36) when there is already a primitive for the exact thing (<primitive: 'primDigitBitXor' module:'LargeIntegers'>) ? Is this duplicate code or there is a reason for this?Â And why is the primDigitBitXor primitive so slow as compared to primitive 36? 2) One would normally expect the 64bit VM to be faster than the 32bit VM.Â That's true in all cases except...Â Well, first, some numbers (Test case attached to this email if you want to reproduce) 32bit Number of #allMask: per second : 6.20M Number of #anyMask: per second : 7.17M Number of #bitAnd: per second : 8.45M Number of #bitAt: per second : 55.15M Number of #bitAt:put: per second : 37.22M Number of #bitClear: per second : 5.18M Number of #bitInvert per second : 6.53M Number of #bitOr: per second : 9.18M Number of #bitXor: per second : 8.97M Number of #highBit per second : 43.23M Number of #<< per second : 11.34M Number of #lowBit per second : 69.44M Number of #noMask: per second : 7.40M Number of #>> per second : 12.36M 64bit Number of #allMask: per second : 10.26M Number of #anyMask: per second : 10.37M Number of #bitAnd: per second : 17.00M Number of #bitAt: per second : 15.89M Number of #bitAt:put: per second : 10.36M Number of #bitClear: per second : 6.44M Number of #bitInvert per second : 9.11M Number of #bitOr: per second : 18.45M Number of #bitXor: per second : 15.38M Number of #highBit per second : 7.66M Number of #<< per second : 10.50M Number of #lowBit per second : 13.49M Number of #noMask: per second : 11.47M Number of #>> per second : 10.52M There are a few surprises here.Â First, #bitAt:, #bitAt:put:, #highBit and #lowBit are a *lot faster* on the 32bit VM than on the 64bit VM! Does anyone have an explanation for this?Â Is this normal? The other surprise is that #>> and #<< seem to be about the same speed on both VM.Â Any reason why the 64bit version isn't faster than the 32bit one? 3) I was surprised to find out that SmallInteger>>#maxVal wasn't a constant (or the same on both VM).Â It's (1<<60)-1 on the 64bit VM and (1<<30)-1 on the 32bit VM.Â So, be warned if your code depends on SmallInteger>>#maxVal for some reason! 4) Is there any rationale/reason/explanation as to why, in Pharo, LargePositiveInteger inherits from the class LargeInteger (which doesn't exist in Squeak) ? Thanks in advance. Â ----------------- 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)

Jan. 7, 2017

Re: [Pharo-dev] Call of projects of open-dev lectures

by Damien Pollet

On 6 January 2017 at 21:04, Hilaire <hilaire(a)drgeo.eu> wrote: > How should I understand 12 * 4 hours? > 12 hours by student in a team of four? > Ten weeks with 4 dedicated hours every friday afternoon, in groups of 3 to 5 -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Jan. 6, 2017

Re: [Pharo-dev] Call of projects of open-dev lectures

by Hilaire

Le 05/01/2017 Ã 18:26, stepharong a Ã©crit : >> How many hours are they supposed to dedicate to the project? > > 12 * 4 hours. How should I understand 12 * 4 hours? 12 hours by student in a team of four? If it is so, it is not that much as I guess again students are new to both Pharo (you did not elaborate on their background regarding Pharo) and even newer to the application to collaborate with. With that perspective, if my guesses are right, I did a selection of Dr. Geo bugs for the students to work on. I also rate the bug difficulties in a scale of 1 to 3. Some are really easy to fix, at least for me as I have the background knowledge, but the student will have to spend time to understand the source code, moreover some bug once fixed need to be documented in the user guides. All in all I selected 14 issues I think the students can reasonably work on. Web page: http://drgeo.eu Forum: http://forum.drgeo.eu Bugs tracker: https://bugs.launchpad.net/drgeo/+bugs?field.tag=student -- Dr. Geo http://drgeo.eu

Jan. 6, 2017

Re: [Pharo-dev] ***Important*** Snapcraft pharo package for Pharo 50

by Damien Pollet

Docker seems pretty nice as well, with the added bonus that it can be hosted on Mac and Windows, and is probably a bit lighter since containers are not full-system. About installing Pharo, I'd guess that the adhoc install procedure is a problem. Whatever the dependencies, it's easier for admins to install stuff if it's just another package that fits with the rest of their distribution.

Jan. 6, 2017

Re: [Pharo-dev] Call of projects of open-dev lectures

by Alexandre Bergel

Hi Stef, Here is the Roassal part: Webpages: http://agilevisualization.com http://moosetechnology.org Mailing-list: https://www.list.inf.unibe.ch/listinfo/moose-dev Bug tracker: https://github.com/moosetechnology/Moose/issues Cheers, Alexandre > On Jan 4, 2017, at 11:48 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi > > We are organising a lecture where students should > - learn pharo > - learn how to communicate with open source community > - learn how to reverse engineer, fix bugs.... > They should work by 3/4. > > We are looking for projects that would like to accept > - propose some bugs to be fixed > - to communicate with newbies and from time to time > > I was thinking about > - MDL > - Roassal > - Moose ? > - Pillar ? but nobody beside me and I do not have the time > - DRGeoII > - Telescope > - Artefact > - Scale > - Ecstatic > > So if you have a project and you want to participate. > We would like to have > - web page? > - mailing-list > - bug trackers/todo? > > Stef -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 6, 2017