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

Re: [Pharo-dev] happy and bold new year

by Norbert Hartl

> Am 09.01.2017 um 11:11 schrieb philippe.back(a)highoctane.be <philippe.back(a)gmail.com>: > > Doru, > > Wow. > > I have to say that in the face of other technologies there is often the force that lures me back go them. But they do not have the same feel. This ability to understand and be able to dig down is unmatched. > > I was reading this mail this morning and it echoes your point pretty nicely: > "I hear a lot about "seeking meaning," especially in the face of tragedy and uncertainty. But how would you know it if you tripped over it? I doubt it's like the justice's definition of pornographyâI'll know it when I see it. > I'd think our brief time here is about creating meaning, first and foremost for ourselves. When we have a lighted path, a goal for our journey (whether or not we reach our destination), we tend to serve a greater purpose. "Journey" comes from the French jornee which means a day, or a day's travels. It refers to our daily activity. > > When we we are engaged in neither meaning nor happiness, we waste our days. When we are engaged in meaning but not happiness, we are sacrificing our days. When we are engaged in high happiness but little meaning, we are in a stimulating or addictive environment. Only when we are immersed in both happiness and meaning do we create an optimal, contributing life. > > I don't know about you, but I'd prefer to take both my meaning and happiness out of others' hands, and create them both myself".--Alan Weiss > > Definitely applies to our tech. > I think it applies to a lot of things especially discussions about nourishment :) Norbert > Happy New Year! > > > > Phil > > > > > Le 9 janv. 2017 10:31, "Tudor Girba" <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> a Ã©crit : > Happy New Year, everyone! > > Over the last year, I went through a rather extensive tour and I directly exposed Moose, GT and Pharo to some 2000+ technical people through various sessions and trainings at conferences and companies. The tour will continue this year. > > Most of the sessions are not directly about Moose, GT or Pharo, but about broader topics that are served through what we do around here. These topics can relate to solving problems without reading code, to steering agile architecture, or more recently, to even broader topics like software environmentalism. If you are wondering what software environmentalism is, please take a look at this talk: > https://youtu.be/N3l3eB62oSw?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA <https://youtu.be/N3l3eB62oSw?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA> > > I now have the confirmation that there is a whole space which is unaddressed by mainstream technologies. Often people find themselves frustrated having to build their systems on top of opaque technologies with not much hope of understanding what is going on under the hood both because they do not have access to what is behind and because they are provided lack the tools to investigate. You see, developers are suppose to have the coolest job on the planet, and many of them are unhappy. This has to change, and we can do that. > > In a conversation I had with a highly respected researcher, after explaining how our tools allow us to work, he noted reluctantly âso, you are claiming that you are practicing a fundamentally different software engineering?â. This question took me a little by surprise because the only answer I found myself being able to provide was âyesâ. I sent him this talk: > https://youtu.be/XWOOJa3kEa0?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA <https://youtu.be/XWOOJa3kEa0?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA> > > It is strange to be in the position to tell the world that we are constructing something fundamentally better, but I really do believe that we are. > > I wish you a happy and bold new year! > > Cheers, > Doru > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > www.feenk.com <http://www.feenk.com/> > > "Every thing should have the right to be different." > > > > >

Jan. 9, 2017

Re: [Pharo-dev] happy and bold new year

by philippe.back＠highoctane.be

