[Pharo-dev] Recognise Stack Exchange Sites by Their Icon

[Yuriy Tymchuk]

Hi,

I’ve found this code puzzle: 
http://codegolf.stackexchange.com/questions/42242/recognise-stack-exchange-sites-by-their-icon
 


Do you think it can be implemented in a nice way in Pharo? Because other 
implementations look hyper obfuscated.

Uko

Re: [Pharo-dev] Duration year

[Chris Muller]

> I was working on a GenericYear that was intended to be used for DateAndTime
> calculus - to be able to add and subtract an arbitrary number of years.  The
> class by itself would not know the days - it is an arbitrary (generic) Year.
>
> It would only know the number of days when it is added (or subtracted) from
> an actual date (or timespan).  The idea was that it would have a very
> specific and limited scope of responsibility.

I liked it.  Hopefully a few loose ends can be fixed up so it can be
put into trunk.

Re: [Pharo-dev] [Esug-list] [Pharo-users] [ann] gtspotter: a moldable interface for spotting objects

[Tudor Girba]

Thanks for the suggestions, Johan. I will change the text and we will
definitely look into making the shortcuts more apparent.

Cheers,
Doru

On Mon, Dec 8, 2014 at 5:17 PM, Johan Fabry  wrote:

>
> OK now I get it … thanks for clarifying!
> I think my confusion stems from the use of ‘category' and then talking
> about 'the collection object’, which made me think about collections and
> source code and protocols and packages and I got lost.
>
> I think that the sentence of the blog would be clearer like this
> (uppercase to show changes):
>
> To do this, GTSpotter offers an extra action: diving in a RESULTS
> category. Pressing Cmd+Shift+ArrowRight dives in the collection OF RESULTS
> OF that category. Thus, we can continue refining the search inside the
> category.
>
> So then, my suggestion for a legend at the bottom of the results list
> would be:
> Cmd+Shift+ArrowUp/ArrowDown = Next/Prev category, Cmd+RightArrow = Dive
> into Result, Cmd+Shift+RightArrow = Dive into Category
>
> > On Dec 8, 2014, at 12:48, Tudor Girba  wrote:
> >
> > Hi,
> >
> > Ok. Let's take it step by step and see if we cannot find a better way of
> explaining.
> >
> > Take a look at the first picture in the blog post. Entering GTSpo shows
> results both for Classes and for Packages. These "Classes" and "Packages"
> are what we call search categories, and they have associated a query
> processor that can populate them with results (see the "Spotting your
> objects" section from the bottom of the post).
> >
> > In our case, we get 39 classes (of which only 5 are shown) and 1 package
> that match the query. If you want to look at all those 39 classes, you can
> dive in the whole collection behind the category in a separate step. This
> is achieved through Cmd+Shift+ArrowRight. Does it make more sense now?
> >
> > I did not consider the category to be confusing. Would you propose
> another name?
> >
> > Cheers,
> > Doru
> >
> >
> > On Mon, Dec 8, 2014 at 4:02 PM, Johan Fabry 
> wrote:
> > Sorry, but no :-(
> >
> > I am always confused when people say ‘category’ because the word has so
> many overloaded meanings. The same happens in the blog post, it is not
> clear to me what category means here, and what does it have to do with the
> collection object?
> >
> > > On Dec 7, 2014, at 11:16, Tudor Girba  wrote:
> > >
> > > Hi,
> > >
> > > Yes, we will still evolve the UI. At the very least you will get the
> shortkeys directly on the actions.
> > >
> > > The answer to your question is in the blog post:
> > > GTSpotter offers an extra action: diving in a category. Pressing
> Cmd+Shift+ArrowRight dives in the collection object containing only the
> items from that category. Thus, we can continue refining the search inside
> the category.
> > >
> > > So, you will open the collection of that sub-category and you will see
> more items at once (not just 5). Is it clearer now?
> > >
> > > Cheers,
> > > Doru
> >
> >
> >
> > ---> Save our in-boxes! http://emailcharter.org <---
> >
> > Johan Fabry   -   http://pleiad.cl/~jfabry
> > PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile
> >
> >
> >
> >
> > --
> > www.tudorgirba.com
> >
> > "Every thing has its own flow"
>
>
>
> ---> Save our in-boxes! http://emailcharter.org <---
>
> Johan Fabry   -   http://pleiad.cl/~jfabry
> PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Investigating MultiByteFileStream for adding tests

[Sven Van Caekenberghe]

> On 08 Dec 2014, at 22:27, sheri...@sheridan-mahoney.com wrote:
> 
> Hi,
> I've been looking into MultiByteFileStream for adding tests in this area, and 
> have come up against what appears to me to be an anomaly.  I ran the 
> following 4 tests:
> 
> 
> FileStream fileNamed: 'test.txt'
> do: [ :str | str
> nextPutAll: '123';
> crlf ].
> 
> MultiByteFileStream fileNamed: 'test2.txt'
> do: [ :str | str
> nextPutAll: '123';
> crlf ].
> 
> FileStream fileNamed: 'test3.txt'
> do: [ :str | str
> nextPutAll: 'élève en Français';
> crlf ].
> 
> MultiByteFileStream fileNamed: 'test4.txt'
> do: [ :str | str
> nextPutAll: 'élève en Français';
> crlf ].
> 
> 
> The results are:
> 
> Input  string Result Unix File
> Class Class  Type
> ---
> FileStream '123'MultiByte-   ASCII text
>FileStream
> 
> MultiByte- '123'MultiByte-   ASCII text
> FileStream  FileStream
> 
> FileStream 'élève enMultiByte-   UTF-8 Unicode
>   Français'FileStream
> 
> MultiByte- 'élève enMultiByte-   UTF-8 Unicode
> FileStream Français'FileStream
> 
> 
> Do operations involving FileStream as input always return a 
> MultiByteFileStream?

Yes.

They also use UTF-8 by default (ASCII is a proper subset of UTF-8).

> Thanks,
> Sheridan
> 

Re: [Pharo-dev] playground vs workspace

[Tudor Girba]

Hi everyone,

My intention was to have a discussion based on arguments and to ask for
permission to change something I believe in. If I give the impression that
I want to name for the sake of naming, I am sorry. And I am sorry I had to
disturb so many people with my infatuation.

At the same time, I am also quite abated by the fact that too many people
look only at what exists and not invest trust in the commitment behind the
effort.

I will stop responding to this thread now.

Thanks for the feedback.

Cheers,
Doru



On Mon, Dec 8, 2014 at 9:30 PM, Hernán Morales Durand <
hernan.mora...@gmail.com> wrote:

> Hello Doru,
>
> I think you have a new different implementation of the classic Workspace,
> for better or worst.
>
> The problem is everybody wants their tool be named as the highest
> taxonomic rank. Compare it with naming your cat as "Cat" and not as Siamese
> Felis Catus which is a specific breed.
>
> On the other side, what prevents for anyone else doing a "better"/new
> implementation and reclaiming the Workspace name? And this could happen
> every year? I don't know you but I get bored of seeing "I want that name"
> discussions.
>
> Workspace is a type of tool, it happens that there is an implementation
> which owned such name. It should be renamed as OldWorkspace,
> DeveloperWorkspace, ClassicWorkspace, or whatever.
>
> For me, Workspace in the World menu should display a sub-menu with both
> implementations. And community gains a place to display/register more
> implementations discriminated by its type.
>
> Hernán
>
>
>
>
>
>
> 2014-12-08 3:18 GMT-03:00 Tudor Girba :
>
> Hi,
>>
>> As you might see, the GTPlayground is called playground not workspace.
>> The main reason for this is that workspace implies the place where work is
>> done, and work is typically associated with creating code.
>>
>> This is not the intention of the workspace.
>>
>> Workspace also comes with a history that is associated with actual
>> implementations. While the current GTPlayground might appear to be similar
>> to the workspace, I think the way you can use the latter produces a
>> significant shift.
>>
>> Furthermore, I think the term playground is more inline with the idea of
>> "playing with live objects". And, in the future, the implementation will
>> likely evolve towards even more liveliness.
>>
>> It is for this reason that I would prefer that the World menu item gets
>> renamed to Playground.
>>
>> What do you think?
>>
>> Cheers,
>> Doru
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow"
>>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Investigating MultiByteFileStream for adding tests

[Stephan Eggermont]

Sheridan wrote:
>Do operations involving FileStream as input always return a 
>MultiByteFileStream? 

That is a well-known pattern, class cluster. A base class defining an interface 
and acting as
a factory hiding the specific class returned. Cocoa uses that a lot, it results 
in a much
cleaner architecture than that of .net and java.
https://developer.apple.com/library/ios/documentation/General/Conceptual/CocoaEncyclopedia/ClassClusters/ClassClusters.html
 

Stephan

[Pharo-dev] Investigating MultiByteFileStream for adding tests

[sheridan]

Hi,
I've been looking into MultiByteFileStream for adding tests in this 
area, and have come up against what appears to me to be an anomaly.  I 
ran the following 4 tests:



FileStream fileNamed: 'test.txt'
 do: [ :str | str
 nextPutAll: '123';
 crlf ].

MultiByteFileStream fileNamed: 'test2.txt'
 do: [ :str | str
 nextPutAll: '123';
 crlf ].

FileStream fileNamed: 'test3.txt'
 do: [ :str | str
 nextPutAll: 'élève en Français';
 crlf ].

MultiByteFileStream fileNamed: 'test4.txt'
 do: [ :str | str
 nextPutAll: 'élève en Français';
 crlf ].


The results are:

Input  string Result Unix File
Class Class  Type
---
FileStream '123'MultiByte-   ASCII text
FileStream

MultiByte- '123'MultiByte-   ASCII text
FileStream  FileStream

FileStream 'élève enMultiByte-   UTF-8 Unicode
   Français'FileStream

MultiByte- 'élève enMultiByte-   UTF-8 Unicode
FileStream Français'FileStream


Do operations involving FileStream as input always return a 
MultiByteFileStream?


Thanks,
Sheridan

Re: [Pharo-dev] playground vs workspace

[Tudor Girba]

Hi,

We do not yet have an IDE (where I stands for integrated). We have a set of
tools and some of them are quite strong. But, we do not have an overall
experience yet.

Yes, the underlying language model does offer a beautiful experience, but
the experience of the tools is far from that. We need tools that are not
just powerful in the hands of few specialists, but tools that are beautiful
and pleasurable to use in the hands of many. This is the goal.

When we will get that, I believe we will change the game.

Cheers,
Doru



On Mon, Dec 8, 2014 at 9:36 PM, kilon alios  wrote:

> "Our "battle" is with the non-Smalltalk world. This is what we need to
> convince. And that world does not care about the history of Smalltalk. It
> cares about how we can solve their problem. That's all."
>
> But you already offer an impressive arsenal of tools. The world can
> complain for several things but what it cannot complain is that Pharo as an
> IDE is not really powerful as a whole. Your competition would be I assume
> specialised tools that come as third party. There is no IDE I know out
> there that offers the level of refactoring of Pharo, in terms of tools and
> libraries.
>
> Also we should not forget that those tools are not just powerful as is the
> example of GTPlayground but are engineered in such way to cooperate which
> each other with ease. While on the other hand , tools for other programming
> languages are by default separate and independent and not necessarily play
> nice with each other which the price one pays to keep things modular and
> unattached to a specific language or IDE. So the way I see it Pharo already
> is beyond competition.
>
> Unless of course you refer to a comparison tool per tool, which mean you
> take this pharo tool and you compare with another tool for another language
> out there. That case would very difficult for you because there are tons of
> development tools out there.
>
> But the overall idea that is "hey there I give you a language, take this
> enviroment too, live coding, how about an IDE  and also get these coding
> tools too " is really a dreamy situation already.
>
> The question is how badly coders want a very powerful IDE at least the
> level of Pharo.
>



-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] playground vs workspace

[kilon alios]

"Our "battle" is with the non-Smalltalk world. This is what we need to
convince. And that world does not care about the history of Smalltalk. It
cares about how we can solve their problem. That's all."

But you already offer an impressive arsenal of tools. The world can
complain for several things but what it cannot complain is that Pharo as an
IDE is not really powerful as a whole. Your competition would be I assume
specialised tools that come as third party. There is no IDE I know out
there that offers the level of refactoring of Pharo, in terms of tools and
libraries.

Also we should not forget that those tools are not just powerful as is the
example of GTPlayground but are engineered in such way to cooperate which
each other with ease. While on the other hand , tools for other programming
languages are by default separate and independent and not necessarily play
nice with each other which the price one pays to keep things modular and
unattached to a specific language or IDE. So the way I see it Pharo already
is beyond competition.

Unless of course you refer to a comparison tool per tool, which mean you
take this pharo tool and you compare with another tool for another language
out there. That case would very difficult for you because there are tons of
development tools out there.

But the overall idea that is "hey there I give you a language, take this
enviroment too, live coding, how about an IDE  and also get these coding
tools too " is really a dreamy situation already.

The question is how badly coders want a very powerful IDE at least the
level of Pharo.

Re: [Pharo-dev] playground vs workspace

[Hernán Morales Durand]

Hello Doru,

I think you have a new different implementation of the classic Workspace,
for better or worst.

The problem is everybody wants their tool be named as the highest taxonomic
rank. Compare it with naming your cat as "Cat" and not as Siamese Felis
Catus which is a specific breed.

On the other side, what prevents for anyone else doing a "better"/new
implementation and reclaiming the Workspace name? And this could happen
every year? I don't know you but I get bored of seeing "I want that name"
discussions.

Workspace is a type of tool, it happens that there is an implementation
which owned such name. It should be renamed as OldWorkspace,
DeveloperWorkspace, ClassicWorkspace, or whatever.

For me, Workspace in the World menu should display a sub-menu with both
implementations. And community gains a place to display/register more
implementations discriminated by its type.

Hernán






2014-12-08 3:18 GMT-03:00 Tudor Girba :

> Hi,
>
> As you might see, the GTPlayground is called playground not workspace. The
> main reason for this is that workspace implies the place where work is
> done, and work is typically associated with creating code.
>
> This is not the intention of the workspace.
>
> Workspace also comes with a history that is associated with actual
> implementations. While the current GTPlayground might appear to be similar
> to the workspace, I think the way you can use the latter produces a
> significant shift.
>
> Furthermore, I think the term playground is more inline with the idea of
> "playing with live objects". And, in the future, the implementation will
> likely evolve towards even more liveliness.
>
> It is for this reason that I would prefer that the World menu item gets
> renamed to Playground.
>
> What do you think?
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>

Re: [Pharo-dev] playground vs workspace

[Andreas Wacknitz]

> Am 08.12.2014 um 20:36 schrieb Andreas Wacknitz :
> 
> 
>> Am 08.12.2014 um 20:27 schrieb Tudor Girba :
>> 
>> Hi Andreas,
>> 
>> With all due respect for the other Smalltalk (inspired or genuine) 
>> environments, I have no intention of waiting for them in order to define the 
>> way forward.
> It’s not about respect for the other Smalltalk environments but for those who 
> work sometimes outside the Pharo world. And you don’t have to wait for 
> anybody. We are talking about the name and not the features.
> As I said: the changes don’t justify a new name in my eyes. For me what you 
> call GTPlayground is a better workspace than the original one. It will 
> replace the workspace (in Pharo) for me
> but it is still a workspace.
> 
>> 
>> Our "battle" is with the non-Smalltalk world. This is what we need to 
>> convince. And that world does not care about the history of Smalltalk. It 
>> cares about how we can solve their problem. That's all.
>> 
> My experience is that the non-Smalltalk ignorant and GTPlayground, as good as 
> it is, will not convince many people. It’s simply too low-level.
Hm, I should have proof read this before hitting the send button: My experience 
is that the (non-Smalltalk) world is ignorant…

> 
> Regards
> Andreas
> 
>> Cheers,
>> Doru
> 
> 

Re: [Pharo-dev] playground vs workspace

[Andreas Wacknitz]

> Am 08.12.2014 um 20:27 schrieb Tudor Girba :
> 
> Hi Andreas,
> 
> With all due respect for the other Smalltalk (inspired or genuine) 
> environments, I have no intention of waiting for them in order to define the 
> way forward.
It’s not about respect for the other Smalltalk environments but for those who 
work sometimes outside the Pharo world. And you don’t have to wait for anybody. 
We are talking about the name and not the features.
As I said: the changes don’t justify a new name in my eyes. For me what you 
call GTPlayground is a better workspace than the original one. It will replace 
the workspace (in Pharo) for me
but it is still a workspace.

> 
> Our "battle" is with the non-Smalltalk world. This is what we need to 
> convince. And that world does not care about the history of Smalltalk. It 
> cares about how we can solve their problem. That's all.
> 
My experience is that the non-Smalltalk ignorant and GTPlayground, as good as 
it is, will not convince many people. It’s simply too low-level.

Regards
Andreas

> Cheers,
> Doru

Re: [Pharo-dev] playground vs workspace

[Tudor Girba]

Hi Andreas,

With all due respect for the other Smalltalk (inspired or genuine)
environments, I have no intention of waiting for them in order to define
the way forward.

Our "battle" is with the non-Smalltalk world. This is what we need to
convince. And that world does not care about the history of Smalltalk. It
cares about how we can solve their problem. That's all.

Cheers,
Doru



On Mon, Dec 8, 2014 at 8:21 PM, Andreas Wacknitz  wrote:

>
> > Am 08.12.2014 um 07:18 schrieb Tudor Girba :
> >
> > Hi,
> >
> > As you might see, the GTPlayground is called playground not workspace.
> The main reason for this is that workspace implies the place where work is
> done, and work is typically associated with creating code.
> For me GTPlayground is a replacement of the workspace. At the moment this
> is obviously so: the workspace menu item has been replaced by the one for
> the Playground.
> The term Workspace is widely known in the Smalltalk community. Don’t
> change the name just because you put some enhancements to it.
>
> >
> > This is not the intention of the workspace.
> >
> > Workspace also comes with a history that is associated with actual
> implementations. While the current GTPlayground might appear to be similar
> to the workspace, I think the way you can use the latter produces a
> significant shift.
> >
> > Furthermore, I think the term playground is more inline with the idea of
> "playing with live objects". And, in the future, the implementation will
> likely evolve towards even more liveliness.
> >
> > It is for this reason that I would prefer that the World menu item gets
> renamed to Playground.
> >
> > What do you think?
> I like the enhancements but I don’t like the new name. Only time will tell
> if the ideas of GTPlayground will be adapted by other Smalltalks and then
> it would be the right time to talk about a better name than workspace.
>
> Regards
> Andreas
>



-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Excel binding

[blake]

You could probably do it with Redline Smalltalk via Apache POI.

On Mon, Dec 8, 2014 at 6:22 AM, Blondeau Vincent <
vincent.blond...@worldline.com> wrote:

>  Hi,
>
>
>
> Does someone know if there is a mean to access Excel sheets from Pharo to
> get data?
>
> I don’t want to use .csv files but .xls/.xlsx files.
>
>
>
> Thanks in advance
>
>
>
> Cheers,
>
>
>
> Vincent BLONDEAU
>
>
>
> --
>
> Ce message et les pièces jointes sont confidentiels et réservés à l'usage
> exclusif de ses destinataires. Il peut également être protégé par le secret
> professionnel. Si vous recevez ce message par erreur, merci d'en avertir
> immédiatement l'expéditeur et de le détruire. L'intégrité du message ne
> pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra
> être recherchée quant au contenu de ce message. Bien que les meilleurs
> efforts soient faits pour maintenir cette transmission exempte de tout
> virus, l'expéditeur ne donne aucune garantie à cet égard et sa
> responsabilité ne saurait être recherchée pour tout dommage résultant d'un
> virus transmis.
>
> This e-mail and the documents attached are confidential and intended
> solely for the addressee; it may also be privileged. If you receive this
> e-mail in error, please notify the sender immediately and destroy it. As
> its integrity cannot be secured on the Internet, the Worldline liability
> cannot be triggered for the message content. Although the sender endeavours
> to maintain a computer virus-free network, the sender does not warrant that
> this transmission is virus-free and will not be liable for any damages
> resulting from any virus transmitted.
>

Re: [Pharo-dev] playground vs workspace

[Tudor Girba]

Indeed :).

