Re: [Pharo-project] A contorted way of making things work :)

[Douglas Brebner]

On 24/12/2012 02:03, Igor Stasenko wrote:

On 24 December 2012 02:27, Peter H. Meadows
 wrote:

What is 'morphic 3' in cuis? Could it be ported to pharo?


Morphic 3 is a grand project pursued mainly by Juan.
Once it will be released to public, we will see.


I believe the most recent Cuis has started this by changing all 
coordinates to parent relative Floats and also by expunging bounds and 
fullBounds.

Re: [Pharo-project] RE : [Preview] The Alternative Browser

[Douglas Brebner]

On 02/08/2012 22:39, GOUBIER Thierry wrote:

Thanks.

For editing more than one method, you would need to open multiple browsers (as 
usual). They all share the same abstract tree, so any change in organisation 
done in one browser is seen by the others.



Have you seen Doug Ways Whisker browser? It's a hierarchical browser 
that can show multiple methods at once which might give you some useful 
ideas. Some info is at 
http://www.fit.vutbr.cz/study/courses/OMP/public/software/sqcdrom2/Packages/Tools/Whisker/ 

Re: [Pharo-project] markdown to latext and html

[Douglas Brebner]

On 26/07/2012 09:58, Camillo Bruni wrote:

markdown / pandoc work pretty well for that :)

http://johnmacfarlane.net/pandoc/

I use it for all non-paper text. Plus you can simply output a .tex file and put 
it
into a real latex document if needed.



It also outputs ePub which is handy.

BTW, as a thought for the future, since ePub3 will support javascript it 
may be possible to embed Amber smalltalk in a standard ebook. Which 
could be very useful for making truly live documentation.

Re: [Pharo-project] class message

[Douglas Brebner]

On 27/05/2012 13:46, Mariano Martinez Peck wrote:


Because ALL objects do have a class. Right?


Wasn't one of the reasons for ProtoObject to enable building non-class 
(e.g. prototype) object systems?

Re: [Pharo-project] Working directory

[Douglas Brebner]

On 26/05/2012 23:08, Igor Stasenko wrote:


I can hardly see what else can replace a tree/graph-like data organization.



Something entirely unexpected that no one saw coming, no doubt :)

e.g. what does the "current working directory" mean in a system with 
orthogonal persistence?

Re: [Pharo-project] Semantic Versioning

[Douglas Brebner]

On 14/05/2012 17:51, Dale Henrichs wrote:

One of the appeals of git/github is that a git commit is immutable so all of 
the artifacts in a commit are guaranteed.


Are you sure? It was my understanding that you *can* alter a git commit. 
Not advisable, but possible.

Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

[Douglas Brebner]

On 09/05/2012 09:08, Göran Krampe wrote:

Ok, regarding changing the syntax of Smalltalk:

- Personally I don't care that much for ANSI. It's dead. I think 
Smalltalk needs to evolve and bloody hell, you have *Traits* in Pharo, 
that is a HUGE difference compared to a bit of literal changes. ;)


- If we *do* decide to "Hey, let's take a look at our literal syntax", 
then we should probably see if we can harmonize a bit. Again, see my 
article for some thoughts in that area.


I agree that Smalltalk literals are quite powerful but I think they 
can be improved.


One thing that occurred to me after reading your article was with a 
formal prefix for #literal and §dynamic syntax, wouldn't it open the 
door to cleanly supporting other, even non-textual objects directly in 
the source?


Whether that's a good idea or not is another question :)

Re: [Pharo-project] DrGeo Android release

[Douglas Brebner]

On 09/05/2012 08:42, Hilaire Fernandes wrote:

Hello,

A small note to let you know we release a free version of DrGeo on
Google Play.

https://play.google.com/store/apps/details?id=eu.drgeo.android

+1 for Smalltalk :)



It works quite nicely on my Galaxy SII phone. Congratulations :)

Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 Smalltalk

[Douglas Brebner]

On 21/04/2012 19:20, Bernhard Pieber wrote:

Dear Smalltalkers,

I am very happy to announce that the Styled Text Editor for the brand new Cuis 
4.0 is now available on GitHub [1]. The Styled Text Editor was first presented 
by me at last year's ESUG in Edinburgh [2]. Thanks to ESUG the presentation was 
recorded [3].

The Styled Text Editor is a framework for rich text editing using styles as 
known from popular word processors like Apple Pages or Microsoft Word. It 
features paragraph and character styles, allowing easy text formatting using 
styles only. It is intended for applications where users need to work with good 
looking rich text in a simple and fast way.


Well, with Pharo 1.4, Cuis 4.0 and now this among others we're just 
being showered with great stuff, congratulations :)


This sounds like it would work well with the ePub support I believe was 
mentioned for a google summer project.

Re: [Pharo-project] Morphic replacement

[Douglas Brebner]

On 27/11/2011 21:08, Fernando Olivero wrote:

When the vm, starts announcing multitouch events, it's a matter of
adding that particular peripheral device to the model. For now, the vm
only announces mouse and keyboard events, therefore i only modeled
those.

Thanks for the question, maybe we should ask the vm guys to add this
to their todo list.




I believe Bert Freudenberg made an iPad VM with multitouch support, 
though I don't know its current status.


Good luck with your work, we could use a better Morphic :)

Re: [Pharo-project] Morphic replacement

[Douglas Brebner]

On 25/11/2011 10:00, Fernando Olivero wrote:

Sounds good except maybe

The world has a mouse and a keyboard, which take care of events
announced by the world.


Does that mean you're not thinking of support for multitouch?

Re: [Pharo-project] Symbol>value:

[Douglas Brebner]

On 30/08/2011 13:30, Tudor Girba wrote:

I proposed this some one or two years ago. I got shut down, but I still find it 
a good idea.

And I even have a semantic reason:
- A Block represents a piece of functionality that can be evaluated with some 
input
- A Symbol often represents a selector which in turns represents a piece of 
functionality that can be evaluated with some input.


I seem to recall there was discussion some time ago about splitting 
Selector functionality from Symbol. After all, there's no real reason 
that a selector /has/ to be a Symbol.


Also, some of the examples in this thread seem to be about terseness for 
terseness sake.

Re: [Pharo-project] Omnibrowser in 1.4

[Douglas Brebner]

On 29/08/2011 21:41, Stéphane Ducasse wrote:

So may be you do not like Ring and this is ok.
Now I want an abstraction so that we can build a remote browser by plugging 
simply rTalk + nautilus + ring.
With the current state of the system this was simply impossible.

I want to be able to browse senders in the past and compare them with the 
current version. Because we use
prehistorical tools even if we could have something like torch to help us.

I cannot see anymore SystemChangeNotifier (even if this was far better than 
without)
PackageInfo, PackageOrganizer with lazy identification of packages
so that when you do an analysis you have to ask sometimes twice to 
packageOrganiser and packageInfo. Ask cyrille the time he spent there.

I want one good browser, one code model (to be used by all the tools), one 
system notifier and a good one.
One AST.



If I may make a metaphor, it sounds like rebuilding a house from the 
foundations on up while you're living in it. Things are bound to get 
unpleasant while it's happening, but it's still worth it in the end. :)

Re: [Pharo-project] Squeak/Pharo on touchscreen: requesting opinions

[Douglas Brebner]

On 18/08/2011 19:40, Dimitry Golubovsky wrote:

I am asking your opinion here (as much of opinion can be had about
something only imaginary) - is the latter method worth implementing:
would one like to use it if available?

Thanks.



One thing to bear in mind is that both Android and Morphic support 
multitouch; specifically, Morphic supports multiple simultaneous Hands 
(in theory, whether the code still works is another matter).


I believe Bert did a demo of multitouch in Squeak (Etoys) on an iPad

Re: [Pharo-project] About not using full Pharo

[Douglas Brebner]

On 20/06/2011 15:09, Torsten Bergmann wrote:

It's hard to work on core without good tools and this will
become more painfull the more we strip down core in the future.

But we all agreed that we need a stable core to build on
top of it because there are also people who just require
a core Smalltalk and not a full developer IDE or people
who have their own IDE setup or want to do experiments.

There is only one solution to this:
  - repackage and introduce clean dependencies between
the packages



Or use something like Craigs Spoon to use the tools in one image to 
build a second customised image.

Re: [Pharo-project] Popularity of Smalltalk in Software Industry

[Douglas Brebner]

On 07/05/2011 01:06, Igor Stasenko wrote:

On 6 May 2011 23:45, Stefan Marr  wrote:

On 06 May 2011, at 19:08, Igor Stasenko wrote:


How about CogVM? Should we stop developing it? Or we should start
supporting both? And can we do that without too much pain? Give us the
idea.

It is all about adopting the ideas, and I could collaboration on that, but I 
can't do that work.
The only problem I see is that there does not seem to be a business case for a 
CogVM with parallel Smalltalk Process execution.


