October 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] RFB looks terribly broken

by Bernat Romagosa

Hi Lukas, I made a copy of PharoDebug.log publicly accessible from: http://seaside.citilab.eu/PharoDebug.log There are some error messages stating: "An attempt to use interactive tools detected, while in non-interactive mode" And others related to RFB. Cheers, 2011/10/17 Lukas Renggli <renggli(a)gmail.com> > It works for me. Are you using RBF from my repostiory? > > Did you try with a different (newer, older, Pharo) VM? > > Any crash dumps that you want to share? > > Lukas > > On 17 October 2011 13:27, Bernat Romagosa > <tibabenfortlapalanca(a)gmail.com> wrote: > > Hi list, > > I'm not able to develop remotely using the RFB server anymore. The image > > just dies all the time. Examples of behaviours that trigger the crash: > > - Right-clicking on a Workspace > > - Saving a method in a Browser, then selecting another method in the same > > Browser > > Any ideas on why is this happening? The same exact image (with the RFB > > server also running and the same VM) works okay locally, but when I > access > > it remotely it becomes unusable. > > Here's my config: > > 'Pharo1.3' (one click) > > 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog-IgorStasenko.123]' > > Debian 6.0 > > > > Cheers! > > -- > > Bernat Romagosa. > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > -- Bernat Romagosa.

Oct. 17, 2011

[Pharo-project] Linus Torvaldsâs Lessons on Software Development Management

by Ben Coman

While I am waiting for enough time to devote to learning more Smalltalk/Squeak/Pharo, I came across this article [1] which reflected upon recent discussion on Fuel version format compatibility, as well as on other projects. Perhaps it is that it is such a great environment for experimenting with ideas that it encourages developers to do so, but it seems that functionality often becomes orphaned as the trunk progresses. I see some efforts provide a more professional platform, and understand that involves 'some' ripping/replacement of unmaintainable code, but which contradicts the philosophy of 'no regressions' mentioned in the article - which in practice I imagine a hard line to walk. Linux is the poster child of open source development success, and while it is more mature that Pharo such that the presented philosophy might not fit exactly, perhaps something can be learned. I hope you find parts of it interesting. cheers, Ben [1] http://h30565.www3.hp.com/t5/Feature-Articles/Linus-Torvalds-s-Lessons-on-S…

Oct. 17, 2011

Re: [Pharo-project] RFB looks terribly broken

by Lukas Renggli

It works for me. Are you using RBF from my repostiory? Did you try with a different (newer, older, Pharo) VM? Any crash dumps that you want to share? Lukas On 17 October 2011 13:27, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: > Hi list, > I'm not able to develop remotely using the RFB server anymore. The image > just dies all the time. Examples of behaviours that trigger the crash: > - Right-clicking on a Workspace > - Saving a method in a Browser, then selecting another method in the same > Browser > Any ideas on why is this happening? The same exact imageÂ (with the RFB > server also running and the same VM)Â works okay locally, but when I access > it remotely it becomes unusable. > Here's my config: > Â 'Pharo1.3' (one click) > Â 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog-IgorStasenko.123]' > Debian 6.0 > > Cheers! > -- > Bernat Romagosa. > -- Lukas Renggli www.lukas-renggli.ch

Oct. 17, 2011

Re: [Pharo-project] How to use freetype?

by Gary Chambers

Try LogicalFont familyName: 'Arial' pointSize: 24 Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, October 17, 2011 1:19 PM Subject: [Pharo-project] How to use freetype? >I feel a bit confused. > > I want to do something as easy as: > > font := Something fontByName: 'Arial'. > > but the problem is that i cannot find anything like that in freetype. > > There is > FreeTypeFontProvider fontFor: aLogicalFont familyName: familyName > > but i puzzled, why it needs a logical font and why i should create it? > > Is there a general way to programmatically say: give me font 'Arial' pt > size 9, > or nil, if font cannot be found? > > -- > Best regards, > Igor Stasenko. >

Oct. 17, 2011

Re: [Pharo-project] When will Fuel file format stabilize?

by Igor Stasenko