However, it is precisely those different opinions that are valuable even if
it is uncomfortable for the one that proposes a new solution.

Cheers,
Doru


On Mon, Dec 8, 2014 at 2:18 PM, Alexandre Bergel 
wrote:

> This is amazing to see such many different opinions. For me, I would keep
> it innovative and breaking with its legacy. Playground for all! No more
> workspaces! And yeah, we will have to write new book about that. We are
> already working on this!
>
> Cheers,
> Alexandre
>
>
> > On Dec 8, 2014, at 3:18 AM, Tudor Girba  wrote:
> >
> > Hi,
> >
> > As you might see, the GTPlayground is called playground not workspace.
> The main reason for this is that workspace implies the place where work is
> done, and work is typically associated with creating code.
> >
> > This is not the intention of the workspace.
> >
> > Workspace also comes with a history that is associated with actual
> implementations. While the current GTPlayground might appear to be similar
> to the workspace, I think the way you can use the latter produces a
> significant shift.
> >
> > Furthermore, I think the term playground is more inline with the idea of
> "playing with live objects". And, in the future, the implementation will
> likely evolve towards even more liveliness.
> >
> > It is for this reason that I would prefer that the World menu item gets
> renamed to Playground.
> >
> > What do you think?
> >
> > Cheers,
> > Doru
> >
> > --
> > www.tudorgirba.com
> >
> > "Every thing has its own flow"
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] playground vs workspace

[Andreas Wacknitz]

> Am 08.12.2014 um 07:18 schrieb Tudor Girba :
> 
> Hi,
> 
> As you might see, the GTPlayground is called playground not workspace. The 
> main reason for this is that workspace implies the place where work is done, 
> and work is typically associated with creating code.
For me GTPlayground is a replacement of the workspace. At the moment this is 
obviously so: the workspace menu item has been replaced by the one for the 
Playground.
The term Workspace is widely known in the Smalltalk community. Don’t change the 
name just because you put some enhancements to it.

> 
> This is not the intention of the workspace.
> 
> Workspace also comes with a history that is associated with actual 
> implementations. While the current GTPlayground might appear to be similar to 
> the workspace, I think the way you can use the latter produces a significant 
> shift.
> 
> Furthermore, I think the term playground is more inline with the idea of 
> "playing with live objects". And, in the future, the implementation will 
> likely evolve towards even more liveliness.
> 
> It is for this reason that I would prefer that the World menu item gets 
> renamed to Playground.
> 
> What do you think?
I like the enhancements but I don’t like the new name. Only time will tell if 
the ideas of GTPlayground will be adapted by other Smalltalks and then it would 
be the right time to talk about a better name than workspace.

Regards
Andreas

Re: [Pharo-dev] playground vs workspace

[Tudor Girba]

Hi,

On Mon, Dec 8, 2014 at 4:51 PM, Torsten Bergmann  wrote:

> >And Playground would match so well the marketing term of "playing with
> live objects".
>
> Sorry - but to me it looks like you were catched too much into: now we
> have to be more modern
> or rival with all this "lively" stuff (Lighttable IDE, Apple Swift, ...).
> We all know
> that being "lively" is something Smalltalk had already years ago and in
> the best way one
> can do it.


It's not. Smalltalk model is live, the ui has always been crappy. We have
to catch up and stop pretending we are in front because we are not. We can
be and we will be, but there is plenty of hard work in front of us.


>You might say that Playground is not the only place where people can play
> with objects, but
>
> Same argument against Workspace is an argument against Playground then.
> Any reason
> you did not continue after your "but"?
>
>
Sorry. Your mail was too long and I missed this one :). I wanted to say
that people can play in the playground, but also play in other places. It
is not the same with the usual meaning of work: work is done in the work
place / work space.



> >Not all. Swift calls it Playground (yes, they copied us ;))
>
> Because Swift uses this does mean ... (***drumrol***) ... NOTHING. Will we
> rename BlockClosures
> to Closures now? Or introduce curly braces? ;)
>

I did not say that. I simply said that not all environments use the term
Workspace.


>You are looking at it from a technical point of view. Yes, it's just a
> merge of two features,
> >but it is the end experience that is so much different.
>
> You said it yourself: we just present it differently. Nothing more. Does a
> concept really justify
> a new name if only presented differently?
>

It's not "just". It's key. It really is :). We have to stop being
programmers for a second if we want to produce a proper user experience.
Users do not care about what it takes technically. They care about their
mental models. This is what has significantly changed.



> I really doubt! Otherwise we would have had to rename the concept of a
> "System Browser" anytime
> we improved the end user experience (which differs also if you compare old
> style Squeak browsers
> and new Nautilus implementation).


Nautilus is a name of a specific system browser, not a concept. It never
wanted to be anything else than a System Browser. Btw, the future coding
solution will unlikely be called System Browser -  :).


>That is why I think we have conceptually a different solution than we ever
> had.
>
> I do not see where it is different now. Diving into object was alway
> possible with existing tools.


That is not the point. That's a technical detail. The fact that I can get
several times faster in creating a visualization or in playing with a query
script is what matters.



> >>3. There is a "Workspace open" but no "Playground open" possibility.
> > I think I do not get this point. What do you mean?
>
> Evaluate
>
> "Workspace open"=> it opens a window
>
>"Playground open"=> not defined


It is defined:
GTPlayground open

Still, where does this argument fit?


>>4. Having two separate tools "Workspace" and "Playground" with nearly
> similar
> >>  goals (write scripts and inspect objects) would be confusing for
> newbees.
> >>
> >>Maybe we could set up a "community voting" somewhere.
> >
> >Perhaps.
>
> If we would like to work as a community and respect other opinions it would
> make sense.
>

I think this is what the mail was all about, was it not?



> So far I guess there are three options discussed:
>
>   a) Keep existing "Workspace" tool and add additional "Playground" tool
>   b) One tool with new name "Playground" (no workspace)
>   c) One tool with known name "Workspace" by renaming the Playground tool
>

Sure. But, this makes some sense only after we have laid out arguments
which is what we do right now.



> >Good point! Can you add a bug issue for this?
>
> https://pharo.fogbugz.com/f/cases/14578/Ask-before-saving-in-the-cloud
>
> Thanks!

Doru


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Excel binding

[Markus Fritsche]

  
  
Replies inline
  

On 08.12.2014 17:07, Blondeau Vincent
  wrote:


  
  
  
  
 
 
De :
Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org]
De la part de Esteban A. Maringolo
Envoyé : lundi 8 décembre 2014 16:01
À : Pharo Development List
Objet : Re: [Pharo-dev] Excel binding
 

  El Mon Dec 08
2014 at 11:41:23 AM, Markus Fritsche 
escribió:
  On
2014-12-08 15:22, Blondeau Vincent wrote:
> Does someone know if there is a mean to access Excel
sheets from Pharo
> to get data?

> I don't want to use .csv files but .xls/.xlsx files.

If you're just going to use .xlsx files, it might be
possible to unzip
the file and peek the xml representation of that table (not
that I've
done it though).
  By unzip the file you actually see the xml,
  but I will complicated to use the values of the formula
  cells and to differentiate the sheets...

  

Yup - I don't know the excel xml format, just remembered that it
might be an option...

  

  
  
  If you're going to support .xls / Excel < 2003 files,
  you will probably
  need a COM-bridge. I remember that I've seen it
for Squeak in the past,
I don't recall having seen it for Pharo.
  It is only Excel
  > 2003.
  
  
  Another kind of hackish solution could be setting up an
  ODBC driver for
  Excel files and then using DBXTalk/ODBC or the
  ConfigurationOfODBC-based
  package.
  
 
I have tried. 
But when I launch
the DBXTalk tests it asked me to choose a
DBXODBX*Facility... Which one should I choose? 
  

  


here is how I connect to an access database on windows:

execute once per session:
OpenDBX current: NBPharoOpenDBX new.

then (access):

| aRow conn settings result |
settings := DBXConnectionSettings host: ''
  port: '' database: ''
  userName: '' userPassword: ''.
conn := ((DBXConnection new settings: settings) platform:
  DBXOdbcBackend new) connect.
conn open.
result := conn execute: 'SELECT * FROM '.
aRow := result nextRow.
[ aRow notNil ] whileTrue: [ 
    aRow values do: [ :value | Transcript show: value; show:
  $; ]. Transcript cr. aRow := result nextRow ].
