- Pharo-dev - lists.pharo.org

Re: [Pharo-project] DBXTalk & seaside / success in Pier one-click / my 1.4 woes follow-up

by Cameron Sanders

Yanni, I tried to be clever and start with 1.4 and load Pier3. But the seaside load looks incomplete -- conrol panel and other things missing. (And I have lost another day of muddling with variations.) Rather than debug this build, perhaps you would tell me your base image build process and I will attempt to replicate that. (Please. ;) So you start with 1.4, and then add ... Seaside, Magritte, Pier, and Fuel? In that order? And which versions, please? Thanks in advance, Cam

June 12, 2012

Re: [Pharo-project] DBXTalk & seaside / success in Pier one-click / my 1.4 woes follow-up

by Mariano Martinez Peck

On Tue, Jun 12, 2012 at 10:28 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 12/06/12 3:46 AM, Mariano Martinez Peck wrote: > >> >> ((Smalltalk at: #ConfigurationOfFuel) project version: '1.8') >> load. >> >> >> I use version 1.7, but because I don't want the other packages in >> the image, >> >> >> what do you mean with that phrase? >> > > It's badly worded. Here's another attempt... > > I use version 1.7, but I don't load it using ConfigurationOfFuel, because > I don't want the other packages (such as benchmarks, SIXX, etc.). So, I > load just the packages: ... > > In we DO NOT load SIXX, or other serializers (but yes our Benchmark package, progressUpate and examples) ((Smalltalk at: #ConfigurationOfFuel) project version: '1.7') record -> a MetacelloNullRecordingMCSpecLoader(linear load : linear load : 1.7 [ConfigurationOfFuel] load : Fuel-MartinDias.479 load : FuelTests-MartinDias.157 load : FuelProgressUpdate-MartinDias.27 load : FuelBenchmarks-MartinDias.88 load : FuelExamples-MartinDias.5) Now, in Version 1.8 by default we only install the core and the tests of the core: (Smalltalk at: #ConfigurationOfFuel) project stableVersion record -> a MetacelloNullRecordingMCSpecLoader(linear load : linear load : 1.8 [ConfigurationOfFuel] load : Fuel-MartinDias.685 load : FuelTests-MartinDias.267 load : FuelCompatibilityBeforePharo20-MartinDias.4) -- Mariano http://marianopeck.wordpress.com

June 12, 2012

Re: [Pharo-project] DBXTalk & seaside / success in Pier one-click / my 1.4 woes follow-up

by Yanni Chiu

On 12/06/12 3:46 AM, Mariano Martinez Peck wrote: > > ((Smalltalk at: #ConfigurationOfFuel) project version: '1.8') > load. > > > I use version 1.7, but because I don't want the other packages in > the image, > > > what do you mean with that phrase? It's badly worded. Here's another attempt... I use version 1.7, but I don't load it using ConfigurationOfFuel, because I don't want the other packages (such as benchmarks, SIXX, etc.). So, I load just the packages: ...

June 12, 2012

Re: [Pharo-project] Problem with FileHandle >> open [WAS] Re: FileReference should throw error when deleting unexisting files?

by StÃ©phane Ducasse

Camillo > So what was the idea beheind this change? > camillo? > Yes We should stabilize his cool effort to use FS and there were some bug in the FIlePlugin just to make things more complex

June 12, 2012

Re: [Pharo-project] Look and font competition

by StÃ©phane Ducasse

thanks! Stef On Jun 12, 2012, at 6:52 PM, Helene Bilbo wrote: > I attached proper document icons for .image, .changes and .sources files to > this issue: > http://code.google.com/p/pharo/issues/detail?id=5626 > > -- > View this message in context: http://forum.world.st/Look-and-font-competition-tp4634175p4634497.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

June 12, 2012

Re: [Pharo-project] Look and font competition

by StÃ©phane Ducasse

On Jun 12, 2012, at 6:49 PM, Helene Bilbo wrote: > > StÃ©phane Ducasse wrote >> >> Now if somebody with better design tastes than us would have some time we >> would really like to get a >> real professional style for 2.0. >> > > Design is not a question of 'fonts' and 'tastes'. Better UI ususally has > some serious research background. You probably have to pay - or get > interested - (the right) professionals to do it, and itâs worth it too! Yes but so far we cannot afford it. > If there is one sheer 'taste' thing, i wonder if Pharo is capable of having > textured UI-elements, like Mac OSX Lion. I attach an image of a button with > a subtle texture to illustrate what i mean. > > Also, have a look at how this guy, Matt Gemmell, has something like Halos (I > know, you donât like them ;) adopted for iOS. It looks amazing! This is not that I do not like them. I do not like that when the get in our way. Else they are cool interaction devices. > http://mattgemmell.com/2012/05/14/mgtilemenu/ I'm not sure that you do not get lost with tile Menu > > http://forum.world.st/file/n4634496/texture.png Why could not we have button with a texture. There is a Iconic button > > -- > View this message in context: http://forum.world.st/Look-and-font-competition-tp4634175p4634496.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

June 12, 2012

Re: [Pharo-project] Look and font competition

by StÃ©phane Ducasse

> I've got an interest in graphic design. I've just done a bit of reading around to familiarize myself with font choice. Thanks for sharing that with us. > First of all, there is the question of monospaced versus proportional fonts. It is widely believed that monospaced fonts are better for programming but then Smalltalk is often different and better. I notice that Pharo 1.4 uses proportional fonts and I've never had a problem with that. Indeed. For us one of the key point is ifTrue: [:each | and of course . and bla; yourself. readibility. > There is good discussion at [1]. > Then there are considerations of technology differences to consider between platforms. > * A difference in rendering between Microsoft and Apple [2] > * Whether ClearType is available cross platform? Some advantages [3] > * Is TrueType available on all platforms? > * Will anti-aliasing be always-on? > [1] http://programmers.stackexchange.com/questions/5473/does-anyone-prefer-prop… > [2] http://www.joelonsoftware.com/items/2007/06/12.html > [3] http://blogs.msdn.com/b/fontblog/archive/2005/12/13/503236.aspx > > Some points against proportional fonts are: > > 1. Not designed for programming. Distinguishing small-o, cap-o & zero and one, small-i, cap-i, small-l, cap-L is the critical feature. Punctuation is often not very distinctive. A little while ago there was a hack to make the period character larger. Also in Pharo 1.4 cap-i and small-l are hard to distinguish. > 2. Alignment of indents. Mainly this is where different developers can use 8, 4 or 2 spaces for fixed tabstops which affects the alignment of text. However searching World > System > Settings for "tab" doesn't show this is configurable, so Pharo seems to sidestep this issue. > > So I like... > * Droid Sans (http://www.google.com/webfonts/specimen/Droid+Sans) Apache License. Steve Matteson. > > * Ubuntu (http://www.google.com/webfonts/specimen/Ubuntu) (similar to Open Font License) > > Some points for monospaced fonts are: > > 3. Some characters are just wider than others. Cramming an 'm' into the space of an 'i' makes it challenging to design a good readable monospace font. > > 4. Most programmer fonts lack italic and bold - which I think becomes important for Nautilus. > > * From http://www.codeproject.com/Articles/30040/Font-Survey-42-of-the-Best-Monosp… I like... > > * Liberation Mono. In particular it seems the clearest of the lot when ClearType is disabled. It deals very well with point (1) above. However while the download page says it is Open Font License the download itself contains only a modified GPL2 license that allows embedding without modification of the font. Steve Matteson. > > * Droid Sans Mono. Same author. Distinguishable point (1). Strong period. Strong number 1 which matches how it appears in engineering drawings. Apache license. Also consider that people like what they are familiar with, and Android will become fairly widespread. > > * Dina. Clean without ClearType. Identical even with ClearType. MIT type license. > > AnonymousPro does also looks good. > > Disclaimer: I am yet to use these fonts in anger. Just reporting impressions so far. > > cheers -ben > > > > > > > > > > > As an aside, even with monospaced fonts there remains an issue with fixed tabstops where new text inserted preceeding a tab stop bumps the tab out of alignment with other vertically aligned text. An very interesting fix for this is "elastic tabstops" [2] [3] > [2] http://nickgravgaard.com/elastictabstops/ > [3] http://tibleiz.net/code-browser/elastic-tabstops.html > >

June 12, 2012

Re: [Pharo-project] Look and font competition

by StÃ©phane Ducasse

On Jun 12, 2012, at 6:43 PM, Igor Stasenko wrote: >> As an aside, even with monospaced fonts there remains an issue with fixed >> tabstops where new text inserted preceeding a tab stop bumps the tab out of >> alignment with other vertically aligned text. An very interesting fix for >> this is "elastic tabstops" [2] [3] >> [2] http://nickgravgaard.com/elastictabstops/ >> [3] http://tibleiz.net/code-browser/elastic-tabstops.html >> > we should do that :) but we need the code in pharo :) > > > > -- > Best regards, > Igor Stasenko. >

June 12, 2012

Re: [Pharo-project] who can have a look at Issue 5913: Remove Squeak epoch

by StÃ©phane Ducasse

> Why? > > If it ain't broke don't fix it. well with that argument we would still have image segment, projects, fileDirectory (soon killed), HttpSocket and other not broken but ugly citizen in the system. > We recently agreed that the Squeak epoch was well-defined, i.e. the start of the 20th century in GMT. This is clear if you read the SMalltalk-80 V2 sources. The reason advanced for changing to Unix was that the Squeak epoch is not well-defined. That argument is incorrect. > > Further, the Squeak epoch is embedded in the VMs, in their answering both seconds and microseconds from the epoch. So there's work involved in getting rid of it. OK this is a good argument to me. > > As far as I can see changing it is pointless wasted effort. I would not say it like that. Because there is a lot of work we do that look pointless but are clearly not. Soon a lot of them will really pay off (ring, nautilus, spec, athens, zinc). Now Sean what was your problem? Because may be we can also improve Squeak-epoch. Stef > > > > > > The > > argument on the squeak list seemed to be: > > - the squeak epoch has a certain beauty to it, being the turn of the century > > vs > > - why reinvent the wheel? Everybody already knows what the unix epoch is > > (e.g. you can point them to Wikipedia) > > > > The full discussion is here: > > http://forum.world.st/Re-Pharo-project-Epoch-returns-local-offset-td4630581… > > > > The main thing is to make sure that whatever we use is based on UTC and not > > local time. > > > > So - two options > > - PharoOffset := 1 January, 1901 UTC > > - Unix offset > > > > Also, whatever we change it to (and IMHO it really needs to be changed), I > > think existing live objects from previous Pharos (e.g. that are materialized > > with fuel) may be invalid (like the recent zip/mcz consequences) > > > > -- > > View this message in context: http://forum.world.st/who-can-have-a-look-at-Issue-5913-Remove-Squeak-epoch… > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > > > > > > -- > > best, > > Eliot > > > > > > > > -- > best, > Eliot >

June 12, 2012

Re: [Pharo-project] Pharo 2.0 Jenkins build failing

by StÃ©phane Ducasse

What is the problem? Because with camillo we still have some change to get in such as the compression changes and monticello for FS. Now for the progress bar the best way is that we disable it, load your change and reenable it. Are you changes loading? Then can we load something after :) Are the two most important questions :) Stef

June 12, 2012