from:"kilon"

Funnily enough I am in the exact opposite opinion, of Graphical approach
being vastly superior to text based approach including programming
languages. 25 years using computers and coding with them and still cannot
fathom why programming languages are still a think and why developers and
power users rely so much on text based approach. But whether I like it or
not the coding world is dominated by text based solutions.

Its a pointless debate though when it comes to pharo will depend on the
people doing the work. Personally I don't have the time of going very deep
into this and doing all the hard work it requires. My focus is elsewhere.
But I welcome any contribution.

As a lawyer myself and a coder, I cannot even begin to compare Latex to the
convenience of Libreoffice I use at work. Its not even a debate .  Latex is
something I never heard of until  Pillar introduced me to it. Can't imagine
who in the right mind would use this to document things, but I guess they
have their reasons.

I started with command line and CP/M back in 1988 but even back then when
GUIs were not mainstream (at least in my country) I was dreaming of
graphical intefaces that would lift me from the restrictions of text based
approach and the dreaded command line. I wish I had found out about
Smalltalk back then and its elegant solution to this problem.

I love Pillar because its simple and I like the syntax, but yeah in the end
I would choose a Graphical Documentation Tool no questions asked.

On Tue, Apr 21, 2015 at 7:39 PM, Dmitri Zagidulin dmi...@zagidulin.net
wrote:

 On Tue, Apr 21, 2015 at 12:15 PM, Sean P. DeNigris s...@clipperadams.com
 wrote:

 I dream that all documents in my Dynabook are WYSIWYG. However, the
 computing world seems to have regressed into writing documents in various
 forms of assembly code.


 Completely disagree, that it's a regression in any way :)  Text-based
 document writing has enabled so many more features than WYSIWYG approaches
 have ever dreamed of. I would be happy to debate the merits of the two
 approaches, feature-for-feature.

 You're basically pining for the equivalent of VisualBasic drag  drop
 programming, versus the flexibility of writing code in an editor. The
 latter wins, no contest. (Now, that is not to say that text-based code
 editing can't be /improved/ with better IDE tools, that's what we're all
 about after all.)

Re: [Pharo-dev] Improving the documentation model

Its funny you mention natural selection an extremely stupid and slow
process. Fortunately for us software evolves with artificial selection
which way faster and way more intelligent. But still it comes with a great
deal of flaws when you take a look at what exactly is popular in the coding
world nowdays . Or even outside the coding world. But yes we can sit here
and debate this for million of years.

I am not a GUI zealot though, I have my own opinion that I never try to
enforce on others. I am perfectly ok with people that prefer a text based
approach. The only thing I am saying that GUIs have one undisputed
advantage, they are not text based only ;)

For me it comes down to making sensible convenient and practical useful
UIs. How you do it , graphical or text based is secondary concern.

I am also aware of the fact that GUIs tend to be more difficult to create,
which provides a very good explanation why command lines are still quite
popular.

On Tue, Apr 21, 2015 at 9:48 PM, Nicolas Anquetil nicolas.anque...@inria.fr
 wrote:


 This remind me of a discussion a very long time ago on a newsgroup

 - a young zealot of GUI (windows, buttons, mouses) was asking himself and
 the community how people could deny that this was the best interface on
 earth or how anybody could prefer text based interface

 - a seasonned sys. admin then started to explain all the clicks he had to
 perform to create one new user account. Result: for one new user some
 minutes of work
 He then added that he had to create HUMDREDS of user every year and was so
 very happy that he did not had to do it all by pointing and clicking but
 had some scripts to do it.

 So the answer to all this is that there are very good and valid reasons to
 prefer text to all the shiny interfaces of he world.
 And you don't even have to look very far to find some.

 As for programming with in a graphical way, the ability has been around
 for decades.
 I believe we can safely assume that if people are still using textual
 interface after such a very long period (in computer science time frame),
 it is most certainly because natural selection has favoured the choice that
 had most advantages ...

 nicolas

 PS: which does not mean that GUI are completely useless


 On 21/04/2015 20:03, kilon alios wrote:

   Funnily enough I am in the exact opposite opinion, of Graphical
 approach being vastly superior to text based approach including programming
 languages. 25 years using computers and coding with them and still cannot
 fathom why programming languages are still a think and why developers and
 power users rely so much on text based approach. But whether I like it or
 not the coding world is dominated by text based solutions.

  Its a pointless debate though when it comes to pharo will depend on the
 people doing the work. Personally I don't have the time of going very deep
 into this and doing all the hard work it requires. My focus is elsewhere.
 But I welcome any contribution.

  As a lawyer myself and a coder, I cannot even begin to compare Latex to
 the convenience of Libreoffice I use at work. Its not even a debate .
 Latex is something I never heard of until  Pillar introduced me to it.
 Can't imagine who in the right mind would use this to document things, but
 I guess they have their reasons.

  I started with command line and CP/M back in 1988 but even back then when
 GUIs were not mainstream (at least in my country) I was dreaming of
 graphical intefaces that would lift me from the restrictions of text based
 approach and the dreaded command line. I wish I had found out about
 Smalltalk back then and its elegant solution to this problem.

  I love Pillar because its simple and I like the syntax, but yeah in the
 end I would choose a Graphical Documentation Tool no questions asked.

 On Tue, Apr 21, 2015 at 7:39 PM, Dmitri Zagidulin dmi...@zagidulin.net
 wrote:

  On Tue, Apr 21, 2015 at 12:15 PM, Sean P. DeNigris 
 s...@clipperadams.com wrote:

 I dream that all documents in my Dynabook are WYSIWYG. However, the
 computing world seems to have regressed into writing documents in various
 forms of assembly code.


  Completely disagree, that it's a regression in any way :)  Text-based
 document writing has enabled so many more features than WYSIWYG approaches
 have ever dreamed of. I would be happy to debate the merits of the two
 approaches, feature-for-feature.

  You're basically pining for the equivalent of VisualBasic drag  drop
 programming, versus the flexibility of writing code in an editor. The
 latter wins, no contest. (Now, that is not to say that text-based code
 editing can't be /improved/ with better IDE tools, that's what we're all
 about after all.)

[Pharo-dev] PharoLauncher all white !!!

I just downloaded latest pharolauncher from here

https://ci.inria.fr/pharo/view/Launcher/job/Launcher-Mac/lastSuccessfulBuild/artifact/Pharo_0.2.7.dmg

The new PL is all white, is this normal ? I cant see the panels to resize
them all see is white and the text.

Re: [Pharo-dev] Improving the documentation model

for the record this is something I am interested into contributing. It
would be great if we coordinate effort . I don't make big promises but I
can definitely spare some hours or even days. I am in the process of
documenting Morphic and I definitely want something more interactive
something more Pharo ;)

On Wed, Apr 22, 2015 at 12:01 AM Sean P. DeNigris s...@clipperadams.com
wrote:

 philippeback wrote
  Pillar is fine as long as we aren't forced into the backend quirks to get
  a
  given output.

 This is actually much more productive than I thought it would be :) We've
 identified some key intentions:
 - easy to version
 - easy to contribute
 - live (whether preview rendering or model being worked on)
 - portable (to other formats); i.e. not tied to one backend; I would add
 here that any syntax is just a serialized, dead form of the live model,
 which is what I really want to think about
 - easy to use for beginners (like WYSIWYG, live help)
 - pathway to efficient use for experts (a la command line, shortcuts,
 gestures; not mouse selection)

 That's a really great list. And WYSIWYG and Pillar are two different
 explorations into that problem space. But there is no point trying to
 convince through words, only to produce your favored approach that adresses
 those points more effectively than the other approach, or maybe we end up
 with two amazing approaches, like emacs and vim and we can happily debate
 forever ;)



 -
 Cheers,
 Sean
 --
 View this message in context:
 http://forum.world.st/Improving-the-documentation-model-tp4820814p4821009.html
 Sent from the Pharo Smalltalk Developers mailing list archive at
 Nabble.com.

Re: [Pharo-dev] [Pharo5] All systems on go!

yeap that was it, it now displays all , thank you Nicolai :)


On Wed, Apr 22, 2015 at 12:00 AM Nicolai Hess nicolaih...@web.de wrote:

 2015-04-21 22:47 GMT+02:00 kilon alios kilon.al...@gmail.com:

 I cant see pharo classes in Nautiluse apart from a few, unless i open
 them with GTSpotter , then they get added to Nautilus. Is this normal ? Is
 it because I miss the sources file ? and if yes where I find it ?


 No, there is an active package pane filter. I thnk this happend by
 accident, the field should be empty.




 On Tue, Apr 21, 2015 at 11:30 PM, Sean P. DeNigris s...@clipperadams.com
  wrote:

 Thanks, Marcus!! :)



 -
 Cheers,
 Sean
 --
 View this message in context:
 http://forum.world.st/Pharo5-All-systems-on-go-tp4820956p4821002.html
 Sent from the Pharo Smalltalk Developers mailing list archive at
 Nabble.com.

Re: [Pharo-dev] PharoLauncher all white !!!

Well I am not complaining , I definitely don't like hard coded colors :)

If none will I will take a look , its being sometime since I contributed to
PL.

On Tue, Apr 21, 2015 at 11:47 PM, Nicolai Hess nicolaih...@web.de wrote:



 2015-04-21 22:33 GMT+02:00 kilon alios kilon.al...@gmail.com:

 I just downloaded latest pharolauncher from here


 https://ci.inria.fr/pharo/view/Launcher/job/Launcher-Mac/lastSuccessfulBuild/artifact/Pharo_0.2.7.dmg

 The new PL is all white, is this normal ?


 Some hard coded values were removed from the Pharo3 theme
 and the theme default values are just white :)

 http://forum.world.st/PharoLauncher-and-Pharo-5-0-tp4820240p4820720.html


 I cant see the panels to resize them all see is white and the text.

Re: [Pharo-dev] pharo home page tagline

2015-04-17 Thread kilon alios

I just point them to my own Pharo website which I think it gives a more
clear picture what Pharo is all about , but hey , I am biased :)

http://thekilon.wix.com/pharo-about

On Fri, Apr 17, 2015 at 6:58 AM, Ben Coman b...@openinworld.com wrote:

 On reddit I see some questions regarding the IDE and OS rolled into one
 tagline on the pharo homepage.  Of course it makes sense to me, but I can
 see how it might not be clear to others, who might even think I don't need
 that, I already have an OS.  I think the tagline would be strong enough
 without it - less is more.

 cheers -ben

Re: [Pharo-dev] [update 5.0] #50001

2015-04-17 Thread kilon alios

make me wonder what pharo version 5001 will look like in 4996 years, but I
guess I can compromise for version 5 for now :) keep up the great work

On Fri, Apr 17, 2015 at 3:00 PM, Marcus Denker marcus.den...@inria.fr
wrote:

 50001
 -

 15288 Shortcuts in text editor are hardcoded
 https://pharo.fogbugz.com/f/cases/15288

Re: [Pharo-dev] [ANN] Pharo 4.0 is released!

2015-04-16 Thread kilon alios

great work people, keep pushing forward, sky is the limit :)

a minor mistake in the website

Check the annonucement http://pharo.org/news/pharo-4.0-released, and the
ChangeLogs
https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo40ChangeLogs.md
.

should be announcement

On Thu, Apr 16, 2015 at 12:29 PM, Esteban Lorenzano esteba...@gmail.com
wrote:

 Please spread widely.
 Sorry for multiple posts.

 (this post can be see here: http://pharo.org/news/pharo-4.0-released)

 Dear World,

 Pharo 4.0 (http://www.pharo.org) is here.

 Pharo is a pure object-oriented programming language and a powerful
 environment, focused on simplicity and immediate feedback.

 Many things have changed in Pharo. Here are some highlights:
 - Inspector/Playground/Spotter are new moldable development tools for
 inspecting, coding and searching objects.
 - Slots model instance variables as first class entities and enable
 meta-programming on this level.
 - ShoreLine reporter introduces a way to report system errors and collect
 statistics, that we will use for future improvements
 - Dark theme.

 These are just the more prominent highlights, but the details are just as
 important. We have closed 1697 issues in Pharo 4. Take a moment to go
 through a more detailed recount of the progress:


 https://github.com/pharo-project/ChangeLogs/blob/master/Pharo40ChangeLogs.md

 Pharo is improving on many fronts, but one of the most prominent changes
 is the addition of moldable tools for inspection and search. These tools
 provide extension mechanisms that allow every object to define ways in
 which it can be understood effectively. To provide an idea of the impact of
 the already existing extensions, the map below shows the Pharo classes
 grouped in packages, highlighting in red those parts of the system that
 have at least one such custom view coming with the main distribution. The
 spread of these extensions shows that moldability is powerful mechanism
 that can be used in many contexts.


 Remember that Pharo is your platform. We thank all the contributors of
 this release:

 Clara Allende, Jean-Baptiste Arnaud, Jean-Christophe Bach, Philippe Back,
 Clement Bera, Alexandre Bergel, Torsten Bergmann, Vincent Blondeau, Noury
 Bouraqadi, Santiago Bragagnolo, Johan Brichau, Sven Van Caekenberghe,
 Damien Cassou, Nicolas Cellier, Guido Chari, Dimitris Chloupis, Andrei
 Chis, Ben Coman, Bernardo Contreras, Tommaso Dal Sasso, Jan Van De Sandt,
 Christophe Demarey, Sean DeNigris, Marcus Denker, Martin Dias, Stephane
 Ducasse, Stephan Eggermont, Luc Fabresse, Johan Fabry, Hilaire Fernandes,
 Jerome Garcia, Tudor Girba, Thierry Goubier, Jigyasa Grover, Kris Gybels,
 Norbert Hartl, Dale Henrichs, Pablo Herrero, Nicolai Hess, Pavel Krivanek,
 Juraj Kubelka, Jan Kurs, Laurent Laffont, Jannik Laval, Kevin Lanvin, Max
 Leske, David Lewis, Diego Lont, Esteban Lorenzano, Tim Mackinnon, Attila
 Magyar, Esteban Maringolo, Stefan Marr, Max Mattone, Martin Mc Clure, Eliot
 Miranda, Alain Plantec, Guillermo Polito, Damien Pollet, Stefan Reichhart,
 Mark Rizun, Udo Schneider, Ignacio Sniechowski, Henrik Sperre Johansen,
 Igor Stasenko, Aliaksei Syrel, Ciprian Teodorov, Camille Teruel, Sebastian
 Tleye, Yuriy Tymchuk, Peter Uhnak, Andres Valloud, Sven Van Caekenberghe,
 Thomas Vincent, Jan Vrany, Martin Walk, Richard Wettel, Dmitri Zagidulin

 And all those who contributed indirectly, by reporting bugs, participating
 in discussion threads, providing feedback...

 Pharo 4.0 is another big step. And, the best is yet to come.

 Enjoy!
 The Pharo Team

Re: [Pharo-dev] Class comments rendered in Nautilus (through Pillar)

2015-04-16 Thread kilon alios

thank you Damien, will give a look , may I also use configuration browser ?
is it up to date ?

On Thu, Apr 16, 2015 at 11:16 AM, Damien Cassou damien.cas...@gmail.com
wrote:


 kilon alios kilon.al...@gmail.com writes:

  ok, but where and which repo ? Smalltalkhub ? GitHub ? Is part of Pillar
 ?
  How I install these packages ?

 load a Pillar image from
 https://ci.inria.fr/pharo-contribution/job/Pillar (using the launcher
 for example :-)) and load Pillar-TextRenderer and
 Pillar-NautilusProofOfConcept in this order from the pillar repository
 (already in monticello).

 --
 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] New User Question on Reddit

2015-04-16 Thread kilon alios

He asked also in irc and I helped him solve the problem by downloading the
sources.
Στις 17 Απρ 2015 2:11 π.μ., ο χρήστης Sean P. DeNigris 
s...@clipperadams.com έγραψε:

 https://news.ycombinator.com/item?id=9390760

 I installed this for Ubuntu 12.04. When I fired it up, it requested I
 choose
 and build a source file (different from Pharo 3). Then when it started, it
 said, Pharo cannot locate the source file named
 /usr/lib/pharo-vm/PharoV40.sources.

 Any ideas what to do?

 TIA, Steve



 -
 Cheers,
 Sean
 --
 View this message in context:
 http://forum.world.st/New-User-Question-on-Reddit-tp4820098.html
 Sent from the Pharo Smalltalk Developers mailing list archive at
 Nabble.com.

Re: [Pharo-dev] PharoV40 sources still broken?

You dont even need to do all that, just open a new image and immediately
complains that sources are missing. But for some strange reason I can
browser code , I thought no sources meant not being able to see the source
code. Restarting the image saved with the setting to download sources does
nothing.

