- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Generators implemented only with blocks

by Francisco Garau

Hi - On 18 Oct 2013, at 06:54, Norbert Hartl <norbert(a)hartl.name> wrote: > Why not just > > gen := [ | current | > current := 0. > [ current := current + 1 ] ] value. > Much concise indeed. But I am trying to have several generators instantiated from the same block definition and be able to set their initial values to any number. Just for fun, of course. > > I think there is two sides of using blocks. One is the ability to carry some code around which is a useful thing. The other one is that encloses over the current environement. The latter is something that you can use for quite powerful stuff. But it is also something people have problems to understand and that can easily introduce problems in code because you didn't think of what it does. > Just remember the last problem with announcements that was caused by blocks. So blocks are to me like a lot of other programming techniques: If you don't really need them don't use them. > > Norbert > > Am 18.10.2013 um 00:46 schrieb Francisco Garau <francisco.garau(a)gmail.com>: > >> Hi >> >> As an exercise, I've implemented a simple Generator using only blocks: >> >> gen := >> [ >> [ | currentValue | >> Array >> with: [ currentValue := 0 ] >> with: [ currentValue := currentValue + 1 ] >> ] value >> ] value. >> >> gen first value. >> next := [:a | a last value]. >> >> getTen := [(1 to: 10) collect: [ :i | next value: gen ]]. >> >> getTen value = #(1 2 3 4 5 6 7 8 9 10). >> getTen value = #(11 12 13 14 15 16 17 18 19 20). >> >> >> There have been some funny arguments in the past whether Blocks are a fundamental part of Smalltalk or not. My code above supports Vassili's view that we could get rid of Objects and implement everything in terms of Blocks. >> >> http://live.exept.de/doc/online/english/programming/humor.html >> >> But more seriously, I find it quite interesting that Lars Bak choose not to implement Blocks for his Resilient Smalltalk. He choose to implement LIFO blocks; that is, blocks that cannot survive the creating activation context (see chapter 2.3 for more details). >> >> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84.7354&rep=rep1&t… >> >> - Francisco >> >

Oct. 18, 2013

realtime

by Paul Davidowitz

Can Pharo be used for 'realtime' applications such as music midi or metronome? Isn't garbage collection a concern? (But I once read that Tektronix used Smalltalk in their oscilloscopes.) Thanks, -Paul

Oct. 18, 2013

Re: [Pharo-dev] Generators implemented only with blocks

by btc＠openinworld.com

Oct. 18, 2013

Re: [Pharo-dev] Generators implemented only with blocks

by Norbert Hartl

Why not just gen := [ | current | current := 0. [ current := current + 1 ] ] value. ? I think there is two sides of using blocks. One is the ability to carry some code around which is a useful thing. The other one is that encloses over the current environement. The latter is something that you can use for quite powerful stuff. But it is also something people have problems to understand and that can easily introduce problems in code because you didn't think of what it does. Just remember the last problem with announcements that was caused by blocks. So blocks are to me like a lot of other programming techniques: If you don't really need them don't use them. Norbert Am 18.10.2013 um 00:46 schrieb Francisco Garau <francisco.garau(a)gmail.com>: > Hi > > As an exercise, I've implemented a simple Generator using only blocks: > > gen := > [ > [ | currentValue | > Array > with: [ currentValue := 0 ] > with: [ currentValue := currentValue + 1 ] > ] value > ] value. > > gen first value. > next := [:a | a last value]. > > getTen := [(1 to: 10) collect: [ :i | next value: gen ]]. > > getTen value = #(1 2 3 4 5 6 7 8 9 10). > getTen value = #(11 12 13 14 15 16 17 18 19 20). > > > There have been some funny arguments in the past whether Blocks are a fundamental part of Smalltalk or not. My code above supports Vassili's view that we could get rid of Objects and implement everything in terms of Blocks. > > http://live.exept.de/doc/online/english/programming/humor.html > > But more seriously, I find it quite interesting that Lars Bak choose not to implement Blocks for his Resilient Smalltalk. He choose to implement LIFO blocks; that is, blocks that cannot survive the creating activation context (see chapter 2.3 for more details). > > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84.7354&rep=rep1&t… > > - Francisco >

Oct. 18, 2013

Re: [Pharo-dev] recovering from a deep disc crashâ¦.

by Norbert Hartl

Am 17.10.2013 um 23:10 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > so backup your machineâ¦ because mine was still working at 8h this morning and 8h40 dropped dead Really strange to see that people _know_ things can break but they wonder if their own stuff breaks _all of a sudden_. :) For Mac users there are two really good options. One is using timemachine and the other is using Arq[1] that makes timemachine like backups on amazon S3. Works like a charm from wherever you are. For both options you need to spend money. But it is nothing compared to the pain of loosing all your data. Really! If you don't want to spend money or don't have a mac you can still make backups to another computer using rsync. You'll find plenty of articles if you search the net for rsync and backup. Norbert [1] http://www.haystacksoftware.com/arq/ [2] http://rsync.samba.org/