Doru, Wow. I have to say that in the face of other technologies there is often the force that lures me back go them. But they do not have the same feel. This ability to understand and be able to dig down is unmatched. I was reading this mail this morning and it echoes your point pretty nicely: "I hear a lot about "seeking meaning," especially in the face of tragedy and uncertainty. But how would you know it if you tripped over it? I doubt it's like the justice's definition of pornographyâI'll know it when I see it. I'd think our brief time here is about *creating* meaning, first and foremost for ourselves. When we have a lighted path, a goal for our journey (whether or not we reach our destination), we tend to serve a greater purpose. "Journey" comes from the French *jornee *which means a day, or a day's travels. It refers to our daily activity. When we we are engaged in neither meaning nor happiness, we waste our days. When we are engaged in meaning but not happiness, we are sacrificing our days. When we are engaged in high happiness but little meaning, we are in a stimulating or addictive environment. Only when we are immersed in both happiness and meaning do we create an optimal, contributing life. I don't know about you, but I'd prefer to take both my meaning and happiness out of others' hands, and create them both myself".--Alan Weiss Definitely applies to our tech. Happy New Year! Phil Le 9 janv. 2017 10:31, "Tudor Girba" <tudor(a)tudorgirba.com> a Ã©crit : > Happy New Year, everyone! > > Over the last year, I went through a rather extensive tour and I directly > exposed Moose, GT and Pharo to some 2000+ technical people through various > sessions and trainings at conferences and companies. The tour will continue > this year. > > Most of the sessions are not directly about Moose, GT or Pharo, but about > broader topics that are served through what we do around here. These topics > can relate to solving problems without reading code, to steering agile > architecture, or more recently, to even broader topics like software > environmentalism. If you are wondering what software environmentalism is, > please take a look at this talk: > https://youtu.be/N3l3eB62oSw?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA > > I now have the confirmation that there is a whole space which is > unaddressed by mainstream technologies. Often people find themselves > frustrated having to build their systems on top of opaque technologies with > not much hope of understanding what is going on under the hood both because > they do not have access to what is behind and because they are provided > lack the tools to investigate. You see, developers are suppose to have the > coolest job on the planet, and many of them are unhappy. This has to > change, and we can do that. > > In a conversation I had with a highly respected researcher, after > explaining how our tools allow us to work, he noted reluctantly âso, you > are claiming that you are practicing a fundamentally different software > engineering?â. This question took me a little by surprise because the only > answer I found myself being able to provide was âyesâ. I sent him this talk: > https://youtu.be/XWOOJa3kEa0?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA > > It is strange to be in the position to tell the world that we are > constructing something fundamentally better, but I really do believe that > we are. > > I wish you a happy and bold new year! > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "Every thing should have the right to be different." > > > > > >

Jan. 9, 2017

happy and bold new year

by Tudor Girba

Happy New Year, everyone! Over the last year, I went through a rather extensive tour and I directly exposed Moose, GT and Pharo to some 2000+ technical people through various sessions and trainings at conferences and companies. The tour will continue this year. Most of the sessions are not directly about Moose, GT or Pharo, but about broader topics that are served through what we do around here. These topics can relate to solving problems without reading code, to steering agile architecture, or more recently, to even broader topics like software environmentalism. If you are wondering what software environmentalism is, please take a look at this talk: https://youtu.be/N3l3eB62oSw?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA I now have the confirmation that there is a whole space which is unaddressed by mainstream technologies. Often people find themselves frustrated having to build their systems on top of opaque technologies with not much hope of understanding what is going on under the hood both because they do not have access to what is behind and because they are provided lack the tools to investigate. You see, developers are suppose to have the coolest job on the planet, and many of them are unhappy. This has to change, and we can do that. In a conversation I had with a highly respected researcher, after explaining how our tools allow us to work, he noted reluctantly âso, you are claiming that you are practicing a fundamentally different software engineering?â. This question took me a little by surprise because the only answer I found myself being able to provide was âyesâ. I sent him this talk: https://youtu.be/XWOOJa3kEa0?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA It is strange to be in the position to tell the world that we are constructing something fundamentally better, but I really do believe that we are. I wish you a happy and bold new year! Cheers, Doru -- www.tudorgirba.com www.feenk.com "Every thing should have the right to be different."

Jan. 9, 2017

Re: [Pharo-dev] [squeak-dev] Integer arithmetic and bit operations in Squeak and Pharo (32bit & 64bit)

by Eliot Miranda

