- Pharo-dev - lists.pharo.org

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

by Igor Stasenko

On 17 October 2011 15:14, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: > Try > > LogicalFont > Â familyName: 'Arial' > Â pointSize: 24 > Thanks. This is what i was looking for. > 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. >> > > > -- Best regards, Igor Stasenko.

Oct. 17, 2011

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