Re: [Pharo-dev] [ANN] Screencast on Versionner (Part 2)

[kilon alios]

thanks Esteban, very useful tutorial

On Thu, Apr 30, 2015 at 6:00 PM Esteban Lorenzano 
wrote:

> https://www.youtube.com/watch?v=SxTpuSHNh2E
>
> On 30 Apr 2015, at 16:48, stepharo  wrote:
>
>  esteban
>
> can you provide the link to the second videos?
>
> Stef
>
>
> Le 30/4/15 15:31, Esteban Lorenzano a écrit :
>
> Hi again,
>
>  Now I made a small video on how to use Versionner to help you manage
> your releases and commits.
>
>  https://youtu.be/cFRJDuWL-Q0
>
>  This is new stuff, so you will need latest Pharo 5 to use it,
> alternatively you can install latest Versionner into Pharo 4 (I don’t know
> how it will work on Pharo 3, you’ll probably need to load Glamour as well
> others).
> In Pharo 4, you can install it executing:
>
>  Gofer it
>  smalltalkhubUser: 'PharoExtras' project: 'Versionner';
>  configuration;
>  loadVersion: '2.12.2'.
>
>  cheers,
> Esteban
>
>
>
>
>

Re: [Pharo-dev] Release with Dark Theme

[kilon alios]

to find in the end that you get 
what you pay for ;)

On Fri, Apr 24, 2015 at 4:43 PM Esteban Lorenzano 
wrote:

> icon design and web design are two very different things.
> I seriously doubt we can get the icon set we need as cheap as you might
> think.
>
> but… we can always try :)
>
> Esteban
>
> On 24 Apr 2015, at 14:55, p...@highoctane.be wrote:
>
>
>
> On Fri, Apr 24, 2015 at 2:33 PM, stepharo  wrote:
>
>>
>>
>> Le 24/4/15 11:06, p...@highoctane.be a écrit :
>>
>>
>>
>> On Fri, Apr 24, 2015 at 9:45 AM, Sven Van Caekenberghe 
>> wrote:
>>
>>> That's a bit harsh, the fonts are the same ;-)
>>> And it is of course possible that you don't like it, it is a matter of
>>> taste.
>>> The contrast thing is also taste, but for some people it solve certain
>>> vision problems.
>>>
>>> Exactly.
>> When you have floaters all day long, the last thing you want is a f*cking
>> white screen.
>>
>> Now, I am using 3.0 with DawnTheme, which is more like SublimeText (in a
>> 3.0).
>>
>> I tried the 4.0 and it is nice. Now, icons should get a pass because the
>> artefacts on the edges are not nice.
>>
>> If there is some little petty cash available, that's the kind of job that
>> can be done supercheap on something like https://en.99designs.be/. That
>> would be good use of consortium/association money for example.
>>
>> Why bother with graphics work when you can get things done professionaly
>> for close to nil?
>>
>>
>> do you know the people?
>> Because I would really be in favor getting people doing this job.
>>
>
> This is a large community.
>
> One can get a full website design done for around $500.
> Got that done and was nice work.
>
> Alternatives (used too): https://www.freelancer.com/
>
> Phil
>
>>
>>
>> Phil
>>
>>
>>
>>
>>
>>
>>
>>> > On 24 Apr 2015, at 09:27, Norbert Hartl  wrote:
>>> >
>>> > That's funny because I tried it two days ago the first time and I
>>> didn't like it. I had troubles to get anything but bitmap fonts. After
>>> setting all things up I was a bit disappointed that contrast wise it
>>> doesn't work for me. Can someone send a screenshot with one setup that
>>> he/she considers good?
>>> >
>>> > thanks,
>>> >
>>> > Norbert
>>> >
>>> >> Am 24.04.2015 um 08:38 schrieb Esteban Lorenzano >> >:
>>> >>
>>> >> I disagree… DarkTheme is just for certain tastes, while regular one,
>>> while probably dated, is more “standard”.
>>> >> Also, DarkTheme is not ready. yeah, yeah… it works and works fine
>>> most of the time… but not *all* the time (take for example find string
>>> dialog… I never found the time to fix it, and nobody complained so… :P).
>>> Finally. we need to adopt SVG icons (in my TODO list since a couple of
>>> months, I will deliver soon, I hope), otherwise they do not look good (this
>>> is a problem eclipse itself had it… we are just inheriting it :) )
>>> >>
>>> >> But a good question would be: How can we push forward our UI, besides
>>> using a darker or clearer theme?
>>> >> I would like to hear some opinions here :)
>>> >>
>>> >> Esteban
>>> >>
>>> >>
>>> >>> On 24 Apr 2015, at 08:33, stepharo  wrote:
>>> >>>
>>> >>> comments about color is to be taken with care.
>>> >>>
>>> >>>
>>> >>> Le 24/4/15 02:48, Sean P. DeNigris a écrit :
>>>  Why didn't/don't we make it the default for 4.0? Everyone seems to
>>> love it,
>>>  and people are commenting that the UI looks dated.
>>> 
>>> 
>>> 
>>>  -
>>>  Cheers,
>>>  Sean
>>>  --
>>>  View this message in context:
>>> http://forum.world.st/Release-with-Dark-Theme-tp4821496.html
>>>  Sent from the Pharo Smalltalk Developers mailing list archive at
>>> Nabble.com.
>>> 
>>> 
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >
>>> >
>>
>>
>