I can tell you more: there is no business cases for VM(s) which can do
manycore :)
At least, to my perception, there is not much pressure from people
(even on mainstream languages) to leverage this technology.
I thought it is very close to come into our houses, but no.. it stuck
somewhere on marketplace, buying a better clothes.



I have the bad feeling that there will continue to be no business case 
for manycore VMs (or serious concurrency in general) until we hit a wall 
at which point they'll suddenly go from uninteresting to desperately 
essential and any language not able to make the jump will be in big trouble.


Besides, wasn't part of Smalltalk all about leading the way rather than 
following behind?

Re: [Pharo-project] Popularity of Smalltalk in Software Industry

[Douglas Brebner]

On 06/05/2011 22:23, Stefan Marr wrote:

(and here we go again...)


On 06 May 2011, at 18:55, Miguel Cobá wrote:


El vie, 06-05-2011 a las 18:32 +0200, Stefan Marr escribió:

Well, I think my work on the RoarVM is some contribution, no? Perhaps, I would 
be more interested in Pharo if it would actually run nicely on the RoarVM, but 
I am stuck with a Squeak 3.x MVC image for my day to day work. And without 
anyone from the community approaching the work to make Pharo thread-safe that 
won't change. It is nice to change the world with Pharo, but the future is 
multi/manycore and Pharo does not support it. Ah, and the day has just 24h so 
don't expect anything from me beside the VM work, thats already enough to keep 
a whole team busy.


I found your post very contradicting and without internal consistency.
You don't care about smalltalk but are creating a vm should run
smalltalk (squeak or pharo) in multiple core. Don't get it. Or you care
that you dedicate time to it or you don't care and don't know why you
build a multicore vm for a system you don't care (maybe the money, the
papers, the citations, don't know)

I am interested in VMs, so why do I need to care about the language on top? 
Actually, I do research in how to support all kind of different languages on 
top of the same VM, because there is not a single language that is the ultimate 
answer to all problems. That is why I do not care about any particular language.
Just look at the JVM. How much of its technology was developed in the pure Java 
context? Not a lot. Most was actually conceived for Smalltalk.
As long as the languages have some commonalities and are not based on 
graph-reduction like Haskell, then they usually don't require a completely new 
designed VM, but a nice set of common abstractions. So why, as a researcher, 
should I care about Smalltalk? Smalltalk is not the final answer, and will 
never be. Neither is any other single language.


Smalltalk the language no. Smalltalk the infinitely malleable 
environment? That's another question :)

Re: [Pharo-project] Nile tests red - Pharo 1.3

[Douglas Brebner]

On 05/05/2011 12:45, Stéphane Ducasse wrote:


Now for pharo we have a vision:
We want a system to invent the next one and that people can make a 
living with it.
- bootstrappable
- clean lean robust
- (ideally) good interface with C
- (ideally) a lovely fast readable documentd extensible VM
- good infrastructure
- meta model for code
- browser for remote/crosscompilation/default browsing
- new compiler
- first class instance variable
- new network layer
- new graphics
- new module system

At the end it may not be Smalltalk but it will be the same spirit. I think that 
we are slowly getting to the point
where we will start to invent new things instead of just removing old 
experiences.



I rather believe it will be Smalltalk. After all, consider how different 
each step of ST-72 to ST-80 was from each other, yet they were all still 
Smalltalk.

Re: [Pharo-project] Just starting out

[Douglas Brebner]

On 04/05/2011 08:58, Toon Verwaest wrote:

On 05/04/2011 09:53 AM, Sven Van Caekenberghe wrote:

On 04 May 2011, at 09:41, Toon Verwaest wrote:


On 05/04/2011 07:20 AM, Stéphane Ducasse wrote:
this is because they are forced to do so because of a new law in 
the us about crypto.

Believe they do not like that.

What law is that, and why? Sounds interesting :)

http://en.wikipedia.org/wiki/Export_of_cryptography_in_the_United_States

Basically, encryption is a weapon.

Sven
Uncrackable encryption will allow drug lords, spies, terrorists and 
even violent gangs to communicate about their crimes and their 
conspiracies with impunity. We will lose one of the few remaining 
vulnerabilities of the worst criminals and terrorists upon which law 
enforcement depends to successfully investigate and often prevent the 
worst crimes.
For this reason, the law enforcement community is unanimous in calling 
for a balanced solution to this problem.





I have to wonder if the people behind this realise that public key 
encryption was originally invented in the UK, not the USA which makes 
export controls rather pointless :)

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

[Douglas Brebner]

On 17/02/2011 18:08, Eliot Miranda wrote:



On Thu, Feb 17, 2011 at 1:59 AM, Douglas Brebner 
mailto:squeakli...@fang.demon.co.uk>> 
wrote:


On 16/02/2011 20:13, Eliot Miranda wrote:



On Wed, Feb 16, 2011 at 12:04 PM, Stéphane Ducasse
mailto:stephane.duca...@inria.fr>> wrote:


On Feb 16, 2011, at 6:15 PM, Eliot Miranda wrote:

>
>
> On Tue, Feb 15, 2011 at 11:50 PM, Stéphane Ducasse
mailto:stephane.duca...@inria.fr>> wrote:
> Eliot a final question.
> So how will you handle OPAL compiler change in Cog?
> Do you require that marcus and jorge have to deal with
decompiler of caseOf: in addition to all the rest?
> Is it a strong requirement? Because then this is clear that
Opal will be delayed. But may be it is not that important
after all.
> Just curious.
>
> OPAL is a Smalltalk compiler.  I can therefore assume that
it will compile Smalltalk.  caseOf: is valid Smalltalk and so
will be compiled by OPAL.  Whether Marcus chooses to optimise
caseOf: or not is up to him.

This is exactly my point.


No it's not.  Your point was to raise two straw-=man arguments:
1. that Marcus and Jorge would have to deal with the decompiler
(not an issue; the decompiler already deals with optimized
caseOf: and the new decompiler will deal with optimized caseOf:
just as it'll deal with optimized ifTrue: ifNotNil: et al).
2. that supporting caseOf: in optimized form will delay Opal (not
an issue; Opal will optimize certain constructs, this is just one
more and won't add a lot of time).

So your point appears to be to try and justify removing caseOf:
on spurious grounds by spreading FUD.

This is so unlike you I'm having a hard time really understanding
what's going on.




Correct me if I'm wrong but isn't Stephane essentially saying that
Opal will just demote #caseOf: from inlined special form to normal
method? (Possibly so it can be unloadable instead of being pinned
in the system by the compiler support).
It seems to me that this shouldn't affect caseOf: use in Cog since
the inlining there is handled by the SLang translator.


It certainly won't affect the production Cog since indeed that goes 
through Slang to emerge as C.  However it will affect developing in 
Cog, which is done by rnning the simulator, and as I've shown case 
statements are used in some performance-critical parts of the system 
(byte access).


Wasn't there mention of Opal having optimisations as extensions so you 
can have an optimised caseOf: without having it hardwired into the compiler?




Or have I totally misunderstood?

Of course, where caseOf: is kept afterwards another question :)


I don't see why one would want to get rid of this useful 
functionality.  There is nothing inherrently wrong with a flexible 
case statement.  Its certainly far more preferrable than a 
performance-equivalent set of nested ifTrue:ifFalse:'s.  Further, the 
dictionary/perform or multiple classes approaches only make sense at a 
certain scale (that's especially true of the dictionary/perform 
alternative since maintaining the dictionary is painful).  So for me 
it makes absolutely no sense for a Squeak-derived Smalltalk dialect to 
eliminate a construct that is really useful in certain circumstances. 
 That kind of thinking eliminates things like contexts and that's a 
slippery slope to eliminating the essential flexibility of the system.


I wasn't arguing for getting rid of it entirely, I prefer it to 
dictionary/perform which I dislike for some reason

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

[Douglas Brebner]

On 16/02/2011 20:13, Eliot Miranda wrote:



On Wed, Feb 16, 2011 at 12:04 PM, Stéphane Ducasse 
mailto:stephane.duca...@inria.fr>> wrote:



On Feb 16, 2011, at 6:15 PM, Eliot Miranda wrote:

>
>
> On Tue, Feb 15, 2011 at 11:50 PM, Stéphane Ducasse
mailto:stephane.duca...@inria.fr>> wrote:
> Eliot a final question.
> So how will you handle OPAL compiler change in Cog?
> Do you require that marcus and jorge have to deal with
decompiler of caseOf: in addition to all the rest?
> Is it a strong requirement? Because then this is clear that Opal
will be delayed. But may be it is not that important after all.
> Just curious.
>
> OPAL is a Smalltalk compiler.  I can therefore assume that it
will compile Smalltalk.  caseOf: is valid Smalltalk and so will be
compiled by OPAL.  Whether Marcus chooses to optimise caseOf: or
not is up to him.

This is exactly my point.


No it's not.  Your point was to raise two straw-=man arguments:
1. that Marcus and Jorge would have to deal with the decompiler (not 
an issue; the decompiler already deals with optimized caseOf: and the 
new decompiler will deal with optimized caseOf: just as it'll deal 
with optimized ifTrue: ifNotNil: et al).
2. that supporting caseOf: in optimized form will delay Opal (not an 
issue; Opal will optimize certain constructs, this is just one more 
and won't add a lot of time).


So your point appears to be to try and justify removing caseOf: on 
spurious grounds by spreading FUD.


This is so unlike you I'm having a hard time really understanding 
what's going on.





Correct me if I'm wrong but isn't Stephane essentially saying that Opal 
will just demote #caseOf: from inlined special form to normal method? 
(Possibly so it can be unloadable instead of being pinned in the system 
by the compiler support).
It seems to me that this shouldn't affect caseOf: use in Cog since the 
inlining there is handled by the SLang translator.


Or have I totally misunderstood?

Of course, where caseOf: is kept afterwards another question :)

Re: [Pharo-project] [update 1.2] #12297

[Douglas Brebner]

On 13/01/2011 22:04, Tudor Girba wrote:

That is a good point. I actually used the Sim Daltonism application (for Mac) 
to check the color blindness issues, but it looks like I overlooked 
Monochromacy (however, this is pretty rare). I will try to look into that.

Cheers,
Doru


It's not just the colour blind that are affected (though they have it 
worst). Even people with perfect vision can find it difficult to 
distinguish adjacent areas of similar contrast.