conn close.
  
Everything in <> brackets needs to be replaced by actual
values. Also, the ODBC backend doesn't support many types =>
which will probably break too :-(

And you will need libopendbx-1.dll, libopendbxplus-1.dll and
opendbx\libodbcbackend-1.dll in your image directory. 

That all being said - before I'll dive into that, I would
probably just whip up a vba script to convert the excel
tables to text files in bulk.


  

  
Should I install
some plugins?
And in
ConfigurationOfODBC there is no tests and doc so I don't
know how to launch it...
  

  

I think there are tests in the monticello repository next to the
ODBC package (there's probably a script command to install them, but
I am usually faster just installing the package from Monticello
manually).

Kind regards
  Markus
  




Re: [Pharo-dev] Pillar and figures


2014-12-08

Thread
Damien Cassou
On Mon, Dec 8, 2014 at 4:31 PM, p...@highoctane.be  wrote:
>
> But the figure is not staying between the two paragraphs for some reason.


I suppose you are talking about the PDF generation.


> Anyone having an explanation and a way to have the thing stay where it
> should?


you can't and probably don't want to do it. For the PDF output, LaTeX
is responsible for positioning the figures to maximize output quality.

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm."
Winston Churchill




Re: [Pharo-dev] Excel binding


2014-12-08

Thread
Blondeau Vincent


De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de Esteban 
A. Maringolo
Envoyé : lundi 8 décembre 2014 16:01
À : Pharo Development List
Objet : Re: [Pharo-dev] Excel binding

El Mon Dec 08 2014 at 11:41:23 AM, Markus Fritsche 
mailto:mfrits...@reauktion.de>> escribió:
On 2014-12-08 15:22, Blondeau Vincent wrote:
> Does someone know if there is a mean to access Excel sheets from Pharo
> to get data?

> I don't want to use .csv files but .xls/.xlsx files.

If you're just going to use .xlsx files, it might be possible to unzip
the file and peek the xml representation of that table (not that I've
done it though).

If you're going to support .xls / Excel < 2003 files, you will probably
need a COM-bridge. I remember that I've seen it for Squeak in the past,
I don't recall having seen it for Pharo.
I see it here: 
http://ss3.gemstone.com/ss/COM.html/Overview?_s=nm1ShYEJFkyZYmBY&_k=rAHtcYsTEzWiJL5n
Could I have access to the code please?
Thanks in advance,
Vincent


Another kind of hackish solution could be setting up an ODBC driver for
Excel files and then using DBXTalk/ODBC or the ConfigurationOfODBC-based
package.

All of this assuming you're running Pharo in Windows.

 Regards!



Ce message et les pièces jointes sont confidentiels et réservés à l'usage 
exclusif de ses destinataires. Il peut également être protégé par le secret 
professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant 
être assurée sur Internet, la responsabilité de Worldline ne pourra être 
recherchée quant au contenu de ce message. Bien que les meilleurs efforts 
soient faits pour maintenir cette transmission exempte de tout virus, 
l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne 
saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, the Worldline liability cannot be triggered for the 
message content. Although the sender endeavours to maintain a computer 
virus-free network, the sender does not warrant that this transmission is 
virus-free and will not be liable for any damages resulting from any virus 
transmitted.



Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
Torsten Bergmann
Doru wrote:
>Please look at the mail I sent to Torsten for a more thorough description of 
>my reasoning. For example, I do not like that >it implies that this is *the* 
>place where work happens, and this is clearly not the case.

Think about your arguments. You mentioned that workspace is not the only place 
where to work.
One can work also in the debugger or in the browser. 

Yes - but a playground is also not the only place where I play with objects. 
Some people love 
to play with their objects in the debugger, browser, script manager, or 
elsewhere...
 
>Yes, I use the playground extensively for so many use cases. I do not miss the 
>Workspace at all and I do 
>not use it since 2 years.

Maybe because ... (***drumroll***) it is conceptually nothing more than an 
enhanced workspace.
Sorry could'nt resists ;)

I stand with my point: the playground is too close to the existing concept of a 
Workspace to deserve 
a new name. At the opposite tools like "Spotter" really introduce something 
conceptually new.

Bye
T.

 








Re: [Pharo-dev] Applying GTSpotter to domain objects, an experiment


2014-12-08

Thread
Tudor Girba
Great!

Thanks a lot for doing this.

At this moment, you cannot add more than one action. It's hardcoded, but we
want to extend that part as well. We just did not get to do it yet.

Cheers,
Doru



On Mon, Dec 8, 2014 at 5:19 PM, Stephan Eggermont  wrote:

> GTSpotter looks like a nice way to build end-user applications too.
> An address book is a simple example of that, with parties and addresses
>
> Clear the address book
>
> ABAddressbookModel  reset.
>
> Add someone
>
> ABAddressbookModel default addFirst: 'Stephan' last:'Eggermont'.
>
> Add a telephone number to someone
>
> ABAddressbookModel default parties first addTelephone: '+31-6-'.
>
> Open a spotter on the address book
>
> GTSpotterMorph new
> width: 400;
> doLayout;
> spotterModel: (GTSpotter on: ABAddressbookModel default);
> openCenteredInWorld
>
>
> How do I add actions to add a person/address, edit it, or remove it?
> I can see how I can add one action, can I add multiple?
>
> Stephan
>



-- 
www.tudorgirba.com

"Every thing has its own flow"



[Pharo-dev] [pharo-project/pharo-core] 567409: 40404


2014-12-08

Thread
GitHub
  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 5674099bc758cec35af5d6cc062f1a58de31f72b
  
https://github.com/pharo-project/pharo-core/commit/5674099bc758cec35af5d6cc062f1a58de31f72b
  Author: Jenkins Build Server 
  Date:   2014-12-08 (Mon, 08 Dec 2014)

  Changed paths:
M 
Athens-Balloon.package/FT2GlyphRenderer.class/instance/accessing/setColor_.st
A 
Athens-Balloon.package/FT2GlyphRenderer.class/instance/private/pixelValue32Of_.st
M 
Athens-Core.package/AthensAffineTransform.class/instance/accessing/inverted.st
A 
Athens-Core.package/AthensAffineTransform.class/instance/private/inverseTransformHalfPi_.st
A 
Athens-Core.package/AthensAffineTransform.class/instance/private/inverseTransformPiOrZero_.st
M 
Athens-Core.package/AthensAffineTransform.class/instance/vector-transform/inverseTransform_.st
A ConfigurationOfAthens.package/ConfigurationOfAthens.class/README.md
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/class/accessing/project.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/class/development 
support/DevelopmentSupport.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/class/development 
support/validate.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/class/loading/load.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/class/loading/loadBleedingEdge.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/class/loading/loadDevelopment.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/class/loading/loadStable.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/class/loading/loadVersion_.st
A ConfigurationOfAthens.package/ConfigurationOfAthens.class/class/metacello 
tool support/isMetacelloConfig.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/class/private/baseConfigurationClassIfAbsent_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/class/private/ensureMetacello.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/class/private/ensureMetacelloBaseConfiguration.st
A ConfigurationOfAthens.package/ConfigurationOfAthens.class/definition.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/accessing/project.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/baselines/baseline10_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/baselines/baseline11_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/baselines/baseline20_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/baselines/baseline21_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/baselines/baseline22_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/baselines/baseline23_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/development_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/stable_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/version011_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/version012_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/version013_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/version014_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/version01_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/version10_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/version11_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/version121_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/version12_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/version13_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/version14_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/version15_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/version16_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/version20_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/version21_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/version22_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/version23_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/version24_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/version25_.st
A 
Confi

[Pharo-dev] [pharo-project/pharo-core]


2014-12-08

Thread
GitHub
  Branch: refs/tags/40404
  Home:   https://github.com/pharo-project/pharo-core



[Pharo-dev] Applying GTSpotter to domain objects, an experiment


2014-12-08

Thread
Stephan Eggermont
GTSpotter looks like a nice way to build end-user applications too.
An address book is a simple example of that, with parties and addresses

Clear the address book

ABAddressbookModel  reset.

Add someone

ABAddressbookModel default addFirst: 'Stephan' last:'Eggermont'.

Add a telephone number to someone

ABAddressbookModel default parties first addTelephone: '+31-6-'.

Open a spotter on the address book

GTSpotterMorph new
width: 400;
doLayout;
spotterModel: (GTSpotter on: ABAddressbookModel default);
openCenteredInWorld


How do I add actions to add a person/address, edit it, or remove it?
I can see how I can add one action, can I add multiple?

Stephan


Addressbook.st
Description: Binary data



Re: [Pharo-dev] [Esug-list] [Pharo-users] [ann] gtspotter: a	moldable interface for spotting objects


2014-12-08

Thread
Johan Fabry

OK now I get it … thanks for clarifying!
I think my confusion stems from the use of ‘category' and then talking about 
'the collection object’, which made me think about collections and source code 
and protocols and packages and I got lost.

I think that the sentence of the blog would be clearer like this (uppercase to 
show changes):

To do this, GTSpotter offers an extra action: diving in a RESULTS category. 
Pressing Cmd+Shift+ArrowRight dives in the collection OF RESULTS OF that 
category. Thus, we can continue refining the search inside the category.

So then, my suggestion for a legend at the bottom of the results list would be:
Cmd+Shift+ArrowUp/ArrowDown = Next/Prev category, Cmd+RightArrow = Dive into 
Result, Cmd+Shift+RightArrow = Dive into Category

> On Dec 8, 2014, at 12:48, Tudor Girba  wrote:
> 
> Hi,
> 
> Ok. Let's take it step by step and see if we cannot find a better way of 
> explaining.
> 
> Take a look at the first picture in the blog post. Entering GTSpo shows 
> results both for Classes and for Packages. These "Classes" and "Packages" are 
> what we call search categories, and they have associated a query processor 
> that can populate them with results (see the "Spotting your objects" section 
> from the bottom of the post).
> 
> In our case, we get 39 classes (of which only 5 are shown) and 1 package that 
> match the query. If you want to look at all those 39 classes, you can dive in 
> the whole collection behind the category in a separate step. This is achieved 
> through Cmd+Shift+ArrowRight. Does it make more sense now?
> 
> I did not consider the category to be confusing. Would you propose another 
> name?
> 
> Cheers,
> Doru
> 
> 
> On Mon, Dec 8, 2014 at 4:02 PM, Johan Fabry  wrote:
> Sorry, but no :-(
> 
> I am always confused when people say ‘category’ because the word has so many 
> overloaded meanings. The same happens in the blog post, it is not clear to me 
> what category means here, and what does it have to do with the collection 
> object?
> 
> > On Dec 7, 2014, at 11:16, Tudor Girba  wrote:
> >
> > Hi,
> >
> > Yes, we will still evolve the UI. At the very least you will get the 
> > shortkeys directly on the actions.
> >
> > The answer to your question is in the blog post:
> > GTSpotter offers an extra action: diving in a category. Pressing 
> > Cmd+Shift+ArrowRight dives in the collection object containing only the 
> > items from that category. Thus, we can continue refining the search inside 
> > the category.
> >
> > So, you will open the collection of that sub-category and you will see more 
> > items at once (not just 5). Is it clearer now?
> >
> > Cheers,
> > Doru
> 
> 
> 
> ---> Save our in-boxes! http://emailcharter.org <---
> 
> Johan Fabry   -   http://pleiad.cl/~jfabry
> PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile
> 
> 
> 
> 
> -- 
> www.tudorgirba.com
> 
> "Every thing has its own flow"



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile





Re: [Pharo-dev] Excel binding


2014-12-08

Thread
Blondeau Vincent


De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de Esteban 
A. Maringolo
Envoyé : lundi 8 décembre 2014 16:01
À : Pharo Development List
Objet : Re: [Pharo-dev] Excel binding

El Mon Dec 08 2014 at 11:41:23 AM, Markus Fritsche 
mailto:mfrits...@reauktion.de>> escribió:
On 2014-12-08 15:22, Blondeau Vincent wrote:
> Does someone know if there is a mean to access Excel sheets from Pharo
> to get data?

> I don't want to use .csv files but .xls/.xlsx files.

If you're just going to use .xlsx files, it might be possible to unzip
the file and peek the xml representation of that table (not that I've
done it though).
By unzip the file you actually see the xml, but I will complicated to use the 
values of the formula cells and to differentiate the sheets...


If you're going to support .xls / Excel < 2003 files, you will probably
need a COM-bridge. I remember that I've seen it for Squeak in the past,
I don't recall having seen it for Pharo.

It is only Excel > 2003.


Another kind of hackish solution could be setting up an ODBC driver for
Excel files and then using DBXTalk/ODBC or the ConfigurationOfODBC-based 
package.



I have tried.

But when I launch the DBXTalk tests it asked me to choose a DBXODBX*Facility... 
Which one should I choose? Should I install some plugins?

And in ConfigurationOfODBC there is no tests and doc so I don't know how to 
launch it...



I heard about OLE (Object Linking and Embedding) to interact with Windows 
objects. Do you know it and what is the difference?

All of this assuming you're running Pharo in Windows.

 Regards!




Of course !



Regards,

Vincent




Ce message et les pièces jointes sont confidentiels et réservés à l'usage 
exclusif de ses destinataires. Il peut également être protégé par le secret 
professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant 
être assurée sur Internet, la responsabilité de Worldline ne pourra être 
recherchée quant au contenu de ce message. Bien que les meilleurs efforts 
soient faits pour maintenir cette transmission exempte de tout virus, 
l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne 
saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, the Worldline liability cannot be triggered for the 
message content. Although the sender endeavours to maintain a computer 
virus-free network, the sender does not warrant that this transmission is 
virus-free and will not be liable for any damages resulting from any virus 
transmitted.



Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
Torsten Bergmann
>And Playground would match so well the marketing term of "playing with live 
>objects". 

Sorry - but to me it looks like you were catched too much into: now we have to 
be more modern
or rival with all this "lively" stuff (Lighttable IDE, Apple Swift, ...). We 
all know
that being "lively" is something Smalltalk had already years ago and in the 
best way one 
can do it.

>You might say that Playground is not the only place where people can play with 
>objects, but

Same argument against Workspace is an argument against Playground then. Any 
reason
you did not continue after your "but"?
 
>Not all. Swift calls it Playground (yes, they copied us ;))

Because Swift uses this does mean ... (***drumrol***) ... NOTHING. Will we 
rename BlockClosures 
to Closures now? Or introduce curly braces? ;)
  
