[Pharo-project] Removing default fonts
In another thread (Pharo image size: 10.9MB) I proposed to remove all but one font since the ones in the image (especially the TT fonts) are not really useful but consume memory. Hilaire suggested to keep Accujen, which to my eyes looks better than the default Accuny font (not perfect, but better..). So I suggest to change the default to Accujen, keep the current default Accuny, and remove all other fonts. The script below does this so you can try it out if you are interested. It frees roughly 2k, but eventually with more cleanup it will have a bigger impact because the TT font instances are still referenced from other places in the system. Adrian Preferences setDefaultFonts: #( (setSystemFontTo: 'Accujen' 12) (setListFontTo: 'Accujen' 12) (setMenuFontTo: 'Accujen' 12) (setFlapsFontTo: 'Accujen' 14) (setEToysFontTo: 'Accujen' 12) (setPaintBoxButtonFontTo: 'Accujen' 12) (setWindowTitleFontTo: 'Accujen' 12) (setBalloonHelpFontTo: 'Accujen' 12) (setCodeFontTo: 'Accujen' 12) (setButtonFontTo: 'Accujen' 12)). Preferences setWindowTitleFontTo: (Preferences windowTitleFont emphasized: 1). Preferences setFlapsFontTo: Preferences windowTitleFont. TextConstants associations do: [ :association | ((association value isKindOf: TextStyle) and: [ association key ~= #Accuny ] and: [ association key ~= #Accujen ] and: [ (TextStyle defaultFamilyNames includes: association key) not ]) ifTrue: [ TextConstants removeKey: association key ]]. #(#DefaultFixedTextStyle #DefaultMultiStyle) do: [ :key | TextConstants at: key put: (TextConstants at: #DefaultTextStyle ) ]. PartsBin clearThumbnailCache. Smalltalk garbageCollect ___________________ http://www.adrian-lienhard.ch/
So I suggest to change the default to Accujen, keep the current default Accuny, and remove all other fonts. The script below does this so you can try it out if you are interested. It frees roughly 2k, but eventually with more cleanup it will have a bigger impact because the TT font instances are still referenced from other places in the system.
+1 I like what the script changes. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
sounds good to me. Stef On Oct 15, 2008, at 10:31 PM, Adrian Lienhard wrote:
In another thread (Pharo image size: 10.9MB) I proposed to remove all but one font since the ones in the image (especially the TT fonts) are not really useful but consume memory. Hilaire suggested to keep Accujen, which to my eyes looks better than the default Accuny font (not perfect, but better..). So I suggest to change the default to Accujen, keep the current default Accuny, and remove all other fonts. The script below does this so you can try it out if you are interested. It frees roughly 2k, but eventually with more cleanup it will have a bigger impact because the TT font instances are still referenced from other places in the system.
Adrian
Preferences setDefaultFonts: #( (setSystemFontTo: 'Accujen' 12) (setListFontTo: 'Accujen' 12) (setMenuFontTo: 'Accujen' 12) (setFlapsFontTo: 'Accujen' 14) (setEToysFontTo: 'Accujen' 12) (setPaintBoxButtonFontTo: 'Accujen' 12) (setWindowTitleFontTo: 'Accujen' 12) (setBalloonHelpFontTo: 'Accujen' 12) (setCodeFontTo: 'Accujen' 12) (setButtonFontTo: 'Accujen' 12)).
Preferences setWindowTitleFontTo: (Preferences windowTitleFont emphasized: 1). Preferences setFlapsFontTo: Preferences windowTitleFont.
TextConstants associations do: [ :association | ((association value isKindOf: TextStyle) and: [ association key ~= #Accuny ] and: [ association key ~= #Accujen ] and: [ (TextStyle defaultFamilyNames includes: association key) not ]) ifTrue: [ TextConstants removeKey: association key ]]. #(#DefaultFixedTextStyle #DefaultMultiStyle) do: [ :key | TextConstants at: key put: (TextConstants at: #DefaultTextStyle ) ].
PartsBin clearThumbnailCache. Smalltalk garbageCollect
___________________ http://www.adrian-lienhard.ch/
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Adrian Lienhard schrieb:
In another thread (Pharo image size: 10.9MB) I proposed to remove all but one font since the ones in the image (especially the TT fonts) are not really useful but consume memory. Hilaire suggested to keep Accujen, which to my eyes looks better than the default Accuny font (not perfect, but better..).
Does somebody have a "font load/ unload" process in mind? Fonts once removed in vanilla squeak are a PITA to load back and re-anchor in the system-wide font collections... So basically, I'd like to vote for "remove and make loadable steph by steph"
On Oct 17, 2008, at 8:03 PM, Markus Fritsche wrote:
Adrian Lienhard schrieb:
In another thread (Pharo image size: 10.9MB) I proposed to remove all but one font since the ones in the image (especially the TT fonts) are not really useful but consume memory. Hilaire suggested to keep Accujen, which to my eyes looks better than the default Accuny font (not perfect, but better..).
Does somebody have a "font load/ unload" process in mind? Fonts once removed in vanilla squeak are a PITA to load back and re-anchor in the system-wide font collections...
So basically, I'd like to vote for "remove and make loadable steph by steph"
step by step because steph is too buzy :) Markus we hear well your wishes now the best way to make it real is to send us some code :) Stef
Stéphane Ducasse schrieb:
So basically, I'd like to vote for "remove and make loadable steph by steph"
step by step because steph is too buzy :) Markus we hear well your wishes now the best way to make it real is to send us some code :)
Just fair. I'll see what I can up with to load fonts by request with the tools supplied within a vanilla pharo image and a given URL (don't nail me on that, I'm known not to keep promises). I guess if I will contribute code I will have to give a signature and mail it, right!?
On Oct 17, 2008, at 8:59 PM, Markus Fritsche wrote:
Stéphane Ducasse schrieb:
So basically, I'd like to vote for "remove and make loadable steph by steph"
step by step because steph is too buzy :) Markus we hear well your wishes now the best way to make it real is to send us some code :)
Just fair. I'll see what I can up with to load fonts by request with the tools supplied within a vanilla pharo image and a given URL (don't nail me on that, I'm known not to keep promises).
Excellent! I think that if we all contribute a little then the system as a whole will really improve a lot. We are all more than busy but I'm convinced that we can do it.
I guess if I will contribute code I will have to give a signature and mail it, right!?
Yes! We try to do it real :) Stef
On Fri, Oct 17, 2008 at 8:48 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Markus we hear well your wishes now the best way to make it real is to send us some code :)
It may not be necessary if we decide to include FreeTypePlus into Pharo because FreeTypePlus uses the fonts of the system. -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
yes but this is still important that we keep the solution to not rely on TT fonts stef On Oct 19, 2008, at 11:10 AM, Damien Cassou wrote:
On Fri, Oct 17, 2008 at 8:48 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Markus we hear well your wishes now the best way to make it real is to send us some code :)
It may not be necessary if we decide to include FreeTypePlus into Pharo because FreeTypePlus uses the fonts of the system.
-- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu) _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stef, On 19/10/2008, at 8:30 PM, Stéphane Ducasse wrote:
yes but this is still important that we keep the solution to not rely on TT fonts
Why is that? Surely basing the font mechanism purely on FreeType would be "Clean" and "Lean" because of all the stuff you could remove, and the plugability and parametric paths you could collapse - and it opens the way to ditching FreeType and using native platform API for text rendering and metrics, which would undoubtedly be "Better" and "Fast". The manifesto already says "Not backward compatible", so it can't be that. If it's a matter of wanting to cover platforms without FreeType - and even then you could use the native API unless you are bare metal, then maybe that should be on the home page with the manifesto. I understand if using native text APIs falls under 'try to avoid to reinvent the wheel', but using only the existing FreeType system doesn't reinvent anything. I'm just curious about the unwritten parameters of Pharo's development, because your statement implies some rule. Cheers, Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Every task involves constraint, Solve the thing without complaint; There are magic links and chains Forged to loose our rigid brains. Structures, structures, though they bind, Strangely liberate the mind. -- James Fallen
On Oct 19, 2008, at 3:51 AM, Antony Blakey wrote:
Stef,
On 19/10/2008, at 8:30 PM, Stéphane Ducasse wrote:
yes but this is still important that we keep the solution to not rely on TT fonts
Why is that?
Well for one thing it requires then implementing the freetype plugin on the iPhone, so it's a barrier to entry for VM developers who are dealing with platforms that may or may not have freetype on them to enable the running of a pharo image. Although the iPhone does have freetype buried somewhere on it, I'm not sure if this is a one hour change or will take all week to enable it.
On 20/10/2008, at 10:48 AM, John M McIntosh wrote:
Well for one thing it requires then implementing the freetype plugin on the iPhone, so it's a barrier to entry for VM developers who are dealing with platforms that may or may not have freetype on them to enable the running of a pharo image.
In that is the case, then I think a stated requirement for Pharo should be a list of platforms, or an explicit statement that it must be usable without FreeType. I'm making two unrelated points: 1. Who not use only FreeType and/or native metrics/rendering. I'm not talking ATSUI, just the kind of simply metrics and character rendering that Squeak has now i.e. char widths, kerning pairs, no ligatures, no bidi etc). 2. Have a clear specification of Pharo's target/constraints/ requirements/intended users/use cases/task applicability, next to the manifesto. What existing code/packages must continue to run? What features must be retained?
Although the iPhone does have freetype buried somewhere on it, I'm not sure if this is a one hour change or will take all week to enable it.
Would it matter if it were a week? Wouldn't the simplification of that part of Pharo be a worthwhile tradeoff? In the scope of a 3 year project, this would seem a simple decision. Or, alternatively, use a metrics/rendering system that uses the native API, with a fallback to FreeType, which IMO would be better, and would work in the iPhone. IMO a clearer statement of goals and constraints would enable better decision making and targeting of effort. Maybe 99% of the problem is Morphic, and a quicker solution would be a native control interface ala SWT. For the purposes of the tools, esp OB, this might be a better outcome for the same effort (OB uses very few controls), especially if the purpose of Pharo is a better Smalltalk playground, rather than an improved Morphic playground. One strategy (which I am following) is to improve OB, get all tools into OB (sans Workspace/Transcript), and then move OB off Morphic. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Nothing is really work unless you would rather be doing something else. -- J. M. Barre
Antony Blakey wrote:
On 20/10/2008, at 10:48 AM, John M McIntosh wrote:
Well for one thing it requires then implementing the freetype plugin on the iPhone, so it's a barrier to entry for VM developers who are dealing with platforms that may or may not have freetype on them to enable the running of a pharo image.
In that is the case, then I think a stated requirement for Pharo should be a list of platforms, or an explicit statement that it must be usable without FreeType.
I would vote for the latter. I would vote strongly against leaving out Squeak's "native" text rendering. With Squeak native I mean a method to render text without any external libraries, e.g. for systems like SqueakNOS, bare metal systems etc. What needs to be done is a proper refactoring of the text, font and text style system so the different rendering mechanisms are easily interchangeable and transparent to the programmer. Michael
On 20/10/2008, at 5:34 PM, Michael Rueger wrote:
I would vote strongly against leaving out Squeak's "native" text rendering. With Squeak native I mean a method to render text without any external libraries, e.g. for systems like SqueakNOS, bare metal systems etc.
How would you justify that in relation to a goal or principle? Maybe: "Pharo must be usable for bare metal systems" or "Pharo must not depend on any libraries that don't come with the OS". In the first case you obviously need *some* external support. Maybe a definition could be driven by the API requirements of the any underlying platform. In the second case you would need to specify the particular OS/version combinations that are targeted. Either of those seem better than "no dependence on FreeType" because they are less arbitrary.
What needs to be done is a proper refactoring of the text, font and text style system so the different rendering mechanisms are easily interchangeable and transparent to the programmer.
Sure, but that's somewhat orthogonal to my point. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 When I hear somebody sigh, 'Life is hard,' I am always tempted to ask, 'Compared to what?' -- Sydney Harris
Michael Rueger writes:
Antony Blakey wrote:
On 20/10/2008, at 10:48 AM, John M McIntosh wrote:
Well for one thing it requires then implementing the freetype plugin on the iPhone, so it's a barrier to entry for VM developers who are dealing with platforms that may or may not have freetype on them to enable the running of a pharo image.
In that is the case, then I think a stated requirement for Pharo should be a list of platforms, or an explicit statement that it must be usable without FreeType.
I would vote for the latter.
I would vote strongly against leaving out Squeak's "native" text rendering. With Squeak native I mean a method to render text without any external libraries, e.g. for systems like SqueakNOS, bare metal systems etc.
I'd vote for the latter too, imagine you want to do a quick VM experiment and you're not used to building VMs for that platform. Requiring TrueType to use your image will raise the bar significantly. Asking for TrueType to deliver a nice look is fine. Bryce
On 20/10/2008, at 7:45 PM, <bryce@kampjes.demon.co.uk> <bryce@kampjes.demon.co.uk
wrote:
I'd vote for the latter too, imagine you want to do a quick VM experiment and you're not used to building VMs for that platform.
But is that a good enough reason to retain all of the other font machinery? What cost in complexity is it worth paying so that someone not used to building VMs can do quick VM experiments? Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 A priest, a minister and a rabbi walk into a bar. The bartender says "What is this, a joke?"
I agree. Stef On Oct 20, 2008, at 9:04 AM, Michael Rueger wrote:
Antony Blakey wrote:
On 20/10/2008, at 10:48 AM, John M McIntosh wrote:
Well for one thing it requires then implementing the freetype plugin on the iPhone, so it's a barrier to entry for VM developers who are dealing with platforms that may or may not have freetype on them to enable the running of a pharo image. In that is the case, then I think a stated requirement for Pharo should be a list of platforms, or an explicit statement that it must be usable without FreeType.
I would vote for the latter.
I would vote strongly against leaving out Squeak's "native" text rendering. With Squeak native I mean a method to render text without any external libraries, e.g. for systems like SqueakNOS, bare metal systems etc.
What needs to be done is a proper refactoring of the text, font and text style system so the different rendering mechanisms are easily interchangeable and transparent to the programmer.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Antony Blakey wrote:
On 20/10/2008, at 7:45 PM, <bryce@kampjes.demon.co.uk> <bryce@kampjes.demon.co.uk> wrote:
I'd vote for the latter too, imagine you want to do a quick VM experiment and you're not used to building VMs for that platform.
But is that a good enough reason to retain all of the other font machinery? What cost in complexity is it worth paying so that someone
that's why my argument about refactoring the font/text/style machinery wasn't completely orthogonal :-) Michael
On 20/10/2008, at 8:37 PM, Michael Rueger wrote:
that's why my argument about refactoring the font/text/style machinery wasn't completely orthogonal :-)
Point taken. Does anyone else think that a better exposition of the goals/ constraints/applicability etc of Pharo would significantly improve the chance of meeting those goals? Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The truth does not change according to our ability to stomach it. -- Flannery O'Connor
that's why my argument about refactoring the font/text/style machinery wasn't completely orthogonal :-)
Point taken.
Does anyone else think that a better exposition of the goals/ constraints/applicability etc of Pharo would significantly improve the chance of meeting those goals?
First let's remove all the etoys/BookMorph Second clean Morphic Third clean a lot of the rest Fourth then we should be in position to have a smaller kernel and may be someone will start to clean and refactor the fonts. There is no magic but we will make sure that if somebody does it we will integrate it. Stef
Hi Markus, Have a look at StrikeFont>>writeAsStrike2named: and #readFromStrike2:. I assume with these methods you can write out the existing strike fonts and read them in again. I would not care about the existing TT fonts as they are in low quality (i.e., blurry, probably because of missing sub-pixel AA). I think that, at least for now, we should leave the two strike fonts I propose in the system and not remove the whole font implementation to not depend on the platform specific free type font implementation. This also leaves the possibility to remove the free type functionality for server images to reduce the memory footprint. Adrian On Oct 17, 2008, at 20:59 , Markus Fritsche wrote:
Stéphane Ducasse schrieb:
So basically, I'd like to vote for "remove and make loadable steph by steph"
step by step because steph is too buzy :) Markus we hear well your wishes now the best way to make it real is to send us some code :)
Just fair. I'll see what I can up with to load fonts by request with the tools supplied within a vanilla pharo image and a given URL (don't nail me on that, I'm known not to keep promises).
I guess if I will contribute code I will have to give a signature and mail it, right!?
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 21/10/2008, at 2:52 AM, Stéphane Ducasse wrote:
First let's remove all the etoys/BookMorph Second clean Morphic Third clean a lot of the rest Fourth then we should be in position to have a smaller kernel and may be someone will start to clean and refactor the fonts.
But these don't really define the purpose of Pharo e.g. Who is the intended audience? In this thread it's already been determined that Pharo 'Must not require FreeType', and someone said 'Must run on bare metal' and 'Must not require external libraries'. Those are the kind of constraints that would immediately define what can be added and what removed. Another important class of constraints would be what packages must not be broken e.g. must Whisker still work?, and thus what packages can/ should be removed. And there must be some context behind wanting to remove eToys/ BookMorph. Is it obsolete/unused? Is it used only by a class of user that you explicitly don't wish to target? Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Success is not the key to happiness. Happiness is the key to success. -- Albert Schweitzer
On Oct 20, 2008, at 11:44 PM, Antony Blakey wrote:
On 21/10/2008, at 2:52 AM, Stéphane Ducasse wrote:
First let's remove all the etoys/BookMorph Second clean Morphic Third clean a lot of the rest Fourth then we should be in position to have a smaller kernel and may be someone will start to clean and refactor the fonts.
But these don't really define the purpose of Pharo e.g. Who is the intended audience?
In this thread it's already been determined that Pharo 'Must not require FreeType', and someone said 'Must run on bare metal' and 'Must not require external libraries'.
Those are the kind of constraints that would immediately define what can be added and what removed.
Another important class of constraints would be what packages must not be broken e.g. must Whisker still work?, and thus what packages can/should be removed.
who said that? We will not be backwards compatible with software that is not used and not maintain.
And there must be some context behind wanting to remove eToys/ BookMorph. Is it obsolete/unused? Is it used only by a class of user that you explicitly don't wish to target?
have a look at the code and you will get the answer. No giant spagetthi code in pharo. I do not want to argue endlessly on that. Squeak is the forum for that kind of discussions.
Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787
Success is not the key to happiness. Happiness is the key to success. -- Albert Schweitzer
On 20.10.2008, at 23:44, Antony Blakey wrote:
And there must be some context behind wanting to remove eToys/ BookMorph. Is it obsolete/unused? Is it used only by a class of user that you explicitly don't wish to target?
eToys is, implementation wise, not written very cleanly. The implementors of etoys always knew 100% that "this hack is the last, then we rewrite everything". If you do that for 10 years, hmm, it shows in code quality. EToys, the one on the OLPC, is based on 3.8 plus *many* changes. Etoys will never be based on 3.9 or 3.10. Thus the etoys in 3.10 (or pharo) would be a fork indpependend of the main eToy branch. Nobody would be interested in maintaining that. But seriously, look at the code. It's a nice example for many things. For example: the prototype will be the product. Or: Never plan to redo everything. You will not. It kind of validates the idea that *evolution* is the most important property of software, and if we want to make progress, supporting evolution is *the* thing to do. The next revolution in software will be a system that supports evolution. Etoys + the support are maybe (conservative estimate) 100.000 of 280.000 lines of code in Pharo. Just imagine how much less maintance, less bugs and in general cleaner architecture we will have. Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
for the vision behind pharo imagine all the implications behind ⢠Better for the better ⢠Beauty to learn from ⢠Not backward compatible ⢠Clean, lean and fast We want a system in which - we can plug different UI frameworks - clean network, clean file system, clean fonts, clean events, clean compiler... - that we could bootstrap: this is one of the goal also - with robust software engineering practices (packages with documentation, tests, smalllint rules attached). Stef On Oct 21, 2008, at 8:47 AM, Marcus Denker wrote:
On 20.10.2008, at 23:44, Antony Blakey wrote:
And there must be some context behind wanting to remove eToys/ BookMorph. Is it obsolete/unused? Is it used only by a class of user that you explicitly don't wish to target?
eToys is, implementation wise, not written very cleanly. The implementors of etoys always knew 100% that "this hack is the last, then we rewrite everything". If you do that for 10 years, hmm, it shows in code quality.
EToys, the one on the OLPC, is based on 3.8 plus *many* changes. Etoys will never be based on 3.9 or 3.10. Thus the etoys in 3.10 (or pharo) would be a fork indpependend of the main eToy branch. Nobody would be interested in maintaining that.
But seriously, look at the code. It's a nice example for many things. For example: the prototype will be the product. Or: Never plan to redo everything. You will not. It kind of validates the idea that *evolution* is the most important property of software, and if we want to make progress, supporting evolution is *the* thing to do. The next revolution in software will be a system that supports evolution.
Etoys + the support are maybe (conservative estimate) 100.000 of 280.000 lines of code in Pharo. Just imagine how much less maintance, less bugs and in general cleaner architecture we will have.
Marcus
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 21/10/2008, at 5:00 PM, Stéphane Ducasse wrote:
On Oct 20, 2008, at 11:44 PM, Antony Blakey wrote:
Another important class of constraints would be what packages must not be broken e.g. must Whisker still work?, and thus what packages can/should be removed.
who said that?
No one. It was a hypothetical.
have a look at the code and you will get the answer. No giant spagetthi code in pharo. I do not want to argue endlessly on that. Squeak is the forum for that kind of discussions.
I'm not arguing one way or the other, and as you (Stéphane) know, I'm doing a much more brutal pruning. I'm *only* suggesting that you develop some guidelines and principles that are objective, measurable, reasonable (as in, useful in reasoning) and useful for decision making, to guide the development and work that goes into Pharo. Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Lack of will power has caused more failure than lack of intelligence or ability. -- Flower A. Newhouse
On 21/10/2008, at 5:43 PM, Stéphane Ducasse wrote:
for the vision behind pharo imagine all the implications behind
⢠Better for the better ⢠Beauty to learn from ⢠Not backward compatible ⢠Clean, lean and fast
We want a system in which - we can plug different UI frameworks - clean network, clean file system, clean fonts, clean events, clean compiler... - that we could bootstrap: this is one of the goal also - with robust software engineering practices (packages with documentation, tests, smalllint rules attached).
But 'imagining implications' isn't really useful as objective input into decision making, or anything that you can measure progress, or even success against. I'll just point to the decision about FreeType - where are the goals/constraints from which that decision follows? Anyway, I'm not trying to piss anyone off, so I'll bow out of this discussion. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The ultimate measure of a man is not where he stands in moments of comfort and convenience, but where he stands at times of challenge and controversy. -- Martin Luther King
have a look at the code and you will get the answer. No giant spagetthi code in pharo. I do not want to argue endlessly on that. Squeak is the forum for that kind of discussions.
I'm not arguing one way or the other, and as you (Stéphane) know, I'm doing a much more brutal pruning. I'm *only* suggesting that you develop some guidelines and principles that are objective, measurable, reasonable (as in, useful in reasoning) and useful for decision making, to guide the development and work that goes into Pharo.
I have one: less crap and not working stuff. :) Stef
I understand your point. But I do not have a measure for self-contained system and without crap. So keeping the fonts is important to avoid to rely on a lot of external software. So to me it makes sense to keep and improve the existing while at the same time use other when it makes sense but not to the point that self contained is damaged. Stef On Oct 21, 2008, at 10:20 AM, Antony Blakey wrote:
On 21/10/2008, at 5:43 PM, Stéphane Ducasse wrote:
for the vision behind pharo imagine all the implications behind
⢠Better for the better ⢠Beauty to learn from ⢠Not backward compatible ⢠Clean, lean and fast
We want a system in which - we can plug different UI frameworks - clean network, clean file system, clean fonts, clean events, clean compiler... - that we could bootstrap: this is one of the goal also - with robust software engineering practices (packages with documentation, tests, smalllint rules attached).
But 'imagining implications' isn't really useful as objective input into decision making, or anything that you can measure progress, or even success against. I'll just point to the decision about FreeType - where are the goals/constraints from which that decision follows?
Anyway, I'm not trying to piss anyone off, so I'll bow out of this discussion.
Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787
The ultimate measure of a man is not where he stands in moments of comfort and convenience, but where he stands at times of challenge and controversy. -- Martin Luther King
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (10)
-
Adrian Lienhard -
Antony Blakey -
bryce＠kampjes.demon.co.uk -
Damien Cassou -
John M McIntosh -
Lukas Renggli -
Marcus Denker -
Markus Fritsche -
Michael Rueger -
Stéphane Ducasse