- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [OT] SpaceX's Falcon 9 - There and back again

by Sven Van Caekenberghe

> On 22 Dec 2015, at 15:31, Hilaire <hilaire(a)drgeo.eu> wrote: > > Le 22/12/2015 14:02, Sven Van Caekenberghe a Ã©crit : >> This is a really great achievement: SpaceX successfully launched a rocket and deployed 11 satellites after failing earlier this year. But best of all, they landed the first stage back on earth! Consider the actual physics involved, mind boggling. >> >> http://www.wired.com/2015/12/spacex-just-landed-rocket-ground-first-time/ >> >> http://arstechnica.com/science/2015/12/by-making-a-historic-landing-spacex-… >> >> Sven >> >> >> >> > It is a nice achievement indeed. However not sure it is a good idea on > the long term. > The main idea behind the Space shuttle was planed to be cheaper with > reusable components: it proves to be both more expensive and less safe. > Time will tell us. Yes, you are right, they still have to prove they can safely and economically reuse them. But each time throwing away the main stage including a bunch of very expensive rocket engines is not very scaleable either. And agreed, the Space Shuttle's cost/performance is hard to judge, still they flew 135 missions using 4/5 vehicles, making important things possible in space. But it sadly enough did not end well. It is fair to say that space is pretty hard. > Hilaire > > -- > Dr. Geo > http://drgeo.eu > http://google.com/+DrgeoEu > > >

Dec. 22, 2015

Re: [Pharo-dev] [OT] SpaceX's Falcon 9 - There and back again

by Hilaire

Le 22/12/2015 14:02, Sven Van Caekenberghe a Ã©crit : > This is a really great achievement: SpaceX successfully launched a rocket and deployed 11 satellites after failing earlier this year. But best of all, they landed the first stage back on earth! Consider the actual physics involved, mind boggling. > > http://www.wired.com/2015/12/spacex-just-landed-rocket-ground-first-time/ > > http://arstechnica.com/science/2015/12/by-making-a-historic-landing-spacex-… > > Sven > > > > It is a nice achievement indeed. However not sure it is a good idea on the long term. The main idea behind the Space shuttle was planed to be cheaper with reusable components: it proves to be both more expensive and less safe. Time will tell us. Hilaire -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu

Dec. 22, 2015

Re: [Pharo-dev] [OT] SpaceX's Falcon 9 - There and back again

by Dimitris Chloupis

absolutely phenomenal landing, I did not even see it coming that was blazzing fast. My mind was blown thanks for sharing. SpaceX made history once more . Mars here we come, lets send Pharo to mars too :D On Tue, Dec 22, 2015 at 3:03 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > This is a really great achievement: SpaceX successfully launched a rocket > and deployed 11 satellites after failing earlier this year. But best of > all, they landed the first stage back on earth! Consider the actual physics > involved, mind boggling. > > http://www.wired.com/2015/12/spacex-just-landed-rocket-ground-first-time/ > > > http://arstechnica.com/science/2015/12/by-making-a-historic-landing-spacex-… > > Sven > > > >

Dec. 22, 2015

How to create a 16x16 icon from a .png file?

by Alexandre Bergel

Hi! A couple of month ago the following expression was working: ThemeIcons new createIconMethodsFromFile: 'cube' directory: '/Users/alexandrebergel/Desktop/cubeâ Now it does not. How can I import .png files in Pharo? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 22, 2015

[OT] SpaceX's Falcon 9 - There and back again

by Sven Van Caekenberghe

This is a really great achievement: SpaceX successfully launched a rocket and deployed 11 satellites after failing earlier this year. But best of all, they landed the first stage back on earth! Consider the actual physics involved, mind boggling. http://www.wired.com/2015/12/spacex-just-landed-rocket-ground-first-time/ http://arstechnica.com/science/2015/12/by-making-a-historic-landing-spacex-… Sven

Dec. 22, 2015

Re: [Pharo-dev] Object graph stream/visitor implementation?

by Mariano Martinez Peck