Re: [Pharo-dev] Release with Dark Theme

[kilon alios]

The No1 thing that bothered me with Pharo was its white theme, found it
both horrible (yes much worse than Squeak) and very tiresome for my eyes.
Even worse was the white theme of Moose which made it impossible or really
hard to see scrollbars , for me, so it was also a problem of contrast not
just color.

Moving to Dark theme , fundamentally changed my experience with Pharo and
made coding much more relaxing. Then I decided to go one step further and
implement my own theme, a dark blue theme and add to it a gui tool to allow
for full customisation of colors (the theme with the tool are available
from configuration Browsers with the name Nireas). Blue is my favorite
color afterall, reminds me of sea, relaxing and full of positive energy.

In the end it comes down to what you like and what you find more enjoyable
to work with. For me it played a small role that the Dark theme is a new
thing with its own set of problem since the change of colors had such a
profound effect on my experience with Pharo.

I cannot imagine myself going back to the default theme, ever.

I would love to see more themes in the future, pink, yellow, brown, green
and much more.

On Fri, Apr 24, 2015 at 11:52 AM Stephan Eggermont  wrote:

> On 24/04/15 01:48, Sean P. DeNigris wrote:
> > Why didn't/don't we make it the default for 4.0? Everyone seems to love
> it,
> > and people are commenting that the UI looks dated.
>
> The advantages of a dark theme:
> - works well for photo/video apps where you don't want extra (colored)
> light;
> - works well in a dark environment;
> - provides little blue light, so doesn't influence sleep;
> - works for certain eye problems;
> don't apply to me much.
> I find reducing eye stress for me is mostly a question
> of adding more ambient light (also works well for my mood).
> In a light environment a light theme works much better.
>
> Stephan
>
>
>
>

Re: [Pharo-dev] ARM Cogit

[kilon alios]

Yes , yes , yes , would love to have Pharo available on Android and use
it on my smartphone on a daily basis , thank you very much guys.

On Wed, Apr 22, 2015 at 9:42 PM Eliot Miranda 
wrote:

> Hi All,
>
> thanks to hard work by Tim Rowledge and Lars Wasserman we now have a
> functional JIT for the ARM in the simulator.  We're still probably some
> weeks away from a functional ARM JIT VM; issues like instruction cache
> flushing on real hardware can be tricky to solve.  But we're at least ready
> to start trying to compile the JIT VM for ARM.  Doug, see that I added a
> build directory for build.linux32ARM/squeak.cog.spur.  Hopefully a fast VM
> for Raspberry Pi and Android is only a few weeks away.
>
> --
> best,
> Eliot
>

Re: [Pharo-dev] QualityAssistant v0.4

[kilon alios]

There is a solution that I was thinking when I was imagining implementing
my own Configuration Browser than I named "Tartara". One of the ideas I had
was the introduction of packages, which is basically something that would
trigger the installation of multiple projects at the same time. So I was
imaging "Core" package that will contain all the core IDEs, "GT" package
all the GT tools , "Games" where there will be multiple games etc.

This way the user would not need to install those tools one by one. Ideally
I was also imagining a detailed description per package with even the
ability to rate the quality of the package or even review it .

>From the looks of it this is already possible with Configuration Browser
but it does not provide this separation yet.

On Wed, Apr 22, 2015 at 11:18 PM Sean P. DeNigris 
wrote:

> stepharo wrote
> > NO NO NO integration in the image.
> > NO external tools to talk to. NO NO NO Change your mindset.
>
> I was actually thinking specifically of new users. I already know how to
> load it and make extensive use of startup preferences so it doesn't really
> matter to me. But it's taken me 5 years to find all the cool extensions I
> use routinely. How will a new user appreciate our Ferrari when we give it
> to
> them without paint, headlights, or seats? Maybe we can have something like
> Edgar's FunSqueak, with all the cool IDE features, be the default download,
> but then, if we're not all using that image, we may commit a sin similar
> Marcus' repeated warning that "the artefact on the build server needs to be
> the artefact of release" of using a different image than we release...
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context:
> http://forum.world.st/QualityAssistant-v0-4-tp4821070p4821265.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] [Moose-dev] QualityAssistant v0.4

[kilon alios]

you definetly got feedback from me with one feature request you did not
reply ;)


On Wed, Apr 22, 2015 at 2:00 PM Yuriy Tymchuk  wrote:

> I am definitely interested in it. Let me know what I should do for this.
>
> I haven’t got a lot of feedback from users, but I fixed problems reported
> by my group and Alex Bergel. The remaining reported issues are quite minor
> and related to how SmallLint works. Changes to SmallLint will arrive later
> after I figure out what the rules are about and what is the way to improve
> them.
>
> Cheers,
> Uko
>
>
> On 22 Apr 2015, at 12:23, Esteban Lorenzano  wrote:
>
> this is so good.
> what about integrate it to Pharo?
>
> cheers,
> Esteban
>
> On 22 Apr 2015, at 08:58, Yuriy Tymchuk  wrote:
>
> Hi everyone!
>
> Probably most of you know, that I am developing a tool called
> QualityAssistant, which displays current critics about your code in
> SystemBrowser, Inspector and Spotter.
>
> I’m happy to tell you that there is a new release v0.4 which does not
> require you to do any previous setup! Just load it from configuration
> browser (pharo 4 & 5) and it will start giving you feedback. More details
> can be found here:
> https://github.com/Uko/QualityAssistant#quality-assistant-beta-. If you
> are upgrading from older version, it is recommended to load
> QualityAssistant into a fresh image, because multiple announcement and
> process changes may cause exceptions in old objects.
>
> Even if you are an experienced programmer you can find QualityAssistant
> useful for instantly spotting typos or making sure that you didn’t forget
> some details about your code.
>
> Please give me a feedback about your experience, as I want to make it even
> more useful. Either write me an email, or open an entry at:
> https://github.com/Uko/QualityAssistant/issues
>
> Have a nice week!
> Uko
>
> 
>
>
> ___
> Moose-dev mailing list
> moose-...@iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
>

Re: [Pharo-dev] WhatsUp from: 2015-04-20 until: 2015-04-30

[kilon alios]

I have been working on MorphicDoc , which is documentation about Morphic
inside the image. Still studying Morphic and trying to figure things out.
More to come :)

On Wed, Apr 22, 2015 at 8:32 AM Tudor Girba  wrote:

> Could JB describe the problem with Metacello? Perhaps there is a
> workaround.
>
> Doru
>
> On Tue, Apr 21, 2015 at 3:27 PM, stepharo  wrote:
>
>>
>>  Hi phil

 just that you know what we are doing

  - Mathieu Lacatou an intern from Thales should be visiting the
 team for
 10 days to pair program with esteban
  about the OSWindow multi-windowing support

  - JB and Merwan are extending the OSWindow touch support, like
 generating scroll events

  - JB is working on Woden and adding some shadders for 3D demoes.

>>> I will have a new guy from Senegal starting to work tomorrow in my lab
>>> on using GPU and Wooden for doing SPH&epidemiological modeling.
>>> How to coordinate all these activities ?
>>>
>>
>> Cool :)
>> I do not know
>> For now he should have a look at Woden, JB  planned to make a CI.
>> But he was blocked because of a bug in the old version of Metacello that
>> we use.
>> So as soon as Metacello is updated, JB can continue his build.
>>
>> Stef
>>
>>>
>>>
>>
>>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>

Re: [Pharo-dev] Improving the documentation model

[kilon alios]

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

[kilon alios]

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


On Wed, Apr 22, 2015 at 12:00 AM Nicolai Hess  wrote:

> 2015-04-21 22:47 GMT+02:00 kilon alios :
>
>> 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 > > 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 !!!

[kilon alios]

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  wrote:

>
>
> 2015-04-21 22:33 GMT+02:00 kilon alios :
>
>> 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] [Pharo5] All systems on go!

[kilon alios]

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 ?

On Tue, Apr 21, 2015 at 11:30 PM, Sean P. DeNigris 
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.
>
>

[Pharo-dev] PharoLauncher all white !!!