>You are looking at it from a technical point of view. Yes, it's just a merge 
>of two features, 
>but it is the end experience that is so much different. 

You said it yourself: we just present it differently. Nothing more. Does a 
concept really justify 
a new name if only presented differently?

I really doubt! Otherwise we would have had to rename the concept of a "System 
Browser" anytime 
we improved the end user experience (which differs also if you compare old 
style Squeak browsers
and new Nautilus implementation).

>That is why I think we have conceptually a different solution than we ever had.

I do not see where it is different now. Diving into object was alway possible 
with existing tools.

 
>>3. There is a "Workspace open" but no "Playground open" possibility.
> I think I do not get this point. What do you mean?
 
Evaluate 

"Workspace open"=> it opens a window

   "Playground open"=> not defined


>>4. Having two separate tools "Workspace" and "Playground" with nearly similar
>>      goals (write scripts and inspect objects) would be confusing for 
>>newbees.
>>
>>Maybe we could set up a "community voting" somewhere.
> 
>Perhaps.
 
If we would like to work as a community and respect other opinions it would
make sense. 

So far I guess there are three options discussed:

  a) Keep existing "Workspace" tool and add additional "Playground" tool
  b) One tool with new name "Playground" (no workspace)
  c) One tool with known name "Workspace" by renaming the Playground tool
 
>Good point! Can you add a bug issue for this?

https://pharo.fogbugz.com/f/cases/14578/Ask-before-saving-in-the-cloud




Re: [Pharo-dev] [Esug-list] [Pharo-users] [ann] gtspotter: a moldable interface for spotting objects


2014-12-08

Thread
Tudor Girba
Hi,

Ok. Let's take it step by step and see if we cannot find a better way of
explaining.

Take a look at the first picture in the blog post. Entering GTSpo shows
results both for Classes and for Packages. These "Classes" and "Packages"
are what we call search categories, and they have associated a query
processor that can populate them with results (see the "Spotting your
objects" section from the bottom of the post).

In our case, we get 39 classes (of which only 5 are shown) and 1 package
that match the query. If you want to look at all those 39 classes, you can
dive in the whole collection behind the category in a separate step. This
is achieved through Cmd+Shift+ArrowRight. Does it make more sense now?

I did not consider the category to be confusing. Would you propose another
name?

Cheers,
Doru


On Mon, Dec 8, 2014 at 4:02 PM, Johan Fabry  wrote:

> Sorry, but no :-(
>
> I am always confused when people say ‘category’ because the word has so
> many overloaded meanings. The same happens in the blog post, it is not
> clear to me what category means here, and what does it have to do with the
> collection object?
>
> > On Dec 7, 2014, at 11:16, Tudor Girba  wrote:
> >
> > Hi,
> >
> > Yes, we will still evolve the UI. At the very least you will get the
> shortkeys directly on the actions.
> >
> > The answer to your question is in the blog post:
> > GTSpotter offers an extra action: diving in a category. Pressing
> Cmd+Shift+ArrowRight dives in the collection object containing only the
> items from that category. Thus, we can continue refining the search inside
> the category.
> >
> > So, you will open the collection of that sub-category and you will see
> more items at once (not just 5). Is it clearer now?
> >
> > Cheers,
> > Doru
>
>
>
> ---> Save our in-boxes! http://emailcharter.org <---
>
> Johan Fabry   -   http://pleiad.cl/~jfabry
> PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"



[Pharo-dev] Pillar and figures


2014-12-08

Thread
p...@highoctane.be
I am writing a book using Pillar.

Here is the problem I do have:

I put something like

Some text explaining XYZ..

 +SomeCaption>file://figures/somefigure.png+

Some other text...


But the figure is not staying between the two paragraphs for some reason.

Anyone having an explanation and a way to have the thing stay where it
should?

TIA
Phil



Re: [Pharo-dev] Excel binding


2014-12-08

Thread
Esteban A. Maringolo
El Mon Dec 08 2014 at 11:41:23 AM, Markus Fritsche 
escribió:

> On 2014-12-08 15:22, Blondeau Vincent wrote:
> > Does someone know if there is a mean to access Excel sheets from Pharo
> > to get data?
>
> > I don't want to use .csv files but .xls/.xlsx files.
>
> If you're just going to use .xlsx files, it might be possible to unzip
> the file and peek the xml representation of that table (not that I've
> done it though).
>
> If you're going to support .xls / Excel < 2003 files, you will probably
> need a COM-bridge. I remember that I've seen it for Squeak in the past,
> I don't recall having seen it for Pharo.
>
> Another kind of hackish solution could be setting up an ODBC driver for
> Excel files and then using DBXTalk/ODBC or the ConfigurationOfODBC-based
> package.
>
>
All of this assuming you're running Pharo in Windows.

 Regards!



Re: [Pharo-dev] [Esug-list] [Pharo-users] [ann] gtspotter: a	moldable interface for spotting objects


2014-12-08

Thread
Johan Fabry
Sorry, but no :-(

I am always confused when people say ‘category’ because the word has so many 
overloaded meanings. The same happens in the blog post, it is not clear to me 
what category means here, and what does it have to do with the collection 
object?

> On Dec 7, 2014, at 11:16, Tudor Girba  wrote:
> 
> Hi,
> 
> Yes, we will still evolve the UI. At the very least you will get the 
> shortkeys directly on the actions.
> 
> The answer to your question is in the blog post:
> GTSpotter offers an extra action: diving in a category. Pressing 
> Cmd+Shift+ArrowRight dives in the collection object containing only the items 
> from that category. Thus, we can continue refining the search inside the 
> category.
> 
> So, you will open the collection of that sub-category and you will see more 
> items at once (not just 5). Is it clearer now?
> 
> Cheers,
> Doru



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile





Re: [Pharo-dev] Code repository


2014-12-08

Thread
Ben Coman

Benoit St-Jean wrote:

Hi guys!

Coming back to Pharo!

I was wondering, what is the preferred code repository for Pharo 3.x/4.x 
packages?  SqueakSource 3 or SmalltalkHub ?


tia
 
-

Benoit St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)


There seems more Pharo activity on SmalltalkHub, but I haven't heard of 
anything wrong with Squeaksource 3.


btw, If you've been off-list for a while, have you tried PharoLauncher?
http://www.smalltalkhub.com/#!/~Pharo/PharoLauncher

cheers -ben




Re: [Pharo-dev] Excel binding


2014-12-08

Thread
Markus Fritsche

On 2014-12-08 15:22, Blondeau Vincent wrote:

Does someone know if there is a mean to access Excel sheets from Pharo
to get data?



I don't want to use .csv files but .xls/.xlsx files.


If you're just going to use .xlsx files, it might be possible to unzip 
the file and peek the xml representation of that table (not that I've 
done it though).


If you're going to support .xls / Excel < 2003 files, you will probably 
need a COM-bridge. I remember that I've seen it for Squeak in the past, 
I don't recall having seen it for Pharo.


Another kind of hackish solution could be setting up an ODBC driver for 
Excel files and then using DBXTalk/ODBC or the ConfigurationOfODBC-based 
package.





Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
Tudor Girba
Hi Sven,

Thanks for the kind words.

Doru

On Mon, Dec 8, 2014 at 2:33 PM, Sven Van Caekenberghe  wrote:

> More documentation is always better, but you can hardly accuse Doru from
> trying, he is making an excellent effort in explaining what he does and
> why, this is a lot of work, and I appreciate it very much. Note that he is
> also trying to convince others of alternative/new/experimental ideas, which
> is even harder.
>
> And apart from that, he (and his team) are not just talking, they write
> actual working code and make it available. Of course they get all sorts of
> feedback, that is why they do it, but please, please consider the amount of
> work and determination it costs to make all this real/useable and not just
> vapourware !
>
> I have the utmost respect for what they are doing and how they are doing
> it.
>
> You (and other users) have a choice: you can keep using Pharo 3 and the
> tools there instead of going along with the development branch. Pharo 3 is
> meant for stable production use, it matches most of the current
> publications.
>
> There is pharo-us...@lists.pharo.org for normal beginner discussions,
> most users should ask questions there, not the other way around as it is
> today. I read both and try to help anyone the best I can.
>
> Sven
>
> > On 08 Dec 2014, at 13:56, kilon alios  wrote:
> >
> > "But, those tools are already added. And they are documented on the
> humane-assessment.com blog, and this can serve as a strong basis for a
> more official documentation."
> >
> > my issue is not "when" but "whether" . If you want to wait out the
> release of Pharo 4 to make official documentation, thats fine by me . I
> take late documentation over no documentation, any day.
> >
> > The problem I see with Pharo and one factor I feel it may even lead to
> the demise of Pharo as a project is that we see new and very exciting sfuff
> added to Pharo like your tools, but the documentation part is lackaster to
> say the least. The real problem comes when the original author decides to
> abandon or not further develop his tools it becomes extremely difficult for
> new people to come in and contribute. The very fact that now we replace the
> old workspace with a new tool is the testament to this problem. I think the
> situation would be dramatically different if Worskpace was fully
> documented, both at the user level and developer level. Its afterall an
> extremely important tool for Pharo. If that was the case we would have seen
> a natural evolution of workspace which would have made Playground far less
> needed.
> >
> > So its not that I disagree just with you I disagree with the general
> management of Pharo that follows the mentality "let the new features in and
> we worry about the documentation later on".  No , no and NO!
> >
> >  I was recently asked by a newcomer to Pharo being a python developer
> himself whether he should invest in Pharo . He wanted my opinion because I
> have experience both in python and pharo . I was not suprised to find out
> that he struggled with the documentation and he was really reluctant to
> give Pharo a serious try. He loved the features and all that but his
> learning was a much bigger pain than his experience with python and other
> programming languages. I ended up recommending him to ask more question
> here in the mailing list and he replied he did not feel comfortable asking
> question that for him were "stupid". Can I blame him ? Of course not. He
> was not aware of many of the blog posts and other source of documentation
> that are not "official".
> >
> > Dont know who that person is and how important as a member would become
> for the Pharo community but I can clearly see his problems being common to
> anyone or almost anyone introduced to Pharo unless that person comes
> already with a Smalltalk background.
> >
> > What I do know is Pharo needs new people to come in and take it further
> and in order to do that we need to build a Pharo that is as inviting to
> newcomers as our abilities permits us to. Putting documentation as a second
> priority is a recipe to disaster.
> >
> >
> >
> >
> >
> >
> >
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"



Re: [Pharo-dev] Code repository


2014-12-08

Thread
stepharo

Welcome back

STHUB :)

Stef

Le 7/12/14 14:14, Benoit St-Jean a écrit :

Hi guys!

Coming back to Pharo!

I was wondering, what is the preferred code repository for Pharo 
3.x/4.x packages?  SqueakSource 3 or SmalltalkHub ?


tia
-
Benoit St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero". (A. Einstein)





[Pharo-dev] Excel binding


2014-12-08

Thread
Blondeau Vincent
Hi,

Does someone know if there is a mean to access Excel sheets from Pharo to get 
data?
I don't want to use .csv files but .xls/.xlsx files.

Thanks in advance

Cheers,

Vincent BLONDEAU




Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage 
exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret 
professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant 
?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre 
recherch?e quant au contenu de ce message. Bien que les meilleurs efforts 
soient faits pour maintenir cette transmission exempte de tout virus, 
l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne 
saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, the Worldline liability cannot be triggered for the 
message content. Although the sender endeavours to maintain a computer 
virus-free network, the sender does not warrant that this transmission is 
virus-free and will not be liable for any damages resulting from any virus 
transmitted.



Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
Tudor Girba
Hi,

Please look at the mail I sent to Torsten for a more thorough description
of my reasoning. For example, I do not like that it implies that this is
*the* place where work happens, and this is clearly not the case.

Yes, I use the playground extensively for so many use cases. I do not miss
the Workspace at all and I do not use it since 2 years.

Cheers,
Doru


On Mon, Dec 8, 2014 at 2:56 PM, Nicolai Hess  wrote:

> Hi Doru,
>
> I do not understand exactly what the difference is or why you wouldn't
> call GTPlayground  " a Workspace".
>
> As I think you are using GTPlayground  very extensively:
> Do YOU use the Workspace at all ?
> Do YOU miss something in GTPlayground, where you would say: "Yes, only a
> workspace should do this".
>
>
> Nicolai
>
>
> 2014-12-08 7:18 GMT+01:00 Tudor Girba :
>
>> Hi,
>>
>> As you might see, the GTPlayground is called playground not workspace.
>> The main reason for this is that workspace implies the place where work is
>> done, and work is typically associated with creating code.
>>
>> This is not the intention of the workspace.
>>
>> Workspace also comes with a history that is associated with actual
>> implementations. While the current GTPlayground might appear to be similar
>> to the workspace, I think the way you can use the latter produces a
>> significant shift.
>>
>> Furthermore, I think the term playground is more inline with the idea of
>> "playing with live objects". And, in the future, the implementation will
>> likely evolve towards even more liveliness.
>>
>> It is for this reason that I would prefer that the World menu item gets
>> renamed to Playground.
>>
>> What do you think?
>>
>> Cheers,
>> Doru
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow"
>>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"



Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
Tudor Girba
Exactly!

This is precisely the way we should look at tools: we should identify why
we need that tool, but not necessarily stick with the tool.

For example, people said a while ago that the Workspace is better than the
Playground for searching for things like implementors. While that might
have been the case at that time, I think that use case is better served by
the now existing Spotter.

It is important to understand the goal and not focus at the implementation.
This is the prerequisite for inventing something new. That is why I keep on
asking stupid questions like: "Why do you need this?" "When do you need
this?"

Coming back to your point, I think that "note tracker" is one of the last
use cases people use a Workspace for. I find this very interesting even if
I do not necessarily have this requirement for myself. I think at the
moment we can keep a renamed Workspace for that, but in the future we will
probably end up with something else. The use case is noted in my book :)

Cheers,
Doru