My 2 cents: i understand that people want to have backwards compatibility, so they could read even 10 years old data from files. now, it could mean a lot of effort to do that. For instance, if your binary model is spawned along 30 classes, then in order to support 2 versions of it, you need another 30 classes.. 3 versions - 90 classes, and so on. So i am thinking that a least painful way could be to create a migration or "upgrade" scripts which people can use to update their data from old format to new one, and put it in a separate package, to not burden a main development line with cruft. Then it will be like a patch system. This is how i imagine it: suppose that you having 2.0 version installed in your system, but want to load 1.6 version data. you load an additional package(s) titled like: migrating 1.6 -> 1.7 migrating 1.7 -> 1.8 migrating 1.8 -> 2.0 and then run migration scripts for your data until you get to the current version. Once you done, you can unload this stuff and be happy. And i think it is also cheaper for developers: it takes an effort to write a new migration procedure every time you changing a format, but you don't have to keep everything in one place and change a model to be compatible with everything. A migration scripts should do their work, while core model and implementation can be kept clean from cruft. -- Best regards, Igor Stasenko.

Oct. 17, 2011

Re: [Pharo-project] Can this be improved in Glamourous?

by csrabak＠bol.com.br

Em 16/10/2011 18:20, Marcus Denker < marcus.denker(a)inria.fr > escreveu: > Hello, > Can people in general *delete* the quoted email parts to a level > that one does need to scroll down 5 pages to read the answer? +1 It is really a must for us that want to keep with the volume of e-mails but have to be parsimonious on the time spent for it. -- Cesar Rabak

Oct. 17, 2011

Re: [Pharo-project] When will Fuel file format stabilize?

by Mariano Martinez Peck

Well...thanks guys. The point is taken. Thanks Philip, Bill and all who gave feedback and suggestions. We are aware of this and we are already discussing with Martin possible solutions and analyzing all the things that has been said in this thread. We will keep you informed. Cheers On Sun, Oct 16, 2011 at 5:14 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Oct 16, 2011, at 4:05 PM, Schwab,Wilhelm K wrote: > > > Stef, Mariano, > > > > There are obvious advantages to a development phase during which > serialized streams are at risk. At some point, I suspect Fuel will have to > take the reading of old streams as a nearly sacred obligation. Otherwise, > it sounds like a cheap horror movie series: "Fuel II: Your data go in, but > they don't come out." > > With Fuel II no zombies :) > > Fuel III the zombies are dead again :) > > > I am using humor to make a point, not to ridicule you. I read the paper, > and learned a LOT. Please see my post from yesterday referring to Dolphin's > #environment. You might be able to simply facade old formats into a > coherent backwardly-compatible whole. Without some attention to that, there > are going to be projects that will not adopt Fuel. > > > > Bill > > > > > > ________________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano Martinez > Peck [marianopeck(a)gmail.com] > > Sent: Sunday, October 16, 2011 9:03 AM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] When will Fuel file format stabilize? > > > > On Sun, Oct 16, 2011 at 3:01 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com<mailto:marianopeck@gmail.com>> wrote: > > > > > > On Sun, Oct 16, 2011 at 2:03 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: > > Mariano I think that the point that Philippe (our national butcher) is > trying to make is the following: > > If by design a serializer takes the perspective that it will be able to > load old formats and ensure > > evolution all the time then you have a really cool serializer. > > > > Yes, I know. The problem is if it is worth it. The effort of providing > such feature could be too much in compare to just load a previous version, > materialize, load new version, and serialize again. > > > > > > Now why in fuel it is not possible to have > > FuelMaterializer load: aFile > > > > load using the default = current format > > > > > > FuelMaterializer load: aFile asOfVersion: 1.4 > > Of course this can be much slower but when you want to load data of > the past you are just happy that this is > > working. > > > > So would not be possible to > > milestone formats > > get the default working fast > > get old version loading slowler but loading. > > > > > > It sounds easy, but at least from what I can see this is very > complicated. > > Do you know a serializer that support this? Lets clarify with an > example: > > > > > > (of course, without putting all along the code IFs like (version > 2) > ifTrue: [blabla] ) > > > > > > I serialize graph X with Fuel 1.4 in Pharo 1.1. > > Then I am in Pharo 1.3 with Fuel 1.7 and I want to materialize X. Fuel > 1.4 doesn't load anymore in Pharo 1.3, so you have to use Fuel 1.7. > > So you want to be able to take Fuel 1.7 and materialize X "using version > 1.4" without even loading 1.4 (because it doesn't load) ? > > > > Thanks > > > > > > Because then we get a win win situation. > > Stef > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > > -- Mariano http://marianopeck.wordpress.com

Oct. 17, 2011

[Pharo-project] How to use freetype?

by Igor Stasenko

I feel a bit confused. I want to do something as easy as: font := Something fontByName: 'Arial'. but the problem is that i cannot find anything like that in freetype. There is FreeTypeFontProvider fontFor: aLogicalFont familyName: familyName but i puzzled, why it needs a logical font and why i should create it? Is there a general way to programmatically say: give me font 'Arial' pt size 9, or nil, if font cannot be found? -- Best regards, Igor Stasenko.

Oct. 17, 2011

[Pharo-project] RFB looks terribly broken

by Bernat Romagosa

Hi list, I'm not able to develop remotely using the RFB server anymore. The image just dies all the time. Examples of behaviours that trigger the crash: - Right-clicking on a Workspace - Saving a method in a Browser, then selecting another method in the same Browser Any ideas on why is this happening? The same exact image (with the RFB server also running and the same VM) works okay locally, but when I access it remotely it becomes unusable. Here's my config: 'Pharo1.3' (one click) 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog-IgorStasenko.123]' Debian 6.0 Cheers! -- Bernat Romagosa.

