Re: [Pharo-dev] XPath chapter...

[J.F. Rick]

Nice!

On Sun, Oct 22, 2017 at 11:53 PM Hernán Morales Durand <
hernan.mora...@gmail.com> wrote:

> I don't know for Pharo development, but I used XPath in Pharo for
> getting a textual description of gene ontology terms, for example:
>
> #('GO:0005623' 'GO:0017071' 'GO:0030680') do: [ : goTerm |
> | xPath xmlDoc quickGO |
> quickGO := '
> http://www.ebi.ac.uk/QuickGO-Old/GTerm?id={1}=oboxml'
> format: { goTerm }.
> xmlDoc := (XMLDOMParser on: (ZnEasy get: quickGO) contents)
> parseDocument.
> xPath := XPath for: 'normalize-space(/obo/term/name/text())' in:
> xmlDoc.
> Transcript show: goTerm; tab; show: xPath; cr ].
>
> Here you've got similar code in Perl and Java so you can compare:
>
> https://www.ebi.ac.uk/QuickGO-Old/clients/download-term.pl
> https://www.ebi.ac.uk/QuickGO-Old/clients/DownloadTerm.java
>
> Best regards,
>
> Hernán
>
>
>
> 2017-10-21 14:04 GMT-03:00 J.F. Rick <s...@je77.com>:
> > NICE! I was just using XPath for Selenium testing. It is really great for
> > that application (commanding a browser like Firefox or Chrome to simulate
> > user actions). What are the applications for XPath in Pharo? Unit
> testing of
> > generating markup?
> >
> > Cheers,
> >
> > Jeff
> >
> > PS After spending significant time with other languages at work, I really
> > have an appreciation of how wonderful Pharo is as a development
> environment.
>
>

Re: [Pharo-dev] XPath chapter...

[J.F. Rick]

NICE! I was just using XPath for Selenium testing. It is really great for
that application (commanding a browser like Firefox or Chrome to simulate
user actions). What are the applications for XPath in Pharo? Unit testing
of generating markup?

Cheers,

Jeff

PS After spending significant time with other languages at work, I really
have an appreciation of how wonderful Pharo is as a development environment.

Re: [Pharo-dev] [ANN] Material Design For Seaside V1.0.0

[J.F. Rick]

Lovely. Something's not quite working with the Menus example on Chrome
Ubuntu. I always get the same menu.

Cheers,

Jeff

On Fri, Sep 23, 2016 at 10:48 AM Christophe Demarey <
christophe.dema...@inria.fr> wrote:

>
> > Le 23 sept. 2016 à 16:21, Cyril Ferlicot D. 
> a écrit :
> >
> > Le 23/09/2016 à 15:53, Christophe Demarey a écrit :
> >> Cool!
> >> Could you share a picture of the widgets by email or put it in the
> GitHub README?
> >>
> >> Thanks,
> >> Christophe
> >>
> >
> > Oups, I made "respond" instead of "respond to all".
> >
> > You can find the demo here:
> > http://eph-b922e2d9.swarm.pharocloud.com/MDLComponentsDemoApplication
>
> Better than a picture. Thanks Cyril.
> An overview of what future native widgets in Pharo could be with Bloc /
> Brick :p
>

[Pharo-dev] Error: cannot create OS pipe

[J.F. Rick]

I've been using CommandShell for some operations on OSX with Pharo5. After
doing a number of "PipeableOSProcess command:" calls (~150), I get an error
inside ExternalPipe:makePipe. For my purposes, I can get around this by
restarting Pharo and limiting the number of operations each session. But,
it is an indication that some resource is not getting freed when the
PipeableOSProcess is deleted (garbage collected). I just thought I'd
mention the bug.

Cheers,

Jeff

Re: [Pharo-dev] Athens Font Rendering Bug

[J.F. Rick]

Thanks. It is working nicely.

On Wed, Jul 20, 2016 at 3:32 PM Nicolai Hess <nicolaih...@gmail.com> wrote:

> 2016-07-20 20:46 GMT+02:00 J.F. Rick <s...@je77.com>:
>
>> Cool. What should I use? Is this useful:
>> http://www.tudorgirba.com/blog/free-font-collection-for-pharo
>>
>
> Any FreeType font, the builtin (Source Sans Pro/ Source Code Pro) or a
> font from your system (after loading all available fonts).
>
> | font boldFont italicFont |
> font := LogicalFont familyName: 'Source Sans Pro' pointSize: 18.
> boldFont := (LogicalFont familyName: 'Arial' pointSize: 18) emphasized:
> TextEmphasis bold emphasisCode.
> italicFont := (LogicalFont familyName: 'Times New Roman' pointSize: 18)
> emphasized: TextEmphasis italic emphasisCode.
> TextMorph new
> contents: (Text initialFont: font stringOrText: 'normal'), (Text
> initialFont: boldFont stringOrText: 'bold'), (Text initialFont: italicFont
> stringOrText: 'italic');
> openInSceneView
>
>
>>
>> On Wed, Jul 20, 2016 at 2:16 PM Nicolai Hess <nicolaih...@gmail.com>
>> wrote:
>>
>>> Do not use StrikeFont with athens
>>>
>>> Am 20.07.2016 7:49 nachm. schrieb "J.F. Rick" <s...@je77.com>:
>>>
>>>> It seems that emphasis is also not respected in Athens. If I try the
>>>> following, it works in BitBlt, but both are rendered as plain inside 
>>>> Athens.
>>>>
>>>> | font boldFont |
>>>> font := StrikeFont familyName: 'Arial' pointSize: 18.
>>>> boldFont := StrikeFont familyName: 'Arial' pointSize: 18 emphasized:
>>>> TextEmphasis bold emphasisCode.
>>>> TextMorph new
>>>> contents: (Text initialFont: font stringOrText: 'test'), (Text
>>>> initialFont: boldFont stringOrText: 'this');
>>>> openInHand
>>>>
>>>>>

Re: [Pharo-dev] Athens Font Rendering Bug

[J.F. Rick]

It seems that emphasis is also not respected in Athens. If I try the
following, it works in BitBlt, but both are rendered as plain inside Athens.

| font boldFont |
font := StrikeFont familyName: 'Arial' pointSize: 18.
boldFont := StrikeFont familyName: 'Arial' pointSize: 18 emphasized:
TextEmphasis bold emphasisCode.
TextMorph new
contents: (Text initialFont: font stringOrText: 'test'), (Text initialFont:
boldFont stringOrText: 'this');
openInHand

>

Re: [Pharo-dev] Athens Font Rendering Bug

[J.F. Rick]

Interesting. Why is it then correct in BitBlt rendering and not correct in
Athens rendering? Does this mean it can be fixed at the Smalltalk level? If
so, give me a hint of where to look and I'll see if I can find a solution.

Cheers,

Jeff

On Sun, Jul 10, 2016 at 1:12 PM Aliaksei Syrel <alex.sy...@gmail.com> wrote:

> Hi
>
> Actually it is not Athens bug. Problem is in string extent measurement
> done by text morph. Athens (Cairo in the end) only renders string glyphs
> created by FreeType2 on positions specified by someone else (morphic in
> this case).
>
> Cheers
> Alex
> On Jul 10, 2016 6:16 PM, "J.F. Rick" <s...@je77.com> wrote:
>
>> Perhaps other people have already reported this for Bloc but something is
>> wrong with the font rendering of Athens. Here's the code and how it is
>> rendered in Athens vs how it is rendered in BitBlt. It seems like Athens
>> adds more space between letters than is supposed to be there.
>>
>> tMorph := TextMorph new.
>> font1 := TextFontReference toFont: (LogicalFont familyName: 'Arial'
>> fallbackFamilyNames: nil pointSize: 28 stretchValue: 5 weightValue: 400
>> slantValue: 0).
>> font2 := (TextFontReference toFont: (StrikeFont familyName: 'Atlanta'
>> size: 11)).
>> t1 := 'this is font1' asText addAttribute: font1.
>> t2 := ' and this is font2' asText addAttribute: font2.
>> tMorph contents: (t1,t2).
>>
>> Cheers,
>>
>> Jeff
>>
>

[Pharo-dev] Athens Font Rendering Bug

[J.F. Rick]

Perhaps other people have already reported this for Bloc but something is
wrong with the font rendering of Athens. Here's the code and how it is
rendered in Athens vs how it is rendered in BitBlt. It seems like Athens
adds more space between letters than is supposed to be there.

tMorph := TextMorph new.
font1 := TextFontReference toFont: (LogicalFont familyName: 'Arial'
fallbackFamilyNames: nil pointSize: 28 stretchValue: 5 weightValue: 400
slantValue: 0).
font2 := (TextFontReference toFont: (StrikeFont familyName: 'Atlanta' size:
11)).
t1 := 'this is font1' asText addAttribute: font1.
t2 := ' and this is font2' asText addAttribute: font2.
tMorph contents: (t1,t2).

Cheers,

Jeff

Re: [Pharo-dev] Sound on Debian

[J.F. Rick]

Th vm-sound-pulse plugin packaged with the Squeak VM works on Ubuntu.

Cheers,

Jeff

On Fri, Jul 8, 2016 at 1:14 PM Dimitris Chloupis 
wrote:

> Was not able to make it work in Ubuntu either, for me it work only on MacOS
>
> On Fri, Jul 8, 2016 at 5:54 PM jannik laval 
> wrote:
>
>> Hi pharoers,
>>
>> I just tried sounds on phratch on Debian 8. It returns this message:
>>
>> sound_Start(default)
>> soundStart: snd_add_pcm_handler: Fonction non implantée
>>
>> Is it a problem known ?
>>
>> Here is my configuration:
>>
>> Image
>> -
>> /usr/lib/Phratch/shared/Pharo4.0.image
>> Pharo4.0
>> Latest update: #40626
>> Unnamed
>>
>> Virtual Machine
>> ---
>> /usr/lib/Phratch/bin/pharo
>> NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid:
>> acc98e51-2fba-4841-a965-2975997bba66 May 15 2014
>> NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid:
>> acc98e51-2fba-4841-a965-2975997bba66 May 15 2014
>> https://github.com/pharo-project/pharo-vm.git Commit:
>> ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200
>> By: Esteban Lorenzano  Jenkins build #14826
>>
>> Unix built on May 15 2014 18:29:39 Compiler: 4.6.3
>> VMMaker versionString https://github.com/pharo-project/pharo-vm.git
>> Commit: ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04
>> +0200 By: Esteban Lorenzano  Jenkins build #14826
>> NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid:
>> acc98e51-2fba-4841-a965-2975997bba66 May 15 2014
>> NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid:
>> acc98e51-2fba-4841-a965-2975997bba66 May 15 2014
>>
>>
>> Cheers,
>> --
>> ~~Jannik Laval~~
>> Enseignant-chercheur
>> Responsable Pédagogique Licence Coordonnateur de Projet en Système
>> d'Information
>> IUT Lumière, Université Lyon Lumière
>> laboratoire DISP
>> http://www.jannik-laval.eu
>> http://www.phratch.com
>> http://www.approchealpes.info
>>
>

Re: [Pharo-dev] AthensCairoSurface not getting garbage collected

[J.F. Rick]

I don't have enough evidence either way, but the signs point to no since
the applications that crash are not ones that use form-based paints. I
assume they wouldn't be affected by the flush. We did have one crash on a
form-based one where it crashed after running for 10 hours. My guess is
that one ran out of memory. That crash is probably resolved. But, I'll keep
everybody informed as I work more on it.

Cheers,

Jeff


On Thu, Jul 7, 2016 at 3:28 AM Alexandre Bergel <alexandre.ber...@me.com>
wrote:

> Jeff, does this flush reduces the amount of crash you are experiencing?
>
> Alexandre
>
> > On Jul 6, 2016, at 9:01 PM, J.F. Rick <s...@je77.com> wrote:
> >
> > Nicolai,
> >
> > THANKS! That worked. I no longer have any AthensCairoCanvas hanging
> around after executing "CairoBackendCache flush".
> >
> > Cheers,
> >
> > Jeff
> >
> > On Sun, Jul 3, 2016 at 11:58 AM Nicolai Hess <nicolaih...@gmail.com>
> wrote:
> > Hi Jeff,
> >
> > if you use forms to paint on an AthensCairoCanvas, they are cached in
> the CairoBackendCache,
> > can you try to flush that cache whith
> > CairoBackendCache flush.
> >
> >
> > 2016-06-18 18:36 GMT+02:00 J.F. Rick <s...@je77.com>:
> > I'm using Athens rendering for my multi-touch applications on Pharo5. As
> part of that, I create a surface:
> > surface := AthensCairoSurface extent: bounds extent asIntegerPoint.
> >
> > Though the object creating that surface is deleted, the surface sticks
> around. So, each time I run the app, I get another instance of
> AthensCairoSurface hanging around. That means all the forms stick around as
> well. So my image can quickly grow towards the 1GB size.
> >
> >  Is there anything I can do about that? Can I manually get the surface
> to delete itself?
> >
> > Cheers,
> >
> > Jeff
> >
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

Re: [Pharo-dev] AthensCairoSurface not getting garbage collected

[J.F. Rick]

Nicolai,

THANKS! That worked. I no longer have any AthensCairoCanvas hanging around
after executing "CairoBackendCache flush".

Cheers,

Jeff

On Sun, Jul 3, 2016 at 11:58 AM Nicolai Hess <nicolaih...@gmail.com> wrote:

> Hi Jeff,
>
> if you use forms to paint on an AthensCairoCanvas, they are cached in the
> CairoBackendCache,
> can you try to flush that cache whith
> CairoBackendCache flush.
>
>
> 2016-06-18 18:36 GMT+02:00 J.F. Rick <s...@je77.com>:
>
>> I'm using Athens rendering for my multi-touch applications on Pharo5. As
>> part of that, I create a surface:
>> surface := AthensCairoSurface extent: bounds extent asIntegerPoint.
>>
>> Though the object creating that surface is deleted, the surface sticks
>> around. So, each time I run the app, I get another instance of
>> AthensCairoSurface hanging around. That means all the forms stick around as
>> well. So my image can quickly grow towards the 1GB size.
>>
>>  Is there anything I can do about that? Can I manually get the surface to
>> delete itself?
>>
>> Cheers,
>>
>> Jeff
>>
>
>

Re: [Pharo-dev] AthensCairoSurface not getting garbage collected

[J.F. Rick]

Are .dmp files useful? If so, I can share those. I do still get crashes but
they are far less since I only use one surface.

Another thing that is happening is that the form-based paints are sticking
around though the form should have been collected. It seems like the way
that paints are being handled is changing in Athens development. I tried
upgrading but that broke things. Is there a way I can be at the bleeding
edge and contribute back to the Athens development? I can't do anything on
the C side but I can contribute on the Smalltalk side.

Cheers,

Jeff

On Thu, Jun 23, 2016 at 7:11 AM Igor Stasenko <siguc...@gmail.com> wrote:

> On 18 June 2016 at 19:36, J.F. Rick <s...@je77.com> wrote:
>
>> I'm using Athens rendering for my multi-touch applications on Pharo5. As
>> part of that, I create a surface:
>> surface := AthensCairoSurface extent: bounds extent asIntegerPoint.
>>
>> Though the object creating that surface is deleted, the surface sticks
>> around. So, each time I run the app, I get another instance of
>> AthensCairoSurface hanging around. That means all the forms stick around as
>> well. So my image can quickly grow towards the 1GB size.
>>
>>  Is there anything I can do about that? Can I manually get the surface to
>> delete itself?
>>
>>
> follow the pointers and look for the culprit, that holding it and not
> releasing. That's all i can advice.
>
>
>> Cheers,
>>
>> Jeff
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>

Re: [Pharo-dev] AthensCairoSurface not getting garbage collected

[J.F. Rick]

Here's some more information on this: When I was having this issue, Pharo
was pretty unstable. It would crash regularly when using
AthensCairoSurface. It would also sometimes have weird visual artifacts.
I'm not sure what these were but it almost looked like the bits were
shifted so that rgb turned into gbr or something. Anyway, I've gone ahead
and dumped that image, loaded all the same code, and started making sure
that I don't save the image when testing the code. I haven't had a crash
since. Perhaps that gives a clue about what was going on.

Cheers,

Jeff

PS This is on the Ubuntu16 and Pharo5.

On Sat, Jun 18, 2016 at 12:36 PM J.F. Rick <s...@je77.com> wrote:

> I'm using Athens rendering for my multi-touch applications on Pharo5. As
> part of that, I create a surface:
> surface := AthensCairoSurface extent: bounds extent asIntegerPoint.
>
> Though the object creating that surface is deleted, the surface sticks
> around. So, each time I run the app, I get another instance of
> AthensCairoSurface hanging around. That means all the forms stick around as
> well. So my image can quickly grow towards the 1GB size.
>
>  Is there anything I can do about that? Can I manually get the surface to
> delete itself?
>
> Cheers,
>
> Jeff
>

[Pharo-dev] Ubuntu Installation Change

[J.F. Rick]

You might also want to include the following in the i386 section of the
Ubuntu installation:
apt-get install libcairo2:i386
While Athens isn't readily used, it is in the image.

Cheers,

Jeff

[Pharo-dev] AthensCairoSurface not getting garbage collected

[J.F. Rick]

I'm using Athens rendering for my multi-touch applications on Pharo5. As
part of that, I create a surface:
surface := AthensCairoSurface extent: bounds extent asIntegerPoint.

Though the object creating that surface is deleted, the surface sticks
around. So, each time I run the app, I get another instance of
AthensCairoSurface hanging around. That means all the forms stick around as
well. So my image can quickly grow towards the 1GB size.

 Is there anything I can do about that? Can I manually get the surface to
delete itself?

Cheers,

Jeff

Re: [Pharo-dev] [ANN] Pharo 6.0 Development started

[J.F. Rick]

Is there a (informal) roadmap for Pharo 6.0? What are the major things that
are being targeted? Bloc replacing Morphic? Move from 32-bit to 64-bit?
Athens-based rendering?

Cheers,

Jeff

On Fri, May 13, 2016 at 11:31 AM Esteban Lorenzano 
wrote:

> Hi,
>
> So, that: We just started development of Pharo 6.0 :)
>
> And of course, now monkey fails because you guys committed fixes from
> Pharo 6.0 in Pharo 5.0 inbox... so if you want the check, please commit in
> the new inbox :)
>
> cheers!
> Esteban
>

Re: [Pharo-dev] new pharo cheatsheet

[J.F. Rick]

I agree that enumeration is more useful but it wouldn't be bad to have
something in there to indicate the 1-index nature, such as
  *'abcd' at: 2* will result in $b
That's all I was suggesting.

Actually, having some cheat sheet on basic enumeration wouldn't be bad as
that is a real strength of Smalltalk. Mention and illustrate what do:
collect: and select: do. Then mention that there are other ones like count:
and sum:.

Cheers,

Jeff

On Sat, Apr 9, 2016 at 4:57 AM Cyril Ferlicot D. <cyril.ferli...@gmail.com>
wrote:

> Le 08/04/2016 22:08, J.F. Rick a écrit :
> > It looks good. I might mention that most data structures are 1 indexed
> > as most other languages tend to be 0 indexed and that throws people new
> > to the language.
> >
>
> I use Pharo since 1 year now and I had to use indexes only 3-4 times. I
> think it is more important to say that Pharo have Collections with an
> awesome API.
>
> --
> Cyril Ferlicot
>
> http://www.synectique.eu
>
> 165 Avenue Bretagne
> Lille 59000 France
>
>

Re: [Pharo-dev] new pharo cheatsheet

[J.F. Rick]

It looks good. I might mention that most data structures are 1 indexed as
most other languages tend to be 0 indexed and that throws people new to the
language.

On Fri, Apr 8, 2016 at 3:58 PM stepharo  wrote:

> new cheatsheet for Pharo syntax.
> Any feedback is welcome
>
> Stef
>

[Pharo-dev] Bloc, Athens, Pharo5 advice

[J.F. Rick]

Hi everybody,

I've been off doing a seaside project which really had me using Pharo more
than doing anything new to develop for it. Now, I'm in the project where I
get to do some more fun stuff on multi-touch interfaces in Pharo. It seems
like Pharo has made major progress in that direction so I'd like to take
advantage of this progress and also contribute to it. But, I'm a bit
confused about the current state, whether it is usable for my project, and
how I can contribute to it.

First, a little about the hardware I will be working with. At home
(development), I have a Dell XPS27 running Ubuntu. It has native
multi-touch capabilities. At work (deployment), I have a Mac Mini (OS X)
hooked up to a 4k display and get multi-touch information through TUIO. In
the past, I used a separate program to turn the Dell touch input into TUIO
and then process it inside Pharo (pretty easy). It seems like I should use
OSWindow support these days to deal with native input on the Dell and then
modify my TUIO adaptor to create those events. Is that correct? If so, how
do I get started on that? Do I need a special VM? Is the OSWindow code in
Pharo5 or do I need other packages?

Last time around (~2 years ago), I started using Athens for rendering
multi-touch graphics and it worked fairly well (great fast vector
rendering). It seems like Athens has been put into Bloc, which is a
framework to replace Morphic. OSWindow support also seems to be linked to
Bloc. Is Bloc solid enough where I could use it to create an application?
If it is fairly far along, I'd be happy to use it and contribute back to
it. Again, is this just in Pharo5 or do I have to load different packages?
Is there any documentation I can look at (code examples are fine)? I've
already looked at the things I found on Google.

Anyway, I'd appreciate any advice on how to get up to speed and perhaps how
I can contribute. At minimum, I have some existing multi-touch applications
that I could share, thereby giving good demos of Pharo multi-touch
capabilities.

Cheers,

Jeff

Re: [Pharo-dev] fullscreen on MacOS (possible VM bug)

[J.F. Rick]

In good news, this problem seems to not exist with the latest Pharo5 VM +
image (seems not backwards compatible to the Pharo4 image), so that'll fix
my problem as I'll just use Pharo5 instead of Pharo4 for this project.

Cheers,

Jeff

On Fri, Mar 25, 2016 at 1:08 PM J.F. Rick <s...@je77.com> wrote:

> In further details, when it is green-button maximized, then I can run
> "Display fullscreenOn" and it doesn't crash. I also upgraded the desktop to
> the latest OS (10.11.4) but that doesn't fix it.
>
> Cheers,
>
> Jeff
>
> On Fri, Mar 25, 2016 at 11:12 AM J.F. Rick <s...@je77.com> wrote:
>
>> Hi,
>>
>> I'm trying to run fullscreen Pharo on MacOS using "Display fullscreenOn".
>> On my laptop (13" Macbook Pro, OS 10.11.4), that works. On my desktop
>> (MacMini, 4k display, OS 10.11.3), the screen goes to black for several
>> seconds and the VM crashes. I am attaching the crash.dmp file. Note that
>> this is a new Pharo4.0 I just downloaded from pharo.org.
>>
>> If I maximize the screen using the green button on the Pharo window, it
>> does not crash. But, it does mean that anytime I move my cursor towards the
>> top the Apple menus appear. That's not ideal for this purpose but could be
>> acceptable. When I quit and restart Pharo, it doesn't come back in full
>> screen mode. Is there Pharo code I can run to have it be in this kind of
>> fullscreen mode without user action?
>>
>> Cheers,
>>
>> Jeff
>>
>>

Re: [Pharo-dev] fullscreen on MacOS (possible VM bug)

[J.F. Rick]

In further details, when it is green-button maximized, then I can run
"Display fullscreenOn" and it doesn't crash. I also upgraded the desktop to
the latest OS (10.11.4) but that doesn't fix it.

Cheers,

Jeff

On Fri, Mar 25, 2016 at 11:12 AM J.F. Rick <s...@je77.com> wrote:

> Hi,
>
> I'm trying to run fullscreen Pharo on MacOS using "Display fullscreenOn".
> On my laptop (13" Macbook Pro, OS 10.11.4), that works. On my desktop
> (MacMini, 4k display, OS 10.11.3), the screen goes to black for several
> seconds and the VM crashes. I am attaching the crash.dmp file. Note that
> this is a new Pharo4.0 I just downloaded from pharo.org.
>
> If I maximize the screen using the green button on the Pharo window, it
> does not crash. But, it does mean that anytime I move my cursor towards the
> top the Apple menus appear. That's not ideal for this purpose but could be
> acceptable. When I quit and restart Pharo, it doesn't come back in full
> screen mode. Is there Pharo code I can run to have it be in this kind of
> fullscreen mode without user action?
>
> Cheers,
>
> Jeff
>
>

[Pharo-dev] fullscreen on MacOS (possible VM bug)

[J.F. Rick]

Hi,

I'm trying to run fullscreen Pharo on MacOS using "Display fullscreenOn".
On my laptop (13" Macbook Pro, OS 10.11.4), that works. On my desktop
(MacMini, 4k display, OS 10.11.3), the screen goes to black for several
seconds and the VM crashes. I am attaching the crash.dmp file. Note that
this is a new Pharo4.0 I just downloaded from pharo.org.

If I maximize the screen using the green button on the Pharo window, it
does not crash. But, it does mean that anytime I move my cursor towards the
top the Apple menus appear. That's not ideal for this purpose but could be
acceptable. When I quit and restart Pharo, it doesn't come back in full
screen mode. Is there Pharo code I can run to have it be in this kind of
fullscreen mode without user action?

Cheers,

Jeff


crash.dmp
Description: Binary data

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

[J.F. Rick]

Lovely little discussion which would be great for beginning OO programmers
to see. The question of whether to return 0 for an empty collection is
interesting. While other things can be summed, we tend to think of sums
returning numbers. In that sense, 0 is a great default return. On the other
hand, having a specific object for a generic sum function is problematic
(+1). There is a real tension and that would be a great discussion for
people to have. Either way, the need for sumIfEmpty: is obvious.

Cheers,

Jeff

On Tue, Dec 1, 2015 at 11:19 AM Ben Coman  wrote:

> On Tue, Dec 1, 2015 at 10:24 PM, Sven Van Caekenberghe 
> wrote:
> > Doru,
> >
> >> On 01 Dec 2015, at 15:11, Tudor Girba  wrote:
> >>
> >> Hi,
> >>
> >>> On Dec 1, 2015, at 12:52 PM, Sven Van Caekenberghe 
> wrote:
> >>>
> >>>
>  On 01 Dec 2015, at 12:45, Stephan Eggermont  wrote:
> 
>  On 01-12-15 11:46, Sven Van Caekenberghe wrote:
> > The basic question for me is, what should
> >
> > #() sum
> >
> > return. Right now, it is an error, I would very much like that for
> this common case the result would be 0. There is a lot of power (easy of
> use) in a unary selector, we should not destroy that with semantics that
> force a test before using it.
> 
>  I like the error, it aligns with most of our collection protocol.
> >>>
> >>> I hate the error, a lot ;-)
> >>>
>  It shows the need for #sum:ifEmpty: though
> >>>
> >>> Yes, as long as #() sum == 0
> >>
> >> That won’t work :).
> >
> > Why ? Please explain.
> >
> >>> I want the simplest case to be simple, having a non-0 default is a
> special case IMHO
> >>
> >> That is why you have sumNumbers:. We could also add
> Collection>>sumNumbers.
> >>
> >> We had this discussion at length before Pharo 4, and this is when we
> agreed to add sumNumbers: and let sum: be generic (like the name says it
> should be) and not assume that it should work with Numbers.
> >
> > It is not about numbers or not, you are still using #+ in your generic
> case, that is numeric in my book. It is about the zero element and how to
> deal with an empty collection.
> >
> > The current solution, which was indeed recently added, leaves the
> problem of what to do with an empty collection. There is no general
> solution, you have to specify a zero element.
> >
> > But for most people in most cases that will be effectively 0, so lets
> make the unary #sum respect that. (And unary #sum will also work for
> non-empty non-zero based objects). The less common case can then use the
> longer message.
>
> https://en.wikipedia.org/wiki/Empty_sum
>
>

[Pharo-dev] Playing video

[J.F. Rick]

Is there a way to play a video file (MP4, AVI, etc.) in Pharo for Mac?
There used to be a way to do this in Squeak but I can't find any
documentation of how I might do it in Pharo.

Re: [Pharo-dev] Ubuntu fullscreen problems

[J.F. Rick]

Works like a charm: both toggling modes and using the Unity pager to switch
workspaces.

Thanks!

Jeff

On Sun, Nov 8, 2015 at 6:40 PM Nicolai Hess <nicolaih...@gmail.com> wrote:

> 2015-10-28 20:14 GMT+01:00 J.F. Rick <s...@je77.com>:
>
>> Cool. I guess if there is a bug report on squeak then there is no reason
>> to create one on pharo. If you need someone to test a solution on Ubuntu
>> 15.10, let me know.
>>
>
> Hi Jeff,
>
> can you check this version, it works for me on
>
> DISTRIB_ID="elementary OS"
> DISTRIB_RELEASE=0.3.1
> DISTRIB_CODENAME=freya
> DISTRIB_DESCRIPTION="elementary OS Freya"
>
>
> https://drive.google.com/file/d/0B8yEahnuIem2VGJlejJpUjZfZHc/view?usp=sharing
>
> it should work on Ubuntu, but I don|t have Ubuntu 15 installed.
>
>
>
>
>>
>> On Wed, Oct 28, 2015 at 11:21 AM Nicolai Hess <nicolaih...@gmail.com>
>> wrote:
>>
>>> 2015-10-28 15:35 GMT+01:00 Peter Uhnák <i.uh...@gmail.com>:
>>>
>>>> I think there must be some incompatibility between Pharo and the host
>>>> window manager/desktop environment.
>>>>
>>>> On Debian/dwm (I am using Ubuntu VM) I can reproduce (1), but not (2).
>>>>
>>>> There is however interesting behavior... if I try to switch desktop
>>>> while in fullscreen it doesn't switch, however once I switch back to
>>>> non-fullscreen, suddenly I jump to the other desktop, as if the keyboard
>>>> shortcut for the switch got buffered somewhere...
>>>>
>>>> Opening a issue in FogzBugz is a good idea so it doesn't get forgotten.
>>>>
>>>> Peter
>>>>
>>>> On Wed, Oct 28, 2015 at 3:15 PM, J.F. Rick <s...@je77.com> wrote:
>>>>
>>>>> Hi everybody,
>>>>>
>>>>> I just upgraded to Ubuntu 15.10 and am using Unity User Interface. I
>>>>> want Pharo to use the full screen (i.e., above the menu bar and launcher).
>>>>> Inside Pharo, I can choose "Toggle full screen mode". This works to some
>>>>> extent but has some problems:
>>>>>
>>>>> (1) I can no longer switch applications or desktops (i.e., pager). So
>>>>> it stops me doing work where I move between Pharo and a browser. This may
>>>>> be expected functionality.
>>>>>
>>>>> (2) More problematically, when I try to switch out of full screen mode
>>>>> by choosing "Toggle full screen mode", the Pharo interface completely
>>>>> disappears (just a giant gray area) and no mouse or keyboard events seem 
>>>>> to
>>>>> register. I have to use command line to kill it. In good news, I can use
>>>>> "save and quit" instead and relaunching it just has it in maximum mode
>>>>> (full screen but launcher and menu bar are visible). I can then toggle 
>>>>> full
>>>>> screen mode twice to get back to full screen.
>>>>>
>>>>> I searched for this on FogBugz but found nothing. Is there a
>>>>> workaround? This seems like a VM issue. Is there a newer VM that fixes
>>>>> this? I just used the most recent one on the Pharo 4.0 download page.
>>>>>
>>>>> If nobody has a fix, I'll open a case on FogBugz. This isn't a large
>>>>> problem but it would be nice to have this
>>>>>
>>>>
>>> It is a know problem (with possible fixes)
>>> (http://bugs.squeak.org/view.php?id=7812)
>>> You can not switch back from fullscreen on a linux 64-bit system (
>>> http://bugs.squeak.org/view.php?id=7833) (maybe not only 32bit issue,
>>> but just the more recent windowmanager)
>>>
>>>
>>>
>>>>
>>>>> Cheers,
>>>>>
>>>>> Jeff
>>>>>
>>>>
>>>>
>>>

[Pharo-dev] Ubuntu fullscreen problems

[J.F. Rick]

Hi everybody,

I just upgraded to Ubuntu 15.10 and am using Unity User Interface. I want
Pharo to use the full screen (i.e., above the menu bar and launcher).
Inside Pharo, I can choose "Toggle full screen mode". This works to some
extent but has some problems:

(1) I can no longer switch applications or desktops (i.e., pager). So it
stops me doing work where I move between Pharo and a browser. This may be
expected functionality.

(2) More problematically, when I try to switch out of full screen mode by
choosing "Toggle full screen mode", the Pharo interface completely
disappears (just a giant gray area) and no mouse or keyboard events seem to
register. I have to use command line to kill it. In good news, I can use
"save and quit" instead and relaunching it just has it in maximum mode
(full screen but launcher and menu bar are visible). I can then toggle full
screen mode twice to get back to full screen.

I searched for this on FogBugz but found nothing. Is there a workaround?
This seems like a VM issue. Is there a newer VM that fixes this? I just
used the most recent one on the Pharo 4.0 download page.

If nobody has a fix, I'll open a case on FogBugz. This isn't a large
problem but it would be nice to have this

Cheers,

Jeff

Re: [Pharo-dev] Ubuntu fullscreen problems

[J.F. Rick]

Cool. I guess if there is a bug report on squeak then there is no reason to
create one on pharo. If you need someone to test a solution on Ubuntu
15.10, let me know.

On Wed, Oct 28, 2015 at 11:21 AM Nicolai Hess <nicolaih...@gmail.com> wrote:

> 2015-10-28 15:35 GMT+01:00 Peter Uhnák <i.uh...@gmail.com>:
>
>> I think there must be some incompatibility between Pharo and the host
>> window manager/desktop environment.
>>
>> On Debian/dwm (I am using Ubuntu VM) I can reproduce (1), but not (2).
>>
>> There is however interesting behavior... if I try to switch desktop while
>> in fullscreen it doesn't switch, however once I switch back to
>> non-fullscreen, suddenly I jump to the other desktop, as if the keyboard
>> shortcut for the switch got buffered somewhere...
>>
>> Opening a issue in FogzBugz is a good idea so it doesn't get forgotten.
>>
>> Peter
>>
>> On Wed, Oct 28, 2015 at 3:15 PM, J.F. Rick <s...@je77.com> wrote:
>>
>>> Hi everybody,
>>>
>>> I just upgraded to Ubuntu 15.10 and am using Unity User Interface. I
>>> want Pharo to use the full screen (i.e., above the menu bar and launcher).
>>> Inside Pharo, I can choose "Toggle full screen mode". This works to some
>>> extent but has some problems:
>>>
>>> (1) I can no longer switch applications or desktops (i.e., pager). So it
>>> stops me doing work where I move between Pharo and a browser. This may be
>>> expected functionality.
>>>
>>> (2) More problematically, when I try to switch out of full screen mode
>>> by choosing "Toggle full screen mode", the Pharo interface completely
>>> disappears (just a giant gray area) and no mouse or keyboard events seem to
>>> register. I have to use command line to kill it. In good news, I can use
>>> "save and quit" instead and relaunching it just has it in maximum mode
>>> (full screen but launcher and menu bar are visible). I can then toggle full
>>> screen mode twice to get back to full screen.
>>>
>>> I searched for this on FogBugz but found nothing. Is there a workaround?
>>> This seems like a VM issue. Is there a newer VM that fixes this? I just
>>> used the most recent one on the Pharo 4.0 download page.
>>>
>>> If nobody has a fix, I'll open a case on FogBugz. This isn't a large
>>> problem but it would be nice to have this
>>>
>>
> It is a know problem (with possible fixes)
> (http://bugs.squeak.org/view.php?id=7812)
> You can not switch back from fullscreen on a linux 64-bit system (
> http://bugs.squeak.org/view.php?id=7833) (maybe not only 32bit issue, but
> just the more recent windowmanager)
>
>
>
>>
>>> Cheers,
>>>
>>> Jeff
>>>
>>
>>
>

Re: [Pharo-dev] Fwd: [Pharo-users] [ann] brick on top of bloc - preview

[J.F. Rick]

On Wed, Aug 26, 2015 at 11:45 PM Ben Coman b...@openinworld.com wrote:

 So morphic has a Z-order but I think not a Z-depth. Is that be
 something we should be aiming for?


In HTML5, Z-depth is pretty exclusively used as a mechanism to determine
Z-order in the HTML / CSS separation. Normally, the order of HTML
determines the Z-order. But, Z-order is really a style thing, rather than a
composition thing. So, specifying the Z-depth allows you to override
standard behavior in the style sheet. This is not necessary in a true
object-based GUI where graphical objects are more self contained and can
easily determine their own Z-order.

I doubt we will see general purpose adoption of any 2D interface that will
rely on Z-depth for anything besides determining Z-order. For instance, the
example of shadow size seems interesting but runs into usability problems
quickly. Let's say that you have element A with a larger shadow to indicate
that it is above element B with a smaller shadow. That seems great. What
happens if element B is selected and brought to the forefront? Does A's
shadow go down in size? If so, that breaks the normal shadow analogy. If
not, it would seem that the shadows would just keep growing bigger each
time a new element is brought to the front. For limited general-purpose
applications (e.g., a larger shadow for an object currently being dragged),
you don't need Z-depth info. For specialized applications where a Z-depth
might make sense (I can't even think of one), there's little problem adding
such functionality to custom widgets. So, my recommendations is to stay
away from trying to implement Z-depth as a fundamental component of a 2D
interface. The benefit is minimal and largely theoretical.

Cheers,

Jeff

[Pharo-dev] Bug? JPEG reading ignores EXIF Orientation

[J.F. Rick]

A lot of mobile phone cameras use the EXIF metadata of JPEG to indicate the
orientation of the image (i.e., vertical vs horizontal, upside down, etc.).
In Pharo 3 (I doubt it has changed in Pharo 4), that data is ignored. So,
when you convert a photo taken from a mobile device to a form, it will
probably be in the wrong orientation. This is true for both JPEGReadWriter
and PluginBasedJPEGReadWriter.

Anybody got any knowledge about this? If not, I'll add it as a bug to
FogBugz.

Cheers,

Jeff
-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

[Pharo-dev] Fwd: Running Pharo on Ubuntu 14.04.1 LTS 64-bit

[J.F. Rick]

 It's probably obvious to you now but arguments up to and including the
 image name are processed by the VM and arguments thereafter are left for
 the image.


Indeed. I've just always been used to practice of setting flags first when
executing a unix command. Perhaps this would be worthwhile adding as a note
in the documentation that spits out. Based on that feedback, I tried
./pharo --headless --no-quit ./Pharo.image pretty quickly. It didn't
occur to me then that order might make a difference as one set of tags is
for the VM and the other is for the scripting ability. Now that I better
understand it, it makes sense. But a note of warning there would have been
helpful. It seems we've come a long way from the early days of the Squeak
VM.

Cheers,

Jeff

-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Running Pharo on Ubuntu 14.04.1 LTS 64-bit

[J.F. Rick]

 Well, after sleeping over it, I too figured that it was the --no-quit that
 you were looking for. Still, the --headless is not needed with the plain
 pharo command ;-)


I had actually found the --no-quit option a long time ago but never thought
that it had to come after the image name.

BTW, having your server running in an image is not what I would recommend.
 I would always use an .st start up script. Not that it would not work, it
 is just safer, clearer.


I was planning to use the startup.st file in the image directory for that.
Or does that not work with this?

Cheers,

Jeff

-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Running Pharo on Ubuntu 14.04.1 LTS 64-bit

[J.F. Rick]

I understand unix quite well. All the ./pharo does is redirect to the vm
with the --nodisplay flag.

When I try it without the eval ZnClient new get: 'https://google.com'
part, I get the following in the terminal:

Usage: [--no-preferences|--preference-file=FILE][subcommand] [--help]
[--copyright] [--version] [--list] [ --no-quit ]
--help   print this help message
--copyright  print the copyrights
--versionprint the version for the image and the vm
--list   list a description of all active command line handlers
--no-quitkeep the image running without activating any other
command line handler
subcommand a valid subcommand in --list

Preference File Modification:
--preference-file   load the preferences from the given FILE
--no-default-preferencesdo not load any preferences from the
default locations

Documentation:
A PharoCommandLineHandler handles default command line arguments and
options.
The PharoCommandLineHandler is activated before all other handlers.
It first checks if another handler is available. If so it will activate the
found handler.

Then pharo exits. It seems like it is just doing the command and then dies.
That's definitely different behaviour than a usual headless pharo.

Cheers,

Jeff



On Sun, Feb 15, 2015 at 5:39 PM, Sven Van Caekenberghe s...@stfx.eu wrote:

 Sorry, Jeff, it most certainly works ;-)

 ./pharo is the headless version
 ./pharo-ui is the version for running a GUI

 these are both bash scripts that use the binary inside pharo-vm
 you can look at what's in them to understand what is going on

 I don't want to be rude, but either you understand command line unix or
 you don't. To make things easier, there are the 2 top level scripts. I have
 no time to explain this from first principles, sorry.

  On 15 Feb 2015, at 23:10, J.F. Rick s...@je77.com wrote:
 
  This somewhat works. At minimum, the command for downloading the google
 home page works. On the other hand, the pharo-ui line caused an error:
 pharo: could not find any display driver
 
  That's not a huge deal as this is on a remote server and I can run
 headless. However, when I try to do that (i.e., ./pharo-vm/pharo headless
 ./Pharo.image ), I get the same message about not finding a display driver.
 
  I do get both vm-display-X11 and vm-display-null showing up as available
 drivers.
 
  Cheers,
 
  Jeff
 
  On Sat, Feb 14, 2015 at 2:15 PM, Sven Van Caekenberghe s...@stfx.eu
 wrote:
  Hi,
 
  It seems some people are having trouble getting Pharo to work on Ubuntu
 14.04.1 LTS 64-bit.
 
  Here is one way to make things work.
 
  Pharo (the VM) is a 32-bit executable dynamically linked to a number of
 libraries, each of which has to be present in its 32-bit variant in order
 to run Pharo and/or to use all features.
 
  On a clean, stock, fully updated Ubuntu 14.04.1 LTS 64-bit, do the
 following (the X11, GL and asound libraries are not needed when you run
 headless on a server):
 
  $ sudo apt-get install curl libc6:i386 libssl1.0.0:i386 libX11.6:i386
 libGL.1:i386 libasound2:i386
 
  $ curl get.pharo.org/40+vm | bash
 
  $ ./pharo Pharo.image eval ZnClient new get: 'https://google.com'
 
  $ ./pharo-ui Pharo.image
 
  HTH,
 
  Sven
 
  PS: Pro tip You can use ldd to check if all dependencies of the VM and
 its plugins in the pharo-vm directory are satisfied
 
  --
  Sven Van Caekenberghe
  Proudly supporting Pharo
  http://pharo.org
  http://association.pharo.org
  http://consortium.pharo.org
 
 
 
 
 
  --
  Jochen Jeff Rick, Ph.D.
  http://www.je77.com/
  Skype ID: jochenrick





-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Running Pharo on Ubuntu 14.04.1 LTS 64-bit

[J.F. Rick]

This somewhat works. At minimum, the command for downloading the google
home page works. On the other hand, the pharo-ui line caused an error:
pharo: could not find any display driver

That's not a huge deal as this is on a remote server and I can run
headless. However, when I try to do that (i.e., ./pharo-vm/pharo headless
./Pharo.image ), I get the same message about not finding a display driver.

I do get both vm-display-X11 and vm-display-null showing up as available
drivers.

Cheers,

Jeff

On Sat, Feb 14, 2015 at 2:15 PM, Sven Van Caekenberghe s...@stfx.eu wrote:

 Hi,

 It seems some people are having trouble getting Pharo to work on Ubuntu
 14.04.1 LTS 64-bit.

 Here is one way to make things work.

 Pharo (the VM) is a 32-bit executable dynamically linked to a number of
 libraries, each of which has to be present in its 32-bit variant in order
 to run Pharo and/or to use all features.

 On a clean, stock, fully updated Ubuntu 14.04.1 LTS 64-bit, do the
 following (the X11, GL and asound libraries are not needed when you run
 headless on a server):

 $ sudo apt-get install curl libc6:i386 libssl1.0.0:i386 libX11.6:i386
 libGL.1:i386 libasound2:i386

 $ curl get.pharo.org/40+vm | bash

 $ ./pharo Pharo.image eval ZnClient new get: 'https://google.com'

 $ ./pharo-ui Pharo.image

 HTH,

 Sven

 PS: Pro tip You can use ldd to check if all dependencies of the VM and
 its plugins in the pharo-vm directory are satisfied

 --
 Sven Van Caekenberghe
 Proudly supporting Pharo
 http://pharo.org
 http://association.pharo.org
 http://consortium.pharo.org





-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Running Pharo on Ubuntu 14.04.1 LTS 64-bit

[J.F. Rick]

Thanks for the pointer to the ZeroConf. This is my first time using that.
I'm used to the usual Ubuntu installation which provides a pharo-vm-x (GUI)
and pharo-vm-nox (headless). The command line functionality is cool, but
that's not what I want. By playing around, I figured out how to get
--no-quit to work. I was trying
   ./pharo --headless --no-quit ./Pharo.image 
and I needed
   ./pharo --headless ./Pharo.image --no-quit 
I guess that makes sense knowing that --no-quit is actually to be processed
by the script and not a flag for the VM.

Anyway, I think I got it figured out. Thanks for the help,

Jeff

On Sun, Feb 15, 2015 at 9:34 PM, Sven Van Caekenberghe s...@stfx.eu wrote:

 BTW, these are pharo-users questions ...

  On 16 Feb 2015, at 01:17, J.F. Rick s...@je77.com wrote:
 
  I understand unix quite well.

 Fine.

  All the ./pharo does is redirect to the vm with the --nodisplay flag.

 So ?

  When I try it without the eval ZnClient new get: 'https://google.com'
 part, I get the following in the terminal:
 
  Usage: [--no-preferences|--preference-file=FILE][subcommand]
 [--help] [--copyright] [--version] [--list] [ --no-quit ]
  --help   print this help message
  --copyright  print the copyrights
  --versionprint the version for the image and the vm
  --list   list a description of all active command line handlers
  --no-quitkeep the image running without activating any other
 command line handler
  subcommand a valid subcommand in --list
 
  Preference File Modification:
  --preference-file   load the preferences from the given FILE
  --no-default-preferencesdo not load any preferences from the
 default locations
 
  Documentation:
  A PharoCommandLineHandler handles default command line arguments and
 options.
  The PharoCommandLineHandler is activated before all other handlers.
  It first checks if another handler is available. If so it will activate
 the found handler.
 
  Then pharo exits. It seems like it is just doing the command and then
 dies.

 Yes, Pharo runs and exits because you do not tell it what to do, like any
 command line utility. Try --list to see all the options.

  That's definitely different behaviour than a usual headless pharo.

 I don't understand what you are referring to. This is the way it works
 with the so called Zero Config system, since quite a while, maybe this can
 help:


 http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/ZeroConf.pdf

 (which might not be 100% up to date, I did not check, but it should help).

 But the point is, what I said before works perfectly, why go look further ?

 What is your concrete problem ?

  Cheers,
 
  Jeff
 
 
 
  On Sun, Feb 15, 2015 at 5:39 PM, Sven Van Caekenberghe s...@stfx.eu
 wrote:
  Sorry, Jeff, it most certainly works ;-)
 
  ./pharo is the headless version
  ./pharo-ui is the version for running a GUI
 
  these are both bash scripts that use the binary inside pharo-vm
  you can look at what's in them to understand what is going on
 
  I don't want to be rude, but either you understand command line unix or
 you don't. To make things easier, there are the 2 top level scripts. I have
 no time to explain this from first principles, sorry.
 
   On 15 Feb 2015, at 23:10, J.F. Rick s...@je77.com wrote:
  
   This somewhat works. At minimum, the command for downloading the
 google home page works. On the other hand, the pharo-ui line caused an
 error: pharo: could not find any display driver
  
   That's not a huge deal as this is on a remote server and I can run
 headless. However, when I try to do that (i.e., ./pharo-vm/pharo headless
 ./Pharo.image ), I get the same message about not finding a display driver.
  
   I do get both vm-display-X11 and vm-display-null showing up as
 available drivers.
  
   Cheers,
  
   Jeff
  
   On Sat, Feb 14, 2015 at 2:15 PM, Sven Van Caekenberghe s...@stfx.eu
 wrote:
   Hi,
  
   It seems some people are having trouble getting Pharo to work on
 Ubuntu 14.04.1 LTS 64-bit.
  
   Here is one way to make things work.
  
   Pharo (the VM) is a 32-bit executable dynamically linked to a number
 of libraries, each of which has to be present in its 32-bit variant in
 order to run Pharo and/or to use all features.
  
   On a clean, stock, fully updated Ubuntu 14.04.1 LTS 64-bit, do the
 following (the X11, GL and asound libraries are not needed when you run
 headless on a server):
  
   $ sudo apt-get install curl libc6:i386 libssl1.0.0:i386 libX11.6:i386
 libGL.1:i386 libasound2:i386
  
   $ curl get.pharo.org/40+vm | bash
  
   $ ./pharo Pharo.image eval ZnClient new get: 'https://google.com'
  
   $ ./pharo-ui Pharo.image
  
   HTH,
  
   Sven
  
   PS: Pro tip You can use ldd to check if all dependencies of the VM
 and its plugins in the pharo-vm directory are satisfied
  
   --
   Sven Van Caekenberghe
   Proudly supporting Pharo
   http://pharo.org
   http://association.pharo.org
   http://consortium.pharo.org