On Mon, Dec 8, 2014 at 2:50 PM, stepharo  wrote:

>
> Le 8/12/14 05:43, stepharo a écrit :
>
> Hi doru
>
> I would like to have playground be named playground and that we keep
> "workspace" but I would like to change the name to "SimpleNoteEditor".
>
> Why because this is always good to have simple tools to read from? (I'm
> not talking about the current workspace implementation but the new one).
> I would like even try to learn something from Playground implementation
> because the tools is more advanced while I'm not afraid to learn
> from a simple tool.
>
>  I do not like the idea that we are all forced to use one single tools. We
> are adults.
>
> Stef
>
>  Hi,
>
>  As you might see, the GTPlayground is called playground not workspace.
> The main reason for this is that workspace implies the place where work is
> done, and work is typically associated with creating code.
>
>  This is not the intention of the workspace.
>
>  Workspace also comes with a history that is associated with actual
> implementations. While the current GTPlayground might appear to be similar
> to the workspace, I think the way you can use the latter produces a
> significant shift.
>
>  Furthermore, I think the term playground is more inline with the idea of
> "playing with live objects". And, in the future, the implementation will
> likely evolve towards even more liveliness.
>
>  It is for this reason that I would prefer that the World menu item gets
> renamed to Playground.
>
>  What do you think?
>
>  Cheers,
> Doru
>
>  --
> www.tudorgirba.com
>
>  "Every thing has its own flow"
>
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"



Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
kilon alios
"Hi Kilon,

Please, let's get positive :)."

I dont believe in being positive or negative can help. I think being open
minded and seeing and exploring problems is far more reliable way to
improve. I also believe that reporting a real problem is far more
beneficial to a community than hiding it away.

"If it's not enough or not in the right place, you have to get specific and
we can address those problems, but you cannot say that there is no
documentation because that is simply not true."

I never said there is no documentation about the GT tools, I said there is
no official documentation, no chapter on PBE or Pharo for the Enterprise.

"Finally, fourth… we as a community has this tendency of start talking of A
and end talking of Z. "

Lets talk about me, I have fully answered the question and I was never
offtopic. The question was should Playground renamed to workspace, my
answer was no . why ? because there is no official documentation about it
and it should not be in the Pharo 4 image even if that is an unstable WIP
image. If that is not an ontopic answer then I have no clue what it is.

In any case I can clearly see there is a vast gap between how I think
coding should be done and what people contributing to Pharo think.
Obviously community is about democracy or should be and if people think
that Pharo goes toward a very good direction I have no issue with that, we
all make our choices and have our own opinions.



[Pharo-dev] [ANN] RProjectConnector V1.0


2014-12-08

Thread
Blondeau Vincent
Hello everyone,

I am glad to announce the first version of the RProjectConnector, a binding 
between Pharo and R using NativeBoost.

You can now call directly your R methods from Pharo:
data := (1 to: 1000) collect: #yourself.
res := (#acf asRFunctionWith: {data}) eval

To use it, you should copy the R libraries near the Pharo VM (see the 
documentation on SmalltalkHub to see how to proceed) and

Gofer it

smalltalkhubUser: 'VincentBlondeau' project: 'RProjectConnector';

configuration;

loadStable
Don't forget to relaunch Pharo after the installation to be able to use the 
connector.

The sources are available on Smalltalkhub:
http://smalltalkhub.com/#!/~VincentBlondeau/RProjectConnector

if you want to participate, just ask me!

Cheers,

Vincent BLONDEAU



Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage 
exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret 
professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant 
?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre 
recherch?e quant au contenu de ce message. Bien que les meilleurs efforts 
soient faits pour maintenir cette transmission exempte de tout virus, 
l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne 
saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, the Worldline liability cannot be triggered for the 
message content. Although the sender endeavours to maintain a computer 
virus-free network, the sender does not warrant that this transmission is 
virus-free and will not be liable for any damages resulting from any virus 
transmitted.



Re: [Pharo-dev] untypeable key combination


2014-12-08

Thread
Guillermo Polito
I think (I just think because I didn't write that class ^^) that class is
the result of an unfinished refactor...

On Mon, Dec 8, 2014 at 2:36 PM, stepharo  wrote:

>
> Le 7/12/14 12:21, Nicolai Hess a écrit :
>
>  We have a class KMUntypeableSingleKeyCombination
>> this is used for key kombinations with
>> tab
>> arrow
>> backspace 
>>
>> This is useful for printing key kombinations like
>> Ctrl+TAB
>>
>> "space" does not use the KMUntypeableSingleKeyCombination class,
>> therefore
>> a short cut like
>> Character space shift asKeyCombination
>> looks like
>> " Shift +  "
>>
>> shouldn't space use this class?
>> And I find the name a little bit misleading, what is a untypeable key?
>> The key is typeable, otherwise we couldn't use it.
>> Renaming the class to KMUnprintableSingleKeyCombination
>> isn't better, because we can print this keycombination.
>>
>>
> +1
>
>>
>> nicolai
>>
>>
>
>



Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
Nicolai Hess
Hi Doru,

I do not understand exactly what the difference is or why you wouldn't call
GTPlayground  " a Workspace".

As I think you are using GTPlayground  very extensively:
Do YOU use the Workspace at all ?
Do YOU miss something in GTPlayground, where you would say: "Yes, only a
workspace should do this".


Nicolai


2014-12-08 7:18 GMT+01:00 Tudor Girba :

> Hi,
>
> As you might see, the GTPlayground is called playground not workspace. The
> main reason for this is that workspace implies the place where work is
> done, and work is typically associated with creating code.
>
> This is not the intention of the workspace.
>
> Workspace also comes with a history that is associated with actual
> implementations. While the current GTPlayground might appear to be similar
> to the workspace, I think the way you can use the latter produces a
> significant shift.
>
> Furthermore, I think the term playground is more inline with the idea of
> "playing with live objects". And, in the future, the implementation will
> likely evolve towards even more liveliness.
>
> It is for this reason that I would prefer that the World menu item gets
> renamed to Playground.
>
> What do you think?
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>



Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
Tudor Girba
Hi,

This was a long mail :). I tried to address your points below.


On Mon, Dec 8, 2014 at 10:55 AM, Torsten Bergmann  wrote:

> I would go the opposite direction and rename the "Playground" window to
> "Workspace".
>
> Several reasons:
>
>1. "Playground" reminds me too much on toyish things (and we had too
> much of this
>   in the past already, thats why Pharo was forked). The windows
> intention is to be
>   used for both: prototyping and serious stuff.
>

Yes, I agree that it is where work can happen. But, it is not the only
place where work happens: the debugger or the code is also where work
happens :). This is why I find the workspace term misleading. And
Playground would match so well the marketing term of "playing with live
objects". You might say that Playground is not the only place where people
can play with objects, but


   2. "Workspace" depicts the area where you usually work and this term is
> IMHO much much
>   better suited. It is also a common concept known not only in
> Smalltalk but also
>   other IDE's.
>

Not all. Swift calls it Playground (yes, they copied us ;))


   3. I do not understand where the significant shift is (that justifies a
> new name) as
>   we had similar tools already in the past. Basically it is a script
> space merged with
>   an inspector, so more an evolution instead of a revolution.
>
>   (This does not mean that I'm not happy that the GT tools are now in
> and provide
>such an easy to use extensibility!)
>

You are looking at it from a technical point of view. Yes, it's just a
merge of two features, but it is the end experience that is so much
different. That is why I think we have conceptually a different solution
than we ever had.



>3. There is a "Workspace open" but no "Playground open" possibility.
>

I think I do not get this point. What do you mean?



>4. Having two separate tools "Workspace" and "Playground" with nearly
> similar
>   goals (write scripts and inspect objects) would be confusing for
> newbees.
>
> Maybe we could set up a "community voting" somewhere.
>

Perhaps.


Other things I would like to see:
> =
>   A. Change to "double clicking" behavior instead of "single clicking"
> when diving
>  deeper into the iVars of objects.
>
>  This would allow to use it as a normal inspector first without having
>  directly more and more panes opening to the right.
>
>  Anytime I start with a script in the initial code pane it is moving
> away
>  when using "Do it and go" and clicking on my objects iVars in the
> right
>  list view.
>
>  With a "double click" the user could decide hisself if he just wants
> to select
>  (single click to do any other menu item action) or dive deeper into
> the
>  object (double click).
>

The double click is not a good solution because it would interfere with
several use cases. One of them is the ability to go through a list and see
the preview to the right. If you would have to double-click or press Enter
to get the preview, it would be too hard. I am considering though to allow
a pseudo-mode and trigger the selection only when Cmd is pressed, but that
is tricky because it can conflict with multiple selections. Another thing
we consider is to freeze the first pane. This will likely solve most
problems.


  B. Possibility to have splitters between the opened panes because
> sometimes the
>  area is not wide enough.
>

This is hard to do because having full panes visible at all times (no
possibility of seeing half of a pane) is more important. I do not have a
solution to marry both of these concerns.



>   C. When several windows are open the "playgrounds" can not be
> distinguished by
>  title in the world tool bar.
>
>  Note that when I save a workspace contents the title of the workspace
> window
>  is changed to the *.ws file.
>

Point taken. This is an area of work that is not finished yet.


>   D. Change the initial tab name to something more meaninful (related to
> C).
>  Or use a better timestamp representation as the current precision. As
> a human
>  I do not distinguish up to milliseconds when opening such a window.
> Maybe up to
>  seconds is enough.
>
>  Using a tab is questionable by itself - we never have more than one
> on the
>  initial code pane...
>

This is indeed another area that is not yet quite finished. The time stamp
shows the actual name of the file from the play-cache folder. It is not
about precision. It is about uniqueness. We could imagine a different
scheme that provide a counter, but I do not think this would be any better.
We have a "tab" because I would like to get to having multiple playgrounds
in the same window. Likely, we should end up being able to change the name
of that playground and this will transparently map to a file that will be
placed in another dedicated folder (I think of calling it play-stash). At
that moment,

Re: [Pharo-dev] Announcements & inter-thread communication


2014-12-08

Thread
stepharo

Thanks for your questions.
My take is
- I would minimize thread and fork. I have the feeling that some 
people forgot or never knew that when we fork a process

we have to pay attention to sync points and race condition.

- About Announcements
- Ideally we would like to remove the changed:/update: and 
replace it by annoucements. Now it will take time

because the widgets are not expecting Annoucements.

Now to your point!

"Now you might say that the programmer should know enough about the 
structure of their threaded code to wrap the action in as critical 
section, but Announcements are a DECOUPLING mechanism, and maybe a THIRD 
PARTY library subscribes to an Announcement that later someone else 
wraps in a fork, and no-one notices possible race conditions created."


Yes!!!

I like your ideas:

"
With this arrangement, a third party subscribed to someone else's 
announcement, that is quietly changed to be wrapped by forked thread,
the third party's code now fails EARLY and OBVIOUS, rather than letting 
subtle race conditions occur at random times. "


This




Le 5/12/14 22:10, Ben Coman a écrit :

_BACKGROUND_

In relation to...
https://pharo.fogbugz.com/default.asp?13182
"Refactor MCFileRepositoryInspector >> versionSearchAccept:"

I am reviewing...
https://pharo.fogbugz.com/default.asp?13007
"Cannot integrate a slice with monticello (red square in the UI)"

and in general considering how Monticello uses multiple threads to 
allow  you to type in the filter while its downloading info from the 
remote repository (which would be good to have more of this sort thing).


Looking back at build 30814 just prior to slice 13007 being integrated,
I notice that MCFileRepositoryInspector>>setRepository:workingCopy: [1]
forks and sends #refresh, which sends #changed: #packageList.

and MCFileRepositoryInspector>>packageSearchAccept: [2]
also forks and sends #changed: #packageList

So there were three threads (including UI [3]) modifying object state, 
which was compounded by #packageList method doing a lot of work.  
Issue 13007 worked around this by moving the work of #packageList out 
to #packageListUpdate, and moved the #changed: sends from [1] & [2] 
also out into #packageListUpdate (and wrapped in a #defer:).



_QUESTIONS_

Now I am considering doing the same for issue 13182 
#versionSearchAccept:, and considering Pharo's goal is to replace all 
Dependents/#changed: mechanisms with Announcements.


1. So I am wondering if that would be a better direction to address this?

Then I wonder about how Announcements interact with threads.  I see 
that SubscriptionRegistry>>deliver: #protect's the generation of 
/interestedSubscriptions/, but the actual announcement delivery occurs 
in the open, in AnnoucemenSubscription>>delvier:,

in the sender's thread.

So for an example...

action := [ :it | self inform: 'removing child'.].
announcer on: RemoveChild do: action.

/action/ might be executed from different concurrent threads.

Now you might say that the programmer should know enough about the 
structure of their threaded code to wrap the action in as critical 
section, but Announcements are a DECOUPLING mechanism, and maybe a 
THIRD PARTY library subscribes to an Announcement that later someone 
else wraps in a fork, and no-one notices possible race conditions 
created.


2. So, is there something reasonable we can do to make the 
common/easier/safer single-threaded case the default, and make people 
work a bit harder to shoot themselves in the foot with multiple threads?


We could introduce Announcer>>onOtherThread:do:
with the purpose of making use of inter-thread announcements more 
explicit in a self documenting way.


Announcements accidentally passed between threads to Announcer>>on:do: 
would generate an exception advising "use #onOtherThread:do: "

with the reasonable expectation that use of #onOtherThread:do:
would follow the pattern...

announcer onOtherThread: RemoveChild do: [ :it |
myMutex critical: [ self inform: 'removing child' ].
].

With this arrangement, a third party subscribed to someone else's 
announcement, that is quietly changed to be wrapped by forked thread,
the third party's code now fails EARLY and OBVIOUS, rather than 
letting subtle race conditions occur at random times.



_PROPOSED IMPLEMENTATION_

"--"

Announcer>>subscribe: anAnnouncementClass do: aValuable
^ registry add: (
AnnouncementSubscription new
announcer: self;
process: Processor activeProcess
announcementClass: anAnnouncementClass;
valuable: aValuable)
"--"