Oct. 17, 2011

Re: [Pharo-project] Fwd: trying to understand loops in pharo

by Levente Uzonyi

On Sun, 16 Oct 2011, StÃ©phane Ducasse wrote: > > On Oct 16, 2011, at 10:33 PM, Nicolas Cellier wrote: > >> Ah, I see, this sound appealing. >> But I would object this: (I'm speaking of do:, not only to:do:) >> 1) what the last value mean for unordered collections? >> 2) for a SequenceableCollection, the behavior is already >> (someCollection inject: nil into: [:void :each | aBlock value: each]) >> 3) returning the last value in all implementors of #do: would cost >> complexification of code and possibly slow down (non clean blocks) >> >> Is it really useful? > > Not really I do not like the idea to rely on it. > but in that case the code you be explicit > > #undefined/nil > should be the last expression of the block. > > My point was: the semantics of a block is to return the last expression and we should be consistent with that. The block returns the last expression, but in this case a method returns the value. Here's an example: (1 to: 10) collect: [ :each | each squared ]. You don't expect to get 100 as the result, do you? :) Levente > > Stef > >> >> Nicolas >> >> 2011/10/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> for me the last expression of the block. >>> >>> Stef >>>>>> Which return value would be useful? >>>>> >>>>> That's not the right question. IMO the compiler should answer the same >>>>> result as the non-inlined one when the return value is asked for. Arguably >>>>> the non-inline version needs to be commented to specify that it returns the >>>>> value it does (in this case self), and that the compiler's optimiser >>>>> reflects this. >>>>> >>>> >>>> Agree, but I was wondering what useful object this common answer could be? >>>> >>>>>> >>>>>> Nicolas >>>>>> >>>>>> 2011/10/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>>> A friend of mine ask me the following >>>>>>> >>>>>>> |result| >>>>>>> result := String new. >>>>>>> 1 to: 10 do: [:n | result := result, n printString, ' ']. >>>>>>> I am trying to do or print this code. It prints 'nil' instead of a >>>>>>> collection. Its an example from PBE book. >>>>>>> do you know the reason? >>>>>>> although this one's working: >>>>>>> result := String new. >>>>>>> (1 to: 10) do: [:n | result := result, n printString, ' ']. >>>>>>> >>>>>>> I checked the implementation >>>>>>> Interval>>do: aBlock >>>>>>> "Evaluate aBlock for each value of the interval. >>>>>>> Implementation note: instead of repeatedly incrementing the value >>>>>>> aValue := aValue + step. >>>>>>> until stop is reached, >>>>>>> We prefer to recompute value from start >>>>>>> aValue := start + (index * step). >>>>>>> This is better for floating points accuracy, while not degrading Integer >>>>>>> and >>>>>>> Fraction speed too much. >>>>>>> Moreover, this is consistent with methods #at: and #size" >>>>>>> | aValue index size | >>>>>>> index := 0. >>>>>>> size := self size. >>>>>>> [index < size] >>>>>>> whileTrue: [aValue := start + (index * step). >>>>>>> index := index + 1. >>>>>>> aBlock value: aValue] >>>>>>> >>>>>>> Number>>to: stop do: aBlock >>>>>>> "Normally compiled in-line, and therefore not overridable. >>>>>>> Evaluate aBlock for each element of the interval (self to: stop by: 1)." >>>>>>> | nextValue | >>>>>>> nextValue := self. >>>>>>> [nextValue <= stop] >>>>>>> whileTrue: >>>>>>> [aBlock value: nextValue. >>>>>>> nextValue := nextValue + 1] >>>>>>> >>>>>>> any further idea than := value is different from value: >>>>>>> Stef >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> best, >>>>> Eliot >>>>> >>>> >>> >>> >>> >> > > >

Oct. 17, 2011