Re: [Pharo-dev] Ubunti 14.04 32bit install error

[J.F. Rick]

I followed the instructions on the Download Pharo page. So, I did include
that command. I just tried it again with the same result.

Cheers,

Jeff

On Sat, Feb 14, 2015 at 4:04 AM, Markus Fritsche mfrits...@reauktion.de
wrote:

  Hello Jeff,

 does it work if you execute

 dpkg --*add*-*architecture* i386

 first?

 Best regards,
   Markus


 On 13.02.2015 23:10, J.F. Rick wrote:

  I just tried it (Ubuntu 14.04) and it doesn't work:

 The following packages have unmet dependencies:
  pharo-launcher : Depends: pharo-vm-desktop:i386 but it is not installable
 E: Unable to correct problems, you have held broken packages.

  Cheers,

  Jeff

 On Fri, Feb 13, 2015 at 7:23 AM, Damien Cassou damien.cas...@gmail.com
 wrote:


 Markus Fritsche writes:

  Hello Brad,

 Yes, there's already a fixed image in the queue, however, it's stuck
 right now as far as I understand.


  the Continuous Integration Server was down. But everything is fixed now
 and you can enjoy the new launcher.

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

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




 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick





-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Ubunti 14.04 32bit install error

[J.F. Rick]

I tried to do sudo aptitude install ia32-libs and got the following
message:

No candidate version found for ia32-libs
No candidate version found for ia32-libs
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 40 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.

Apparently getting ia32-libs in 14.04 is a known problem:
http://stackoverflow.com/questions/23182765/how-to-install-ia32-libs-in-ubuntu-14-04-lts-trusty-tahr
I've been trying some things recommended there but I can't seem to get it
to work.

Cheers,

Jeff

On Sat, Feb 14, 2015 at 7:58 AM, J.F. Rick s...@je77.com wrote:

 I followed the instructions on the Download Pharo page. So, I did include
 that command. I just tried it again with the same result.

 Cheers,

 Jeff

 On Sat, Feb 14, 2015 at 4:04 AM, Markus Fritsche mfrits...@reauktion.de
 wrote:

  Hello Jeff,

 does it work if you execute

 dpkg --*add*-*architecture* i386

 first?

 Best regards,
   Markus


 On 13.02.2015 23:10, J.F. Rick wrote:

  I just tried it (Ubuntu 14.04) and it doesn't work:

 The following packages have unmet dependencies:
  pharo-launcher : Depends: pharo-vm-desktop:i386 but it is not installable
 E: Unable to correct problems, you have held broken packages.

  Cheers,

  Jeff

 On Fri, Feb 13, 2015 at 7:23 AM, Damien Cassou damien.cas...@gmail.com
 wrote:


 Markus Fritsche writes:

  Hello Brad,

 Yes, there's already a fixed image in the queue, however, it's stuck
 right now as far as I understand.


  the Continuous Integration Server was down. But everything is fixed now
 and you can enjoy the new launcher.

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

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




 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick





 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Ubunti 14.04 32bit install error

[J.F. Rick]

I just tried it (Ubuntu 14.04) and it doesn't work:

The following packages have unmet dependencies:
 pharo-launcher : Depends: pharo-vm-desktop:i386 but it is not installable
E: Unable to correct problems, you have held broken packages.

Cheers,

Jeff

On Fri, Feb 13, 2015 at 7:23 AM, Damien Cassou damien.cas...@gmail.com
wrote:


 Markus Fritsche writes:

  Hello Brad,

 Yes, there's already a fixed image in the queue, however, it's stuck
 right now as far as I understand.


 the Continuous Integration Server was down. But everything is fixed now
 and you can enjoy the new launcher.

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

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




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

[Pharo-dev] Installing Pharo on Ubuntu

[J.F. Rick]

I have a new computer and installed Ubuntu 14.10 on it. When I tried to
install Pharo using the PPA instructions, it failed. I get the following
message when executing sudo apt-get update:

W: Failed to fetch
http://ppa.launchpad.net/pharo/stable/ubuntu/dists/utopic/main/binary-amd64/Packages
404  Not Found
W: Failed to fetch
http://ppa.launchpad.net/pharo/stable/ubuntu/dists/utopic/main/binary-i386/Packages
404  Not Found

I was able to get Pharo running with the Zeroconf script, but I thought I'd
report that the standard thing didn't work. Is it just that a binary
doesn't yet exist for 14.10.

Cheers,

Jeff

-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] R: from 2009's The death of Smalltalk to 2014's But Really, You Should Learn Smalltalk

[J.F. Rick]

Hi Sebastian,

Noel is actually my academic older brother (i.e., we had the same doctoral
advisor). Noel's introduction is nice but it is to people who know how to
program (specifically, Ruby programmers). That's useful. The Pharo books
and YouTube videos do this very well. But, you also need to provide a way
in for people who are learning to program. One thing you could do is
provide a book that could be used at a university to teach object-oriented
programming.

Cheers,

Jeff

*Da:* Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org
 pharo-dev-boun...@lists.pharo.org] *Per conto di *Sebastian Sastre
 *Inviato:* venerdì 9 gennaio 2015 19:07
 *A:* Pharo Development List
 *Oggetto:* Re: [Pharo-dev] from 2009's The death of Smalltalk to 2014's
 But Really, You Should Learn Smalltalk



 Hi Jochen,



 have in mind that the talk you referred is from 2009 and many
 controversial things happened in the Ruby community at that time.



 Coming closer to today, we just had this presentation which presents
 Smalltalk better than many Smalltalkers I've heard!

 https://www.youtube.com/watch?v=eGaKZBr0ga4



 Want to show off smalltalk to non-smalltalker audiences *in an effective
 way*? watch and learn!


-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

[Pharo-dev] The death of Smalltalk

[J.F. Rick]

Hi everyone,

I just watched https://www.youtube.com/watch?v=YX3iRjKj7C0 and had a few
comments that I thought I would share.

First, there is a real opportunity for Smalltalk to come back in the guise
of Pharo. Steph and Marcus are doing a great job providing leadership
towards that end and the community is great. Second, we need to be careful
in spreading the word. Slowly but surely (the current Pharo approach) is a
great approach as it allows really building something worth spreading
before trying to get everyone into it. If it spreads too quickly, bad API
or immature toolkits will become ingrained and flaws will be apparent. The
books, websites, etc. are really good things to get right before trying to
get others into it; they are already very good. Third, if you want to
really spread Smalltalk, then the fundamentals that newcomers experience
need to be without obvious flaws. From personal experience, I can tell you
that BitBlt rendering makes newbies think that Pharo is a toy language.
Switching to Athens rendering is therefore tremendously important for
adoption. Package management really needs to be cleaned up. There needs to
be a simple way to merge resources (bitmaps, audio, external files) into
the codebase. Simple audio needs to work on all platforms. This may seem
trivial but audio is one of the simplest things that newcomers want to do.
From a Linux perspective, this will probably necessitate switching to a
64-bit VM as the 32-bit sound plug-ins are a giant pain. Given that even
phone OSs are switching to 64-bit, there may not be a need for a 32-bit
Pharo. Of course, much of this is already on the horizon.

As the new year begins, I'll once again be coding in Pharo and look forward
to it. I'm really hopeful about the future.

Cheers,

Jeff

-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] [ANN] OnScreenKeyboard

[J.F. Rick]

Awesome. I've been working on an onscreen keyboard as well. Perhaps we can
join forces, though it will be a while before I can continue to work on it.

Cheers,

Jeff

On Sat, Nov 22, 2014 at 2:55 PM, Pavel Krivanek pavel.kriva...@gmail.com
wrote:

 Hi,

 I created the first version of a virtual keyboard morph for Pharo. To
 try it, evaluate:

 Gofer it
  url: '
 http://www.smalltalkhub.com/mc/PavelKrivanek/OnScreenKeyboard/main';
  package: 'OnScreenKeyboard';
  load.

 OnScreenKeyboard new open.

 Currently it doesn't work well together with completion morphs so
 please disable code completion.

 Features:
 - splitted int two parts
 - compact look
 - swipe up to write uppercase letter
 - swipe left to do backspace
 - swipe down to write special character
 - swipe right to write numbers and other special characters
 - swipe up right to press combination with ctrl (e.g. ctrl+p)
 - swipe down right to press combination with alt
 - press Kb button to move the keyboard up and down on the screen
 - press shift/alt/ctrl keys to hold them (e.g. for selecting text with
 cursor keys and shift)

 Feel free to send patches and improvements directly to the project
 repository :-)

 Cheers,
 -- Pavel




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] [ANN] OnScreenKeyboard

[J.F. Rick]

Well, that is a part I haven't gotten to. I only have the looks of it done.
Plus it is only for Athens graphics. I do plan on making it work with
multi-touch, but that's also something that will probably take some work.
Currently, I don't have a multi-touch machine to make progress. Once I get
it, we'll see.

Cheers,

Jeff

On Mon, Nov 24, 2014 at 9:34 AM, Pavel Krivanek pavel.kriva...@gmail.com
wrote:

 Hi,

 where can I find your code?

 I would like to see the emulation of touchpad too (where whole device
 screen acts as a touchpad. Something like TouchMousePointer
 application [1]). Because this is currently the only usable way how to
 control Pharo on tablets.

 ...And Pharo is usable on tablets because this OnScreenKeyboard
 package was WHOLE created on a small 8 tablet and partly in a bus
 without any attached additional hardware ;-)

 [1] http://www.lovesummertrue.com/touchmousepointer/en-us/

 Cheers,
 -- Pavel

 2014-11-24 15:13 GMT+01:00 J.F. Rick s...@je77.com:
  Awesome. I've been working on an onscreen keyboard as well. Perhaps we
 can
  join forces, though it will be a while before I can continue to work on
 it.
 
  Cheers,
 
  Jeff
 
  On Sat, Nov 22, 2014 at 2:55 PM, Pavel Krivanek 
 pavel.kriva...@gmail.com
  wrote:
 
  Hi,
 
  I created the first version of a virtual keyboard morph for Pharo. To
  try it, evaluate:
 
  Gofer it
   url:
  'http://www.smalltalkhub.com/mc/PavelKrivanek/OnScreenKeyboard/main';
   package: 'OnScreenKeyboard';
   load.
 
  OnScreenKeyboard new open.
 
  Currently it doesn't work well together with completion morphs so
  please disable code completion.
 
  Features:
  - splitted int two parts
  - compact look
  - swipe up to write uppercase letter
  - swipe left to do backspace
  - swipe down to write special character
  - swipe right to write numbers and other special characters
  - swipe up right to press combination with ctrl (e.g. ctrl+p)
  - swipe down right to press combination with alt
  - press Kb button to move the keyboard up and down on the screen
  - press shift/alt/ctrl keys to hold them (e.g. for selecting text with
  cursor keys and shift)
 
  Feel free to send patches and improvements directly to the project
  repository :-)
 
  Cheers,
  -- Pavel
 
 
 
 
  --
  Jochen Jeff Rick, Ph.D.
  http://www.je77.com/
  Skype ID: jochenrick




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

[Pharo-dev] SandstoneDB questions

[J.F. Rick]

I'm starting to use SandstoneDB for a project (seems pretty cool) and I had
two questions:
(1) I noticed that the commit: instance method discussed in the
documentation does not exist. Has it been deprecated? There is a commit:
class method but it seems like instance functionality.
(2) It seems like Sandstone does keep versions. Is there a way I can
retrieve old versions? I can't seem to find an API for that.

Cheers,

Jeff

-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Context variables?

[J.F. Rick]

Thanks. Will do.

Jeff

On Wed, Oct 15, 2014 at 11:34 AM, Camille Teruel camille.ter...@gmail.com
wrote:

 Hi Jeff,

 I think you should look at DynamicVariable and ProcessSpecificVariable
 classes. The first one is a read-only while the second is writable.
 You have to subclass these class for each variable you want.

 Ex:
 DynamicVariable subclass: #MyVar.
 MyVar value: 4 during: [ MyVar value ]

 HTH,
 Camiile


 On 15 oct. 2014, at 17:09, J.F. Rick s...@je77.com wrote:

 I remember there was some discussion on the list about support for
 variables tied to the context rather than to the instance or class. This
 seems particularly useful for a web application where you might want to
 access the request and response from the context. What is the proper name
 for these kind of variables and where can I read about how to use them?

 Cheers,

 Jeff

 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick





-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

[Pharo-dev] Context variables?

[J.F. Rick]

I remember there was some discussion on the list about support for
variables tied to the context rather than to the instance or class. This
seems particularly useful for a web application where you might want to
access the request and response from the context. What is the proper name
for these kind of variables and where can I read about how to use them?

Cheers,

Jeff

-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] ANNC: QR Code (v.2)

[J.F. Rick]

Well, the QRCode natively just has a bitmap form. The little server app
requests that form (perhaps with a border, mirrored, reversed, etc.) and
then magnifies it and converts it to a PNG. So, putting the result in a PDF
is as trivial or as hard as putting a bitmap form into a PDF. How difficult
that is is something that Olivier can perhaps answer.

QR codes ultimately just carry some text. We're used to it being a URL but
any arbitrary text is possible. Several formats have established
themselves. For instance, you can use the VCard format to create a business
card QR code. So, there could be some nice uses of QR code where PDF is the
right medium.

Cheers,

Jeff

On Tue, Oct 7, 2014 at 3:15 AM, stepharo steph...@free.fr wrote:

 this is cool
 I want discussing with olivier and do you think that it would be easy to
 produce pdf (beside cropping the morph and saving it as png)
 On 6/10/14 17:49, J.F. Rick wrote:

 I've got a new version of the QR Code generator:
 http://smalltalkhub.com/#!/~JochenRick/QRCode 
 http://smalltalkhub.com/#%21/%7EJochenRick/QRCode

 This one includes support for MicroQR, for UTF-8 encoding and other
 aspects of the latest QR standard (e.g., mirroring). I've also written a
 small Zinc web app which makes it easy to try out.

 Enjoy!

 Jeff

 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick






-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] ANNC: QR Code (v.2)

[J.F. Rick]

On Tue, Oct 7, 2014 at 8:52 AM, Esteban A. Maringolo emaring...@gmail.com
wrote:

 ps: There is also a way to encode a QR with a image/logo inside, but I
 don't know how that works.


As far as I can tell, that whole embed an image / logo is a stupid hack.
QR codes have error correction. So, if you choose a high error correction,
you can replace meaningful pixels with a logo and it will still function.
But, it means that you have to choose high error correction, leading to a
larger code, which is inherently harder to scan. My advice is to keep the
QR code small and it doesn't have to take up that much real estate. Then,
you can put your nice logo next to the QR code, taking up the same amount
of space and looking better.

A more promising angle is a translucent QR code, such as featured on the
following:
http://www.visualead.com/explore-qr-code-designs/

Cheers,

Jeff

-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

[Pharo-dev] ANNC: QR Code (v.2)

[J.F. Rick]

I've got a new version of the QR Code generator:
http://smalltalkhub.com/#!/~JochenRick/QRCode

This one includes support for MicroQR, for UTF-8 encoding and other aspects
of the latest QR standard (e.g., mirroring). I've also written a small Zinc
web app which makes it easy to try out.

Enjoy!

Jeff

-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] About ways to participate in community and general negativity

[J.F. Rick]

Hi Esteban,

seconding your points, it is important to acknowledge why a solid Pharo
core is important and worth striving towards even if it can be painful.
First, read Bret Victor's reflection on Doug Englebart:
http://worrydream.com/#!/Engelbart

He makes the case that the vision that drove Englebart was important to how
he realized things, giving the specific example of how his video
conferencing system was fundamentally different than today's screen sharing
technology. Today's screen sharing is basically a nice hack onto an
existing single user system. Simply doing what Englebart did would require
a lot of restructuring at the foundation. With Pharo, we have the
possibility to really build / refactor from the ground up, building a
fundamentally better foundation, ultimately making cool things possible.
For my own work, I'm excited about the possibility of building a new
multi-touch implementation from the ground up. That said, the current Pharo
foundations have a number of problems for me:

(1) Graphics are still based on BitBlt, which is slow and ugly. Moving over
to Athens will address this. While I have successfully used Athens
graphics, I still get VM crashes (which are probably due to Athens as I did
not get the crashes beforehand).
(2) Sound does not really work. On 64-bit linux, I can't simply play a
recorded file as the sound plug-ins really only work for a 32-bit system.
(3) Event handling does not get touch events. I've hacked this so far but a
sustainable solution would be great.
(4) Packages do not facilitate transfer of resources. For my purposes, I
need to add images and sound to a package. This is not really possible
right now.

I am willing to help on these problems for the community but sometimes I
need support, especially when C code is necessary, rather than Pharo code.
For instance, if I could get a VM that gives me raw touch events into
Pharo, I could take (3) from there. I'd also be willing to work on (4) but
I could use some help. One intimidating part is that there are so many
package managers for Pharo. It might be nice if we simplified down to one:
the right one.

Anyway, you can count me in for some contribution back to Pharo core but I
might need some support from Pharo central and it won't happen for at least
another month as I'm just getting set up in the new location (e.g., no
access to a multi-touch device).

Cheers,

Jeff