Denis, The DeepTraverser was a little easy hack I shared years ago to Tudor Girba which he then (improved it?) put it in Moose. While it works is still very limited. You can give it a try. And if not, please spend some time checking the graph traverser we have in Fuel. I suspect it could be easily adapted for custom code, but I am not sure ;) Basically, check FLAnalysis >> run, which has a stack and starts the trace via #mapAndTrace: Cheers, On Tue, Dec 22, 2015 at 6:20 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > I found this: http://smalltalkhub.com/#!/~Moose/DeepTraverser > > 2015-12-22 10:05 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> >> > On 22 Dec 2015, at 09:46, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> > >> > Hello. >> > >> > Do we have way to traverse object graph? >> > >> > I want stream which iterate object graph through instance variables >> with knowledge about path at every step. >> > >> > Maybe Fuel has classes for this ? >> > >> >> yes, I think so.. there is #fuelAccept:, but I am not sure how general it >> is. >> >> I remember that Doru did some object graph iteration experiments, too? >> (I canât find it). >> >> But I think we should actually add a general âobject graph iteratorâ to >> the reflective >> features of the language. It seems very useful to have, and for sure Fuel >> could just >> use it. >> >> Marcus >> >> >> >> >> > -- Mariano http://marianopeck.wordpress.com

Dec. 22, 2015

Re: [Pharo-dev] VM error in Arch Linux

by Ben Coman

You just happen to coincide with a transition point from V3 system to new Spur system, which gets us ready for native 64-bit. Just as a point of experiment, try Pharo build 50495 rather than (presumably) Pharo-latest. Then look at upgrading PharoLauncher as others described. Cheers -ben On Tuesday, December 22, 2015, nacho <0800nacho(a)gmail.com> wrote: > Hi Folks, > I've installed pharo-vm and pharo-launcher from AUR as stated in the pharo > site. > Everything works fine for Pharo 4. > But when I try to load a Pharo 5 image I get the following error: > This interpreter (vers. 6502) cannot read file image (vers. 6521) > > and when I do pharo --version: > 3.9-7 #1 Thu Dec 17 00:38:38 CET 2015 gcc 4.6.3 [Production ITHB VM] > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Dec 17 2015 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Dec 17 2015 > https://github.com/pharo-project/pharo-vm.git Commit: > bad6fa2684afcf1d7cdb485f11049a4a4290fbc8 Date: 2015-12-14 12:47:06 +0100 > By: > Esteban Lorenzano <estebanlm(a)gmail.com <javascript:;>> Jenkins build > #15024 > Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 > UTC > 2012 i686 i686 i386 GNU/Linux > plugin path: /usr/share/pharo-vm/ [default: /usr/share/pharo-vm/] > > > Any clues? > > Thanks in advance > Nacho > > > > ----- > Nacho > Smalltalker apprentice. > Buenos Aires, Argentina. > -- > View this message in context: > http://forum.world.st/VM-error-in-Arch-Linux-tp4868239.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Dec. 22, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Ferlicot D. Cyril