Oct. 18, 2013

Re: [Pharo-dev] IMPORTANT: RPackage behavior changed and Nautilus updated

by Tudor Girba

Excellent! Doru p.s. It's amazing how often I feel like saying "amazing" about Pharo these days :) On Thu, Oct 17, 2013 at 12:20 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > Hi, > > I just important an important change in Pharo. > I made a new step over the integration of RPackage into the system, and as > a result there is a different behavior. > Although 99% of users shouldn't notice it, that can drive to headaches to > tool developers, like Thierry and his AltBrowser (but I'm not sure about > that) :) > I'm sorry, but this is inevitable... and part of a long path discussed and > adopted since almost 1 1/2 years. > > So, what's the change? > Now 1 RPackage 0 1 MCPackage. > As a result, package granularity is coarse, and then categories for class > are stored as package tags. > Other consequence is that RPackageSet is now more or less useless, but I'm > keeping it because it provides caching services for monticello, and the > speed up resulting is good :) > This change opens the path to remove old PackageInfo, finally :) > > To take the new structure into account (and to add a long time awaited > feature), I modified nautilus to use a tree instead a simple list (finally!) > And since I was in the mood, I moved groups to same list, taking the idea > of the screenshot Stef sent the other day (lots of good ideas that we > should adopt there), and then I removed the "groups" button... in > functionality is good, but visually not so much... I accept ideas about :) > > THERE WILL BE BUGS! > This is a really deep and important change, I'm pushing it because we need > to test and fix. So, do not hesitate to send your reports! > Also, there are features in modified-nautilus that are missing. It would > be good to have a list of them so I can implement it :) > > Please, report any issue around. > > Enjoy, > Esteban > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 18, 2013

Fwd: Generators implemented only with blocks

by Francisco Garau

Hi As an exercise, I've implemented a simple Generator using only blocks: gen := [ [ | currentValue | Array with: [ currentValue := 0 ] with: [ currentValue := currentValue + 1 ] ] value ] value. gen first value. next := [:a | a last value]. getTen := [(1 to: 10) collect: [ :i | next value: gen ]]. getTen value = #(1 2 3 4 5 6 7 8 9 10). getTen value = #(11 12 13 14 15 16 17 18 19 20). There have been some funny arguments in the past whether Blocks are a fundamental part of Smalltalk or not. My code above supports Vassili's view that we could get rid of Objects and implement everything in terms of Blocks. http://live.exept.de/doc/online/english/programming/humor.html But more seriously, I find it quite interesting that Lars Bak choose not to implement Blocks for his Resilient Smalltalk. He choose to implement LIFO blocks; that is, blocks that cannot survive the creating activation context (see chapter 2.3 for more details). http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84.7354&rep=rep1&t… - Francisco

Oct. 17, 2013

Re: [Pharo-dev] IMPORTANT: RPackage behavior changed and Nautilus updated

by Camille Teruel

On 17 oct. 2013, at 12:20, Esteban Lorenzano wrote: > Hi, > > I just important an important change in Pharo. > I made a new step over the integration of RPackage into the system, and as a result there is a different behavior. > Although 99% of users shouldn't notice it, that can drive to headaches to tool developers, like Thierry and his AltBrowser (but I'm not sure about that) :) > I'm sorry, but this is inevitable... and part of a long path discussed and adopted since almost 1 1/2 years. > > So, what's the change? > Now 1 RPackage 0 1 MCPackage. Awesome!! > As a result, package granularity is coarse, and then categories for class are stored as package tags. Fantastic!!! > Other consequence is that RPackageSet is now more or less useless, but I'm keeping it because it provides caching services for monticello, and the speed up resulting is good :) > This change opens the path to remove old PackageInfo, finally :) > To take the new structure into account (and to add a long time awaited feature), I modified nautilus to use a tree instead a simple list (finally!) Fabulous!!! > And since I was in the mood, I moved groups to same list, taking the idea of the screenshot Stef sent the other day (lots of good ideas that we should adopt there), and then I removed the "groups" button... in functionality is good, but visually not so much... I accept ideas about :) > THERE WILL BE BUGS! > This is a really deep and important change Indeed! Esteban, thank you for all your hard work. Now I'm forced to believe in god. He and I are working in the same office ;) > , I'm pushing it because we need to test and fix. So, do not hesitate to send your reports! > Also, there are features in modified-nautilus that are missing. It would be good to have a list of them so I can implement it :) > > Please, report any issue around. > Enjoy, > Esteban > > >

Oct. 17, 2013

recovering from a deep disc crashâ¦.

by Torsten Bergmann

Hope you dont burn the disk packs and start something new when things starts to get interesting ...

Oct. 17, 2013

Re: [Pharo-dev] recovering from a deep disc crashâ¦.

by Alexandre Bergel

Time machine is wonderful for this... Alexandre On Oct 17, 2013, at 6:10 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > so backup your machineâ¦ because mine was still working at 8h this morning and 8h40 dropped dead > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 17, 2013