[kilon alios]

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

[kilon alios]

"I'm against GUIs for distributed version control for collaborating on
documentation. "

yes this is a valid concern this is why I also agree with what others have
said of a GUI toll that helps us write documentation but it exports it to
pillar so we can use easily version control with it.  Or maybe you mean you
are not satisfied with how git gui clients have been doing their job ?

"GUI Zealot yes, mouse Zealot definitely not."

Yeap I agree with this very much, I am using a 3d application, Blender and
as you can imagine relying on mouse is basically unthinkable because of how
extremely complex the UI is. I use mouse for editing polygons, I use a
wacom tablet for sculpting and I use keyboard shorcuts for ton of other
blender actions. 3d apps have ton of shortcuts out of necessity. But there
is a solution recently in the form of pie penus, those menus work  on
premise of leaving an open circle area for displaying what you operate on
and open around it icon based menus in circular layout. You can enter those
menus using mouse gestures (you can also optionally do it the traditional
way of clicking on the menus), that makes for very fast interaction as fast
as using key shortcuts. You can this way create mouse gesture combos to do
very complex actions and at the same time you have a visual feedback of
what you doing exactly something that shortcus lack. Those mouse gestures
dont require any clicking.

I think pie menus would work great for Pharo.




So there is a lot of room for UI ideas still and GUIs are still in an
infant state. Another idea I had recently it using a multi touch device
like smartphone or table as an interface used for operating Blender and
Pharo, something like a TV remote . This usage is popular with musicians
for controlling musical software.

Re: [Pharo-dev] Improving the documentation model

[kilon alios]

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

[kilon alios]

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 
wrote:

> On Tue, Apr 21, 2015 at 12:15 PM, Sean P. DeNigris 
> 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] [update 5.0] #50001

[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 
wrote:

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

Re: [Pharo-dev] pharo home page tagline

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

[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] Class comments rendered in Nautilus (through Pillar)

[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 
wrote:

>
> kilon alios  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] [ANN] Pharo 4.0 is released!

[kilon alios]

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

a minor mistake in the website

"Check the annonucement , and the
ChangeLogs

."

should be "announcement"

On Thu, Apr 16, 2015 at 12:29 PM, Esteban Lorenzano 
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] How to find versions of core packages?

[kilon alios]

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

version10: spec


On Wed, Apr 15, 2015 at 7:24 PM, Dmitri Zagidulin 
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)

[kilon alios]

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

[kilon alios]

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  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  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] Class comments rendered in Nautilus (through Pillar)

[kilon alios]

Just pop open the Configuration Browser and choose to install MorphicDoc. I
am now trying to understand how layout policies for morphs works which is
what I will be documenting next.

Your link feature is also very important for me because I am taking
advantage of the examples methods of Nautilus to provide an easy way for
people to run examples based on documentation , having a link makes my life
even easier.

Together with MorphicDoc its my desire to develop a secondary project I
have talked about in the past but did not have the confidence to pursue,
called "Prometheas". I was thinking 2 things for the near future a) Better
Pillar support for help tool (it already support very basic pillar)  ,
already your work makes my life a lot easier b) better integration with
GTSpotter for help tool.

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.

On Wed, Apr 15, 2015 at 7:27 PM, KasperOsterbye  wrote:

> Thanks Damien for putting this on the mailing list.
>
> A few words about the state of that Pillar-TextRenderer.
>
> The TextRenderer accepts at least the commands shown by the screenshot
> noted
> by Damien. In addition I would like to point to a special link type I
> added:
> *LinkText>pharo://Classname[/methodname]* which will render a link which
> when clicked will open a new Nautilus browser on said class and method.
> (I think that link syntax migh actually be useful in both the HTML and
> Latex
> Pillar exporters as well, perhaps just extracting the source and inserting
> it inline in the produced document. - but perhaps that is already done
> using
> some other feature I overlooked).
>
> I am rather overwhelmed by the PluggableTextView and other TextMorphs, so
> please understand that the supplied functionality is most likely not the
> right way to do this, but it seems to work.
>
> And Kilon, you are more than welcome to contact me and introduce me to this
> project of yours. As new to the morphic system I can tell you that
> documentation is really needed here.
>
> -- Kasper
>
>
>
> --
> View this message in context:
> http://forum.world.st/Class-comments-rendered-in-Nautilus-through-Pillar-tp4819726p4819735.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

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

[kilon alios]

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