...and by the way, I got 3.4e-9 on 32-bit (down from 2.7e-9) when I launched it after the 64-bit system and ran the benchmark while the 64-bit system was still running. So run on as quiet a machine as possible. On Sun, Jan 8, 2017 at 4:07 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Benoit, > > On Fri, Jan 6, 2017 at 11:59 PM, Benoit St-Jean <bstjean(a)yahoo.com> wrote: > >> 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. >> > > It's really important when running micro-benchmarks like this to minimize > or eliminate other costs. So you should unwind your inner loops, to at > least to ten repetitions or more. And it's wise to measure the time taken > for an empty loop. In these cases I'd consider comparing a loop containing > 10 instances of the operation against one containing one, e.g. for a time > in seconds you could use > > > | small1 small2 n | > n := 1000000. > small1 := SmallInteger minVal. > small2 := SmallInteger maxVal. > (Time millisecondsToRun: [1 to: n do: [:i| small1 bitXor: small2. small1 > bitXor: small2. small1 bitXor: small2. small1 bitXor: small2. small1 > bitXor: small2. small1 bitXor: small2. small1 bitXor: small2. small1 > bitXor: small2. small1 bitXor: small2. small1 bitXor: small2. small1 > bitXor: small2]]) - (Time millisecondsToRun: [1 to: n do: [:i| small1 > bitXor: small2]]) / 10000.0 / n > > When I do this I get 2.4e-9 for 64-bit Squeak and 2.7e-9 for 32-bit > Squeak. Note that I used 1 to: n do: [:ignored| rather than timesRepeat: > because I know its inlined and timesRepeat: isn't always. But in any case > I don't see the large difference in SmallInteger operation times that you > do. Could you repeat your measurements taking something similar to my > approach? > > >> >> 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? >> > > Primitive 36 deals with only 64-bit values (up to 8 byte LargeIntegers). <primitive: > 'primDigitBitXor' module:'LargeIntegers'> deals with arbitrary sized large > integers. > >> >> 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) >> > > It depends on the computation. One should expect the 64-bit VM to be > faster for certain kinds of arithmetic because it can do more in one > operation, e.g. 60-bit arithmetic should be much faster in 64-bits than in > 32-bits, most floating point should be much faster because of the immediate > floating-point representation. But consider a purely symbolic computation, > say tree walking. The 64-bit version has to move twice as much data as the > 32-bit version, so if the working set is large but amenable to execution in > 32-bits one would expect the 32-bit application to run faster because it > accesses half the data. > > > >> >> 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? >> > > Can you rerun the numbers using my approach before we attempt to answer > this? > > >> >> 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) >> >> >> >> > > > -- > _,,,^..^,,,_ > best, Eliot > -- _,,,^..^,,,_ best, Eliot

Jan. 9, 2017

Re: [Pharo-dev] [squeak-dev] Integer arithmetic and bit operations in Squeak and Pharo (32bit & 64bit)

by Eliot Miranda

Hi Benoit, On Fri, Jan 6, 2017 at 11:59 PM, Benoit St-Jean <bstjean(a)yahoo.com> wrote: > 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. > It's really important when running micro-benchmarks like this to minimize or eliminate other costs. So you should unwind your inner loops, to at least to ten repetitions or more. And it's wise to measure the time taken for an empty loop. In these cases I'd consider comparing a loop containing 10 instances of the operation against one containing one, e.g. for a time in seconds you could use | small1 small2 n | n := 1000000. small1 := SmallInteger minVal. small2 := SmallInteger maxVal. (Time millisecondsToRun: [1 to: n do: [:i| small1 bitXor: small2. small1 bitXor: small2. small1 bitXor: small2. small1 bitXor: small2. small1 bitXor: small2. small1 bitXor: small2. small1 bitXor: small2. small1 bitXor: small2. small1 bitXor: small2. small1 bitXor: small2. small1 bitXor: small2]]) - (Time millisecondsToRun: [1 to: n do: [:i| small1 bitXor: small2]]) / 10000.0 / n When I do this I get 2.4e-9 for 64-bit Squeak and 2.7e-9 for 32-bit Squeak. Note that I used 1 to: n do: [:ignored| rather than timesRepeat: because I know its inlined and timesRepeat: isn't always. But in any case I don't see the large difference in SmallInteger operation times that you do. Could you repeat your measurements taking something similar to my approach? > > 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? > Primitive 36 deals with only 64-bit values (up to 8 byte LargeIntegers). <primitive: 'primDigitBitXor' module:'LargeIntegers'> deals with arbitrary sized large integers. > > 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) > It depends on the computation. One should expect the 64-bit VM to be faster for certain kinds of arithmetic because it can do more in one operation, e.g. 60-bit arithmetic should be much faster in 64-bits than in 32-bits, most floating point should be much faster because of the immediate floating-point representation. But consider a purely symbolic computation, say tree walking. The 64-bit version has to move twice as much data as the 32-bit version, so if the working set is large but amenable to execution in 32-bits one would expect the 32-bit application to run faster because it accesses half the data. > > 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? > Can you rerun the numbers using my approach before we attempt to answer this? > > 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) > > > > -- _,,,^..^,,,_ best, Eliot