e.g. If you look at the save changes window that appears when quitting 
an image you'll notice the buttons almost disappear into the background.


Still, it's good that someone is working on this :)

Re: [Pharo-project] [update 1.2] #12297

[Douglas Brebner]

On 13/01/2011 11:29, Tudor Girba wrote:

I tried to start from zero and add a new variable (e.g., color) only when I 
could not distinguish something. There are still things that are superfluous 
(e.g., the border around all tabs, or the bulky shape of an expander), but I 
did not have enough time and Morphic expertise to do better.

Now, orange vs blue is actually not just a matter of taste because your orange 
is not the same as my blue. There are two reasons: (1) it is stronger, and (2) 
it appears in more places (e.g., at the bottom of the scrollbar). This means 
that it will compete for my attention with more force. This might be your 
intention, but it is not mine because it takes away from my main focus which is 
the content.



I admit that I do like the blue for selections.
However, I find that the blue gradient on the buttons is difficult to 
see clearly.


I suspect this is because the chosen blue has high contrast against the 
white background of the list but *extremely* poor contrast with the grey 
button/frame background. If you look at the browser in greyscale, the 
difference stands out starkly (see the attached image).


I also find all of the buttons without white borders seem to blend into 
the background so much as to become difficult to distinguish.


Otherwise, I do like it :)
<>

Re: [Pharo-project] Issue 3485 in pharo: VMMaker does not load on Pharo 1.2

[Douglas Brebner]

On 29/12/2010 10:14, Igor Stasenko wrote:

Entries like:
ADPCMCodec methodsFor: 'private' stamp: 'zz (auto pragmas 12/08) 3/2/2004 07:58'

should look like:

ADPCMCodec methodsFor: 'private' author: 'zz' comment: 'auto pragmas
12/08' timestamp:'3/2/2004 07:58'


Just out of curiosity is that date the third of February or the second 
of March 2004? ;)

Re: [Pharo-project] [OT] Re: Why Smalltalk ? Which Smalltalk ?

[Douglas Brebner]

On 22/12/2010 23:24, Igor Stasenko wrote:

guys, lets just stop pouring oil into the flames because it will burn
people in both camps, without any benefit to anyone.

I am equivalently happy to see any good news about Squeak as well as
Pharo. Come on, there is enough space in boat for both of them,
not saying about other dialects.



Agreed. I for one am pleased that both Pharo and Squeak exist (and Cuis 
too!) since it allows different people with different priorities to work 
in different directions without stepping on each others toes.


And, it's not like code developed in one system is automatically 
non-portable to the others :)

Re: [Pharo-project] About SimpleMorphic

[Douglas Brebner]

On 07/11/2010 03:17, Juan Vuletich wrote:


In Pharo, this method calls #adjustLayoutBounds: (19), #layout:in: 
(149), #layoutProportionallyIn: (10), 
#computeCellArrangement:in:horizontal:target: (87), 
#computeGlobalCellArrangement:in:horizontal:wrap:spacing: (31), 
#computeCellSizes:in:horizontal: (30), 
#computeExtraSpacing:in:horizontal:target: (136), 
#layoutLeftToRight:in: (91), #layoutTopToBottom:in: (91), 
#placeCells:in:horizontal:target: (70). The numbers in parenthesis are 
the sum of the lines of code of the implementors. Total lines of code 
for layout (taking only these most important methods) is 714. I doubt 
there are many people who really understand all of this code.


In SimpleMorphic (Cuis), this calls #layoutSubmorphsIn: (10), 
#applyLayoutFrameIn: (11), #layout:in: (24). Total lines of code is 
45. I believe any smalltalker could understand these in just minutes.


I hope this makes makes it clearer to you what SimpleMorphic is.




This sounds awesome, Morphics' complexity has long been a sticking point 
of mine.


Thanks for doing this :)

Re: [Pharo-project] posting etiquette - please post new text at the *top* of your email

[Douglas Brebner]

On 27/10/2010 08:11, Oscar Nierstrasz wrote:

Hi Folks,

It is really hard keeping up with the deluge of email on this list.  It is even 
harder if you have to search through posts to find the actual new text buried 
in all the quoted stuff.

Unless there is a very good reason to provide the context, please add your new 
text *before* any quoted material.



Or even better, cut out the irrelevant quoted text :)


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] WebClient License Update

[Douglas Brebner]

 On 09/09/2010 03:27, Andreas Raab wrote:
For string concatenation on the other hand, we're basically talking 
about dispersing a whole load of FUD about all the things that "may" 
go wrong. Fact is, nothing actually *does* go wrong with the change, 
but the change does fix situations that are *very* difficult to handle 
otherwise. One of the unfortunate realities of string concatenation is 
that it's very often used around error messages and logging, often in 
corner cases that aren't well tested, like:


 ifTrue:[
self log: 'Found impossible condition: ', foo.
].



I'm not sure how important this is considered in Squeak/Pharo, 
especially in this context, but isn't this sort of output string 
manipulation a definite no-no from an i18n viewpoint?


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Single instance executables

[Douglas Brebner]

 On 04/09/2010 08:25, Denis Kudriashov wrote:

You could open some file for write at image startup. When its failed
you know that another image already started



That only works on Windows. Unix will allow you to open a file for 
writing multiple times simultaneously.




___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final

[Douglas Brebner]

 On 30/08/2010 12:06, Levente Uzonyi wrote:

On Mon, 30 Aug 2010, Stéphane Ducasse wrote:



Now
- since the license is unclear
- since the license of the contributors is unclear
we will not use it as an infrastructural assets for Pharo. I imagine 
that Seaside will not use it either.


Well, we are about to use it for Seaside.



Is that legal?
IANAL but it was my understanding that if code has no licence it means 
that noone but the author has any right to do anything with it 
whatsoever. Not to download it, use it or even read it. That's why 
licences explicitly grant you rights, because otherwise you have /none/.
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] ESUG will sponsor the XMLRPC project!

[Douglas Brebner]

On 28/06/2010 22:18, Germán Arduino wrote:


Blogger and Google in general yes, are moving to GData but xml-rpc is
still suported.

But I understand your point, you think that isn't worth to invest in
this protocol.

I need to think about.

   


It is still in use though, and as mentioned elsewhere on this thread you 
don't get to dictate the protocol the people on the other side use :)


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] pharo and stand along GUI projects

[Douglas Brebner]

On 05/06/2010 17:42, Richard Durr wrote:

Since single-fullwindow apps like garageband, finalcut, aperture et
al. are all very well accepted, a single-fullwindow app based on pharo
sounds possible.

   


By accessibility (a11y) I meant support for disabled use, such as 
screenreaders and voice operation.
Also useful for hands or eyes free operation such as while driving or 
other physical tasks :)



On Sat, Jun 5, 2010 at 6:28 PM, Douglas Brebner
  wrote:
   

On 05/06/2010 14:39, Schwab,Wilhelm K wrote:
 

Native widgets are over-rated IMHO.  That is not to say they have no
value, and it would be nice to see us make them easy to use.  I am split on
whether I would like to see the IDE tools appear as host widgets on Linux;
it would probably be best to set (sorry) a preference for the image to run
over multiple windows or to default to what we have now which can be very
useful if I need to work on two or more images at one time.  That is rare,
and most of the time I would like to see the OS' task bar include my
Smalltalk tools.


   

The only real advantage I see for native widgets currently is that they
support things like accessibility, though Juan mentioned he's thought about
that for Morphic 3 which gives me hope :)
 





___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] pharo and stand along GUI projects

[Douglas Brebner]

On 05/06/2010 14:39, Schwab,Wilhelm K wrote:

Native widgets are over-rated IMHO.  That is not to say they have no value, and 
it would be nice to see us make them easy to use.  I am split on whether I 
would like to see the IDE tools appear as host widgets on Linux; it would 
probably be best to set (sorry) a preference for the image to run over multiple 
windows or to default to what we have now which can be very useful if I need to 
work on two or more images at one time.  That is rare, and most of the time I 
would like to see the OS' task bar include my Smalltalk tools.

   


The only real advantage I see for native widgets currently is that they 
support things like accessibility, though Juan mentioned he's thought 
about that for Morphic 3 which gives me hope :)


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] The Morphic 3 project

[Douglas Brebner]

On 02/06/2010 12:43, Juan Vuletich wrote:

Hi Folks,

I'm new to this list, but many of you already know me.

Morphic 3 is a deep redesign of the Morphic framework. It includes new 
rendering algorithms I developed that produce unparalleled visual 
quality. Really. This is the best 2d rendering in the world. You can 
take a look at  www.jvuletich.org. I have been working a lot recently, 
and uploaded several very cool samples for you to see.




This is awesome :)

I'm wondering though, what you intend for the input side. There's a lot 
of touch screen and multitouch devices around now which would be nice to 
directly support in addition to keyboard + mouse, things like pinch-zoom 
on a ZUI would be cool :)


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Pharo by example book: copying/pasting code snippets

[Douglas Brebner]

On 13/05/2010 22:13, Andrei Stebakov wrote:
When I copy and paste code snippets from the book, the compiler 
complains about the minus signs (which is different character from 
what Pharo expects):


For example the line from the book:
(j > 1) ifTrue: [ (cells at: i at: j − 1) toggleState].
I have to change to (with "short" minus sign)
(j > 1) ifTrue: [ (cells at: i at: j - 1) toggleState].
Otherwise the method doesn't get accepted.
I wonder if this is a PDF issue and if it could be corrected?



Looks like the pdf is using the unicode minus character instead of the 
ascii dash (which Pharo uses for minus) which are not the same.


I wouldn't like to argue about which is in the wrong here ;)


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Zoomable UI

[Douglas Brebner]

On 19/04/2010 18:32, Igor Stasenko wrote:

This is where, i think we should be heading:

http://ahead.com

And this is why i think, a graphics frameworks should be vector based,
not a pixel based one.

   


You may want to look at the papers on Pad++ which had a fair bit of 
information on ZUIs, including optimisation and navigation techniques, 
though I haven't looked at it for a long time. (I mention navigation 
because a ZUI desktop can be immense and easy to get lost in :)


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] About my recursive blues :)

[Douglas Brebner]

On 06/01/2010 20:13, Stéphane Ducasse wrote:
> Hi guys
>
> Sometimes I'm not in good mood. Today I was in a bad bad mood. Quite bad even 
> badder. 
> I was wondering why I was doing all that and the rest. What was the use to do 
> Pharo 
> if we get Squeak doing exactly the same - Ok we were right long time ago but 
> still seeing all the removal of 
> crappy code we begged to be removed and got bashed for and also doing all 
> that effort and seeing it redone 
> was not helping. Being right sometimes is not even cool  :) So a plain bad 
> day cold and rainy. 
> I was frustrated that I cannot be somebody else, doing stuff full time and no 
> other duties
> and going faster. In short nothing was working and I was a frustation ball 
> like I'm good at being. 
>   

One thing I've noticed is that Squeak, Pharo and Cuis are all pulling in
different directions and I suspect that they simply wouldn't work if
attempted in a single shared project.

I feel that having the different forks is actually a good thing since
people can do different things in the different forks which can then be
shared or at least inspire others :)

You're doing good work and I for one appreciate it :)


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Beginner question :) search and replace in String

[Douglas Brebner]

On 05/01/2010 00:02, Adrian Kuhn wrote:
>
> I won't comment on the rest, some prefer concise language, some like to keep 
> it
>  verbose. My point is that a language should offer short aliases for common
>  terms, and I guess all of my examples are common enough to qualify for a
>  shorter aliases based on that criterion--if you want to mimic the evolution 
> of
>  abbreviations in natural language.
>
>   

Please bear in mind that natural languages have much more redundancy and
less precision than programming languages.

In addition, programming languages have handy tools like autocompletion
that natural languages don't, making abbreviations less useful :)

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Pharo-beginner mailing list ?

[Douglas Brebner]

On 31/12/2009 00:34, Adrian Kuhn wrote:
> Stéphane Ducasse  writes:
>
>   
>> @Adrian: the forum idea is nice but I do not why it did not work for
>> Smalltalk. I went to the site you mentioned but I could not get how 
>> it works.
>> 
> You ask, they answer (or if you are in for points: they ask, you answer). It 
> is
>  the major *open and free* site for questions & answers regarding programming.
>  Well, I will not attempt to explain stackoverflow beyond that... 
>
> A general web 2.0 platform can of course not replace a dedicated community
>  platform. But being present on the *now* web (average time for a answer on SO
>  is about 2 minutes!) is a must these days. A strategy for the pharo twitter
>  account might also improve visibility as well as accessibility. Linking to
>  awesome mailing list or blog posts, both from Pharo, Smalltalk *and* outside,
>  would be my suggestion. 
>
> Sorry to say, but mailing lists are parent's technology :)
>   

I have to admit I dislike web forums and actually feel they're kinda
primitive due to the way you need to go to each of them to keep up
instead of having everything come to you in one place.

Wasn't one of the points of computers to get rid of manually doing
everything yourself like this? ;)


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Cap lock madness

[Douglas Brebner]

Schwab,Wilhelm K wrote:
> In working on the loader, my image appeared to go crazy.  I was
> picking up things by halos when I had not intended to do so, the menus
> didn't look right; it was a mess.  I wondered whether my new laptop
> had a busted/stuck control or alt key, and then noticed that the cap
> lock was on.  Is there any reason the menus get weird when the cap
> lock is set?  It seems like a nice way to drive off new users unless
> I'm missing the big picture somewhere.


Caps lock is a modifier under X11, just like alt, ctrl, shift, meta and
hyper.

There was a change in the unix VM on 2009-08-26 which might fix this:
* vm-display-X11/sqUnixX11.c (x2sqModifier): Do not map Caps Lock to
shift modifier.


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Opening image multiple times - bug or feature?

[Douglas Brebner]

Igor Stasenko wrote:
> 2009/9/25 Douglas Brebner :
>   
>> John M McIntosh wrote:
>> 
>>> Actually the WIndows VM use to lie, might still, if you opened a file
>>> READ/WRITE but it was read only, like on a CD, then the windows VM would
>>> say SURE no problem.  This caused grief for macintosh users using one-
>>> click apps on a CD because we would cause a walkback saying we
>>> couldn't open the file READ/WRITE.
>>>
>>>   
>> The problem I had was code that was written on unix that opened the same
>> file twice in write mode in the initialization methods. Broke nastily on
>> windows with confusing exceptions and leaking file handles iirc.
>>
>>
>> BTW, opening an image twice at the same time on windows give the
>> "changes file not accessible" popup at startup of the second image.
>>
>> 
> Right, because on windows you can obtain an exclusive write-lock on a
> file for a process and disallow others
> to open it for writing.
> AFAIK, POSIX systems also allowing locking the file handle through
> using ioctl().
>
>   


Yep, and windows isn't the only one that does this by default, it's
merely the most common :)


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Opening image multiple times - bug or feature?

[Douglas Brebner]

John M McIntosh wrote:
> Actually the WIndows VM use to lie, might still, if you opened a file  
> READ/WRITE but it was read only, like on a CD, then the windows VM would
> say SURE no problem.  This caused grief for macintosh users using one- 
> click apps on a CD because we would cause a walkback saying we  
> couldn't open the file READ/WRITE.
>   

The problem I had was code that was written on unix that opened the same
file twice in write mode in the initialization methods. Broke nastily on
windows with confusing exceptions and leaking file handles iirc.


BTW, opening an image twice at the same time on windows give the
"changes file not accessible" popup at startup of the second image.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Opening image multiple times - bug or feature?

[Douglas Brebner]

Schwab,Wilhelm K wrote:
> Hello all,
>
> I'm getting Ubuntu configured on my new $400 laptop, and just noticed that I 
> can load one Pharo image at least twice w/o any error messages.  Is that good 
> or bad?  I'm inclined to say it is bad, with caveats below.
>   

It's because unix allows you to open a file for write multiple times.
This also applies to in-image code which can make for interesting
platform dependant bugs when running on platforms that don't allow this,
like windows.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Status of Alien FFI

[Douglas Brebner]

