- Pharo-dev - lists.pharo.org

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

by dimitris chloupis

I learned my lesson once, back in my University days, I was doing a law essay in English (Greek is my mother tongue so definitely not easy) , I was working for hours , back then microsoft word had no auto save, forgot to save, accidentally close the window , bye bye work. That was 1999-2000. Suffice to say that I was typing like insane few hours before submitting my work. It was not just that I would fail my course Â (just a single subject of it) if I did not submit but I would get only 50% grade cause English unis dont allows you to get more if you redo an essay, exam whatever. So really bad experience. >From there on , all is online baby. Me and the Internet are closest friends. Time machine is a recent friend, I am already using DropBox for my law documents (microsoft word), MediaFire for my big files , soundclick for the music I compose and souncloud. Code has been before smalltalk that I was doing python only github and now for pharo smalltalkhub. So I rarely keep things locally, of course with time machine I have covered that corner too. Â Â On Friday, 18 October 2013, 8:34, Norbert Hartl <norbert(a)hartl.name> wrote: 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] realtime

by Frank Shearar

On 18 October 2013 08:22, Paul Davidowitz <pdavidow(a)fastmail.fm> wrote: > 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.) StÃ©phane Rollandin has been doing audio work in Squeak (in the form of the mu0 application) for many years now, so it should be perfectly possible in Pharo. frank > Thanks, > -Paul >

Oct. 18, 2013

Re: [Pharo-dev] The Pharo 3 theme

by Esteban Lorenzano

I started to experiment with a dark theme (after Phil asked it). The problem is that everything in morphic is so crapy programmed that remove the hardcoding stuff is incredible hard. Anyway, I have an initial design that could work (at least for the simple skins), now it remains the work of decoupling the skin from the morphs... no idea when I will finish anyway. Esteban On Oct 18, 2013, at 10:26 AM, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > I completely agree, I hate it as much I hate apples new scroll bar, that disappear as soon as you stop scrolling with magic mouse making them impossible to use manually. Also what with all the white ? I seriously need to make a dark theme for pharo, my eyes start hurting ..... aaaaaaaaaaaa ;D > > > On Friday, 18 October 2013, 11:02, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > yesterday I also adding settings for IconSet... so you should be able to play around with themes and icons :) > > On Oct 18, 2013, at 10:06 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Is unusable on some brightness settings: the scroll bars become invisible to my old eyes :) > > > > Thierry > > -- > > Thierry Goubier > > CEA list > > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > > 91191 Gif sur Yvette Cedex > > France > > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > > > >

Oct. 18, 2013

Re: [Pharo-dev] The Pharo 3 theme

by dimitris chloupis

I completely agree, I hate it as much I hate apples new scroll bar, that disappear as soon as you stop scrolling with magic mouse making them impossible to use manually. Also what with all the white ? I seriously need to make a dark theme for pharo, my eyes start hurting ..... aaaaaaaaaaaa ;D On Friday, 18 October 2013, 11:02, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: yesterday I also adding settings for IconSet... so you should be able to play around with themes and icons :) On Oct 18, 2013, at 10:06 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Is unusable on some brightness settings: the scroll bars become invisible to my old eyes :) > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

Oct. 18, 2013

Re: [Pharo-dev] realtime

by dimitris chloupis

MIDI is not a concern because MIDI is slooooooooowwwwwwww far slower than pharo. Audio processing now thats tricky at 44khz per second that a lot of calculations and general speaking you would not want to use smalltalk for that part. Even C has to be heavily optimised and you need to 100% know what you doing.Â When things come down to language speed, there is a huge "IT DEPENDS" , you know the one that is carried as a huge labeled panel by small airplanes in the sky. So pharo offers you actually loads of options on this one.Â 1) FFI , now with this option you can call compiled libs from pharo, nativeboost is the modern solution but there are older FFIs too that pharo has carried from squeak. This way you can use existing C libs that do the job. 2) C compiling, now in this case you may want to compile your own C code, again you can use FFI or you can compile it as a VM plugin. Its up to you. I think this is how Etoys in Squeak implements the FM synthesizer. 3) Assembly , with nativeboost now its allowed to inline assembly code, this option has the advantages that everything is kept at smalltalk side, of course you still code in assembly and compilation is automatic so you dont need to worry about that. But assembly is platform specific so you will need create different code for different platforms. Â Of course machine code is blazzing fast.Â 4) Sockets, now this is not an obvious solutions but is what I am considering for my project Ephestos, There are like tons of midi and audio tools that can be operated by sockets. The biggest example is supercollider, supercollider has a server that does all the audio and mid processing, generally you communicate with its server via sclang which is language that copies smalltalk features heavily. However there is also the option of communication via sockets and to be precise using the osc protocol which is actually a replacement to MIDI far more powerful and far more faster. This option is also a great one because supercollider is a beast , with tons of features, a big community and a tool that has well proven its worth for over a decade now. Its far more powerful than any MIDI or AUDIO app you have used and unlike other tools is not only realtime but live coding orientated like pharo. So my goal is to bring eventualy supercollider to pharo users. But its not a big priority of mine right now.Â So those are more or less your options. As you can see its not only doable , but doable in many diffirent ways, every one with its advantage and disadvantage , so pick your poison and carry on ;)Â Please not that this ways are implemented in any other language , apart from nativeboost of course.Â About GC , well in that case when you call a C lib or do machine code via nativeboost assembler you bypass GC unless you use smalltalk objects, AFAIK VM stops any action and executes your C / Assembly code and resumes after execution. However there will be an overhead to compile the code and to call the code. That means generally that you will need to profile and see how much code needs to be ported to assembly/C to reduce these overheads. Â Its all about having a good idea how your code works. Â My sockets solution also wont have you worried about GC since it throws all heavy computation to the supercollider server , that means way less things to worry about. Apparently you can have your cake and eat it too ;)Â On Friday, 18 October 2013, 10:23, Paul Davidowitz <pdavidow(a)fastmail.fm> wrote: 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