Jan. 9, 2017

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

by Alistair Grant

On 7 January 2017 at 04:31, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > Stef, > > RE: why they "cannot install Pharo" --- I'd guess it is because Pharo > requires 32 bit libraries and those are not available in the current Linux > releases by default ... to install the 32 bit libraries requires sudo > privileges and students aren't going to be able to do it themselves and the > sysadmins aren't going to want to have to add 32 bit libraries to a bunch of > linux machines just for pharo ... just a guess . > > Dale > > > On 01/06/2017 05:38 AM, Stephane Ducasse wrote: > > Hi pharoers > > I want to share with you my experience with trying to use Pharo at the > University here on Linux. > I think that they are on Ubuntu and ... the sys admin told me that they > cannot install Pharo :( > Since I'm not expert in Linux install I cannot help ;( > > So we will probably use windows. > Now they told me that what would be nice is to get a snap for Pharo > based on snapcraft.io. > > Does any of you have a snap description or willing to help so that we can > get > a snap for Pharo50? then for Pharo60? Disclaimer: I haven't ever developed a snap package, so this is just my understanding, no experience! Damien has already mentioned Docker, which may be a good solution - I'm not familiar enough to comment on the differences other than I expect that a snap package would be lower overhead. Snap packaging is being developed by Canonical, the maintainers of Ubuntu. The touted advantages over existing packaging formats such as ppa's include: - Applications are sandboxed, increasing security (the are known limitations with X11, but this is the goal) - All dependencies can be included in the package - this gets back to what Dale was saying about the 32 bit libraries, they could be included in, and limited to, the snap package. Having said that, I don't know if snap packages support 32bit applications. - They're cross platform. The snap runtime has been ported to many of the major linux distributions, e.g. fedora, arch, gentoo, etc. - They're supposed to be fairly easy to develop (compared to ppa's). If Pharo can be made to work as a snap package it would probably be a good replacement for the ppa (eventually, older OSs won't support them). Cheers, Alistair

Jan. 8, 2017

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

by philippe.back＠highoctane.be

Then use the Centos VM It is for older libC. Phil Le 8 janv. 2017 20:01, "stepharong" <stepharong(a)free.fr> a Ã©crit : > On Fri, 06 Jan 2017 18:31:59 +0100, Dale Henrichs < > dale.henrichs(a)gemtalksystems.com> wrote: > > Stef, > > RE: why they "cannot install Pharo" --- I'd guess it is because Pharo > requires 32 bit libraries and those are not available in the current Linux > releases by default ... to install the 32 bit libraries requires sudo > privileges and students aren't going to be able to do it themselves and the > sysadmins aren't going to want to have to add 32 bit libraries to a bunch > of linux machines just for pharo ... just a guess . > > > I was talking about the sys admin and I think that there is a problem with > the different libC and they do not want to mess everything because we did > not plan it. > > Dale > > On 01/06/2017 05:38 AM, Stephane Ducasse wrote: > > Hi pharoers > > I want to share with you my experience with trying to use Pharo at the > University here on Linux. > I think that they are on Ubuntu and ... the sys admin told me that they > cannot install Pharo :( > Since I'm not expert in Linux install I cannot help ;( > > So we will probably use windows. > Now they told me that what would be nice is to get a snap for Pharo > based on snapcraft.io. > > Does any of you have a snap description or willing to help so that we can > get > a snap for Pharo50? then for Pharo60? > > Stef > > > > > > -- > Using Opera's mail client: http://www.opera.com/mail/ >

Jan. 8, 2017

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

by stepharong

On Fri, 06 Jan 2017 18:31:59 +0100, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > Stef, > > RE: why they "cannot install Pharo" --- I'd guess it is because Pharo > requires 32 bit libraries and those are not available in the current > Linux releases by default ... to install the 32 bit libraries >requires > sudo privileges and students aren't going to be able to do it themselves > and the sysadmins aren't going to want to have to add 32 bit libraries > to a bunch of linux machines just for pharo >... just a guess . I was talking about the sys admin and I think that there is a problem with the different libC and they do not want to mess everything because we did not plan it. > > Dale > > On 01/06/2017 05:38 AM, Stephane Ducasse wrote: >> Hi pharoers >> I want to share with you my experience with trying to use Pharo at the >> University here on Linux.I think that they are on Ubuntu and ... the >> sys admin told me that they cannot install Pharo :( >> Since I'm not expert in Linux install I cannot help ;( >> >> So we will probably use windows.Now they told me that what would be >> nice is to get a snap for Pharobased on snapcraft.io. >> Does any of you have a snap description or willing to help so that we >> can geta snap for Pharo50? then for Pharo60? >> >> Stef > -- Using Opera's mail client: http://www.opera.com/mail/

Jan. 8, 2017

Re: [Pharo-dev] No Projects at smalltalkhub

by Stephane Ducasse

to my own regret :) On Sun, Jan 8, 2017 at 2:38 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > I will try because I want to start moving some of my project to iceberg. > > Stef, to me, you are the perfect idea / tool debugger :-) > Let us know about your impression and experience report using Iceberg. > > Alexandre > > > > > > > On Fri, Jan 6, 2017 at 3:30 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > crapâ¦ I will need to check a bit more. > > > > Esteban > > > > ps: (maybe a good moment to start testing iceberg and moving projects to > git support?) If you execute this: > > > > Metacello new > > baseline: 'Iceberg'; > > repository: 'github://npasserini/iceberg:multi-remotes'; > > load. > > IceRepository defaultBackendType: #IceLibgitLocalRepository. > > > > in one of the VMs here: https://dl.bintray.com/pharo-project/pharo-vm/ > (the 32bits versions) > > latest version should work. > > > > *except* in macOS where you need to modify > > > > LGitLibrary>>macModuleName > > > > to answer 'libgit2.dylib' > > > > > >> On 6 Jan 2017, at 15:14, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > >> > >> No wait, now the list of teams is empty ? I am not in any team anymore ? > >> But I can see my name in the list of members of project Pharo > >> > >> 2017-01-06 15:05 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >> > >> > >> 2017-01-06 15:01 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> I restarted it and now I see 3 projectsâ¦ is that correct? > >> > >> YES > >> > >> Thanks. > >> > >> > >> > >> Esteban > >> > >>> On 5 Jan 2017, at 23:16, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > >>> > >>> All my projects at smalltalkhub.com are gone - again. > >>> (http://smalltalkhub.com/#!/~NicolaiHess) > >> > >> > >> > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Jan. 8, 2017

Re: [Pharo-dev] No Projects at smalltalkhub

by Dimitris Chloupis

I had a merge issue once, but merge issues are normal never saw them as problem and with the git gui client I am using it took me a few seconds to resolve. I have not done a pull request but I do not see why I would have any problem There is also a filetree version without any metadata if I remember correctly that I always wanted to give a try but because I know how to avoid merge issues I never had good enough reason to give it a try. In case of merge issue its just about choosing which version will overwrite the other one which is something my git gui client handles automagically with minimum input from me On Sun, Jan 8, 2017 at 3:50 PM Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > No issues when merging? What about pull-request? > > Alexandre > > > > On Jan 8, 2017, at 10:40 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > has worked perfect for , definetly a tons better than sthub and > squeaksource and definitely more stable . I do not think I ever experienced > a single problem with git and pharo. > > > > On Sun, Jan 8, 2017 at 3:19 PM Stephan Eggermont <stephan(a)stack.nl> > wrote: > > On 08/01/17 12:54, Dimitris Chloupis wrote: > > > Squeaksource ? > > > > > > Was it not made read only ? > > > > It was fixed and seems to be reliable with the current load > > ss3 was always stable > > > > > It's been ages since I last visited sthub and ss3 , I thought you guys > > > would have moved to github by now or some alternative that is far > stable > > > than sthub > > > > No, git support is still bleeding edge. A few times a year I check the > > progress made. Not everything can move to github, and some things need > > support on older versions and other platforms, and it needs to work > > everywhere. Not there yet. > > > > Stephan > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Jan. 8, 2017