Ken Treis wrote:
> On Sep 16, 2009, at 12:02 PM, Douglas Brebner wrote:
>
>   
>> One minor point is that whether integers and longs are different  
>> depends
>> on the platforms data model. Under MS Win64, integers and long  
>> integers
>> are both 32bit, while on most unixes integers are 32bit while long  
>> ints
>> are 64bit. (LLP64 and LP64 models respectively)
>>
>> I don't know if this is important though.
>> 
>
> Good point. All of my platforms are LP64 (Mac OS X and Linux x86-64),  
> and my main objective at present is to get this working for an  
> application I'm committed to build, so I was ignoring those sorts of  
> cross-platform details.
>
> Perhaps there would need to be new primitives for the basic size of  
> each relevant C type? I'm anxious to hear what Eliot might have to say  
> about this since he's got about 2000x more experience with this than I  
> do.
>
>   

There's actually four 64bit data models, though I believe that pretty
much every mainstream 64 bit platform is LP64 except MS Windows. Though
no doubt someone is waiting to prove me wrong :)

BTW, I just read about an embedded processor with 32 bit pointers, 32
bit integers but 40 bit(!) longs. Now that's nasty.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Status of Alien FFI

[Douglas Brebner]

Ken Treis wrote:
>
> * I'm creating a partial Alien library for GemStone so that I can use
> the CairoGraphics package in both Pharo and GLASS. But on x86-64,
> there there's a size difference between a pointer/long and an integer.
> It'd be nice to have some more explicit APIs on Alien, so I could say
> "Alien newCInteger" or "Alien newCLong" and have the platform return
> me the proper size Alien. Even without the platform size differences,
> it seems awkward to use "Alien newC: 4" everywhere I want an integer,
> "Alien newC: 8" where I want a double, etc.
>
> * Similarly, I'd like an API on AlienLibrary that distinguishes
> between integers and longs. In the CairoGraphics package I've added
> some methods to this effect:

One minor point is that whether integers and longs are different depends
on the platforms data model. Under MS Win64, integers and long integers
are both 32bit, while on most unixes integers are 32bit while long ints
are 64bit. (LLP64 and LP64 models respectively)

I don't know if this is important though.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] getting rid of these boring questions and popup

[Douglas Brebner]

Stéphane Ducasse wrote:
> I agree. :)
> I would love to have that.
> this is why we should really have a system to experiment these ideas.
>
>   

The Glamour framework looks useful for browser experimentation. I would
really like a modern version of the Whisker browser Doug Way created.

> On Sep 12, 2009, at 6:15 PM, Philippe Marschall wrote:
>
>   
>> Stéphane Ducasse wrote:
>> 
>>> well for this we will have to rewrite paragraphEditor :)
>>> So in making pharo moves forward we will have to accept losing some
>>> feedback.
>>>   
>> The feedback is still there. The piece of code is still marked as a
>> problem. It just doesn't get in your way.
>>
>> 
>>> But yes your idea is cool.
>>>   
>> You'll have to do more than that. I think this whole 80ies style  
>> browser
>> that's based on scrolling, clicking and popups doesn't cut it anymore
>> and adding more tabs and buttons isn't gonna fix it.
>>
>> Example, why is the browser the size it currently is? Because that was
>> more or less full screen in the 80ies. Consequence you'll always  
>> have to
>> resize and scroll when you open a browser because the category and  
>> class
>> panes are too small. I see how this was cool, exciting and new in the
>> 80ies but today it gets in my way.
>>
>> Example, I want to go to a method in a class. Either I click '--all--'
>> and scroll, scroll, look, scroll, scroll back or I click through the
>> protocols until I found on it. When I'm in Eclipse and want to open a
>> variable or method declaration I hit Ctrl + O, Eclipse shows me a  
>> short
>> outline of the class. Like in Firefox Awesome Bar it filters the  
>> list as
>> I type part of the name. Once I select something it closes and goes
>> there. Zero mouse activity. Zero additional window. When I'm in a  
>> method
>> and want to go to a method invoked there either I Ctrl + click it or I
>> hit F3. When I want to see the hierarchy of a class or the inheritance
>> of a method I just do Ctrl + T and an inline window opens. It closes
>> when I select something or hit Esc. Pharo stacks so many windows on  
>> top
>> of each other that you're never going to find your way back. So at the
>> end of the day you just close dozens of windows.
>>
>> Short anecdote, I our current project we don't ask the user for
>> confirmation, ever. If he decides to delete Migros, we do it without
>> asking. The previous version of the product did but users just  
>> developed
>> a reflex to click popups away without even reading them.
>>
>> And don't get me started on breakpoints. Or blocking the UI.
>>
>> Cheers
>> Philippe
>>
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>   


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Don't ask me how to reproduce this one :)

[Douglas Brebner]

Schwab,Wilhelm K wrote:
> Hello all,
>
> I periodically see a degradation of anti-aliased fonts, and have no idea what 
> causes it.  Given my recent adventures in to startup/shutdown, I suppose it 
> could be due to a problem there??  It seems to be triggered by saving the 
> image w/o quitting.  This recent occurance was different in that I started 
> noting that the text in browsers looked different to me, perhaps just that 
> the method name was not bold??  Something was not quite right, but the text 
> still looked to be rendered well.  Shortly thereafter, the full breakdown 
> happened with everything rendered in an ugly font.  It seems safe to save the 
> image in this state, and exiting and re-loading the image fixes is.  Any 
> ideas?
>   

I had the truetype fonts disappear but doing

FreeTypeFontProvider current updateFromSystem.

fixed it. I don't know if that's the correct way to do it though

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Display depth on Linux

[Douglas Brebner]

Stéphane Ducasse wrote:
> Guys
>
> could you create a wiki pages with "Possible problems with interacting  
> tools on windows"
> or something like that?
>
> Stef
>
>   
I believe this problem is due to a combination of the unix vm putting
garbage into the alpha channel (the extra 8bits in 32bit colour after
RGB) and a Composite extension manager active on the X server. I think
Metacity uses Composite as does Compiz and a few others.

Composite is the X extension that allows the 3d desktop stuff and other
shiny effects to work btw.

> On Aug 10, 2009, at 11:20 PM, Mariano Martinez Peck wrote:
>
>   
>> Does someone know if there are also problems in Metacity  as there  
>> are with Compiz when using something else than 32 bits?
>>
>> Best,
>>
>> Mariano
>>
>> 2009/8/10 Hernan Wilkinson 
>> yeap, it was that, thanks!
>>
>> 2009/8/9 Mariano Martinez Peck 
>>
>>
>>
>> 2009/8/9 Hernan Wilkinson 
>>
>> On linux, when setting Display Depth to something else than 32, it  
>> is impossible to recongnize something on the screen.
>> We did some research with Juan Vuletich on this and it sounds like  
>> an error on the VMnot the Smalltalk code
>> We try it on Ubuntu 9.04, 64 bits. Is this a known bug?
>>
>>
>> Do you have Compiz activated?
>>
>>
>> 


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [ANN] Updating a Pharo image is now possible

[Douglas Brebner]

Stan Shepherd wrote:
> Douglas Brebner wrote:
>   
>> Stan Shepherd wrote:
>> 
>>> Mariano Martinez Peck wrote:
>>>   
>>>   
>>>> On Mon, Aug 10, 2009 at 5:37 AM, stan shepherd
>>>> wrote:
>>>>
>>>> 
>>>> 
>>>>> Hi Damien, it gives the same error on
>>>>> 'Morphic-adrian_lienhard.345.mcz'. And it seems **very** slow, ie
>>>>> running for hours. Is that expected?
>>>>>   
>>>>>   
>>>> I don't think so. In make case, when it takes a hours is because there
>>>> is
>>>> Nod32 activated ;)
>>>> You must exclude Squeak folders from Nod32.
>>>>
>>>>
>>>> 
>>>> 
>>> I don't think so- it's all Linux here. I gather Nod32 is a Windows
>>> antivirus.
>>>   
>>>   
>> Are you using it on a network drive? That can be horrifically slow too
>>
>>
>> 
>
> It's right here on my machine - which is quite well speced. I do have a
> firewall at the router, and OenDNS as the DNS server. I also still had
> Seaside running while updating - is that an issue?
>
>   
It's just that loading packages do *lot* of small accesses to the
changes+sources files so if they're on a network drive it's possible to
get round trip latency on every access. When I moved my files from a
network drive to a local one, loading a package could go from 20+
minutes to less than one.


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] a process to maintain non core package

[Douglas Brebner]

Miguel Enrique Cobá Martinez wrote:
> El dom, 09-08-2009 a las 21:01 +0100, Keith Hodges escribió:
>   
>> Keith Hodges wrote:
>> 
>>> Adrian Lienhard wrote:
>>>   
>>>   
 Hi,

 I really think we need a package management system and a process to  
 maintain it.

 The goal is that loading and using non-core packages "just  
 works"
 
>> Same goal as for Sake/Packages, and it works for me.
>>
>> 
  (unlike for instance SqueakMap, where loading more often fails  
 than succeeds because there are a lot of obsolete packages and a  
 dependency mechanism is missing).

 - There should be a responsible maintainer for each package
 
 
>> Not a realistic proposition. Better to be open to all to maintain on
>> behalf of the community.
>> 
>
> Why not, the debian project use this model since 1996 or something like
> that.
> The same package system the use report packages not maintained anymore
> (orphans and waiting for mantainer)
>
>   
 - For each package there should be a known way to discuss and report  
 problems
 
 