On Wed, Apr 15, 2015 at 3:36 PM, Nicolai Hess nicolaih...@web.de wrote:

 pharo 4.0 608 with PharoV40 sources:

 - enter some text in a workspace
 - select the text
 - choose Method source with it

 -
 RemoteString(Object)error:
 [
 filePositionHi  theFile size
 ifTrue: [ self error: 'RemoteString past end of file' ].
 theFile position: filePositionHi.
 theFile nextChunk ] in RemoteStringstring in Block: [ ...
 BlockClosureensure:
 RemoteStringstring
 ClassOrganizationcomment
 ClassOrganizationclassComment
 [ :each |
 bar current: (count := count + 1).
 each
 selectorsDo: [ :sel |
 ((each sourceCodeAt: sel) includesSubstring: aString
 caseSensitive: caseSensitive)
 ifTrue: [ addMethod value: each value: sel ] ].
 (each organization classComment asString includesSubstring: aString
 caseSensitive: caseSensitive)
 ifTrue: [ addComment value: each ] ] in [ :bar |
 | count |
 count := 0.
 self
 allBehaviorsDo: [ :each |
 bar current: (count := count + 1).
 each
 selectorsDo: [ :sel |
 ((each sourceCodeAt: sel) includesSubstring: aString
 caseSensitive: caseSensitive)
 ifTrue: [ addMethod value: each value: sel ] ].
 (each organization classComment asString includesSubstring:
 aString caseSensitive: caseSensitive)
 ifTrue: [ addComment value: each ] ] ] in
 SystemNavigationallMethodsWithSourceString:matchCase: in Block: [ :each |
 ...
 [ :aClass |
 aBlock
 value: aClass;
 value: aClass class ] in SystemNavigationallBehaviorsDo: in Block: [
 :aClass | ...
 [ :name | aBlock value: (self at: name) ] in
 SystemDictionaryallClassesDo: in Block: [ :name | aBlock value: (self at:
 name) ]
 OrderedCollectiondo:
 SystemDictionaryallClassesDo:
 SystemNavigationallBehaviorsDo:
 [ :bar |
 | count |
 count := 0.
 self
 allBehaviorsDo: [ :each |
 bar current: (count := count + 1).
 each
 selectorsDo: [ :sel |
 ((each sourceCodeAt: sel) includesSubstring: aString
 caseSensitive: caseSensitive)
 ifTrue: [ addMethod value: each value: sel ] ].
 (each organization classComment asString includesSubstring:
 aString caseSensitive: caseSensitive)
 ifTrue: [ addComment value: each ] ] ] in
 SystemNavigationallMethodsWithSourceString:matchCase: in Block: [ :bar |
 ...
 BlockClosurecull:
 [ result := block cull: self ] in [
 self prepareForRunning.
 [ result := block cull: self ]
 on: JobNotification
 do: [ :notification | notification handle: self ] ] in Jobrun in
 Block: [ result := block cull: self ]
 BlockClosureon:do:
 [
 self prepareForRunning.
 [ result := block cull: self ]
 on: JobNotification
 do: [ :notification | notification handle: self ] ] in Jobrun in
 Block: [ ...
 BlockClosureensure:
 Jobrun
 MorphicUIManager(UIManager)displayProgress:from:to:during:
 ByteString(String)displayProgressFrom:to:during:
 SystemNavigationallMethodsWithSourceString:matchCase:
 SystemNavigationbrowseMethodsWithSourceString:matchCase:
 [ :aPresentation |
 aPresentation selectLine.
 self systemNavigation browseMethodsWithSourceString: aPresentation
 selectedText matchCase: false ] in
 GLMPharoPlaygroundPresentation(GLMRubricSmalltalkCodePresentation)browsingSelectionActions
 in Block: [ :aPresentation | ...
 BlockClosureglamourValueWithArgs:
 GLMGenericAction(GLMAction)actOn:
 GLMGenericAction(GLMAction)morphicActOn:
 [ :ann | ann action morphicActOn: aPresentation ] in
 GLMMorphicPharoPlaygroundRenderer(GLMMorphicWidgetRenderer)installActionsOnModel:fromPresentation:
 in Block: [ :ann | ann action morphicActOn: aPresentation ]
 BlockClosurecull:
 BlockClosurecull:cull:

Re: [Pharo-dev] Class comments rendered in Nautilus (through Pillar)

You want it for class comment , I want it for the Help Browser tool for the
Morphic documentation project I am doing . This could not come at a better
time, cant wait to look at the code, Thank you very much :)

On Wed, Apr 15, 2015 at 6:52 PM, Damien Cassou damien.cas...@gmail.com
wrote:

 Hi,

 Kasper Østerbye has just finished a proof-of-concept that renders Pillar
 text inside a class comment pane.

 From the view, the developer can press $ (dollar) to edit the document in
 Pillar.



 Best regards,

 --
 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] PharoV40 sources still broken?

I would not call it unstable, I downloaded the file as Esteban pointed
(thank you ) and it works fine for me.

On Wed, Apr 15, 2015 at 7:52 PM, Peter Uhnák i.uh...@gmail.com wrote:

 So what is the last known stable version now? 40605? Or can I use the
 latest?

 Peter

 On Wed, Apr 15, 2015 at 4:06 PM, Torsten Bergmann asta...@gmx.de wrote:

 This should fix it:
  Smalltalk allClasses do: [ :each | each class organization comment:
 nil; commentStamp: nil ]

 Yes - can confirm the error and can also confirm this statement fixes it.

 Thx
 T.

Re: [Pharo-dev] How to find versions of core packages?

You could take a look at the available configuration, there are usually
version methods in the instance side  like for example

version10: spec
version: '1.0' imports: #('1.0-baseline' )

On Wed, Apr 15, 2015 at 7:24 PM, Dmitri Zagidulin dmi...@zagidulin.net
wrote:

 How does one go about finding the version numbers of core libraries like
 SUnit that are included in a particular Pharo distribution?

 (What prompted me to try and find out is that at the start of the SUnit
 chapter in UPBE, it says In the future, Pharo may include version of
 SUnit4.0. And I was curious whether Pharo 4.0 includes that newer version
 of SUnit, etc. But I'm also curious whether there's a general procedure or
 convention for finding versions of external libraries that are also pulled
 into Pharo core.)

Re: [Pharo-dev] Class comments rendered in Nautilus (through Pillar)

ok, but where and which repo ? Smalltalkhub ? GitHub ? Is part of Pillar ?
How I install these packages ?

On Wed, Apr 15, 2015 at 9:15 PM, Kasper Osterbye kas...@itu.dk wrote:

 kilon.alios wrote
  So if you can provide me a link to your code, even if your code is far
  from
  final it will at least give me a good idea how things work. Suffice to
 see
  I am very fresh with Morphic myself but I love to learn it, document it
  and
  improve it.

 The packages are named Pillar-TextRenderer (to be loaded first) and
 Pillar-NautilusProofOfConcept (goes second). The proof of concept overrides
 one method in the nautilus browser, so to go back you need to revert that
 change (versions is your friend here).

 The key method in the Pillar-TextRenderer is: PRDecoratedTextWriter
 classon: aParsedPillarDoc

 -- Kasper



 --
 View this message in context:
 http://forum.world.st/Class-comments-rendered-in-Nautilus-through-Pillar-tp4819726p4819759.html
 Sent from the Pharo Smalltalk Developers mailing list archive at
 Nabble.com.

Re: [Pharo-dev] PetitMarkdown

2015-04-14 Thread kilon alios

Stef gets fierce emotional at times, he is very passionate about Pharo. I
dont think he has a problem with having a good MD parser though it looks
like that will be hard to do because of the nature of the MD syntax but his
real problem is people porting doc to MD and abandoning or not even giving
Pillar a serious try. That is something that concerns me too.

I agree with Stef that Pillar is really nice and frankly MD has little to
offer over Pillar. I also dont agree that MD is significantly more readable
than Pillar to justify choosing MD over Pillar. Also making a document
format tailor made for Pharo needs and ideology comes with its own big
benefit that may not be obvious on the short term but long term may make a
big difference.

I agree also having control over your own format is always a big benefit.

Also Pillar is not opposed to MD , quite the contrary it generates MD files
as it does HTML , LATEX and PDF files.

When I started using Pharo I also did not understand this obsession of
remaking so much technology in pharo. But now I know that the moment you
integrate something from scratch into a very powerful live environment like
Pharo it becomes a completely new thing. It becomes a live thing.  Its
definitely make the effort well worth it.  Now I am also a victim of this
curse ;)

I love Pillar, its super easy to learn, very easy to read and well its made
with Pharo which make it also easier to extend. Hands down a winner in my
book ;)

Go Pillar Go! :)

Ps: Help tool already support a very small part of Pillar syntax with its
wikisyntax pragma.


On Tue, Apr 14, 2015 at 11:03 PM, Dmitri Zagidulin dmi...@zagidulin.net
wrote:

 Whoa.
 I genuinely don't understand the fierce emotions here. Why do Pillar and
 Markdown have to be opposed? Why is wanting support for better parsing of
 MD (a commonly used format around the web, and useful in many projects)
 somehow an insult to the work done on Pillar?

 (Incidentally, I don't quite understand why Pillar was created in the
 first place. Why have a slightly different and incompatible markdown format
 from what the rest of the world is using? But that's not the point. We have
 both, and it's easy to support both. What's the problem?)


 On Tue, Apr 14, 2015 at 3:08 PM, stepharo steph...@free.fr wrote:

  I'm really pissed off. Because nearly nobody tried to write anything
 with pillar and you just talk
 about what you do not know.  But thanks this is great to see that we are
 spending our energy for people
 who will never even try to use what we are doing.
 Superb!

 No need to reply I will not read this thread anymore. And I should not
 even have because it was so obvious.

 And yes I 'm REALLY pissed off. You should also say to cyril that what is
 is doing is hopeless because as soon
 as we will have a stupid markdown parser suddenly it will be great. what
 a shit.

 So go and write your documentation in any format and do not expect me to
 look at it.
 I'm fed up about people that want doc on the web and when we spend time
 to migrate from latex to
 pillar to generate html and latex do not even consider what we did.

 Stef

  I would prefer pillar for class / packages comments


  I was quite surprised there are any MD defendants considering the
 pillar push. But since diversity is (often) a good think maybe having
 something like gt-inspector there would be cool where you can add this in
 whatever format you want. (And maybe one day someone will write pillar to
 morphic/whatever converter and it would be even cooler.)

It is a difficult topic. I agree with anyone that MarkDown is not a
 good format for parsing. Pillar is the right thing to do here. But there is
 one point of MarkDown that is hard to beat. A MarkDown text is always good
 to read, eben while writing. In something like a class comment it would be
 easy to use. What we don't want is to write system documentation in a
 format that you need to convert first before you can see the result. It is
 either having a wysiwyg editor for those things with pillar below or a
 simple format that can both.


  my 2 cents,



  that’s actually my main point too, yes.

  Esteban


  norbert

Re: [Pharo-dev] Contributing to Bloc

2015-04-07 Thread kilon alios

thats understanable and reasonable. I am impressed with how well it
emulates Morphic so far.

On Tue, Apr 7, 2015 at 5:50 PM, Alain Plantec via Pharo-dev 
pharo-dev@lists.pharo.org wrote:



 -- Forwarded message --
 From: Alain Plantec alain.plan...@yahoo.com
 To: Pharo Development List pharo-dev@lists.pharo.org
 Cc:
 Date: Tue, 7 Apr 2015 16:49:38 +0200
 Subject: Re: [Pharo-dev] Contributing to Bloc
 Hello,

 in fact you are running morphic widget inside bloc. The compatibility is
 not 100%.
 I guess here the problem is related to the global coordinate system of
 Morphic.
 We will try to fix it.
 Thanks for reporting.
 Cheers
 Alain


 On 06 Apr 2015, at 13:56, kilon alios kilon.al...@gmail.com wrote:

 another weird problem i just found is that right side down arrow menu when
 clicked it opens in random location instead of bellow its icon. I tried it
 with System Browser.

 By the way i am talking about already available Pharo tools and not bloc
 examples.

 On Mon, Apr 6, 2015 at 2:03 PM, Nicolai Hess nicolaih...@web.de wrote:

 2015-04-06 10:22 GMT+02:00 kilon alios kilon.al...@gmail.com:

 Hey guys, these last days I have taken a look at Bloc and really like
 its design. So I was wondering how I can be of assistance. I am not an
 experienced pharo jedi like you guys but I think I could do my small part
 to help make Bloc into a replacement for Morphic.

 From what I see Bloc some issues rendering Morphs , for example tabs
 (window groups) and some glitches here and there.



 I don't know a tabs example that is build with bloc.
 The current bloc world renders a classic Morph on an AthensCanvas if they
 define a
 #drawOnAthensCanvas: method.
 If this is missing or not correctly working, we should change the
 implementation in the Athens project (Athens-Morphic).





 So how am I proceed ? How I can help ?

Re: [Pharo-dev] Contributing to Bloc

2015-04-07 Thread kilon alios

No problem waiting for an answer.

Ok then I will keep using it and reporting problems I find. Documenting is
something I can do too, I am familiar with pillar , so I will send some
pull requests when I get a good understanding of Bloc. Contributing
examples is something I can do too, will wait for the move of bloc to a
public repo I can contribute too including comments.

For now I will stress tests and report and then when I am familiar enough
move to other tasks.

On Tue, Apr 7, 2015 at 6:01 PM, Alain Plantec via Pharo-dev 
pharo-dev@lists.pharo.org wrote:



 -- Forwarded message --
 From: Alain Plantec alain.plan...@yahoo.com
 To: Pharo Development List pharo-dev@lists.pharo.org
 Cc:
 Date: Tue, 7 Apr 2015 17:00:30 +0200
 Subject: Re: [Pharo-dev] Contributing to Bloc

  So how am I proceed ? How I can help ?


 sorry for the late answer, I’m very busy ….
 but thanks !!
 for now I think the most important is to document bloc and to stress it
 - by trying the examples or
 - by trying to program new examples or
 - by adding comments, fix the english or by asking questions.
 Cheers
 Alain

Re: [Pharo-dev] Contributing to Bloc

2015-04-06 Thread kilon alios

another weird problem i just found is that right side down arrow menu when
clicked it opens in random location instead of bellow its icon. I tried it
with System Browser.

By the way i am talking about already available Pharo tools and not bloc
examples.

On Mon, Apr 6, 2015 at 2:03 PM, Nicolai Hess nicolaih...@web.de wrote:

 2015-04-06 10:22 GMT+02:00 kilon alios kilon.al...@gmail.com:

 Hey guys, these last days I have taken a look at Bloc and really like its
 design. So I was wondering how I can be of assistance. I am not an
 experienced pharo jedi like you guys but I think I could do my small part
 to help make Bloc into a replacement for Morphic.

 From what I see Bloc some issues rendering Morphs , for example tabs
 (window groups) and some glitches here and there.



 I don't know a tabs example that is build with bloc.
 The current bloc world renders a classic Morph on an AthensCanvas if they
 define a
 #drawOnAthensCanvas: method.
 If this is missing or not correctly working, we should change the
 implementation in the Athens project (Athens-Morphic).





 So how am I proceed ? How I can help ?

Re: [Pharo-dev] New Pull Request for UpdatedPharoByExample

2015-04-05 Thread kilon alios

no, as I suspected I have forgot to change from my old email to my new one.
Should work now.

On Mon, Apr 6, 2015 at 2:17 AM, Dmitri Zagidulin dmi...@zagidulin.net
wrote:

 You might have to click on the Watch button on the repo.


 On Sunday, April 5, 2015, kilon alios kilon.al...@gmail.com wrote:

 Strangely enough it does not notify me, probably need to change something
 in my github settings.

 On Sun, Apr 5, 2015 at 6:39 PM, Dmitri Zagidulin dmi...@zagidulin.net
 wrote:

 Thanks, Gaurav! It is now merged.

 I don't think one needs to send an email to the mailing list, though,
 for PRs. Github usually notifies anybody who's watching the repository,
 when new PRs are made.

 On Sun, Apr 5, 2015 at 9:28 AM, Gaurav Singh grvanm.co...@gmail.com
 wrote:

 I have made a few corrections in the chapter Syntax in a Nutshell.
 Link to the pull request:
 https://github.com/SquareBracketAssociates/UpdatedPharoByExample/pull/30
 Kindly review the pull request.

Re: [Pharo-dev] Spotter

2015-04-05 Thread kilon alios

The problem of people like a tool too much you get a ton of feature
requests :D

I don't envy those poor developers.

Re: [Pharo-dev] New Pull Request for UpdatedPharoByExample

2015-04-05 Thread kilon alios

Strangely enough it does not notify me, probably need to change something
in my github settings.

On Sun, Apr 5, 2015 at 6:39 PM, Dmitri Zagidulin dmi...@zagidulin.net
wrote:

 Thanks, Gaurav! It is now merged.

 I don't think one needs to send an email to the mailing list, though, for
 PRs. Github usually notifies anybody who's watching the repository, when
 new PRs are made.

 On Sun, Apr 5, 2015 at 9:28 AM, Gaurav Singh grvanm.co...@gmail.com
 wrote:

 I have made a few corrections in the chapter Syntax in a Nutshell.
 Link to the pull request:
 https://github.com/SquareBracketAssociates/UpdatedPharoByExample/pull/30
 Kindly review the pull request.

Re: [Pharo-dev] UpdatedPharoByExample for 3.0, 4.0, 5.0

2015-04-04 Thread kilon alios

I agree it makes sense, we can use git tags , or branches. Having separate
docs for every version is how it works for all other languages I have used.
Its zero extra work.

I dont know about the generation of pdfs though, I am not familair with CI
/ Jenkins and how easy it is to assign specific builds to git tags /
branches.

On Sat, Apr 4, 2015 at 4:04 PM, Sean P. DeNigris s...@clipperadams.com
wrote:

 Would it make sense to freeze the documentation for each image version?
 Maybe
 a branch per image? This way, people who choose/need to work with previous
 image versions have an accurate reference. From my limited Git experience
 it
 shouldn't be much extra work.



 -
 Cheers,
 Sean
 --
 View this message in context:
 http://forum.world.st/UpdatedPharoByExample-for-3-0-4-0-5-0-tp4817514.html
 Sent from the Pharo Smalltalk Developers mailing list archive at
 Nabble.com.

Re: [Pharo-dev] Can we have basicRaw in GTInspector?

I did not know that, thanks

On Fri, Apr 3, 2015 at 12:39 PM, Esteban Lorenzano esteba...@gmail.com
wrote:


 On 02 Apr 2015, at 18:16, p...@highoctane.be wrote:

 Welcome to the club of GT is awesome and sometimes freezes it all.

 Happened to me once or twice this morning as well.
 Switched back to basic inspector for a couple things.

 Having both options available would be nice (like inspect = basic /explore
 = gt).


 you *have* both options
 (i) inspect = GT
 (I) basic inspect = basic inspect :)

 Esteban


 Phil

 On Thu, Apr 2, 2015 at 5:30 PM, stepharo steph...@free.fr wrote:

 This morning GTInspector was so slow that it blocked the complete system
 on the machine of Cyril. :(
 We can tell him that he is stupid to have a bad machine or we could try
 to use this to see how
 we can help our users.

 So we had to use basicInspect to get our job done (once we ctrl-. to
 escape the render hell)
 because raw uses a tree morph.

 Why raw cannot reproduce the old simple and working basicInspect
 then we could have a basic inspect on double click to avoid to use this
 bad tree and that we can work.

 just try to on RubSmalltalkCodeMode class#menuOn: to get the feel. Even
 on my superfast machine is
 is sluggish.

 I really think that we should support backdoors.
 We need to have a mini browser, a mini debugger and a working inspector.

 Setf

Re: [Pharo-dev] Pharo 4 Beta, first impressions

Not me I used to be a windows only user for over a decade and I was always
have been wondering why the close /max/min are on the right side when menus
start from the left. So when I finally decided to convert to Macos it was a
welcomed change and still is.

Now you can ask me after 8 years being a MacOS users how I feel about the
way mac windows maximise and you wont hear nice things even now that they
offer full screen options.

I am not a creature of habit apparently, If I don't like something the
first minutes chances are that I wont like it 2 decades either. Sometimes I
change my mind, but it is rare. Really, really rare.

On Fri, Apr 3, 2015 at 3:41 PM, Benoit St-Jean via Pharo-dev 
pharo-dev@lists.pharo.org wrote:



 -- Forwarded message --
 From: Benoit St-Jean bstj...@yahoo.com
 To: Marcus Denker marcus.den...@inria.fr, Pharo Development List 
 pharo-dev@lists.pharo.org
 Cc:
 Date: Fri, 3 Apr 2015 12:37:41 + (UTC)
 Subject: Re: [Pharo-dev] Pharo 4 Beta, first impressions
 It's not so much about the Windows look (whether it's Win98, Win 2K, Win
 XP, Win Me, Win 8, Win Whatever).  Every Windows user *expects* to have the
 Close, Maximize  Minimize buttons at the upper right of the Window.

 It might look like a silly detail but try swapping the buttons of a Mac
 user to the right and wait a few seconds before he complains!  ;)

 -
 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)

   --
  *From:* Marcus Denker marcus.den...@inria.fr
 *To:* Benoit St-Jean bstj...@yahoo.com; Pharo Development List 
 pharo-dev@lists.pharo.org
 *Sent:* Friday, April 3, 2015 8:28 AM
 *Subject:* Re: [Pharo-dev] Pharo 4 Beta, first impressions


 On 03 Apr 2015, at 14:11, Benoit St-Jean via Pharo-dev 
 pharo-dev@lists.pharo.org wrote:


 *Date: *3 Apr 2015 14:08:03 CEST
 *From: *Benoit St-Jean bstj...@yahoo.com
 *Reply-To: *Benoit St-Jean bstj...@yahoo.com
 *To: *Pharo Development List pharo-dev@lists.pharo.org
 *Subject: **Pharo 4 Beta, first impressions*


 3 quick things :

 1) How can I get the Windows theme (W2K) that was available in Pharo 3
 (it's no longer there in Pharo 4.0 Beta).  Having the close, maximize 
 minimize buttons to the left of every window is VERY annoying for Windows
 users!

 Windows 2k is 16 years old. We can not maintain a museum of old windows
 looks… it just makes no sense (at all. At all… I don’t even think how
 someone can think that we should!).
 Keep in mind that nobody uses it (but you, I guess), so it will for sure
 be broken in subtle ways…

 We need to use it where it makes sense. A windows 2000 look is not one of
 these things.



 2) Am I the only one annoyed by the fact that the Collection class still
 holds on to 2 class variables (one of them being an instance of Random, the
 other a mutex) for the sole purpose of accommodating the #atRandom 
 #atRandom: methods ?  Even worse, the Integer class' implementation of
 #atRandom references the Collection class to use that random instance!  In
 other words, Integer#atRandom -- Collection#randomForPicking --
 Random !  I've always been a fan of the mind your own business approach.
 Wouldn't it make a lot more sense to have the Random class provide a
 default instance (a singleton) whenever other classes need such an object
 instead of crippling the code with class variables and singleton instance
 all over the place?


 The system is very large. I think it is fundamentally wrong to assume that
 something like this (Design level things) will be magically fixed if there
 was no discussion, no issue tracker entry, no nothing.

 Why do you think that this will “fix itself magically”? I would really
 like to know your thought process behind this… is there something that
 makes you think that a release process could catch
 this? How?

 Marcus

Re: [Pharo-dev] Pharo 4 Beta, first impressions

 It's not as if someone would ask for an OS/2 or a Motif UI theme!  There
are *LOTS* of people on Windows still !
That is irrelevant really . Thats not how open source works. In open source
something maintained or goes in or stays in because someone bothers to code
for it.

You may get 1 billion users to complain about this and still it wont change
a thing. You still need a developer to do the work. Most open source devs
like to work on things that they really care about.

And is not as if things are better for MacOS user, the watery theme looks
very dated , ugly and it is not even compatible with the new dark theme. So
in the end it makes sense to use one of the recent themes, either white or
dark.

Also you are the first to complain about this.If you want to get this fixed
the easiest way is to fix it yourself as third party library and add it to
the configuration browser for others to use.  If you expect for someone
else to fix it, you may have to wait for decades and no it wont matter if
you get a billion users to agree with you and sign a petition.

How many people you think asked for a blue theme in this mailing list ?
none . Pharo now has a blue theme because of me, and has no windows theme
with so many windows users. How many people use the blue them ? most likely
only me. Thats how open source works I am afraid, dont blame Pharo, blame
life and the reality we live in :)

Re: [Pharo-dev] Pharo 4 Beta, first impressions

The point is, every piece of code needs to be written and maintained which
takes time and energy from other activities.

I completely agree with you. I have zero issues of main pharo developers
kicking out libraries that are not so much used by pharo users. Those
libraries are perfectly capable of existing as third party.

I also love the plan to make pharo modular, remove libraries from inside
and make it easy to install. This way each one of us can easily make an
image tailor made for his/her needs. Each pharo user is an individual with
individual needs.

Installing libraries is dead easy with the Configuration Browser ,
including their dependencies , just one click away.

Of course that leaves whos going to maintain that stuff.  I agree with
Marcus here, you want it in pharo , code it.The theme support in Pharo is
very powerful , I know because I created my own custom blue theme and a
tool to allow easy customization of theme colors with zero coding (Nireas).
I expected that by now Nireas would be replaced by another way more
powerful theme manager but it has not. Why ? Not because my theme manager
is very good, but because the community is just too small. I love using my
blue theme and fits perfect to my taste and needs ;)

In the end no code can be more personal than the code you create.

There is no need for everything to exist inside the image , great things
can exist outside too. All it needs people who really care about pharo by
coding for it.

Re: [Pharo-dev] [ANN] New service: The Pharo catalog

does the project info depend on the sthub page of the project ?

also you put too close

Copyright (C) 2015, by Esteban Lorenzano for the Pharo project.

people may think that you are the author of all projects. I know you are
super Pharo coder, but even a super man coder like you cant create so much
code :D


On Wed, Apr 1, 2015 at 1:13 PM, Esteban Lorenzano esteba...@gmail.com
wrote:

 Hi,

 Last week I made a super small project to consolidate all projects
 published in all metarepos.
 Is very simple, in the style of smalltalkhub repository list, but it shows
 all projects with the info their owners provided.
 Yes, it could be a lot better, but we do not want to lose much time with
 this because not far in the future (but not right now) we will put online a
 much better service :)

 You can see the catalog here:

 http://catalog.pharo.org

 and a JSON variant here:

 http://catalog.pharo.org/catalog/json

 enjoy,
 Esteban

Re: [Pharo-dev] Brand new modern Spotter design!

tried on a new Pharo 4 image, i get tons of the same error Error: instances
of Unidentified Object are not indexable . It keeps erroring forever and it
does not even allow me to open the debugger :(

Re: [Pharo-dev] Brand new modern Spotter design!

ok it works with fresh latest image. The new color does not respect the
dark theme.  I really like the tooltips, is it possible to adjust tooltip
depending on the OS so it displays the appropriate shortcut ?

On Wed, Apr 1, 2015 at 1:14 PM, kilon alios kilon.al...@gmail.com wrote:

 tried on a new Pharo 4 image, i get tons of the same error Error:
 instances of Unidentified Object are not indexable . It keeps erroring
 forever and it does not even allow me to open the debugger :(

Re: [Pharo-dev] Brand new modern Spotter design!

My opinion :

Even when a tool has its own theme support should still support and respect
the central theme.

Re: [Pharo-dev] Brand new modern Spotter design!

can you explain a bit more what you mean ? are you referring to the pharo
central theme or GTSpotter theme ?

It will be a huge pain for users  to set a separate theme for each tool
inside pharo.

On Wed, Apr 1, 2015 at 2:19 PM, Tudor Girba tu...@tudorgirba.com wrote:

 But we think that complementary universal colors work best in this context.

 Doru

 --
 www.tudorgirba.com

 Every thing has its own flow

  On 01 Apr 2015, at 13:07, kilon alios kilon.al...@gmail.com wrote:
 
 
  My opinion :
 
  Even when a tool has its own theme support should still support and
 respect the central theme.

Re: [Pharo-dev] Improving communication and roadmap

2015-03-28 Thread kilon alios

the advantage of a roadmap is that allows people that can agree on
principle on a specific kind of approach can work together as a team
towards a common goal under the same project.

People who cant find someone else to agree with them, or dont like the
existing solutions can always follow their own path and create their own
code. On other hand those kind of people can also benefit from a roadmap
because a roadmap is always an attractive force for contributors.

When I (used here generally not just to refer to me) know what your
intention is with this code in the future , I will be far more willing to
help you out if our goals are common. If not then roadmap can still be
useful if I dont want our two projects , mine and yours to overlap.

So a roadmap is a win win situation.

And I dont even need to go into the advantages of planning ahead.

On Sat, Mar 28, 2015 at 5:05 PM, Tudor Girba tu...@tudorgirba.com wrote:

 I think the fear that someone else might do something similar should not
 stop action.

 Having multiple solutions to choose from is a good thing :)

 Cheers,
 Doru

 On Sat, Mar 28, 2015 at 2:32 PM, Sean P. DeNigris s...@clipperadams.com
 wrote:

 stepharo wrote
  So I would like to propose that we share a kind of board of announce on
  what people are doing.

 Thank you! This is great. I've also been hesitant to work on certain
 things
 (e.g. cleaning up Morphic events) because I didn't want to unintentionally
 overlap with someone else's work.



 -
 Cheers,
 Sean
 --
 View this message in context:
 http://forum.world.st/Improving-communication-and-roadmap-tp4815705p4815753.html
 Sent from the Pharo Smalltalk Developers mailing list archive at
 Nabble.com.




 --
 www.tudorgirba.com

 Every thing has its own flow

Re: [Pharo-dev] [ANN] Quality Assistant: live code critics feedback

2015-03-27 Thread kilon alios

u know I was about to recommend that for code critic. What a coincidence.
Installed and using it on my project.

On Fri, Mar 27, 2015 at 10:13 AM, Yuriy Tymchuk yuriy.tymc...@me.com
wrote:

 Dear Pharo developers,

 As you already know I am working on providing better code quality support
 in Pharo. You can use Code Critics in Pharo to detect bad practices and
 potential bugs. But launching the Critics Browser and running it on your
 code every now and then requires additional effort which demotivates many
 people in doing it.

 I want to present you a compact tool called Quality Assistant
 https://github.com/Uko/QualityAssistant#quality-assistant-푏푒푡푎-

 It runs SmallLint rules on the code that you save and provides you with a
 critic feedback directly in the place where you code: the Nautilus Browser.

 Quality Assistant is available for Pharo 4 from the Configuration browser.
 Please read about how to set it up here:
 https://github.com/Uko/QualityAssistant#set-up

 I plan to introduce more features in the future and your feedback is much
 appreciated.

 Cheers!
 Uko

Re: [Pharo-dev] [IMPORTANT] Release will be delayed one week. PLEASE TEST!

2015-03-27 Thread kilon alios

I am testing every single day since when Pharo 4 became available :)

Its your fault that Pharo has been rock stable. Apart from some crashes
when I tried to install SmaCC in few images but no crashes since then.

On the other hand, I always complain one way or another so 

On Fri, Mar 27, 2015 at 4:02 PM, Esteban Lorenzano esteba...@gmail.com
wrote:

 Hi,

 We still find some problems and we do not feel the release will be ready
 for April 1st.
 So we decided to delay the release one week.

 Please, please, please… now is the moment to test!
 Do not complain later!

 cheers,
 Esteban

Re: [Pharo-dev] SmalltalkHub Watch this project is not working for me

2015-03-27 Thread kilon alios

This feature does not work, it never did. It was meant to be implemented at
some point but unfortunately the original developer stopped working on
StHub and its currently maintained by one dev Esteban and he is very busy.
Though I cant complain Esteban recently implemented my No1 feature request
a list of all available StHub projects.

On Fri, Mar 27, 2015 at 5:03 PM, garduino gardu...@gmail.com wrote:

 Yes, I know the expected behaviour and I think that is useful to have such
 sort of quick links to projects that I'm interested on.

 Me comment pointed to the fact that pressing the button don't added the
 project that I wanted to watch to my list, but now seems to work again.



 --
 View this message in context:
 http://forum.world.st/SmalltalkHub-Watch-this-project-is-not-working-for-me-tp4815519p4815586.html
 Sent from the Pharo Smalltalk Developers mailing list archive at
 Nabble.com.

Re: [Pharo-dev] Existing script example pragmas and new GT needs

2015-03-26 Thread kilon alios

+1
couldn't agree more :)

On Thu, Mar 26, 2015 at 1:06 PM, Esteban Lorenzano esteba...@gmail.com
wrote:

 Ok… my 2c:

 Basically there is a difference between an “example” and a prototype,
 which is what the gtExample intends to do. Exemplar is just another way to
 name a prototype.
 Sorry to make you sad and tired… but when you introduce such an important
 new tool as all the gtools are, you cannot expect people to accept all your
 choices “as is”… and debate is the only way to achieve some consensus.

 Esteban

 ps: we are just days from release and we are all stressed a lot… so lets
 take a breath and consider things with the appropriate distance. We are not
 talking about the cure for cancer here, just the right name for a pragma,
 in a method.

  On 26 Mar 2015, at 10:02, Torsten Bergmann asta...@gmx.de wrote:
 
  Hi Tudor,
 
  We will rename example back to gtExample and keep the API as it is.
 That will leave Pharo 4 with one example method while the other 100 will
 use gtExample. This will be available with the next GT integration.
 
  As I already wrote (and Guillermo equally pointed out): most of them are
 there because you created/introduced many extension
  methods with GT to provide these sample instances like in $a for
 Charater or 42 for Integer, ...
  Which is completely valid to demonstrate how usefull your new extension
 is. But it is because you investigated so far more to
  demonstrate this new mechanism.
 
 
  And yes, currently we have just one example in the image (beside some
 other in external projects). But if we do not
  want to rely on the exampleXXX pattern anymore we will mark the typical
 example methods with example in the future and would
  have around 140 in the latest image:
 
  |coll|
  coll := IdentitySet new.
  Object withAllSubclassesDo: [:aClass |
   aClass class selectorsDo: [:selector |
(selector  beginsWith: 'example') ifTrue: [ coll add: selector
 ]
  ]].
  ^coll
 
  If we dont mark them I agree that there are only a few counterwise.
 
  But again: from my side it is not about the current numbers. It is about
 the future mechanism, clear and
  understandable concepts and naming.
 
  The usualy exampleXXX demos for code fits well with example from the
 name and mentally. Example
  is a very generous term for something to look at and learn.
 
  In Pharo one can now demonstrate in the new GT inspector lively ready
 made instances!
  You feature and the research bound to it is not only important but a
 real improvement.
  I like that and I'm sure this will push us forward a lot.
 
  Still IMHO mentally using example for depicting code to look at does
 fit namewise and
  conceptualy very well with the known and usual example methods in the
 image or external
  packages. Some of them provide an instance, but many of them just show
 how to use code.
 
  And yes: I would the new GT mechanism to use a term and pragma name that
 better depicts
  what should be provided from the one who uses it: typical example
 instances or exemplars
  of the class.
 
  When one creates a class
 
 Object subclass: #RevolutionarySystem
instanceVariableNames: 'name'
classVariableNames: ''
category: 'The-World'
 
  he can implement a class side method to use the new mechanism:
 
 uniqueExemplar
exemplar
 
^RevolutionarySystem called: 'Pharo'
 
  And this class side method returns an exemplary instance. If such a
 method should
  also serves as an example method (in the tradition of a code example to
 look at)
  one can even mark it with both pragmas.
 
  The decision has nothing to do with arguments.
 
  Why do you negotiate instead of (at a minimum) ellaborate what you think
 of the made
  proposal to use exemplar for the new GT mechanism.
 
  See the definition for exemplar:
 
  http://dictionary.reference.com/browse/exemplar
a model or pattern to be copied or imitated
a typical example or instance
 
  http://www.thefreedictionary.com/exemplar
One that is worthy of imitation; a perfect example or model
One that is typical or representative
 
  http://www.merriam-webster.com/dictionary/exemplar
an admired person or thing that is considered an example that
 deserves to be copied
a typical example
 
  http://www.ldoceonline.com/dictionary/exemplar
formal a good or typical example
 
  http://www.dict.cc/?s=exemplar
instance
specimen
sample
 
  All the 100 instances now returns by GT extension are such exemplars:
 they are
  typical instances like $a or 42 one can use as a model or pattern to be
 copied
  or imitated.
 
  Would'nt that perfectly fit with what you intended with your new
 feature: the preview
  should help people to just inspect a class, look at the new e.g. tab
 and learn from
  premade instances?
 
  The release is too important and we got distracted from the goal.
 
  No doubt that the release is important and fixing it NOW from the
 technical side is easy
  as I

Re: [Pharo-dev] New Pharo-Launcher package for Mac and Windows

2015-03-26 Thread kilon alios

I was talking with a new Pharo user and she was telling me that
PharoLauncher was not working on Windows , glad you manage to fix it. Great
work Damien , thanks :)

I am using it on macos , works great .

On Thu, Mar 26, 2015 at 5:46 PM, Damien Cassou damien.cas...@gmail.com
wrote:


 Hi,

 I've just updated the 2 installers for mac and windows.

 http://files.pharo.org/platform/launcher/Pharo_0.2.4.dmg
 http://files.pharo.org/platform/launcher/pharo_installer-0.2.4.exe

 - the windows installer should have the PharoV30.sources file that was
   missing

 - both installers now install the most recent Pharo launcher

 --
 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] could the size of Playground be reduced a bit

2015-03-26 Thread kilon alios

very useful thanks Tudor :)

On Thu, Mar 26, 2015 at 1:47 AM, Tudor Girba tu...@tudorgirba.com wrote:

 Hi,

 In the latest GT-Playground and GT-Inspector you get the following
 behavior:
 - you can resize the windows, and the windows spawned afterwards will
 remember the dimensions, or
 - you can explicitly specify the size you prefer in the settings browser.


 https://pharo.fogbugz.com/f/cases/14541/Editing-the-default-inspector-window-size

 Cheers,
 Doru


 On Wed, Mar 25, 2015 at 11:43 PM, Peter Uhnák i.uh...@gmail.com wrote:

 oh resizing is already mandatory I am afraid. When the object inspected
 is big, there is no other option but to resize the whole window. And many
 if not most useful Pharo objects worth inspecting are big.

 I rarely have to resize it (arguably I'm not using to full potential);
 but my point was that there should be sensible defaults for both primary
 (most common) use cases. You can never satisfy everyone 100%.

 Plus resizing windows is part of the experience of using a window GUI
 system.

 As a long time user of dwm the very idea of resizing windows with mouse
 is repulsive to me. (I still struggle in this respect with Pharo... but I
 have a dream. :))

 Peter




 --
 www.tudorgirba.com

 Every thing has its own flow

Re: [Pharo-dev] Existing script example pragmas and new GT needs

Well personally I would name it as it is , in this case exampleOfInstance ,
exampleOfInstance: and exampleOfInstanceFrom:

examplar means nothing for me. example is also bad choice for something
that is not example of code and rather example of an instance.

Re: [Pharo-dev] could the size of Playground be reduced a bit

oh resizing is already mandatory I am afraid. When the object inspected is
big, there is no other option but to resize the whole window. And many if
not most useful Pharo objects worth inspecting are big.

Plus resizing windows is part of the experience of using a window GUI
system.

On Wed, Mar 25, 2015 at 9:05 PM, Peter Uhnák i.uh...@gmail.com wrote:

 ±1

 The problem is that it is not only playground, but also an inspector.

 While I would like the window smaller in both dimensions (no script is
 that wide), it would sort of break do it and go.
 One idea might be to increase it to the current size only when do it and
 go is executed (and the inspector is not opened yet).

 Because otherwise users of it would have to resize it manually very often
 - if it is the size of the original Workspace, the inspector is utterly
 useless.

 Peter

Re: [Pharo-dev] Fuel issue tracker now on github

Welcome to the dark side of the fork.

On Tue, Mar 24, 2015 at 9:03 PM, Max Leske maxle...@gmail.com wrote:

 Hi folks

 We’ve moved the issue tracker from Google code to github:
 https://github.com/theseion/fuel/issues.

 Cheers,
 Max

Re: [Pharo-dev] Existing script example pragmas and new GT needs

Just for your information Bloc already has 150 methods using the example
pragma. Most likely there are other libraries out there using it as well. I
also suspect since this is new and not documented example will be heavily
used in the future because having example code is too useful to pass. I am
off to port my methods to it :)

On Thu, Mar 26, 2015 at 12:28 AM, Tudor Girba tu...@tudorgirba.com wrote:

 Hi Torsten,

 We will rename example back to gtExample and keep the API as it is.
 That will leave Pharo 4 with one example method while the other 100 will
 use gtExample. This will be available with the next GT integration.

 The decision has nothing to do with arguments. This discussion managed to
 sadden me and I will not continue it anymore. The release is too important
 and we got distracted from the goal.

 I wish you all a peaceful night.

 Doru


 On Wed, Mar 25, 2015 at 10:54 PM, Torsten Bergmann asta...@gmx.de wrote:

 stepharo wrote:
 I'm confused. Did you use the example pragmas before?

 Yes, this was already integrated in Pharo 4 since several weeks. It
 allows marking an class
 side method without relying on the exampleXXX pattern. Maybe I should
 have made more noise about
 it.

 So you can have a class side example method to demonstrate or give
 something to
 others to learn:

tryThisOut
 example
  ...

 without having to rely on the exampleXXX pattern.

 Nautilus honors this the same way as for exampleXXX methods with a play
 icon that one
 can click and that executes the example. No need to have or select self
 tryThisOut
 in a comment. And you can choose selector names you like and that are
 good for your
 users like simpleExampleToTryOut or confusingExampleToDisplay.

 It would also allow us collect all example methods easily and display
 them in an example
 browser for newbees they can use to go through all example methods and
 learn from
 the code.


 Tudor in parallel worked on gtExample and unfortunately changed this to
 example
 afterwards as well (maybe upon your request). He has a new feature that
 when you open
 an inspector on a class you can see example instances of that class in
 a new tab.

 For this to work he needed also a pragma - by choosing the same name we
 got this
 conflict in the pragmas.

 But it is not about who was first - it is about correct naming. This new
 feature in GT
 requires a method to return example instances - thats why I suggested
 to use a better
 name like exampleInstance or just exemplar.

 With this we would be clear in naming, would not conflict and be sove
 both issues
 (the new preview and not relying on exampleXXX for example methods).

 I would neither like to loose the fix that I already provided and that
 was integrated
 nor the nice work of Tudor.

  I'm ok with exemplar too.

 Attached is a changeset GTExemplars.1.cs that:

   - changes the GT use of example, example: and exampleFrom: to
 exemplar and exemplar: and exemplarFrom:
   - it also uses correct method naming for the returned exemplars/sample
 instances of the class, for instance #gtExampleSimple - simpleExemplar
   - it also changes GTExample - GTExemplar, GTExampleExtractionStrategy
 - GTExamplarExtractionStrategy, ...
 and also uses ...exemplar... instead of ...example... for the methods
 and temporaries in these classes.

 With this changeset the new feature does not conflict. The changeset is
 based on Pharo4.0 Latest update: #40582 as of today
 and when quickly integrated this should be easy to fileIn/integrate into
 the externally managed GT tools as well
 as the image.


 With this integrated into GT/Pharo 4 we would not conflict and make
 things clear:

   1. we use the term example for regular Smalltalk code examples as
 most of us knows from the past
  either in an exampleXXX method or with the example pragma.

   2. And we can use the concept and term exemplar to return
 instances/exemplars of a class and browse them
  with the new preview feature Tudor introduced.
  Give me an exemplar of class Character, give me an exemplar of
 class String, ...

 = I'll leave the decison to the community or finally the board to
 integrate this as I communicated my
points and reasons now often enough including an attached ready to be
 integrated solution.

I did my homework now and leave this to others to decide and either
 deny it or open a bug to
integrate.

  PS: From far it looks like a bikeshed discussion :)

 May be. But I'm very serious about this as you see because getting names
 and concepts right is often
 the hardest part. And it would be hard to change after the release
 because people will use it already.

 Bye
 T.








 --
 www.tudorgirba.com

 Every thing has its own flow

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

There is a big diffirence between Morphic and the other. Morphic is a full
solution and mature one as well. The others , with the exception of Bloc ,
try to wrap things up or offering better solution to some areas.

The one thing I don't understand is why improving Morphic or even
redesigning it is not even on the table. Looks to me like the least painful
scenario. Unless thats the intention of Bloc to be the next generation of
Morphic. In that case I am all for Bloc.

I am in a dilemma myself, I am currently deep into interfacing pharo with
python for my project Ephestos but I will need to consider a GUI API soon.
Spec is out of the question since I dont like the desing and does not
support custom made GUIs which is what I want. Brick is as far as I
understand an extension to morphic and not usable. Which leaves me with 2
candidates Morphic and Bloc.

The one thing I really like about Bloc is that it is vectorial which is the
kind of custom GUI I want to create but it will also have to be fast and
since its related to Athens, Athens has proven very slow for my needs. So I
am considering sticking to Morphic and make the GUI pseudo vectorial using
bitmaps. In any case the situation is far from ideal . But I really like to
push something forward (preferably Bloc or a new Morphci) and I would hate
it if I go creating my own solution but that is a very likely scenario too.

On Tue, Mar 24, 2015 at 2:56 PM, Esteban Lorenzano esteba...@gmail.com
wrote:

 And well… I think Nicolai is right in a point (not the fault of Brick,
 btw): current status is far from ideal:

 - we have Morphic, and it’s upcoming replace, Brick (but Brick is not in
 the image, so the pain there is less)
 - we have Spec to support our tooling.
 - we have Glamour to support… well, our tooling too.
 - we have now Brick, who (AFAIS) is an extension of Morphic, and a
 replacement the Morphic Widgets and also Glamour.
 GTTools team has explicitly declared Brick will replace Glamour (but API
 will remain largely compatible, they say).
 GTTools team has also stated they would use Bloc is they could/when they
 can.
 - We have the old Text Editor
 - We have Rubric, which was stated to be “old stuff” and deprecated
 - We have also the new TxModel which intends to replace both, Text Editor
 and Rubric… but it cannot be used right now (or better: It cannot replace
 none of the previous yet)

 So… which one to use?
 We, the board, have something clear and some other not so clear yet, for
 example:

 - we would like to replace Morphic with Bloc, but this is a lot of work
 and will take a lot of time so in the mean time we also clean old Morphic
 as much as we can (and we encourage people to do it)
 - Spec needs work too
 - Glamour will be replaced by Brick, so do not use it
 - TxModel will replace all the previous, but it needs a lor of work. In
 the mean time, we suggest to use and improve Rubric, and of course, we
 would like to have more people contributing to TxModel.

 So well… yes this is a mess. Yes we are aware. No we don’t know when
 things will improve, but *they will*.
 In the mean time as a Pharo user, I would like to know which one should I
 use for my projects… this is my recommendation:

 - Do not use “direct” Morphic unless doing graphics
 - Use TxModel and if you cannot, Rubric
 - Use Brick or Spec, not Glamour (because Brick will replace it soon)

 And of course, I would help with fixes and reports on everything :)


 cheers,
 Esteban




 On 24 Mar 2015, at 12:37, Tudor Girba tu...@tudorgirba.com wrote:

 Hi Nicolai,

 I am surprised by your conclusion that the current Brick implementation
 disqualifies it from being part of the Core :)

 Let's recap.

 Brick was created to support GT. We wanted GT in the image, hence Brick is
 in the image as part of Glamour. In the meantime, Brick has grown and it's
 now an almost standalone framework, but it is not yet advisable to use it
 apps because it will likely change more.

 As Alex says, we do not want to have two competing new projects running in
 parallel (Brick and Bloc) and fragmenting the effort even more. That is
 why, for Pharo 5 we want to invest in Bloc. The interesting thing is that
 while Bloc starts from scratch, Brick already works and has quite some high
 level widgets and logic built in. Brick is already going in the same
 direction expected by Bloc, so we will likely have the opportunity of
 moving Brick on top of Bloc (Alex already did an experiment in this
 direction).

 Concretely, on March 31 and April 1 (no joke :)), we have a session in
 Bern where Alain Plantec will join us to look into how to approach this
 problem concretely.

 All in all, you should see Brick as a pragmatic intermediary step towards
 removing Morph. I agree that it can be better (what cannot be), but I
 disagree we should discard GT because of it.

 Cheers,
 Doru


 On Tue, Mar 24, 2015 at 12:06 PM, Nicolai Hess nicolaih...@web.de wrote:



 2015-03-23 20:54 GMT+01:00 Aliaksei Syrel

Re: [Pharo-dev] Update question

I tried it a few times, and had nothing but problems with it. We have
discussed here several times and from what I have learned there several
technical limitation.

I am using pharolauncher non stop and wonder why Pharolauncher is not
integrated inside Pharo yet. I have added my code inside the configuration
browser (Ephestos, Nireas) and Installing my code back in a fresh image is
just a two click process.

On Tue, Mar 24, 2015 at 12:13 PM, Norbert Hartl norb...@hartl.name wrote:

 Today I wanted (again) to update my image and it can't find GT packages.
 So I'm interested how the community deals with that. Do you take fresh
 downloaded images regularly? Or you do not update? Is it just me?

 thanks,

 Norbert

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

Tudor , I am only amazed how much you guys accomplish with so limited
resources. I may not agree with some of the choices but I am very happy
with the progress Pharo is making and glad I stick around.

If the community is not ready for a roadmap , so be it. You will be ready
when you will be ready.I do think however that more the community grows
coordinating effort will become a key issue.

I do agree that things look very encouraging and I trust the community to
move Pharo forward.

Just a side note: what I find cool about Pharo GUI coding is that all tools
are written in Pharo. Its easy to take this for granted but taking a look
at other dynamic programming languages shows that his is a blessing. I have
to confess I did not understand this obsession of implementing everything
in Pharo when I joined coming from python. But now I find this obsession
too infectious to resist :)

On Tue, Mar 24, 2015 at 11:56 PM, Tudor Girba tu...@tudorgirba.com wrote:

 Hi Kilon,

 The situation is like this. For quite a while we did not have enough
 expertise in this community to build serious UI frameworks that can work.
 In the meantime we learnt a lot. GT is not just a couple of windows. It's
 an experiment of building something that does not exist anywhere else, and
 we learnt a lot from doing it. For example, to make Spotter both responsive
 and robust, the most difficult part was to learn to build the machinery
 behind, but now we are passed that initial step. At the same time, Alain
 put a ton of effort in Bloc. Athens was exercised both as the engine behind
 Block and from the Roassal team. And there are others like Sean, Nicolai
 and Ben who work around the same areas.

 This are all seemingly parallel and uncoordinated efforts, but they are
 converging. It is exactly because we are committed to the long term goal of
 building a real and better alternative to Morphic that we choose to not
 stop half way with Brick which is probably enough for GT purposes and
 choose instead to invest in evaluating Bloc.

 Yes, we do not have the replacement now, but we have never had so much
 investment and will around the UI as we have now. We do not know at this
 point what is the better way, we do not know the exact roadmap because it
 is more than just a matter of implementation. But, I know that the kinds of
 results we had recently around the UI is a highly encouraging predictor.

 Cheers,
 Doru



 On Tue, Mar 24, 2015 at 5:19 PM, kilon alios kilon.al...@gmail.com
 wrote:


 
 if you read my mail, you will notice that I said BOTH are on the table
 (and we are actually moving oon both):
 - Bloc is the redesign
 - In the mean time we WORK and ENCOURAGE others to work on improve it.

 Last time I asked about Bloc , I was told not to use it and instead stick
 with Spec or Morphic.

 I said it before and will say it again, you guys need to sit down and
 make a roadmap for Pharo because I am reading a lot of conflicting posts in
 this mailing list and this is does not give the professional look Pharo
 wants to show to people outside Pharo. As a user replace in the long run
 is not enough ! The original author of Bloc , Alain, also said that he is
 pretty much the only one that works on Bloc (with some help from Stef) and
 if people dont start helping him out he is going to give up.

 How many more threads should we have about the GUI future of Pharo before
 people really get the message that we need a roadmap ?

 Additionally , Pharo needs a roadmap , seriously it does.

 but Morphic it self has several fundamental flaws that cannot be fixed
 and that’s why in the long, very long way, needs to be replaced.  

 What flaws , where , when , how , why ? So much discussion that Morphic
 must go , close to zero discussion what the actual problems are.

 First, Athens is not a replace for Morphic, is a replace for the canvas
 in which morphs are drawn. So is not Morphic or Athens… is Morph using
 DisplayPlugin or Morphic using Athens.

 Second I did not say Athens is to replace Morphic . From my understanding
 Bloc is based on Athens and Bloc is to replace Morphic. Correct me If I am
 wrong.

 Glamour is very mature and I’ve used it serval times… and in theory
 Brick will be compatible with Glamour (mostly) so even if developers
 deprecate one for the other you will be able to use your code (mostly). 

 Brick is called non usable by its own authors. Glamour is framework of
 building browsers and simplified GUIs , its nowhere near as powerful as
 Morphic and is based on Morphic. From the looks of its is not even as
 powerful as Spec. Through the couple years I have been around I have seen
 at best a couple of question on how to make it work compared to hundreds of
 questions about Spec and Morphic . How something can be matured if it is
 not heavily used ?

 But anyway, how can Athens be so slow? Why? Can you share some info? 

 You ask me to tell you why Athens is slow when we have this discussion
 before ( a few months ago) and you

Re: [Pharo-dev] Google Code Shutdown

Another project abandoned by Google, what a surprise :D

On Tue, Mar 24, 2015 at 3:14 PM, Sean P. DeNigris s...@clipperadams.com
wrote:

 In case anyone hasn't heard, Google Code will shut down entirely on January
 25, 2016. I was following these Smalltalk projects there:
 magritte-metamodel
 moose-technology
 seaside
 marsonpharo
 nativeboost
 metacello
 squeaksource3
 phratch - already on GitHub per Jannik

 The easiest action seems to be to export to GitHub, for which Google Code
 even provides a button! I just used it for one of my projects and it was
 pretty painless.

 - Sean

 Cross-posted to ESUG, pharo-dev, squeak-dev, seaside-dev, magritte,
 metacello



 -
 Cheers,
 Sean
 --
 View this message in context:
 http://forum.world.st/Google-Code-Shutdown-tp4814760.html
 Sent from the Pharo Smalltalk Developers mailing list archive at
 Nabble.com.

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]


if you read my mail, you will notice that I said BOTH are on the table (and
we are actually moving oon both):
- Bloc is the redesign
- In the mean time we WORK and ENCOURAGE others to work on improve it.

Last time I asked about Bloc , I was told not to use it and instead stick
with Spec or Morphic.

I said it before and will say it again, you guys need to sit down and make
a roadmap for Pharo because I am reading a lot of conflicting posts in this
mailing list and this is does not give the professional look Pharo wants to
show to people outside Pharo. As a user replace in the long run is not
enough ! The original author of Bloc , Alain, also said that he is pretty
much the only one that works on Bloc (with some help from Stef) and if
people dont start helping him out he is going to give up.

How many more threads should we have about the GUI future of Pharo before
people really get the message that we need a roadmap ?

Additionally , Pharo needs a roadmap , seriously it does.

but Morphic it self has several fundamental flaws that cannot be fixed and
that’s why in the long, very long way, needs to be replaced.  

What flaws , where , when , how , why ? So much discussion that Morphic
must go , close to zero discussion what the actual problems are.

First, Athens is not a replace for Morphic, is a replace for the canvas in
which morphs are drawn. So is not Morphic or Athens… is Morph using
DisplayPlugin or Morphic using Athens.

Second I did not say Athens is to replace Morphic . From my understanding
Bloc is based on Athens and Bloc is to replace Morphic. Correct me If I am
wrong.

Glamour is very mature and I’ve used it serval times… and in theory Brick
will be compatible with Glamour (mostly) so even if developers deprecate
one for the other you will be able to use your code (mostly). 

Brick is called non usable by its own authors. Glamour is framework of
building browsers and simplified GUIs , its nowhere near as powerful as
Morphic and is based on Morphic. From the looks of its is not even as
powerful as Spec. Through the couple years I have been around I have seen
at best a couple of question on how to make it work compared to hundreds of
questions about Spec and Morphic . How something can be matured if it is
not heavily used ?

But anyway, how can Athens be so slow? Why? Can you share some info? 

You ask me to tell you why Athens is slow when we have this discussion
before ( a few months ago) and you told me that Athens is slow because of
how Pharo handles rendering and that as soon as we move to SDL things will
be 10 times faster.

All I have to do is VGTiger runDemo and my 3Ghz Quad Cores beg me for mercy
at 50% consumption. Calling it slow , is an understatement.

Other much simpler example are very slow too like the sliding logo example
at many more.

Of course this problem affects Morphic too so personally I am examining the
possibility that no pharo library will satisfy me and instead I will make
my own GUI API on top of QT or HTML. Obviously more work for me, obviously
a scenario that I want to avoid, but if the alternative is an app that
consumes 50% cpu then I dont have much of a choice. Maybe I could take a
look at Mars too.

Re: [Pharo-dev] Update question

@Kilon:
  Integrating PharoLauncher in the standard image would not make sense.
Then I use PharoLauncher to download
  an image with a prepackaged PharoLauncher, ...

  If you mean that it should be the default tool to download when getting
Pharo 4.0 or Pharo 3.0 from the
  download page or from zeroconf then I would agree. Maybe some more help
is needed for Pharo newbees then.

Actually it makes perfect sense, think about it. We have configuration
browser. Now go to your pharolauncher and enable development mode, open
world menu and bingo pharolauncher is there as a tool and i think thats
great already. So you have 2 tools in your image 1) Configuration Browser
that allows you to install pharo libraries / apps 2) PharoLauncher that
allows you to download images . Both accessed in world menu and this
functionality is already provided by PharoLauncher.


I don't think Kilon was referring to PhaoLauncher, but to World  System 
Software update
cheers -ben

Yeap correct Ben I was referring to Software Update, as a matter of fact I
loved PharoLauncher so much I became a contributor and added documentation
about it in the new PBE.

On Tue, Mar 24, 2015 at 4:43 PM, Norbert Hartl norb...@hartl.name wrote:


  Am 24.03.2015 um 13:02 schrieb Sean P. DeNigris s...@clipperadams.com:
 
  NorbertHartl wrote
  What would be better using PharoLauncher?
 
  I was a hold out, but I've finally started using it and it's really nice.
  For things that don't have an automated build process, it's much better
 than
  downloading from file.pharo.org by hand. You can set the folder to
 which the
  images get saved, and choose to make new images from e.g. Pharo 4, 3, 2,
  moose, anything on the contribution CI server, and a few others.
 
  I really like Peter's idea to act from a startup script based on the
 image
  name. That sounds like a powerful combination.
 

 Oh, I didn't know that you can choose the folder where the images live. I
 might take another peek at it. But then I'm using something like that for a
 very long time.

 - make a folder projects in you home directory
 - in that folder create symlink to any of your smalltalk project directory
 that you are working at the moment
 - drop that folder in the dock
 - you click the icon on the dock, a list of projects pops up, you select
 one and you get the contents of that the directory. You click on an image
 and it starts

 So I'm not sure I'll gain something but I will try again.

 Norbert

Re: [Pharo-dev] collecting Pharo 4.0 Contributors

I am Dimitris Chloupis, always a honor to contribute to such an awesome
project like Pharo. I have not contributed bug fixes but I have contributed
with a lot of documentation by porting 5 chapters of PBE to Pharo 3 and
many video tutorials.

You cant be a dead language and still the king of live coding , that would
be ironic :D

Nope Pharo is alive and kicking ass . Thanks to all the contributors .

On Tue, Mar 24, 2015 at 4:39 PM, Esteban Lorenzano esteba...@gmail.com
wrote:

 Hi,

 I’m collection the list of contributors for this version.
 Since we detect contributors by author stamps:

 - some times who made the commit does not reflect all the people who
 worked on a problem,
 - we consider contributors to Pharo all people who has contributed in any
 way: discussing things, commenting bugs, doing videos or any kind of
 documentation, etc.

 the list will be incomplete, so please look for yourself on it and let me
 know if you are missing:

 also, I would like to know who are this two guys:
 - aaef
 - monty

 (btw… we collected so far 76 contributors… not bat at all, for a dead
 language ;) )

 Clara Allende
 Jean Baptiste Arnaud
 Philippe Back
 Clement Bera
 Alexandre Bergel
 Torsten Bergmann
 Vincent Blondeau
 Noury Bouraqadi
 Santiago Bragagnolo
 Johan Brichau
 Sven Van Caekenberghe
 Damien Cassou
 Nicolas Cellier
 Guido Chari
 Dimitris Chloupis
 Andrei Chis
 Ben Coman
 Bernardo Contreras
 Tommaso Dal Sasso
 Jan Van De Sandt
 Christophe Demarey
 Sean DeNigris
 Marcus Denker
 Martin Dias
 Stephane Ducasse
 Stephan Eggermont
 Luc Fabresse
 Johan Fabry
 Hilaire Fernandes
 Jerome Garcia
 Tudor Girba
 Thierry Goubier
 Kris Gybels
 Norbert Hartl
 Dale Henrichs
 Pablo Herrero
 Nicolai Hess
 Pavel Krivanek
 Juraj Kubelka
 Jan Kurs
 Laurent Laffont
 Jannik Laval
 Kevin Lanvin
 Max Leske
 David Lewis
 Diego Lont
 Esteban Lorenzano
 Esteban Maringolo
 Stefan Marr
 Tim Mackinnon
 Max Mattone
 Martin Mc Clure
 Eliot Miranda
 Sean De Nigris
 Alain Plantec
 Guillermo Polito
 Damien Pollet
 Stefan Reichhart
 Mark Rizun
 Udo Schneider
 Ignacio Sniechowski
 Henrik Sperre Johansen
 Igor Stasenko
 Aliaksei Syrel
 Ciprian Teodorov
 Camille Teruel
 Sebastian Tleye
 Yuriy Tymchuk
 Peter Uhnak
 Andres Valloud
 Sven Van Caekenberghe
 Thomas Vincent
 Martin Walk
 Richard Wettel

 thanks,
 Esteban

Re: [Pharo-dev] UI Workflows Are Like Snowflakes

2015-03-23 Thread kilon alios

I am referring to a general workflow that will ensure a user has a uniform
experience GUI wise. For example a gui tool will have to use the tab system
if it can be spanned in multiple instances, have a shortcut dialog that
will appear in a specific way, tools that come with their own code editors
respect general editor shortcuts etc etc . It will form the basis upon
which GUIs that are integrated to pharo are based on and then also allow
for freedom of expression on implementation details. A general agreement on
how Pharo should behave GUI wise since GUI is such a huge deal for Pharo.

On Mon, Mar 23, 2015 at 4:58 PM, Peter Uhnák i.uh...@gmail.com wrote:

 On Mon, Mar 23, 2015 at 3:15 PM, kilon alios kilon.al...@gmail.com
 wrote:

 It would be nice if there was a general guideline of GUI design that all
 tools would have to obey instead of giving complete freedom in creating a
 very fragmented experience.

 Could you elaborate on this a little? Are you refering to Spec vs Glamour
 (Brick)? Or issues inside of Spec, and/or Morphic?

 Peter

Re: [Pharo-dev] UI Workflows Are Like Snowflakes

2015-03-23 Thread kilon alios

It would be nice if there was a general guideline of GUI design that all
tools would have to obey instead of giving complete freedom in creating a
very fragmented experience.

I think this will be necessary the more complex tools are integrated into
Pharo.

Re: [Pharo-dev] Color arithmetical operations are broken

2015-03-22 Thread kilon alios

wait a sec why Alpha affects the Color ? o_O


Color white - (Color white alpha:0.5) = Color gray.

What ? No ! This make no sense


Color white - (Color white alpha:0) = Color white

Ok reasonable


Color white - (Color white alpha:1.0) = Color black.
again reasonable




On Sun, Mar 22, 2015 at 4:06 PM, Aliaksei Syrel alex.sy...@gmail.com
wrote:

 Color white - (Color white alpha:0) = Color white
 Color white - (Color white alpha:0.5) = Color gray.
 Color white - (Color white alpha:1.0) = Color black.
 For what do you need the color arithmetic ?
 Maybe there are already other operations defined on Color that you can
 used instead.


 That is too complicated :)
 The idea was to have one-line fix that just leaves the behaviour as it was
 before, simply makes it not produce garbage.
 Basically there should be a long discussion after pharo 4 is released.

 How it is now:
 (Color white alpha: 0) = Color transparent = false
 Color white - (Color white alpha: 0) = Color black = true

 From logical point of view is should not be black. But from mathematical
 point of view Color is just a vector and operations with it should be the
 same or almost the same as with vectors.

 For what do you need the color arithmetic ?

 I wanted to get linear discrete transformation from one color to another
 to use it in animation

 Cheers,
 Alex

 On Sun, Mar 22, 2015 at 1:54 PM, Marcus Denker marcus.den...@inria.fr
 wrote:


 On 22 Mar 2015, at 13:35, Nicolai Hess nicolaih...@web.de wrote:



 2015-03-22 12:43 GMT+01:00 Nicolai Hess nicolaih...@web.de:



 2015-03-21 15:51 GMT+01:00 Eliot Miranda eliot.mira...@gmail.com:

 Why not take the average of alpha in all cases?

 Eliot (phone)

 On Mar 21, 2015, at 6:32 AM, Aliaksei Syrel alex.sy...@gmail.com
 wrote:



 Or weight the argument by its alpha and don't change the alpha of the
 receiver:
 Color white - (Color white alpha:0) = Color white
 Color white - (Color white alpha:0.5) = Color gray.
 Color white - (Color white alpha:1.0) = Color black.

 For what do you need the color arithmetic ?
 Maybe there are already other operations defined on Color that you can
 used instead.

 As the arithmetic operations on Color doesn't work (for years?), maybe
 we should remove
 the operation now, and replace them with a more verbose api
 addRGB/ addRGBA/ subRGBA 

 nicolai


 Ah, this issue is already closed. That was a rather short discussion. And
 #/ and #* still don't work
 for colors.


 Yes… I think we have a problem that there is no “this is ready for
 integration” check.

 We need to get more careful…

 Marcus

Re: [Pharo-dev] Color arithmetical operations are broken

2015-03-22 Thread kilon alios

I personally assume to get Color transparent when subtract two absolutely
equal colors.

why ? that makes no sense to me. I guess we reason about things
differently. In art black and white are not colors, they are called
neutrals and they have the meaning of the existence of light (white) and
non existence of light (black) as such black has the meaning of zero.
Transparency does not affect colors its a characteristic of materials by
allowing some of the light to pass through.

In my view for arithmetical operation transparency should be ignored and
operate only on the color itself.

Re: [Pharo-dev] update of pharo by example?

the main repo is here

https://github.com/SquareBracketAssociates/UpdatedPharoByExample

There is a link for how to contribute in the README.

I was added as a contributor, all the above projects are inside an
organisation so once you added as a contributor to this orgainsation you
can contribute directly to all books .

Pull requests make more sense when you create forks and make your own
versions that go to a diffirent direction than the original repo. When all
you want is to contribute then becoming a contributor makes more sense
because its more straightforward for you and the original authors.

On Sat, Mar 21, 2015 at 2:59 AM, Dmitri Zagidulin dmi...@zagidulin.net
wrote:

 What's the workflow, to contribute to Updated Pharo By Example?

 Should people just make PRs against that repo?

 Looking over some of the other SquareBracketAssociates repos, there seems
 to be a repository-based workflow?
 - https://github.com/SquareBracketAssociates/PharoInProgress for work in
 progress chapters
 - https://github.com/SquareBracketAssociates/PharoReadyForReviews  for
 chapters ready for reviews?
 Does that mean that one makes PRs to the main UPBE repo after they get
 reviews? Or is this a previous / obsolete workflow?




 On Tue, Mar 10, 2015 at 3:19 PM, Serge Stinckwich 
 serge.stinckw...@gmail.com wrote:

 You may have a look here:


 https://ci.inria.fr/pharo-contribution/view/Books/job/UpdatedPharoByExample/lastSuccessfulBuild/artifact/book-result/UpdatedPharoByExample.pdf

 and contribute here:
 https://github.com/SquareBracketAssociates/UpdatedPharoByExample



 On Tue, Mar 10, 2015 at 8:13 PM, Alexandre Bergel
 alexandre.ber...@me.com wrote:
  Hi!
 
  I’ve heard some of you are working on an update of pharo by example. Is
  there anything ready for now? Some chapter maybe?
 
  Cheers,
  Alexandre
  --
  _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
  Alexandre Bergel  http://www.bergel.eu
  ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
 
 
 



 --
 Serge Stinckwich
 UCBN  UMI UMMISCO 209 (IRD/UPMC)
 Every DSL ends up being Smalltalk
 http://www.doesnotunderstand.org/

Re: [Pharo-dev] update of pharo by example?

And then the actual repo owners/contributors have a chance to comment on
the change (with nice tools like you can comment on individual lines of
code), and ask for corrections. (And then the author of the PR can make
corrections, and they'll show up automatically in the pull request.) Then,
finally, if they approve of the contribution, the pull request is merged.

There is a workflow of discussion for contributors , commits can have
comments and those comments can form discussions. You can also open  issues
and have a discussion there pointing to specific commits. Github issues are
not just there for bugs and now with its powerful tagging system you can
use it for all sort of discussion without polluting other kinds of issues
like bugs. Wiki can also be used for roadmap , again linking to specific
commits its easy etc. Thats what I love about Github its so flexible.

The main difference of pull requests is a way for forks to exchange code. I
am not saying you cant have a fork that closely follows the main repo and
just send pull requests but as I said in that case it would make more sense
to be a contributor directly. The whole process of accepting is not a such
a huge deal since you can always revert or even edit specific commits.

As a contributor to a repo, you can create a branch and a pull request
towards another branch in that very same repo, so you have access to the
same social mechanism if you want to use it.

yeah I kinda suspected that could be possible but why not just merge and
get it done ? Again the social mechanism of pull request is not any more
social that regular contributor commits.

Re: [Pharo-dev] update of pharo by example?

I had pull request phobias, I saw a doctor and I am fine now with some
medication.

The important thing is that you guys contribute , how you do it , its up to
you. For me not having to deal with pull requests is one less thing to
worry about. If I had to use them , I would . I used them once to improve
the dark theme in Amber, had no issues with it.

The bottom line is that more people are needed to contribute to
documentation. That's the important thing, the rest is just details.

On Sat, Mar 21, 2015 at 8:50 PM, Peter Uhnák i.uh...@gmail.com wrote:

 Also, thread hijacking. :)

Re: [Pharo-dev] update of pharo by example?

Great welcome on board Dmitri , by the way my real name is Dimitri too :)

On Sat, Mar 21, 2015 at 10:02 PM, Dmitri Zagidulin dmi...@zagidulin.net
wrote:

 Thanks, Stef, Kilon.

 I would like to contribute, actually.
 (I made a PR to the original PBE repo and the Updated PBE, linking the
 Readmes to each other etc).
 My GitHub username is 'dmitrizagidulin', if you'd like to add me to
 contributors.

 (I'm happy to merge pull requests etc, if you guys are busy and dont want
 to deal with it).

 Dmitri

 On Saturday, March 21, 2015, stepharo steph...@free.fr wrote:

  thanks dmitri.
 Indeed I would love to have people helping more. Damien and me are
 flooded by work right now.
 If you start here are some suggestions:
 - start by the end chapters (there are easier because less dependent)
 - I started to remove interaction details that will make the book
 obsolete fast.
 - I use Pharo and not Smalltalk most of the time.
 - I control reference on squeak because this is a pharo book
 - I'm redoing the diagram.
 - I was stuck in the Object Model (because the code changed and I
 should design an example
 that will be stable over time and not based on the system).
 Now the object model is not only presenting it but it is also
 teaching fundamental aspects of oop (that unfortunately
 many people got wrong.

 What would be good
 - you can start reading what we did already
 - ideally I would like to extend pillar so that we can execute the
 code snippets automatically and check that they are correct
 oscar had this excellent idea for PBE.

 if you start let us know :)

 We are working on a Mooc about Pharo so we want to have Pharo by Example
 fully updated.

 Stef


 Le 21/3/15 01:59, Dmitri Zagidulin a écrit :

   What's the workflow, to contribute to Updated Pharo By Example?

  Should people just make PRs against that repo?

  Looking over some of the other SquareBracketAssociates repos, there
 seems to be a repository-based workflow?
 - https://github.com/SquareBracketAssociates/PharoInProgress for work in
 progress chapters
 - https://github.com/SquareBracketAssociates/PharoReadyForReviews  for
 chapters ready for reviews?
  Does that mean that one makes PRs to the main UPBE repo after they get
 reviews? Or is this a previous / obsolete workflow?




 On Tue, Mar 10, 2015 at 3:19 PM, Serge Stinckwich 
 serge.stinckw...@gmail.com wrote:

 You may have a look here:


 https://ci.inria.fr/pharo-contribution/view/Books/job/UpdatedPharoByExample/lastSuccessfulBuild/artifact/book-result/UpdatedPharoByExample.pdf

 and contribute here:
 https://github.com/SquareBracketAssociates/UpdatedPharoByExample



 On Tue, Mar 10, 2015 at 8:13 PM, Alexandre Bergel
 alexandre.ber...@me.com wrote:
  Hi!
 
  I’ve heard some of you are working on an update of pharo by example. Is
  there anything ready for now? Some chapter maybe?
 
  Cheers,
  Alexandre
  --
  _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
  Alexandre Bergel  http://www.bergel.eu
  ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
 
 
 



  --
 Serge Stinckwich
 UCBN  UMI UMMISCO 209 (IRD/UPMC)
 Every DSL ends up being Smalltalk
 http://www.doesnotunderstand.org/

Re: [Pharo-dev] update of pharo by example?

just sent you an invitation , should give you access to whole organization
including all books.

On Sat, Mar 21, 2015 at 10:02 PM, Dmitri Zagidulin dmi...@zagidulin.net
wrote:

 Thanks, Stef, Kilon.

 I would like to contribute, actually.
 (I made a PR to the original PBE repo and the Updated PBE, linking the
 Readmes to each other etc).
 My GitHub username is 'dmitrizagidulin', if you'd like to add me to
 contributors.

 (I'm happy to merge pull requests etc, if you guys are busy and dont want
 to deal with it).

 Dmitri

 On Saturday, March 21, 2015, stepharo steph...@free.fr wrote:

  thanks dmitri.
 Indeed I would love to have people helping more. Damien and me are
 flooded by work right now.
 If you start here are some suggestions:
 - start by the end chapters (there are easier because less dependent)
 - I started to remove interaction details that will make the book
 obsolete fast.
 - I use Pharo and not Smalltalk most of the time.
 - I control reference on squeak because this is a pharo book
 - I'm redoing the diagram.
 - I was stuck in the Object Model (because the code changed and I
 should design an example
 that will be stable over time and not based on the system).
 Now the object model is not only presenting it but it is also
 teaching fundamental aspects of oop (that unfortunately
 many people got wrong.

 What would be good
 - you can start reading what we did already
 - ideally I would like to extend pillar so that we can execute the
 code snippets automatically and check that they are correct
 oscar had this excellent idea for PBE.

 if you start let us know :)

 We are working on a Mooc about Pharo so we want to have Pharo by Example
 fully updated.

 Stef


 Le 21/3/15 01:59, Dmitri Zagidulin a écrit :

   What's the workflow, to contribute to Updated Pharo By Example?

  Should people just make PRs against that repo?

  Looking over some of the other SquareBracketAssociates repos, there
 seems to be a repository-based workflow?
 - https://github.com/SquareBracketAssociates/PharoInProgress for work in
 progress chapters
 - https://github.com/SquareBracketAssociates/PharoReadyForReviews  for
 chapters ready for reviews?
  Does that mean that one makes PRs to the main UPBE repo after they get
 reviews? Or is this a previous / obsolete workflow?




 On Tue, Mar 10, 2015 at 3:19 PM, Serge Stinckwich 
 serge.stinckw...@gmail.com wrote:

 You may have a look here:


 https://ci.inria.fr/pharo-contribution/view/Books/job/UpdatedPharoByExample/lastSuccessfulBuild/artifact/book-result/UpdatedPharoByExample.pdf

 and contribute here:
 https://github.com/SquareBracketAssociates/UpdatedPharoByExample



 On Tue, Mar 10, 2015 at 8:13 PM, Alexandre Bergel
 alexandre.ber...@me.com wrote:
  Hi!
 
  I’ve heard some of you are working on an update of pharo by example. Is
  there anything ready for now? Some chapter maybe?
 
  Cheers,
  Alexandre
  --
  _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
  Alexandre Bergel  http://www.bergel.eu
  ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
 
 
 



  --
 Serge Stinckwich
 UCBN  UMI UMMISCO 209 (IRD/UPMC)
 Every DSL ends up being Smalltalk
 http://www.doesnotunderstand.org/

Re: [Pharo-dev] trying a hot update un smalltalkhub

2015-03-17 Thread kilon alios

Great work Esteban that JSON may come handy for building a front end of
STHub inside Pharo , so the users wont have to open an internet browser to
browser and download sthub projects.

On Tue, Mar 17, 2015 at 12:50 PM, Esteban Lorenzano esteba...@gmail.com
wrote:

 ok, thank went more or less fine :)

 now you have:

 http://smalltalkhub.com/list

 and

 http://smalltalkhub.com/list/json

 enjoy :)

 Esteban



 On 17 Mar 2015, at 11:15, Esteban Lorenzano esteba...@gmail.com wrote:

 Hi,

 I’m trying to use the power of pharo and do a hot update in smalltalkhub.
 Of course, it can fail… in that case I will need to turn it off and do it
 in the old way… :)

 Esteban

Re: [Pharo-dev] Debugging red screen

2015-03-11 Thread kilon alios

I have seen that myself but I dont think it was NB , I think it was
strikefonts and TTFs but that problem has been resolved since then. So its
possible to get severe red box of doom. Fortunately it rarely happens and
has happened to me 1-2 times.

On Wed, Mar 11, 2015 at 6:24 PM, Max Leske maxle...@gmail.com wrote:


  On 11 Mar 2015, at 17:15, Natalia Tymchuk natalia.tymc...@unikernel.net
 wrote:
 
  Hello.
  I’m working with graphics. Usually if i have some problem I got the
 debugger window, however some times it gives me the red rectangle error. I
 cannot understand from it what is the problem.
  What should I do in such case, maybe there is some way to get this
 signalError in debugger?
 
  Best regards,
  Natalia

 I work with NB too and I’ve never seen that (I either get a debugger or my
 image crashes :) ). Maybe it has something to do with the fact that you’re
 using / modifying Athens which is itself used to render elements of the
 image?

 Cheers,
 Max

 
  P.S. Here I attach the error I got.
 
   Screen Shot 2015-03-11 at 16.59.17.png

Re: [Pharo-dev] Pharo code of conduct?

2015-03-10 Thread kilon alios

Well you could also rename ubuntu code of conduct to pissing against the
wind to be more accurate. Since their biggest troll is Linus himself, the
creator of Linux.

And since they are not going to kick him out any time soon , such document
is as pointless as it could ever be.

Fortunately Pharo is in the opposite side and a far better position than
the Linux community will ever be. The real question is that if pharo ever
gets a troll like Linus that also happens to be a very substantial
contributor will the Pharo community have the courage to kick this guy out.
I would most definetly not be sticking around to find out.

I love Pharo , but I love having fun with coding even more.

Good conduct is a flag almost all people wave around but very few willing
to fight for it. A piece of paper is just meaningless without the relevant
actions.People who have zero tolerance against behaviour with the clear
intention to ridicule , insult and divide a community.

On Tue, Mar 10, 2015 at 10:47 AM, Christophe Demarey 
christophe.dema...@inria.fr wrote:

 Hello,

 We got some threads around the best way to work / communicate between
 ourselves.
 We are not the only ones concerned! Take a look at:

- http://www.zdnet.com/article/linux-adopts-conflict-resolution-code/
- http://www.ubuntu.com/about/about-ubuntu/conduct


 I really like the ubuntu code of conduct. We could adopt one for Pharo:
 1/ to always keep the fun
 2/ to describe how works the Pharo community to newcomers.

 Christophe.

Re: [Pharo-dev] new link to query all projects in smalltalkhub

2015-03-10 Thread kilon alios

AT LAST!!!

Thank you Esteban :)

On Tue, Mar 10, 2015 at 10:33 PM, Torsten Bergmann asta...@gmx.de wrote:

 Nice - by using a simple jquery plugin like http://www.datatables.net/
 on the page this would have been browseable/searchable.
 But it is a good start. Thanks!

 Bye
 T.


  Gesendet: Dienstag, 10. März 2015 um 12:09 Uhr
  Von: Esteban Lorenzano esteba...@gmail.com
  An: Pharo Development List pharo-dev@lists.pharo.org
  Betreff: Re: [Pharo-dev] new link to query all projects in smalltalkhub
 
 
   On 10 Mar 2015, at 11:58, p...@highoctane.be wrote:
  
   Cool.
  
   Would be nice with the description as well. Will avoid clicking around.
 
 
  yes, I thought it too, but descriptions are sometimes very long… it
 would be too much.
 
 
  
   Phil

Re: [Pharo-dev] [ANN AthensSketch] A playground for drawings with Athens.

2015-03-06 Thread kilon alios

compared to everything else I have used. I dont think I have ever seen even
twice as big as the one used in those examples spike my single core so
much. I am using menu meters ultilie that shows me how much cpu each
application uses and how much each core, together with memory and otther
stats.

But even more so I can eve see the frames in those animations flicker.
Especially that pharo slide logo example, but also all others.

On Sat, Mar 7, 2015 at 12:47 AM, Nicolai Hess nicolaih...@web.de wrote:



 2015-03-06 18:40 GMT+01:00 kilon alios kilon.al...@gmail.com:

 very good example and very informative thank you.

 Sadly it also shows that even with Athens Pharo is incredible slow.


 Compared to what?


 Simple animation spiking a single 3.2 Ghz core to 50% does not look very
 promising for heavy big size graphic based animations. Which is not a
 surprise since this was also evident the first time I tried the VGTiger
 demo. But still , its better than no Athens ;)

 On Fri, Mar 6, 2015 at 6:28 PM, Alexandre Bergel alexandre.ber...@me.com
  wrote:

 This is really good that you are diving into Athens. It deserves it!

 Alexandre


  On Mar 6, 2015, at 10:20 AM, Nicolai Hess nicolaih...@web.de wrote:
 
  There is a play button in the SketchBrowser.
  And if you open just the simple sketch view:
  ASketchExampleColors openView
  you'll have to start the drawing from the morph menu.
 
  In a prior version I had some autoplay option, but sometimes this
 throws
  a NativeBoost error, if it is the first time it loads the cairo
 library.
 
  Maybe I should add the autoplay again.
 
 
 
 
  2015-03-06 16:03 GMT+01:00 Torsten Bergmann asta...@gmx.de:
  For me all the samples stay black. But the Athens tiger demo works...
 
  Is this a driver problem?
 
  Bye
  T.
 
  Gesendet: Freitag, 06. März 2015 um 10:14 Uhr
  Von: Nicolai Hess nicolaih...@web.de
  An: Pharo Development List pharo-dev@lists.pharo.org, Any
 question about pharo is welcome pharo-us...@lists.pharo.org
  Betreff: [Pharo-dev] [ANN AthensSketch] A playground for drawings with
 Athens.
 
  The main purpose of this packages is to ease the creation of simple
 drawings and provide a rich set of examples for Athens drawing API.
  --
  Gofer new
smalltalkhubUser: 'NicolaiHess' project: 'AthensSketch';
configuration;
load.
  ConfigurationOfAthensSketch loadDevelopment.
 
  AthensSketchBrowser open.
 
  -
 
 
  This is a simple playground for Athens drawings. Just subclass
 AthensSketch and define your own sketch drawing in the #drawStepOn: method.
 It provides basic frame based animation (play/pause/stop).
 
  Open a player with
  ASketchExampleColors openPlayer',
  or a simple viewer morph with
  ASketchExampleColors openView (start and stop rendering from the morph
 menu)
 
  The AthensSketchBrowser lists all defined AthensSketch subclasses.
 (Basic examples
  from package AthensSketch and some more examples from package
 ASketchExamples).
  You can step through the list of examples, start and stop the drawing,
 or view and edit the drawing code.
 
  It is great that we have now a vector based drawing API. The (old)
 Canvas API is
  already great for pixel based drawings. A rich API and many good
 things if
  you discover it. And Athens is a  addition that can increase our
 possibilities.
  There were some questions about Athens, what it is and what it is used
 for, maybe this
  helps.
 
 
  nicolai
 

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

[Pharo-dev] Dead link to the bluebook

2015-03-06 Thread kilon alios

This link is dead


http://stephane.ducasse.free.fr/FreeBooks/BlueBook/

Re: [Pharo-dev] [ANN AthensSketch] A playground for drawings with Athens.

2015-03-06 Thread kilon alios

That is not really helpfull. Anything that uses cairo? I would like to
make some comparisons and it would help if I can recreate the same
animations.
(I did some work with cairo and python, but no animation. I used cairo for
animations together with GTK, sure this was faster but these applications
are only made for the animation, just a simple drawing loop. Pharo of
course has much more that happens in between).

No I was not talking as a developer but rather as a user, so by
everything I mean literally everything I use, cairo based or not. I am no
cairo developer , I only took a look at the pycairo docs once. I have
picked the habit of taking a look at how much cpu each application consumes
by using Blender. As you can imagine blender can eat cpu cycles like
peanuts, so I have an overall idea under which circumstances the cpu can
max out so I have learned to avoid it by utlising several techniques. I am
also a blender python developer.

But then its not hard to imagine that when you see a simple animation of a
small logo slide in a very small area cosuming 30-50% of CPU and flicker,
that 2d game running in full screen or even half screen would be a no go.

On Sat, Mar 7, 2015 at 4:38 AM, Esteban Lorenzano esteba...@gmail.com
wrote:


 On 07 Mar 2015, at 00:02, Nicolai Hess nicolaih...@web.de wrote:

 2015-03-06 20:18 GMT+01:00 Esteban Lorenzano esteba...@gmail.com:


 On 06 Mar 2015, at 18:40, kilon alios kilon.al...@gmail.com wrote:

 very good example and very informative thank you.

 Sadly it also shows that even with Athens Pharo is incredible slow.
 Simple animation spiking a single 3.2 Ghz core to 50% does not look very
 promising for heavy big size graphic based animations. Which is not a
 surprise since this was also evident the first time I tried the VGTiger
 demo. But still , its better than no Athens ;)


 That’s because we are converting the rendering into a bitmap that is
 after drawn for the vm… a complete inefficient mechanism.


 I heard this multiple times, but I still don't get it. The (cairo)
 rendering happens on a (in memory) imagesurface. There is no extra
 allocation
 of a bitmap for every drawing on the screen. Drawing the rendering on the
 screen is a bitblt (copybits) operation, like it is done for every other
 Form.


 I will try to explain… is a problem in several ways:
 1) what is not efficient at all is BitBlt plugin, our current way to
 display things. Want an example? just open a new image, open a browser (or
 a playground, or any window) and start moving it…. then watch how your cpu
 starts heating (in my machine, is around 35%, some times… just one
 browser).
 2) Now… what we do with Athens is:
 a) create an in-memory surface and draw things there.
 b) convert that surface into a bitblt compatible format (this is actually
 just a copy, not much actually)
 c) display the result into the current world window (another copy)
 3) Now imagine all that cycling (stepping)…

 With OSWindow (SDL2) what we do is:
 1) create a SDL2 surface
 2) draw on it
 3) cycle on (2)



 I have a running experiment for drawing directly in the canvas (using
 SDL2 library) and the tiger demo drops from eating 70% of cpu to 9% in my
 machine.


 We can do this without SDL, but of course less platform independent, with
 cairos win32 , quartz, or xrender (os dependent) surfaces. This is really
 fast, no need
 for an (in memory) image surface. But one problem with this approach is,
 some morphs need to access the current displays Form data (HandMorph for
 example).
 And this does not work (or not easily) with the OS device surface.
 Does this work with cairo and SDL?


 yes, why not?
 and yes… we can have several backends. The advantage on using SDL2 is that
 you do not need to maintain one different backend for each platform. Of
 course, it has also drawbacks, as always… but our manpower is determinant
 here and we decided to take the “common approach”… we will have time to
 improve later, if we find is necessary (but frankly, I do not think so for
 the moment)


 One thing that is really slow is painting an image with Athens, because
 the cairo backend creates a new surface for this image and uses this
 image as a pattern paint. The slow part is copying and converting the
 image data into the surface.
 I already proposed an alternative, (it's a bit like cheating), we can use
 the bitblt to copy and convert the image data into the surface, this again
 is much faster.


 this is something inherent to cairo (and athens as a result)… I suppose
 game programmers already dealt with this problem. I suggest look there for
 answers (I didn’t look there, nor seen your proposed solution yet… sorry I
 will as soon as I find some time).

 cheers,
 Esteban




 Our idea is to move pharo in that direction for Pharo5 so next year we
 will be a lot better :)

 Esteban


 On Fri, Mar 6, 2015 at 6:28 PM, Alexandre Bergel alexandre.ber...@me.com
  wrote:

 This is really good that you are diving into Athens

Re: [Pharo-dev] Recording user actions in GTools

no objection from me, whatever help you guys improve the tools, helps me ;)

On Thu, Feb 26, 2015 at 5:10 PM, Andrei Chis chisvasileand...@gmail.com
wrote:

 Hi,

 In order to better understand how people use the GT tools we would like to
 integrate, before the Pharo code freeze, a small extension to GT tools (300
 lines of code) that records and sends usage data.

 The recording of data will be opt-out: *you have to explicitly agree with
 sending usage data*.
 The first time you open a GT tool, that tool will embed a small UI asking
 you if you want to enable data submission.
 We will save the setting in the your preference directory so it will be
 shared between all your local images.
 You can change this setting at any time from the Settings Browser.

 For now we will only like to collect data about Spotter.
 *By default we will only collect anonymous data *about various actions
 you do in spotter (open, close, search, dive-in, dive-out, select element,
 etc) without collecting any data what about what query you enter or what
 search results you get.
 We would also add an optional setting for sending the query text and
 selected elements.

 We will send then the data periodically to our server and when you close
 the image.

 The data that will be send is rather small: 1000 actions require 7kb of
 data.
 Thus sending an entire day worth of recordings, if all you did that day
 was searching, should be around 1MB of data.

 The recording does not influence the performance of Spotter. Spotter
 already generates all events of interest as announcements.
 To enable recording we just register a subscriber with the Spotter
 announcer and store the events of interest.

 We would like to get your opinion on this.


 Cheers,
 GT team

Re: [Pharo-dev] The evil twin in 40516

I see , I did not realise there is so much negative about Pharo since most
people dont seem to be aware of it and the moment they understand what it
is they are impressed. At least people I introduced to Pharo.


Me too.
And the infrastructure is getting really really great. To be point that I
cannot see what the people will
do with it. So this is great,

I am also interested into maybe creating my own sub language in Pharo that
can turn to pharo code but also offer features more orientated towards
visual coding. But that is way down the road.

Re: [Pharo-dev] The evil twin in 40516

so essentially live coding the live coding, wow that sounds impressive
indeed.

Thanks for taking the time explaining it.

I guess this feature will be also very useful for people building DSLs with
Pharo.

On Fri, Feb 27, 2015 at 5:24 PM, stepharo steph...@free.fr wrote:

  in essence we can annotate an AST and the annotations can become live at
 runtime and can also represents the computation itself.
 So you can have objects that represent properties of the execution itself
 and change the execution or something like that :).

 So with that we can for example build better debugger, profilers,


 Le 27/2/15 13:24, kilon alios a écrit :

  I can explain why, its the language you use.

  For example this feature, I have no clue what you guys are talking about.

  For people to be impressed first they need to understand what they should
 be impressed with.

 On Fri, Feb 27, 2015 at 2:12 PM, Marcus Denker marcus.den...@inria.fr
 wrote:



 On Fri, Feb 27, 2015 at 12:35 PM, Tudor Girba tu...@tudorgirba.com
 wrote:

 So many cool things!

  We cannot even imagine at this point what all these little conceptual
 things will bring in downstream projects. This is amazing.


  Interestingly, the world view of most people is different... they never
 realise this, they seem to fundamentally not see this
 connection. I have not yet found out why...

 Marcus

Re: [Pharo-dev] The evil twin in 40516

Sooner or later then you will have to name people, because talking
generally wont change the situation.

Who in this community believe that improving Pharo is pointless / does not
have an effect ?

I am getting totally opposite feeling with this community. One the reasons
I enjoy Pharo.

On Fri, Feb 27, 2015 at 2:34 PM, Marcus Denker marcus.den...@inria.fr
wrote:


 On 27 Feb 2015, at 13:24, kilon alios kilon.al...@gmail.com wrote:

 I can explain why, its the language you use.

 For example this feature, I have no clue what you guys are talking about.

 For people to be impressed first they need to understand what they should
 be impressed with.

 I did not mean this feature. I mean the abstract concept of improvement
 having an effect.

 On Fri, Feb 27, 2015 at 2:12 PM, Marcus Denker marcus.den...@inria.fr
 wrote:



 On Fri, Feb 27, 2015 at 12:35 PM, Tudor Girba tu...@tudorgirba.com
 wrote:

 So many cool things!

 We cannot even imagine at this point what all these little conceptual
 things will bring in downstream projects. This is amazing.


 Interestingly, the world view of most people is different... they never
 realise this, they seem to fundamentally not see this
 connection. I have not yet found out why...

Marcus

Re: [Pharo-dev] The evil twin in 40516

I can explain why, its the language you use.

For example this feature, I have no clue what you guys are talking about.

For people to be impressed first they need to understand what they should
be impressed with.

On Fri, Feb 27, 2015 at 2:12 PM, Marcus Denker marcus.den...@inria.fr
wrote:



 On Fri, Feb 27, 2015 at 12:35 PM, Tudor Girba tu...@tudorgirba.com
 wrote:

 So many cool things!

 We cannot even imagine at this point what all these little conceptual
 things will bring in downstream projects. This is amazing.


 Interestingly, the world view of most people is different... they never
 realise this, they seem to fundamentally not see this
 connection. I have not yet found out why...

Marcus

Re: [Pharo-dev] Athens/Morphic

2015-02-23 Thread kilon alios

so that means now athens mix with morphic just fine without extra work ,
great work guys :)

On Mon, Feb 23, 2015 at 10:59 AM, Nicolai Hess nicolaih...@web.de wrote:

 Load the new configuration of athens (2.9)
 Open an AthensWorld:
 AthensWrapWorldMorph new openInWorld


 Drag and drop some morphs on this athens world.
 (Nautilus /Old Workspace should fully work/ GT Inspector and Playground
 not)



 2015-02-23 9:51 GMT+01:00 stepharo steph...@free.fr:

  how can I play with that?

 even if I should not.

 Le 20/2/15 08:54, Marcus Denker a écrit :

 Very nice! Works here (on Mac).

  I will integrate as soon as the CI is up again…

  Marcus

  On 19 Feb 2015, at 12:44, Nicolai Hess nicolaih...@web.de wrote:

Most of this (without the test class (AthensTestDisplay)) is now
 ready for
 integration.

  A lot of changes for making Mophic and Text(Morphs) work on Athens
 (For testing purpose there is also the AthensWrapWorldMorph included).

  The Canvas wrapper (AthensCanvasWrapper) is not yet included and
 therefore
  all Morphs that do not explicit have a proper drawOnAthensCanvas method
 arent't drawn (or just like rectangles).

  Should work with any image = 40490
  Just load the latest ConfigurationOfAthens from pharo 40 inbox and
 load
 ConfigurationOfAthens loadVersion:'2.9'

  If this is working (or not:) ) please leave a note on fogbugz:
 14954 load new configuration 2.9 (more morphic support)


  nicolai


 2015-01-31 11:54 GMT+01:00 Alain Plantec alain.plan...@yahoo.com:



 Yes the HandMorph is handled like any other Morph, it draws itself
 and
  after that it draws all its submorphs. (And actually it does not use
 any caching, and it is still quite fast)


  the same in Bloc, no caching and it works just fine :)

 But yes, it needs a special drawOnAthens method.


  Do you plane to make a package for it ?
 I would like to integrate it in Bloc.


  What would like to integrate?

  In fact I do not see any change when in Bloc.
 So I guess I will have to adapt Bloc to your changes.

 I will upload the changes  in Athens-Morphic package to
  the Athens repository.


  cool.

  thanks

  Alain

Re: [Pharo-dev] ||

2015-02-08 Thread kilon alios

I disagree.  I want to see the pragma.  It has essential information that
shouldn't be hidden.  I want to edit it easily.  And how can you in the one
hand say it can be implemented as a normal message send a d at the same
time want it hidden?  Be consistent :-)

I agree with you Eliot, I definitely would not want for pragmas to be
hidden. They are an important part of the code they should be visible with
the rest of the code. It would lead to confusion otherwise . Opening 10
tools to be able to view code is also not ideal.

Re: [Pharo-dev] ||

Personally I don't like Pragmas, they have not convinced me so far that
they fit the style of Smalltalk syntax. I have to confess though I never
liked descriptive elements and languages .

About python decorators I disagree that are similar to pragmas. Pragmas are
focused on being descriptive , python decorators are descriptive as by
product. The main focus of python decorators is to shorten code by
introducing syntactic sugar.

I agree though this is a very interesting discussion and I dont understand
most of the things stated here so I leave an open door and mind for
pragmas. Maybe one day I will get it.

On Sat, Feb 7, 2015 at 10:02 AM, Thierry Goubier thierry.goub...@gmail.com
wrote:



 2015-02-06 22:00 GMT+01:00 stepharo steph...@free.fr:

 Really interesting discussion. I like pragmas but this is interesting to
 see them challenged.


 Thanks. It's a pleasure to discuss that way :)


  Yes, but there end up being lots of naming conventions and they are
 non-obvious.  Whereas pragmas, because they are in-your-face in the methods
 in question, don't need conventions. They just need documenting ;-).

 Thierry I'm skeptical that multiple protocol will save the problem
 because you will rely on coding conventions.


 Pragma as well: just explain the conventions behind the gtInspector
 pragmas, for example.

 But give me multiple protocols and I'll show you the same conventions
 rewritten in less lines (and a slightly more efficient code).


 And pragma is a clever tagging.


 Then maybe we should remove protocols and replace them with pragmas :)

 Thierry



 Stef

Re: [Pharo-dev] ||

Kilon, pragmas are not limited to being descriptive.

Ok , I went back and carefully read your posts. I did not noticed that
pragmas are executable too, I stand corrected. It appears I underestimated
Pragmas, after reading your posts I see where you going with this.
Especially the part of adding methods to objects like menu
entries definitely makes some sense.

The more I think how I would do this, the more I start to appreciate
pragmas. For example I would attach some variables to Object class to
create a dictionary that will manage meta data for each method. That would
move the definition of the method meta data outside the method definition
itself but I am not sure if that is such a good thing afterall.

I think I will let myself get a few years more experience in Pharo to make
up my mind and fully appreciate pragmas.

Re: [Pharo-dev] ||

I agree, my objection too is how it looks syntax wise. As I said I don't
understand pragmas deeply enough to make a decision if I want them removed
or not.

Tag wise, well I think a tag should be an IDE and not a language feature.
But thats my personal preference. Protocols for me at least is another way
to tag things.

As I said in the past I would prefer a more elaborate system of tagging for
methods and classes similar how Stackoverflow questions work of default and
custom tags.

On the other hand, people like different things so I never made a big deal
out of it.  So for now I just tolerate pragmas and they do tolerate me :D

On Sat, Feb 7, 2015 at 5:41 PM, Hernán Morales Durand 
hernan.mora...@gmail.com wrote:


 2015-02-07 5:59 GMT-03:00 kilon alios kilon.al...@gmail.com:

 Personally I don't like Pragmas, they have not convinced me so far that
 they fit the style of Smalltalk syntax. I have to confess though I never
 liked descriptive elements and languages .


 Me neither. Actually the pragma idea is not wrong per se, it is the tag
 syntax to write them which bothers me. Because the world can be described
 with tags if you start that path.
 There are other ways to add metadata to methods. Without tagging.
 And they don't need to be in the method pane itself.
 It is like having to specify protocol because there is no list pane to
 create them.

 Hernán


 About python decorators I disagree that are similar to pragmas. Pragmas
 are focused on being descriptive , python decorators are descriptive as by
 product. The main focus of python decorators is to shorten code by
 introducing syntactic sugar.

 I agree though this is a very interesting discussion and I dont
 understand most of the things stated here so I leave an open door and mind
 for pragmas. Maybe one day I will get it.







 On Sat, Feb 7, 2015 at 10:02 AM, Thierry Goubier 
 thierry.goub...@gmail.com wrote:



 2015-02-06 22:00 GMT+01:00 stepharo steph...@free.fr:

 Really interesting discussion. I like pragmas but this is interesting
 to see them challenged.


 Thanks. It's a pleasure to discuss that way :)


  Yes, but there end up being lots of naming conventions and they are
 non-obvious.  Whereas pragmas, because they are in-your-face in the 
 methods
 in question, don't need conventions. They just need documenting ;-).

 Thierry I'm skeptical that multiple protocol will save the problem
 because you will rely on coding conventions.


 Pragma as well: just explain the conventions behind the gtInspector
 pragmas, for example.

 But give me multiple protocols and I'll show you the same conventions
 rewritten in less lines (and a slightly more efficient code).


 And pragma is a clever tagging.


 Then maybe we should remove protocols and replace them with pragmas :)

 Thierry



 Stef

Re: [Pharo-dev] [squeak-dev] Re: ||

And none of the XML and web technologies sell as much as Angry Birds and
Candy Crash Saga :D

I think you underestimate people. True Web is very popular, but lets not
forget all the promises a decade ago that we will completely move to the
cloud in a few years and we are still desktop all the way. Only desktop has
moved to mobile devices which none could predict it at the time.

On the other hand Smalltalk was not rejected because it was beautiful , it
was rejected because it failed to adjust to current demands. It remained a
good proof of concept and not much more than that. It opened the door , but
never truly entered the room.

On Sat, Feb 7, 2015 at 6:01 PM, Andreas Wacknitz a.wackn...@gmx.de wrote:


  Am 07.02.2015 um 16:18 schrieb David T. Lewis le...@mail.msen.com:
 
  On Thu, Feb 05, 2015 at 01:54:51PM +0100, Marcus Denker wrote:
 
  On 05 Feb 2015, at 10:12, Marcus Denker marcus.den...@inria.fr
 wrote:
 
  On 05 Feb 2015, at 10:04, Marcus Denker marcus.den...@inria.fr
 wrote:
 
  Another way to see it: How would the original Smalltalk be designed if
 they would have had 4GB RAM in 1978?
 
  What fascinates me still is that Smalltalk used the existing resources
 (even building their own machines) to an
  extreme, while today we are obsessed to find reasons why we can not do
 anything that makes the system
  slower or use more memory than yesterday. And that even with resources
 growing every year???
 
  This is why we e.g. now have a meta object describing every instance
 variable in Pharo. I am sure there are people
  who will see these ~7000 objects as pure waste??? while I would say
 that we have already *now* the resources to be
  even more radical.
 
 
  Seemingly I still can not explain what I mean in away that people get
 it, so please just ignore this mail.
 
   Marcus
 
 
  Your point makes good sense to me. In 1978, a system in which a low-level
  integer was represented as an object with behavior would have been
 perceived
  as a rediculously wasteful idea. And can you imagine someone seriously
  suggesting something so wasteful as automatic memory management?
 
  So if the same system was being designed today, it might very well
 include
  new concepts that today are perceived as wasteful. Some of those concepts
  might turn out to be very good thing once we get used to them.
 The times have changed. Today waste seems to be a requirement.
 Whatever application you have - reimplement it using „web technologies“.
 Whatever data you have - store it in „the cloud“ and tunnel its
 transportation over port 80,
 gain extra points for using XML here.

 Today, beautiful small things like Smalltalk are ignored by the masses and
 being laughed at.

 Andreas

Re: [Pharo-dev] Spotter exact match

2015-02-05 Thread kilon alios

+1


On Thu, Feb 5, 2015 at 2:46 PM, Ben Coman b...@openinworld.com wrote:

 Some feedback on spotter.

 I want to search for #doIt.  It shows me five methods starting with doIt
 but it would be nicer if exact matches took priority. Alternatively, it
 would be okay if typing doitspace did an exact match.

 cheers -ben

Re: [Pharo-dev] ||

2015-02-05 Thread kilon alios

I am surely wont complain if you made code that I need to be faster,
faster.

Afterall languages like C/C++ are not popular by accident. Nor is
accidental that many of python libraries are made in those two language
that people love to hate.

I am definitely not claiming that performance is not important. But slow
speed definetly did not kill Python, it wont kill Pharo either.

On the other hand recently I was distracted by the fact that people still
code on old computers like Amstrads and Amigas  and have beendoing some
amazing stuff like GUIs OS with video playback , internet browsing,
Business applications etc which is kinda insane if you take into account
that these are machines that thousands times slow with cpu that barely
reach 6-12mhz.

So I think we need to be realistic about Pharo and let things evolve and
people contribute the way they want and can. Both performace and efficiency
are very important. But yes I am more orientated towards well designed
workflow. Maybe this is why I still I love Amiga 500 :D

On Thu, Feb 5, 2015 at 12:24 PM, Thierry Goubier thierry.goub...@gmail.com
wrote:



 2015-02-05 11:14 GMT+01:00 kilon alios kilon.al...@gmail.com:

 And there is also the matter of hardware evolution.

 When I was running Pharo on my 2007 imac 20'' with dual core 2.GHZ ,
 Morphic was slow. And by slow I mean that I could see it was struggling to
 move windows around. I could see windows flickering trying to render
 themselves moving around.

 But now with my 2014 imac even though the screen is double the size and
 the resolution much bigger (27'' retina) , Morphic is now quite fast. The
 reason is of course the fact that the CPU is a quad core at 3 Ghz thats
 almost a 3x times increase in speed and it really shows.

 Even when Pharo take full the huge area of 27'' Morphic is responsive and
 quite fast.


 Which means if I see you complaining of speed issues, then it must be
 really bad :)

 Thierry

Re: [Pharo-dev] ||

2015-02-05 Thread kilon alios

And there is also the matter of hardware evolution.

When I was running Pharo on my 2007 imac 20'' with dual core 2.GHZ ,
Morphic was slow. And by slow I mean that I could see it was struggling to
move windows around. I could see windows flickering trying to render
themselves moving around.

But now with my 2014 imac even though the screen is double the size and the
resolution much bigger (27'' retina) , Morphic is now quite fast. The
reason is of course the fact that the CPU is a quad core at 3 Ghz thats
almost a 3x times increase in speed and it really shows.

Even when Pharo take full the huge area of 27'' Morphic is responsive and
quite fast.

8 cores are not much further down the road either. And unlike the native
GUI of MACOS , Morphic does not take advantage of GPU acceleration that can
offer speed us even 10 times compared to a modern CPU.

So I think that even if we keep performance in Pharo at same level, things
will get noticeably better through the evolution of hardware alone.

I do agree that Efficiency and especially ease of use must be the main
focus.

On Thu, Feb 5, 2015 at 11:55 AM, Sven Van Caekenberghe s...@stfx.eu wrote:


  On 05 Feb 2015, at 10:46, Thierry Goubier thierry.goub...@gmail.com
 wrote:
 
 
 
  2015-02-05 10:12 GMT+01:00 Marcus Denker marcus.den...@inria.fr:
 
   On 05 Feb 2015, at 10:04, Marcus Denker marcus.den...@inria.fr
 wrote:
  
  
   On 04 Feb 2015, at 22:04, Levente Uzonyi le...@elte.hu wrote:
  
   A single parser is a nice goal, but performance is top priority for
 Shout, because it should do it's job real-time. When it starts lagging
 behind, then people just turn it off, because it doesn't help them.
   Can those parsers (SHRBTextStyler and a Smalltalk parser written
 using PetitParser) parse an average method in less than 20ms on an average
 machine?
  
   I have not yet benchmarked it… PetitParser as it is is too slow, but
 we will soon have a faster version (factor 10).
  
   We should do some benchmarks. For using, it seems ok. With a fast
 machine + JIT, which does not say much of course.
   (there is a setting 'AST based coloring’ in Pharo3 and Pharo4, but it
 is turned off by default).
  
   One thing that is nice with the AST is that it can be used for other
 things, too. e.g. in Pharo we have a menu that is defined
   by the AST nodes and structural navigation in the editor.
  
 
  Another way to see it: How would the original Smalltalk be designed if
 they would have had 4GB RAM in 1978?
 
  Badly for today's machines :)
 
 
  What fascinates me still is that Smalltalk used the existing resources
 (even building their own machines) to an
  extreme, while today we are obsessed to find reasons why we can not do
 anything that makes the system
  slower or use more memory than yesterday. And that even with resources
 growing every year…
 
  You're spoiled by your nice and expensive macbooks :)
 
  Honestly, on some of today's machines, you'd better avoid long methods
 or GT tools stuff because they are slow.
 
  SmaCC code generation is slow.
 
  PluggableTreeMorph is slow.
 
  Nautilus is slow.
 
  Loading large configurations is slow.
 
  Roassal complex graphs are slow.
 
  Serge's modeling stuff is slow.
 
  PetitParser has performance problems.
 
  BitBlt is slow (and Cairo has bugs).
 
 
  This is why we e.g. now have a meta object describing every instance
 variable in Pharo. I am sure there are people
  who will see these ~7000 objects as pure waste… while I would say that
 we have already *now* the resources to be
  even more radical.
 
  Being radical in the context of Pharo is offering to remove stuff or
 layers :):)
 
  Thierry

 It is obviously a compromise (or a continuum) between abstractions and
 performance.

 But there should remain a focus on efficiency (not just speed but also
 memory), it is hard to fix these things years later.

Re: [Pharo-dev] How Stable is Pharo 4.0?

2015-02-04 Thread kilon alios

Well I would not just call it painless more like a very big improvement
over Pharo 3. No strange bugs and abnormal behaviour so far , and I have
been using it for more than a year.

On Wed, Feb 4, 2015 at 4:21 PM, Sean P. DeNigris s...@clipperadams.com
wrote:

 Is anyone successfully using it for everyday development on their own
 projects? How painless/ful is it? Thanks



 -
 Cheers,
 Sean
 --
 View this message in context:
 http://forum.world.st/How-Stable-is-Pharo-4-0-tp4803645.html
 Sent from the Pharo Smalltalk Developers mailing list archive at
 Nabble.com.

Re: [Pharo-dev] Plague Doctor

2015-01-30 Thread kilon alios

Easier for you or me ? :D

Unfortunately my free time is too limited to try everything that pops up to
the mailing list to later find out that I can't get it to work because of
limited/non existent  documentation  and me having no clue what the thing
is doing or spend time on something that does not interest me. So its
easier to just ignore it and move on.

But since I am super interested to solutions that make managing windows
more manageable (pun intended) I can't resist trying this out.

On Fri, Jan 30, 2015 at 4:35 PM, Roberto Minelli roberto.mine...@usi.ch
wrote:

 Woop, didn't check for copyright when I did the poster. However, the
 Plague Doctor monitors the usage of windows in the Pharo IDE and closes the
 ones that are likely not to be used. It uses (optional) visual clues the
 importance of a windows (heat scale from blue to red) and fades away not
 used windows.

 It's easier if you give it a try!

 On 30 Jan 2015, at 12:57, kilon alios kilon.al...@gmail.com wrote:

 Bare in mind that using Copyrighted images without the permission of the
 author makes you liable to be sued.

 So what is Plague Doctor ? The smalltalkhub description does not help at
 all, what is that window plague ?

 On Fri, Jan 30, 2015 at 1:28 PM, stepharo steph...@free.fr wrote:

  :)

 Great picture! I love Plague Doctor
 freaking guy.

 Stef

 Le 30/1/15 11:29, Roberto Minelli a écrit :

 To follow Stef’s advice of advertising our projects, here is the Plague
 Doctor!

  During development your Pharo IDE will quickly become overcrowded with
 unused windows. The Plague Doctor is a tool, inspired by Autumn Leaves,
 that helps you to mitigate this issue by closing the windows that you are
 less likely to use in the future.

  If you want to try our prototype, please install it with the following
 script or ask me for a quick demo (I am Lille for the PharoDays!).

  Gofer new
   smalltalkhubUser: 'RobertoMinelli' project: 'PlagueDoctor';
   package: 'ConfigurationOfPlagueDoctor';
   load.
 (Smalltalk at: #ConfigurationOfPlagueDoctor) loadDevelopment.

  mime-attachment.png

  http://smalltalkhub.com/#!/~RobertoMinelli/PlagueDoctor

  P.s. If you report a problem or a feature request, please file in an
 entry
 https://github.com/RobertoMinelli/PlagueDoctor/issues

Re: [Pharo-dev] Create window group for Playground

2015-01-30 Thread kilon alios

you dont watch my video tutorials ? ;D

here is one for window groups

https://www.youtube.com/watch?v=GGJZeajjWGUindex=12list=PLqbtQ7OkSta0ULYAd7Qdxof851ybh-_m_

I agree this one of the features that I really miss and I think I was the
first one to report it in this least when Playground was announced it for
Pharo 4. Yes Peter I am using your workaround to compensate for this.

Do you want to hear the irony , I only use Workspace to create a window
group to act as a container for Playgrounds :D

Actually finding a way to create tabs for the guis in Pharo had been one of
my first priorities to develop but when I reported my idea in this mailing
list I was informed that the feature already existed. I was so happy I made
a video tutorial about it because its a pity so useful features to be so
hidden from the user. Probably an Icon would have made it way more obvious
to most users.

On Fri, Jan 30, 2015 at 12:11 PM, stepharo steph...@free.fr wrote:

Another features that nobody knows (even us).

Stef

Le 29/1/15 18:51, Torsten Bergmann a écrit :

Previous (and still included) Workspace, Transcript and Nautilus
provide Window grouping by selecting Create window group from the
window menu and then dragging two windows onto each other.
They are grouped together in one single window then and each one
gets a tab.

Looks like Playground does not support this feature yet - so currently
I end up with many many windows which for me is a step backwards
compared to working with workspaces in Pharo 3.0

What is necessary to provide this for the Playground so we have a
common behavior for all the tools and a cleaner desktop?

Thanks
T.

Re: [Pharo-dev] Create window group for Playground

2015-01-30 Thread kilon alios

personally I dont even understand why one would not want tabs, especially
in such a heavy window orientated enviroment like Pharo. Sure if I better
solution existed yes, but even in MacOS while mission control existed for
quite some time (offers a bird eye view of opened windows) still Apple was
forced to implement tabs even inside Finder. Tabs are actually a standard
feature for all applications nowdays and is strange that Pharo has hidden
it inside menus.

I completely agree with you that drag and drop or at least some other easy
to use solution would be ideal.

On Fri, Jan 30, 2015 at 3:00 PM, Ben Coman b...@openinworld.com wrote:

 maybe it should just be enabled permanently? defaulting to showing a tab
 when only one window is present - just the same as you get with a web
 browser.  I think this paradigm is common enough with web browsers today
 being able to drag/drop tabs is a common enough that this will be
 discoverable for most people.

 Perhaps a preference to turn it off as a backup for those that don't like
 it?

 btw,

 cheers -ben

 On Fri, Jan 30, 2015 at 8:48 PM, Tudor Girba tu...@tudorgirba.com wrote:

 I know about the feature, but we did not yet find a proper solution for
 it.

 The current default solution does not make for a good user experience: I
 have to click an obscure menu item just to make the window be a drop target
 and I get no visual feedback of what can be dropped on it. The issue of
 many windows is a significant problem that deserves a closer attention.

 I am sure it will take a while, though.

 Cheers,
 Doru


 On Fri, Jan 30, 2015 at 11:11 AM, stepharo steph...@free.fr wrote:

 Another features that nobody knows (even us).

 Stef

 Le 29/1/15 18:51, Torsten Bergmann a écrit :

  Previous (and still included) Workspace, Transcript and Nautilus
 provide Window grouping by selecting Create window group from the
 window menu and then dragging two windows onto each other.
 They are grouped together in one single window then and each one
 gets a tab.

 Looks like Playground does not support this feature yet - so currently
 I end up with many many windows which for me is a step backwards
 compared to working with workspaces in Pharo 3.0

 What is necessary to provide this for the Playground so we have a
 common behavior for all the tools and a cleaner desktop?

 Thanks
 T.







 --
 www.tudorgirba.com

 Every thing has its own flow

Re: [Pharo-dev] Metacello: Possible to detect updates in a Github repo ?

2015-01-28 Thread kilon alios

Thank you both, looks like this one will need some extra work from my part.
I will have to postpone it for now because its not a a high priority as
other things I planned but will definetly take a look at your pointers Dale
and Serge links ASAP at least to get an idea about the direction I will be
going with this.

[Pharo-dev] Metacello: Possible to detect updates in a Github repo ?

2015-01-27 Thread kilon alios

I was wondering how possible it is to check a github repo for new commits
and compare it with the existing code to based on the Baseline loading of a
Github repo to Pharo. Is it possible ?

I want to make an updater for my project that will pop up a dialog to alert
the user for new updates in my Github repo.

Does a Baseline have access to git commits and their time/date signature ?

By the way Dale forgot to reply previously that I am definetly checking out
git tags as you suggested.

Re: [Pharo-dev] The Pharo Morphic book

2015-01-24 Thread kilon alios

I absolutely agree that incremental is the way to go, I am slow doer anyway
;)

On Sat, Jan 24, 2015 at 9:26 PM, stepharo steph...@free.fr wrote:


 Le 19/1/15 22:21, kilon alios a écrit :

 Ok then I think the best way to do this is to start this in my own github
 account then give you guys the link , review the documentation and if you
 find satisfying add it to SquareBracketAssociates via forking it, if not I
 can still continue it with my github account. Of course I will use pillar
 and follow the same workflow as PBE. I don't want to do this via blog posts
 , I prefer pillar and github.

 We can create a repo on


  PBE wise looks like from what I see from a first look that 12 out 16
 chapters are ported. So PBE is near completion at least at a draft level. I
 can give a hand with a couple more chapters thats not a big deal.

 Thanks. We will have to read it again. I have to check (I got stuck in the
 model chapter and the first one).

  There is no Pharo book for Morphic and for me this is a big omission.
 Frankly I would take even a small docs about Morphic and Pharo 3/4 over no
 documentation at all, any day.


 Sure
 Just read what I said.
 Go incremental.

  I am not saying that you should contribute to a Morphic book I mean this
 is your choice but its something I want to work on. If people want to
 contribute all they have to do is fork my repo and send me pull requests or
 even add them as contributors. If they dont want, no problemo I continue
 alone.

  In any case when I have something substantial (something more than 30
 pages) I will alert the list.

 On Mon, Jan 19, 2015 at 10:31 PM, stepharo steph...@free.fr wrote:


  Hello people, I am really interested since PBE seems to go very well to
 now concentrate on a project I had in mind for some time and it is to start
 a book on Pharo Morphic.


  I would start small and for example as a series of blog posts.
 Then we you reach a certain amount I would then turn them into a book.

 For Spec we plan to collect all the material and have a small booklet.


 My plan is to add it to github group SquareBracketAssociates which I am
 member of for contributing to the new PBE.

 Is that ok with you ?


  it is ok but now the strategy I adopted is the following one:
 - avoid to have many unfinished books (or many not making progress or
 slow progress)
 - this is why I have work in progress to work on the chapters, ready
 for reviews then the chapters will populate the books
 - this way I do not give the impression that Pharo is starting stuff
 and not finishing
 - I would suggest the same: host some chapter in the work in progress
 and when you enough push that to a book.

 I finished an editorial pass on deep into pharo and will continue to work
 on Pharo by example, then resume my work on
 the other books (slow is n't it :)).


 I will try to port all documentation available already for Morphic from
 self and squeak to Pharo 4 and of course add my own pages as well.

  There is not much available, or exciting but you can start there.


  I also have forgot my travis password, I have asked here before but none
 replied, so if anyone can help me recover my password or create a new one
 or create a job for the project , I will appreciate it.


  travis I do not know.


 Obviously I want to make this project according to the guidelines of the
 community. So if you have suggestions fire away :)

 I would like this to be the official book on Morphic , I want it to be
 both a tutorial but also a reference book with more emphasis on the
 reference side. Probably will divide in into a Part 1 and a Part 2 where
 Part 1 is the tutorial and Part 2 is the reference.

 I dont expect to of course to do a ton of work and finish this book any
 time soon, but then something is better than nothing.

Re: [Pharo-dev] HELP WANTED: improve Dark Theme

2015-01-23 Thread kilon alios

I think roassal can do that

On Fri, Jan 23, 2015 at 2:05 PM, Esteban Lorenzano esteba...@gmail.com
wrote:


 On 23 Jan 2015, at 12:53, Torsten Bergmann asta...@gmx.de wrote:

 https://bugs.eclipse.org/bugs/show_bug.cgi?id=385003
 https://code.google.com/p/eclipse-svg-icons/


 cool!
 now I have to figure out how to display svg icons in pharo… but this is
 what I was looking for :)

 Esteban



 Gesendet: Freitag, 23. Januar 2015 um 12:24 Uhr
 Von: Sven Van Caekenberghe s...@stfx.eu
 An: Pharo Development List pharo-dev@lists.pharo.org
 Betreff: Re: [Pharo-dev] HELP WANTED: improve Dark Theme


 On 23 Jan 2015, at 12:03, Esteban Lorenzano esteba...@gmail.com wrote:

 Hi,

 The Dark Theme is a standard theme upcoming in Pharo4, but as you might
 noticed, is still far from perfect.
 I would like to take some actions on it but I do not have a lot of time
 this days, so I thought on asking for help :)

 What I think is needed?

 1) There are some bugs (for example in the search window, cmd+f in text
 panes)
 2) Icon-set is not prepared for dark backgrounds. Now, this is a problem
 in eclipse itself who didn’t had a dark-theme either until recently. Now, I
 know they added a dark-theme and a corresponding set of icons (a set that
 can be displayed correctly both in white and black backgrounds), but I
 cannot find the icons. So if someone knows where they are, I’ll gladly
 replace them.


 3) Fix spotter theming (currently ignores dark theme)

 I know in an ideal world we will have our own set of icons, but that
 requires a lot of effort and design talent… so in the mean time, I think
 eclipse icons are doing a good job :)

 cheers,
 Esteban

Re: [Pharo-dev] WhatsUp from: 2015-01-19 until: 2015-01-31

2015-01-22 Thread kilon alios

great work, the Pharo documentation has been improving rapidly lately and
this is great news for me and any newcomer to pharo. Will definetly take a
look :)

On Tue, Jan 20, 2015 at 5:39 AM, Alexandre Bergel alexandre.ber...@me.com
wrote:

 - worked on Agile visualization. Several chapters have been added. Other
 have been reworked. Http://AgileVisualization.com

 - integrated openstreetmap to Roassal

 - improved Hapao, the test coverage tool we have

 Next week we will continue to work on AgileVisualization the book has to
 fly:)

 Alexandre



  Le 19 janv. 2015 à 03:00, seas...@rmod.lille.inria.fr a écrit :
 
  Hi! We're sending this automatic email twice a month, to give the
 community an opportunity to easily know what's happening and to coordinate
 efforts.  Just answer informally, and feel free to spawn discussions
 thereafter!
 
  ### Here's what I've been up to since the last WhatsUp:
 
  -
 $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS
 
  ### What's next, until 2015-01-31 (*):
 
  - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION
 
  (*) we'll be expecting results by then ;)

Re: [Pharo-dev] pharo-contribution CI out of space?

thanks Damien :)

On Tue, Jan 20, 2015 at 7:58 AM, Damien Cassou damien.cas...@gmail.com
wrote:


 kilon alios writes:

  you can remove my job a book I named Pharo Universe , I no longer need
 it,
  although it only contains the translated sound chapter which Stef has
  already copied to the other book. If I remember correctly it was inside
  Pharo-Contribution.

 done.

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

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

[Pharo-dev] The Pharo Morphic book

Hello people, I am really interested since PBE seems to go very well to now
concentrate on a project I had in mind for some time and it is to start a
book on Pharo Morphic.

My plan is to add it to github group SquareBracketAssociates which I am
member of for contributing to the new PBE.

Is that ok with you ?

I will try to port all documentation available already for Morphic from
self and squeak to Pharo 4 and of course add my own pages as well.

I also have forgot my travis password, I have asked here before but none
replied, so if anyone can help me recover my password or create a new one
or create a job for the project , I will appreciate it.

Obviously I want to make this project according to the guidelines of the
community. So if you have suggestions fire away :)

I would like this to be the official book on Morphic , I want it to be both
a tutorial but also a reference book with more emphasis on the reference
side. Probably will divide in into a Part 1 and a Part 2 where Part 1 is
the tutorial and Part 2 is the reference.

I dont expect to of course to do a ton of work and finish this book any
time soon, but then something is better than nothing.

[Pharo-dev] Pharo books and Pharo website

In Twitter I saw earlier this week a link posted for all books of Pharo ,
some new ones too. Is it possible to have this link also in the Pharo
website documentation section ?

I think it will look very good for pharo to expose to newcomers all the
hard work we are doing or have done with documentation.

Plus even if those books are not finished they are too useful to stay in
the dark.

Re: [Pharo-dev] The Pharo Morphic book