AnnouncementSubscription>>deliver: anAnnouncement
process ~= Processor activeProcess ifTrue: [
self error: [ 'Cross thread announcements should subscribe 
using #onOtherThread:do: ' ].

^ (self handlesAnnouncement: anAnnouncement ) ifTrue: [
[action cull: anAnnouncement cull: announcer]
   

Re: [Pharo-dev] RBSmalllintContext>>primitiveComputerLiterals


2014-12-08

Thread
stepharo


Le 5/12/14 08:40, Ben Coman a écrit :


I just noticed RBSmalllintContext>>primitiveComputerLiterals
doesn't seem to follow the typical pattern for that naming convention.

Without digging to really understand it, I just wondered if it maybe 
should be called #computeLiteralsForPrimitive,

or #basicComputerLiterals, or something else...


basic


cheers -ben








Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
stepharo


Le 8/12/14 05:43, stepharo a écrit :

Hi doru

I would like to have playground be named playground and that we keep 
"workspace" but I would like to change the name to "SimpleNoteEditor".
Why because this is always good to have simple tools to read from? (I'm 
not talking about the current workspace implementation but the new one).
I would like even try to learn something from Playground implementation 
because the tools is more advanced while I'm not afraid to learn

from a simple tool.

I do not like the idea that we are all forced to use one single tools. 
We are adults.


Stef


Hi,

As you might see, the GTPlayground is called playground not 
workspace. The main reason for this is that workspace implies the 
place where work is done, and work is typically associated with 
creating code.


This is not the intention of the workspace.

Workspace also comes with a history that is associated with actual 
implementations. While the current GTPlayground might appear to be 
similar to the workspace, I think the way you can use the latter 
produces a significant shift.


Furthermore, I think the term playground is more inline with the idea 
of "playing with live objects". And, in the future, the 
implementation will likely evolve towards even more liveliness.


It is for this reason that I would prefer that the World menu item 
gets renamed to Playground.


What do you think?

Cheers,
Doru

--
www.tudorgirba.com 

"Every thing has its own flow"







Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
stepharo

+1
And there is plenty of blog post to turn them into chapters.
If everything we produce would have this documentation quality I would 
not be worried.


Le 8/12/14 05:33, Sven Van Caekenberghe a écrit :

More documentation is always better, but you can hardly accuse Doru from 
trying, he is making an excellent effort in explaining what he does and why, 
this is a lot of work, and I appreciate it very much. Note that he is also 
trying to convince others of alternative/new/experimental ideas, which is even 
harder.

And apart from that, he (and his team) are not just talking, they write actual 
working code and make it available. Of course they get all sorts of feedback, 
that is why they do it, but please, please consider the amount of work and 
determination it costs to make all this real/useable and not just vapourware !

I have the utmost respect for what they are doing and how they are doing it.

You (and other users) have a choice: you can keep using Pharo 3 and the tools 
there instead of going along with the development branch. Pharo 3 is meant for 
stable production use, it matches most of the current publications.

There is pharo-us...@lists.pharo.org for normal beginner discussions, most 
users should ask questions there, not the other way around as it is today. I 
read both and try to help anyone the best I can.

Sven


On 08 Dec 2014, at 13:56, kilon alios  wrote:

"But, those tools are already added. And they are documented on the 
humane-assessment.com blog, and this can serve as a strong basis for a more official 
documentation."

my issue is not "when" but "whether" . If you want to wait out the release of 
Pharo 4 to make official documentation, thats fine by me . I take late documentation over no 
documentation, any day.

The problem I see with Pharo and one factor I feel it may even lead to the 
demise of Pharo as a project is that we see new and very exciting sfuff added 
to Pharo like your tools, but the documentation part is lackaster to say the 
least. The real problem comes when the original author decides to abandon or 
not further develop his tools it becomes extremely difficult for new people to 
come in and contribute. The very fact that now we replace the old workspace 
with a new tool is the testament to this problem. I think the situation would 
be dramatically different if Worskpace was fully documented, both at the user 
level and developer level. Its afterall an extremely important tool for Pharo. 
If that was the case we would have seen a natural evolution of workspace which 
would have made Playground far less needed.

So its not that I disagree just with you I disagree with the general management of Pharo 
that follows the mentality "let the new features in and we worry about the 
documentation later on".  No , no and NO!

  I was recently asked by a newcomer to Pharo being a python developer himself whether he should 
invest in Pharo . He wanted my opinion because I have experience both in python and pharo . I was 
not suprised to find out that he struggled with the documentation and he was really reluctant to 
give Pharo a serious try. He loved the features and all that but his learning was a much bigger 
pain than his experience with python and other programming languages. I ended up recommending him 
to ask more question here in the mailing list and he replied he did not feel comfortable asking 
question that for him were "stupid". Can I blame him ? Of course not. He was not aware of 
many of the blog posts and other source of documentation that are not "official".

Dont know who that person is and how important as a member would become for the 
Pharo community but I can clearly see his problems being common to anyone or 
almost anyone introduced to Pharo unless that person comes already with a 
Smalltalk background.

What I do know is Pharo needs new people to come in and take it further and in 
order to do that we need to build a Pharo that is as inviting to newcomers as 
our abilities permits us to. Putting documentation as a second priority is a 
recipe to disaster.
















Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
stepharo

Hi doru

I would like to have playground be named playground and that we keep 
"workspace" but I would like to change the name to "SimpleNoteEditor".
I do not like the idea that we are all forced to use one single tools. 
We are adults.


Stef


Hi,

As you might see, the GTPlayground is called playground not workspace. 
The main reason for this is that workspace implies the place where 
work is done, and work is typically associated with creating code.


This is not the intention of the workspace.

Workspace also comes with a history that is associated with actual 
implementations. While the current GTPlayground might appear to be 
similar to the workspace, I think the way you can use the latter 
produces a significant shift.


Furthermore, I think the term playground is more inline with the idea 
of "playing with live objects". And, in the future, the implementation 
will likely evolve towards even more liveliness.


It is for this reason that I would prefer that the World menu item 
gets renamed to Playground.


What do you think?

Cheers,
Doru

--
www.tudorgirba.com 

"Every thing has its own flow"





Re: [Pharo-dev] From IRC: is glorp dead?


2014-12-08

Thread
stepharo



On 07 Dec 2014, at 17:59, Юрий Мироненко  wrote:

GLORP-based applications is main source of income for me for last several yers. 
It works just now. And it definetely works in Ubuntu x64, if it's important. 
And also works fine in Windows.

Yes, I know, but sometimes it is a bit difficult to set things up, giving all 
the different platforms.

Since this is a recurring question, I would be super if you could write a short 
article about your experiences.


+1
Let me know if I can help. I gathered a lot of glorp material other the 
years but I never program with it.




Another simple Glorp introduction is 
https://medium.com/@svenvc/reddit-st-in-10-cool-pharo-classes-1b5327ca0740


2014-12-07 18:31 GMT+03:00 Brad :
No, it's not dead, just pretty sleepy. I've got it working with MySQL on an 
Ubuntu 14.04 32bit OS, but not yet on a 64bit OS.

Once I get my 64bit OS working, I'm going to work on getting Glorp/DBXTalk 
working for real business activity.

Look here for some resources http://dbxtalk.smallworks.eu

Brad Selfridge
913-269-2385


On Dec 7, 2014, at 8:25 AM, Max Leske  wrote:

 From the IRC:

LudicrousMango: Hi can anyone tell me is Glorp dead?  I was trying to evaluate 
pharo as a replacement for an existing rails project, but I can't even find a 
way of connecting to my postgresql database.
LudicrousMango: can someone help point me in the right direction.  The 
Enterprise book leaves the setup part of glorp blank.
LudicrousMango: and the glorp.org site has expired
maxleske: LudicrousMango: good question. I’ll forward it to the dev mailing list


Cheers,
Max












Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
Alexandre Bergel
I do not completely buy the documentation argument. It is not a big deal saying 
when you read “Workspace” in a book, it is actually “Playground”. People even 
figure this out alone. The code browser mentioned in Pharo by example is fairly 
different from the one we have currently. It even has a different name! But 
people can sort this out very quickly.

Let’s move on, without caring much about old books. New books are being written 
and more will come. Let’s focus on making the system better!

Cheers,
Alexandre



> On Dec 8, 2014, at 10:29 AM, Esteban Lorenzano  wrote:
> 
> First, I want to say that in this special case I tend to be in agreement with 
> Torsten. Because I also see playground as an evolution of the good old 
> workspace. Also, most documentation still refers to that area as “workspace” 
> and not “playground”… and honestly I still do not understand why is 
> *fundamentally* different. Inspectors are also really different and 
> nevertheless we are still calling them inspectors… I suppose we can do the 
> same with playground/workspace.

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.







Re: [Pharo-dev] untypeable key combination


2014-12-08

Thread
stepharo


Le 7/12/14 12:21, Nicolai Hess a écrit :

We have a class KMUntypeableSingleKeyCombination
this is used for key kombinations with
tab
arrow
backspace 

This is useful for printing key kombinations like
Ctrl+TAB

"space" does not use the KMUntypeableSingleKeyCombination class, therefore
a short cut like
Character space shift asKeyCombination
looks like
" Shift +  "

shouldn't space use this class?
And I find the name a little bit misleading, what is a untypeable key?
The key is typeable, otherwise we couldn't use it.
Renaming the class to KMUnprintableSingleKeyCombination
isn't better, because we can print this keycombination.



+1


nicolai







Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
Sven Van Caekenberghe
More documentation is always better, but you can hardly accuse Doru from 
trying, he is making an excellent effort in explaining what he does and why, 
this is a lot of work, and I appreciate it very much. Note that he is also 
trying to convince others of alternative/new/experimental ideas, which is even 
harder.

And apart from that, he (and his team) are not just talking, they write actual 
working code and make it available. Of course they get all sorts of feedback, 
that is why they do it, but please, please consider the amount of work and 
determination it costs to make all this real/useable and not just vapourware !

I have the utmost respect for what they are doing and how they are doing it.

You (and other users) have a choice: you can keep using Pharo 3 and the tools 
there instead of going along with the development branch. Pharo 3 is meant for 
stable production use, it matches most of the current publications.

There is pharo-us...@lists.pharo.org for normal beginner discussions, most 
users should ask questions there, not the other way around as it is today. I 
read both and try to help anyone the best I can.

Sven

> On 08 Dec 2014, at 13:56, kilon alios  wrote:
> 
> "But, those tools are already added. And they are documented on the 
> humane-assessment.com blog, and this can serve as a strong basis for a more 
> official documentation."
> 
> my issue is not "when" but "whether" . If you want to wait out the release of 
> Pharo 4 to make official documentation, thats fine by me . I take late 
> documentation over no documentation, any day.
> 
> The problem I see with Pharo and one factor I feel it may even lead to the 
> demise of Pharo as a project is that we see new and very exciting sfuff added 
> to Pharo like your tools, but the documentation part is lackaster to say the 
> least. The real problem comes when the original author decides to abandon or 
> not further develop his tools it becomes extremely difficult for new people 
> to come in and contribute. The very fact that now we replace the old 
> workspace with a new tool is the testament to this problem. I think the 
> situation would be dramatically different if Worskpace was fully documented, 
> both at the user level and developer level. Its afterall an extremely 
> important tool for Pharo. If that was the case we would have seen a natural 
> evolution of workspace which would have made Playground far less needed. 
> 
> So its not that I disagree just with you I disagree with the general 
> management of Pharo that follows the mentality "let the new features in and 
> we worry about the documentation later on".  No , no and NO!
> 
>  I was recently asked by a newcomer to Pharo being a python developer himself 
> whether he should invest in Pharo . He wanted my opinion because I have 
> experience both in python and pharo . I was not suprised to find out that he 
> struggled with the documentation and he was really reluctant to give Pharo a 
> serious try. He loved the features and all that but his learning was a much 
> bigger pain than his experience with python and other programming languages. 
> I ended up recommending him to ask more question here in the mailing list and 
> he replied he did not feel comfortable asking question that for him were 
> "stupid". Can I blame him ? Of course not. He was not aware of many of the 
> blog posts and other source of documentation that are not "official".
> 
> Dont know who that person is and how important as a member would become for 
> the Pharo community but I can clearly see his problems being common to anyone 
> or almost anyone introduced to Pharo unless that person comes already with a 
> Smalltalk background.
> 
> What I do know is Pharo needs new people to come in and take it further and 
> in order to do that we need to build a Pharo that is as inviting to newcomers 
> as our abilities permits us to. Putting documentation as a second priority is 
> a recipe to disaster. 
> 
> 
> 
> 
> 
> 
> 





Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
Esteban Lorenzano
Ok… several things :)

First, I want to say that in this special case I tend to be in agreement with 
Torsten. Because I also see playground as an evolution of the good old 
workspace. Also, most documentation still refers to that area as “workspace” 
and not “playground”… and honestly I still do not understand why is 
*fundamentally* different. Inspectors are also really different and 
nevertheless we are still calling them inspectors… I suppose we can do the same 
with playground/workspace.

Second, while I understand people tend to react conservative to changes, please 
guys understand that to keep tools inside image forever just does not scales 
and then requirements like “ok for adding, but please let the old tools too” 
can not be a path to follow. Of course we are not going to remove immediately, 
but certainly during next cycle one of both will fade away.
It has to be like that because to maintain everything forever requires 
exponential resources… and we cannot do that. 

Third, documentation is important but hard to produce in a reliable way. Also, 
documentation style in pharo (or any smalltalk) is fundamentally different than 
documentation in other systems. We have a system and a culture that empowers 
system exploration and that is the way we need to improve things: more examples 
*in system* is better than written documentation (and we have several books now 
of written documentation, is just that some of them is outdated). 
And yes, we still need to improve a  lot in that area… but we are not in zero, 
quite the opposite… anyway, we will never have the kind of documentation that 
other system has… 

Finally, fourth… we as a community has this tendency of start talking of A and 
end talking of Z. Like this thread… this was a question about the name of a 
tool. Not a discussion about lack of documentation or a feedback thread. All 
concerns are super valid, but talking about them in the incorrect place are 
causing me (and I think several others) to miss the importance of all things. 
So: documentation is another thread, and feedback is another thread. I agree 
with both of you, but if you put it here it will be lost because they become 
invisible, 

cheers, 
Esteban


> On 08 Dec 2014, at 10:55, Torsten Bergmann  wrote:
> 
> I would go the opposite direction and rename the "Playground" window to
> "Workspace". 
> 
> Several reasons:
> 
>   1. "Playground" reminds me too much on toyish things (and we had too much 
> of this
>  in the past already, thats why Pharo was forked). The windows intention 
> is to be
>  used for both: prototyping and serious stuff.  
> 
>   2. "Workspace" depicts the area where you usually work and this term is 
> IMHO much much
>  better suited. It is also a common concept known not only in Smalltalk 
> but also
>  other IDE's.
> 
>   3. I do not understand where the significant shift is (that justifies a new 
> name) as 
>  we had similar tools already in the past. Basically it is a script space 
> merged with 
>  an inspector, so more an evolution instead of a revolution.
> 
>  (This does not mean that I'm not happy that the GT tools are now in and 
> provide 
>   such an easy to use extensibility!)
> 
>   3. There is a "Workspace open" but no "Playground open" possibility.
> 
>   4. Having two separate tools "Workspace" and "Playground" with nearly 
> similar
>  goals (write scripts and inspect objects) would be confusing for newbees.
> 
> Maybe we could set up a "community voting" somewhere.
> 
> 
> 
> Other things I would like to see:
> =
>  A. Change to "double clicking" behavior instead of "single clicking" when 
> diving 
> deeper into the iVars of objects. 
> 
> This would allow to use it as a normal inspector first without having 
> directly more and more panes opening to the right. 
> 
> Anytime I start with a script in the initial code pane it is moving away 
> when using "Do it and go" and clicking on my objects iVars in the right 
> list view. 
> 
> With a "double click" the user could decide hisself if he just wants to 
> select
> (single click to do any other menu item action) or dive deeper into the
> object (double click). 
> 
> 
>  B. Possibility to have splitters between the opened panes because sometimes 
> the 
> area is not wide enough.
> 
>  C. When several windows are open the "playgrounds" can not be distinguished 
> by 
> title in the world tool bar.
> 
> Note that when I save a workspace contents the title of the workspace 
> window 
> is changed to the *.ws file.
> 
>  D. Change the initial tab name to something more meaninful (related to C). 
> Or use a better timestamp representation as the current precision. As a 
> human 
> I do not distinguish up to milliseconds when opening such a window. Maybe 
> up to
> seconds is enough. 
> 
> Using a tab is questionable by itself - we never have more than one o

Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
Tudor Girba
Hi Kilon,

Please, let's get positive :).

I really do not see how your remarks apply to the current situation. We put
quite some effort in documenting GT tools through posts on the humane
assessment blog (in the meantime, the page should be more reliable - I
hope) and through examples in the image. We took specific care exactly in
providing examples so that people can have something to guide themselves by.

In fact, we did not release until we had those examples. Just look at the
announcement of Spotter and you will see that it has a significant usage
documentation.

If it's not enough or not in the right place, you have to get specific and
we can address those problems, but you cannot say that there is no
documentation because that is simply not true. I think we have enough
material to create a couple of chapters in a Pharo book, or even a book on
its own, and I think it is reasonable to assume that given that the
material is available we can find the rest of the effort to produce the
"official" documentation.

Cheers,
Doru



On Mon, Dec 8, 2014 at 1:56 PM, kilon alios  wrote:

> "But, those tools are already added. And they are documented on the
> humane-assessment.com blog, and this can serve as a strong basis for a
> more official documentation."
>
> my issue is not "when" but "whether" . If you want to wait out the release
> of Pharo 4 to make official documentation, thats fine by me . I take late
> documentation over no documentation, any day.
>
> The problem I see with Pharo and one factor I feel it may even lead to the
> demise of Pharo as a project is that we see new and very exciting sfuff
> added to Pharo like your tools, but the documentation part is lackaster to
> say the least. The real problem comes when the original author decides to
> abandon or not further develop his tools it becomes extremely difficult for
> new people to come in and contribute. The very fact that now we replace the
> old workspace with a new tool is the testament to this problem. I think the
> situation would be dramatically different if Worskpace was fully
> documented, both at the user level and developer level. Its afterall an
> extremely important tool for Pharo. If that was the case we would have seen
> a natural evolution of workspace which would have made Playground far less
> needed.
>
> So its not that I disagree just with you I disagree with the general
> management of Pharo that follows the mentality "let the new features in and
> we worry about the documentation later on".  No , no and NO!
>
>  I was recently asked by a newcomer to Pharo being a python developer
> himself whether he should invest in Pharo . He wanted my opinion because I
> have experience both in python and pharo . I was not suprised to find out
> that he struggled with the documentation and he was really reluctant to
> give Pharo a serious try. He loved the features and all that but his
> learning was a much bigger pain than his experience with python and other
> programming languages. I ended up recommending him to ask more question
> here in the mailing list and he replied he did not feel comfortable asking
> question that for him were "stupid". Can I blame him ? Of course not. He
> was not aware of many of the blog posts and other source of documentation
> that are not "official".
>
> Dont know who that person is and how important as a member would become
> for the Pharo community but I can clearly see his problems being common to
> anyone or almost anyone introduced to Pharo unless that person comes
> already with a Smalltalk background.
>
> What I do know is Pharo needs new people to come in and take it further
> and in order to do that we need to build a Pharo that is as inviting to
> newcomers as our abilities permits us to. Putting documentation as a second
> priority is a recipe to disaster.
>
>
>
>
>
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"



Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
Alexandre Bergel
This is amazing to see such many different opinions. For me, I would keep it 
innovative and breaking with its legacy. Playground for all! No more 
workspaces! And yeah, we will have to write new book about that. We are already 
working on this!

Cheers,
Alexandre


> On Dec 8, 2014, at 3:18 AM, Tudor Girba  wrote:
> 
> Hi,
> 
> As you might see, the GTPlayground is called playground not workspace. The 
> main reason for this is that workspace implies the place where work is done, 
> and work is typically associated with creating code.
> 
> This is not the intention of the workspace.
> 
> Workspace also comes with a history that is associated with actual 
> implementations. While the current GTPlayground might appear to be similar to 
> the workspace, I think the way you can use the latter produces a significant 
> shift.
> 
> Furthermore, I think the term playground is more inline with the idea of 
> "playing with live objects". And, in the future, the implementation will 
> likely evolve towards even more liveliness.
> 
> It is for this reason that I would prefer that the World menu item gets 
> renamed to Playground.
> 
> What do you think?
> 
> Cheers,
> Doru
> 
> -- 
> www.tudorgirba.com
> 
> "Every thing has its own flow"

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.







Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
p...@highoctane.be
Le 8 déc. 2014 13:57, "kilon alios"  a écrit :
>
> "But, those tools are already added. And they are documented on the
humane-assessment.com blog, and this can serve as a strong basis for a more
official documentation."
>
> my issue is not "when" but "whether" . If you want to wait out the
release of Pharo 4 to make official documentation, thats fine by me . I
take late documentation over no documentation, any day.
>
> The problem I see with Pharo and one factor I feel it may even lead to
the demise of Pharo as a project is that we see new and very exciting sfuff
added to Pharo like your tools, but the documentation part is lackaster to
say the least. The real problem comes when the original author decides to
abandon or not further develop his tools it becomes extremely difficult for
new people to come in and contribute. The very fact that now we replace the
old workspace with a new tool is the testament to this problem. I think the
situation would be dramatically different if Worskpace was fully
documented, both at the user level and developer level. Its afterall an
extremely important tool for Pharo. If that was the case we would have seen
a natural evolution of workspace which would have made Playground far less
needed.
>
> So its not that I disagree just with you I disagree with the general
management of Pharo that follows the mentality "let the new features in and
we worry about the documentation later on".  No , no and NO!
>
>  I was recently asked by a newcomer to Pharo being a python developer
himself whether he should invest in Pharo . He wanted my opinion because I
have experience both in python and pharo . I was not suprised to find out
that he struggled with the documentation and he was really reluctant to
give Pharo a serious try. He loved the features and all that but his
learning was a much bigger pain than his experience with python and other
programming languages. I ended up recommending him to ask more question
here in the mailing list and he replied he did not feel comfortable asking
question that for him were "stupid". Can I blame him ? Of course not. He
was not aware of many of the blog posts and other source of documentation
that are not "official".

Smalltalk vas always been a self selecting tool. Pharo is like that.

The bluebook is great to learn a lot.

As are a lot of free books.

But ppl do not read them it seems...

Now tell me a lot of R and Node packages are well documented... Argh. No.
They happen to have a lot of Q&A on SO.

Phik

>
> Dont know who that person is and how important as a member would become
for the Pharo community but I can clearly see his problems being common to
anyone or almost anyone introduced to Pharo unless that person comes
already with a Smalltalk background.
>
> What I do know is Pharo needs new people to come in and take it further
and in order to do that we need to build a Pharo that is as inviting to
newcomers as our abilities permits us to. Putting documentation as a second
priority is a recipe to disaster.
>
>
>
>
>
>
>



Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
kilon alios
"But, those tools are already added. And they are documented on the
humane-assessment.com blog, and this can serve as a strong basis for a more
official documentation."

my issue is not "when" but "whether" . If you want to wait out the release
of Pharo 4 to make official documentation, thats fine by me . I take late
documentation over no documentation, any day.

The problem I see with Pharo and one factor I feel it may even lead to the
demise of Pharo as a project is that we see new and very exciting sfuff
added to Pharo like your tools, but the documentation part is lackaster to
say the least. The real problem comes when the original author decides to
abandon or not further develop his tools it becomes extremely difficult for
new people to come in and contribute. The very fact that now we replace the
old workspace with a new tool is the testament to this problem. I think the
situation would be dramatically different if Worskpace was fully
documented, both at the user level and developer level. Its afterall an
extremely important tool for Pharo. If that was the case we would have seen
a natural evolution of workspace which would have made Playground far less
needed.

So its not that I disagree just with you I disagree with the general
management of Pharo that follows the mentality "let the new features in and
we worry about the documentation later on".  No , no and NO!

 I was recently asked by a newcomer to Pharo being a python developer
himself whether he should invest in Pharo . He wanted my opinion because I
have experience both in python and pharo . I was not suprised to find out
that he struggled with the documentation and he was really reluctant to
give Pharo a serious try. He loved the features and all that but his
learning was a much bigger pain than his experience with python and other
programming languages. I ended up recommending him to ask more question
here in the mailing list and he replied he did not feel comfortable asking
question that for him were "stupid". Can I blame him ? Of course not. He
was not aware of many of the blog posts and other source of documentation
that are not "official".

Dont know who that person is and how important as a member would become for
the Pharo community but I can clearly see his problems being common to
anyone or almost anyone introduced to Pharo unless that person comes
already with a Smalltalk background.

What I do know is Pharo needs new people to come in and take it further and
in order to do that we need to build a Pharo that is as inviting to
newcomers as our abilities permits us to. Putting documentation as a second
priority is a recipe to disaster.



[Pharo-dev] Morphic3 and BPG


2014-12-08

Thread
Torsten Bergmann
Hi,

Found the below one somewhere on the internet today.

To the graphic gurus: any comments regarding Morphic 3 or the 
new BPG format in the context of Pharo?

Thx
T.



-
CUIS Smalltalk-80 GUI algorithm now available in C, JS!

Maybe, some people haven't yet noticed, that CUIS Smalltalk GUI uses a 
completely different 
antialiasing algorithm. Excellent MORPHIC-3, antialiased: 
http://www.jvuletich.org/Morphic3/Morphic3-200911.html

The filter is named after Cornelius Lanczos (Hungarian pronunciation: [ 
ˈlaːntsoʃ])

Lanczos resampling or Lanczos filter is a mathematical formula used to smoothly 
interpolate the 
value of a digital signal between its samples.

So, no more artefacts! Resulting in a 3x higher compression without significant 
loss of 
image quality.

Isn't that just wonderful?

Here Fabrice Bellard's implementation: http://bellard.org/bpg/lena.html
-




Re: [Pharo-dev] [Pharo-users] [ann] gtspotter: a moldable interface	for spotting objects


2014-12-08

Thread
Tudor Girba
Hi Christophe,

On Mon, Dec 8, 2014 at 10:43 AM, Christophe Demarey <
christophe.dema...@inria.fr> wrote:

> Hi Doru and all,
>
> Great work. All these tools are really moving the development experience a
> step forward :)
> I will try it ASAP.
> At this time, I just wonder if it is possible to search text in method
> sources. It is often useful.
>

It's not done now, but you can just add it. It should probably take you a
couple of minutes :). Just try to follow the instructions from the end of
the post and let us know how it goes.