The Pharo 3 theme

by Goubier Thierry

Is unusable on some brightness settings: the scroll bars become invisible to my old eyes :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Oct. 18, 2013

Re: [Pharo-dev] The Pharo 3 theme

by Esteban Lorenzano

yesterday I also adding settings for IconSet... so you should be able to play around with themes and icons :) On Oct 18, 2013, at 10:06 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Is unusable on some brightness settings: the scroll bars become invisible to my old eyes :) > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

Oct. 18, 2013

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

by Esteban Lorenzano

On Oct 18, 2013, at 9:57 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Hi Esteban, > > I'm porting to the new RPackage and I have a few questions: > > * What is the best way to get the RPackage linked to a MCWorkingCopy? I use > > aMCWorkingCopy packageSet packages first > > But is there a better way to do it? well... it should, but it isn't :( I suppose RPackageOrganizer default packageNamed: aMCWorkingCopy packageName should work, but I didn't implemented (feel free to do it and commit a slice :). > > * For tags, if the package has only a system category with the same name as the package, will this result in one tag or no tag (i.e. will there be at least one tag in a RPackage?) there will be always one tag (homonym to its parent) > * RPackageTag has a few assymetries: adding a class to a tag doesn't change its system category, however renaming a tag reclassifies the classes in the tag... mmm... yes, I'm more or less aware. We should fix that, but still not sure how (easiest when is to make the add tag to inform a new system category, but then also rename/remove). Again... if you want to help there, please do it! > * Tracking changes to tags suppose in fact listening to system-category announcements, isn't it? yep :( anyway, next year I will remove also System Categories, but in the mean time we need the sync. > Otherwise, porting to the new RPackage is going along fine :) Thanks for the effort. cool! > I haven't found the new Nautilus yet :( why? it is there :) Esteban > > Thierry > > Le 17/10/2013 15:51, Esteban Lorenzano a Ã©crit : >> yes, because package names changed (no more 1 rpackage = 1 system category), then the export of sources changed too (not the contents). >> >> For example, what was AST-Core-*, now is just AST-Core. >> >> Esteban >> >> On Oct 17, 2013, at 2:51 PM, Marcus Denker <marcus.denker(a)gmail.com> wrote: >> >>> >>> >>>> On 17.10.2013, at 13:11, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>> >>>> Strange... the commit is already there :) >>>> >>> >>> >>> too large for the list (7mb) >>>> https://github.com/pharo-project/pharo-core/commit/39e14deac5f2ad03e2d1b539… >>>> >>>>> On 2013-10-17, at 13:08, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>> >>>>> he... the update is already there, github failed to send the diff info (yet) >>>>> >>>>>> On Oct 17, 2013, at 1:09 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Le 17/10/2013 12:51, Esteban Lorenzano a Ã©crit : >>>>>>> >>>>>>> On Oct 17, 2013, at 12:57 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>>>>>> >>>>>>>> Are you using MorphTreeMorph? >>>>>>> yep :) >>>>>> >>>>>> I haven't tried to use multi-selection in the tree; the code to handle multi-selection looks fairly complex. >>>>>> >>>>>> I remember having difficulties to understand how to pass and receive objects through drag and drop. >>>>>> >>>>>> I'll have a look as soon as I see the update coming. Unless loading the last Nautilus packages in Pharo3Inbox works :) >>>>>> >>>>>> Thierry >>>>>> >>>>>>>> >>>>>>>> Thierry >>>>>>>> >>>>>>>> Le 17/10/2013 12:46, Esteban Lorenzano a Ã©crit : >>>>>>>>> btw, a couple things that I know still doesn't work in Nautilus with trees: >>>>>>>>> >>>>>>>>> - drag and drop (I failed miserably when trying to implement it, any help here would be welcome :) >>>>>>>>> - multiselection in packages >>>>>>>>> >>>>>>>>> Esteban >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 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 >>>>>>>> >>>>>>>> -- >>>>>>>> Thierry Goubier >>>>>>>> CEA list >>>>>>>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>>>>>>> 91191 Gif sur Yvette Cedex >>>>>>>> France >>>>>>>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>>>>> >>>>>> -- >>>>>> Thierry Goubier >>>>>> CEA list >>>>>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>>>>> 91191 Gif sur Yvette Cedex >>>>>> France >>>>>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>>> >>> >> >> >> > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

Oct. 18, 2013

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

by Goubier Thierry

Hi Esteban, I'm porting to the new RPackage and I have a few questions: * What is the best way to get the RPackage linked to a MCWorkingCopy? I use aMCWorkingCopy packageSet packages first But is there a better way to do it? * For tags, if the package has only a system category with the same name as the package, will this result in one tag or no tag (i.e. will there be at least one tag in a RPackage?) * RPackageTag has a few assymetries: adding a class to a tag doesn't change its system category, however renaming a tag reclassifies the classes in the tag... * Tracking changes to tags suppose in fact listening to system-category announcements, isn't it? Otherwise, porting to the new RPackage is going along fine :) Thanks for the effort. I haven't found the new Nautilus yet :( Thierry Le 17/10/2013 15:51, Esteban Lorenzano a Ã©crit : > yes, because package names changed (no more 1 rpackage = 1 system category), then the export of sources changed too (not the contents). > > For example, what was AST-Core-*, now is just AST-Core. > > Esteban > > On Oct 17, 2013, at 2:51 PM, Marcus Denker <marcus.denker(a)gmail.com> wrote: > >> >> >>> On 17.10.2013, at 13:11, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> >>> Strange... the commit is already there :) >>> >> >> >> too large for the list (7mb) >>> https://github.com/pharo-project/pharo-core/commit/39e14deac5f2ad03e2d1b539… >>> >>>> On 2013-10-17, at 13:08, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> >>>> he... the update is already there, github failed to send the diff info (yet) >>>> >>>>> On Oct 17, 2013, at 1:09 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>>>> >>>>> >>>>> >>>>> Le 17/10/2013 12:51, Esteban Lorenzano a Ã©crit : >>>>>> >>>>>> On Oct 17, 2013, at 12:57 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>>>>> >>>>>>> Are you using MorphTreeMorph? >>>>>> yep :) >>>>> >>>>> I haven't tried to use multi-selection in the tree; the code to handle multi-selection looks fairly complex. >>>>> >>>>> I remember having difficulties to understand how to pass and receive objects through drag and drop. >>>>> >>>>> I'll have a look as soon as I see the update coming. Unless loading the last Nautilus packages in Pharo3Inbox works :) >>>>> >>>>> Thierry >>>>> >>>>>>> >>>>>>> Thierry >>>>>>> >>>>>>> Le 17/10/2013 12:46, Esteban Lorenzano a Ã©crit : >>>>>>>> btw, a couple things that I know still doesn't work in Nautilus with trees: >>>>>>>> >>>>>>>> - drag and drop (I failed miserably when trying to implement it, any help here would be welcome :) >>>>>>>> - multiselection in packages >>>>>>>> >>>>>>>> Esteban >>>>>>>> >>>>>>>> >>>>>>>>> On 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 >>>>>>> >>>>>>> -- >>>>>>> Thierry Goubier >>>>>>> CEA list >>>>>>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>>>>>> 91191 Gif sur Yvette Cedex >>>>>>> France >>>>>>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>>>> >>>>> -- >>>>> Thierry Goubier >>>>> CEA list >>>>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>>>> 91191 Gif sur Yvette Cedex >>>>> France >>>>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>> >> > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Oct. 18, 2013

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

by Norbert Hartl

Am 18.10.2013 um 09:35 schrieb Francisco Garau <francisco.garau(a)gmail.com>: > 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. > genGen := [ : initial | | current | current := initial. [ current := current + 1 ] ]. gen := genGen value: 10. gen2 := genGen value: 50. (1 to: 10) inject: OrderedCollection new into: [ :col :elem | col add: gen value. col add: gen2 value. col ] ;) Norbert >> >> 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