On Fri, Oct 3, 2014 at 7:44 AM, Esteban Lorenzano esteba...@gmail.com
wrote:

 Hi,

 I'm writing this because I'm sad about what is happening in this list.
 I'm seeing a lot of general negativity and non constructive ways to
 discuss things.
 I'm also seeing more and more people using Pharo for their particular
 interests (which is of course a good thing) but less and less people who
 contribute back to Pharo.
 Finally, I'm seeing more frequently an attitude of customer, more than
 the conviction than this, Pharo, is also yours...

 Please people, we (the pharo core team) cannot do everything. We do not
 have the manpower or the resources to hire manpower. We would like, but we
 just do not have the resources (is already a blessing that we can work on
 this, for now: INRIA is paying, but what it pays is *research*, not pharo
 the language, so this is a collateral advantage)

 So, having an OPEN SOURCE project, with limited resources means that there
 is a lot of things that depend on the community.
 It depends on the community not just to fix, but to enlarge the ecosystem
 in general too.

 So, I refuse to believe that we cannot be a cool and helpful community.
 I refuse to believe that general negativity and bad humor can overcome the
 joy of participating in this collective effort.

 So, here some recommendations for enhance the way we participate:

 - Be positive. Just this is a s**t does not help. Even if it is.
 - Be propositional. Just this is a s**t, and not telling what you
 want/prefer does not help.
 - Be proactive. Just this is a s**t, and not report, discuss and (at
 least time to time) provide a fix/enhancement does not help.

 In conclusion: not helping does not help :)
 After all, this is the pharo-dev list. I mean, the list of people
 wanting to participate from this great, community effort.

 cheers,
 Esteban, still grateful of belonging to this community






-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Proportional Tab Stops

[J.F. Rick]

Sure. I'll add a ticket to Fogbugz since nobody has any real objections to
my proposed solution. Once I have some time, I might try to solve it myself.

Cheers,

Jeff


On Wed, Sep 3, 2014 at 1:36 PM, Ben Coman b...@openinworld.com wrote:

  Tudor Girba wrote:

 Hi,

  Glad to hear from you.

  Thanks for spotting the issue with tabbing. I think your suggestion of
 having tabs spacing being proportional with the font size makes sense.
 Could we interest you in submitting a slice for this? :)

  Cheers,
 Doru


 I think he indicated he did not have time right now :)

 Rick, I think that sounds like a good idea.  Maybe you could log a ticket
 on Fogbugz, so you can...
 * stay updated with any action on it
 * be involved in testing any proposed solutions
 * when you back into the Pharo groove, if its still an outstanding issue
 you might have a shot at it yourself.

 cheers -ben





 On Wed, Sep 3, 2014 at 9:43 AM, J.F. Rick s...@je77.com wrote:

 Hi everyone,

  I'm writing for two reasons. First, I wanted to let people know that I
 haven't disappeared. I'm just having to take a break as I finish up with my
 current academic post. As I am no longer going to be there, Pharo
 contributions don't help the department. So, I can't justify devoting any
 time to Pharo. But, I'm still interested in Athens, multitouch support, and
 Pharo for beginners. In October, I move back to Atlanta and will start a
 company. At that point, I aim to be back, though I may concentrate a bit
 more on server technology (full version of newest QRCode specifications
 half way done).

  Second, I wanted to mention a slight annoyance and suggest a solution.
 Background: I taught a class on introduction / intermediate programming in
 Pharo the last few years. One thing I try to teach my students is to use
 proper indention for their code. Unlike Python (great syntax for a first
 language), you do not need to indent in Smalltalk for code to work properly
 so students don't have to properly use indention to organize their code.
 For tiny bits of code (as is required in introductory programming),
 indention is not that important but it gets more important as they advance.
 Even my better students often used bad indention practices, though I
 emphasized it in class and all sample code I gave them was properly
 indented. In class, I often solved problems and demonstrated code. So that
 students could see what I typed, I increased the size of the font (24pt
 standard font). Though the font increased, the tab spacing remained the
 same. So, when I indented with one tab, it looked much smaller than a tab
 would have looked on their 10pt code editor. I saw people using spaces to
 indent code, which I never talked about. My guess is that they were trying
 to replicate the amount of space that my code was indented. They saw that a
 tab looked too big and used spaces. A simple solution is for tab spacing in
 code panes to increase proportionally with the font size. I feel like
 suggesting that as an improvement for Pharo 4. Does that seem reasonable?
 Are there arguments against it?

  Cheers,

  Jeff

  --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick




  --
 www.tudorgirba.com

  Every thing has its own flow





-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] [Article] Elegant Pharo Code

[J.F. Rick]

I've often wondered if there might not be a better way to write while loops
that output a product, similar to enumeration sum: and count:.

| sum count index |
sum := 0.
count := 0.
index := 1.
[ index := index + 1.
   index isPrime ifTrue: [
  count := count + 1.
  sum := sum + index ].
   count = 64 ] whileFalse.

vs something like

| count sum |
count := 0.
sum := 1 until: [ count = 64 ] sum: [ :index |
   index isPrime
  ifTrue: [
 count := count + 1.
 index ]
  ifFalse: [ 0 ] ].

or

| count sum |
count := 0.
sum := (1 until: [ count = 64 ]) sum: [ :index |
   index isPrime
  ifTrue: [
 count := count + 1.
 index ]
  ifFalse: [ 0 ] ].


On Sun, Jul 13, 2014 at 3:05 PM, Sergi Reyner sergi.rey...@gmail.com
wrote:

 It may have been mentioned already, but number 7 is wrong, is states:

 7. Sum of the first 64 primes

 when it actually is:

 7. Sum of the primes not larger than 64


 Cheers,
 Sergi


 2014-07-12 17:02 GMT+01:00 Sven Van Caekenberghe s...@stfx.eu:


 On 08 Jul 2014, at 21:53, kilon alios kilon.al...@gmail.com wrote:

  Ruby and Pearl look very ugly to me.
 
  Programming languages are primarily personal preference.
 
  Pharo advantages to me at least are far more than live image, its live
 coding which by the way is different from live image, the IDE tools, the
 factor that is all Pharo objects even when you do assembly coding inside
 Pharo , the libraries of course and last but not least the community.
 
  I could name also thousands more advantages that I have found in the
 implementation that I really like as well others I don't. Devil , as they
 say, is in the details. Details are everything , generalisations have
 little meaning.
 
  Lovely article Sven , keep them coming. I think Pharo would definitely
 benefit from a cookbook working as a database where pharo coders can use to
 find example code the easy way.

 Thanks, Kilon.

  But even articles like this can help a lot, I just wish that there was
 a Pharo wiki to keep these links and see them buried in Pharo news.

 Yes, I think we need more/better places to link everything together. A
 curated reading list maybe.

  PS: Sven I am making my own Pharo book called Pharo Universe where I
 want to put things that are not part of PBE or PFTE which can be find here
 https://github.com/kilon/Pharo-Universe and here
 https://ci.inria.fr/pharo-contribution/job/PharoUniverse/ . May I have
 permission to use your articles as chapters for my book ?  I will fully
 credit you and link back to your blog posts of course :)

 I know you are doing a lot of effort with respect to documentation and
 that is really great and important. I am not sure that copying articles
 that were not meant to be part of a book or larger whole is a good
 solution, for either party, it will give too much repetition and not a lot
 of coherence.

  On Tue, Jul 8, 2014 at 10:33 PM, Paul Davidowitz pdavi...@fastmail.fm
 wrote:
  Very nice, except all this could be done in Ruby, also elegantly.
  The Smalltalk advantage is the live image, and that's where the focus
  should be.
 
 






-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] [Pharo-users] PillarHub

[J.F. Rick]

Awesome. Not that I have time right now but I have always wanted to bring
Swiki / AniAniWeb into the present. This would be the right foundational
work to make this a useful reality.

On a side note, I apologize for all the bad qualities of Pillar markup.
Back in 1999, I created ComSwiki out of the beginning that was PWS Swiki
(the first wiki to eschew camel case for links). One of the first things I
did was to make changes to the markup to improve it. Of course, once we had
some users and established content, all the decisions I made at that early
point in the project were made permanent. Looking at Pillar, it pretty much
uses the syntax I created back then (with a few improvements). I'm sure the
markup just drifted through the Smalltalk community and was then adopted by
Pillar. It's not a bad design but I've always felt that a better, more
extensible syntax was possible. As usual, the good proved to be the enemy
of the great.

Cheers,

Jeff


On Wed, Jul 2, 2014 at 10:57 AM, p...@highoctane.be p...@highoctane.be
wrote:


 Superb!

 Keep on pushing, that's how we can attain the critical momentum.

 Hopefully, I'll be able to show something from my side as well on the
 commercial products front.

 Phil



 On Wed, Jul 2, 2014 at 10:00 AM, Sven Van Caekenberghe s...@stfx.eu
 wrote:

 Wow, amazing - great work !

 On 02 Jul 2014, at 09:28, Yuriy Tymchuk yuriy.tymc...@me.com wrote:

  Hi everyone.
 
  I'm so excited that I cannot keep silent. Guys from Pharocloud have
 implemented online editor (and storage) for Pillar documents. This is
 really amazing, and you can check it out here:
 http://pillarhub.pharocloud.com/hub/pillarhub/about.
 
  They have a really nice plans, and now we can write pillar docs with
 live compilation and share them online.
 
  Cheers!
  Uko






-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] [ANN] LaTeX to Pillar converter

[J.F. Rick]

Cool.

Jeff


On Thu, Jun 19, 2014 at 3:54 PM, Damien Cassou damien.cas...@gmail.com
wrote:

 I'm happy to announce that I wrote a LaTeX to Pillar converter. This
 converter should not be considered perfect and proof reading is required.
 Still, the converter could automatically convert from:


 https://github.com/SquareBracketAssociates/PharoByExample-english/blob/master/Streams/Streams.tex

 to:


 https://github.com/SquareBracketAssociates/UpdatedPharoByExample/blob/master/Streams/Streams.pillar


 This Pillar file is then exported to either

 html:
 https://ci.inria.fr/pharo-contribution/job/UpdatedPharoByExample/lastSuccessfulBuild/artifact/Streams/Streams.pillar.html

 or pdf:
 https://ci.inria.fr/pharo-contribution/job/UpdatedPharoByExample/lastSuccessfulBuild/artifact/Streams/Streams.pillar.pdf

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

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




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

[Pharo-dev] Random VM crashes

[J.F. Rick]

Hi,

when I have one of my multi-touch programs open, Pharo occasionally (read
once every few days) just crashes. Ubuntu mentions a failure to report to
Ubuntu on the pharovm but I'm not sure how to understand that failure.

I thought it might be one of two things: (1) some sort of problem with
Athens rendering or (2) some sort of problem with the multi-touch events.
Those are really the only things that separate when I'm developing and when
I'm testing. It never crashes when I'm developing, which is a much larger
percentage of the time. Recently, the crash happened when I was not
touching the display. That meant that there would not have been any touch
events to process, nor would an Athens render happen. Strange.

I'm not sure how to proceed. I've turned off the multi-touch support for
the time being to see if it still happens. If so, that would probably
exonerate the multi-touch code. Does anyone else have rare random
unexplained crashes happening while using Athens? Is there anything I could
do to better diagnose the problem. It's fiendish as it happens so rarely
and there is no replicable action that causes it to happen.

Cheers,

Jeff

-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Random VM crashes

[J.F. Rick]

Cool! I am using SVG files so there might be some unicode data being sent
to Cairo buffer. On the other hand, my crash happens randomly, rather than
as a result of a specific repeatable action. It sounds like this would be
more along the lines of a repeatable sequence.

Anyway, I'll update the code and see if it helps. Again, this problem is
difficult to diagnose as the crash only happens every other day. Even if it
doesn't happen all week, it doesn't mean that that was the problem. For
instance, there have been no crashes today, so it makes me think that the
multi-touch support, rather than Athens, is the culprit.

Cheers,

Jeff


On Wed, Apr 9, 2014 at 2:12 PM, Igor Stasenko siguc...@gmail.com wrote:




 On 9 April 2014 13:55, J.F. Rick s...@je77.com wrote:

 Hi,

 when I have one of my multi-touch programs open, Pharo occasionally (read
 once every few days) just crashes. Ubuntu mentions a failure to report to
 Ubuntu on the pharovm but I'm not sure how to understand that failure.

 I thought it might be one of two things: (1) some sort of problem with
 Athens rendering or (2) some sort of problem with the multi-touch events.
 Those are really the only things that separate when I'm developing and when
 I'm testing. It never crashes when I'm developing, which is a much larger
 percentage of the time. Recently, the crash happened when I was not
 touching the display. That meant that there would not have been any touch
 events to process, nor would an Athens render happen. Strange.

 I'm not sure how to proceed. I've turned off the multi-touch support for
 the time being to see if it still happens. If so, that would probably
 exonerate the multi-touch code. Does anyone else have rare random
 unexplained crashes happening while using Athens? Is there anything I could
 do to better diagnose the problem. It's fiendish as it happens so rarely
 and there is no replicable action that causes it to happen.

 i fixed recently this one:


 https://pharo.fogbugz.com/f/cases/13184/Fix-encoder-for-displaying-high-range-unicode-chars

 could be it?


 Cheers,

 Jeff

 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick




 --
 Best regards,
 Igor Stasenko.




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Suggested Syntax Highlighting Features for Beginners

[J.F. Rick]

I went ahead and created two cases in FogBugz for the respective issues:
https://pharo.fogbugz.com/f/cases/13186/Syntax-Highlighting-Distinguish-Assignment-and-Comparison
https://pharo.fogbugz.com/f/cases/13187/Syntax-Highlighting-Messages-with-2-Arguments

That way this issue won't be completely forgotten.


On Fri, Apr 4, 2014 at 7:26 PM, J.F. Rick s...@je77.com wrote:

 On Fri, Apr 4, 2014 at 6:41 PM, Ben Coman b...@openinworld.com wrote:

 For assignment, I would say bold both := and the variable being assigned
 to.


 I like that a lot, especially since it draws the two critical elements of
 variable and assignment together. On a minor note, both := and = are
 currently the same color: black. That only furthers the := is a message
 misconception. It might be worthwhile also giving := its own color, given
 its uniqueness.


 Underlining sounds interesting, but there are a few choices:
 a. nested underlining - self someMessage: (self otherMessage: arg 1 and:
 arg2) and: arg3
 b. non-nested underlining - only underline #otherMessage:and: and not
 #someMessage:and:
 c. dynamically underline only message where cursor is located.


 I think you could do nested underlining in the same way that nested blocks
 and parentheses work. someMessage: and the second and: are underlined in
 black. otherMessage: and the first and: are underlined in green. That way
 nesting is clear. This would also be useful for code with nested
 conditionals, probably the most common occurrence of nested multi-part
 messages. I also like (c) as a minimally intrusive change that could help
 novices when they write code. It has the disadvantage that novices couldn't
 look at a piece of foreign code and get where the multi-part messages were.

 Cheers,

 Jeff

 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] [Moose-dev] Re: Re: Re: Fwd: Font problem is still there

[J.F. Rick]

Woohoo! Works for me. You made my day.

In regards to determining the DPI of the display, can't we just set that as
a preference with a default value of 96? That would satisfy 98% of cases.
We could also add a primitive that would allow the VM to have its say
(e.g., retina display on MacOS). When that primitive fails, it would
default to the preference.

Cheers,

Jeff


On Fri, Apr 4, 2014 at 2:55 AM, Igor Stasenko siguc...@gmail.com wrote:

 Okay, i think i got it..

 Here is what happens:
 - the font size is usually specified in points, not x@y points, but
 typographical points,
 which is
 1/72 inch


 TextStyle pointsToPixels: 14

 TextStyle pointsToPixels: 14 = 18.668

 pointsToPixels: points
 ^points * self pixelsPerInch / 72.0


 but in Athens, i , stupid idiot, completely forgot about that,
 and use point size directly, to scale up font ..
 but the point is that this scaling performed in font units (EMs).

 so, to actually scale font correctly, i must use same TextStyle
 pointsToPixels: ..
 as Freetype package using..

 there is one caveat, that if you really want to see exactly , say 16
 points sized font on your screen,
 it is not possible without knowing the display resolution - how many
 pixels in one inch (hence
 #pixelsPerInch ).
 Unfortunately, our VMs don't give us a way to determine DPI of display..
 and so, it is always 96 :/

 pheww

 fromFreetypeFont: aFont cairoFace: face
 .

   -  fontMatrix scaleBy: aFont pointSize.

  +  fontMatrix scaleBy: (TextStyle pointsToPixels: aFont pointSize).

 problem solved ... (i hope) :)

 --
 Best regards,
 Igor Stasenko.




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Suggested Syntax Highlighting Features for Beginners

[J.F. Rick]

On Fri, Apr 4, 2014 at 6:41 PM, Ben Coman b...@openinworld.com wrote:

 For assignment, I would say bold both := and the variable being assigned
 to.


I like that a lot, especially since it draws the two critical elements of
variable and assignment together. On a minor note, both := and = are
currently the same color: black. That only furthers the := is a message
misconception. It might be worthwhile also giving := its own color, given
its uniqueness.


 Underlining sounds interesting, but there are a few choices:
 a. nested underlining - self someMessage: (self otherMessage: arg 1 and:
 arg2) and: arg3
 b. non-nested underlining - only underline #otherMessage:and: and not
 #someMessage:and:
 c. dynamically underline only message where cursor is located.


I think you could do nested underlining in the same way that nested blocks
and parentheses work. someMessage: and the second and: are underlined in
black. otherMessage: and the first and: are underlined in green. That way
nesting is clear. This would also be useful for code with nested
conditionals, probably the most common occurrence of nested multi-part
messages. I also like (c) as a minimally intrusive change that could help
novices when they write code. It has the disadvantage that novices couldn't
look at a piece of foreign code and get where the multi-part messages were.

Cheers,

Jeff

-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] [Moose-dev] Re: Re: Re: Fwd: Font problem is still there

[J.F. Rick]

Cool. I just loaded the latest NB and Athens (as Igor sent around) but my
image is not fully up to date. I'll try downloading a new one and reloading
my work from packages. I just wanted to make sure that this was worth the
effort. If that doesn't work, then I'll send Igor my image.

Cheers,

Jeff


On Wed, Apr 2, 2014 at 10:55 PM, Pharo4Stef pharo4s...@free.fr wrote:


 On 02 Apr 2014, at 14:46, J.F. Rick s...@je77.com wrote:

 Is this supposed to fix the font rendering problem or some other font
 problem? I tried it and it doesn't seem to help the rendering problem.


 normally it should fix the font PrObLem
 can you check that you loaded the latest NB?


 Cheers,

 Jeff


 On Tue, Apr 1, 2014 at 6:27 PM, Igor Stasenko siguc...@gmail.com wrote:

 okay i uploaded updated configs for NativeBoost and Athens into official
 repositories for these projects.

 Gofer new smalltalkhubUser: 'Pharo' project: 'NativeBoost';
 configuration;
 load.

 ConfigurationOfNativeBoost loadDevelopment.



 Gofer new smalltalkhubUser: 'Pharo' project: 'Athens';
 configuration;
 load.

 ConfigurationOfAthens loadDevelopment.


 shall do the trick..

 for more details see

 https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-different-platforms



 On 28 March 2014 21:13, Pharo4Stef pharo4s...@free.fr wrote:

 thanks Igor.
 I'm trying to look at the font reloading bug.


 On 28 Mar 2014, at 17:19, Igor Stasenko siguc...@gmail.com wrote:


 https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-different-platforms


 On 28 March 2014 16:42, Igor Stasenko siguc...@gmail.com wrote:

 so, the quick and dirty fix is to put:

 CairoGlyph classbyteAlignment

 NativeBoost platformId = NativeBoostConstants win32PlatformId
 ifTrue: [  ^ 8 ].
 ^ super byteAlignment

 and then:

 CairoGlyph rebuildFieldAccessors
 CairoGlyphsArray initialize

 (note you must run this snippet each time your image changes platform)..

 and i need more time to fix it for real, because it is NB issue, to
 automatically recalculate the structs size
 if it changes platform.. (which also means you cannot store instances
 of struct in image which survive the session)
 ... damn.. that's going to be complicated.

 ---



 On 28 March 2014 16:27, Igor Stasenko siguc...@gmail.com wrote:




 On 28 March 2014 16:01, Igor Stasenko siguc...@gmail.com wrote:


 Ookkayy..
 so, current status:

  - finally we got an agreement that big red square because of font
 loading issues and font rendering artifacts is two separate issues.
 Thanks!
 - i am not going to address font-loading issue here and now..
 (because we spent time on it earlier today with Stef already and you 
 should
 have the report on it in separate mail).

 - we seem to be agreed that it is best to use same (up-to-date
 version) of software when reporting issues to work on them. Thanks 
 again. :)

 - while on linux and mac things seem to be working fine, i can
 confirm that there is rendering artifacts (same as reported by Vincent) 
 on
 Windows.

 so i going to explore what causing this problem..

 ... and found the cause:

 On windows, for unknown reason, the structure (cairo_glyph_t) uses
 different memory space alignment than on mac and linux

 fieldsDesc
 ^ #(
 ulongindex;
 double   x;
 double   y;
 )

 on mac and linux , the size of this structure in memory = 4 + 8 + 8 =
 20 bytes,
 on windows, however, due to 8-byte alignment, it is  4 + 8 + 8 + (4
 alignment) bytes...

 this causing the effect that if you copy array of glyphs in memory,
 it does not copying whole array by slightly less  (because it uses
 wrong struct size which is smaller than it is)..
 and because of that, you got weird artefacts at the tail of string,
 replaced by misplaced/invalid characters etc..
 because it is basically read from uninitialized part of memory with
 random data.

 i going to fix structure alignment for windows from default 4 bytes to
 8 bytes..
 but this is not very good news.. because this affecting many things...
 (as you can imagine, not only cairo/athens working with external
 structures, which need to be properly aligned).

 --
 Best regards,
 Igor Stasenko.




 --
 Best regards,
 Igor Stasenko.




 --
 Best regards,
 Igor Stasenko.





 --
 Best regards,
 Igor Stasenko.




 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick





-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] [Moose-dev] Re: Re: Re: Fwd: Font problem is still there

[J.F. Rick]

Is this supposed to fix the font rendering problem or some other font
problem? I tried it and it doesn't seem to help the rendering problem.

Cheers,

Jeff