>> That's just arbitrary metadata in the package definition, for more
>> general topics we use the packa...@squeakfoundation.org mailing list
>> 
 - A gate keeper includes and removes packages from the set depending  
 on their status
 
 
>> Probably too complicated to be practical.
>> 
 This limits the set of included packages (at least initially) but  
 would increase the quality and hence the user experience.

 Maybe there could be two sets, a stable and an unstable set. New  
 
 
>> Sake/Packages supports a stable and a beta release of each package.
>> 
 packages would first go to the unstable set and then move up to the  
 stable set after a while.

 An automated build process could load packages into new builds and  
 report the result of the tests.
 
 
>> Bob does that.
>> 
 The package management system does not need to be very sophisticated,  
 
 
>> Sake is as simple as possible for defining actions with dependencies.
>> 
 but it should manage dependencies and have a simple GUI (to search for  
 packages and see what is already loaded).
 
 
>> Sake/Packages uses the class browser as is, no extra GUI is required.
>>
>> Packages provided explore
>>
>> shows you what is loaded, and this should be merged into
>> PackageOrganization.
>>
>> Keith
>> 
>
> Keith, it really appear that you have built the platform to bring this
> dream a reality, but somehow (the details are not relevant now) you
> haven't materialized a "steve jobs" kind of show off of it.
> I believe your words, based on your other projects that I use. What do
> you need, as Stephan said, to bring a complete, working, and as simple
> to understand for all of us of your tools.
> This is my proposal:
>
> I think that if you can put a working example (minimal, a couple of
> packages, and the core) using Pharo, the pharo community happily will
> support you. No more fights, no more angry mails, just the working full
> simple demo.
> I offer to you access to a server with a homologated IP to install (I
> can help you here too) to setup the repositories to test your tools.
> If the community agree to use your tools and process I can also buy and
> donate the domain to host this infrastructure. In the beginning I will
> host it, if someday it grows more than I can support (bandwidth mainly,
> the space isn't problem) then we will discuss with the community to
> migrate the repos to a bigger servers or to ask for donations or some
> other party that can host it (maybe the folks of seasidehosting). We'll
> see in that moment.
>
> But, Keith, we need to see to believe and support you.
>
>
>   
I've seen Keiths Seaside gui he made for Bob though I don't know if he
wants it to be shown around. It looks nice.

Here's a quick explanation for those not familiar with them.
Sake is essentially Make for Smalltalk, allowing you to define tasks
that can depend on other tasks.
Bob is a build tool, which handles all the actual building using Sake
tasks to define what to do.

With Bob+Sake, you can define a build to:
1. Start with a defined image.
2. Load a set of packages into that image (either specific versions or
the latest ones).
3. Apply specific fixes from the bug tracker.
4. Run tests.
5. Save the new image and export all the new package versions to a new
folder.

You can define tasks to apply features to an image such as closures or
perform updates between versions or even update applications.

For example, you can define tasks to do the following sort of things
Pharo1.0beta -> Pharo1.0final
Pharo1.0beta -> Pharo-latest.
Squeak 3.10.2 image -> 3.10.2+closures.
Squeak 3.8 image -> 3.8+closures.
Seaside 2.8 -> 2.9.
Pharo-latest -> Pharo-latest + Se

Re: [Pharo-project] [ANN] Updating a Pharo image is now possible

[Douglas Brebner]

Stan Shepherd wrote:
> Mariano Martinez Peck wrote:
>   
>> On Mon, Aug 10, 2009 at 5:37 AM, stan shepherd
>> wrote:
>>
>> 
>>> Hi Damien, it gives the same error on
>>> 'Morphic-adrian_lienhard.345.mcz'. And it seems **very** slow, ie
>>> running for hours. Is that expected?
>>>   
>> I don't think so. In make case, when it takes a hours is because there is
>> Nod32 activated ;)
>> You must exclude Squeak folders from Nod32.
>>
>>
>> 
>
> I don't think so- it's all Linux here. I gather Nod32 is a Windows
> antivirus.
>   
Are you using it on a network drive? That can be horrifically slow too


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] SmalltalkImage current platformName [WAS] Re: Baseline test results on pharo core 10392

[Douglas Brebner]

David T. Lewis wrote:
> On Thu, Jul 30, 2009 at 05:51:02AM +0100, Douglas Brebner wrote:
>   
>> David T. Lewis wrote:
>> 
>>> FWIW, the implementation that I used for OSProcess is:
>>>
>>> OSProcess class>>isWindows
>>> OSProcess class>>isUnix
>>> OSProcess class>>isUnixMac
>>> OSProcess class>>isNonUnixMac
>>> OSProcess class>>isRiscOS (1)
>>> OSProcess class>>isOS2 (2)
>>>
>>> And yes, Squeak does run on platforms other than unix and win32. Hopefully
>>> it is not too much of a stretch to envision #isSqueakNOS, #isPlan9, #isVMS,
>>> #isChrome, and #isTripos (3). And Tripos was the host for BCPL (4) which 
>>> was a
>>> host for early Smalltalk, which begat Squeak, which inspired Pharo, which
>>> leads us to this discussion, so give some love to Tripos and also to Martin
>>> Richards (5) who continues to advance the development of several of these
>>> seminal technologies.
>>>   
>>>   
>> I believe there's a port to Syllable too, and I expect to see one to
>> AROS or another AmigaOS version :)
>> 
>
> [veering hopelessly off topic, sorry]
> The original AmigoOS was Tripos: http://www.amigahistory.co.uk/tripos.html
>   

The original Amiga*D*OS was Tripos, AmigaOS was more than that (as that
page mentions, Intuition already existed). Though I agree, this is very
offtopic  :)

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] SmalltalkImage current platformName [WAS] Re: Baseline test results on pharo core 10392

[Douglas Brebner]

David T. Lewis wrote:
> FWIW, the implementation that I used for OSProcess is:
>
>   OSProcess class>>isWindows
>   OSProcess class>>isUnix
>   OSProcess class>>isUnixMac
>   OSProcess class>>isNonUnixMac
>   OSProcess class>>isRiscOS (1)
>   OSProcess class>>isOS2 (2)
>
> And yes, Squeak does run on platforms other than unix and win32. Hopefully
> it is not too much of a stretch to envision #isSqueakNOS, #isPlan9, #isVMS,
> #isChrome, and #isTripos (3). And Tripos was the host for BCPL (4) which was a
> host for early Smalltalk, which begat Squeak, which inspired Pharo, which
> leads us to this discussion, so give some love to Tripos and also to Martin
> Richards (5) who continues to advance the development of several of these
> seminal technologies.
>
>   
I believe there's a port to Syllable too, and I expect to see one to
AROS or another AmigaOS version :)


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Beginner Tasks

[Douglas Brebner]

Serge Stinckwich wrote:
> 2009/7/30 Simon Denier :
>   
>> Stef is talking of http://www.squeaksource.com/TestServerSimple.html
>> Now this is a rather rudimentary adaptation from a tool made by Swiss guys.
>> It runs automatically when launching the image, loads packages and runs
>> tests for different projects.
>> Right now it is tailored for Moose projects
>> I guess that the area that need improvements are:
>> - configuration of projects to load, with prerequisites (using Metacello
>> perhaps?). Right now this is hard-coded, see TSProject class>>run
>> - headless running (sometimes some interactive dialogs still pop up,
>> especially when there is a problem loading a package, and this ruins the
>> automatization)
>> - better handling of errors (problems such as above)
>> 
>
> What could be nice is a build server like this one :
> https://hudson.dev.java.net/
> Look here for a running example: http://build.willowgarage.com/
>
>   
Don't we already have a build server in the form of Keiths Bob & Sake?
It even has a Seaside interface.


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] SmalltalkImage current platformName [WAS] Re: Baseline test results on pharo core 10392

[Douglas Brebner]

Andreas Wacknitz wrote:
>
> Am 29.07.2009 um 21:13 schrieb Mariano Martinez Peck:
>
>>
>>
>> On Wed, Jul 29, 2009 at 6:06 PM, Andreas Wacknitz > > wrote:
>>
>>
>> Am 29.07.2009 um 20:08 schrieb Marcus Denker:
>>
>>
>>
>> sooner or later. And I can't see that
>>OSPlatform current isMacOSX
>> is really that much better than
>>SmalltalkImage current platformName = 'Mac OS'
>>
>>
>>
>> Yes it is. I it is not MUCH better, but a bit better and easy to
>> implement. Tomorrow the platform name changes and you have to change
>> your code all over the image. At least, with this, you have the
>> hardcoded in a single place. After this, with a single "senders" you
>> can see where it is used and how to modify this for a more OO stuff.
>
> I beg to disagree. First, you could also search for senders of
> "platformName". Second, what to do when you need to add a new platform?
> At the moment there is "isUnix". But there might be differences
> between Linux, Solaris, RiscOS, FreeBSD, ...
There can be considerable differences. e.g. the gnu tools used by Linux
have different command line options from the BSD tools which could
impact things like OSProcess.
> You don't want a single search and multiple change but a single search
> AND change.
> In my opinion the proposed code is only a minor improvement.
>
>
Maybe one possible solution would be to select on features, e.g.
something like PlatformFeatures>>#menuSupport? I believe Common Lisp
does something like that with their *features* variable.


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] about