> Another related thing I don't know how to do, is to refactor a set of
> methods (could be some methods to 20 or more). In these methods, I send a
> specific message. Now, I just want to remove the message implementation (it
> is not a rename) and I have to update the code accordingly. Sometimes, I
> could do that by just a search/replace (text) functionality (would be cool
> to use patterns there) in methods source code but I cannot find a way do
> that for now. So I do it by hand.
> I wonder if it already exists a way to do that or if GTSpotter could
> address this issue.
>

I think this is out of the direct realm of GTSpotter. But, it would be an
interesting area nevertheless. We would likely be able to benefit from
combining somehow RB rules with spotter.

Cheers,
Doru




> Christophe.
>
> Le 7 déc. 2014 à 14:14, Tudor Girba a écrit :
>
> Hi,
>
> Alex Syrel, Andrei Chis and I are happy to announce a new addition to the
> Glamorous Toolkit:
> GTSpotter, a novel interface for spotting objects.
>
> GTSpotter has two goals:
> - Provide a uniform yet moldable interface that can work on any object, and
> - Handle searching through arbitrary levels of object nesting.
>
> We think this will have a significant impact on the development workflow
> in Pharo.
>
> Here is a couple of screenshots:
>  
> 
>
>
> A trailer is available here:
> https://www.youtube.com/watch?v=PhSmjR3NOlU
>
> A detailed description is available here:
> http://www.humane-assessment.com/blog/introducing-gtspotter
>
> It works already in Pharo 3.0 and can be played with by following the
> instructions from:
> http://gt.moosetechnology.org
>
> Please let us know what you think.
>
> Enjoy,
> The Glamorous Team
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"



Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
Torsten Bergmann
I would go the opposite direction and rename the "Playground" window to
"Workspace". 