[kilon alios]

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  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 RemoteString>>string in Block: [ ...
> BlockClosure>>ensure:
> RemoteString>>string
> ClassOrganization>>comment
> ClassOrganization>>classComment
> [ :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
> SystemNavigation>>allMethodsWithSourceString:matchCase: in Block: [ :each |
> ...
> [ :aClass |
> aBlock
> value: aClass;
> value: aClass class ] in SystemNavigation>>allBehaviorsDo: in Block: [
> :aClass | ...
> [ :name | aBlock value: (self at: name) ] in
> SystemDictionary>>allClassesDo: in Block: [ :name | aBlock value: (self at:
> name) ]
> OrderedCollection>>do:
> SystemDictionary>>allClassesDo:
> SystemNavigation>>allBehaviorsDo:
> [ :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
> SystemNavigation>>allMethodsWithSourceString:matchCase: in Block: [ :bar |
> ...
> BlockClosure>>cull:
> [ result := block cull: self ] in [
> self prepareForRunning.
> [ result := block cull: self ]
> on: JobNotification
> do: [ :notification | notification handle: self ] ] in Job>>run in
> Block: [ result := block cull: self ]
> BlockClosure>>on:do:
> [
> self prepareForRunning.
> [ result := block cull: self ]
> on: JobNotification
> do: [ :notification | notification handle: self ] ] in Job>>run in
> Block: [ ...
> BlockClosure>>ensure:
> Job>>run
> MorphicUIManager(UIManager)>>displayProgress:from:to:during:
> ByteString(String)>>displayProgressFrom:to:during:
> SystemNavigation>>allMethodsWithSourceString:matchCase:
> SystemNavigation>>browseMethodsWithSourceString:matchCase:
> [ :aPresentation |
> aPresentation selectLine.
> self systemNavigation browseMethodsWithSourceString: aPresentation
> selectedText matchCase: false ] in
> GLMPharoPlaygroundPresentation(GLMRubricSmalltalkCodePresentation)>>browsingSelectionActions
> in Block: [ :aPresentation | ...
> BlockClosure>>glamourValueWithArgs:
> GLMGenericAction(GLMAction)>>actOn:
> GLMGenericAction(GLMAction)>>morphicActOn:
> [ :ann | ann action morphicActOn: aPresentation ] in
> GLMMorphicPharoPlaygroundRenderer(GLMMorphicWidgetRenderer)>>installActionsOnModel:fromPresentation:
> in Block: [ :ann | ann action morphicActOn: aPresentation ]
> BlockClosure>>cull:
> BlockClosure>>cull:cull:
>
>

Re: [Pharo-dev] PetitMarkdown

[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 
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  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] why we removed debugTest from nautilus?

[kilon alios]

+1

On Sat, Apr 11, 2015 at 3:58 PM, Max Leske  wrote:

>
> On 11 Apr 2015, at 10:10, Nicolai Hess  wrote:
>
>
>
> 2015-04-10 17:28 GMT+02:00 Clément Bera :
>
>> Well I guess I used to click proceed and not close the debugger...
>>
>
>
> I don't know who is working on the breakpoint support and I don't know how
> long it will take.
> Maybe we can fix thie image freeze and re-include the debugtest code until
> the new breakpoint support.
>
> what do you think?
>
>
> I would love that. I know a couple of people who already complained about
> the test debug feature missing and I think that said feature is really an
> important point of the IDE. That being said, it will probably mean delaying
> the release another week or two. Then again, releasing something in a good
> state is better IMHO than releasing on time.
>
> Cheers,
> Max
>
>
>
>
>>
>> 2015-04-10 1:24 GMT-07:00 Max Leske :
>>
>> For a little more context: the issue was originally raised by Clara in
>>> the thread titled "MNU: receiver of "stepToCallee:" is nil”. IIRC the
>>> issue was easily reproducible when debugging a test, then closing the
>>> debugger (via the close icon). Clicking “Proceed” on the other hand
>>> gracefully terminated the process.
>>>
>>> Cheers,
>>> Max
>>>
>>>
>>> On 10 Apr 2015, at 09:56, Nicolai Hess  wrote:
>>>
>>> 2015-04-10 2:37 GMT+02:00 Clément Bera :
>>>
 I was using it frequently too and I have never experienced any issues...

>>>
>>> Ok, can you describe a use case, what test case you can start and
>>> close the debugger without image freeze?
>>>
>>> Maybe we can find what is the difference between that
>>> test case and  those that freeze the image, and than find a fix.
>>>
>>>

 2015-04-09 14:58 GMT-07:00 Nicolai Hess :


> 2015-04-09 23:38 GMT+02:00 p...@highoctane.be :
>
>> No Debug Tests?
>>
>> Geez, I am using that all the time.
>>
>
> And you're never encountered this issue 14689
> ?
> Or did this work in older versions?
>
>
>
>
>>
>> Phil
>>
>>
>> On Thu, Apr 9, 2015 at 10:21 PM, Marcus Denker <
>> marcus.den...@inria.fr> wrote:
>>
>>>
>>> > On 09 Apr 2015, at 22:32, Sean P. DeNigris 
>>> wrote:
>>> >
>>> > Nicolai Hess wrote
>>> >>
>>> http://forum.world.st/do-we-need-to-debug-testmethods-from-within-Nautilus-tp4805795.html
>>> >
>>> > Ah, I miss that too! From that thread, it seems it was removed
>>> temporarily
>>> > until we have real breakpoints. Is there an issue for its return?
>>> >
>>>
>>> Not yet.
>>>
>>> Marcus
>>>
>>
>>
>

>>>
>>>
>>
>
>

Re: [Pharo-dev] Contributing to Bloc

[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 
> To: Pharo Development List 
> 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  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  wrote:
>
>> 2015-04-06 10:22 GMT+02:00 kilon alios :
>>
>>> 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

[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 
> To: Pharo Development List 
> 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

[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  wrote:

> 2015-04-06 10:22 GMT+02:00 kilon alios :
>
>> 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 ?
>>
>
>

[Pharo-dev] Contributing to Bloc

[kilon alios]

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.

So how am I proceed ? How I can help ?

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

[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 
wrote:

> You might have to click on the Watch button on the repo.
>
>
> On Sunday, April 5, 2015, kilon alios  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 
>> 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 
>>> 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] New Pull Request for UpdatedPharoByExample

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

[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] UpdatedPharoByExample for 3.0, 4.0, 5.0

[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 
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] Pharo 4 Beta, first impressions

[kilon alios]

" 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

[kilon alios]

"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] Pharo 4 Beta, first impressions

[kilon alios]

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 
> To: Marcus Denker , 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 
> *To:* Benoit St-Jean ; 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 
> *Reply-To: *Benoit St-Jean 
> *To: *Pharo Development List 
> *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] Can we have basicRaw in GTInspector?

[kilon alios]

I did not know that, thanks

On Fri, Apr 3, 2015 at 12:39 PM, Esteban Lorenzano 
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  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] (a = b) ifTrue: []

[kilon alios]

its possible to completely or partly avoid a condition check . Instead you
can use a common name for a method for various objects , that method may
have different code for each object it belongs. This way you dont need to
check your data instead you send the message and you let the method itself
to execute the appropriate code for the approriate object( kind of data).

This also much more reasonable to read. It will depend however in your
particular situation. You can have also a chain of methods. Essentially we
talk here about objects that interact with each other by triggering methods
without the need for conditional checks since the method call is of the
same name but the code executed  depends on the receiver of the message /
messages.

It takes time to get used to this chain reaction message sending but I
think it really worth it because it produces far simpler code to read and
far more modular too.

On Thu, Apr 2, 2015 at 6:15 PM, Anne Etien 
wrote:

> Hi,
>
> I wanted to write a method that:
> - if (a = b) checks other conditions that are specified in the ifTrue
> block and return this (boolean) value
> - returns false if (a!=b)
>
> So I wrote:
> myMethod
> ^ (a=b) ifTrue: [ aBlockCheckingConditions].
>
> However, when (a!=b) the method returns nil (since false ifTrue: []
> returns nil). So do you have an idea how I can do to express that or should
> I mandatorily wrote also an ifFalse:?
>
> The problem comes certainly because we don’t know that the ifTrueBlock
> will return a boolean.
>
> If you have prettier ideas, I am interested in.
>
> Anne
>

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

[kilon alios]

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  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  wrote:
> >
> >
> > 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!

[kilon alios]

My opinion :

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

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

[kilon alios]

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

[kilon alios]

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

[kilon alios]

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] Improving communication and roadmap

[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  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 
> 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] SmalltalkHub "Watch this project" is not working for me

[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  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] [IMPORTANT] Release will be delayed one week. PLEASE TEST!

[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 
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] [ANN] Quality Assistant: live code critics feedback

[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 
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] New Pharo-Launcher package for Mac and Windows

[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 
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] Existing

[kilon alios]

+1
couldn't agree more :)

On Thu, Mar 26, 2015 at 1:06 PM, Esteban Lorenzano 
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  wrote:
> >
> > Hi Tudor,
> >
> >> We will rename  back to  and keep the API as it is.
> That will leave Pharo 4 with one  method while the other 100 will
> >use . 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  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  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  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  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
> >   
> >
> >   ^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 :
> >
> > 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

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

[kilon alios]

very useful thanks Tudor :)

On Thu, Mar 26, 2015 at 1:47 AM, Tudor Girba  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  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] Fuel issue tracker now on github

[kilon alios]

Welcome to the dark side of the fork.

On Tue, Mar 24, 2015 at 9:03 PM, Max Leske  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

[kilon alios]

Just for your information Bloc already has 150 methods using the 
pragma. Most likely there are other libraries out there using it as well. I
also suspect since this is new and not documented  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  wrote:

> Hi Torsten,
>
> We will rename  back to  and keep the API as it is.
> That will leave Pharo 4 with one  method while the other 100 will
> use . 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  wrote:
>
>> stepharo wrote:
>> >I'm confused. Did you use the  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
>> 
>>  ...
>>
>> 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  and unfortunately changed this to
>> 
>> 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  or just .
>>
>> 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 ,  and  to
>>  and  and 
>>   - 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  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] could the size of Playground be reduced a bit

[kilon alios]

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  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] Existing

[kilon alios]

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] Existing

[kilon alios]

Hey guys since we talk about the  pragma, I wanted to thank the
implementors of this very useful feature. I was testing Bloc and it comes
with loads of examples using this pragma and has been extremely convenient.
Definitely will be using it with my code too. I was not ware of 

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

[kilon alios]

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

Re: [Pharo-dev] Update question

[kilon alios]

"@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  wrote:

>
> > Am 24.03.2015 um 13:02 schrieb Sean P. DeNigris :
> >
> > 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

[kilon alios]

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 
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] Google Code Shutdown

[kilon alios]

Another project abandoned by Google, what a surprise :D

On Tue, Mar 24, 2015 at 3:14 PM, Sean P. DeNigris 
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?]

[kilon alios]

"
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] Which one to use? [WAS: Re: GLMBrick whats next?]