[Douglas Brebner]

Igor Stasenko wrote:
> 2009/7/23 Stéphane Ducasse :
>   
>> Juan pointed to me the following CUIS fixes that could interest us.
>> Now I feel not able to check that.
>> Is there somebody good (SIG for example :)) that could spend some time
>> on that?
>>
>> 
> Stef, i wish i could have more than a single life on that :)
>
> My current list of employment:
> - work on paid project(s)
> - work on own small project (will announce soon)
> - finish work on VM+Image Process Scheduling refactoring
>   
Now that sounds interesting. Are you working with Elliot on that?

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Author class

[Douglas Brebner]

Stéphane Ducasse wrote:
> no space  in names
> sorry for van Neumann -> vanNeumann
>
>   
Also beware of non-letters like - and ' (dash and apostrophe) which can
and do appear.
> On Jul 23, 2009, at 12:58 AM, Douglas Brebner wrote:
>
>   
>> Miguel Cobá wrote:
>> 
>>> On Wed, Jul 22, 2009 at 2:53 PM, Stéphane
>>> Ducasse wrote:
>>>   
>>>>> I can unify all the message sends to Author in the core image,  
>>>>> also I
>>>>> can unify the initials and name usage, but
>>>>>
>>>>>   
>>>> It would be nice :)
>>>> The prompt should ask for firstname.lastname and not initials :)
>>>>
>>>>
>>>> 
>>> So I can replace all the prompts to initials for name in the format  
>>> you mention.
>>>
>>> Will this format be the prefered/oficial one?
>>> Will other formats be allowed? Maybe asking for firstname and then  
>>> for
>>> lastname and
>>> then inside Author concatenating in a firstname.lastname.
>>>
>>> What happens with someone with two firstnames and lastnames, like me:
>>>
>>> Miguel Enrique Cobá Martínez
>>>
>>> Firstname: Miguel Enrique
>>> Lastname: Cobá Martínez
>>>
>>> yes it is an bad example as I would write:
>>>
>>> Firstname: Miguel
>>> Lastname: Cobá
>>>
>>> What about spaces?
>>>
>>>   
>> Spaces aren't avoidable since some names have them e.g. "von Braun".
>> Other things to consider are some cultures (like japanese) write names
>> lastname, firstname and others have non-letter chars in their names  
>> e.g.
>> irish names can have apostrophies like "O'Brien" and double barrelled
>> names can have dashes.
>>
>> The best way to do it might be to just have a field for you to input
>> your name in your preferred form since proper international name
>> handling is complicated.
>>
>> 

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Author class

[Douglas Brebner]

Miguel Cobá wrote:
> On Wed, Jul 22, 2009 at 2:53 PM, Stéphane
> Ducasse wrote:
>>> I can unify all the message sends to Author in the core image, also I
>>> can unify the initials and name usage, but
>>>   
>> It would be nice :)
>> The prompt should ask for firstname.lastname and not initials :)
>>
>> 
>
> So I can replace all the prompts to initials for name in the format you 
> mention.
>
> Will this format be the prefered/oficial one?
> Will other formats be allowed? Maybe asking for firstname and then for
> lastname and
> then inside Author concatenating in a firstname.lastname.
>
> What happens with someone with two firstnames and lastnames, like me:
>
> Miguel Enrique Cobá Martínez
>
> Firstname: Miguel Enrique
> Lastname: Cobá Martínez
>
> yes it is an bad example as I would write:
>
> Firstname: Miguel
> Lastname: Cobá
>
> What about spaces?
>   

Spaces aren't avoidable since some names have them e.g. "von Braun".
Other things to consider are some cultures (like japanese) write names
lastname, firstname and others have non-letter chars in their names e.g.
irish names can have apostrophies like "O'Brien" and double barrelled
names can have dashes.

The best way to do it might be to just have a field for you to input
your name in your preferred form since proper international name
handling is complicated.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Call for testers of a faster MC

[Douglas Brebner]

Stéphane Ducasse wrote:
> On Jul 17, 2009, at 6:23 PM, Douglas Brebner wrote:
>
>> Stéphane Ducasse wrote:
>>> The problem doug is that it is unclear if all the features are
>>> needed and what is the status of the implementation. I do not
>>> know what are orphanage, scripts, upgrade upgrade, file...
>> Well, it was my understanding that this version of MC, PackageInfo
>> and Installer were the ones which were intended to become the
>> portable versions that all Squeak forks would use.
>
>
> Well yes this is the intention of keith. It was a bold challenge. Now
> if you look at Installer you get a lot of things you do not need.

True, but this was just an attempt to get MC loaded. I'd expect quite a
lot could be trimmed.

>>> Now the key point is that if somebody in the pharo community
>>> stand up and take the **huge** and painful job to have a **real**
>>> look at MC1.5/1.6 and to be here as a fireman then there is a
>>> chance that we use it. Not just saying yes it works (which is
>>> already a challenge as I noticed it these days).
>> Yes, but my response was only to do with solving the the loading
>> problem you had. Not that every MC problem had been solved :)
>
> ;) Anyway this is a long way to go but we should go there step by
> step. Welcome to pharo.

Thank you :)
I've been away from Squeak for a while due to the problems it's had but
one of the reasons I came back was seeing what was happening with Pharo :)


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Call for testers of a faster MC

[Douglas Brebner]

Stéphane Ducasse wrote:
> The problem doug is that it is unclear if all the features are needed
>  and what is the status of the implementation. I do not know what are
> orphanage, scripts, upgrade upgrade, file...

Well, it was my understanding that this version of MC, PackageInfo and
Installer were the ones which were intended to become the portable
versions that all Squeak forks would use.

> We just did not update to MC1.5 because we are idiot or blind.

I never claimed you were :(

> First we were focusing on something else and also when something is
>  working for you then it is difficult to try something new and risky
> since it can stall the complete process. I do not even know what LFP
> is doing in our back.

As I understand it, this approach only upgrades Installer, PackaageInfo
and Monticello, it doesn't include the rest of LPF.

> Now the key point is that if somebody in the pharo community stand up
> and take the **huge** and painful job to have a **real** look at
> MC1.5/1.6 and to be here as a fireman then there is a chance that we
> use it. Not just saying yes it works (which is already a challenge as
> I noticed it these days).

Yes, but my response was only to do with solving the the loading problem
you had. Not that every MC problem had been solved :)

>
> Stef
>
>
>
>> Stéphane Ducasse wrote:
>>> I checked a bit but actualClassIn: in MC1.6 depends on
>>> MCMethodDefinition having theClass as instanceVariable.
>>>
>>> The results of this experience is clearly showing me that merging
>>>  between fork is nearly impossible. I already lost some days on
>>> that issues and I think that we will stay with a slow MC for now.
>>>
>>>
>>>
>>>
>> Isn't the version loaded by the following code from my other mail
>> the already merged version of 1.5/1.6? (I believe that 1.6 is just
>> 1.5 with atomic loading enabled)
>>
>> Preferences enable: #allowBlockArgumentAssignment. Preferences
>> disable: #raiseDepreciatedWarnings. Installer upgrade upgrade.
>> Installer install: 'UpgradeMonticelloBootstrap'.


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Call for testers of a faster MC

[Douglas Brebner]

Stéphane Ducasse wrote:
> I checked a bit but actualClassIn: in MC1.6 depends on  
> MCMethodDefinition having theClass as instanceVariable.
>
> The results of this experience is clearly showing me that merging  
> between fork is nearly impossible.
> I already lost some days on that issues and I think that we will stay  
> with a slow MC for now.
>
>
>   
Isn't the version loaded by the following code from my other mail the
already merged version of 1.5/1.6? (I believe that 1.6 is just 1.5 with
atomic loading enabled)

Preferences enable: #allowBlockArgumentAssignment.
Preferences disable: #raiseDepreciatedWarnings.
Installer upgrade upgrade.
Installer install: 'UpgradeMonticelloBootstrap'.


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Call for testers of a faster MC

[Douglas Brebner]

Stéphane Ducasse wrote:
> Ok it works
>
>   
>> Preferences enable: #allowBlockArgumentAssignment.
>> Preferences disable: #raiseDepreciatedWarnings.
>>
>> Installer upgrade upgrade.
>> Installer install: 'UpgradeMonticelloBootstrap'.
>> 
>
> Now which version is loaded?
>
>
>   
This should install the latest version of Installer, PackageInfo and
Monticello 1.5

You should get:

>From http://www.squeaksource.com/Installer
Installer-Core-kph.321.mcz
Installer-Scripts-kph.16.mcz
Installer-Formats-kph.4.mcz