On Tue, Apr 1, 2014 at 6:27 PM, Igor Stasenko siguc...@gmail.com wrote:

 okay i uploaded updated configs for NativeBoost and Athens into official
 repositories for these projects.

 Gofer new smalltalkhubUser: 'Pharo' project: 'NativeBoost';
 configuration;
 load.

 ConfigurationOfNativeBoost loadDevelopment.



 Gofer new smalltalkhubUser: 'Pharo' project: 'Athens';
 configuration;
 load.

 ConfigurationOfAthens loadDevelopment.


 shall do the trick..

 for more details see

 https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-different-platforms



 On 28 March 2014 21:13, Pharo4Stef pharo4s...@free.fr wrote:

 thanks Igor.
 I'm trying to look at the font reloading bug.


 On 28 Mar 2014, at 17:19, Igor Stasenko siguc...@gmail.com wrote:


 https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-different-platforms


 On 28 March 2014 16:42, Igor Stasenko siguc...@gmail.com wrote:

 so, the quick and dirty fix is to put:

 CairoGlyph classbyteAlignment

 NativeBoost platformId = NativeBoostConstants win32PlatformId
 ifTrue: [  ^ 8 ].
 ^ super byteAlignment

 and then:

 CairoGlyph rebuildFieldAccessors
 CairoGlyphsArray initialize

 (note you must run this snippet each time your image changes platform)..

 and i need more time to fix it for real, because it is NB issue, to
 automatically recalculate the structs size
 if it changes platform.. (which also means you cannot store instances of
 struct in image which survive the session)
 ... damn.. that's going to be complicated.

 ---



 On 28 March 2014 16:27, Igor Stasenko siguc...@gmail.com wrote:




 On 28 March 2014 16:01, Igor Stasenko siguc...@gmail.com wrote:


 Ookkayy..
 so, current status:

  - finally we got an agreement that big red square because of font
 loading issues and font rendering artifacts is two separate issues.
 Thanks!
 - i am not going to address font-loading issue here and now.. (because
 we spent time on it earlier today with Stef already and you should have 
 the
 report on it in separate mail).

 - we seem to be agreed that it is best to use same (up-to-date
 version) of software when reporting issues to work on them. Thanks again. 
 :)

 - while on linux and mac things seem to be working fine, i can confirm
 that there is rendering artifacts (same as reported by Vincent) on 
 Windows.

 so i going to explore what causing this problem..

 ... and found the cause:

 On windows, for unknown reason, the structure (cairo_glyph_t) uses
 different memory space alignment than on mac and linux

 fieldsDesc
 ^ #(
 ulongindex;
 double   x;
 double   y;
 )

 on mac and linux , the size of this structure in memory = 4 + 8 + 8 =
 20 bytes,
 on windows, however, due to 8-byte alignment, it is  4 + 8 + 8 + (4
 alignment) bytes...

 this causing the effect that if you copy array of glyphs in memory,
 it does not copying whole array by slightly less  (because it uses
 wrong struct size which is smaller than it is)..
 and because of that, you got weird artefacts at the tail of string,
 replaced by misplaced/invalid characters etc..
 because it is basically read from uninitialized part of memory with
 random data.

 i going to fix structure alignment for windows from default 4 bytes to
 8 bytes..
 but this is not very good news.. because this affecting many things...
 (as you can imagine, not only cairo/athens working with external
 structures, which need to be properly aligned).

 --
 Best regards,
 Igor Stasenko.




 --
 Best regards,
 Igor Stasenko.




 --
 Best regards,
 Igor Stasenko.





 --
 Best regards,
 Igor Stasenko.




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Redraw suggestion for Athens

[J.F. Rick]

Sure. It's just a change to Pharo that a switch to Athens rendering could
enable. You couldn't quite do the same thing in BitBlt / current Morphic as
you would need three forms: one for rendering, one inactive one, and one
active one. Switching to Athens would make the V-Sync thing be quite
efficient as you wouldn't be copying large amount of bits from one form to
another on a regular basis.

Cheers,

Jeff


On Thu, Mar 27, 2014 at 5:09 PM, Igor Stasenko siguc...@gmail.com wrote:




 On 26 March 2014 20:22, J.F. Rick s...@je77.com wrote:

 I've been using Athens to render my applications and I've thought a bit
 about how the #changed mechanism might change when BitBlt rendering is
 replaced by Athens rendering. First, you must realize that a lot of the
 rendering in Morphic is highly specialized to deal with the slowness of
 BitBlt rendering. So, a morph that has changed in appearance (by moving,
 etc.) calls the #changed message on itself. This tells morphic that it
 needs to get rerendered when the screen is next being updated. The full
 bounds of the morph are then added to the damage recorder. When the UI loop
 gets around to it, the damage areas are rerendered in a relatively smart
 fashion. For instance, if a morph is opaque, none of the morphs behind it
 get rendered. Only the damage rectangles are copied to the canvas, which is
 then updated.

 With Athens, this strategy is problematic. Because Athens allows for
 arbitrary rotation and scaling, it is much more difficult to determine the
 bounds of a specific morph. Athens also can use local positioning as
 opposed to the global positioning currently used in Morphic. Igor argues
 that it is best not to try to figure this out but just to render everything
 when anything has changed. In my experience, that is a reasonable
 proposition. Athens rendering is fast enough that even full animation could
 be done reasonably. That would also simplify the #changed code and could
 pretty much eliminate the damage recorder.

 OK. That's enough setup. Now for the suggestion. One problem I still have
 with Athens rendering is that there is still a visual artifact that has to
 do with the screen refresh not being in sync with the UI loop. Half the
 screen renders the previous frame and the other half renders the current
 frame. While it only is noticeable when moving something fast, it still
 isn't nice. So, here's the suggestion. Have two Athens surfaces in memory
 that switch between being the one next to be rendered and the active one.
 When the screen refresh comes along, send it to the last one rendered
 (i.e., the active one). When a change happens, render the surface on the
 inactive one. When that is done, make it the active one. Thus, the screen
 update always has an accurate form. It also would mean less copying around
 of forms (i.e., cacheing). I'm not sure if this implementation is viable,
 but it seems like a fairly efficient strategy that Athens could enable.


 Right. This is something what called V-Sync. And all i can tell about it,
 that it is out of scope of Athens,
 because there's nothing in Athens API which tells where the results of
 drawing will be used: on screen, printed on paper, into file etc..
 Dealing with it requires another device-specific layer which controls it,
 in our case - the layer responsible for delivering content to the screen.
 Apparently for such layer (if it will appear one day - like in OSWindow),
 it should be completely orthogonal, where content comes from: from Athens,
 BitBlt or other source(s).






-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Font problem is still there

[J.F. Rick]

Ubuntu (latest) + Arial font (though other fonts have the same problem).

Cheers,

Jeff


On Thu, Mar 27, 2014 at 4:44 PM, Igor Stasenko siguc...@gmail.com wrote:

 Btw, guys i need some details:
  - what platform you using
  - what default font you using


 On 26 March 2014 21:27, Tudor Girba tu...@tudorgirba.com wrote:

 Thanks, indeed :)

 Please keep us informed.

 Doru


 On Wed, Mar 26, 2014 at 5:57 PM, Alexandre Bergel 
 alexandre.ber...@me.com wrote:

  I didn't tried to debug it, i can't bet it would be easy (need to
 build a debug version of cairo first)
  but it worth trying.
  Meanwhile i will put workaround back.

 Thanks Igor. Let us know!

 Alexandre


 
   Hi!
  
   there's some kind of caching interference either in cairo or
 between cairo and freetype,
   when using identity transformation matrix and integral (integer)
 font sizes.
   and there is a simple workaround:
  
   canvas pathTransform restoreAfter: [
   canvas pathTransform scaleBy: 1.1.
   draw text here
  
   ]
  
   this workaround was in font-rendering code, but then i removed it,
 because i thought problem was solved.
  
   Can we add this back please?
   This font problem is quite serious. It makes people laugh at Pharo...
 
 
 
 
  --
  Best regards,
  Igor Stasenko.

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







 --
 www.tudorgirba.com

 Every thing has its own flow




 --
 Best regards,
 Igor Stasenko.




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

[Pharo-dev] Redraw suggestion for Athens

[J.F. Rick]

I've been using Athens to render my applications and I've thought a bit
about how the #changed mechanism might change when BitBlt rendering is
replaced by Athens rendering. First, you must realize that a lot of the
rendering in Morphic is highly specialized to deal with the slowness of
BitBlt rendering. So, a morph that has changed in appearance (by moving,
etc.) calls the #changed message on itself. This tells morphic that it
needs to get rerendered when the screen is next being updated. The full
bounds of the morph are then added to the damage recorder. When the UI loop
gets around to it, the damage areas are rerendered in a relatively smart
fashion. For instance, if a morph is opaque, none of the morphs behind it
get rendered. Only the damage rectangles are copied to the canvas, which is
then updated.

With Athens, this strategy is problematic. Because Athens allows for
arbitrary rotation and scaling, it is much more difficult to determine the
bounds of a specific morph. Athens also can use local positioning as
opposed to the global positioning currently used in Morphic. Igor argues
that it is best not to try to figure this out but just to render everything
when anything has changed. In my experience, that is a reasonable
proposition. Athens rendering is fast enough that even full animation could
be done reasonably. That would also simplify the #changed code and could
pretty much eliminate the damage recorder.

OK. That's enough setup. Now for the suggestion. One problem I still have
with Athens rendering is that there is still a visual artifact that has to
do with the screen refresh not being in sync with the UI loop. Half the
screen renders the previous frame and the other half renders the current
frame. While it only is noticeable when moving something fast, it still
isn't nice. So, here's the suggestion. Have two Athens surfaces in memory
that switch between being the one next to be rendered and the active one.
When the screen refresh comes along, send it to the last one rendered
(i.e., the active one). When a change happens, render the surface on the
inactive one. When that is done, make it the active one. Thus, the screen
update always has an accurate form. It also would mean less copying around
of forms (i.e., cacheing). I'm not sure if this implementation is viable,
but it seems like a fairly efficient strategy that Athens could enable.

Cheers,

Jeff

-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] pharo sound should be working

[J.F. Rick]

Any ideas of how to go forward? It seems to work for some people on Linux
but not for me. Mine is Ubuntu 13.10 (64 bit). And I have all the
libasound2 libraries installed.

Cheers,

Jeff


On Tue, Mar 18, 2014 at 2:11 PM, J.F. Rick s...@je77.com wrote:

 I've tried the zeroconf script. It installs fine and it seems to work fine
 until I try to play sound. Then, it crashes. I get the following message in
 STD_OUT:
 sound_Start(default)
 sound_Start: snd_add_pcm_handler: Function not implemented
 ./pharo-ui: line 11: 5799 I/O possible $DIR/pharo-vm/pharo $@

 When I did pharo -help, I get the following as sound drivers:
 vm-sound-null
 vm-sound-ALSA

 This is on Ubuntu 13.10.

 Cheers,

 Jeff


 On Mon, Mar 17, 2014 at 5:40 PM, Esteban Lorenzano esteba...@gmail.comwrote:

 the ppa is not updated yet... this is a test version.
 you have to install libasound2i386 and  libasound2-plugins:i386.
 you get the vm with zeroconf: wget -O- get.pharo.org/vmLatest | bash

 Esteban

 On 17 Mar 2014, at 16:49, J.F. Rick s...@je77.com wrote:

 What would I need to do to install it on Ubuntu? Could I just use the
 PPA? If so, what are the commands?

 Cheers,

 Jeff


 On Mon, Mar 17, 2014 at 3:45 PM, Esteban Lorenzano 
 esteba...@gmail.comwrote:

 can you check with the latest vm now?

 btw... you need to install:

 sudo apt-get install libasound2-plugins:i386

 in order to prevent warnings.

 On 15 Mar 2014, at 00:03, Nicolai Hess nicolaih...@web.de wrote:

 2014-03-14 21:43 GMT+01:00 Esteban Lorenzano esteba...@gmail.com:

 Hi,

 so I committed some changes to allow soundplugin to work on the pharovm.
 can you please download and test in your platforms?


 Works on windows




 (remember, in linux you need libasound2 dependency installed)


 it does not work on linux Ubuntu 12.04.2 LTS
 (I have installed libasound2).

 Why don't we include the pulse config again and build the vm-sound-pulse
 module as well?
 As I described it in the issue 12493, vm-sound-oss is buildable too. But
 current
 linux distribution don't provide the older OSS sound system.
 (it worked for me with ubuntu 10.04 but not with 12.04)



 cheers,
 Esteban






 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick





 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] pharo sound should be working

[J.F. Rick]

Some more information. SoundPlayer boinkScale works. FMSound does not
work. When I try playing a sampled sound, I get the following message in
the terminal:
   sound_Start(default)
   soundStart: snd_add_pcm_handler: Function not implemented
It also crashes the VM.

It seems like this is a know issue: http://bugs.squeak.org/view.php?id=7328

Cheers,

Jeff


On Thu, Mar 20, 2014 at 9:44 AM, Esteban Lorenzano esteba...@gmail.comwrote:

 the 32bits version of them?
 I can create a parallels image and try there... no promises :)

 Esteban

 On 20 Mar 2014, at 09:42, J.F. Rick s...@je77.com wrote:

 Any ideas of how to go forward? It seems to work for some people on Linux
 but not for me. Mine is Ubuntu 13.10 (64 bit). And I have all the
 libasound2 libraries installed.

 Cheers,

 Jeff


 On Tue, Mar 18, 2014 at 2:11 PM, J.F. Rick s...@je77.com wrote:

 I've tried the zeroconf script. It installs fine and it seems to work
 fine until I try to play sound. Then, it crashes. I get the following
 message in STD_OUT:
 sound_Start(default)
 sound_Start: snd_add_pcm_handler: Function not implemented
 ./pharo-ui: line 11: 5799 I/O possible $DIR/pharo-vm/pharo $@

 When I did pharo -help, I get the following as sound drivers:
 vm-sound-null
 vm-sound-ALSA

 This is on Ubuntu 13.10.

 Cheers,

 Jeff


 On Mon, Mar 17, 2014 at 5:40 PM, Esteban Lorenzano 
 esteba...@gmail.comwrote:

 the ppa is not updated yet... this is a test version.
 you have to install libasound2i386 and  libasound2-plugins:i386.
 you get the vm with zeroconf: wget -O- get.pharo.org/vmLatest | bash

 Esteban

 On 17 Mar 2014, at 16:49, J.F. Rick s...@je77.com wrote:

 What would I need to do to install it on Ubuntu? Could I just use the
 PPA? If so, what are the commands?

 Cheers,

 Jeff


 On Mon, Mar 17, 2014 at 3:45 PM, Esteban Lorenzano 
 esteba...@gmail.comwrote:

 can you check with the latest vm now?

 btw... you need to install:

 sudo apt-get install libasound2-plugins:i386

 in order to prevent warnings.

 On 15 Mar 2014, at 00:03, Nicolai Hess nicolaih...@web.de wrote:

 2014-03-14 21:43 GMT+01:00 Esteban Lorenzano esteba...@gmail.com:

 Hi,

 so I committed some changes to allow soundplugin to work on the
 pharovm.
 can you please download and test in your platforms?


 Works on windows




 (remember, in linux you need libasound2 dependency installed)


 it does not work on linux Ubuntu 12.04.2 LTS
 (I have installed libasound2).

 Why don't we include the pulse config again and build the
 vm-sound-pulse module as well?
 As I described it in the issue 12493, vm-sound-oss is buildable too.
 But current
 linux distribution don't provide the older OSS sound system.
 (it worked for me with ubuntu 10.04 but not with 12.04)



 cheers,
 Esteban






 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick





 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick




 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick





-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] pharo sound should be working

[J.F. Rick]

Sometimes it doesn't crash it. So, I can attempt to play a sound multiple
times without it crashing. But, then, after a little time, it crashes.

Cheers,

Jeff


On Thu, Mar 20, 2014 at 11:26 AM, Esteban Lorenzano esteba...@gmail.comwrote:

 yeah, I'm checking that... it is probably not fixable in the release time :(
 is because alsa and pulseaudio have incompatibilities and it breaks the
 ALSA based sound system... I do not have the time to write a pulse sound.

 anyway... what is weird is that it crashes your vm, because it does not do
 that with mine.

 Esteban

 On 20 Mar 2014, at 11:21, J.F. Rick s...@je77.com wrote:

 Some more information. SoundPlayer boinkScale works. FMSound does not
 work. When I try playing a sampled sound, I get the following message in
 the terminal:
sound_Start(default)
soundStart: snd_add_pcm_handler: Function not implemented
 It also crashes the VM.

 It seems like this is a know issue:
 http://bugs.squeak.org/view.php?id=7328

 Cheers,

 Jeff


 On Thu, Mar 20, 2014 at 9:44 AM, Esteban Lorenzano esteba...@gmail.comwrote:

 the 32bits version of them?
 I can create a parallels image and try there... no promises :)

 Esteban

 On 20 Mar 2014, at 09:42, J.F. Rick s...@je77.com wrote:

 Any ideas of how to go forward? It seems to work for some people on Linux
 but not for me. Mine is Ubuntu 13.10 (64 bit). And I have all the
 libasound2 libraries installed.

 Cheers,

 Jeff


 On Tue, Mar 18, 2014 at 2:11 PM, J.F. Rick s...@je77.com wrote:

 I've tried the zeroconf script. It installs fine and it seems to work
 fine until I try to play sound. Then, it crashes. I get the following
 message in STD_OUT:
 sound_Start(default)
 sound_Start: snd_add_pcm_handler: Function not implemented
 ./pharo-ui: line 11: 5799 I/O possible $DIR/pharo-vm/pharo $@

 When I did pharo -help, I get the following as sound drivers:
 vm-sound-null
 vm-sound-ALSA

 This is on Ubuntu 13.10.

 Cheers,

 Jeff


 On Mon, Mar 17, 2014 at 5:40 PM, Esteban Lorenzano 
 esteba...@gmail.comwrote:

 the ppa is not updated yet... this is a test version.
 you have to install libasound2i386 and  libasound2-plugins:i386.
 you get the vm with zeroconf: wget -O- get.pharo.org/vmLatest | bash

 Esteban

 On 17 Mar 2014, at 16:49, J.F. Rick s...@je77.com wrote:

 What would I need to do to install it on Ubuntu? Could I just use the
 PPA? If so, what are the commands?

 Cheers,

 Jeff


 On Mon, Mar 17, 2014 at 3:45 PM, Esteban Lorenzano esteba...@gmail.com
  wrote:

 can you check with the latest vm now?

 btw... you need to install:

 sudo apt-get install libasound2-plugins:i386

 in order to prevent warnings.

 On 15 Mar 2014, at 00:03, Nicolai Hess nicolaih...@web.de wrote:

 2014-03-14 21:43 GMT+01:00 Esteban Lorenzano esteba...@gmail.com:

 Hi,

 so I committed some changes to allow soundplugin to work on the
 pharovm.
 can you please download and test in your platforms?


 Works on windows




 (remember, in linux you need libasound2 dependency installed)


 it does not work on linux Ubuntu 12.04.2 LTS
 (I have installed libasound2).

 Why don't we include the pulse config again and build the
 vm-sound-pulse module as well?
 As I described it in the issue 12493, vm-sound-oss is buildable too.
 But current
 linux distribution don't provide the older OSS sound system.
 (it worked for me with ubuntu 10.04 but not with 12.04)



 cheers,
 Esteban






 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick





 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick




 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick





 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick





-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] pharo sound should be working

[J.F. Rick]

What would I need to do to install it on Ubuntu? Could I just use the PPA?
If so, what are the commands?

Cheers,

Jeff


On Mon, Mar 17, 2014 at 3:45 PM, Esteban Lorenzano esteba...@gmail.comwrote:

 can you check with the latest vm now?

 btw... you need to install:

 sudo apt-get install libasound2-plugins:i386

 in order to prevent warnings.

 On 15 Mar 2014, at 00:03, Nicolai Hess nicolaih...@web.de wrote:

 2014-03-14 21:43 GMT+01:00 Esteban Lorenzano esteba...@gmail.com:

 Hi,

 so I committed some changes to allow soundplugin to work on the pharovm.
 can you please download and test in your platforms?


 Works on windows




 (remember, in linux you need libasound2 dependency installed)


 it does not work on linux Ubuntu 12.04.2 LTS
 (I have installed libasound2).

 Why don't we include the pulse config again and build the vm-sound-pulse
 module as well?
 As I described it in the issue 12493, vm-sound-oss is buildable too. But
 current
 linux distribution don't provide the older OSS sound system.
 (it worked for me with ubuntu 10.04 but not with 12.04)



 cheers,
 Esteban






-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Touch Events VM changes

[J.F. Rick]

Does that mean that normal mouse movement won't work with that VM? I have a
couple other things that take precedent but that does sound like it would
be worth playing with.

Cheers,

Jeff


On Tue, Mar 11, 2014 at 1:29 PM, Igor Stasenko siguc...@gmail.com wrote:

 Jeff, since you running linux you can look at what we have done with Ronie
 not long ago.
 Basically we changed VM and removed all window/event management code and
 instead do everything at image side.
 I think it would be good if you can try and add multi-touch events support
 to the code.

 If you wanna try, you need to build new VM first,
 and follow this:
 https://pharo.fogbugz.com/f/cases/12743/OSWindow-integration

 Then you can look at OSWindow package (its X11 part) and see what is
 needed to support multi-touch events.

 You should build VM from sources taken from here:
 https://github.com/ronsaldo/pharo-vm



 On 11 March 2014 11:37, J.F. Rick s...@je77.com wrote:

 As we move from mouse-keyboard devices to touch-based ones, it would be
 nice if we could unify touch development across the different Pharo
 platforms (iOS, Android, Windows 8, Linux, etc.), so that we can start to
 build touch-aware widgets and frameworks. Currently, there's a lot of
 interest but no unified movement. For instance, I've got a very nice
 multi-touch 27 computer that I run in Linux. I develop the applications in
 Pharo but I currently use a hack to get the touch events: I use OSProcess
 to start the mtdev2tuio application that takes touch input and sends it via
 TUIO. I then use a UDP socket to read the events on Pharo. If I am to share
 my work, I need to get beyond the hack. I (or rather Igor as I watched)
 investigated the possibility of using NativeBoost calls to do the same, but
 it would not work since mtdev2tuio has to run as superuser, meaning Pharo
 would have to run as superuser. We came to the conclusion that this must be
 a VM-level change.

 I'm not a VM hacker but would like to reach the people who maintain the
 linux and windows VM to see if this might not be a reasonable addition to
 the standard VM. There does seem to be standard support for touch events in
 XFree86, so it shouldn't be too large a change on Linux. I assume that
 Windows 8 similarly makes touch events available. Is this the right place
 to ask or is there another mailing list (e.g., the cog-vm)?

 Cheers,

 Jeff

 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick




 --
 Best regards,
 Igor Stasenko.




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