Several reasons:

   1. "Playground" reminds me too much on toyish things (and we had too much of 
this
  in the past already, thats why Pharo was forked). The windows intention 
is to be
  used for both: prototyping and serious stuff.  

   2. "Workspace" depicts the area where you usually work and this term is IMHO 
much much
  better suited. It is also a common concept known not only in Smalltalk 
but also
  other IDE's.

   3. I do not understand where the significant shift is (that justifies a new 
name) as 
  we had similar tools already in the past. Basically it is a script space 
merged with 
  an inspector, so more an evolution instead of a revolution.

  (This does not mean that I'm not happy that the GT tools are now in and 
provide 
   such an easy to use extensibility!)

   3. There is a "Workspace open" but no "Playground open" possibility.

   4. Having two separate tools "Workspace" and "Playground" with nearly similar
  goals (write scripts and inspect objects) would be confusing for newbees.

Maybe we could set up a "community voting" somewhere.



Other things I would like to see:
=
  A. Change to "double clicking" behavior instead of "single clicking" when 
diving 
 deeper into the iVars of objects. 

 This would allow to use it as a normal inspector first without having 
 directly more and more panes opening to the right. 

 Anytime I start with a script in the initial code pane it is moving away 
 when using "Do it and go" and clicking on my objects iVars in the right 
 list view. 
 
 With a "double click" the user could decide hisself if he just wants to 
select
 (single click to do any other menu item action) or dive deeper into the
 object (double click). 


  B. Possibility to have splitters between the opened panes because sometimes 
the 
 area is not wide enough.

  C. When several windows are open the "playgrounds" can not be distinguished 
by 
 title in the world tool bar.
 
 Note that when I save a workspace contents the title of the workspace 
window 
 is changed to the *.ws file.

  D. Change the initial tab name to something more meaninful (related to C). 
 Or use a better timestamp representation as the current precision. As a 
human 
 I do not distinguish up to milliseconds when opening such a window. Maybe 
up to
 seconds is enough. 

 Using a tab is questionable by itself - we never have more than one on the 
 initial code pane...

  E. Easily saving in the cloud is nice - but I would ask the user before 
sending
 it. This prevents wrong usage by accidentially clicking.

 Think of usage in a business scenario where you may work with confidential 
 data that would otherwise be posted on the web... 
  
 
Thanks
T.





 






Re: [Pharo-dev] [Pharo-users] [ann] gtspotter: a moldable interface	for spotting objects


2014-12-08

Thread
Christophe Demarey
Hi Doru and all,

Great work. All these tools are really moving the development experience a step 
forward :)
I will try it ASAP.
At this time, I just wonder if it is possible to search text in method sources. 
It is often useful.
Another related thing I don't know how to do, is to refactor a set of methods 
(could be some methods to 20 or more). In these methods, I send a specific 
message. Now, I just want to remove the message implementation (it is not a 
rename) and I have to update the code accordingly. Sometimes, I could do that 
by just a search/replace (text) functionality (would be cool to use patterns 
there) in methods source code but I cannot find a way do that for now. So I do 
it by hand.
I wonder if it already exists a way to do that or if GTSpotter could address 
this issue.

Christophe.

Le 7 déc. 2014 à 14:14, Tudor Girba a écrit :

> Hi,
> 
> Alex Syrel, Andrei Chis and I are happy to announce a new addition to the 
> Glamorous Toolkit: 
> GTSpotter, a novel interface for spotting objects.
> 
> GTSpotter has two goals:
> - Provide a uniform yet moldable interface that can work on any object, and
> - Handle searching through arbitrary levels of object nesting.
> 
> We think this will have a significant impact on the development workflow in 
> Pharo.
> 
> Here is a couple of screenshots:
>   
> 
> 
> 
> A trailer is available here:
> https://www.youtube.com/watch?v=PhSmjR3NOlU
> 
> A detailed description is available here:
> http://www.humane-assessment.com/blog/introducing-gtspotter
> 
> It works already in Pharo 3.0 and can be played with by following the 
> instructions from:
> http://gt.moosetechnology.org
> 
> Please let us know what you think.
> 
> Enjoy,
> The Glamorous Team



smime.p7s
Description: S/MIME cryptographic signature



Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
Tudor Girba
Hi Kilon,

I agree with you in saying that we should have documentation.

But, those tools are already added. And they are documented on the
humane-assessment.com blog, and this can serve as a strong basis for a more
official documentation.

Please keep in mind that Pharo 4.0 is still under development, and things
will still change until the release.

And, of course, we would welcome anyone willing to contribute with
documentation.

Cheers,
Doru



On Mon, Dec 8, 2014 at 10:27 AM, kilon alios  wrote:

> I disagree as I also disagree with the replacement of workspace and the
> inspector.
>
> My opinion on this can be summarised as "*Nothing should be added to
> Pharo without being fully documented*" .
>
> The use of workspace and the inspector is well documented in PBE. There is
> no official documentation for GTPlayground and GTInspector. Sure those
> tools are not as powerful as the tools you guys have developed but they are
> production ready, well tested and fully documented.
>
> But I know of course that my opinion is not popular since pharoers care
> more about extending their environment than caring about newcomers or
> teaching people how to use Pharo. This is a trend that has dominated Pharo
> and it looks it will continue and takes Pharo a direction I definetly dont
> want to go. On the other hand Pharo is the only tool and language that does
> this at least compared to my experience.
>
> On Mon, Dec 8, 2014 at 10:47 AM, p...@highoctane.be 
> wrote:
>
>> This makes a lot of sense.
>>
>> Having a plain workspace alongside would be perfect for me.
>>
>> I am using Playground in my 3.0 (now having installed the new version
>> with the nicer menus) and it works well. But this is definitely not what I
>> use as a workspace.
>>
>> One use case for a plain Workspace is when providing a kind of list of
>> sample commands to customers to use on the image.
>>
>> Like in: "Open this workspace contents, here are the typical commands for
>> you to use".
>>
>> Removing this ability and having a large thing popping at the right is
>> really disturbing for these use cases.
>>
>> Phil
>>
>>
>>
>> On Mon, Dec 8, 2014 at 7:18 AM, Tudor Girba  wrote:
>>
>>> Hi,
>>>
>>> As you might see, the GTPlayground is called playground not workspace.
>>> The main reason for this is that workspace implies the place where work is
>>> done, and work is typically associated with creating code.
>>>
>>> This is not the intention of the workspace.
>>>
>>> Workspace also comes with a history that is associated with actual
>>> implementations. While the current GTPlayground might appear to be similar
>>> to the workspace, I think the way you can use the latter produces a
>>> significant shift.
>>>
>>> Furthermore, I think the term playground is more inline with the idea of
>>> "playing with live objects". And, in the future, the implementation will
>>> likely evolve towards even more liveliness.
>>>
>>> It is for this reason that I would prefer that the World menu item gets
>>> renamed to Playground.
>>>
>>> What do you think?
>>>
>>> Cheers,
>>> Doru
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Every thing has its own flow"
>>>
>>
>>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"



Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
p...@highoctane.be
On Mon, Dec 8, 2014 at 10:27 AM, kilon alios  wrote:

> I disagree as I also disagree with the replacement of workspace and the
> inspector.
>
> My opinion on this can be summarised as "*Nothing should be added to
> Pharo without being fully documented*" .
>
> The use of workspace and the inspector is well documented in PBE. There is
> no official documentation for GTPlayground and GTInspector. Sure those
> tools are not as powerful as the tools you guys have developed but they are
> production ready, well tested and fully documented.
>

That's why I think we should keep the classic tools in the system.
I am going to train people for two days on how to use the application and
people ask for reference works to read. I fall they see is different from
the books, that's a problem indeed.
Phil

>
> But I know of course that my opinion is not popular since pharoers care
> more about extending their environment than caring about newcomers or
> teaching people how to use Pharo. This is a trend that has dominated Pharo
> and it looks it will continue and takes Pharo a direction I definetly dont
> want to go. On the other hand Pharo is the only tool and language that does
> this at least compared to my experience.
>
> On Mon, Dec 8, 2014 at 10:47 AM, p...@highoctane.be 
> wrote:
>
>> This makes a lot of sense.
>>
>> Having a plain workspace alongside would be perfect for me.
>>
>> I am using Playground in my 3.0 (now having installed the new version
>> with the nicer menus) and it works well. But this is definitely not what I
>> use as a workspace.
>>
>> One use case for a plain Workspace is when providing a kind of list of
>> sample commands to customers to use on the image.
>>
>> Like in: "Open this workspace contents, here are the typical commands for
>> you to use".
>>
>> Removing this ability and having a large thing popping at the right is
>> really disturbing for these use cases.
>>
>> Phil
>>
>>
>>
>> On Mon, Dec 8, 2014 at 7:18 AM, Tudor Girba  wrote:
>>
>>> Hi,
>>>
>>> As you might see, the GTPlayground is called playground not workspace.
>>> The main reason for this is that workspace implies the place where work is
>>> done, and work is typically associated with creating code.
>>>
>>> This is not the intention of the workspace.
>>>
>>> Workspace also comes with a history that is associated with actual
>>> implementations. While the current GTPlayground might appear to be similar
>>> to the workspace, I think the way you can use the latter produces a
>>> significant shift.
>>>
>>> Furthermore, I think the term playground is more inline with the idea of
>>> "playing with live objects". And, in the future, the implementation will
>>> likely evolve towards even more liveliness.
>>>
>>> It is for this reason that I would prefer that the World menu item gets
>>> renamed to Playground.
>>>
>>> What do you think?
>>>
>>> Cheers,
>>> Doru
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Every thing has its own flow"
>>>
>>
>>
>


-- 
---
Philippe Back
Visible Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Mail:p...@highoctane.be | Web: http://philippeback.eu
Blog: http://philippeback.be | Twitter: @philippeback
Youtube: http://www.youtube.com/user/philippeback/videos

High Octane SPRL
rue cour Boisacq 101 | 1301 Bierges | Belgium

Pharo Consortium Member - http://consortium.pharo.org/
Featured on the Software Process and Measurement Cast -
http://spamcast.libsyn.com
Sparx Systems Enterprise Architect and Ability Engineering EADocX Value
Added Reseller



Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
kilon alios
I disagree as I also disagree with the replacement of workspace and the
inspector.

My opinion on this can be summarised as "*Nothing should be added to Pharo
without being fully documented*" .

The use of workspace and the inspector is well documented in PBE. There is
no official documentation for GTPlayground and GTInspector. Sure those
tools are not as powerful as the tools you guys have developed but they are
production ready, well tested and fully documented.

But I know of course that my opinion is not popular since pharoers care
more about extending their environment than caring about newcomers or
teaching people how to use Pharo. This is a trend that has dominated Pharo
and it looks it will continue and takes Pharo a direction I definetly dont
want to go. On the other hand Pharo is the only tool and language that does
this at least compared to my experience.

On Mon, Dec 8, 2014 at 10:47 AM, p...@highoctane.be 
wrote:

> This makes a lot of sense.
>
> Having a plain workspace alongside would be perfect for me.
>
> I am using Playground in my 3.0 (now having installed the new version with
> the nicer menus) and it works well. But this is definitely not what I use
> as a workspace.
>
> One use case for a plain Workspace is when providing a kind of list of
> sample commands to customers to use on the image.
>
> Like in: "Open this workspace contents, here are the typical commands for
> you to use".
>
> Removing this ability and having a large thing popping at the right is
> really disturbing for these use cases.
>
> Phil
>
>
>
> On Mon, Dec 8, 2014 at 7:18 AM, Tudor Girba  wrote:
>
>> Hi,
>>
>> As you might see, the GTPlayground is called playground not workspace.
>> The main reason for this is that workspace implies the place where work is
>> done, and work is typically associated with creating code.
>>
>> This is not the intention of the workspace.
>>
>> Workspace also comes with a history that is associated with actual
>> implementations. While the current GTPlayground might appear to be similar
>> to the workspace, I think the way you can use the latter produces a
>> significant shift.
>>
>> Furthermore, I think the term playground is more inline with the idea of
>> "playing with live objects". And, in the future, the implementation will
>> likely evolve towards even more liveliness.
>>
>> It is for this reason that I would prefer that the World menu item gets
>> renamed to Playground.
>>
>> What do you think?
>>
>> Cheers,
>> Doru
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow"
>>
>
>



Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
p...@highoctane.be
This makes a lot of sense.

Having a plain workspace alongside would be perfect for me.

I am using Playground in my 3.0 (now having installed the new version with
the nicer menus) and it works well. But this is definitely not what I use
as a workspace.

One use case for a plain Workspace is when providing a kind of list of
sample commands to customers to use on the image.

Like in: "Open this workspace contents, here are the typical commands for
you to use".

Removing this ability and having a large thing popping at the right is
really disturbing for these use cases.

Phil



On Mon, Dec 8, 2014 at 7:18 AM, Tudor Girba  wrote:

> Hi,
>
> As you might see, the GTPlayground is called playground not workspace. The
> main reason for this is that workspace implies the place where work is
> done, and work is typically associated with creating code.
>
> This is not the intention of the workspace.
>
> Workspace also comes with a history that is associated with actual
> implementations. While the current GTPlayground might appear to be similar
> to the workspace, I think the way you can use the latter produces a
> significant shift.
>
> Furthermore, I think the term playground is more inline with the idea of
> "playing with live objects". And, in the future, the implementation will
> likely evolve towards even more liveliness.
>
> It is for this reason that I would prefer that the World menu item gets
> renamed to Playground.
>
> What do you think?
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>



Re: [Pharo-dev] playground vs workspace


2014-12-08

Thread
Hilaire
Le 08/12/2014 07:18, Tudor Girba a écrit :
> It is for this reason that I would prefer that the World menu item gets
> renamed to Playground.
> 
> What do you think?
> 

I agree with your POV

Hilaire

-- 
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu






    

      
    
    
67 matches
    

    
Advanced search


Search the list




    
    

      

                               Site Navigation
      
      

        
The Mail Archive home
        

          pharo-dev - all messages
        

          pharo-dev  - about the list
        
Expand
      
    

    

      

  				Mail list logo
      
      
    
  

    

	        	      Footer information
    
    

      
The Mail Archive home
      
Add your mailing list
      
FAQ
      
Support
      
Privacy