[kilon alios]

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 
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  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  wrote:
>
>>
>>
>> 2015-03-23 20:54 GMT+0

Re: [Pharo-dev] Update question

[kilon alios]

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  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] UI Workflows Are Like Snowflakes

[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  wrote:

> On Mon, Mar 23, 2015 at 3:15 PM, kilon alios 
> 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

[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

[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] Color arithmetical operations are broken

[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 
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 
> wrote:
>
>>
>> On 22 Mar 2015, at 13:35, Nicolai Hess  wrote:
>>
>>
>>
>> 2015-03-22 12:43 GMT+01:00 Nicolai Hess :
>>
>>>
>>>
>>> 2015-03-21 15:51 GMT+01:00 Eliot Miranda :
>>>
 Why not take the average of alpha in all cases?

 Eliot (phone)

 On Mar 21, 2015, at 6:32 AM, Aliaksei Syrel 
 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] update of pharo by example?

[kilon alios]

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

[kilon alios]

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

[kilon alios]

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  wrote:

> Also, thread hijacking. :)
>

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

[kilon alios]

"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?

[kilon alios]

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

[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 
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  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] update of pharo by example?

[kilon alios]

I definitely know how that feels ;)

On Thu, Mar 12, 2015 at 4:51 PM, stepharo  wrote:

>  I feel alone with damien... :)
> We are making progress but slowly
>
> Stef
>
> Le 10/3/15 20:13, Alexandre Bergel a écrit :
>
> 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
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

Re: [Pharo-dev] Debugging red screen

[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  wrote:

>
> > On 11 Mar 2015, at 17:15, Natalia Tymchuk 
> 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.
> >
> >  
> >
> >
>
>
>

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

[kilon alios]

AT LAST!!!

Thank you Esteban :)

On Tue, Mar 10, 2015 at 10:33 PM, Torsten Bergmann  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" 
> > An: "Pharo Development List" 
> > 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] Pharo code of conduct?

[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] GitHub = Communication

[kilon alios]

My favorite is that one can open an issue for a bug or a missing
feature and then attach a pull request to that issue with the code
that resolves this issue. I also like that github gives you the
ability to create a website for the project which is also managed by
github (the website) as a separate branch of the project.



On 3/9/15, Sean P. DeNigris  wrote:
> I am continuing to use SmalltalkHub for most of my development, but
> sometimes
> GitHub's social coding features are outrageously helpful. Check out these
> code reviews I was able to give to a GSoC student. After loading his code
> in
> moments by pasting the GitHub URL into GitFileTree, we were commenting on a
> pull request line by line, bringing us both visually straight to the most
> important points! This is so much easier than e.g. via email, where I have
> to cut and paste snippets to quote for each change/comment.
>
> https://github.com/rohitsukhwal/HelloWorld/pull/1
> https://github.com/rohitsukhwal/Calculator/pull/1
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context:
> http://forum.world.st/GitHub-Communication-tp4810542.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

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

[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 
wrote:

>
> On 07 Mar 2015, at 00:02, Nicolai Hess  wrote:
>
> 2015-03-06 20:18 GMT+01:00 Esteban Lorenzano :
>
>>
>> On 06 Mar 2015, at 18:40, kilon alios  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

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

[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  wrote:

>
>
> 2015-03-06 18:40 GMT+01:00 kilon alios :
>
>> 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 > > 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  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 :
>>> > 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" 
>>> > An: "Pharo Development List" , "Any
>>> question about pharo is welcome" 
>>> > 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
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>>
>>
>

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

[kilon alios]

Ah thats great news Esteban, 70% to 9% is more than enough for my needs. I
can wait a year, no problemo.

This is all optimised inside VM ? Or you plan to bring those optimizations
also inside the image ? SDL2 is a very powerful lib and a very wise move to
move to it. Not just for 2d graphics, but also 3d, events and so much more.

On Fri, Mar 6, 2015 at 9:18 PM, Esteban Lorenzano 
wrote:

>
> On 06 Mar 2015, at 18:40, kilon alios  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 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.
> 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 
> 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  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 :
>> > 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" 
>> > An: "Pharo Development List" , "Any
>> question about pharo is welcome" 
>> > 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
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>
>

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

[kilon alios]

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

On Fri, Mar 6, 2015 at 6:28 PM, Alexandre Bergel 
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  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 :
> > 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" 
> > An: "Pharo Development List" , "Any question
> about pharo is welcome" 
> > 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

[kilon alios]

This link is dead


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

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

[kilon alios]

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

On Thu, Feb 26, 2015 at 5:10 PM, Andrei Chis 
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

[kilon alios]

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

[kilon alios]

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  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 
> wrote:
>
>>
>>
>> On Fri, Feb 27, 2015 at 12:35 PM, Tudor Girba 
>> 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

[kilon alios]

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 
wrote:

>
> On 27 Feb 2015, at 13:24, kilon alios  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 
> wrote:
>
>>
>>
>> On Fri, Feb 27, 2015 at 12:35 PM, Tudor Girba 
>> 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

[kilon alios]

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 
wrote:

>
>
> On Fri, Feb 27, 2015 at 12:35 PM, Tudor Girba 
> 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

[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  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 :
>
>>  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  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 :
>>
>>>
>>>
>>> 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] ||

[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] ||

[kilon alios]

"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] [squeak-dev] Re: ||

[kilon alios]

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  wrote:

>
> > Am 07.02.2015 um 16:18 schrieb David T. Lewis :
> >
> > On Thu, Feb 05, 2015 at 01:54:51PM +0100, Marcus Denker wrote:
> >>
> >>> On 05 Feb 2015, at 10:12, Marcus Denker 
> wrote:
> 
>  On 05 Feb 2015, at 10:04, Marcus Denker 
> 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] ||

[kilon alios]

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 :
>
>> 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 :
>>>
>>>> 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 alios]

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 
wrote:

>
>
> 2015-02-06 22:00 GMT+01:00 stepharo :
>
>> 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] Spotter & exact match

[kilon alios]

+1


On Thu, Feb 5, 2015 at 2:46 PM, Ben Coman  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 "doit did an exact match.
>
> cheers -ben
>

Re: [Pharo-dev] ||

[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 
wrote:

>
>
> 2015-02-05 11:14 GMT+01:00 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.
>>
>
> Which means if I see you complaining of speed issues, then it must be
> really bad :)
>
> Thierry
>

Re: [Pharo-dev] ||

[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  wrote:

>
> > On 05 Feb 2015, at 10:46, Thierry Goubier 
> wrote:
> >
> >
> >
> > 2015-02-05 10:12 GMT+01:00 Marcus Denker :
> >
> > > On 05 Feb 2015, at 10:04, Marcus Denker 
> wrote:
> > >
> > >
> > >> On 04 Feb 2015, at 22:04, Levente Uzonyi  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?

[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 
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.
>
>