[Pharo-dev] Touch Events VM changes

[J.F. Rick]

As we move from mouse-keyboard devices to touch-based ones, it would be
nice if we could unify touch development across the different Pharo
platforms (iOS, Android, Windows 8, Linux, etc.), so that we can start to
build touch-aware widgets and frameworks. Currently, there's a lot of
interest but no unified movement. For instance, I've got a very nice
multi-touch 27 computer that I run in Linux. I develop the applications in
Pharo but I currently use a hack to get the touch events: I use OSProcess
to start the mtdev2tuio application that takes touch input and sends it via
TUIO. I then use a UDP socket to read the events on Pharo. If I am to share
my work, I need to get beyond the hack. I (or rather Igor as I watched)
investigated the possibility of using NativeBoost calls to do the same, but
it would not work since mtdev2tuio has to run as superuser, meaning Pharo
would have to run as superuser. We came to the conclusion that this must be
a VM-level change.

I'm not a VM hacker but would like to reach the people who maintain the
linux and windows VM to see if this might not be a reasonable addition to
the standard VM. There does seem to be standard support for touch events in
XFree86, so it shouldn't be too large a change on Linux. I assume that
Windows 8 similarly makes touch events available. Is this the right place
to ask or is there another mailing list (e.g., the cog-vm)?

Cheers,

Jeff

-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Touch Events VM changes

[J.F. Rick]

Definitely agreed on the strategy of processing the raw events on the image
side as that will be much more flexible. But, we still need the VM to send
the raw events.

I'll check on the vm-dev list. I think I'm already subscribed to it.

Cheers,

Jeff


On Tue, Mar 11, 2014 at 12:03 PM, Esteban Lorenzano esteba...@gmail.comwrote:

 Hi,

 I agree that we need a unified event model. Now... our vision is to solve
 that in image side, not in vm (and vm should send the raw events as is).
 The reason of why we want it in image is easy: image means pharo, and it
 means more hands (or eyes) over it. Then is easier to maintain :)
 Anyway, we are slowly working on it (See Igor  Ronnie work around
 OSWindow). But is probably too slow :)

 Esteban

 On 11 Mar 2014, at 11:37, J.F. Rick s...@je77.com wrote:

 As we move from mouse-keyboard devices to touch-based ones, it would be
 nice if we could unify touch development across the different Pharo
 platforms (iOS, Android, Windows 8, Linux, etc.), so that we can start to
 build touch-aware widgets and frameworks. Currently, there's a lot of
 interest but no unified movement. For instance, I've got a very nice
 multi-touch 27 computer that I run in Linux. I develop the applications in
 Pharo but I currently use a hack to get the touch events: I use OSProcess
 to start the mtdev2tuio application that takes touch input and sends it via
 TUIO. I then use a UDP socket to read the events on Pharo. If I am to share
 my work, I need to get beyond the hack. I (or rather Igor as I watched)
 investigated the possibility of using NativeBoost calls to do the same, but
 it would not work since mtdev2tuio has to run as superuser, meaning Pharo
 would have to run as superuser. We came to the conclusion that this must be
 a VM-level change.

 I'm not a VM hacker but would like to reach the people who maintain the
 linux and windows VM to see if this might not be a reasonable addition to
 the standard VM. There does seem to be standard support for touch events in
 XFree86, so it shouldn't be too large a change on Linux. I assume that
 Windows 8 similarly makes touch events available. Is this the right place
 to ask or is there another mailing list (e.g., the cog-vm)?

 Cheers,

 Jeff

 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick





-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Touch Events VM changes

[J.F. Rick]

Hi Sergi,

Based on my experience developing touch interfaces since 2007, I believe in
touch. I believe it will be the future of interfaces and I believe it can
be better than mouse-keyboard interfaces. That said, it is not there yet.
Now is the time to innovate and get it there so that touch interfaces won't
be poor replicas of their desktop forebears. Currently, text entry is a
real problem for touch exclusive devices, but there is progress being made
on that front. We don't have the answer yet but I think it will be a
significantly different landscape in five years. In regards to touch vs
physical pointers, this is not as large of a problem as people make it out
to be. It is just that our widgets tend to be created for mouse-based
interfaces and therefore don't transition well to touch. Interfaces
designed with touch in mind can be just as smooth (if not smoother) as
mouse-based interfaces. You just have to take advantage of what touch does
well (faster, more precise routes; multi-touch gestures; bimanual
interaction) and stay clear of things it does poorly (precise touch down,
covering the target with the finger).

Cheers,

Jeff


On Tue, Mar 11, 2014 at 12:34 PM, Sergi Reyner sergi.rey...@gmail.comwrote:

 2014-03-11 10:37 GMT+00:00 J.F. Rick s...@je77.com:

 As we move from mouse-keyboard devices to touch-based ones


 I certainly hope that we refers to a small group of people, unless we
 get onscreen keyboards as good as physical ones, feedback included. The
 same goes for touch versus physical pointer :)

 Cheers,
 Sergi




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] how can I test soundplugin?

[J.F. Rick]

Yes, load PharoSound and do the following:

SoundPlayer boinkScale.
SoundService soundEnabled.
SoundService registeredClasses.
SoundService reset.
BaseSoundSystem soundEnabled: true.
SoundService default.
ss := SoundService default new.
ss class soundEnabled.
ss class soundEnabled: true.
ss beep.
(FMSound lowMajorScaleOn: FMSound pluckedElecBass) play.
(FMSound lowMajorScaleOn: FMSound randomWeird1) play.
(FMSound majorScaleOn: FMSound oboe1) play.
FMSound testFMInteractively.
(SampledSound bachFugueVoice2On: SampledSound new) play.
SoundPlayer shutDown

SoundPlayer boinkScale.
SoundService soundEnabled.
BaseSoundSystem soundEnabled: true.
FMSound testFMInteractively.

sound := FMSound pitch: 'a4' dur: 1.0 loudness: 0.4.
sound play.

SoundService default new class soundEnabled: true.
(FMSound pitch: 'a4' dur: 1.0 loudness: 0.4) play


On Mon, Mar 10, 2014 at 5:33 PM, Esteban Lorenzano esteba...@gmail.comwrote:

 Hi,

 I'm working on the SoundPlugin (finally!) and I would like to know how can
 I test that is working.
 Is there a package or a script that I can execute to see if it is working?

 cheers,
 Esteban




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

[Pharo-dev] AthensCanvas isVisible:

[J.F. Rick]

I'm trying to make the most of Athens rendering. One problem is that
AthensCanvas currently does not support clipping. In normal Morphic, when
an object changes its appearance, a changed message triggers the damage
recorder to mark the full bounds as invalid. On the next redraw cycle, a
canvas is sent around with a clipRect that is equivalent to the damaged
area. Morphs not intersecting that clipRect are not drawn. This is a fairly
efficient process.

Currently, AthensCanvas does not seem to have a clipRect. When an
AthensCanvas gets sent the isVisible: message, it returns true. That means
all elements are drawn for any update cycle. That's inefficient. I've got a
fairly complex application. Instead of the five elements that are necessary
to redraw, I get all 100. Now, Athens is so fast that it mainly makes up
for that. But, a 20x inefficiency is not a good thing to include in the
system.

Are there plans to introduce a clipRect functionality into Athens? I
noticed that isVisible: is called in the fullDrawOnAthensCanvas:
method, which leads me to think that it should have a meaning (eventually).
I do realize that such functionality is a bit more difficult for Athens as
it uses relative, rather than global coordinates.

Cheers,

Jeff

-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Fwd: [Moose-dev] Text Displaying issue with Roassal

[J.F. Rick]

Here's an updated bug for this:
https://pharo.fogbugz.com/f/cases/12777/Athens-font-cacheing-bug

Cheers,

Jeff


On Tue, Feb 25, 2014 at 2:33 PM, Vincent Blondeau 
vincent.blond...@polytech-lille.net wrote:

  Hi Pharoers,

 We are encounter a problem with text displaying under Roassal.
 Roassal is a Moose tool to make some graphics visualisations, principally
 graphs.
 Some visualisations are displaying some text, like :

 - ROMondrianExample new centeredText
 - ROMondrianExample new temporaryEdges
 - ROMondrianExample new labeledRectangle

 They use AthensCanvas to render.

 Since the beginning of February, we experiment very strange problems with
 font displaying. See by yourself :

 What we expect :

 What we have :

 You can see that the letters in each word are not of the same size.
 (To reproduce do : ROMondrianExample new labeledRectangle in a fresh
 Moose image :
 https://ci.inria.fr/moose/job/moose-5.0/lastSuccessfulBuild/artifact/moose-5.0.zip
 )

 We thought it was a font problem. So we updated the fonts to use this one
 :
 LogicalFont familyName: StandardFonts defaultFont familyName pointSize:
 aSize
 which is the default system font. (The fonts are located in
 ROFontOrganizerAthens).

 But the problem was not solved.

 After some searches, we saw that Roassal (via the ROAthensCanvas) uses
 AthensCairoCanvas and this class has been changed begin February to use
 native boost.
 The closed issue related is :

 12765 Athens font rendering missing letters and missizing others
 https://pharo.fogbugz.com/f/cases/12765

 That should resolve the problem instead of created one ;)


 So if we load the older packages of Athens-Core and Athens-Cairo (before
 the issue resolution):

 Name: Athens-Core-MarcusDenker.34
 Author: MarcusDenker
 Time: 5 July 2013, 10:59:47.206954 am
 UUID: e844b2d4-b091-42a4-9be0-17101dcdbd30
 Ancestors: Athens-Core-MarcusDenker.33, Athens-Core-ErwanDouaille.33

 Name: Athens-Cairo-MarcusDenker.51
 Author: MarcusDenker
 Time: 26 August 2013, 4:03:06.190096 pm
 UUID: 9e1bfddb-67f7-4a36-864d-11060b8b6881
 Ancestors: Athens-Cairo-SebastianTleye.50

 we have no problem of font displaying !

 The question is :
 What we should adapt in Roassal to support this new implementation of
 Athens ? Or is Athens (by the native boost primitives) broken ?

 Thanks in advance !


 Vincent BLONDEAU






-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick
inline: image/pnginline: image/png

Re: [Pharo-dev] Fwd: [Moose-dev] Text Displaying issue with Roassal

[J.F. Rick]

Thanks, but the keyboard design is basically ripping off iOS and Android.
Once it works, I'll share.

Cheers,

Jeff


On Tue, Feb 25, 2014 at 3:52 PM, Tudor Girba tu...@tudorgirba.com wrote:

 This is a beautiful looking keyboard :)

 Doru


 On Tue, Feb 25, 2014 at 2:45 PM, J.F. Rick s...@je77.com wrote:

 Here's an updated bug for this:
 https://pharo.fogbugz.com/f/cases/12777/Athens-font-cacheing-bug

 Cheers,

 Jeff


 On Tue, Feb 25, 2014 at 2:33 PM, Vincent Blondeau 
 vincent.blond...@polytech-lille.net wrote:

  Hi Pharoers,

 We are encounter a problem with text displaying under Roassal.
 Roassal is a Moose tool to make some graphics visualisations,
 principally graphs.
 Some visualisations are displaying some text, like :

 - ROMondrianExample new centeredText
 - ROMondrianExample new temporaryEdges
 - ROMondrianExample new labeledRectangle

 They use AthensCanvas to render.

 Since the beginning of February, we experiment very strange problems
 with font displaying. See by yourself :

 What we expect :

 What we have :

 You can see that the letters in each word are not of the same size.
 (To reproduce do : ROMondrianExample new labeledRectangle in a fresh
 Moose image :
 https://ci.inria.fr/moose/job/moose-5.0/lastSuccessfulBuild/artifact/moose-5.0.zip
 )

 We thought it was a font problem. So we updated the fonts to use this
 one :
 LogicalFont familyName: StandardFonts defaultFont familyName pointSize:
 aSize
 which is the default system font. (The fonts are located in
 ROFontOrganizerAthens).

 But the problem was not solved.

 After some searches, we saw that Roassal (via the ROAthensCanvas) uses
 AthensCairoCanvas and this class has been changed begin February to use
 native boost.
 The closed issue related is :

 12765 Athens font rendering missing letters and missizing others
 https://pharo.fogbugz.com/f/cases/12765

 That should resolve the problem instead of created one ;)


 So if we load the older packages of Athens-Core and Athens-Cairo (before
 the issue resolution):

 Name: Athens-Core-MarcusDenker.34
 Author: MarcusDenker
 Time: 5 July 2013, 10:59:47.206954 am
 UUID: e844b2d4-b091-42a4-9be0-17101dcdbd30
 Ancestors: Athens-Core-MarcusDenker.33, Athens-Core-ErwanDouaille.33

 Name: Athens-Cairo-MarcusDenker.51
 Author: MarcusDenker
 Time: 26 August 2013, 4:03:06.190096 pm
 UUID: 9e1bfddb-67f7-4a36-864d-11060b8b6881
 Ancestors: Athens-Cairo-SebastianTleye.50

 we have no problem of font displaying !

 The question is :
 What we should adapt in Roassal to support this new implementation of
 Athens ? Or is Athens (by the native boost primitives) broken ?

 Thanks in advance !


 Vincent BLONDEAU






 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick




 --
 www.tudorgirba.com

 Every thing has its own flow




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick
inline: image/pnginline: image/png

[Pharo-dev] Animation by Stepping

[J.F. Rick]

Athens graphics are fast enough that it is possible to do high frame-rate
animations. I've been trying (and, to various degrees, succeeding) in
adding animations to my touch applications. I'm using stepping to do it.
Basically, you just move pieces / update the display when step gets called.
If you set the stepTime to 30, you should get somewhere around 30 frames
per second, which is quite smooth.

The problem I have is that the step mechanism in Pharo seems to block out
the UI thread. In Squeak, you could return 0 for the stepTime message and
then step would get called each UI cycle. In Pharo, the two seem to be
disconnected. If the stepTime is too low, the processor will be busy doing
redrawing and the UI loop is stopped. When I do stepTime of 20, the UI
stops responding until after the animation is over. When I do stepTime of
50, the UI keeps working. The lower the stepTime, the smoother the
animation, but also the chance that the UI becomes unresponsive. That's a
nasty tradeoff. Is there a good way to do step style animation without this
tradeoff? Why was stepping and the UI loop separated? Is there a different
way that animation should be implemented?

Cheers,

Jeff

-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Animation by Stepping

[J.F. Rick]

Thanks for that. Based on that, I investigated a bit further. It seems to
be a touch UI problem. I'm using TUIO to read touch events. When doing
animations, the OSC process (at user background priority) fails to trigger.
I need to change how I use the OSCServer.

Cheers,

Jeff


On Thu, Feb 20, 2014 at 5:48 PM, p...@highoctane.be p...@highoctane.bewrote:

 I've done such a kind of app (without Athens but with Morphic) on the iPad.

 I works nicely.

 Now, MorphicUIManagerspawnNewProcess tells us:

 spawnNewProcess

 UIProcess := [
 [World doOneCycle.  Processor yield.  false] whileFalse: [].
  ] newProcess priority: Processor userSchedulingPriority.
 UIProcess name: 'Morphic UI process'.
  UIProcess resume


 So, World doOneCycle forever.

 World being a PasteUpMorph

 then we enter this ping pong of double dispatches in the the doOneCycle (I
 think this could be utterly simplified but hey, it takes courage to go in
 there. I've got my own scribbled map but it would take quite a while to
 change things. Add to that that Stef and Igor appear to be working on some
 event internals so that all of the previous knowledge will be moot...)


 PasteUpMorphdoOneCycle
   worldState doOneCycleFor: self

 with worldState being a WorldState

 at one point, the worldState will call the WorlddrawOn: aCanvas

 Which happens under:

 WorldStatedoOneCycleNowFor: aWorld
 Immediately do one cycle of the interaction loop.
  This should not be called directly, but only via doOneCycleFor:

 DisplayScreen checkForNewScreenSize.

 process user input events
 LastCycleTime := Time millisecondClockValue.
 self handsDo: [:h |
  ActiveHand := h.
 h processEvents.
 ActiveHand := nil
  ].

 the default is the primary hand
 ActiveHand := self hands first.

 aWorld runStepMethods. there are currently some variations here
 self displayWorldSafely: aWorld.

 runStepMethods call into the runLocalStepMethodsIn: aWorld

 where all kinds of old things show up (like priorWorld where we do not
 have that anymore, as we only have one nowà.

 and where the stepList is also processed and this:

 (now  lastStepTime or: [now - lastStepTime  5000])
 ifTrue: [self adjustWakeupTimes: now]. clock slipped

 takes place (I wonder why, someone can explain?)

 And if the stepList isn't empty, it will go through all step methods:

 [stepList isEmpty not and: [stepList first scheduledTime  now]]
  whileTrue:
 [lastStepMessage := stepList removeFirst.
 morphToStep := lastStepMessage receiver.
  (morphToStep shouldGetStepsFrom: aWorld)
 ifTrue:
 [lastStepMessage value: now.
  lastStepMessage ifNotNil:
 [stepTime := lastStepMessage stepTime ifNil: [morphToStep stepTime].
  lastStepMessage scheduledTime: now + (stepTime max: 1).
 stepList add: lastStepMessage]].
 lastStepMessage := nil].
  lastStepTime := now.


 Ah, now + (stepTime max: 1)... guess that zero will not cut it then.
 Minimum stepTime will at least be one.

 This explains that I guess.

 The Squeak 4.3 doOneCycleNowFor: aWorld is more or less similar (it has a
 capturingGesture thing but without effect).

 And the stepTime has also the max:1 thing.

 runLocalStepMethodsIn: aWorld
 Run morph 'step' methods (LOCAL TO THIS WORLD) whose time has come. Purge
 any morphs that are no longer in this world.
  ar 3/13/1999: Remove buggy morphs from the step list so that they don't
 raise repeated errors.

 | now morphToStep stepTime priorWorld |
  now := Time millisecondClockValue.
 priorWorld := ActiveWorld.
 ActiveWorld := aWorld.
  self triggerAlarmsBefore: now.
 stepList isEmpty
 ifTrue:
  [ActiveWorld := priorWorld.
 ^self].
 (now  lastStepTime or: [now - lastStepTime  5000])
  ifTrue: [self adjustWakeupTimes: now]. clock slipped
 [stepList isEmpty not and: [stepList first scheduledTime  now]]
  whileTrue:
 [lastStepMessage := stepList removeFirst.
 morphToStep := lastStepMessage receiver.
  (morphToStep shouldGetStepsFrom: aWorld)
 ifTrue:
 [lastStepMessage value: now.
  lastStepMessage ifNotNil:
 [stepTime := lastStepMessage stepTime ifNil: [morphToStep stepTime].
  lastStepMessage scheduledTime: now + (stepTime max: 1).
 stepList add: lastStepMessage]].
 lastStepMessage := nil].
  lastStepTime := now.
 ActiveWorld := priorWorld


 So, I wonder why it would be different in Squeak.

 HTH

 Phil



















 On Thu, Feb 20, 2014 at 5:16 PM, J.F. Rick s...@je77.com wrote:

 Athens graphics are fast enough that it is possible to do high frame-rate
 animations. I've been trying (and, to various degrees, succeeding) in
 adding animations to my touch applications. I'm using stepping to do it.
 Basically, you just move pieces / update the display when step gets called.
 If you set the stepTime to 30, you should get somewhere around 30 frames
 per second, which is quite smooth.

 The problem I have is that the step mechanism in Pharo seems to block out
 the UI thread. In Squeak, you could return 0 for the stepTime message and
 then step would get called each UI cycle. In Pharo, the two seem

Re: [Pharo-dev] Animation by Stepping

[J.F. Rick]

This is on a Dell XPS1 running Linux. I'm familiar withe the iOS event
handling.

Cheers,

Jeff

On Thursday, February 20, 2014, p...@highoctane.be p...@highoctane.be
wrote:

 Rick,

 What OS are you using TUIO/OSC on?

 If you do iPad stuff, you do not need that as the iOS VM and image can
 support touch.

 Phil





 On Thu, Feb 20, 2014 at 6:51 PM, kilon alios kilon.al...@gmail.comwrote:

 Interesting topic, there is also this

 http://www.smalltalkhub.com/#!/~vmariano/Pegasus

 but I have not used it so I cant say how usable it is.


 On Thu, Feb 20, 2014 at 7:46 PM, J.F. Rick s...@je77.com wrote:

 Thanks for that. Based on that, I investigated a bit further. It seems to
 be a touch UI problem. I'm using TUIO to read touch events. When doing
 animations, the OSC process (at user background priority) fails to trigger.
 I need to change how I use the OSCServer.

 Cheers,

 Jeff


 On Thu, Feb 20, 2014 at 5:48 PM, p...@highoctane.be p...@highoctane.bewrote:

 I've done such a kind of app (without Athens but with Morphic) on the iPad.

 I works nicely.

 Now, MorphicUIManagerspawnNewProcess tells us:

 spawnNewProcess

 UIProcess := [
 [World doOneCycle.  Processor yield.  false] whileFalse: [].
  ] newProcess priority: Processor userSchedulingPriority.
 UIProcess name: 'Morphic UI process'.
  UIProcess resume


 So, World doOneCycle forever.

 World being a PasteUpMorph

 then we enter this ping pong of double dispatches in the the doOneCycle (I
 think this could be utterly simplified but hey, it takes courage to go in
 there. I've got my own scribbled map but it would take quite a while to
 change things. Add to that that Stef and Igor appear to be working on some
 event internals so that all of the previous knowledge will be moot...)


 PasteUpMorphdoOneCycle
   worldState doOneCycleFor: self

 with worldState being a WorldState

 at one point, the worldState will call the WorlddrawOn: aCanvas

 Which happens under:

 WorldStatedoOneCycleNowFor: aWorld
 Immediately do one cycle of the interaction loop.
  This should not be called directly, but only via doOneCycleFor:

 DisplayScreen checkForNewScreenSize.

 process user input events
 LastCycleTime := Time millisecondClockValue.
 self handsDo: [:h |
  ActiveHand := h.
 h processEvents.
 ActiveHand := nil
  ].

 the default is the primary hand
 ActiveHand := self hands first.

 aWorld runStepMethods. there are currently some variations here
 self displayWorldSafely: aWorld.

 runStepMethods call into the runLocalStepMethodsIn: aWorld

 where all kinds of old thi



-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

[Pharo-dev] Amber Suggested Use

[J.F. Rick]

It would be cool to use Pharo / Amber to do something like the following:
http://flapmmo.com

Cheers,

Jeff

-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Why Smalltalk is not popular?

[J.F. Rick]

Well, there are some serious reasons that Smalltalk is not currently so
popular. Here are a few:
(1) It used to be expensive. That kept it from being adopted initially.
That may no longer be the case but, once the reputation is ruined, it is
hard for people to give it a second chance.
(2) There is no natural bias built in. Want to program in the browser?
Learn Javascript. Want to program on the server? Learn PHP. Want to take
the AP CS exam in the US? Learn Java. Want to program for MacOS / iOS?
Learn Objective C. Want to use the Microsoft Developer Suite? Learn C#.
Want to bind to the largest set of libraries? Learn C. There is no killer
application domain for Smalltalk.
(3) The syntax is significantly different than languages people are
familiar with. In addition, the IDE is quite different. So, transitioning
is difficult.
(4) There's a Catch-22. People who want to employ Smalltalk programmers
can't find any, so they switch to some language they can find (e.g., Java).
Then, nobody bothers to learn Smalltalk because they perceive as no demand.

I think there's a real possibility that Pharo can overcome these obstacles
in a meaningful way. The web technologies part is so strong already that it
could easily be the next Ruby on Rails (i.e., comes out of nowhere to gain
real market share by doing one thing really well). The simplicity and live
coding ability could also make it a very nice teaching language, but
significant work will need to be done to make it that.

Cheers,

Jeff


On Wed, Feb 12, 2014 at 5:14 PM, kilon alios kilon.al...@gmail.com wrote:

 frankly I find the community here, extremely friendly , well motivated,
 reasonable and humble. And I dont let a couple of incidents per year change
 my mind of what happens here on a daily basis.

 Smalltalk is unpopular because it never had a big company behind it or a
 good marketing strategy. 99% of people out there, had, have and will have
 no clue what smalltalk is all about.

 You want to talk about ObjC ? fine . Lets be honest , objc was like 42th
 most popular language in TIOBE and now is like 3rd. Why ? because iOS.
 Thats all, not because of quality of the language , not because it has
 super friendly community , not because users saw the light.

  The only thing that ObjC shares with smalltalk is message passing. Does
 that make ObjC part of the family , eh , no. Unless you are prepared to let
 tons other languages and IDEs join you, but then you still wont have a
 family but a nation. And ObjC is a seriously ugly language. Its still no
 C++ , Javascript , Perl or PHP, but its ugly. Smalltalk is gorgeous.

 Also dont put too much emphasis on popularity. Java library is super
 popular and many of its libraries are a big pile of mess. Its quantity vs
 quality. C++ is on the same boat. Popularity gives you mainly quantity.

 My advice is don't be humble, be proud of your work and what you have
 accomplished with Pharo and your individual project. And if sometimes
 things go south , remember its much better to be passionate than being
 dull. Its all part of being human. Keep an open mind, and keep walking ,
 one step at a time.


 On Wed, Feb 12, 2014 at 5:40 PM, Sven Van Caekenberghe s...@stfx.euwrote:


 On 12 Feb 2014, at 14:54, askoh as...@askoh.com wrote:

  The recent arguments in Smalltalk made me have an Eureka moment on why
  Smalltalk is not popular. Smalltalk attracts brilliant people. But these
  brilliant people scare others away. Instead of Showing How, they Show
 Off.
  Instead of being inclusive, they are picky. Instead of discussing, they
  fight.
 
  So, Smalltalkers, please be humble, friendly and pacific. Show How.
 Invite
  anyone interested to join. And let's talk normally.

 I agree, of course. (With the second paragraph, less with the first:
 these discussion happen everywhere, ever read emails by Linus Torvalds ?)

 --

 But I had an epiphany today, based on this discussion of what is the
 definition of Smalltalk. I hereby declare that we are the _third_ most
 popular language (family) in use today !

 Based on this very reputable (ahem) index:

   http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

 I really think that in a broad definition of Smalltalk, Objective-C is
 part of the family.

 According to the first line of

   http://en.wikipedia.org/wiki/Objective-C

 Objective-C is a general-purpose, object-oriented programming language
 that adds Smalltalk-style messaging to the C programming language.

 And messaging is at the core of Smalltalk. It also has a similar class
 based object model, is late bound in almost everything and has some
 reflective capabilities. There are even a couple of projects mixing the two
 explicitly.

 Reserve a bigger venue for the next ESUG !

 Sven

 PS: We've had these discussions before on various occasions: it is really
 hard to come up with a definition of what is Smalltalk, or even a good list
 of what is so special about it - there really is a elusive, hard to define
 

Re: [Pharo-dev] Shortcuts

[J.F. Rick]

I actually just reported this bug to FogBugz today. Try doing it twice in a
row and see if that gets you what you want. If so, that matches my
experience on Ubuntu. Investigating a bit further, it seems that ctrl and
command are different for different platforms. Try doing alt-f and see if
that works. It could be that we are using the wrong modifier. It is strange
that both modifiers work for do it or print it but not for find.

Cheers,

Jeff


On Wed, Feb 5, 2014 at 2:26 PM, Diego Lont diego.l...@delware.nl wrote:

 Hi all,

 I am probably a stupid user, but I cannot use the new short-cuts that are
 default everywhere. Because currently when I press crtl-x or crtl-f,
 nothing happens, so I assume they are broken.

 I have learned that when I type a short-cut, this should give visual
 feedback. So when I press crtl-x (or cmd-x on my mac), I would expect a
 visual aid that tells me what I can delete. class xxx, method yyy, etc.
 This way I hope I can find my shortcuts again.

 Diego




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] process to collaborate on cleaning morphic