Le 20/12/2015 12:59, Max Leske a Ã©crit : > I would like to wrap up this discussion. > > > While I think that iterators are an intriguing idea I also believe that > they are beyond the scope of this issue. If anybody wants to follow up > on iterators (or unit types for that matter) please start a new thread / > issue. > > > I propose to use Svenâs version for #sum:ifEmpty:. The result would be > these three methods: > > sum > ^ self > sum: [ :each | each ] > ifEmpty: [ 0 ] > > sum: aBlock > ^ self > sum: aBlock > ifEmpty: [ self errorEmptyCollection ] > > sum: aBlock ifEmpty: emptyBlock > | sum sample | > self isEmpty ifTrue: [ ^ emptyBlock value ]. > sample := self anyOne. > sum := self > inject: sample > into: [ :accum :each | accum + (aBlock value: each) ]. > ^ sum - sample > > > Iâve attached a couple of benchmark results below. To me they show that > 1. the new implementation is maybe a tiny bit slower but insignificantly > so (if youâre going for performance youâll probably write your own > optimised version anyway) > 2. there is no need to duplicate the code (like #sum and #sum: currently > do). Itâs perfectly fine to delegate to #sum:ifEmpty: > > > > In addition to the above changes I would like to remove #detectSum: (-> > #sum:) and #sumNumbers (-> #sum). > > > Note that once we agree on changing this API, we will need to also > change #detectMin:, #detectMax:, #min, #max as well as all overrides > (e.g. RunArray, Interval) of these and of #sum et. al. to stay > consistent. The changes would of course be in line with this change, > such that every operation has a unary selector with a sensible default, > one that takes a block and throws an error for empty collections and a > third that takes a block for the iteration and one for the empty case. > > > Please cast your vote for these changes: > > 1. Do you agree to changing #sum and #sum: in the suggested way? > Yes > 2. Do you agree to the removal of #detectSum:? > Yes > 3. Do you agree to the removal of #sumNumbers? > Yes > 4. Do you agree that the #max and #min selectors also need to be adapted? > Yes > > > Thanks for you help. > > Cheers, > Max > > > > > > Benchmarks > ============ > (Note that these arenât very good benchmarks. Thereâs quite some > variation on each run.) > > > Machine: > MacBook Pro (15-inch, Early 2011) > CPU: 2.2 GHz Intel Core i7 > Memory: 8 GB 1333 MHz DDR3 > Disk: APPLE SSD TS512C (500 GB) > > > Benchmarks of the current versions: > > [ (1 to: 1000000) asArray sum ] benchFor: 10 seconds. > 75 iterations, 7.470 per second > > [ (1 to: 1000000) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 72 iterations, 7.128 per second > > > [ (1 to: 100) asArray sum ] benchFor: 10 seconds. > 1,189,477 iterations, 118,912 per second > > > [ (1 to: 100) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 1,171,467 iterations, 117,112 per second > > > > Benchmarks of the new versions: > > [ (1 to: 1000000) asArray sum ] benchFor: 10 seconds. > 73 iterations, 7.244 per second > > [ (1 to: 1000000) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 75 iterations, 7.480 per second > > [ (1 to: 1000000) asArray sum: [ :e | e ] ifEmpty: [ 0 ] ] benchFor: 10 > seconds. > 72 iterations, 7.141 per second > > > [ (1 to: 100) asArray sum ] benchFor: 10 seconds. > 1,115,827 iterations, 111,560 per second > > [ (1 to: 100) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 1,154,595 iterations, 115,425 per second > > [ (1 to: 100) asArray sum: [ :e | e ] ifEmpty: [ 0 ] ] benchFor: 10 seconds. > 1,102,358 iterations, 110,203 per second > -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Dec. 22, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Nicolai Hess

2015-12-20 12:59 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > > > I propose to use Svenâs version for #sum:ifEmpty:. The result would be > these three methods: > > sum > ^ self > sum: [ :each | each ] > ifEmpty: [ 0 ] > > sum: aBlock > ^ self > sum: aBlock > ifEmpty: [ self errorEmptyCollection ] > > sum: aBlock ifEmpty: emptyBlock > | sum sample | > self isEmpty ifTrue: [ ^ emptyBlock value ]. > sample := self anyOne. > sum := self > inject: sample > into: [ :accum :each | accum + (aBlock value: each) ]. > ^ sum - sample > > > Iâve attached a couple of benchmark results below. To me they show that > 1. the new implementation is maybe a tiny bit slower but insignificantly > so (if youâre going for performance youâll probably write your own > optimised version anyway) > 2. there is no need to duplicate the code (like #sum and #sum: currently > do). Itâs perfectly fine to delegate to #sum:ifEmpty: > > > > In addition to the above changes I would like to remove #detectSum: (-> > #sum:) and #sumNumbers (-> #sum). > there is no #sumNumbers, only #sumNumbers: > > > Note that once we agree on changing this API, we will need to also change > #detectMin:, #detectMax:, #min, #max as well as all overrides (e.g. > RunArray, Interval) of these and of #sum et. al. to stay consistent. The > changes would of course be in line with this change, such that every > operation has a unary selector with a sensible default, one that takes a > block and throws an error for empty collections and a third that takes a > block for the iteration and one for the empty case. > > > Please cast your vote for these changes: > > 1. Do you agree to changing #sum and #sum: in the suggested way? > yes > > 2. Do you agree to the removal of #detectSum:? > yes > > 3. Do you agree to the removal of #sumNumbers? > yes > > 4. Do you agree that the #max and #min selectors also need to be adapted? > hm. I like the "detect". If aCollection detectMax: aBlock becomes aCollection max: aBlock it looks too similar to aCollection size max: aValue But I could live with that :) > > > Thanks for you help. > > Cheers, > Max > > > > > > Benchmarks > ============ > (Note that these arenât very good benchmarks. Thereâs quite some variation > on each run.) > > > Machine: > MacBook Pro (15-inch, Early 2011) > CPU: 2.2 GHz Intel Core i7 > Memory: 8 GB 1333 MHz DDR3 > Disk: APPLE SSD TS512C (500 GB) > > > Benchmarks of the current versions: > > [ (1 to: 1000000) asArray sum ] benchFor: 10 seconds. > 75 iterations, 7.470 per second > > [ (1 to: 1000000) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 72 iterations, 7.128 per second > > > [ (1 to: 100) asArray sum ] benchFor: 10 seconds. > 1,189,477 iterations, 118,912 per second > > > [ (1 to: 100) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 1,171,467 iterations, 117,112 per second > > > > Benchmarks of the new versions: > > [ (1 to: 1000000) asArray sum ] benchFor: 10 seconds. > 73 iterations, 7.244 per second > > [ (1 to: 1000000) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 75 iterations, 7.480 per second > > [ (1 to: 1000000) asArray sum: [ :e | e ] ifEmpty: [ 0 ] ] benchFor: 10 > seconds. > 72 iterations, 7.141 per second > > > [ (1 to: 100) asArray sum ] benchFor: 10 seconds. > 1,115,827 iterations, 111,560 per second > > [ (1 to: 100) asArray sum: [ :e | e ] ] benchFor: 10 seconds. > 1,154,595 iterations, 115,425 per second > > [ (1 to: 100) asArray sum: [ :e | e ] ifEmpty: [ 0 ] ] benchFor: 10 > seconds. > 1,102,358 iterations, 110,203 per second > >

Dec. 22, 2015

Re: [Pharo-dev] VM error in Arch Linux

by Ferlicot D. Cyril

Le 22/12/2015 11:14, nacho a Ã©crit : > Hi Folks, > I've installed pharo-vm and pharo-launcher from AUR as stated in the pharo > site. > Everything works fine for Pharo 4. > But when I try to load a Pharo 5 image I get the following error: > This interpreter (vers. 6502) cannot read file image (vers. 6521) > > and when I do pharo --version: > 3.9-7 #1 Thu Dec 17 00:38:38 CET 2015 gcc 4.6.3 [Production ITHB VM] > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Dec 17 2015 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Dec 17 2015 > https://github.com/pharo-project/pharo-vm.git Commit: > bad6fa2684afcf1d7cdb485f11049a4a4290fbc8 Date: 2015-12-14 12:47:06 +0100 By: > Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #15024 > Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC > 2012 i686 i686 i386 GNU/Linux > plugin path: /usr/share/pharo-vm/ [default: /usr/share/pharo-vm/] > > > Any clues? > Hi, Since last week a new VM is use for Pharo 5 beta. You need to download the new VM on http://files.pharo.org/vm/pharo-spur32/. Then you need to update Pharo Launcher. For now the easiest way I think is to enable the development mode in PharoLauncher, go in Monticello, and load the last version of Pharo Launcher core. Later I think that a new release of Pharo Launcher will make thing easier. Then you can disable the development mode and do Alt + Shift + S to save you image. After this everything should be fine. > Thanks in advance > Nacho > > > > ----- > Nacho > Smalltalker apprentice. > Buenos Aires, Argentina. > -- > View this message in context: http://forum.world.st/VM-error-in-Arch-Linux-tp4868239.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Dec. 22, 2015