>From http://www.squeaksource.com/mc/
PackageInfo-Base-mtf.70.mcz
System-PasswordManager-kph.2.mcz (a dependency)
Monticello.impl-kph.643.mcz

I tried this on the 10373 download and the latest 10379 images and it
just works.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Pharo-Dev/web Image slowness

[Douglas Brebner]

Adrian Lienhard wrote:
> Can you elaborate on what is slow?
> Is this only Pharo or also Squeak?
>
>   
Anything that hits the changes file such as compiling or many MC operations.
e.g. When you see the a popup saying "Snapshotting" it's time to go get
something to eat.
And yes, it affects Squeak too.

The speed difference between running it on a local hard drive and a
remote one is incredible.
> Adrian
>
> On Jul 17, 2009, at 01:07 , Douglas Brebner wrote:
>
>   
>> Stéphane Ducasse wrote:
>> 
>>> Ok we will fix that for 1.0
>>> right now we are not even in beta.
>>>
>>>
>>>   
>> As a minor point, running Pharo on a network drive is *horrifically*
>> slow so don't do that :)
>> 


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Call for testers of a faster MC

[Douglas Brebner]

Keith Hodges wrote:

> Stef if you want to load the source code direct from an mcz, Installer
> can do it as in the following example.
>
> scriptUpgradeMonticelloBootstrap
>
> (Installer url: 'http://www.squeaksource.com/mc/PackageInfo-Base')
> fileInSource.
> (Installer url:
> 'http://www.squeaksource.com/mc/System-PasswordManager') fileInSource.
> (Installer url: 'http://www.squeaksource.com/mc/', self class
> configMCVersion,'.mcz') fileInSource.
>
> This is available in Installer install: 'UpgradeMonticelloBootstrap'.
>
> Damien loads MC1.5 via...
>
> Installer install: 'LevelPlayingField'
>
> this doesnt include Installer-Launcher which causes the above problem.
>
>
>   
I was able to load it in a 10379 image after upgrading Installer.

Preferences enable: #allowBlockArgumentAssignment.
Preferences disable: #raiseDepreciatedWarnings.

Installer upgrade upgrade.
Installer install: 'UpgradeMonticelloBootstrap'.

Thanks to Keith :)


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Pharo-Dev/web Image slowness

[Douglas Brebner]

Stéphane Ducasse wrote:
> Ok we will fix that for 1.0
> right now we are not even in beta.
>
>   
As a minor point, running Pharo on a network drive is *horrifically*
slow so don't do that :)


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Call for testers of a faster MC

[Douglas Brebner]

Douglas Brebner wrote:
> Stephane, if you set the following preferences
> raiseDepreciatedWarnings=disabled (causes problems due to the Author
> initials depreciation)
> allowBlockArgumentAssignment=enabled (Breaks a method called
> #unloadTraits. A convenience method that isn't used and isn't in the
> image after the install is finished)
>
> then you can load MC 1.5 (with updated Installer) by using Keiths LPF
> script.
>
> After setting the prefs, do the following:
>
> HTTPSocket httpFileIn: 'ftp.squeak.org/3.11/scripts/LPF.st'.
>
> and it should just work.
>   
I know it's bad form to reply to my own mail but there's minor breakage
in that ProjectLauncher>>#startUpAfterLogin throws a DNU by sending
#setupFlaps when you first click on the world after restarting the image.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Call for testers of a faster MC

[Douglas Brebner]

Stéphane Ducasse wrote:
> thanks mariano and kirtai.
>
> On Jul 16, 2009, at 10:39 PM, Mariano Martinez Peck wrote:
>
>   
>> StefKirtai was looking you in IRC
>>
>> [16:39]  is stephanes problem with loading mc due to non- 
>> atomicloading changing a method then using it before another method  
>> it depends on is compiled?
>> [17:06]  Kirtai: stef isn't in IRC most of the time
>> [17:07]  it would be better to send him an email
>> [17:07]  I'm just lookin at the problem
>> [17:07]  seems that  MCMethodDefinition>>actualClass is  
>> calling MCMethodDefinition>>actualClassIn: after actualClass is  
>> recompiled but before actualClassIn: is installed
>> 
>
> argh!
>   
Stephane, if you set the following preferences

raiseDepreciatedWarnings=disabled (causes problems due to the Author
initials depreciation)
allowBlockArgumentAssignment=enabled (Breaks a method called
#unloadTraits. A convenience method that isn't used and isn't in the
image after the install is finished)

then you can load MC 1.5 (with updated Installer) by using Keiths LPF
script.

After setting the prefs, do the following:

HTTPSocket httpFileIn: 'ftp.squeak.org/3.11/scripts/LPF.st'.

and it should just work.


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [ANN] Fix to issue 825

[Douglas Brebner]

Marcus Denker wrote:
> On 30.06.2009, at 11:44, Douglas Brebner wrote:
>
>> Marcus Denker wrote:
>>> I personally think that with today's resources (my laptop has 4GB
>>>  of Ram, not 256Kb), we should rethink some of the
>>> design-desicions taken 30 years ago. But many people are
>>> violently against this, fighting a battle by citing "embedded
>>> systems". If one manages to convince them that "embedded" these
>>> days does not equal "small", they mumble about "smart dust" and
>>> obscure things just to be able to fight for hacks not needed
>>> these days...
>>>
>>> Exploring new ways with the resources we have today does not mean
>>>  that everything needs to live in the image. It means that one
>>> can affort to invest resources into very general, reusable
>>> solution to problems like this.
>> Didn't Tim change CompiledMethods so they referred to their source
>> using a pointer so the source could be stored anywhere?
>>
>
> Yes, Tim did some changes (in 1998) to make compiledMethods normal
> objects that have a ByteArray for the bytecode and a normal instvar
> for the pointer to the source. IMHO the way to go, but it was never
> added to squeak... mostly because people feared the overhead (there
> are 40.000 methods, so adding another 40.000 is indeed noticable, as
> we have seen in 3.9 with the MethodProperties...).

I so wish that had made it in.

> I personally like this change, as it makes the implementation higher-
>  level and more OO, which I think is a good thing. I personally think
>  that "more OO" is better than "more compact", considering that a
> laptop these days has 4GB (this is GIGABYTES) of RAM.

Yes, it feels like an optimisation that simply isn't necessary any more.
Worse, it makes it hard for tools to work on them. I can imagine quite a
few tools that could be made with Tim style CompiledMethods.

> I always wonder how Smaltalk would look like if it was disgned with
> the same philosophy in 1976 that people apply today. Using the "but
> it costs memory" philosphy that everyone favors today, Smalltalk
> would never have been done in 1976 at all.

Smalltalk (and Lisp too) have always looked to me like they were
designed for future hardware rather than whatever was contemporary.
Didn't Alan say something about that?

The mind boggles at what a Smalltalk properly designed today would look
like. Though I do believe it would feel similar to todays since the
basic ideas of message passing and a live systems containing the tools
would probably remain though on a much larger scale with multiple images
working together.

Personally, I feel that people are looking too hard at the artefacts
like the image, the class structure and forgetting *why* they were built
the way they were.

>>> One interesting aspect of the source/changes "outside the image"
>>> is that this problem of data that is not used often and thus can
>>> live on disk vs. memory is a general one. Hacking it into the
>>> system just for the sources is just that: a hack. Providing a
>>> general, scalable way to let objects live on disk that are not
>>> needed is much better, as everyone can than use it. The system
>>> can use it for other resources (fonts, images...). Programmers
>>> can use it to keep their domain data on disk automatically.
>>
>> You mean something like LOOM? I would love to have that :)
>>
> Yes! :-)

I'd also like to be able to store on remote images or even internet
sites. Something like Craigs Spoon perhaps :)



___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [ANN] Fix to issue 825

[Douglas Brebner]

Marcus Denker wrote:
> I personally think that with today's resources (my laptop has 4GB of
> Ram, not 256Kb), we should rethink some of the design-desicions taken
> 30 years ago. But many people are violently against this, fighting a
> battle by citing "embedded systems". If one manages to convince them
> that "embedded" these days does not equal "small", they mumble about
> "smart dust" and obscure things just to be able to fight for hacks
> not needed these days...
> 
> Exploring new ways with the resources we have today does not mean
> that everything needs to live in the image. It means that one can
> affort to invest resources into very general, reusable solution to
> problems like this.

Didn't Tim change CompiledMethods so they referred to their source using
a pointer so the source could be stored anywhere?

> One interesting aspect of the source/changes "outside the image" is
> that this problem of data that is not used often and thus can live on
> disk vs. memory is a general one. Hacking it into the system just for
> the sources is just that: a hack. Providing a general, scalable way
> to let objects live on disk that are not needed is much better, as
> everyone can than use it. The system can use it for other resources
> (fonts, images...). Programmers can use it to keep their domain data
> on disk automatically.


You mean something like LOOM? I would love to have that :)


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project