[J.F. Rick]

On Wed, Jan 29, 2014 at 3:36 PM, Pavel Krivanek pavel.kriva...@gmail.comwrote:

 I would like to continue in the direction started with the Morphic-Core.
 It's a subset of Morphic that is able to be loaded into a headless image,
 initialize itself and show world with one basic responsive morph.


There's a question of what is necessary for a modern GUI core. To me, we
need to get out of BitBlt rendering completely and towards vectors.
Reliance on BitBlt makes Pharo seem slow and outdated. Pixelation is so
early 1990s. Novices also don't understand that a slow GUI isn't indicative
of everything being slow. There's no reason Pharo's UI can't be fast enough
that you can't tell the difference between it and a native app. That would
do a lot to make Pharo more palatable to newcomers. First impressions are
critical.

We should also make it easy for people to build animations and build them
into the core tools (when it makes sense). Most modern OSs feature great
support for animation. Even if these things are largely eye candy, they do
change people's perceptions. I'd love to be able to do something like this:
   aMorph resizeToBounds: (100 @ 100 extent: 200 @ 200) inSeconds: 2.
Speaking of which, it would be nice if orientation could be included into
the equation. Perhaps support for affine transforms would be standard.
There also should be substantial support for vector graphics. The Athens
SVG input is a good step forward, but I'd like to see something that seems
very Pharo-native and that can be exported to SVG, rather than something
that seems very close to SVG XML (as is now the case). Ideally, I'd like to
do the old demo of rotating a browser and still using it but have it still
look smooth (i.e., no pixelation).

Another thing to perhaps address is how morphs are controlled and resized.
Currently, when we change the extent, then the top left corner remains the
same. For most cases, keeping the center the same would be more intuitive;
 does that and is fairly easy for programming novices to use. It would
also allow us to combine rotation and scaling in some ways:
   aMorph rotateAndScaleBottomLeftTo: 300 @ 20. keep the center stationary

Cheers,

Jeff

-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Athens Font Problem

[J.F. Rick]

Weirdly enough, the problem seems to be slowly solving itself. It is as
though, when a font size is used for the first time, that it piggybacks off
an existing size. I'm not sure what gets some characters to correspond
correctly while others are the wrong size.

Cheers,

Jeff


On Fri, Jan 24, 2014 at 6:53 PM, J.F. Rick s...@je77.com wrote:

 While trying to use fonts with Athens is no longer crashing my up-to-date
 Ubuntu Pharo image (sweet!), there is a weird phenomenon of fonts varying
 in size. I've created some simple code to showcase it and capture what it
 looks like:

 Cheers,

 Jeff

 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] process to collaborate on cleaning morphic

[J.F. Rick]

I've spent a considerable amount of time fighting with Morphic trying to
get TouchUI and Athens rendering working. Based on that, my feeling is that
getting Athens thoroughly integrated into Morphic is key. The way Morphic
used to work is that a morph would signal itself as changed, marking its
bounds as needing to get redrawn. Once a UI cycle, all the dirty areas
would get summed together and any morphs within those bounds would be asked
to redraw. Part of the way this worked is by using a clipping canvas. Thus,
a morph could decide whether it or its submorphs needed to get drawn based
on the clipping area. This was a quite efficient process.

Using AthensWrapMorph to move my applications to Athens, I've seen how the
speed advantages of Athens can disappear without such a process. Since
there is no clipping canvas, all morphs get redrawn for each draw cycle.
Compounding the problem, each changed message triggers a redraw. While
Athens rendering can be blazingly fast, doing it 48 (actual number for one
of my apps) times as many times as necessary does make it seem slow.

Another problem is with animation. Athens gives us the possibility to do
some really nice animations. So far, I haven't found a way to do these in a
way where it doesn't block out the interface. Having support for animations
that don't slow down the interface would be a great ground competency to
have for Morphic.

To me, integrating Athens thoroughly into Morphic and allowing Morphic to
take advantage of the speed and flexibility is the next step. After that,
event handling should be addressed. Debugging events is a giant pain and
part of it is that there is a ton of reflection and event handling
happening in an event handler rather than the object itself. Sometimes it
isn't clear how the event handler is being created and trying to figure out
where something is set becomes frustrating.

Anyway, that's my experience.

Jeff



On Sat, Jan 25, 2014 at 10:30 PM, Pharo4Stef pharo4s...@free.fr wrote:


 Sean
 I’m trying to understand how we could work together to share forces on
 cleaning morphic.
 Now it is not easy because some of the changes are crosscutting many
 packages.
 If somebody has an idea.

 Stef




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

[Pharo-dev] Nautilus UI Improvement Suggestion

[J.F. Rick]

Someone complained about the History Navigator being in an unintuitive
position a while back. What about moving the functionality into the title.
Add a drop down or list icon to the right of the title and clicking on that
can be used to navigate it. As it currently is, the title and the History
Navigator pretty much show the same thing.

Cheers,

Jeff

-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Pharo 3.0 not responding to mouse or keyboard after launch

[J.F. Rick]

Try just hitting Alt without anything else. That has worked for me on Linux.

Jeff

On Saturday, January 11, 2014, Martin McClure wrote:

 On 01/10/2014 09:15 PM, Martin McClure wrote:

 I saw this a time or two in Pharo 2.0, and now I've seen it in Pharo 3.0
 -- I launch my working image and all my windows display, but it doesn't
 respond to mouse clicks. Keystrokes don't seem to do anything either,
 other than alt-., which dumps the text below to the terminal, but
 doesn't seem to do anything else.

 Any ideas how to debug this?

 I'm running on Linux. Pharo 3.0 last updated on Jan 7.


 Ouch! Now it's doing this with the virgin 3.0 image. That didn't happen
 before with 2.0.

 -Martin




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Athens SVG Import

[J.F. Rick]

'self changed' logic is the thing that triggers drawing. Before Athens,
various different morphs would register that their part of the screen
needed to be updated with a 'self changed' thing. Then, once a UI cycle,
the sum of the areas needing to be changed was determined and those morphs
within that area would be redrawn. So, you could have a 100 'self changed'
things happening before drawing happens. It seems like with Athens that
each 'self changed' causes a redraw. So, having 25 times as many self
changed messages causes 25 times as many drawing cycles. While Athens is
faster than BitBlt rendering, it may not be 25 times faster.

Cheers,

Jeff


On Thu, Jan 9, 2014 at 10:36 AM, Igor Stasenko siguc...@gmail.com wrote:




 On 9 January 2014 10:26, J.F. Rick s...@je77.com wrote:

 OK. I've made a little headway in diagnosing the problem. It seems that
 one culprit is that the self changed thing works differently with Athens
 than previously. Correct me if I'm wrong, but it seems like sending that
 method immediately causes the canvas to draw. In contrast, before, it just
 marked that area as needing to be redrawn and then, on an update cycle, it
 would redraw the total area that changed. I was using a model-view pattern
 that had 25 components to it. When each got the update command, it seems to
 have launched the canvas to draw. When I changed it so that only one
 changed command was given, the interface became immediately much snappier.
 Adding a factor of 25 to rendering could cause even fast rendering to be
 quite noticeable. So, it is not an inherent problem with drawing forms but
 rather one with changing the programming paradigm. Forms are just
 noticeably slower to draw than vector components and that exacerbated my
 problem.


 Hmm.. Can you explain me, how Athens is related to that? :)

 'self changed' logic and its handling is related to Morphic and used by it.
 there's no way how you can change it by changing something in Athens.



 Cheers,

 Jeff


 On Thu, Jan 9, 2014 at 8:18 AM, J.F. Rick s...@je77.com wrote:

 Hmm. Weird. Could it be a linux thing? Bit order or something? Could it
 be a transparency issue? Could it be a size of the form? I have forms of
 size around 200 x 200. At this point, I haven't numerically investigated
 it. I just notice a significant difference in rendering speed as I switch
 from forms to SVGs. Perhaps it is having to redraw the entire interface
 very often. I'll investigate a bit more when I have some time.

 Cheers,

 Jeff


 On Thu, Jan 9, 2014 at 2:08 AM, Igor Stasenko siguc...@gmail.comwrote:




 On 8 January 2014 08:59, J.F. Rick s...@je77.com wrote:

 In good news, I was able to implement the S/s functionality and both
 of my SVGs now load properly. I'll try some more soon and commit the
 changes once I have tested it a bit more.

 In bad news, the cacheing was working properly, so I still suspect
 that rendering forms as a paint is too intensive to be practical for many
 applications. I'll try to evaluate it a bit more as I replace forms with
 SVGs. If the forms are causing the problem, then performance should
 noticeably increase.


 I just did a little comparison:

 | surface time |
 surface := AthensCairoSurface extent: 200@200.

 surface drawDuring: [ :canvas|
 canvas setPaint: Color red.
 canvas setShape: (0@0 extent: 100@100).
 time := [ 1 timesRepeat: [ canvas draw ] ] timeToRun.
  ].
 time
  0:00:00:00.115
 =

 same as above but with:
  canvas setPaint: (ThemeIcons current backIcon).

 time
  0:00:00:00.093
 ===

 same as above but with:
 (canvas setPaint: (ThemeIcons current backIcon)) repeat.

 time
  0:00:00:00.956

 as you can see, even in slowest case, the throughput is:

 100*100*1 = 100'000'000 pixels (texels) per second.



 Cheers,

 Jeff


 --
 Best regards,
 Igor Stasenko.




 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick




 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick




 --
 Best regards,
 Igor Stasenko.




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Athens SVG Import

[J.F. Rick]

Sure, but getting the glue between Athens and Morphic right is important if
we want Morphic to successfully use Athens. I'll investigate it sometime
and see where the problem lies.

BTW, I'm starting to work on the SVG thing. There definitely are a few
things missing from the specification. For instance, opacity does not work
that well. I'll just see what bugs I find and try to put solutions to them
together. One thing that occurred to me is that we may want to think about
abstracting a bit up from the SVG format. Could we have a more universal
vector format that can be read from an SVG and can be written to an SVG but
could also have other applications (e.g., Postscript)? What I am thinking
of is something along the lines of forms. They can be written out as JPGs
or PNGs but they aren't very JPG or PNG like when you are using them.

Cheers,

Jeff


On Thu, Jan 9, 2014 at 1:07 PM, Igor Stasenko siguc...@gmail.com wrote:




 On 9 January 2014 12:54, J.F. Rick s...@je77.com wrote:

 'self changed' logic is the thing that triggers drawing. Before Athens,
 various different morphs would register that their part of the screen
 needed to be updated with a 'self changed' thing. Then, once a UI cycle,
 the sum of the areas needing to be changed was determined and those morphs
 within that area would be redrawn. So, you could have a 100 'self changed'
 things happening before drawing happens. It seems like with Athens that
 each 'self changed' causes a redraw. So, having 25 times as many self
 changed messages causes 25 times as many drawing cycles. While Athens is
 faster than BitBlt rendering, it may not be 25 times faster.


 Lets make things clear: Athens is responsible for drawing things on canvas.
 It is not responsible for what you drawing, when and where. Such things is
 beyond the scope of Athens.
 So, if there's a bug it could be related to some Morphic glue code (like
 in AthensWrapMorph etc). That is possible.
 And so, if you suspecting there's something wrong, look in that direction,
 and don't loose time trying to fix something in Athens because these things
 actually belong to morphic.



 Cheers,

 Jeff


 On Thu, Jan 9, 2014 at 10:36 AM, Igor Stasenko siguc...@gmail.comwrote:




 On 9 January 2014 10:26, J.F. Rick s...@je77.com wrote:

 OK. I've made a little headway in diagnosing the problem. It seems that
 one culprit is that the self changed thing works differently with Athens
 than previously. Correct me if I'm wrong, but it seems like sending that
 method immediately causes the canvas to draw. In contrast, before, it just
 marked that area as needing to be redrawn and then, on an update cycle, it
 would redraw the total area that changed. I was using a model-view pattern
 that had 25 components to it. When each got the update command, it seems to
 have launched the canvas to draw. When I changed it so that only one
 changed command was given, the interface became immediately much snappier.
 Adding a factor of 25 to rendering could cause even fast rendering to be
 quite noticeable. So, it is not an inherent problem with drawing forms but
 rather one with changing the programming paradigm. Forms are just
 noticeably slower to draw than vector components and that exacerbated my
 problem.


 Hmm.. Can you explain me, how Athens is related to that? :)

 'self changed' logic and its handling is related to Morphic and used by
 it.
 there's no way how you can change it by changing something in Athens.



 Cheers,

 Jeff


 On Thu, Jan 9, 2014 at 8:18 AM, J.F. Rick s...@je77.com wrote:

 Hmm. Weird. Could it be a linux thing? Bit order or something? Could
 it be a transparency issue? Could it be a size of the form? I have forms 
 of
 size around 200 x 200. At this point, I haven't numerically investigated
 it. I just notice a significant difference in rendering speed as I switch
 from forms to SVGs. Perhaps it is having to redraw the entire interface
 very often. I'll investigate a bit more when I have some time.

 Cheers,

 Jeff


 On Thu, Jan 9, 2014 at 2:08 AM, Igor Stasenko siguc...@gmail.comwrote:




 On 8 January 2014 08:59, J.F. Rick s...@je77.com wrote:

 In good news, I was able to implement the S/s functionality and both
 of my SVGs now load properly. I'll try some more soon and commit the
 changes once I have tested it a bit more.

 In bad news, the cacheing was working properly, so I still suspect
 that rendering forms as a paint is too intensive to be practical for 
 many
 applications. I'll try to evaluate it a bit more as I replace forms with
 SVGs. If the forms are causing the problem, then performance should
 noticeably increase.


 I just did a little comparison:

 | surface time |
 surface := AthensCairoSurface extent: 200@200.

 surface drawDuring: [ :canvas|
 canvas setPaint: Color red.
 canvas setShape: (0@0 extent: 100@100).
 time := [ 1 timesRepeat: [ canvas draw ] ] timeToRun.
  ].
 time
  0:00:00:00.115
 =

 same as above

Re: [Pharo-dev] Athens SVG Import

[J.F. Rick]

In good news, I was able to implement the S/s functionality and both of my
SVGs now load properly. I'll try some more soon and commit the changes once
I have tested it a bit more.

In bad news, the cacheing was working properly, so I still suspect that
rendering forms as a paint is too intensive to be practical for many
applications. I'll try to evaluate it a bit more as I replace forms with
SVGs. If the forms are causing the problem, then performance should
noticeably increase.

Cheers,

Jeff


On Tue, Jan 7, 2014 at 7:42 PM, Igor Stasenko siguc...@gmail.com wrote:




 On 7 January 2014 19:25, J.F. Rick s...@je77.com wrote:

 On Tue, Jan 7, 2014 at 11:22 AM, Igor Stasenko siguc...@gmail.comwrote:

 Right. Converting Form(s) to paint(s) is memory intensive operation.
 Basically, it copies contents of the form to newly created surface.
 To avoid this, use caching. Here is an example from ImageMorph:

  drawOnAthensCanvas: aCanvas

 | cached |

 cached := aCanvas cacheAt: image ifAbsentPut: [
 image asAthensPaintOn: aCanvas.
 ].

 aCanvas setPaint: cached.

 aCanvas paintTransform restoreAfter: [
 aCanvas paintTransform translateBy: self innerBounds origin
 negated.

 aCanvas drawShape: self innerBounds.
 ].

 without caching, rendering morphic desktop was very slow, since all
 icons is forms.


 Yes. I had figured that out. Unfortunately, even with cacheing, it was
 slow after enough images were open. It could be that, for whatever reason,
 my cacheing code is not working, but I doubt it. It looks pretty exactly
 like that.


 what object you using as a key for cache? because if its temporary object,
 then its useless.



 Anyway, for most of my applications, switching over to vector-based
 graphics would be a better choice as it would allow for me to more easily
 scale to different screen sizes. So, I was excited to try the SVG import.
 Now that the XMLParser is working, I am running into some problems with the
 SVG import code. It seems that it doesn't support some of the features that
 an SVG export from Illustrator produces. I was wondering if I could get
 some help there.

 First, Illustrator tends to spit out SVGs that use
 #reflectedCubicBezier curves, which is not yet implemented.

 Second, I found a small bug in ASPathConverterreadPoint The self
 skipBlanks has to be changed to self skipBlanksAndComma or multiple
 points cannot be read in sequence.

 Can you submit the fix, please? Let me know if you need commit rights .


 Thanks. I'd love to contribute. My SmalltalkHub Id is JochenRick.


 Okay, i added you. Wellcome.


   Third, while ASPathConverter supports vLineTo: and hLineTo:,
 AthensCairoPathBuilder does not. I tried implementing these myself but they
 apparently don't work the way I thought they should.


 should be straightforward:

 vLineTo: number
 ^ self lineTo: (absolute ifTrue: [ endPoint x@number ] ifFalse: [
 0@number ])

 hLineTo: number
  ^ self lineTo: (absolute ifTrue: [ number@endPoint y ] ifFalse: [
 number@0 ])


 Great. Works like a charm. The swap shapes one now works fine. I can also
 include that in a commit.






 Here are two examples of the kind of SVG files I would like to read:
 button-swapShapes.svghttp://home.cc.gatech.edu/je77/uploads/1/button-swapShapes.svg
  -
 This one fails because of vLineTo: and hLineTo:
 button-erase.svghttp://home.cc.gatech.edu/je77/uploads/1/button-erase.svg
  -
 This one fails because of reflectedCubicBezier curves.

 You mean this one?:


 *S/s * (shorthand/smooth CurveTo)

 x2,y2
 x, y

 Draw a cubic Beizer curve from the current point to (x,y). The first
 control point is assumed to be the reflection of the second control point 
 (x2,
 y2) on the previous command relative to the current point.

 Yes. Not supported. Yet :)
 But it should be quite easy to implement.
 Jochen, i need help with completing SVG importer. So, if you can help,
 please do.

 Can you tell me what is your login name on smalltalkhub, so i will add
 you to
 http://smalltalkhub.com/#!/~Pharo/Athens
 committers?



 Thanks. I'd love to contribute. My SmalltalkHub Id is JochenRick. I can
 take a shot at implementing the S/s thing. If you have any URLs that would
 be helpful for getting started, please send them my way. Otherwise, I'll
 just try to find some documentation on Cairo and SVG. That seems like the
 major obstacle.

 I use W3C/SVG.. i don't think there's any better/more complete and more
 comprehensive source than official one :)

 http://www.w3.org/TR/SVG11/

 Cheers,

 Jeff

 PS I know my name is confusing. My surname is Rick. My forename is
 Jochen, but I go by Jeff for English speaking people.

 hehe.. i typed Jeff at first, but then looked at your profile picture
 which says 'Jochen Rick'
 and corrected it :)




 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick




 --
 Best regards,
 Igor Stasenko.




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com

Re: [Pharo-dev] Athens SVG Import

[J.F. Rick]

Hmm. Weird. Could it be a linux thing? Bit order or something? Could it be
a transparency issue? Could it be a size of the form? I have forms of size
around 200 x 200. At this point, I haven't numerically investigated it. I
just notice a significant difference in rendering speed as I switch from
forms to SVGs. Perhaps it is having to redraw the entire interface very
often. I'll investigate a bit more when I have some time.

Cheers,

Jeff


On Thu, Jan 9, 2014 at 2:08 AM, Igor Stasenko siguc...@gmail.com wrote:




 On 8 January 2014 08:59, J.F. Rick s...@je77.com wrote:

 In good news, I was able to implement the S/s functionality and both of
 my SVGs now load properly. I'll try some more soon and commit the changes
 once I have tested it a bit more.

 In bad news, the cacheing was working properly, so I still suspect that
 rendering forms as a paint is too intensive to be practical for many
 applications. I'll try to evaluate it a bit more as I replace forms with
 SVGs. If the forms are causing the problem, then performance should
 noticeably increase.


 I just did a little comparison:

 | surface time |
 surface := AthensCairoSurface extent: 200@200.

 surface drawDuring: [ :canvas|
 canvas setPaint: Color red.
 canvas setShape: (0@0 extent: 100@100).
 time := [ 1 timesRepeat: [ canvas draw ] ] timeToRun.
  ].
 time
  0:00:00:00.115
 =

 same as above but with:
 canvas setPaint: (ThemeIcons current backIcon).

 time
  0:00:00:00.093
 ===

 same as above but with:
 (canvas setPaint: (ThemeIcons current backIcon)) repeat.

 time
  0:00:00:00.956

 as you can see, even in slowest case, the throughput is:

 100*100*1 = 100'000'000 pixels (texels) per second.



 Cheers,

 Jeff


 --
 Best regards,
 Igor Stasenko.




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] XMLParser Problem with SVG

[J.F. Rick]

Monty, thanks. You are right that the latest version of XMLParser fixes the
parsing problem. I think you just need to upload an updated configuration
to the MetaRepoForPharo30 to fix this.

And, yes, I would like to know how to turn DTD parsing off or for it to
cache the DTD as it takes several seconds to retrieve the DTD for SVG and
that gets annoying.

Cheers,

Jeff


On Mon, Jan 6, 2014 at 10:18 AM, Sven Van Caekenberghe s...@stfx.eu wrote:


 On 06 Jan 2014, at 10:06, Igor Stasenko siguc...@gmail.com wrote:

 
 
 
  On 5 January 2014 15:19, J.F. Rick s...@je77.com wrote:
  I am trying to use SVG with Athens; however, the XMLParser for Pharo 3.0
 cannot read normal SVG files that it used to. So, the demo of ASVGMorph
 fromFile: 'lion.svg' fails in the XMLParser (i.e., before ASVGMorph really
 does anything to it). It seems to download the DTD file from the Internet
 and then cannot properly parse it. Here is my setup:
 
  Up-to-date Pharo 3.0. Added XMLParser from the Configuration Browser.
  Example file can be found here:
 http://www.thetangentbundle.net/w/images/f/ff/lion.svg
  The following brings up an error: XMLDOMParser parseFileNamed: 'lion.svg'
 
  Hmm, why it tries to parse DTD file? It looks like something has changed
 in XMLDOMParser, because it wasn't before, and there is no support in SVG
 parser
  for that.

 Yes, the parsing of DTD’d is new, Monthy added it recently.
 He says there is a way to turn it off.

 
  Cheers,
 
  Jeff
 
  --
  Jochen Jeff Rick, Ph.D.
  http://www.je77.com/
  Skype ID: jochenrick
 
 
 
  --
  Best regards,
  Igor Stasenko.





-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

[Pharo-dev] Athens SVG Import

[J.F. Rick]

This message is mainly for Igor, who probably already curses every time he
sees my name on the development list. But, perhaps others have had some
experience with this as well.

I'm still working on moving my touch applications to Athens. I am running
into a major problem with icons. My applications tend to have quite a few
icons in them. In the old BitBlt versions, I just used forms for the icons.
That same approach fails with Athens as form rendering is time consuming.
With just ten medium-sized forms open in my AthensWrapMorph, the system
starts to crawl. My guess is that form rendering needs to be sped up before
Athens can be widely adopted. Using the form as a paint, while flexible,
seems pretty intense.

Anyway, for most of my applications, switching over to vector-based
graphics would be a better choice as it would allow for me to more easily
scale to different screen sizes. So, I was excited to try the SVG import.
Now that the XMLParser is working, I am running into some problems with the
SVG import code. It seems that it doesn't support some of the features that
an SVG export from Illustrator produces. I was wondering if I could get
some help there.

First, Illustrator tends to spit out SVGs that use #reflectedCubicBezier
curves, which is not yet implemented.

Second, I found a small bug in ASPathConverterreadPoint The self
skipBlanks has to be changed to self skipBlanksAndComma or multiple
points cannot be read in sequence.

Third, while ASPathConverter supports vLineTo: and hLineTo:,
AthensCairoPathBuilder does not. I tried implementing these myself but they
apparently don't work the way I thought they should.

Here are two examples of the kind of SVG files I would like to read:
button-swapShapes.svghttp://home.cc.gatech.edu/je77/uploads/1/button-swapShapes.svg
-
This one fails because of vLineTo: and hLineTo:
button-erase.svg http://home.cc.gatech.edu/je77/uploads/1/button-erase.svg -
This one fails because of reflectedCubicBezier curves.

Cheers,

Jeff

-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

[Pharo-dev] XMLParser Problem with SVG

[J.F. Rick]

I am trying to use SVG with Athens; however, the XMLParser for Pharo 3.0
cannot read normal SVG files that it used to. So, the demo of ASVGMorph
fromFile: 'lion.svg' fails in the XMLParser (i.e., before ASVGMorph really
does anything to it). It seems to download the DTD file from the Internet
and then cannot properly parse it. Here is my setup:

Up-to-date Pharo 3.0. Added XMLParser from the Configuration Browser.
Example file can be found here:
http://www.thetangentbundle.net/w/images/f/ff/lion.svg
The following brings up an error: XMLDOMParser parseFileNamed: 'lion.svg'

Cheers,

Jeff

-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Soundplugin for Windows/Linux

[J.F. Rick]

Great to hear. Not having sound on linux is a bit annoying.

Cheers,

Jeff


On Sat, Jan 4, 2014 at 10:33 AM, Esteban Lorenzano esteba...@gmail.comwrote:

 is in my todo before release… but patience :)


 On 04 Jan 2014, at 00:12, Nicolai Hess nicolaih...@web.de wrote:

 Can someone change PharoVM build configs
 regarding issue 12493 https://pharo.fogbugz.com/default.asp?12493
 Sound does not work for Windows and Linux VMs because

 windows) PharoVMBuilder does not include soundplugin in the windows config
 linux) vm-sound-alsa has unresolved externals - can not be loaded
 squeaks vm-sound-oss and vm-sound-pulse are working with pharo too
 vm-sound-oss source is in pharos vm source, but not in pharovmbuilders
 config, so it just isn't built.

 For me, it looks like it is solveable by just changing PharoVMBuilder
 configs.

 I built my own VMs for Windows (Windows 7 32Bit) and Linux (Ubuntu 10.04),
 and it works. But I don't know if the exclusion of this plugins is on
 purpose
 because they may make problems on other Win/Linux versions.

 Nicolai





-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Weird Athens Artifact

[J.F. Rick]

OK. Here's some code to demonstrate the bug:

wrap := AthensWrapMorph new
extent: 100 @ 100;
yourself.
black := Morph new
extent: 100 @ 100;
color: Color black;
yourself.
red := Morph new
extent: 100 @ 50;
color: Color red;
yourself.
transparent := Morph new
extent: 50 @ 50;
position: 25 @ -25;
color: Color transparent;
yourself.
wrap
addMorph: black;
addMorph: red;
addMorph: transparent;
openInWorld

Please note that for this to work, you have to remove the initialize
method in AthensWrapMorph that makes it use a TableLayout, which is a silly
choice. Though adding transparent should not make a difference in the
rendering, it does.

Cheers,

Jeff


On Thu, Jan 2, 2014 at 5:29 PM, J.F. Rick s...@je77.com wrote:

 I'm aware of the default Morphic behavior. I've hacked it so that a
 transparent 1x1 pixel bit is in the hand and its movement causes the brown
 morph to move and remain a submorph of the AthensWrapMorph application.

 Yes, this is some kind of weird clipping thing. Specifically, it looks
 like clipping is not happening. The brown morph (and the area behind it)
 renders correctly but it is not rendered at the correct location. Instead,
 the starting location of the rendering seems to be forced into the bounds
 of the surface. That's why it looks like the background things have shifted
 downwards.

 Cheers,

 Jeff


 On Thu, Jan 2, 2014 at 5:10 PM, Igor Stasenko siguc...@gmail.com wrote:




 On 2 January 2014 16:54, J.F. Rick s...@je77.com wrote:

 I've been converting DigiTile over to Athens with general success but I
 have found an odd rendering bug. In this scenario, I am moving the brown
 square around with a hand. As I am using AthensWrapMorph, I have made it so
 that the brown square is a submorph of the application (an AthensWrapMorph)
 and not in the hand. The brown square is actually twice the extent that it
 appears (i.e., it has a 50 pixel transparent border). This has to be done
 to allow rotation handles to be added. Anyway, when it moves so that its
 top would go beyond the top of the application, some crazy rendering effect
 happens, as illustrated in the included screenshots. This same behavior
 happens when moving the square to the left side of the screen. It does not
 happen on either the right or the bottom of the screen. It seems like
 Athens does not like for submorphs of AthensWrapMorph to extend to the left
 or above their parent. This seems like a problem and something that can
 easily happen as somebody moves some morph to be partially offscreen.


 Sounds like clipping issue. But it is hard to tell anything by looking at
 screenshots..
 Usually all things outside of visible area should be clipped.
  Also, note that dragging, like it is done in Morphic, the dragged morph
 changes its owner to hand (handmorph)..
 and since it is only within AthensWrapMorph it is where it uses rendering
 by Athens, it could be simply the case that it don't renders at all (or
 just uses morhic rendering while held by hand).


 Cheers,

 Jeff

 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick




 --
 Best regards,
 Igor Stasenko.




 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Don't make me think (the one thing you shouldn't ignore about user interfaces)

[J.F. Rick]

As somebody coming from the HCI side, rather than the software engineering
/ programming language side, I too value usability. But, it seems to me
that you first do the major changes and then slowly hone to get usability
right. I find lots of small little usability bugs in Pharo 3.0 but I assume
that those are mainly due to the tools getting majorly upgraded right now.
I'm not sure how to report these tiny usability bugs. If someone can chime
in on the correct way to report these, I'd be willing to report them. For
instance, I notice that when I am writing code in the browser and click to
another method, I am no longer warned that my code will be lost. It is
simply lost. That's a basic usability thing: Prevent costly errors. But, I
assume that this is just a matter of Nautilus still getting refined. So, it
may not even be worth mentioning.

My main contribution right now is being an early adopter of Athens and
sending any weaknesses I find to the list. Athens is new and still has lots
of little bugs. At the same time, it is ambitious and a major step forward
for Pharo if it can be fully integrated. Of course, these little bugs will
get taken care of as Athens is more widely used but part of the excitement
of Pharo is that it is evolving. There are some areas where usability
honing can be useful but others were the software engineering has to settle
down before the honing can start.

Cheers,

Jeff


On Fri, Jan 3, 2014 at 10:48 AM, Tudor Girba tu...@tudorgirba.com wrote:

 Thanks for bringing this up.

 Yes, we should care about usability.

 And I agree that usability is attainable as long as you approach it with
 consistent discipline. It's similar to designing code: you start asking
 questions, figure out what the right questions are, and then stick to it.

 I like Steve Krug's Don't make me think book. However, please keep in mind
 that the lessons in the book apply specifically to the web. An environment
 like Pharo should not obey exactly the same things.

 But, as Esteban says, let's focus on the future, and keep usability high
 in our list of concerns. Even if we might not know how to do it now, simply
 sticking with it will make us better in the long run.

 Cheers,
 Doru




 On Fri, Jan 3, 2014 at 10:38 AM, Esteban Lorenzano esteba...@gmail.comwrote:

 Hi Sebastian,

 I feel your pain :)

 we are aiming to focus Pharo 4 in “modularisation and tools”, to enhance
 what we have currently.
 Now… one of the biggest problems we have is that people is so used to the
 old tools that they don’t even realise that we can do a lot better. And
 most possible some people will react violently to any change… but well, we
 will do it anyway, with your help.
 Let’s all together build a better IDE for the future :)

 Esteban

 On 03 Jan 2014, at 01:13, Sebastian Sastre sebast...@flowingconcept.com
 wrote:

 Guys is no mystery that we have some issues with UI.

 It's not so bad either, we have many things that are light years ahead of
 other but we consistently miss some really basic stuff from the
 Human-Computer-Interactcion point of view.

 The community is biased towards engineering and unbalanced regarding to
 design so this is no surprise (why this happens is another interesting
 conversation).

 UI is not that hard when you know what to pay attention to but we need
 first to decide if we care about usability and the developer experience at
 all.

 This fantastic talk from Steve Krug exposes what's the least you can do
 for the usability of any software.


 http://blip.tv/business-of-software/steve-krug-on-the-least-you-can-do-about-usability-1566021

  sebastian https://about.me/sebastianconcept

 o/









 --
 www.tudorgirba.com

 Every thing has its own flow




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

[Pharo-dev] Weird Athens Artifact

[J.F. Rick]

I've been converting DigiTile over to Athens with general success but I
have found an odd rendering bug. In this scenario, I am moving the brown
square around with a hand. As I am using AthensWrapMorph, I have made it so
that the brown square is a submorph of the application (an AthensWrapMorph)
and not in the hand. The brown square is actually twice the extent that it
appears (i.e., it has a 50 pixel transparent border). This has to be done
to allow rotation handles to be added. Anyway, when it moves so that its
top would go beyond the top of the application, some crazy rendering effect
happens, as illustrated in the included screenshots. This same behavior
happens when moving the square to the left side of the screen. It does not
happen on either the right or the bottom of the screen. It seems like
Athens does not like for submorphs of AthensWrapMorph to extend to the left
or above their parent. This seems like a problem and something that can
easily happen as somebody moves some morph to be partially offscreen.

Cheers,

Jeff

-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick
attachment: withArtifact.pngattachment: withoutArtifact.png

Re: [Pharo-dev] Weird Athens Artifact

[J.F. Rick]

I'm aware of the default Morphic behavior. I've hacked it so that a
transparent 1x1 pixel bit is in the hand and its movement causes the brown
morph to move and remain a submorph of the AthensWrapMorph application.

Yes, this is some kind of weird clipping thing. Specifically, it looks like
clipping is not happening. The brown morph (and the area behind it) renders
correctly but it is not rendered at the correct location. Instead, the
starting location of the rendering seems to be forced into the bounds of
the surface. That's why it looks like the background things have shifted
downwards.

Cheers,

Jeff


On Thu, Jan 2, 2014 at 5:10 PM, Igor Stasenko siguc...@gmail.com wrote:




 On 2 January 2014 16:54, J.F. Rick s...@je77.com wrote:

 I've been converting DigiTile over to Athens with general success but I
 have found an odd rendering bug. In this scenario, I am moving the brown
 square around with a hand. As I am using AthensWrapMorph, I have made it so
 that the brown square is a submorph of the application (an AthensWrapMorph)
 and not in the hand. The brown square is actually twice the extent that it
 appears (i.e., it has a 50 pixel transparent border). This has to be done
 to allow rotation handles to be added. Anyway, when it moves so that its
 top would go beyond the top of the application, some crazy rendering effect
 happens, as illustrated in the included screenshots. This same behavior
 happens when moving the square to the left side of the screen. It does not
 happen on either the right or the bottom of the screen. It seems like
 Athens does not like for submorphs of AthensWrapMorph to extend to the left
 or above their parent. This seems like a problem and something that can
 easily happen as somebody moves some morph to be partially offscreen.


 Sounds like clipping issue. But it is hard to tell anything by looking at
 screenshots..
 Usually all things outside of visible area should be clipped.
 Also, note that dragging, like it is done in Morphic, the dragged morph
 changes its owner to hand (handmorph)..
 and since it is only within AthensWrapMorph it is where it uses rendering
 by Athens, it could be simply the case that it don't renders at all (or
 just uses morhic rendering while held by hand).


 Cheers,

 Jeff

 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick




 --
 Best regards,
 Igor Stasenko.




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

[Pharo-dev] Problems with Athens Font Rendering

[J.F. Rick]

I keep on crashing my VM based on using Athens to render fonts. Some things
work; some don't. It is a mystery.

I managed to install the TrueType fonts. I'm using StringMorph in an
AthensWrapMorph, so it is rendered in Athens. When I do the following, it
seems to work fine:

string := StringMorph contents: 'HelloWorld' font: (LogicalFont familyName:
'Arial' pointSize: 20).
string color: Color white.
string position: 100 @ 100.
self addMorph: string.

When I changed it to 30, it initially crashed. Now it doesn't crash, but
the rendering is the same as for 20. When I change it to 40, it crashes.
When I add two strings, one of size 20 and one of size 30, it crashes. All
of these things render fine outside of Athens (i.e., I just open them in
the world).

What am I doing wrong?

Jeff

-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Convert to Athens

[J.F. Rick]

I'm facing some problems with AthensWrapMorph. Basically, when I add a
morph, I can't change its position. It just stays in the top left. Whatever
I try to do to change its position (self position: 100@100) does not work.

Cheers,

Jeff


On Wed, Nov 20, 2013 at 5:04 PM, J.F. Rick s...@je77.com wrote:

 Thanks. It works. I already have found a few bugs and one thing I don't
 understand.

 (1) A few Paint things seem to implement athensFillRectangle:on: and
 athensFillPath:on: rather than fillRectangle:on: and fillPath:on:. It seems
 like it should be the latter rather than the former. I changed the names
 and the evil rectangle of doom disappeared.

 (2) Using the AthenWrapMorph, it seems that the bottom row of pixels is
 not rendered or clipped. I can stop this phenomenon by changing the
 createSurface method to have the extent be 0@1 bigger. While that works,
 it seems like there's a bug somewhere in AthensCairoSurface.

 (3) I ended up changing a morph so that it should render differently. In
 standard Pharo, I just use self changed and it updates. Is there an
 equivalent in Athens? Do I have to explicitly tell Athens to rerender it?
 If so, how? I tried self render but that did not seem to help.

 Cheers,

 Jeff


 On Wed, Nov 20, 2013 at 11:08 AM, Igor Stasenko siguc...@gmail.comwrote:

 http://www.smalltalkhub.com/#!/~Pharo/Athens


 On 20 November 2013 09:04, J.F. Rick s...@je77.com wrote:

 Right. Where is this Athens repository? I have the latest in
 Pharo30/main (Athens-Morphic-MarcusDenker.23.mcz) and that does not seem to
 include AthensWrapperMorph.

 Cheers,

 Jeff


 On Wed, Nov 20, 2013 at 8:35 AM, Igor Stasenko siguc...@gmail.comwrote:




 On 19 November 2013 17:42, J.F. Rick s...@je77.com wrote:

 Indeed. I would like to know that. It doesn't seem to be included in
 the latest Pharo 3.0.


 it could be not yet included.
 in that case, load most recent Athens-Morphic package from athens
 repository.



 Cheers,

 Jeff


 On Fri, Nov 15, 2013 at 7:34 PM, Hilaire Fernandes 
 hilaire.fernan...@gmail.com wrote:

 Le 15/11/2013 14:17, Igor Stasenko a écrit :
 
  for transition , i implemented a special morph, AthensWrapMorph
  which wraps (as its name says) its children morphs and forces them
 to be
  rendered by athens
  (the child morphs will never receive #drawOn: but
 #drawOnAthensCanvas:
  instead ).


 I guess Jeff, may want to know where to find this wrapper.

 Hilaire


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





 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick




 --
 Best regards,
 Igor Stasenko.




 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick




 --
 Best regards,
 Igor Stasenko.




 --
 Jochen Jeff Rick, Ph.D.
 http://www.je77.com/
 Skype ID: jochenrick




-- 
Jochen Jeff Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick