[Pharo-dev] [ANN] Pharo 12 Release !

[Esteban Lorenzano via Pharo-dev]

Dear Pharo users and dynamic language lovers:

We have released Pharo  version 12!


   What is Pharo?

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


 * Simple & powerful language: No constructors, no types declaration,
   no interfaces, no primitive types. Yet a powerful and elegant
   language with a full syntax fitting in one postcard! Pharo is
   objects and messages all the way down.
 * Live, immersive environment: Immediate feedback at any moment of
   your development: Developing, testing, debugging. Even in production
   environments, you will never be stuck in compiling and deploying
   steps again!
 * Amazing debugging experience: Pharo environment includes a debugger
   unlike anything you've seen before. It allows you to step through
   code, restart the execution of methods, create methods on the fly,
   and much more!
 * Pharo is yours: Pharo is made by an incredible community, with more
   than 100 contributors for the last revision of the platform and
   hundreds of people constantly contributing with frameworks and
   libraries.
 * Fully open-source: Pharo full stack is released under MIT
    License and available on
   GitHub 

... more on the Pharo Features page .

In this iteration of Pharo, we continue working on our objectives of 
improvement, clean-up and modularization. Also, we included a number of 
usability and speed improvements. A complete list of changes and 
improvements is available in our Changelog 



Some highlights of this amazing version:


   Highlights


 New breakpoint system

The debug point system is a breakpoint model that supersedes the 
previous implementation of breakpoints and watchpoints. They are 
configurable, composable, and extensible. The traditional breakpoints 
remain available, including conditional breakpoints, one-time 
breakpoints, and object-centric breakpoints. Additionally, there are new 
types of breakpoints, such as chained-breakpoints, which condition the 
activation of certain breakpoints on the triggering of others (e.g., 
breakpoint B only activates if breakpoint A is hit first). Debug points 
also feature a dedicated browser and integration options.



 Tools

 * Scalable fluid class syntax is now the default one
 * Preparing the introduction of the Bloc graphic system by migrating
   more tools to Spec2 widgets
 * Spec2 UI framework enhancements to support GTK 4
 * Leaner version of the Metacello package manager
 * More robust and strict mode for FFI


 System

 * New architecture for refactorings and domain specific transformations
 * Code loading speed improvement
 * Fast browsing via fully optimized package tags
 * Optmized memory usage via optimized method protocols
 * Compiler simplifications and improvements


 Virtual machine

 * Massive image support with permanent space
 * String/ByteArray comparison speed up


   Development Effort

This new version is the result of 1895 Pull Requests integrated just in 
the Pharo repository. We have closed 865 issues and received 
contributions from more than 70 different contributors. We have also a 
lot of work in the separate projects that are included in each Pharo 
release:


 * http://github.com/pharo-spec/NewTools
   
 * http://github.com/pharo-spec/NewTools-DocumentBrowser
   
 * http://github.com/pharo-spec/Spec 
 * http://github.com/pharo-vcs/Iceberg
   
 * http://github.com/ObjectProfile/Roassal3
   
 * http://github.com/pillar-markup/Microdown
   
 * http://github.com/pillar-markup/BeautifulComments
   
 * http://github.com/pharo-project/pharo-vm
   


   Contributors

We always say Pharo is yours. It is yours because we made it for you, 
but most importantly because it is made by the invaluable contributions 
of our great community (yourself). A large community of people from all 
around the world contributed to Pharo 12.0 by making pull requests, 
reporting bugs, participating in discussion threads, providing feedback, 
and a lot of helpful tasks in all our community channels. Thank you all 
for your contributions.


The Pharo Team

Discover Pharo: https://pharo.org/features

Try Pharo: http://pharo.org/download 

Learn Pharo: http://pharo.org/documentation 

[Pharo-dev] [ANN] Pharo 12 development is now frozen

[Esteban Lorenzano via Pharo-dev]

Hi,

As we announced a couple of weeks ago, Pharo 12 development entered its 
freeze status.


This means no more new features will be included, we will concentrate 
until release just in important bugfixes.


If you have an issue that you consider a showstopper for your 
workflow/needs, let us now and we will consider it.


Cheers!

Esteban

[Pharo-dev] IMPORTANT: Pharo 12 will enter feature freeze on March 1st

[Esteban Lorenzano via Pharo-dev]

Hi,

The development of Pharo 12 will enter in feature freeze on March 1st 
and we plan to have at least one month of stabilization (but we will 
release when we are ready, in April).


cheers,

Esteban

[Pharo-dev] ANN: New voyage and mongotalk versions, for mongodb >=5

[Esteban Lorenzano]

Hi,

We just made a new release of the mongotalk drivers [1], which replaces 
the drivers for mongodb, making possible for Pharo users to connect with 
a recent mongo database (versions 5 and beyond). Old legacy driver is 
still accessible with some minimal work, in case of need [2].

We also updated Voyage to use the new driver by default [3].

Enjoy,
Esteban

[1] https://github.com/pharo-nosql/mongotalk/releases/tag/v2.0
[2] https://github.com/pharo-nosql/mongotalk#older-mongo-versions--5
[3] https://github.com/pharo-nosql/voyage/releases/tag/v2.0

[Pharo-dev] Re: How to reinitialize SpCodePresenter commands?

[Esteban Lorenzano]

Hi,

This is not cached, commands are calculated each time (hence, there is no 
reset).

Esteban

> On 24 Aug 2023, at 20:55, stephane ducasse  wrote:
> 
> Hi
> 
> I wanted to extend SpCodePresenter so I created a new command and I added the 
> new command manually in 
> 
> codeNavigationCommandsGroupWith: aPresenter
> 
>| group |
>group := (CmCommandGroup named: 'Code search') asSpecGroup
> description: 'Search the system from code selection.';
> beDisplayedAsSubMenu;
> yourself.
> 
>self flag: #TODO. "This looks like a very bad way to do this :P"
>{
>KyoBrowseClassCommand . 
>
>SpBrowseClassCommand.
>SpBrowseImplementorsCommand.
>SpBrowseSendersCommand.
>SpBrowseMethodReferencesCommand.
>SpBrowseMethodsMatchingStringInsensitiveCommand.
>SpBrowseMethodsMatchingStringSensitiveCommand.
>SpBrowseMethodsContainingStringCommand } do: [ :commandClass |
>group register: (commandClass forSpecContext: aPresenter) ].
> 
>^ group
> 
> My command worked but when I changed 
> from 
> 
> KyoBrowseClassCommand  class >> defaultShortcutKey
>
>^ $k command mac  | $k control win | $k control unix
> 
> to 
> 
> KyoBrowseClassCommand class >> defaultShortcutKey
>
>^ $k command mac , $b command mac | $k control win | $k control unix
> 
> I could not open the playground
> So I reverted my changes but I cannot find the way to reinitialize 
> SpCodePresenter
> 
> S

[Pharo-dev] [ANN] Pharo 11 Released !

[Esteban Lorenzano]

Dear Pharo users and dynamic language lovers:

We have released Pharo (https://pharo.org/) version 11!
What is Pharo?
Pharo is a pure object-oriented programming language and a powerful environment 
focused on simplicity and immediate feedback.

Simple & powerful language: No constructors, no types declaration, no 
interfaces, no primitive types. Yet a powerful and elegant language with a full 
syntax fitting in one postcard! Pharo is objects and messages all the way down.
Live, immersive environment: Immediate feedback at any moment of your 
development: Developing, testing, debugging. Even in production environments, 
you will never be stuck in compiling and deploying steps again!

Amazing debugging experience: Pharo environment includes a debugger unlike 
anything you've seen before. It allows you to step through code, restart the 
execution of methods, create methods on the fly, and much more!

Pharo is yours: Pharo is made by an incredible community, with more than 100 
contributors for the last revision of the platform and hundreds of people 
constantly contributing with frameworks and libraries.

Fully open-source: Pharo full stack is released under MIT 
(https://opensource.org/licenses/MIT) License and available on GitHub 
(https://github.com/pharo-project/pharo)

... more on the Pharo Features page (http://www.pharo.org/features).

In this iteration of Pharo, we continue working on our objectives of 
improvement, clean-up and modularization. Also, we included a number of 
usability and speed improvements. A complete list of changes and improvements 
is available in our Changelog 
(https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo110ChangeLogs.md)
Some highlights of this amazing version:
Highlights
Tools
Iceberg (the git client/VCS control tool) has received a lot of tweaks and 
fixes to work better with GitHub and other Git services.

Our debugger now incorporates lots of tweaks and notably the capability of 
adding bindings in the context interaction model.

The is a new implementation of rewrite tools and improved refactoring support.

There is a new tool: The Document Browser, which presents Microdown (markdown 
compatible) documents placed on the web or locally.

New Tools presented in Calypso (the System Browser) and additional extended 
Inspectors.

All versions of NewTools, Spec, Roassal and Microdown have been updated with 
their respective bug fixes and improvements.

System
Extended Full Blocks and Constant Clock closures support.

Additional Inlining and optimizations

Bug Fixes and Clean up.

Ephemeron Finalization support.

Virtual machine
Ephemerons Production Ready.

Initial support for Single-Instruction Multiple-Data (SIMD).

Third-Party Dependency Update (Newer versions, Graphic Libraries using Hardware 
Acceleration).

Clean Ups: Remove lots of old code, notably old experiments, and dead code.

Development Effort
This new version is the result of 1412 Pull Requests integrated just in the 
Pharo repository. We have closed 972 issues and received contributions from 
more than 70 different contributors. We have also a lot of work in the separate 
projects that are included in each Pharo release:

http://github.com/pharo-spec/NewTools (https://github.com/pharo-spec/NewTools)
http://github.com/pharo-spec/NewTools-DocumentBrowser 
(https://github.com/pharo-spec/NewTools-DocumentBrowser)

http://github.com/pharo-spec/Spec (https://github.com/pharo-spec/Spec)

http://github.com/pharo-vcs/Iceberg (https://github.com/pharo-vcs/Iceberg)

http://github.com/ObjectProfile/Roassal3 
(https://github.com/ObjectProfile/Roassal3)

http://github.com/pillar-markup/Microdown 
(https://github.com/pillar-markup/Microdown)

http://github.com/pillar-markup/BeautifulComments 
(https://github.com/pillar-markup/BeautifulComments)

http://github.com/pharo-project/pharo-vm 
(https://github.com/pharo-project/pharo-vm)

Contributors
We always say Pharo is yours. It is yours because we made it for you, but most 
importantly because it is made by the invaluable contributions of our great 
community (yourself). A large community of people from all around the world 
contributed to Pharo 11.0 by making pull requests, reporting bugs, 
participating in discussion threads, providing feedback, and a lot of helpful 
tasks in all our community channels. Thank you all for your contributions.

The Pharo Team
Discover Pharo: https://pharo.org/features
Try Pharo: http://pharo.org/download
Learn Pharo: http://pharo.org/documentation

[Pharo-dev] Re: [ANN] preparing for release, freezing enhancements :)

[Esteban Lorenzano]

Hi Jean,

As every year, we try to release in april. Now if this will be there or not, it 
always depends on several things, but for now we are pretty confident on it :P
About renaming branches... we will not do that for the moment, sorry.
We have discussed a lot in the past and this naming pattern is working so far.
But as every release also, we will re-discuss our process after the release 
happens, to iterate on it and improve... what would be the rational behind 
having a main branch as default instead a branch with the version we are 
working on? (I could consider start having branchs named, e.g. pharo12-dev, to 
differentiate it from the stable branch, but since that would mean to change a 
lot of tools that depend on the naming, it has to be considered careful).

cheers!
Esteban

On Mar 10 2023, at 1:42 pm, Privat, Jean  wrote:
> Nice,
>
> do you have a timeframe in mind for the release, or this will be "when it's 
> ready"?
> Also, a suggestion: do not create a `Pharo12` branch yet but use a 
> master/main one (and make it the default branch).
> It helps newcomers to understand more easily the structure of the project.
>
> -J
> ________
> De : Esteban Lorenzano 
> Envoyé : 10 mars 2023 05:03
> À : Pharo Development List
> Objet : [Pharo-dev] [ANN] preparing for release, freezing enhancements :)
>
> Hello,
> We are slowly preparing to release Pharo 11.
> For those making changes that are not bugfixes, we will open Pharo 12 branch 
> beginning of next week.
>
> Please, stop submitting enhancement/modification changes to Pharo 11, but 
> instead all bugfixes you can contribute are welcome :)
> cheers!
> Esteban
>

[Pharo-dev] [ANN] preparing for release, freezing enhancements :)

[Esteban Lorenzano]

Hello,

We are slowly preparing to release Pharo 11.
For those making changes that are not bugfixes, we will open Pharo 12 branch 
beginning of next week.

Please, stop submitting enhancement/modification changes to Pharo 11, but 
instead all bugfixes you can contribute are welcome :)
cheers!
Esteban

[Pharo-dev] Re: Linux OBS builds updated

[Esteban Lorenzano]

yes, but for windows the recommended way is to use the pharo launcher installer 
: https://files.pharo.org/pharo-launcher/windows
or, if you want to download the standalone VM: 
http://files.pharo.org/get-files/100/pharo-vm-Windows-x86_64-stable.zip
Esteban
On Jan 4 2023, at 3:25 pm, Aik-Siong Koh  wrote:
>
> Does Windows get as good support as Linux or Mac?
> I am waiting for the Home and End key to work on Windows.
> Thanks,
> Aik-Siong Koh
>
> Esteban Lorenzano wrote:
> >
> > Hi,
> >
> > I updated linux OBS builds to get it up to date with distro changes :
> > Added:
> > Fedora 37
> >
> > Ubuntu 22.10
> >
> > OpenSUSE Leap 15.3
> >
> > OpenSUSE Leap 15.4
> >
> >
> > Fixed:
> > Arch (Manjaro)
> >
> > OpenSUSE Tumbleweed
> >
> >
> > Removed (Obsoletes):
> > OpenSUSE Leap 15.1
> >
> > OpenSUSE Leap 15.2
> >
> > Fedora 32
> >
> > Fedora 33
> >
> >
> > You can test all the new/fixed as correspond: 
> > https://software.opensuse.org//download.html?project=devel%3Alanguages%3Apharo%3Alatest=pharo9-ui
> >
> > Enjoy,
> > Esteban
>

[Pharo-dev] Linux OBS builds updated

[Esteban Lorenzano]

Hi,

I updated linux OBS builds to get it up to date with distro changes :
Added:
Fedora 37

Ubuntu 22.10

OpenSUSE Leap 15.3

OpenSUSE Leap 15.4

Fixed:
Arch (Manjaro)

OpenSUSE Tumbleweed

Removed (Obsoletes):
OpenSUSE Leap 15.1

OpenSUSE Leap 15.2

Fedora 32

Fedora 33

You can test all the new/fixed as correspond: 
https://software.opensuse.org//download.html?project=devel%3Alanguages%3Apharo%3Alatest=pharo9-ui
Enjoy,
Esteban

[Pharo-dev] Re: What did happen with CustomHelp?

[Esteban Lorenzano]

yeah, CustomHelp was old and bad and we removed it.
better having nothing that a broken (and incomplete) tool.

anyway... eventually we will introduce the new document browser, and the idea 
is to externalize documentation.

Esteban
On Jan 3 2023, at 9:49 am, Marcus Denker  wrote:
> Hello,
>
> this issue has more infos:
> https://github.com/pharo-project/pharo/issues/12099
> I think we will add NewTools-DocumentationBrowser by default soon.
> Marcus
> > On 21 Dec 2022, at 23:39, Denis Kudriashov  wrote:
> >
> > Hi.
> >
> > There is no CustomHelp in Pharo 11 anymore. And no Help Browser in the menu.
> > What is the story behind it? Is there any new alternative?
> >
> > Now any external {Project}-Help package is not loadable into the new system.
> >
> > Regards,
> > Denis
>

[Pharo-dev] PhEP submitted: String interpolation for Pharo

[Esteban Lorenzano]

Hello,
There is a new PhEP (Pharo Enhancement Proposal) submitted titled: "String 
interpolation for Pharo" that requires the attention of the community:

https://github.com/pharo-project/pheps/pull/9
Cheers!
Esteban

[Pharo-dev] ANN: Introducing PhEPs (Pharo Enhancement Proposals)

[Esteban Lorenzano]

Hello,

Some of you were present at PharoDays 2022 were we made a presentation 
explaining this new way of handling the evolution of Pharo.
In that talk we explained that this is an attempt of having the community 
involved in more deep way, with a clear (and visible) decision process, taking 
the model the Python community has been using with success (so why not us? :P).

In a nutshell, the idea is that everybody wanting to work on any kind of 
enhancement for Pharo can now send their proposal and start a discussion 
process (a discussion arbitrated by the Pharo Board), and if this discussion 
leads to an accepted enhancement, the work will be integrated as part of the 
Pharo Environment.
How it works?
- There is a repository: https://github.com/pharo-project/pheps
- and a detailed description of the process: 
https://github.com/pharo-project/pheps/blob/main/phep-0001.md

You will have all the information you need there, but here is a summary of the 
process (you can also find it in the guidelines PhEP):
0. (Optional, but recommended) the proposer discusses the idea in pharo-dev 
list or discord, with members of the team, and gather ideas.
1. The proposer will clone the PhEP repository (pharo-project/pheps) and adds a 
proposal draft following the required stucture:
- the file will not have an ID, hence it needs to be called `phep-proposal.md`
- the proposal will have the header and structure explained in the section 
**Submitting a PhEP** (header, abstract, motivation and description).
- the proposal will also have a "champion" (which by default is the author 
itself), responsible for the implementation of the proposal in case is been 
accepted.
2. The proposal will be submitted as PR to the PhEP repository.
3. A mail will be send to `pharo-dev` mailing list, including the link and the 
abstract of the proposal.
4. There will be a discussion process and in case of acceptance of the 
proposal, an ID will be assigned by the reviewer.
5. As final stage, the author renames the `phep-proposal.md` file as 
`phep-ID.md` and includes the ID in the phep file header (this step can be 
performed by the reviewer if he decides so).
6. The reviewer will merge the PR

In the next days I will be sending a couple fo PhEPs to add to those already 
there, to get the process started.
Do not hesitate to participate!
Cheers,
Esteban

ps: Yes, I am aware "pheps" sounds fun on english :)

[Pharo-dev] [ANN] Pharo 10 released!

[Esteban Lorenzano]

Dear Pharo users and dynamic language lovers:

We have released Pharo version 10 (https://pharo.org/) !
Pharo is a pure object-oriented programming language and a powerful 
environment, focused on simplicity and immediate feedback.

Pharo 10 was a short iteration where we focused mainly on stability and 
enhancement of the environment :
Massive system cleanup
gained speed

removed dead code

removed old/deprecated frameworks (Glamour, GTTools, Spec1)

All Remaining tools written using the deprecated frameworks have been 
rewritten: Dependency Analyser, Critique Browser, and many other small 
utilities.

Modularisation has made a leap, creating correct baselines (project 
descriptions) for many internal systems, making possible the work and 
deployment of minimal images.

Removing support for the old Bytecode sets and embedded blocks simplified the 
compiler and language core.

As a result, our image size has been reduced by 10% (from 66MB to 58MB)

The VM has also improved in several areas: better async I/O support, socket 
handling, FFI ABI,

Even being a short iteration, we have closed a massive amount of issues: around 
600 issues and 700 pull requests. A more extended changelog can be found at 
https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo100ChangeLogs.md.

While the technical improvements are significant, still the most impressive 
fact is that the new code that got in the main Pharo 10 image was contributed 
by more than 80 people.
Pharo is more than code. It is an exciting project involving a great community.
We thank all the contributors to this release:
Aaron Bieber, Ackerley Tng, Alban Benmouffek, Alejandra Cossio, Aless Hosry, 
Alexandre Bergel, Aliaksei Syrel, Alistair Grant, Arturo Zambrano, Asbathou 
Biyalou-Sama, Axel Marlard, Bastien Degardins, Ben Coman, Bernardo Contreras, 
Bernhard Pieber, Carlo Teixeira, Carlos Lopez, Carolina Hernandez, Christophe 
Demarey, Clotilde Toullec, Connor Skennerton, Cyril Ferlicot, Dave Mason, David 
Wickes, Denis Kudriashov, Eric Gade, Erik Stel, Esteban Lorenzano, Evelyn Cusi 
Lopez, Ezequiel R. Aguerre, Gabriel Omar Cotelli, Geraldine Galindo, Giovanni 
Corriga, Guille Polito, Himanshu, Jan Bliznicenko, Jaromir Matas, Kasper 
Østerbye, Kausthub Thekke Madathil, Konrad Hinsen, Kurt Kilpela, Luz Paz, Marco 
Rimoldi, Marcus Denker, Martín Dias, Massimo Nocentini, Max Leske, 
Maximilian-ignacio Willembrinck Santander, Miguel Campero, Milton Mamani 
Torres, Nahuel Palumbo, Norbert Hartl, Norm Green, Nour Djihan, Noury 
Bouraqadi, Oleksandr Zaitsev, Pablo Sánchez Rodríguez, Pablo Tesone, Pavel 
Krivanek, Pierre Misse-Chanabier, Quentin Ducasse, Raffaello Giulietti, 
Rakshit, Renaud de Villemeur, Rob Sayers, Roland Bernard, Ronie Salgado, 
Santiago Bragagnolo, Sean DeNigris, Sebastian Jordan Montt, Soufyane Labsari, 
Stephan Eggermont, Steven Costiou, Stéphane Ducasse, Sven Van Caekenberghe, 
Theo Rogliano, Thomas Dupriez, Théo Lanord, Torsten Bergmann, Vincent Blondeau.

(If you contributed to Pharo 10 development in any way and we missed your name, 
please send us an email and we will add you).
Enjoy!
The Pharo Team
Discover Pharo: https://pharo.org/features
Try Pharo: http://pharo.org/download (https://pharo.org/download)
Learn Pharo: http://pharo.org/documentation (https://pharo.org/documentation)

[Pharo-dev] Re: ANN: Linux Open Build Service new versions

[Esteban Lorenzano]

that's the image, not the VM :)
(you need latest P10 image :P )

Esteban
ps: I use manjaro, so I am sure it has to be working for you now ;)
On Mar 17 2022, at 2:51 pm, Gabriel Cotelli  wrote:
> Thanks!
>
> I've tried the Arch instructions for Manjaro Linux but it seems that I have a 
> newer libgit2 version installed because when starting a Pharo 9 image I get a 
> debugger with
>
> Error: Cannot locate any of #('libgit2.1.0.0.so (http://libgit2.1.0.0.so)' 
> 'libgit2.so.1.0.0' 'libgit2.so.1.0' 'libgit2.so.1.1' 'libgit2.so.1.2' 
> 'libgit2.so.0.25.1'). Please check if it installed on your system"
>
> I've checked and it seems I have libgit 1.4
> ldconfig -p | grep libgit
> libgit2.so.1.4 (libc6,x86-64) => /usr/lib/libgit2.so.1.4
> libgit2.so (libc6,x86-64) => /usr/lib/libgit2.so
>
> Is anyone able to use the OBS builds for Manjaro or Arch?
> On Thu, Mar 17, 2022 at 9:26 AM Esteban Lorenzano  (mailto:esteba...@netc.eu)> wrote:
> > Hi,
> >
> > I have been preparing our OBS builds [1] for the Pharo 10 release.
> > We now include:
> >
> > Fedora 35
> > Ubuntu 21.10
> >
> > Debian 11
> >
> >
> >
> > And we fixed the rolling releases:
> > Arch
> > OpenSUSE Thumbleweed
> >
> >
> >
> > Enjoy!
> > Esteban
> >
> > [1] 
> > https://software.opensuse.org//download.html?project=devel%3Alanguages%3Apharo%3Alatest=pharo9-ui
>
>

[Pharo-dev] ANN: Linux Open Build Service new versions

[Esteban Lorenzano]

Hi,

I have been preparing our OBS builds [1] for the Pharo 10 release.
We now include:

Fedora 35
Ubuntu 21.10

Debian 11

And we fixed the rolling releases:
Arch
OpenSUSE Thumbleweed

Enjoy!
Esteban

[1] 
https://software.opensuse.org//download.html?project=devel%3Alanguages%3Apharo%3Alatest=pharo9-ui

[Pharo-dev] Re: Array sum. is very slow

[Esteban Lorenzano]

Nevertheless, I would like to stress that the usage of low level libraries to 
speed up what needs to fast is a correct approach in whatever language that 
exists, from old turbo pascal enabled an "asm" command to write directly 
assembly when needed to modern languages that implements their libraries in C 
and then use it... heck, even C libraries have parts written in assembly when 
needed!
I do not see why we can not gain speed in the places where is needed through a 
primitive, a plugin or a FFI call.

cheers!
Esteban

On Jan 12 2022, at 6:24 pm, teso...@gmail.com wrote:
> I have activated the plugin in the build for Pharo9, it will be available in 
> the next release.
>
> It will be interesting to have a Float64 extension to it.
> On Wed, Jan 12, 2022, 18:06 Marcus Denker  (mailto:marcus.den...@inria.fr)> wrote:
> >
> >
> > > On 12 Jan 2022, at 17:38, Henrik Sperre Johansen 
> > > mailto:henrik.s.johan...@veloxit.no)> 
> > > wrote:
> > > True!
> > > It’s a little bit of a naming conundrum, since the «Float» in Pharo is 
> > > already 64-bit, but since we’re speaking «native» arrays,
> > > DoubleArray
> > > would be the best, I guess.
> > >
> > > Speaking of, the related new (… to me, anyways) 
> > > DoubleByte/DoubleWordArray classes have incorrect definitions in Pharo 9 
> > > AFAICT- variableByte/WordSubclasses, instead of 
> > > variableDoubleByte/variableDoubleWordSubclasses…
> >
> > We finally fixed this in Pharo10 2 days ago: 
> > https://github.com/pharo-project/pharo/pull/9792
> >
> > Marcus

[Pharo-dev] Re: pharo9 tools moldability

[Esteban Lorenzano]

you have also this :

https://github.com/pharo-spec/smalltodo-example/blob/master/SmallTODO-Tutorial-1.md
Esteban
On Dec 19 2021, at 8:37 pm, Danil Osipchuk  wrote:
> Sebastian, yes, this is exactly kind of writeups I was asking for -- thanks
>
> regards,
> Danil
>
>
>
> вс, 19 дек. 2021 г. в 20:19, Sebastian Jordan Montano 
> mailto:sebastian.jor...@inria.fr)>:
> > This may interest you:
> >
> >
> > https://modularmoose.org/2021/05/04/how-to-build-a-new-moose-tool.html
> >
> > > De: "Danil Osipchuk"  > > (mailto:danil.osipc...@gmail.com)>
> > > À: "Pharo Development List"  > > (mailto:pharo-dev@lists.pharo.org)>
> > > Envoyé: Samedi 18 Décembre 2021 15:06:33
> > > Objet: [Pharo-dev] pharo9 tools moldability
> >
> >
> > > Dear all,
> > >
> > > Being a long time smalltalk user (meaning I'm crafting tools for my own 
> > > usage for domains I'm working with) I always relied upon the environment 
> > > itself to interact with models to spare time creating user interfaces. 
> > > Besides plain inspectors I used metafacilities where possible -- seaside, 
> > > then omnibrowser and lately glamour toolkit in pharo8.
> > > Now it seems the glamourous core is not part of pharo9 anymore. Meanwhile 
> > > pharo9 looks increasingly neat and I would like to make a transition but 
> > > having tools in pharo8 holds me back.
> > > I would be grateful for any pointers to help me to get started with the 
> > > moldable inspectors pharo9 - papers, talks, online discussions, etc. I 
> > > can likely figure it out on my own, but having an overall understanding 
> > > of the approach concept would save an effort and shorten the trial and 
> > > error phase.
> > > (maybe I'm overcomplicating it and just having browsed around inspector 
> > > code pragmas is enough to get started)
> > >
> > >
> > >
> > >
> > > regards,
> > > Danil
> > >
> >
> >
> >
> >
>
>

[Pharo-dev] Re: Ephemeron Status?

[Esteban Lorenzano]

hi Sean,

I guess this enters in the "needing properly image support" part :)
Esteban

On Oct 10 2021, at 1:35 am, s...@clipperadams.com wrote:
> Good news! Thanks for the update. Are blocks passed to announcements now 
> weakly held/properly disposed of? IIRC this was on hold for many years 
> pending proper ephemeron support

[Pharo-dev] [ANN] smalltalkCI now supports Pharo 10

[Esteban Lorenzano]

... this is more for Pharo developpers than Pharo users, but informing also 
users just in case :)

https://github.com/hpi-swa/smalltalkCI/pull/538
Esteban

[Pharo-dev] [ANN] Pharo 9 released!

[Esteban Lorenzano]

Dear World and dynamic language lovers:

The time has come for Pharo 9 (https://pharo.org/) !
Pharo is a pure object-oriented programming language and a powerful 
environment, focused on simplicity and immediate feedback.

Here are the key features of Pharo 9:
Full redesign of the Spec UI framework (new logic, application, style, GTK3 
back-end)
New tools:

new playground,

new object centric inspector,

new object centric debugger.

better and new Refactorings

class comments are now written in Microdown format (Markdown compatible)

classes now can be defined using a "fluid" api (Preview)

New completion framework that adapts better to edition contexts and is 
customizable

Fast universal non-blocking FFI which now uses libFFI as backend.

Pharo now supports Windows, OSX, Linux (Ubuntu, Debian, Fedora, openSUSE, Arch, 
Raspbian) and multiple architectures (Intel/ARM 32/64bits).

Virtual Machine

Idle VM

Support for ARM 64bits

Support for Apple M1

More than 3000 tests

Built for Ubuntu 18.04, 19.04, 20.04, 21.04, 21.10; Debian 9, 10, Testing; 
Fedora 32, 32, 34; openSUSE 15.1, 15.2, Tumbleweed; Manjaro; Arch

Uses SDL 2.0 as back-end by default. It supports extended event handling, 
including trackpad support.

General speed up due to compiler optimisations and UI simplification.

And many, many more tests.

These are just the more prominent highlights, but the details are just as 
important. We have closed a massive amount of issues: around 1400 issues and 
2150 pull requests.
A more extended changelog can be found at 
https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo90ChangeLogs.md.
While the technical improvements are significant, still the most impressive 
fact is that the new code that got in the main Pharo 9 image was contributed by 
more than 90 people.
Pharo is more than code. It is an exciting project involving a great community.
We thank all the contributors to this release:
Aaron Bieber, Ackerley Tng, Alban Benmouffek, Ale Cossio, Alexandre Bergel, 
Alistair Grant, Allex Oliveira, Angela Chia-Ling, Arturo Zambrano, Asbathou 
Biyalou-Sama, Ben Coman, Benoit Verhaegue, Carlo Teixeira, Carlos Lopez, 
Carolina Hernandez, Charles A. Monteiro, Christoph Thiede, Christophe Demarey, 
Clotilde Toullec, Cyril Ferlicot, Damien Pollet, Daniel Aparicio, David Bajger, 
David Sánchez i Gregori, Denis Kudriashov, Ellis Harris, Eric Brandwein, Eric 
Gade, Erik Stel, ErikOnBike, Esteban Lorenzano, Esteban Villalobos, Evelyn Cusi 
Lopez, Evelyn Cusi Lopez, Ewan Dawson, Francis Pineda, Francis Pineda, Gabriel 
Omar Cotelli, Geraldine Galindo, Giovanni Corriga, Guille Polito, Himanshu jld, 
Johan Brichau, Jonathan van Alteren, Jordan Montt, Julien Delplanque, Kamil 
Kukura, Kasper Østerbye, Kurt Kilpela, Laurine Dargaud, Marco Rimoldi, Marcus 
Denker, Martin Dias, Martin McClure, Massimo Nocentini, Max Leske, Maximilian 
Ignacio Willembrinck Santander, Milton Mamani Torres, Moussa Saker, Myroslava 
Romaniuk, Nicolas Anquetil, Norbert Hartl, Nour Djihan, Oleksandr Zaitsev, 
Pablo Sánchez Rodríguez, Pablo Tesone, Pavel Krivanek, Philippe Lesueur, Pierre 
Misse, Rakshit P., Rob Sayers, Roland Bernard, Ronie Salgado, Sean DeNigris, 
Sebastian Jordan Montaño, Serge Stinckwich, Stephan Eggermont, Steven Costiou, 
Stéphane Ducasse, Sven Van Caekenberghe, Thomas Dupriez, Théo Lanord, Théo 
Rogliano, Todd Blanchard, Torsten Bergmann, Vincent Blondeau, Wéslleymberg 
Lisboa.

(If you contributed with Pharo 9 development in any way and we missed your 
name, please send us an email and we will add you).
Enjoy!
The Pharo Team
Try Pharo: http://pharo.org/download (https://pharo.org/download)
Learn Pharo: http://pharo.org/documentation (https://pharo.org/documentation)

[Pharo-dev] Pharo Progress Report 2021-07-08

[Esteban Lorenzano]

So, this is it. The short term goals are now full of Pharo 9 release tasks, 
meaning we finished most of the technical issues remaining for the release: The 
M1 VM is available (and working in zeroconf), a new version of Pharo Launcher 
is ready to be unveiled all showstopper bugs fixed. Of course, that means more 
short term goals will emerge (but for next week!).
As a consequence, a new medium term goal has arrived: We want to do a new 
iteration on the Pharo process, attempting to improve the release cycle and the 
general way we work.

Short-term goals:
- Release 9
- Release Pharo Launcher for Pharo 9
- Release Zeroconf for Pharo 9

Medium-term goals:
- Review Pharo 10 process
- Removal of GTSpotter
- Removal of remaining GTTools

Long-term goals:
- Removal of Glamour
- Removal if Spec1
- Migration of Calypso to Spec2

## Last week
- last bits on Spec2 leaks fixing
- fixed some issues in iceberg.
- work on zeroconf (supporting ARM)
- make Open Build Service ready for Pharo 9
- Pharo Launcher ready for Pharo 9 release (including new P9 urls and M1 
support)

## This week
- prepare Pharo 9 release (announcements, reviewing site, final bugs, etc.)
- prepare Pharo Launcher for Pharo 9 release
- prepare Zeroconf for Pharo 9 release
- work on Pharo 9 by example

[Pharo-dev] Pharo Progress Report 2021-07-01

[Esteban Lorenzano]

Last week, the new inspector received some tests and class comments. Far from 
perfect to be honest, but it will be enough for this release, also class 
comments for Spec2 are ready to dispatch (even if also they can be improved, of 
course).

Short-term goals:
- Since we are in freeze mode: fixing important bugs on Pharo9 and its 
components (this issue will stay here until release).
- M1 VM release.
- include M1 in PharoLauncher

Medium-term goals:
- Removal of GTSpotter
- Release 9.0

Long-term goals:
- Removal of remaining GTTools
- Removal of Glamour
- Removal if Spec1
- Migration of Calypso to Spec2

## Last week
- fixed some memory leaks on Spec2 (and some "non leaks", but that needed to be 
taken into account, like better control of undo/redo history on text areas).
- cleaning some dependences.
- some work on microdown
- some work on methodwrappers

## This week
- Review OpenBulldService to make something that actually works :)
- Start preparing release "non technical" stuff
- Updating Pharo 9 by example

[Pharo-dev] Pharo Progress Report 2021-06-24

[Esteban Lorenzano]

This week, Spotter got class comments and some tests (not perfect, but better), 
and we improved tests and comments there, and in consequence is now "ready" to 
release (ready in the sense of "quality enough", bugs and improvements can 
always be needed) :)

Short-term goals:
- Improve quality and quantity of tests in StInspector
- Improve quality of class comments in Spec2 framework.
- Since we are in freeze mode: fixing important bugs on Pharo9 and its 
components (this issue will stay here until release).
- include M1 in PharoLauncher

Medium-term goals:
- Removal of GTSpotter
- M1 VM release.
- Release 9.0

Long-term goals:
- Removal of remaining GTTools
- Removal of Glamour
- Removal if Spec1

## Last week
- StSpotter workflow was tweaked, looking for the right behavior. Class 
comments and tests were added.
- NewTools settings are now exposed correctly in tools section of settings 
browser (is not just
reorganise new tools settings and make them more clear in settings browser 
(there are not many anyway).
- Fixed some memory leaks on Spec2.
- The usual bugfixes and PR processing.

## This week
- more tests in StInspector.
- verify showstopper bugs
- update pharolauncher with urls for Pharo 9 and enable M1 VM

[Pharo-dev] Pharo Progress Report 2021-06-16

[Esteban Lorenzano]

This week we move on with what's needed for the upcoming release, this time we 
make improvements on tests for playground and removed the pharo catalog... not 
bad, but more need to come :)

Short-term goals:
- Improve quality and quantity of tests in StInspector
- Improve quality and quantity of tests in StSpotter
- Improve quality of class comments in Spec2 framework.
- Since we are in freeze mode: fixing important bugs on Pharo9 and its 
components (this issue will stay here until release).
- include M1 in PharoLauncher

Medium-term goals:
- Removal of GTSpotter
- M1 VM release.
- Release 9.0

Long-term goals:
- Removal of remaining GTTools
- Removal of Glamour
- Removal if Spec1

## Last week
- removed catalog browser (it was obsolete and just a source of confusion for 
newbies)
- some homogeneisation on commands in code presenter that will affect all 
newtools
- fixing issues on Spec2/NewTools and writing tests
- we get close to an alpha version of pharo-launcher command line
- debugging an ARM32 problem
- fixed an emergent bug on global definitions in workspaces
- the usual PRs reviews/merges.

## This week
- hunting some leaks and fixing bugs on Spec2
- recovering the file browser dialog
- more debugging on the ARMv32

[Pharo-dev] Pharo Progress Report 2021-06-09

[Esteban Lorenzano]

We are slowly moving on to a "ready to release" status, but there are still 
some tasks to do and in fact we have one new short term task. Still, it does 
not looks but we have improve the stability and the speed of integrations, 
which means an overall better life and status to move on :)
Also, I splitted the short term goals in easier to messure tasks, so I can 
remove them ;)

Short-term goals:
- Improve quality and quantity of tests in StInspector
- Improve quality and quantity of tests in StSpotter
- Improve quality and quantity of tests in StPlayground
- Improve quality of class comments in Spec2 framework.
- Since we are in freeze mode: fixing important bugs on Pharo9 and its 
components (this issue will stay here until release).
- include M1 in PharoLauncher
- Remove pharo catalog from image

Medium-term goals:
- Removal of GTSpotter
- M1 VM release.
- Release 9.0

Long-term goals:
- Removal of remaining GTTools
- Removal of Glamour
- Removal if Spec1

## Last week
- ED (Emergency debugger) fixed (the UI was revamped to work on OSWindow and 
the SDL2 backend, in fact).
- Pass on Spec and NewTools repositories. Now development branches are called 
dev-1.0 and stable branch is "Pharo9.0" (will fit better the development cycle),
- Some enhancements in the new spotter
- For Spec, enhance tests in trees/lists/dropdowns.
- Stef added some improvements to microdown (Still for P10).
- Pablo made some fixes to the test runner
- ... and Marcus was busy fixing bugs and integrating PRs

### This week (starting 2021-06-07):
- Some final cleanups (GTSpotter and Catalog... yes, catalog is out because for 
now is better not having nothing that havign something that misslead people)
- Take care about some crashes in the new M1
- adapting PharoLauncher to download M1 VMs
- more on PharoLauncher command line

[Pharo-dev] Pharo Progress Report 2021-06-02

[Esteban Lorenzano]

Hi,

We finished one short term task : Improve integration structure of Spec2 and 
NewTools. I am adding an explanation of the change at the end of this report.
The rest is unchanged, with the addendum of we are starting to review medium 
term goals, because maybe we need to split "remove of GTTools" and move part of 
it to Pharo 10. Basically, removing now will cause ripples, and with the 
exception of GTSpotter and maybe GTPlayground, can push the release farther in 
time.

Short-term goals:
- Improve quality and quantity of tests in Spec2 and NewTools frameworks.
- Improve quality of class comments in Spec2 framework.
- Since we are in freeze mode: fixing important bugs on Pharo9 and its 
components (this issue will stay here until release).
- include M1 in PharoLauncher

Medium-term goals:
- Removal of GTTools
- M1 VM release.
- Release 9.0

## Last week
- Finished the pass on CI for Spec2 and NewTool (see document below).
- merged changes of NewTools (last one with the "old" CI)
- Pablo is working on a sockets problem
- Stef was working in microdown (but probably this will be for Pharo 10)
- several bugfixes in the context of our monthly sprint

## This week
- work on emergency debugger (ED) problems
- maybe work on make PharoLauncher download M1 VM when is required.
- more on Sockets
- pass on ReleaseTests for Pharo 9

cheers!
Esteban

ps: are you finding this reports useful? any idea on how can we improve them?


ci.docx
Description: Binary data

[Pharo-dev] Re: Fuel projects, anyone?

[Esteban Lorenzano]

Hola Gabriel!

I will be curious... which components are those?
Do we have a success story with them? ;)

Esteban
On May 27 2021, at 10:15 pm, Gabriel Cotelli  wrote:
> We're using Fuel to serialize the stack on unexpected errors to ease further 
> debugging. See 
> https://github.com/ba-st/Launchpad/blob/release-candidate/source/Launchpad/ErrorStackSerializer.class.st.
>
> So any project using ba-st/Launchpad (https://github.com/ba-st/Launchpad) is 
> indirectly using Fuel. For the record, the Pharo components running in the 
> backend of https://mercapabbaco.com are using this technique.
>
> Cheers,
> Gabriel
>
>
>
> On Thu, May 27, 2021 at 5:09 PM Max Leske  (mailto:maxle...@gmail.com)> wrote:
> > Hi everyone,
> >
> > I was made aware that there actually are people who use Fuel :) I rarely 
> > get feedback, apart from the spare bug report, so I was thrilled to hear 
> > about people who use it actively or even have applications in production 
> > that rely on Fuel.
> > To celebrate that (and boost my own ego of course...) I've added a 
> > "Projects using Fuel" section to the readme on GitHub and I'd love to see 
> > more entries in that list! So please let me know (or open a PR!) if you 
> > think your project deserves some exposure ;)
> > Here's the link: https://github.com/theseion/Fuel.
> > Stay awesome and positive!
> > Cheers,
> > Max
> >
> >
> >
> >
>
>

[Pharo-dev] Pharo Progress Report 2021-05-26

[Esteban Lorenzano]

(I changed the date format of this mails to something that is clear also in 
north america :) )

No much change since last week, with one task entering short term goals (in 
bold) and the rest unchanged (there was movement... just none of the tasks was 
finished :P).
Short-term goals:
- Improve integration infrastructure for Spec2 and NewTools frameworks.
- Improve quality and quantity of tests in Spec2 and NewTools frameworks.
- Improve quality of class comments in Spec2 framework.
- Since we are in freeze mode: fixing important bugs on Pharo9 and its 
components (this issue will stay here until release).
- include M1 in PharoLauncher

Medium-term goals:
- Removal of GTTools
- M1 VM release.
- Release 9.0

## Last week
- working on infrastructure (github actions and improving baselines and merge).
- Some enhancements to SpApplication (UI interactions), SpCodePresenter
- Added more tests to StInspector
- merged Spec2 0.9.13 (lots of improvements, see 
https://github.com/pharo-spec/Spec/releases/tag/v0.8.13)
- Pablo was working on improvements in the Test Runner and some experiments for 
future work on GC.
- Guille was working on profiling (a time consuming task, pun intended ;)) and 
metalinks
- Christophe is back and resuming the work on PharoLauncher (command line)
- Marcus was sketching some future clean ups and refactors (for Pharo 10) and 
as always, processing PRs :)

## This week
- finish a pass on NewTools (v0.6.6)
- start a clean up pass on Spec
- improve testing of NewTools (Infrastructure in general, StInspector if time).
- Resume plans for Pakbot (old Cargo)

[Pharo-dev] Pharo Progress Report 19/05/2021 (The Return)

[Esteban Lorenzano]

Hello!

The other day Torsten mention in discord that before was easier to follow what 
was going on due the reports we were publishing, and I think he is right. This 
reports stopped to being produced when the pandemic arise and lock-down was the 
norm... our organisation of work suffered and the reports were an undesirable 
victim :)
I intend to resume the publication of weekly status reports, with a difference: 
focusing on immediate changes is not productive anymore because we have the 
excelent report of Marcus for that (which follows the integrations in Pharo 
development branch).
So, I will talk about immediate and medium-term goals, and steps we are doing 
following them.
This is the first, let's see if this helps people to follow :)
Short-term goals:
- Improve integration infrastructure for Spec2 and NewTools frameworks.
- Improve quality and quantity of tests in Spec2 and NewTools frameworks.
- Improve quality of class comments in Spec2 framework.
- Since we are in freeze mode: fixing important bugs on Pharo9 and its 
components (this issue will stay here until release).

Medium-term goals:
- Removal of GTTools
- M1 VM release
- Release 9.0

# Last week work
## Last week:
- moved newtools and spec infrastructure to github actions (travis was being 
slow)
- fixed several bugs on SpGridLayout, SpDropListPresenter,SpTreePresenter and 
SpTreeTablePresenter
- fixed wrong enable/disable dynamic and style of buttons (also in toolbars).
- added some inspector extensions to improve visibility of Morph data
- added a lot of tests to new Playground, SpCodePresenter, SpTreePresenter and 
SpTreeTablePresenter.
- Pablo and Guille were working hard on improving the VM profiling 
infrastructure.
- making the ARM simulator work
- Working in the parallel execution of tests
- Improving the stability of Socket primitives
- Fixing problems in the Large Images support
- Extending DrTest to delegate the UI construction to the plugins
- Stef ported MethodWrappers to Pharo 9 (which allow a lot of profiling and 
"object centric" stuff.
- Finally, Marcus was busy processing PRs and discussing future steps (in part 
with me ;) )

## This week
(as always, this is just pointing in a direction, what later comes in depends 
on the work load, problems, and "unknowns")

- finish new infrastructure to improve integration speed of Spec2 and NewTools
- add tests to new Inspector
- more freezing actions (bugfixing, PR processing)

cheers!
Esteban

[Pharo-dev] [ANN] Freezing Pharo 9 development right now :)

[Esteban Lorenzano]

Hi,

So, today I was checking how much it is missing for release and what is our 
status, and I realized if we do not freeze now, we will never release in a 
reasonable time.
So, even if there are a couple of cleanups and that to still do that should 
happen before, I will declare that Pharo 9.0 enters in freeze Pharo 9.0 right 
now (and I will sneak the cleanups anyway, but being more careful).

What does this means?
No more features, just bugfixes

No more fixes of things that can wait until Pharo 10

In two weeks I will open the Pharo 10 development branch, up to then, please 
help fixing what's missing (which is a lot) !
Have a great weekend,
cheers!
Esteban

[Pharo-dev] Re: PharoJ now available for Pharo10

[Esteban Lorenzano]

that's nice... specially taking into account that Pharo10 does not yet exits :P

Esteban
On Apr 1 2021, at 1:38 pm, Noury Bouraqadi  wrote:
> Hi everyone,
>
> We continue to make progress during our weekly coding sessions. We are glad 
> to announce that this week we made a huge leap forward. Now PharoJS is 
> available for Pharo 10. To install it, run the following script in a Pharo 10 
> playground
> Metacello new
> baseline: 'PharoJS';
> repository: 'github://PharoJS/PharoJS:pharo10';
> load

[Pharo-dev] Re: Pharo - GSOC 2021

[Esteban Lorenzano]

Super !
Thank you very much to all people working to make it possible !

Esteban
On Mar 11 2021, at 7:33 am, Serge Stinckwich  wrote:
> Dear all,
>
> great news I want to share with you: Pharo has been selected to be part of 
> GSOC 2021
>
> https://summerofcode.withgoogle.com/organizations/?sp-search=pharo#4667274369171456
>
> Thank you to the great team of admins for making this happen: Oleksandr 
> Zaitsev, Gordana Rakic and Juan Pablo Sandoval Alcocer !
>
> We will send updates soon on the student selection process soon.
> Regards,
>
> --
> Serge Stinckwic
> h
>
> https://twitter.com/SergeStinckwich

[Pharo-dev] Re: Can anyone get recent Pharo9 builds to work on Linux?

[Esteban Lorenzano]

hi,

I still have no problem with any of that.
So you will have to be more specific : which image version, which VM version, 
which linux version.

Esteban
On Dec 27 2020, at 10:51 am, Danil Osipchuk  wrote:
> I can confirm text input is severely broken backspace/del (tried on Linux 
> buster, but it seems to be an image problem) -- control characters themselves 
> get inserted into text pane.
> Type a string into a pane, ex. '123456789', position cursor somewhere in the 
> middle, press del/backspace/ left arrows. If you inspect the string 
> you'll see control characters inside (evident at 'Items' tab)
>
> regards,
> Danil
>
>
> вс, 27 дек. 2020 г. в 02:08, Martin McClure  (mailto:mar...@hand2mouse.com)>:
> > If anyone can get recent (within the last week or so) 64-bit Pharo9
> > images to work on Linux, please let me know how you did that! I've tried
> > everything I can think of and no luck.
> >
> > For the purposes of this query, "working'' means that you can open a
> > playground, type into the it, then backspace over what you've typed.
> >
> > If you can do that on Linux, this information would be much appreciated:
> > * What build are you running?
> > * What VM are you running and where did you get it?
> > * How do you launch it? If from the command-line, what arguments?
> >
> > Thanks,
> > -Martin
>
>
>

[Pharo-dev] Re: Can anyone get recent Pharo9 builds to work on Linux?

[Esteban Lorenzano]

Hi Martin,

I just did :
wget -O- get.pharo.org/64/90+vmHeadlessLatest | bash
./pharo-ui Pharo.image

And I had no problem at all (except a libgit2 version that will be fixed soon).
I am using a Manjaro, but I do not see why it should not work on others.
Esteban
On Dec 27 2020, at 12:07 am, Martin McClure  wrote:
> If anyone can get recent (within the last week or so) 64-bit Pharo9
> images to work on Linux, please let me know how you did that! I've tried
> everything I can think of and no luck.
>
> For the purposes of this query, "working'' means that you can open a
> playground, type into the it, then backspace over what you've typed.
>
> If you can do that on Linux, this information would be much appreciated:
> * What build are you running?
> * What VM are you running and where did you get it?
> * How do you launch it? If from the command-line, what arguments?
>
> Thanks,
> -Martin
>

[Pharo-dev] Re: This week (49/2020) on the Issue Tracker

[Esteban Lorenzano]

On Dec 7 2020, at 5:22 pm, Guillermo Polito  wrote:
>
>
> > El 7 dic 2020, a las 17:02, Sean P. DeNigris  
> > escribió:
> >
> > Wow! Impressive list :)
> >
> >
> > Marcus Denker-4 wrote
> >> - Activation in single click (which triggers column expansion) is now
> >> default for inspections (it was double click, but it felt weird).
> >
> > -1 on this. The problem with single click is that it adds a column even when
> > you don't want it to. This was very annoying. IMO after using the
> > double-click for a few months (it took that long to get used to it), the
> > extra click is significantly less disruptive than the unnecessary column
> > adding.
>

>
> +1 on this.
> That is why I made double click by default when I first implemented it.
> Every time you click on glamour everything shifts, rotates, moves, it is 
> super disrupting when you **just want to click**.
>
> The single click should not shuffle the UI, or the UI should provide a way to 
> “click” on something without moving everything around.

that's why it was double click first and is a setting now.
I preferred the other way too, but people complained so I added a setting.
we are still trying so we can revert the default.
but there is a bug around I want to fix: default activation event is double 
click or enter, and that's not how it works now (easy to fix, though).

Esteban

[Pharo-dev] [ANN] New inspector as default in your Pharo9 image!

[Esteban Lorenzano]

Hi all,

Today we are introducing our new inspector based on NewTools.
This is part of our effort to replace all old tools (some based on Glamour, 
some based on Spec1 and some others in plain Morphic) to meet same design 
guidelines and prepare them for the future of the Pharo IDE.
Next weeks we will integrate the new Spotter, which will be the end of the 
Glamour migration effort. Some work on migrating Iceberg and other Spec1 tools 
are on its way (and they will be merged as soon as work reach beta status)

The most important changes for the new inspector are the inclusion of 
object-centric breakpoints, that apply only for the inspected object:
- Right click on any instance variable in the raw view shows a menu to install 
a breakpoint on accesses to that variable: the execution will break whenever 
this variable is read, written or both (this is configurable) but only for the 
inspected object.
- Right click on any method in the "Meta" view shows a menu to install a 
breakpoint on that method: the execution will break when that method is called 
but only for the inspected object.
- The toolbar shows a button to configure a breakpoint on state access for the 
inspected object: the execution will break whenever any instance variable of 
the object is accessed (read, write or both and configurable) but only for the 
inspected object.
- The breakpoint pane shows all breakpoints installed for the inspected object 
and for all other instances of the object's class. Use this pane to deactivate 
or to uninstall object-centric breakpoints.

Cheers!
Esteban

ps: Yes, there will be bugs (maybe a lot) and missing inspector extensions. I'm 
counting on you to report (or/and helping implement it)

[Pharo-dev] [ANN] NewTools 0.4 integrated into Pharo 9 (New Playground and New Debugger)

[Esteban Lorenzano]

Hi all,

Today we have integrated (finally!) the first version of our Spec2 
based NewTools.


While this is a fairly long process that will lead to all tools in 
Pharo to be written with the same framework and following the same 
design guidelines, we started with the easiest one (the playground) and 
one of the most complex (the debugger) to start fleshing out what we 
want to achieve.


Next weeks we will release the new inspector, which for now resides 
only inside the new debugger and it is just a proof of concept for the 
moment.



In general, for any tool to be a fair replacement to some other tool, 
it needs to fulfill this two criteria:


it needs to solve all the problems the previous tool solved, and

it needs to solve problems the previous tool did not.


What do you have to expect from the integrated new tools?

The new debugger:

Allows /object centric debugging./

Enhances extensibility, making adding plugins a lot easier than before.

Enables /scripting/.

The new playground

Enables /sharing variables/between playgrounds

Enhances visibility of binding variables by embedding an inspector

Enhances visibility of saved pages


Both tools should cover already most of the functionality the older 
tools but there are still some missing features and for sure a good 
amount of bugs you will find it and we will gladly fix :)


Do you want to know more?


Object centric debugging tutorial: 



Sindarin scripting API: 

Playground help file: 




Enjoy!

Esteban

Re: [Pharo-dev] Spec2 dynamic list layouts seem confused

[Esteban Lorenzano]

Yes, I think they need to be removed.

On ven., juil. 10, 2020 at 10:17, Martin McClure 
 wrote:

Hi Esteban,

 It's good to hear that all layouts are now dynamic!

 Does that mean that you'll be removing 
SpDynamicPresentersListBuilder and friends? If not, it still needs to 
be fixed.


 Thanks,
 -Martin

 On 7/10/20 1:47 AM, Esteban Lorenzano wrote:

Hi Martin,

In fact, all those examples needs to be removed and replaced by new 
ones. They correspond to a moment where Spec was very static. But 
now all layouts are dynamic so they do not have sense (and they do 
not work fine either).


Next merge (0.8) will have a focus on those details, now that we are 
arriving to a semi-stable status :)


Esteban

 On jeu., juil. 9, 2020 at 23:03, Martin McClure 
 <mailto:mar...@hand2mouse.com> wrote:
I wanted to see examples of dynamic layout in Spec2, and tried 
SpCalendarPresenter.


AFAICT, SpCalendarPresenter is doing the right thing, using 
SpDynamicLeftToRightColumnsLayout. However, the subclasses of 
SpDynamicPresentersListLayout seem to have the concepts of row and 
column swapped, so that the SpDynamicLeftToRightColumnsLayout is 
actually doing what the SpDynamicTopToBottomRowsLayout should do. 
And vice versa.


I hope to take a deeper look tomorrow.

If I wanted to submit a pull request with the fix, what repo should 
I be working with?


Thanks,
-Martin

Re: [Pharo-dev] Spec2 dynamic list layouts seem confused

[Esteban Lorenzano]

Hi Martin,

In fact, all those examples needs to be removed and replaced by new 
ones. They correspond to a moment where Spec was very static. But now 
all layouts are dynamic so they do not have sense (and they do not work 
fine either).


Next merge (0.8) will have a focus on those details, now that we are 
arriving to a semi-stable status :)


Esteban

On jeu., juil. 9, 2020 at 23:03, Martin McClure  
wrote:
I wanted to see examples of dynamic layout in Spec2, and tried 
SpCalendarPresenter.


AFAICT, SpCalendarPresenter is doing the right thing, using 
SpDynamicLeftToRightColumnsLayout. However, the subclasses of 
SpDynamicPresentersListLayout seem to have the concepts of row and 
column swapped, so that the SpDynamicLeftToRightColumnsLayout is 
actually doing what the SpDynamicTopToBottomRowsLayout should do. And 
vice versa.


I hope to take a deeper look tomorrow.

If I wanted to submit a pull request with the fix, what repo should I 
be working with?


Thanks,
-Martin

Re: [Pharo-dev] Spec2 -- where to discuss?

[Esteban Lorenzano]

hi,

cool!
here, discord and elsewhere are all valid places ;)

Esteban

On mar., juil. 7, 2020 at 13:56, Martin McClure  
wrote:

Hi all,

I've started working with the Spec2 preview in Pharo 9. So far, I'm 
doing OK on my own, but I imagine I'll have some questions.


What's the best place to ask Spec2 questions, make suggestions, 
possibly make minor contributions? Here? Discord (which I haven't yet 
used)? Elsewhere?


Thanks,
-Martin

Re: [Pharo-dev] Pharo 7.0.5

[Esteban Lorenzano]

yes

On lun., juin 29, 2020 at 11:05, Sven Van Caekenberghe  
wrote:

And will I get that version using

$ curl get.pharo.org/64/70 | bash

and will that version be available in the Pharo Launcher as well ?

 On 29 Jun 2020, at 10:51, Esteban Lorenzano <mailto:esteba...@netc.eu>> wrote:


 ok, in theory... you have Pharo 7.0.5 now, as final version.

 Esteban

 On lun., juin 29, 2020 at 09:11, Sven Van Caekenberghe 
mailto:s...@stfx.eu>> wrote:

 OK, thanks.


  On 29 Jun 2020, at 06:58, Esteban Lorenzano <mailto:esteba...@netc.eu>

 > wrote:

  Hi Sven,

  In general, I would say Pharo 7 is not maintained anymore, but in 
this case I think we should have done this as last task before 
closing it.
  I will try to do a final release now (we'll see how it works, it 
should be an easy task but two years happened since P7 so... we 
will not know until we try ;) )


  Esteban

  On dim., juin 28, 2020 at 20:32, Sven Van Caekenberghe <
 s...@stfx.eu <mailto:s...@stfx.eu>
 > wrote:

  PING: I still did not yet get any answer.


   On 17 May 2020, at 12:27, Sven Van Caekenberghe <
 s...@stfx.eu <mailto:s...@stfx.eu>

  > wrote:

   Hi,

   Is there any intention of officially releasing Pharo 7.0.5 ?

   There are 18 commits after 7.0.4



 <https://github.com/pharo-project/pharo/compare/v7.0.4...Pharo7.0>



   I need the following



 <https://github.com/pharo-project/pharo/pull/5079>



   which is one of the 18 commits

   Zinc HTTP Components is currently partially broken on Pharo 9 
because #digitAt: was replaced by #byteAt: and #digitAt: is now 
removed.


   In order to fix this I could start using #byteAt: as far back as 
7.0.5 and add it myself for even older Pharo versions using my 
Zinc-Pharo-Forward-Compatibility package.


   What has to happen to make it possible to release 7.0.5 ? More 
testing ? Where is the artefact to test ?


   Thx,

   Sven

Re: [Pharo-dev] Pharo 7.0.5

[Esteban Lorenzano]

ok, in theory... you have Pharo 7.0.5 now, as final version.

Esteban

On lun., juin 29, 2020 at 09:11, Sven Van Caekenberghe  
wrote:

OK, thanks.

 On 29 Jun 2020, at 06:58, Esteban Lorenzano <mailto:esteba...@netc.eu>> wrote:


 Hi Sven,

 In general, I would say Pharo 7 is not maintained anymore, but in 
this case I think we should have done this as last task before 
closing it.
 I will try to do a final release now (we'll see how it works, it 
should be an easy task but two years happened since P7 so... we will 
not know until we try ;) )


 Esteban

 On dim., juin 28, 2020 at 20:32, Sven Van Caekenberghe 
mailto:s...@stfx.eu>> wrote:

 PING: I still did not yet get any answer.


  On 17 May 2020, at 12:27, Sven Van Caekenberghe <mailto:s...@stfx.eu>

 > wrote:

  Hi,

  Is there any intention of officially releasing Pharo 7.0.5 ?

  There are 18 commits after 7.0.4


 <https://github.com/pharo-project/pharo/compare/v7.0.4...Pharo7.0>


  I need the following


 <https://github.com/pharo-project/pharo/pull/5079>


  which is one of the 18 commits

  Zinc HTTP Components is currently partially broken on Pharo 9 
because #digitAt: was replaced by #byteAt: and #digitAt: is now 
removed.


  In order to fix this I could start using #byteAt: as far back as 
7.0.5 and add it myself for even older Pharo versions using my 
Zinc-Pharo-Forward-Compatibility package.


  What has to happen to make it possible to release 7.0.5 ? More 
testing ? Where is the artefact to test ?


  Thx,

  Sven

Re: [Pharo-dev] Pharo 7.0.5

[Esteban Lorenzano]

Hi Sven,

In general, I would say Pharo 7 is not maintained anymore, but in this 
case I think we should have done this as last task before closing it.
I will try to do a final release now (we'll see how it works, it should 
be an easy task but two years happened since P7 so... we will not know 
until we try ;) )


Esteban

On dim., juin 28, 2020 at 20:32, Sven Van Caekenberghe  
wrote:

PING: I still did not yet get any answer.

 On 17 May 2020, at 12:27, Sven Van Caekenberghe > wrote:


 Hi,

 Is there any intention of officially releasing Pharo 7.0.5 ?

 There are 18 commits after 7.0.4

 

 I need the following

 

 which is one of the 18 commits

 Zinc HTTP Components is currently partially broken on Pharo 9 
because #digitAt: was replaced by #byteAt: and #digitAt: is now 
removed.


 In order to fix this I could start using #byteAt: as far back as 
7.0.5 and add it myself for even older Pharo versions using my 
Zinc-Pharo-Forward-Compatibility package.


 What has to happen to make it possible to release 7.0.5 ? More 
testing ? Where is the artefact to test ?


 Thx,

 Sven

Re: [Pharo-dev] Completion Setting Split-Up

[Esteban Lorenzano]

Hi Sean, 

Because NECPreferences is attached to Settings subsystem which is a Morphic 
component and it will pull all morphic/tools/etc. dependences whenever 
included/referenced. That way, if we want to split the completion framework 
from Moprhic/Rubric, we need to inverse the dependency (instead NEEntry 
depending on NECPreferences, NECPreferences depending on NECEntry).

Esteban

> On 24 Jun 2020, at 23:34, Sean P. DeNigris  wrote:
> 
> Why has NECPreferences `#spaceAfterCompletion` been moved to NECEntry in
> Pharo 9? Usability seems a bit worse because the user now has to know about
> two objects to configure it. Also, it was originally held in a class-side
> instVar, which made it seem like different NECEntry subclasses might have
> different behavior and might justify the move, but it is now a class var,
> shared by all, and so the behavior seems the same...
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 

Re: [Pharo-dev] Want to run C code in Pharo using UFFI

[Esteban Lorenzano]

Hi,

You need to have gcc or clang installed, pharo will not do the compile job for 
you.
Then you can execute something like 

LibC system: ‘g++ -o myprogram myprogram.cpp’

Esteban

> On 18 Jun 2020, at 09:42, Shawon Hoque  wrote:
> 
> Hello
> Do you have any idea about compiling a C/C++ file using LibC in pharo ? if  i 
> can compile a C++ file using Pharo than i can run that .exe file using pharo 
> LibC
> 
> Thanks
> 
> On Thu, Jun 18, 2020 at 3:25 PM hogoww  > wrote:
> Using Astares's answer you can do:
> 
>  LibC system: 'my command line for compilation'
> 
> Pierre
> On 18/06/2020 09:21, Shawon Hoque wrote:
>> Hello
>> Do you have any idea about compiling a C/C++ file using LibC in pharo ? if  
>> i can compile a C++ file using Pharo than i can run that .exe file using 
>> pharo LibC
>> 
>> Thanks
>> 
>> 
>> On Thu, Jun 18, 2020 at 3:13 PM Torsten Bergmann > > wrote:
>> From the filename I guess it is Windows. Should work with:
>> 
>>   LibC system: 'D:/DEV_FreeCAD/build/bin/box.step'
>> 
>> but note that .step is not a regular executable extension like EXE and other.
>> More a file type that is associated with the executable of free cad.
>> 
>> You can also check the Process class in 
>> https://github.com/astares/Pharo-OS-Windows 
>> 
>> if you need more control.
>> 
>> For detailed questions you can meet me on Pharo Discord.
>> 
>> Bye
>> T. (aka astares)
>> 
>> 
>> > Gesendet: Donnerstag, 18. Juni 2020 um 08:18 Uhr
>> > Von: "shawon58" mailto:shawonhoqu...@gmail.com>>
>> > An: pharo-dev@lists.pharo.org 
>> > Betreff: [Pharo-dev] Want to run C code in Pharo using UFFI
>> >
>> > Hello There
>> > i am new to Pharo, so as i learn UFFI can handle c code, but i want to know
>> > that, how to run below attached code using UFFI.
>> >
>> > #include
>> > #include
>> >
>> > int main( void ) {
>> >
>> >   int result ;
>> >   result=system("D:/DEV_FreeCAD/build/bin/box.step");
>> >   printf("%d",result);
>> >   return 0;
>> > }
>> >
>> >
>> > So if anyone have idea please share with me. It will be a great help to me.
>> >
>> > Thanks for your kind help
>> >
>> >
>> >
>> > --
>> > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html 
>> > 
>> >
>> >
>> 

[Pharo-dev] [Mm10s] 2020-06-15

[Esteban Lorenzano]

### Last week:

* [Spec2] rename ToolBar* with Toolbar
* [Spec2] Finished a huge iteration to split Spec into SpecCore and Morphic 
backend
* [TFFI] refactored TFPointerType>>write:into to use a dispatch instead a 
chained if. 
* [UFFI] FFILibraryFinder is now more intelligent: it can find from a list 
of libraries
(#findAnyLibrary:) and it can receive also a list of user defined paths 
(#userPaths:) to enhance
the lookup and allow customisation. Also, unix 64bit known paths list has 
been enlarged
incorporating /lib64 and /usr/lib64
* [NewTools-Playground] bug: "implementors" is not working (NOT FIXED YET)
* [NewTools] Fixed a bug when inspecting attribute values on debugger (and 
find problems to 
feed Steven ;) ).
* [Pharo 9] fixed a dependency of FreeType on Morphic (if you wanted 
FreeType, you needed to
install all Morphic to have that working)
* [Idle-VM] w/Pablo  fix socket problems in windows (in fact, it was not a 
bug but the fact that the 
headless VM will not work on Win7)
* [Idle-VM] w/Pablo Worked a lot with OBS to package pharo for different 
Linux distors. At the end, we
got one more or less working.
* [Spec2-doc] pass on CaseStudyOne.pillar - Style
* [OBS] added Fedora_32, Fedora_31 build.
* [OBS] working on Debian distros (WIP).


### This week (starting 2020-06-15):

- more OBS (trying to get Debian to build).
- more NewTools (playground)
- more Spec2 refactor to get it ready to a new merge. 

[Pharo-dev] [Mm10s] 2020-06-08

[Esteban Lorenzano]

### Last week:


   * [Idle-VM] w/Pablo. Worker problem with delays
   worker version was not interrupting the aio. We spent some time here and 
this was a non existing 
   problem at the end (but we found and fix a bug on Spec2-Gtk).
   * [Idle-VM] problem when save image with gtk backend
   fix a bug happening when application was shutting down and some events want 
still happen, who
   causes a callback that is alredy discarded to be executed.
   * [Idle-VM] new version of memory access
   test, bench and merge of new memory access primitive
   (lowcode didn't applied, finally)
   * [spec2] preparation of a window box to make some tests there.
   * [spec2] gtk backend now has an image-side based tree store, which allows 
much better
   interoperability. Next task is to migrate the adaptors: list, table and 
treetable (not trivial,
   but needed)
   * [TFFI] added a new type: FFIBoolean32 to handle the fact that many 
libraries (in my case,
   Gtk), do not use bool=8bit implementation. Now, users need to map their 
boolean (in my case,
   gboolean) to this type by hand. I didn't find a better way to fix this issue 
:(
   * [spec2] gtk backend now answers propertly to keyboard events in windows.
   * [spec2] fix a (new) bug on GtkTreeView, because we do not need to unref 
stores manually. This
   bug was introduced by my recent fix on GtkTreeView, which initialize method 
was not sending
   super.
   * [spec2] avoid the traverse of roots when releasing a GtkTreeDataStore (Gtk 
does that)
   * [spec2] list/table/tree migrated to use the new GtkTreeDataStore (lots of 
simplifications,
   specially on GtkTreeTableAdapter)
   * [NewTools-Playground] bug: doit from toolbar does not uses interactionMode
   * [Spec2-doc] Add style section (reference) to SpApplication
   * [NewTools-Playground] bug: "implementors" is not working. I couldn’t 
reproduce the problem. 
   Maybe is fixed now?

### This week (starting 2020-06-08):


- Mostly cleanups and re-organisations on Spec2 (preparing v0.7 for Pharo9)
- Preparing v0.1 of NewTools (also, to prepare an integration to Pharo9)
- Building VM on Fedora linux
- Testing Idle-VM on Windows

Re: [Pharo-dev] [Pharo-users] About strange email related to smalltalkhub read-only on squeak-dev

[Esteban Lorenzano]

Yes, also the project is MIT so… anyone has the right to take it and use 
it/modify it/etc. with the only constraint of mention all the contributors.

But anyway, for me the most important question is: How far are we to provide 
good FFI bindings to a security library (like openssl or/and others) that will 
allow us to escape this situation? I really prefer not to have a hard to 
maintain solution that will also annoy the original authors who put its code in 
MIT but didn’t realise the implications of it.

Esteban

> On 1 Jun 2020, at 08:59, Sven Van Caekenberghe  wrote:
> 
> 
> 
>> On 1 Jun 2020, at 06:39, Jerry Kott  wrote:
>> 
>> If you read the text of the EAR and take into account all other facts, I 
>> think that the notion that anyone should get into trouble by copying open 
>> source Smalltalk crypto libraries to other repositories is just a pure FUD. 
>> This software is open source, it is publicly available including the source 
>> code, it is hosted on a domain that is controlled by a non-US entity, and 
>> it’s easily accessible in its current form from countries that are currently 
>> on the US ‘vorboten’ list.
> 
> Indeed.
> 
> 

[Pharo-dev] [Mm10s] 2020-05-25

[Esteban Lorenzano]

### Last week:

* PR to remove enlumineur UI and tests from Pharo because it is not working 
and is causing
problems with the Spec2 0.6 merge.
* [Spec2] new merge with P9
* [newtools] profile inspector to see why StHeaderBar rendering is so slow 
in morphic (and it
was because of the use of some font not standard).
* [spec2] optimise a bit the application os styles by keeping the defined 
font instead look for
it each time. This speeds up StDebugger a lot :)
* [vm] compiling the vm on fedora 32. Some problems around, but I got it 
building (more or less,
I needed to use clang). Now, I have problems with the load of modules (like 
libgit2).
* [spec2] fix a bug on gtk in which labels and images where not responding 
to events defined in
#eventHandler.
* [spec2] fix a bug that was preventing some commands on GtkMillerAdapter 
to be executed
correctly
* [spec2] fix a bug on toolbar buttons (gtk side) that was causing the vm 
to crash because
sometimes I keep invalid references (this may cause problems later?).
* [spec2] code: I made a HUGE refactor on how interactionModel works (now 
they are real objects,
and users need to use one of the existent or implement their own)


### This week (starting 2020-05-25):

- work with the new inspector.
- fixes on Gtk backend
- finish (If possible) the Fedora 32 build

Re: [Pharo-dev] uFFI: What is the difference between FFIExternalObject and FFIOpaqueObject?

[Esteban Lorenzano]

Hi,

That’s not really possible :)
In your case, Method is already a pointer (with arity 1).
Which means 

Method *

Is in fact a pointer to a pointer (arity 2), something like "void**"

This is a typical case, but you are not “having the two cases”, you still have 
one :)

UFFI will try to box/unbox that for you, btw… but sometimes this is not what 
you want (because pointers to pointers is a typical way to answer lists, for 
example). And UFFI does not know what you want there… in this cases (when you 
want the list), the recommended way is to get the pointer and create the list 
yourself. Instead: 

Method *methodList()

You call 

void *methodList()

To avoid the unbox attempt, and then you process your answer “in raw” (for 
example using the #readArrayOf:until: method).

If it happens that you use both SomeStructure, and SomeStructure*, then is not 
an opaque type, and you need to map it by subclasses FFIExternalStructure and 
implementing fieldsDesc, etc.

Esteban

> On 23 May 2020, at 20:00, Sean P. DeNigris  wrote:
> 
> Esteban Lorenzano wrote
>> The easiest way I have to explain is: 
>> 
>> You use an OpaqueObject when you will refer to the opaque type in calls
>> as:  someFunction(opaqueobject *someArg).
>> You use an ExternalObject when you will refer to the opaque type in calls
>> as: someFunction(externalobject someArg).
> 
> Very clear! We're getting somewhere :) But...
> 
> What if a type is used both ways? 
> 
> For example:
>   ^ self ffiCall: #(Method * class_copyMethodList(Class self, uint
> *outCount))
> and
>   ^ self ffiCall: #(struct objc_method_description *
> method_getDescription(Method self))
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 

Re: [Pharo-dev] uFFI: What is the difference between FFIExternalObject and FFIOpaqueObject?

[Esteban Lorenzano]

> On 22 May 2020, at 15:25, Esteban Lorenzano  wrote:
> 
> 
>> On 22 May 2020, at 15:07, Ben Coman > <mailto:b...@openinworld.com>> wrote:
>> 
>> 
>> 
>> On Fri, 22 May 2020 at 15:25, Esteban Lorenzano > <mailto:esteba...@netc.eu>> wrote:
>>> On 22 May 2020, at 04:24, Sean P. DeNigris >> <mailto:s...@clipperadams.com>> wrote:
>>> 
>>> Esteban Lorenzano wrote
>>>> The class comments are not clear?
>>> 
>>> Maybe it's me ;-)
>> 
>> 
>> No. I struggled with this also, and still don't have it fully grasped.  I 
>> could follow Eteban's advice in a particular case I asked about, but still 
>> feel hard to reason about next time. 
>> http://forum.world.st/typedef-pointerArity-for-FFIOpaqueObjects-td4914975.html
>>  
>> <http://forum.world.st/typedef-pointerArity-for-FFIOpaqueObjects-td4914975.html>
>>  
>> http://forum.world.st/UFFI-isPointer-absolute-or-versus-naturalPointerArity-td4917236.html
>>  
>> <http://forum.world.st/UFFI-isPointer-absolute-or-versus-naturalPointerArity-td4917236.html>
>>  
>>  
>>> 
>>> 
>>> Esteban Lorenzano wrote
>>>> Opaque object = https://en.wikipedia.org/wiki/Opaque_data_type 
>>>> <https://en.wikipedia.org/wiki/Opaque_data_type>
>>>> https://en.wikipedia.org/wiki/Opaque_data_type 
>>>> <https://en.wikipedia.org/wiki/Opaque_data_type>;
>>>> External object = a pointer to something. 
>>> 
>>> For example, why is ObjCClass a subclass of FFIExternalObject instead of
>>> FFIOpaqueObject when the docs say that a "Class [is] An opaque type that
>>> represents an Objective-C class"? Also, is the distinction just conceptual?
>>> I don't see what either class "buys" you in behavior since they are siblings
>>> that both pretty much have no methods. 
>> 
>> 
>> This is because ObjCClass = SomeOpaqueStructurePointer (is already a 
>> pointer), same as ObjCSelector and ObjCMethod.
>> Difference is subtle, because is just a different way of representing the 
>> same. 
>> 
>> The easiest way I have to explain is: 
>> 
>> As a prelude to my next comment, how does "External" distinguish between the 
>> two case?
>> Aren't both cases dealing with external C data? 
>> 
>> You use an OpaqueObject when you will refer to "the opaque type" in calls 
>> as:  someFunction(opaqueobject *someArg).
>> You use an ExternalObject when you will refer to "the opaque type" in calls 
>> as: someFunction(externalobject someArg).
>> 
>> That makes the distinction really clear.  So if now IIUC, both cases deal 
>> with "opaque types" 
>> with the *only* difference between the two being the arity?
>> Then I propose the following naming would be more intention revealing...
>> 
>> OpaqueObject when you will refer to "the opaque type" in calls as:  
>> someFunction(opaqueobject *someArg).
>> OpaquePointer when you will refer to "the opaque type" in calls as: 
>> someFunction(opaquepointer someArg).  
>> 
>> 
>> And to test my new understanding, the matching typdefs and FFI calls would 
>> be...
>> 
>> OPAQUE OBJECT
>> -  typedef MyOpaqueType opaqueobject.
>> -  int someFunction(opaqueobject *someArg) 
>> 
>> -  FFIOpaqueObject subclass: #MyOpaqueType.
>> -  self ffiCall: #(int someFunction( MyOpaqueType *ot ) ).
>> - opaque type has arity 0, so FFI needs to take a pointer to it  
>>  
>> OPAQUE POINTER
>> -  typedef MyOpaqueObject *opaquepointer.
>> -  int someFunction(opaquepointer someArg) 
>> 
>> -  FFIOpaquePointer subclass: # MyOpaqueType.
>> -  self ffiCall: #(int someFunction( MyOpaqueType ot ) ).
>> - opaque type has arity of 1,  so FFI uses it directly 
>> 
>> The latter FFI call is without the *… because FFIOpaquePointer is already a 
>> pointer. 
>> In practice, both FFI calls are identical, and you use the one that matches 
>> the C header definitions.
>> 
>> 
>> ...or maybe I still don't get it.
> 
> No, you got it :)
> Part of the confusion is the horribly bad name that FFIExternalObject has :/
> Other part is my inability to explain it ;)
> 
> But yes, this is all as you say.
> If someone wants to do a PR changing the names and maybe enhancing my 
> comments… it would be nice :D
Of course keeping the old names as deprecated! ;)

> 
> Esteban
> 
>> 
>>  cheers -ben
> 

Re: [Pharo-dev] uFFI: What is the difference between FFIExternalObject and FFIOpaqueObject?

[Esteban Lorenzano]

> On 22 May 2020, at 15:07, Ben Coman  <mailto:b...@openinworld.com>> wrote:
> 
> 
> 
> On Fri, 22 May 2020 at 15:25, Esteban Lorenzano  <mailto:esteba...@netc.eu>> wrote:
>> On 22 May 2020, at 04:24, Sean P. DeNigris > <mailto:s...@clipperadams.com>> wrote:
>> 
>> Esteban Lorenzano wrote
>>> The class comments are not clear?
>> 
>> Maybe it's me ;-)
> 
> 
> No. I struggled with this also, and still don't have it fully grasped.  I 
> could follow Eteban's advice in a particular case I asked about, but still 
> feel hard to reason about next time. 
> http://forum.world.st/typedef-pointerArity-for-FFIOpaqueObjects-td4914975.html
>  
> <http://forum.world.st/typedef-pointerArity-for-FFIOpaqueObjects-td4914975.html>
>  
> http://forum.world.st/UFFI-isPointer-absolute-or-versus-naturalPointerArity-td4917236.html
>  
> <http://forum.world.st/UFFI-isPointer-absolute-or-versus-naturalPointerArity-td4917236.html>
>  
>  
>> 
>> 
>> Esteban Lorenzano wrote
>>> Opaque object = https://en.wikipedia.org/wiki/Opaque_data_type 
>>> <https://en.wikipedia.org/wiki/Opaque_data_type>
>>> https://en.wikipedia.org/wiki/Opaque_data_type 
>>> <https://en.wikipedia.org/wiki/Opaque_data_type>;
>>> External object = a pointer to something. 
>> 
>> For example, why is ObjCClass a subclass of FFIExternalObject instead of
>> FFIOpaqueObject when the docs say that a "Class [is] An opaque type that
>> represents an Objective-C class"? Also, is the distinction just conceptual?
>> I don't see what either class "buys" you in behavior since they are siblings
>> that both pretty much have no methods. 
> 
> 
> This is because ObjCClass = SomeOpaqueStructurePointer (is already a 
> pointer), same as ObjCSelector and ObjCMethod.
> Difference is subtle, because is just a different way of representing the 
> same. 
> 
> The easiest way I have to explain is: 
> 
> As a prelude to my next comment, how does "External" distinguish between the 
> two case?
> Aren't both cases dealing with external C data? 
> 
> You use an OpaqueObject when you will refer to "the opaque type" in calls as: 
>  someFunction(opaqueobject *someArg).
> You use an ExternalObject when you will refer to "the opaque type" in calls 
> as: someFunction(externalobject someArg).
> 
> That makes the distinction really clear.  So if now IIUC, both cases deal 
> with "opaque types" 
> with the *only* difference between the two being the arity?
> Then I propose the following naming would be more intention revealing...
> 
> OpaqueObject when you will refer to "the opaque type" in calls as:  
> someFunction(opaqueobject *someArg).
> OpaquePointer when you will refer to "the opaque type" in calls as: 
> someFunction(opaquepointer someArg).  
> 
> 
> And to test my new understanding, the matching typdefs and FFI calls would 
> be...
> 
> OPAQUE OBJECT
> -  typedef MyOpaqueType opaqueobject.
> -  int someFunction(opaqueobject *someArg) 
> 
> -  FFIOpaqueObject subclass: #MyOpaqueType.
> -  self ffiCall: #(int someFunction( MyOpaqueType *ot ) ).
> - opaque type has arity 0, so FFI needs to take a pointer to it  
>  
> OPAQUE POINTER
> -  typedef MyOpaqueObject *opaquepointer.
> -  int someFunction(opaquepointer someArg) 
> 
> -  FFIOpaquePointer subclass: # MyOpaqueType.
> -  self ffiCall: #(int someFunction( MyOpaqueType ot ) ).
> - opaque type has arity of 1,  so FFI uses it directly 
> 
> The latter FFI call is without the *… because FFIOpaquePointer is already a 
> pointer. 
> In practice, both FFI calls are identical, and you use the one that matches 
> the C header definitions.
> 
> 
> ...or maybe I still don't get it.

No, you got it :)
Part of the confusion is the horribly bad name that FFIExternalObject has :/
Other part is my inability to explain it ;)

But yes, this is all as you say.
If someone wants to do a PR changing the names and maybe enhancing my comments… 
it would be nice :D

Esteban

> 
>  cheers -ben

Re: [Pharo-dev] uFFI: What is the difference between FFIExternalObject and FFIOpaqueObject?

[Esteban Lorenzano]

> On 22 May 2020, at 04:24, Sean P. DeNigris  wrote:
> 
> Esteban Lorenzano wrote
>> The class comments are not clear?
> 
> Maybe it's me ;-)
> 
> 
> Esteban Lorenzano wrote
>> Opaque object = https://en.wikipedia.org/wiki/Opaque_data_type
>> https://en.wikipedia.org/wiki/Opaque_data_type;
>> External object = a pointer to something. 
> 
> For example, why is ObjCClass a subclass of FFIExternalObject instead of
> FFIOpaqueObject when the docs say that a "Class [is] An opaque type that
> represents an Objective-C class"? Also, is the distinction just conceptual?
> I don't see what either class "buys" you in behavior since they are siblings
> that both pretty much have no methods.

This is because ObjCClass = SomeOpaqueStructurePointer (is already a pointer), 
same as ObjCSelector and ObjCMethod.
Difference is subtle, because is just a different way of representing the same. 

The easiest way I have to explain is: 

You use an OpaqueObject when you will refer to the opaque type in calls as:  
someFunction(opaqueobject *someArg).
You use an ExternalObject when you will refer to the opaque type in calls as: 
someFunction(externalobject someArg).

Esteban

> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html 
> <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html>

Re: [Pharo-dev] uFFI: What is the difference between FFIExternalObject and FFIOpaqueObject?

[Esteban Lorenzano]

Hi, 

The class comments are not clear?

Opaque object = https://en.wikipedia.org/wiki/Opaque_data_type 

External object = a pointer to something. 

> On 21 May 2020, at 21:53, Sean P. DeNigris  > wrote:
> 
> I'm working on improving the documentation. I'd like examples of situations
> when you'd use one or the other and why...
> 
> Also, the FFIOpaqueObject class comment could be fleshed out a bit. Check
> out this excerpt: 
>"this means we always access them through a reference. 
>Now, we could declare the pointer to the structures, but 
>then our declarations wouldn't be as close to C as we want." 
> 
> What would be an example of "declar[ing] the pointer to the structures" and
> the resulting declarations that "wouldn't be as close to C as we want"?


There are plenty of cases in C where you do: 

struct MyStruct *s;

Buy tou cannot do (or you cannot use): 

struct MyStruct s;

This is like that because most modern frameworks use the opaque type as a place 
to keep state, but to interact with them you use functions. e.g: 

MyOpaqueType *ot = newOpaqueType();
opaque_type_someFunction(ot, “a parameter”);


Then an opaque object would be: 

FFIOpaqueObject subclass: #MyOpaqueType.

And you can do an ffi call like this: 

self ffiCall: #(void opaque_type_someFunction(MyOpaqueType *ot, char *aString)).

Note the declaration of "MyOpaqueType *ot”

This is how C declaration looks. 

We can say that an opaque type is a pointer type with arity 0.

Now, an FFIExternalObject (which should be called FFIExternalPointer), has 
already an arity of 1.

Which means, if you declare: 

FFIExternalObject subclass: #MyOpaqueTypePtr.

The same ffiCall you did before would be: 

self ffiCall: #(void opaque_type_someFunction(MyOpaqueTypePtr ot, char 
*aString)).

Note the declaration without the *… this is because FFIExternalObject is 
already a pointer. 

Of course, you can write the function call both ways and it works identically… 
but the first one is closer to what you do in C regularly. 

Esteban

> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html 
> 

[Pharo-dev] [Mm10s] 2020-05-18

[Esteban Lorenzano]

Short list today ;)

### Last week:

   * [NewTools-Playground] polishing details and get it ready to test 
internally (which now is the case :P)
   * Documenting transmissions sub-framework. 
   * Spent a lot of time preparing integration of Spec2 0.6 into P9.

### This week (starting 2020-05-18):

- Finish 0.6 merge.
- Start working with NewTools-Inspector
- verify some errors in UFFI
- Gtk backend: verify some problems with low-level events

Re: [Pharo-dev] Squeak and Pharo speed differences

[Esteban Lorenzano]

Hi, 

Apples and oranges here. 
Yes, both are fruits (perceived speed), but that’s the only point in common :)

Apples and oranges because one thing is the overall performance of the 
environment and another completely different the perceived execution speed of 
the GUI.

Still, some answers:

> On 15 May 2020, at 06:47, Shaping  > wrote:
> 
> Hi all.
>  
>  
> Squeak 5.3:  
>   Time millisecondsToRun: [ 10 factorial  ] 6250
>  
> Pharo 8:
>   Time millisecondsToRun: [ 10 factorial  ] 7736
>  
> Why the difference?

I have no idea. But I have to say that IN MY MACHINE: 

Squeak 5.3, just downloade: 
 Time millisecondsToRun: [ 10 factorial ].  6289

Pharo (9, regular VM): 
 Time millisecondsToRun: [ 10 factorial ]. "3585"

This surprises me more than you, in fact because I was expecting similar times 
(VM is the same, after all).

Basically, all this benchmarks are very unreliable and depend a lot on the 
machine you are running and ultimately, "weather conditions". 

> Squeak 5.3 release notes describe arithmetic improvements.  Nice.  I crunch 
> very big numbers, and these improvements therefore have value.  Why would 
> they not be included in OSVM (forked or not) and the basic class-set for both 
> Squeak and Pharo? 

In general , since VM is the same, if changes are in VM they are already in 
Pharo.

> Playing with Squeak 5.3, I’ve noticed that the GUI is snappier.  Browser 
> ergonomics are better too (for me at least), but that can be fixed/tuned in 
> either environ to suit the developer.  (Still that’s some work I prefer not 
> to do.)  Pharo GUIs are now generally slower, except for the Launcher, which 
> is delightfully quick because it is written in Spec2.  I presume that all 
> Pharo GUIs will eventually (ETA?) be written in Spec2 and that Pharo will 
> then be quick in all its GUIs.  The obvious question is:  Will Squeak be 
> improving GUI look/behavior and speed with Spec2?  If not, can I load Spec2 
> into Squeak so that I can do new GUI work there?

I don’t know about Squeak, this is not the appropriate place to ask Squeak 
questions. 

But yes, Pharo is in a battle to improve its GUI (we are basically rewriting 
all tools with Spec2, but even that some times is not enough since Morphic has 
become bloated, so our fight for performant tools is constant.
Pharo 9 will replace all glamour based tools (Playground, inspector and 
debugger), plus some more old tools, and all will improve there I think 
(GTTools are cool, but Glamour was slow).

> Both Squeak and Pharo have slow text selection.  Pick any word in any pane, 
> and double click it to select it.  When I do this, I sense a 75 to 100 ms 
> latency between the end of the double click and the selection highlight 
> appearing on the word.   I thought I’d entered a wormhole.  So I did the same 
> experiment in VW 8.3.2, VS Code, and Notepad, and all three showed 
> undetectable latencies.   This matters to me.  I’m trying to port from VW to 
> Pharo or Squeak (for a really long time now), and can’t push myself past the 
> text-selection delay problem.  Can text-selection speed be improved to the 
> level of VW’s?   Can someone sketch the algo used and/or point me to the 
> right class/methods.  

I don’t know… I’m sure is possible, but someone has to do it :)
What I can tell you is that text model/operation is a big concern for us... 

> The Squeak debugging experience step-to-step is much quicker.  The latencies 
> in Pharo after button- release are very long.  I estimate 100 to 150 ms.   
> That’s too long for me to work productively.  I lose my mental thread with 
> many of those delays, and have to restart the thought.  It’s a serious 
> problem, caused mostly by acclimation to no detectable latency for many years 
> (Dolphin and VW have quick GUIs).  Is speeding up the Pharo debugger with 
> Spec2 a priority?  I can’t think of a better GUI-related priority for Pharo.

Yes, it is a priority, but it is still a WIP.
Part of this problems has nothing to do with GUI… thing is even if “debugger” 
is same concept, our debugger and the old debugger (which squeak continued) 
have a complete different machinery behind… still, yes we are working. 

>  
> 
> Not speed-related:
>  
> -  How can I load additional fonts into Squeak?  Pharo does this with the 
> font dialog’s Update button.

You’ll have to ask in squeak list, the sis not the appropriate place for that :)

> - Where in the Squeak and Pharo images can I change mouse-selection behavior 
> to be leading-edge?  Some of the Squeak panes have this; others don’t.  I 
> want leading-edge action in all panes, and wish the feature were in 
> Preferences/Settings. 

I do not understand what that is. 
Still, I guess the right answer would be: if it is not there, being (both) open 
source projects that are sustained by communities, and being you part of the 
community, I think it would be a nice contribution for everybody if you 
absolute need this and 

[Pharo-dev] [Mm10s] 2020-05-11

[Esteban Lorenzano]

Last week and this one are still in low-motion, but here we are :)

### Last week:

* [Spec2] uncovered a bug in RubAbstractTextArea: it does not fires 
eventHandler events! (but I
will need to see how deep is this problem tomorrow, maybe it affects all 
events there).
* [Pharo 9] added a PR (https://github.com/pharo-project/pharo/pull/6305) 
to fix a missing event
handling of keyUp/keyDown events when morphic event handling is used.
* [Spec2] add cursorPosition protocol to SpTextPresenters, who will answer 
a column@row
position, instead of cursorPositionIndex who will answer the position in 
the text (an offset)
* [Spec2] add cmd+t to show context menus
* [Spec2-doc] SpStyle
* [NewTools] add a generic StHeaderPanel to contain a StHeaderBar and a 
content presenter. Add
also a global addWindowShortcurTo: to override on the presenters who wants 
to add global
shortcuts to its owner window.
* [NewTools-Playground] add line and cursor position information in the 
status bar.
* [NewTools-Playground] pass on load page dialog (presenter). Is working, 
but not as I want
* [NewTools-Playground] added headers to page selector window.
* [NewTools-Playground] auto-save current page
* [Spec2] added shortcut based context menu popup for morphic (it was 
implemented in Gtk
already)
* [NewTools-Playground] add publish code
* [Pharo 9] bug: spanNewSessionFrom: breakes debugging tests (moved to new 
tools, which is where is actually needed)

### This week (starting 2020-05-11):

- move new playground to beta status (open it for test)
- finish some keybindings issues on Gtk backend
- work on idle vm to fix remaining bugs
- sync with Ronnie to start testing lowcode memory access
- document transmission sub-framework

[Pharo-dev] [Mm10s] 2020-05-04

[Esteban Lorenzano]

### Last week:

(In fact, this is “last week” plus what I did during holidays, but well... ;) )

   * [Spec2] fix a bug while try to assign alignment in a paned layout. 
   * [spec2] code presenter now allow lineNumbers (maybe others to come?)
   * [spec2] syles can not be added/removed dinamically
   * [spec2] fix double print of shortcuts on morphic (not sure is correct, but 
it will work) 
   * Idle-VM: revamp debugger in callback mechanism
   * [spec2] fixed a regression (https://github.com/pharo-spec/Spec/issues/869 
)
   * [NewTools-Playground] playground needs to save last size used
   * [spec2] fix GtkMorphicUIManager. Now it should select correctly the 
manager.
   * [NewTools-Playground] fix bug: menus are showing incorrect shortcut (they 
were duplicated)
   * [spec2] added methods required by syntax highlight to code presenter (it 
was not working
   properly)
   * [spec2] added a new SpPresenterSelectorPresenter (ugly name, but 
descriptive) to allow
   containers that will change its contents depending on a condition.
   * [spec2] bugfix: SpWindowResizing needs to inform old and new sizes in 
SpWindow (morphic).
   * [spec2] calling #asPresenter in #add:constraints to make sure 
dynamic-added presenters are
   actually presenters (since we can add also strings)
   * [NewTools-Playground] add bindings menu and fix bindings access. Add 
"shared" bindings concept.
   * [NewTools-Playground] documentation
   * [spec2] merged work on RichText (pillar) from Norbert
   * [spec2] created specdocs project to generate pillar docs (maybe this needs 
to be part of spec
   itself?)

### This week (starting 2020-05-04):

   * fixes on SpMenuPresenter and keybingdings for Gtk backend
   * new spec2 merge with Pharo 9.
   * work on new tools playground.

Re: [Pharo-dev] [Mm10s] 2020-04-13

[Esteban Lorenzano]

Monday morning, time for the weekly status mail in 10 seconds!

### Last week:

Features implemented: 
* Spec2: Popovers, low level event handler (focus, mouse and keyboard 
events).
* NewTools: playground now uses popover to display print results.

Detail log: 

* [spec2] colors in morphic SpStyle now accept named or hex definitions 
(too illegible to add
them as Color decomposed STON expressions)
* [spec2] propagateNaturalWidth/propagateNaturalHeight now works for 
SpTextPresenter
* [newtools] fix the problem on the shortcut handling (they were ignored)
* [spec2] text presenter. While fixing propagateNaturalHeight: I needed to 
revisit how styles
are applied: basically before I was passing from top to bottom style 
applying it and now I
realise that I cannot because I need to be able to reset the style (case 
.application and .text
with the height of components). So I developped a merge function and I 
apply that. And now I
broke propagateNaturalWidth: :( 
* [spec2] finally, the popovers with text presenters and propagation of 
width/height are working!
* [newTools] printIt command for playground now uses popover
* [spec2] fix a problem where removing a presenter that was resolved from a 
symbol (a possible
case when declaring layouts) was failing.
* [spec2] added lowlevel eventHandler. Now presenters can plug to low level
events: focus/mouse/keyboard.

### This week (starting 2020-04-13):

- Forced Holidays :)

[Pharo-dev] Migrating your projects to GitHub? Do not forget to tag your project!

[Esteban Lorenzano]

Hello, 

Just a gentle reminder to tag your project as “Pharo”, so a search engine can 
find it better!

Esteban

Re: [Pharo-dev] [Spec] Selected item in a list off screen

[Esteban Lorenzano]

Hi,

> On 9 Apr 2020, at 10:17, Hilaire  wrote:
> 
> Thanks Esteban. There is not hurry. I just want to be sure about my own doing.
> 
> I will now write a dedicated workspace to let kids write, save and execute 
> easily DrGeo script.

SpCodePresenter is your friend there :)
(And I’m polishing details on it)

Esteban

> 
> Hilaire
> 
> Le 08/04/2020 à 22:00, Esteban Lorenzano a écrit :
>> There is an ongoing bug about list selections, I hope to work on it tomorrow 
>> if time allows me.
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

Re: [Pharo-dev] [Spec] Selected item in a list off screen

[Esteban Lorenzano]

Hi Hilaire, 

There is an ongoing bug about list selections, I hope to work on it tomorrow if 
time allows me.

Esteban

> On 8 Apr 2020, at 19:54, Hilaire  wrote:
> 
> So this is the normal behavior?
> 
> I am not missing anything ?
> 
> Hilaire
> 
> Le 04/04/2020 à 19:57, Hilaire a écrit :
>> 
>> Hi,
>> 
>> When I programmatically selects an item in a presenter list *and* when this 
>> item is off screen -- for example at the end of a long list -- the list 
>> widget is not scrolled to make it visible.
>> 
>> (DrGScriptBrowser2 new script: DrGeoUserScript allSubclasses last; yourself) 
>> openWithSpec
>> 
>> Is it a bug or am I missing something
>> 
>> Thanks
>> 
>> Hilaire
>> 
>> -- 
>> Dr. Geo
>> http://drgeo.eu
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

[Pharo-dev] [Mm10s] 2020-04-06

[Esteban Lorenzano]

Morning. 
Last week was kind of slow. Lots of (personal) things to take care that took 
more time than expected: kids, basement flood, etc.
Anyway, this is what I managed to achieve: 

### Last week

* [spec2] add "align" property to box layouts (so you can center, or align 
right, etc.).
* [spec2] SpTextPresenter now respond also to “editable” property 
(different than “readonly”.
* [spec2] add popover component (took more time than expected ;) ).
* [spec2] SpCodePresenter now accepts insertPopoverAfterSelection:
* review and accept (most) of all pending PRs from Spec2

### This week (starting 2020-05-06):

(Still stuck in the same)

   * [idlevm] more on the revamp of callbacks
   * [spec2] enhance SpMenuPresenter (to allow checkboxes and etc.)
   * [spec2] more on SpCodePresenter
   * [newtools] more on StPlayground

[Pharo-dev] [Mm10s] 2020-03-30

[Esteban Lorenzano]

### Last week:

* [idlevm] working with Pablo on the revamp of callbacks mechanism. Still 
WIP :(
* [idlevm] refactor into GtkDebugSession  and GtkMorphicUIManager and allow 
them to be chosen
(Just to not crash the image while doing tests).
* [spec2] fix keybindings of text editors (they need to be redirected to 
textArea instead the
rubric morph)
* [spec2] fix printit on SpCodePresenter (still, I need to use a popover on 
it... but one thing
at a time)
* [spec2] spent a ridiculous amount of time refactoring the baseline.
* [spec2] fix an error while emulating keystrokes to tests keybindings.
* [spec2] fix SpToolCommands related to interaxcting with the code.
* [NewTools-Playground] bug: cmd+b in class shows SpCodePresenter
* [spec2] removed autoAccept and acceptoOnCr from text logic (this is a 
remain of 
Morphic era, and it shouldn’t be there in a widget library)
* Spec2: deal with the modal problem on Spec2-Morphic
* [spec2] add "defaultKeyboardFocus" concept to transmit directly to a 
specific child (yes, we
have the focusOrder concept, but this is to easy direct transmission.
* [spec2] enhanced SpCodePresenter source completion in Gtk (now it is not 
showing the popup 
always, just when there is a word to complete)

### This week (starting 2020-03-30):

* [idlevm] more on the revamp of callbacks
* [spec2] enhance SpMenuPresenter (to allow checkboxes and etc.)
* [spec2] more on SpCodePresenter
* [newtools]] more on StPlayground

Re: [Pharo-dev] [Mm10] 2020-03-23 (WAS: No subject)

[Esteban Lorenzano]

> On 23 Mar 2020, at 10:34, teso...@gmail.com wrote:
> 
> Hi,
>  Aleph is the fantasy name of the index manager. Basically, it is a
> set of indexes we are using on the image.
> As Esteban said, everything should work in Pharo 8, but it requires
> harvesting some changes I have made in the Pharo 9 image, so I will
> try to do it this week.
> 
> Today I will try to fix some of the issues while generating the
> indexes the first time. The only issue is that it takes a lot of time,
> I want to reduce it to something usable.

hah… same mail at same time ;)

> 
> Cheers,
> Pablo
> 
> On Mon, Mar 23, 2020 at 10:10 AM Vincent Blondeau via Pharo-dev
> mailto:pharo-dev@lists.pharo.org>> wrote:
>> 
>> Hi Pablo,
>> 
>> Great news! We are eager to test this. Do you plan to backport the changes 
>> for the large images to Pharo8.0? Or should we try a 9.0 to try it?
>> 
>> Also, what is Aleph? (I cannot find a description in this list thread...)
>> 
>> Cheers,
>> Vincent Blondeau
>> Lifeware SA
>> 
>> -Original Message-
>> From: Pharo-dev On Behalf Of teso...@gmail.com
>> Sent: Monday, 23 March 2020 10:02
>> To: Pharo-dev 
>> Subject: Re: [Pharo-dev] (no subject)
>> 
>> Sorry for the subject less message, sending it too fast
>> 
>> On Mon, Mar 23, 2020 at 9:55 AM teso...@gmail.com  wrote:
>>> 
>>> Monday morning, so I spam to tell what I have done last week for Pharo.
>>> 
>>> ### Last week:
>>> 
>>> - Integrating Spotter processors with Aleph
>>> - Testing problem with Pharo8 and Metacello loading.
>>> - Debugging problem with SDL in OSX Pharo8 VM
>>> - Adding classes indexes to AlephIndexManager
>>> - Adding a baseline to load Spotter + Aleph + Completion: this
>>> improves the spotter/completion and senders/implementors/... for large
>>> images. An announcement will arrive when I have better index
>>> generation times.
>>> - Generating a Big image for testing (using
>>> github.com/tesonep/pharo-image generator)
>>> - Commenting and fixing PR
>>> - Deleting closed PR from Jenkins
>>> - A new version of the VM for RHEL (32 / 64 bits)
>>> - Improving the performance of the indexes of Spotter
>>> 
>>> ### This week... idealy (starting 2020-03-23):
>>> 
>>> - Improving Large images index generation time.
>>> - Fixing Package List / Categories in Calypso
>>> - [VM] Fix symbolic links in Pharo8 VM
>>> - Adding a label to a PR when it has no test errors.
>>> - [OSSubprocess] Integrate Pavel + Christophe windows version.
>>> - [VM] Check the crash dumps in an endless loop
>>> - [VM] Improve the usage of Stdout and Stderr, in a correct way
>>> - [Pharo9] Propose a PR for Fuel to support Sista
>>> - [VM] Fixing Tests in Idle.
>>> - [VM] SDL Plugin for Idle.
>>> - [VM] Improving Speed of TFFI.
>>> - [VM] Writing tests for JIT generation
>>> 
>>> --
>>> Pablo Tesone.
>>> teso...@gmail.com
>> 
>> 
>> 
>> --
>> Pablo Tesone.
>> teso...@gmail.com
>> 
>> 
>> 
> 
> 
> -- 
> Pablo Tesone.
> teso...@gmail.com 

Re: [Pharo-dev] [Mm10] 2020-03-23 (WAS: No subject)

[Esteban Lorenzano]

And… for those who do not understand the code names: 

- Aleph is an index system that keeps senders/implementors and references, 
making access to this queries almost automatic even in very big images.
- This also speeds up all refactors, since they query for implementors 
and references all the time.
- Spotter queries have been redesigned to not create the full list before 
showing it, but fetching the values using a generator. It also uses aleph 
(which in time uses a trie three) to fetch the results. Fuzzy matcher is gone 
here, but the gain is bigger than the lost.
- Complishion is a new code completion framework who fetches also using 
generators, and also uses different heuristics to provide more “close” answers 
instead just the list.

Then, there is a not-so-small list of smaller changes, most of them applied 
directly to the image (but for those you need P9).

In sum, we have speed up a lot the usage of Pharo in big images… but of course 
we will be waiting for feedback to go farther where needed :) 

Esteban 

> On 23 Mar 2020, at 10:29, Esteban Lorenzano  wrote:
> 
> 
> 
>> On 23 Mar 2020, at 10:28, Esteban Lorenzano > <mailto:esteba...@gmail.com>> wrote:
>> 
>> Hi,
>> 
>>> On 23 Mar 2020, at 10:14, Vincent Blondeau via Pharo-dev 
>>> mailto:pharo-dev@lists.pharo.org>> wrote:
>>> 
>>> 
>>> From: "Vincent Blondeau" >> <mailto:vincent.blond...@lifeware.ch>>
>>> Subject: RE: [Pharo-dev] [Mm10] 2020-03-23 (WAS: No subject)
>>> Date: 23 March 2020 at 10:14:12 CET
>>> To: "'Pharo Development List'" >> <mailto:pharo-dev@lists.pharo.org>>
>>> 
>>> 
>>> Hi Pablo,
>>> 
>>> Great news! We are eager to test this. Do you plan to backport the changes 
>>> for the large images to Pharo8.0? Or should we try a 9.0 to try it?
>> 
>> While there is no reason that aleph (and complishion) would not work on P8, 
>> for some more subtle changes you will need to jump on P9 (but no worries, P9 
>> it is very stable) :)
> And spotter :P
> 
> 
>> 
>> Esteban
>> 
>> 
>>> 
>>> Also, what is Aleph? (I cannot find a description in this list thread...)
>>> 
>>> Cheers,
>>> Vincent Blondeau
>>> Lifeware SA
>>> 
>>> -Original Message-
>>> From: Pharo-dev On Behalf Of teso...@gmail.com <mailto:teso...@gmail.com>
>>> Sent: Monday, 23 March 2020 10:02
>>> To: Pharo-dev mailto:pharo-dev@lists.pharo.org>>
>>> Subject: Re: [Pharo-dev] (no subject)
>>> 
>>> Sorry for the subject less message, sending it too fast
>>> 
>>> On Mon, Mar 23, 2020 at 9:55 AM teso...@gmail.com 
>>> <mailto:teso...@gmail.com> mailto:teso...@gmail.com>> 
>>> wrote:
>>>> 
>>>> Monday morning, so I spam to tell what I have done last week for Pharo.
>>>> 
>>>> ### Last week:
>>>> 
>>>> - Integrating Spotter processors with Aleph
>>>> - Testing problem with Pharo8 and Metacello loading.
>>>> - Debugging problem with SDL in OSX Pharo8 VM
>>>> - Adding classes indexes to AlephIndexManager
>>>> - Adding a baseline to load Spotter + Aleph + Completion: this 
>>>> improves the spotter/completion and senders/implementors/... for large 
>>>> images. An announcement will arrive when I have better index 
>>>> generation times.
>>>> - Generating a Big image for testing (using 
>>>> github.com/tesonep/pharo-image <http://github.com/tesonep/pharo-image> 
>>>> generator)
>>>> - Commenting and fixing PR
>>>> - Deleting closed PR from Jenkins
>>>> - A new version of the VM for RHEL (32 / 64 bits)
>>>> - Improving the performance of the indexes of Spotter
>>>> 
>>>> ### This week... idealy (starting 2020-03-23):
>>>> 
>>>> - Improving Large images index generation time.
>>>> - Fixing Package List / Categories in Calypso
>>>> - [VM] Fix symbolic links in Pharo8 VM
>>>> - Adding a label to a PR when it has no test errors.
>>>> - [OSSubprocess] Integrate Pavel + Christophe windows version.
>>>> - [VM] Check the crash dumps in an endless loop
>>>> - [VM] Improve the usage of Stdout and Stderr, in a correct way
>>>> - [Pharo9] Propose a PR for Fuel to support Sista
>>>> - [VM] Fixing Tests in Idle.
>>>> - [VM] SDL Plugin for Idle.
>>>> - [VM] Improving Speed of TFFI.
>>>> - [VM] Writing tests for JIT generation
>>>> 
>>>> --
>>>> Pablo Tesone.
>>>> teso...@gmail.com <mailto:teso...@gmail.com>
>>> 
>>> 
>>> 
>>> --
>>> Pablo Tesone.
>>> teso...@gmail.com <mailto:teso...@gmail.com>

Re: [Pharo-dev] [Mm10] 2020-03-23 (WAS: No subject)

[Esteban Lorenzano]

> On 23 Mar 2020, at 10:28, Esteban Lorenzano  wrote:
> 
> Hi,
> 
>> On 23 Mar 2020, at 10:14, Vincent Blondeau via Pharo-dev 
>> mailto:pharo-dev@lists.pharo.org>> wrote:
>> 
>> 
>> From: "Vincent Blondeau" > <mailto:vincent.blond...@lifeware.ch>>
>> Subject: RE: [Pharo-dev] [Mm10] 2020-03-23 (WAS: No subject)
>> Date: 23 March 2020 at 10:14:12 CET
>> To: "'Pharo Development List'" > <mailto:pharo-dev@lists.pharo.org>>
>> 
>> 
>> Hi Pablo,
>> 
>> Great news! We are eager to test this. Do you plan to backport the changes 
>> for the large images to Pharo8.0? Or should we try a 9.0 to try it?
> 
> While there is no reason that aleph (and complishion) would not work on P8, 
> for some more subtle changes you will need to jump on P9 (but no worries, P9 
> it is very stable) :)
And spotter :P


> 
> Esteban
> 
> 
>> 
>> Also, what is Aleph? (I cannot find a description in this list thread...)
>> 
>> Cheers,
>> Vincent Blondeau
>> Lifeware SA
>> 
>> -Original Message-
>> From: Pharo-dev On Behalf Of teso...@gmail.com <mailto:teso...@gmail.com>
>> Sent: Monday, 23 March 2020 10:02
>> To: Pharo-dev mailto:pharo-dev@lists.pharo.org>>
>> Subject: Re: [Pharo-dev] (no subject)
>> 
>> Sorry for the subject less message, sending it too fast
>> 
>> On Mon, Mar 23, 2020 at 9:55 AM teso...@gmail.com <mailto:teso...@gmail.com> 
>> mailto:teso...@gmail.com>> wrote:
>>> 
>>> Monday morning, so I spam to tell what I have done last week for Pharo.
>>> 
>>> ### Last week:
>>> 
>>> - Integrating Spotter processors with Aleph
>>> - Testing problem with Pharo8 and Metacello loading.
>>> - Debugging problem with SDL in OSX Pharo8 VM
>>> - Adding classes indexes to AlephIndexManager
>>> - Adding a baseline to load Spotter + Aleph + Completion: this 
>>> improves the spotter/completion and senders/implementors/... for large 
>>> images. An announcement will arrive when I have better index 
>>> generation times.
>>> - Generating a Big image for testing (using 
>>> github.com/tesonep/pharo-image <http://github.com/tesonep/pharo-image> 
>>> generator)
>>> - Commenting and fixing PR
>>> - Deleting closed PR from Jenkins
>>> - A new version of the VM for RHEL (32 / 64 bits)
>>> - Improving the performance of the indexes of Spotter
>>> 
>>> ### This week... idealy (starting 2020-03-23):
>>> 
>>> - Improving Large images index generation time.
>>> - Fixing Package List / Categories in Calypso
>>> - [VM] Fix symbolic links in Pharo8 VM
>>> - Adding a label to a PR when it has no test errors.
>>> - [OSSubprocess] Integrate Pavel + Christophe windows version.
>>> - [VM] Check the crash dumps in an endless loop
>>> - [VM] Improve the usage of Stdout and Stderr, in a correct way
>>> - [Pharo9] Propose a PR for Fuel to support Sista
>>> - [VM] Fixing Tests in Idle.
>>> - [VM] SDL Plugin for Idle.
>>> - [VM] Improving Speed of TFFI.
>>> - [VM] Writing tests for JIT generation
>>> 
>>> --
>>> Pablo Tesone.
>>> teso...@gmail.com <mailto:teso...@gmail.com>
>> 
>> 
>> 
>> --
>> Pablo Tesone.
>> teso...@gmail.com <mailto:teso...@gmail.com>
>> 
>> 
>> 
>> 
>> 
> 

Re: [Pharo-dev] [Mm10] 2020-03-23 (WAS: No subject)

[Esteban Lorenzano]

Hi,

> On 23 Mar 2020, at 10:14, Vincent Blondeau via Pharo-dev 
>  wrote:
> 
> 
> From: "Vincent Blondeau" 
> Subject: RE: [Pharo-dev] [Mm10] 2020-03-23 (WAS: No subject)
> Date: 23 March 2020 at 10:14:12 CET
> To: "'Pharo Development List'" 
> 
> 
> Hi Pablo,
> 
> Great news! We are eager to test this. Do you plan to backport the changes 
> for the large images to Pharo8.0? Or should we try a 9.0 to try it?

While there is no reason that aleph (and complishion) would not work on P8, for 
some more subtle changes you will need to jump on P9 (but no worries, P9 it is 
very stable) :)

Esteban


> 
> Also, what is Aleph? (I cannot find a description in this list thread...)
> 
> Cheers,
> Vincent Blondeau
> Lifeware SA
> 
> -Original Message-
> From: Pharo-dev On Behalf Of teso...@gmail.com
> Sent: Monday, 23 March 2020 10:02
> To: Pharo-dev 
> Subject: Re: [Pharo-dev] (no subject)
> 
> Sorry for the subject less message, sending it too fast
> 
> On Mon, Mar 23, 2020 at 9:55 AM teso...@gmail.com  wrote:
>> 
>> Monday morning, so I spam to tell what I have done last week for Pharo.
>> 
>> ### Last week:
>> 
>> - Integrating Spotter processors with Aleph
>> - Testing problem with Pharo8 and Metacello loading.
>> - Debugging problem with SDL in OSX Pharo8 VM
>> - Adding classes indexes to AlephIndexManager
>> - Adding a baseline to load Spotter + Aleph + Completion: this 
>> improves the spotter/completion and senders/implementors/... for large 
>> images. An announcement will arrive when I have better index 
>> generation times.
>> - Generating a Big image for testing (using 
>> github.com/tesonep/pharo-image generator)
>> - Commenting and fixing PR
>> - Deleting closed PR from Jenkins
>> - A new version of the VM for RHEL (32 / 64 bits)
>> - Improving the performance of the indexes of Spotter
>> 
>> ### This week... idealy (starting 2020-03-23):
>> 
>> - Improving Large images index generation time.
>> - Fixing Package List / Categories in Calypso
>> - [VM] Fix symbolic links in Pharo8 VM
>> - Adding a label to a PR when it has no test errors.
>> - [OSSubprocess] Integrate Pavel + Christophe windows version.
>> - [VM] Check the crash dumps in an endless loop
>> - [VM] Improve the usage of Stdout and Stderr, in a correct way
>> - [Pharo9] Propose a PR for Fuel to support Sista
>> - [VM] Fixing Tests in Idle.
>> - [VM] SDL Plugin for Idle.
>> - [VM] Improving Speed of TFFI.
>> - [VM] Writing tests for JIT generation
>> 
>> --
>> Pablo Tesone.
>> teso...@gmail.com
> 
> 
> 
> --
> Pablo Tesone.
> teso...@gmail.com
> 
> 
> 
> 
> 

[Pharo-dev] [Mm10s] 2020-03-23

[Esteban Lorenzano]

Last week was not very productive because of reasons of public knowledge. 
Also, because having the kids in home mades very difficult to keep work 
continuity.

### Last week:

* [spec2] add toolbar menubutton item (to allow menu-like dropdown).
* [spec2] toolbar buttons can now update icons and labels (they can be 
modified on runtime)
* [Spec2] align morphic and gtk side on different changes happened last 
months.
* [spec2] fix errors in SpCodePresenter while applying syntax highlight. 
* [spec2] SpCodePresenter now uses new “Complishion” framework to provide 
code completion.
* [spec2] SpCodePresenter fixes to allow variable bindings (in case of 
playgrounds, etc.)
* [spec2] Some work with keybindings (unfinished), with the idea to allow 
KeyboardKey to provide also 
an entry point to key combinations (so we can do Fkeys, for example).
* [calypso] fix a problem when user selects two methods by cmd+click on them

### This week (starting 2020-03-23):

* more on spec2 morphic->gtk3 alignment 
* more on keybindings
* revamp callback exception mechanism to not crash the vm in certain cases 
(when working with GTK3 backend).
* work with Pablo on the Idle VM

[Pharo-dev] [Mm10s] 2020-03-16

[Esteban Lorenzano]

### Last week:

* Spec2: remove usages of SpLayout
* [spec2] Make SpCodePresenter work with the new completion engine (from 
Guille's complishion).
This will require to install it (until it is integrated in Pharo 9)
* [spec2] enhance the mapping of Gtk3 key codes to internal pharo key 
codes. Anyway, we need a
different way to declare keybindings using real codes (so we can map Fkeys 
for example).
* [spec2] in gtk3, fix an annoying "non-bug" on syntax highlighting: it was 
spreading warnings of
"variable undeclared" while parsing the entered text, filling the 
transcript with undesired
output.
* [Spec2] extract deprecations into a loadable package
* [spec2] remove deprecated usages on EyeInspector and in addition make it 
work again (but it
still need some love)
* [Spec2] fix a bug where the traverse of presenters was not working 
because new layout
mechanism accepts any kind of presenter to be there, not just a symbol.
* [spec2] finished integration of v0.3
* [big-images] modified fast table to work also with a "generator" 
approach. This change introduces 
this dimension without affecting the regular behavior.(this is useful to 
display things that need time 
to be calculated). 
* [ejdb] enhance a bit persistence queries adding regex support.

### This week (starting 2020-03-16):

* Work mostly on Spec2 side (mostly aligning changes from morphic to gtk3 
backend,
but I will also take some issues around. 
* Put on a “big-images” baseline to load and use when you have images that 
takes > 1G (or 
you want/speed up because of any reason).

Re: [Pharo-dev] Iceberg confusion

[Esteban Lorenzano]

Hi,

> On 14 Mar 2020, at 04:35, Ben Coman  wrote:
> 
> So I discovered a bug with Pharo Launcher and logged... 
> https://github.com/pharo-project/pharo-launcher/issues/431 
>   
> and then wanted to contributing a fix, 
> but hit some confusion with Iceberg that discouraged me continuing.
> 
> The first thing I'm compelled to do to build my sense of control/mastery of 
> the situation
> is sync the local github repo to the in-Image code, and I continually 
> struggle with doing this quickly and fluently.

well… no :)
It doesn’t matters in which commit you are, you can just create a branch from 
there and commit your changes there.

> 
> 
> In a fresh install of Pharo Launcher (pharo-launcher-1.9.2.zip),
> after opening Iceberg and on the pharo-launcher repo 
> doing Repair > Clone again this repository > Clone from github.com 
> 
>   + Owner Name: pharo-project
>   + Project Name: pharo-launcher
> 
> I find it is "not-yet" repaired.  There is more-to-do [1] to repair a "Detach 
> Working Copy"
> 
> 
> A newcomer confronted with that may just stop there
> but I'm familiar with Iceberg so IIUC to clear a "Detached Working Copy" I 
> need to do checkout a commit. 

No you don’t :)
Detached working copy does not means you need to checkout a commit. 
It means you are working in a commit which is not your head. 
You have several strategies (repairs) you can follow here : 
- you can indeed checkout the head.
- you can create a branch from your commit.
- you can discard what you have in image and load what is the working copy head.

> So I try... Right-click pharo-launcher > Repository...
> 
> 
> But that doesn't help me since there is no clue which commit the in-Image 
> code came from**, so I don't know which to check out. 

You do not want to checkout a commit, see previous comment.

> I presume the middle tab at the bottom is showing the diff between "a49ef1d 
> to HEAD"  on disk and not the in-Image source.  
> 
> If I take a guess to check out the latest then that shows a lot of 
> difference, so that is discouraging.  I really don't want to have to try 
> checking out each commit in turn searching for the matching one.
> 
> Now luckily half an hour later while writing this post I notice there is a 
> "1.9.2" tag.  Checking this out gave now differences so yay! I managed to 
> work around my problem.  But still, I lost that half-hour (and similar many 
> times before) so my Big Question still remains... 
> 
>Why must information about where there code comes always from be deleted 
> from release-images???
> 
> Above I had prior knowledge to to fill in the "Repair" fields with
>   + Owner Name: pharo-project
>   + Project Name: pharo-launcher
> 
> but other times having to research-and-guess what these fields should be
> to match in-Image code is a real barrier to contributing.
>  
> It would be really-really great if rather than an image being delivered like 
> this...
>  
> 
> it would look like this...
> 
> with all the other Unknowns also filled in, 
> but discovering that info would take another half hour (also a case in point) 
> 
> This would make it simple to fill in the Repair dialog fields,
> and remove my main workflow irritation in an otherwise fantastic tool.
> 
> cheers -ben

Esteban

[Pharo-dev] [Mm10s] 2020-03-09

[Esteban Lorenzano]

### Last week

* [voyage] caches may be a cache by class. introduce #cacheFor: method and 
use it.
* [voyage] Release pharo bindings for EJDB and Voyage-EJDB backend.
* [Support for big images] "literal methods" speed up in calypso
* [Support for big images] release Aleph index system to speed up big 
images senders/implementors and all 
Refactors associated
* [Spec2] worked with Christophe to fix the sort and selection problem in 
tables and lists.
* [Spec2] enhance documentation (SpButtonPresenter)
* [Spec2] remove deprecations from baseline

### This week (starting 2020-03-09)

* [Spec2] merge 0.3 with Pharo 9.,
* [Support for big images] Test (and maybe distribute) the “big images 
package”

Re: [Pharo-dev] Updated Fuel version for Pharo 8

[Esteban Lorenzano]

Ah, yes. Please do a PR :)

> On 8 Mar 2020, at 19:28, Esteban Lorenzano  wrote:
> 
> Hi Max, 
> 
> We will schedule a minor release with this and some other changes next 
> week(s) :)
> 
> Esteban
> 
> 
>> On 8 Mar 2020, at 16:35, Max Leske  wrote:
>> 
>> Hi folks,
>> 
>> I just released Fuel 3.0.2 and I'd like to update the current version in 
>> Pharo 8 to the new one. I know I'm past the Pharo 8 release date, so I guess 
>> it won't happen but I thought I'd ask anyway.
>> 
>> There are no functional changes in 3.0.2 but I've updated the platform (it's 
>> currently still FLPharo7Platform in Pharo 8) and removed some unused stuff. 
>> So should I open a PR?
>> 
>> 
>> In any case I'll open a PR for Pharo 9.
>> 
>> Cheers,
>> Max
> 

Re: [Pharo-dev] Updated Fuel version for Pharo 8

[Esteban Lorenzano]

Hi Max, 

We will schedule a minor release with this and some other changes next week(s) 
:)

Esteban


> On 8 Mar 2020, at 16:35, Max Leske  wrote:
> 
> Hi folks,
> 
> I just released Fuel 3.0.2 and I'd like to update the current version in 
> Pharo 8 to the new one. I know I'm past the Pharo 8 release date, so I guess 
> it won't happen but I thought I'd ask anyway.
> 
> There are no functional changes in 3.0.2 but I've updated the platform (it's 
> currently still FLPharo7Platform in Pharo 8) and removed some unused stuff. 
> So should I open a PR?
> 
> 
> In any case I'll open a PR for Pharo 9.
> 
> Cheers,
> Max

[Pharo-dev] [Mm10s] 2020-02-24

[Esteban Lorenzano]

### Last week:

* [spec2] fixed the last remaining issue with full-replace layouts.
* [spec2] fixed the visibility of windows on gtk: the backend was drawing 
windows before receive
the open message (because of the visibility settings)
* [spec2] made a mock up of “generator based list presenter” : a way to not 
need to feed all items to 
a list before displaying them (this should sped up big lists, and rescue 
the fast table main purpose). 
* spent part of the day looking for improvements on the callback speed. 
Figured out looking for
a callback by address is time consuming because it makes an #isKindOf: very 
frequently. I made a
PR to make the comparisson faster.
* [big-images] made calypso modification about TabManager go into Pharo8 
(maybe issues remaining?
We will see, hopefully not).
* [big-images] start analysis on speeding up 
senders/implementors/references (this should also help for
refactors later)

### This week: 

* [big-images] finish senders/implements/references speed up

[Pharo-dev] [Mm10s] 2020-02-17

[Esteban Lorenzano]

### Last week:

* [vm idle] Fix a bug when pipe signal happens and there is no handler to 
set it.
* [spec2] migrating transmission to explicit ports (with selector name 
instead a list of them)
* [newtools] migrate tools to new transmission mechanism.
* [big-images] digging on calypso slowness when dealing with big images. So 
far, biggest problem
is the full update that happens each time something change: it hangs from 
SystemAnnouncement to
fire a *full* update, even if later it does not applies any change. And 
this updates are
complicated. For now `ClyUnimplementedMethodsQuery` is prohibitive in a 
context of deep
hierarchies and tons of methods.
* [spec2] dynamic layouts working for Morphic and GTK

### This week: 

* [big-images]  make Calypso features that are time consuming able to be 
disabled.
* [big-images]  recognise “literal methods” and skip time consuming useless 
actions.

[Pharo-dev] [Mm10s] 2020-02-10

[Esteban Lorenzano]

### Last week:

* [objcbridge] finish migration of ObjCBridge to TFFI. Now everything works 
as expected, proxies
inclusive (chich was absent before)
* [spec2] fix a problem in the build of toolbars from commands (this one 
was new... it was
working before).
* [spec2] I spent some time figuring out what we need to fix the "sorted 
table+selection item"
problem. Basically, selectedItem needs to be retrieved from sorted 
collection, not from original
model. But this is problem because sorted collection lives in adapter part 
(or even worst on
gtk).
* Spec2: implement SpToolBarToggleButton
* Spec2-doc: SpLabelPresenter
* Spec2: bug: error mapping of $^ in gtk backend.
* building a small tool to help me find image leaks. For now, is just a 
simpler way to visualise
amount of instances (no graphics, just numbers). I may add other stuff 
later. It can be found at 
https://github.com/estebanlm/WAMO (WAMO=Where Are My Objects)
* [newtools] I added some settings to change the default toolbar display 
mode. I like small
icons, Stef likes big ones... like this we are all happy :)
* [big images] testing different heuristics to make a big image (and 
killing my machine in the
process)

### This week

* More on work on speed up of big images (finish migration to notebook 
morph, start looking improvements on senders/implementors)
* Work on idle vm
* Spec2: work on dynamic layouts

Re: [Pharo-dev] [rmod] PR without Tests

[Esteban Lorenzano]

+1000

> On 6 Feb 2020, at 10:29, teso...@gmail.com wrote:
> 
> 
> -- 

[Pharo-dev] [Mm10s] 2020-02-3

[Esteban Lorenzano]

### Last week

* add FFILibraryFinder helper to find libraries in the standard directories 
for each
platform. They are still incomplete (since linux in particular has a lot), 
but is a begining.
* [big images] Calypso replacement of TabManagerMorph with SpNotebookMorph 
(allowing lazy loading instead spawning a fork)
* Pharo 9: merge Spec2 0.2.1
* [spec2] fix several issues in SpNotebookMorph related to theming but not 
exclusive
* [spec2] remove some bad usages of do: #symbol
* [spec2] solve a problem with $^ character in dead keyboards (I will need 
to map all dead
code).

### This week

* [big images] Fix duplication implementations of SystemNavigation things 
(implementors, senders, etc)
* Work on idle vm

Re: [Pharo-dev] [Mm10s] 2020-01-27

[Esteban Lorenzano]

Oops, I forget the attach :)

spec2-status.pdf
Description: Adobe PDF document
On 27 Jan 2020, at 10:01, Esteban Lorenzano <esteba...@gmail.com> wrote:### Last week    * Release Pharo 8.0    * [UFFI] See a problem in TFFI + Gtk3 backend caused by a change made to allow String econdings.    * [objcbridge] I made the bridge compatible with the latest version of TFFI    * [spec2] prepare a status document (I will attach it to this mail)    * [spec2] table/list/trees: default sort in string columns work.    * [Spec2-doc] add good comments to SpApplication    * [big images] review usages of SystemNavigation (and similars) in the image, looking to centralise its behaviour (so we can plan strategies).    * [big images] I got a functional calypso that uses notebook instead tabmanager. Still a lot of bugs to fix to make it functional (but it looks promising).    * [Morphic] I fixed some errors on SpNotebookMorph: is was not informing correctly the last page when a page changed event happened.    * Some branch clean up on pharo site### This week    * Work on speed up of big images (finish migration to notebook morph, start looking improvements on senders/implementors)    * Work on idle vm

[Pharo-dev] [Mm10s] 2020-01-27

[Esteban Lorenzano]

### Last week

* Release Pharo 8.0
* [UFFI] See a problem in TFFI + Gtk3 backend caused by a change made to 
allow String econdings.
* [objcbridge] I made the bridge compatible with the latest version of TFFI
* [spec2] prepare a status document (I will attach it to this mail)
* [spec2] table/list/trees: default sort in string columns work.
* [Spec2-doc] add good comments to SpApplication
* [big images] review usages of SystemNavigation (and similars) in the 
image, looking to centralise its behaviour (so we can plan strategies).
* [big images] I got a functional calypso that uses notebook instead 
tabmanager. Still a lot of bugs to fix to make it functional (but it looks 
promising).
* [Morphic] I fixed some errors on SpNotebookMorph: is was not informing 
correctly the last page when a page changed event happened.
* Some branch clean up on pharo site

### This week

* Work on speed up of big images (finish migration to notebook morph, start 
looking improvements on senders/implementors)
* Work on idle vm

Re: [Pharo-dev] URGENT: Pharo 8 Needs Stable Version Update

[Esteban Lorenzano]

Mmm. There is an error in the CI and it did not uploaded the stable*.zip 
archives (while it did the latest).
I uploaded them by hand but we need to review the process (problem is now I 
cannot test it in my machine anymore, I need to prepare an environment)

> On 25 Jan 2020, at 07:30, Esteban Lorenzano  wrote:
> 
> Which url?
> I don’t know well how pharo launcher works, but zeroconf is downloading the 
> correct version.
> 
> but there is a bug somewhere and the naming/versioning still shows 8.0.0 
> while it should show 8.0.1.
> 
> Esteban
> 
>> On 24 Jan 2020, at 22:31, Sean P. DeNigris  wrote:
>> 
>> EstebanLM wrote
>>> Done 
>> 
>> I see the new 8.0.1 release tag, but the URL still downloads 8.0.0
>> (bbcdf97). Is there another step?
>> 
>> 
>> 
>> -
>> Cheers,
>> Sean
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>> 
> 

Re: [Pharo-dev] URGENT: Pharo 8 Needs Stable Version Update

[Esteban Lorenzano]

Which url?
I don’t know well how pharo launcher works, but zeroconf is downloading the 
correct version.

but there is a bug somewhere and the naming/versioning still shows 8.0.0 while 
it should show 8.0.1.

Esteban

> On 24 Jan 2020, at 22:31, Sean P. DeNigris  wrote:
> 
> EstebanLM wrote
>> Done 
> 
> I see the new 8.0.1 release tag, but the URL still downloads 8.0.0
> (bbcdf97). Is there another step?
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 

Re: [Pharo-dev] URGENT: Pharo 8 Needs Stable Version Update

[Esteban Lorenzano]

Done 


> On 24 Jan 2020, at 17:57, Sean P. DeNigris  wrote:
> 
> How do we update https://files.pharo.org/image/80/stable-64.zip?
> 
> The "emergency evaluator on warning" issue [1] is fixed, but Launcher is
> still serving a pre-fix image under "Official distributions". This seems
> like a critical issue as new users may be immediately put off. FYI as a
> workaround select the latest snapshot from the "Pharo 8.0" build templates
> further down in the tree.
> 
> 1. https://github.com/pharo-project/pharo/issues/5545
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 

Re: [Pharo-dev] [ANN] Pharo 8.0 Released!

[Esteban Lorenzano]

> On 20 Jan 2020, at 14:44, Esteban Maringolo  wrote:
> 
> Great news!
> 
> Just a correction, the link to the changelog is wrong, the correct one is 
> this:
> https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo80ChangeLogs.md
>  
> <https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo80ChangeLogs.md>
>  
Damn it! :P

> (impressive, btw)
>  
> Esteban A. Maringolo
> 
> 
> On Mon, Jan 20, 2020 at 10:24 AM Esteban Lorenzano  <mailto:esteba...@gmail.com>> wrote:
> Dear World and dynamic language lovers: 
> The time has come for Pharo 8.0 <https://pharo.org/>!
> Pharo is a pure object-oriented programming language and a powerful 
> environment, focused on simplicity and immediate feedback.
> 
> Here are the key highlights of this release:
> 
> The 64-bit version has become the recommended version for Windows as it was 
> for Unix and OSX.
> Iceberg, the git client for Pharo, reached its version 1.6.5 with several 
> improvements and bugfixes.
> Calypso, Pharo’s system browser has new and better refactoring integrations 
> and AST-based suggestions for class definitions.
> The unified foreign function interface (UnifiedFFI) has been improved with 
> more support for literal objects, better type coercions, and more 
> documentation.
> Several speed improvements in code searches and compilation.
> 
> In addition, this version includes several previews of new tools such as the 
> Spec2 GUI framework with native widget integration and the new DrTests test 
> analysis tool and opens the door for the upcoming headless VMs for servers 
> and non-blocking FFI.
> These are just the more prominent highlights, but the details are just as 
> important. We have closed a massive amount of issues: 2805 issues! 
> A comprehensive changelog can be found at 
> https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo80ChangeLogs.md
>  
> <https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo60ChangeLogs.md>).
> While the technical improvements are significant, still the most impressive 
> fact is that the new code that got in the main Pharo 8.0 image was 
> contributed by more than 100 people.
> Pharo is more than code. It is an exciting project involving energetic 
> people. We thank all the contributors to this release:
> Serge Stinckwich, Myroslava Romaniuk, Hilaire Fernandes, Alexandre Bergel, 
> David Bajger, Sean DeNigris, Theodore Moen, Dayne Guerra Calle, Juraj 
> Kubelka, Max Leske, Santiago Jose Dandois, Alistair Grant, Sabine Mana, Chia 
> Yu, Stephan Eggermont, Milton Mamani, Pavel Krivanek, Ben Coman, Marcus 
> Denker, Pierre Misse, Christophe Demarey, Allex Oliveira, Andreina Cota, Theo 
> Rogliano, Clément Dutriez, Quentin Ducasse, Cyril Ferlicot, Cameron 
> Bierwagen, Marek Niepieklo, Clotilde Toullec, Esteban Lorenzano, Vincent 
> Blondeau, Danil Osipchuk, Eiichiro Ito, Noury Bouraqadi, Oleksandr Zaytsev, 
> Jason Riggs, Alain Plantec, Kasper Osterbye, Leonardo Cecchi, Chi Huynh, 
> Santiago Bragagnolo, Antonio Pierro, Pablo Tesone, Tim Mackinnon, Wesley 
> Duerksen, Wilfred Hughes, John Brant, Evelyn Cusi Lopez, Manuel Leuenberger, 
> Thomas Dupriez, Norbert Hartl, Torsten Bergmann, Gabriel Omar Cotelli, Carlo 
> Teixeira, Guille Polito, Torsten Bergman, Damien Pollet, Holger Hans Peter 
> Freyther, Julio Ripoll, Carolina Hernandez Phillips, Julien Delplanque, Hugo 
> Lasnier, James Foster, Will Hensel, Erik Stel, Sven Van Caekenberghe, Martín 
> Dias, Tomohiro Oda, Konrad Hinsen, Sébastien Roccaserra, Stéphane Ducasse, 
> Denis Kudriashov, Ellis Harris, Steven Costiou
> (If you contributed with Pharo 8.0 development in any way and we missed your 
> name, please send us a mail and we will add you).
> Enjoy!
> The Pharo Team
> Try Pharo: http://pharo.org/download <https://pharo.org/download>
> Learn Pharo: http://pharo.org/documentation <https://pharo.org/documentation>
> 
> If you cannot see this, follow this link: 
> http://pharo.org/news/pharo8.0-released 
> <http://pharo.org/news/pharo8.0-released>

Re: [Pharo-dev] [ANN] Pharo 8.0 Released!

[Esteban Lorenzano]

Links to upvote: 

https://www.reddit.com/r/programming/comments/erd65s/pharo_80_the_immersive_pure_object_oriented/
https://news.ycombinator.com/item?id=22098604

:)


> On 20 Jan 2020, at 14:23, Esteban Lorenzano  wrote:
> 
> Dear World and dynamic language lovers: 
> The time has come for Pharo 8.0 <https://pharo.org/>!
> Pharo is a pure object-oriented programming language and a powerful 
> environment, focused on simplicity and immediate feedback.
> 
> Here are the key highlights of this release:
> 
> The 64-bit version has become the recommended version for Windows as it was 
> for Unix and OSX.
> Iceberg, the git client for Pharo, reached its version 1.6.5 with several 
> improvements and bugfixes.
> Calypso, Pharo’s system browser has new and better refactoring integrations 
> and AST-based suggestions for class definitions.
> The unified foreign function interface (UnifiedFFI) has been improved with 
> more support for literal objects, better type coercions, and more 
> documentation.
> Several speed improvements in code searches and compilation.
> 
> In addition, this version includes several previews of new tools such as the 
> Spec2 GUI framework with native widget integration and the new DrTests test 
> analysis tool and opens the door for the upcoming headless VMs for servers 
> and non-blocking FFI.
> These are just the more prominent highlights, but the details are just as 
> important. We have closed a massive amount of issues: 2805 issues! 
> A comprehensive changelog can be found at 
> https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo80ChangeLogs.md
>  
> <https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo60ChangeLogs.md>).
> While the technical improvements are significant, still the most impressive 
> fact is that the new code that got in the main Pharo 8.0 image was 
> contributed by more than 100 people.
> Pharo is more than code. It is an exciting project involving energetic 
> people. We thank all the contributors to this release:
> Serge Stinckwich, Myroslava Romaniuk, Hilaire Fernandes, Alexandre Bergel, 
> David Bajger, Sean DeNigris, Theodore Moen, Dayne Guerra Calle, Juraj 
> Kubelka, Max Leske, Santiago Jose Dandois, Alistair Grant, Sabine Mana, Chia 
> Yu, Stephan Eggermont, Milton Mamani, Pavel Krivanek, Ben Coman, Marcus 
> Denker, Pierre Misse, Christophe Demarey, Allex Oliveira, Andreina Cota, Theo 
> Rogliano, Clément Dutriez, Quentin Ducasse, Cyril Ferlicot, Cameron 
> Bierwagen, Marek Niepieklo, Clotilde Toullec, Esteban Lorenzano, Vincent 
> Blondeau, Danil Osipchuk, Eiichiro Ito, Noury Bouraqadi, Oleksandr Zaytsev, 
> Jason Riggs, Alain Plantec, Kasper Osterbye, Leonardo Cecchi, Chi Huynh, 
> Santiago Bragagnolo, Antonio Pierro, Pablo Tesone, Tim Mackinnon, Wesley 
> Duerksen, Wilfred Hughes, John Brant, Evelyn Cusi Lopez, Manuel Leuenberger, 
> Thomas Dupriez, Norbert Hartl, Torsten Bergmann, Gabriel Omar Cotelli, Carlo 
> Teixeira, Guille Polito, Torsten Bergman, Damien Pollet, Holger Hans Peter 
> Freyther, Julio Ripoll, Carolina Hernandez Phillips, Julien Delplanque, Hugo 
> Lasnier, James Foster, Will Hensel, Erik Stel, Sven Van Caekenberghe, Martín 
> Dias, Tomohiro Oda, Konrad Hinsen, Sébastien Roccaserra, Stéphane Ducasse, 
> Denis Kudriashov, Ellis Harris, Steven Costiou
> (If you contributed with Pharo 8.0 development in any way and we missed your 
> name, please send us a mail and we will add you).
> Enjoy!
> The Pharo Team
> Try Pharo: http://pharo.org/download <https://pharo.org/download>
> Learn Pharo: http://pharo.org/documentation <https://pharo.org/documentation>
> 
> If you cannot see this, follow this link: 
> http://pharo.org/news/pharo8.0-released 
> <http://pharo.org/news/pharo8.0-released>

[Pharo-dev] [ANN] Pharo 8.0 Released!

[Esteban Lorenzano]

Dear World and dynamic language lovers: 
The time has come for Pharo 8.0 <https://pharo.org/>!
Pharo is a pure object-oriented programming language and a powerful 
environment, focused on simplicity and immediate feedback.

Here are the key highlights of this release:

The 64-bit version has become the recommended version for Windows as it was for 
Unix and OSX.
Iceberg, the git client for Pharo, reached its version 1.6.5 with several 
improvements and bugfixes.
Calypso, Pharo’s system browser has new and better refactoring integrations and 
AST-based suggestions for class definitions.
The unified foreign function interface (UnifiedFFI) has been improved with more 
support for literal objects, better type coercions, and more documentation.
Several speed improvements in code searches and compilation.

In addition, this version includes several previews of new tools such as the 
Spec2 GUI framework with native widget integration and the new DrTests test 
analysis tool and opens the door for the upcoming headless VMs for servers and 
non-blocking FFI.
These are just the more prominent highlights, but the details are just as 
important. We have closed a massive amount of issues: 2805 issues! 
A comprehensive changelog can be found at 
https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo80ChangeLogs.md
 
<https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo60ChangeLogs.md>).
While the technical improvements are significant, still the most impressive 
fact is that the new code that got in the main Pharo 8.0 image was contributed 
by more than 100 people.
Pharo is more than code. It is an exciting project involving energetic people. 
We thank all the contributors to this release:
Serge Stinckwich, Myroslava Romaniuk, Hilaire Fernandes, Alexandre Bergel, 
David Bajger, Sean DeNigris, Theodore Moen, Dayne Guerra Calle, Juraj Kubelka, 
Max Leske, Santiago Jose Dandois, Alistair Grant, Sabine Mana, Chia Yu, Stephan 
Eggermont, Milton Mamani, Pavel Krivanek, Ben Coman, Marcus Denker, Pierre 
Misse, Christophe Demarey, Allex Oliveira, Andreina Cota, Theo Rogliano, 
Clément Dutriez, Quentin Ducasse, Cyril Ferlicot, Cameron Bierwagen, Marek 
Niepieklo, Clotilde Toullec, Esteban Lorenzano, Vincent Blondeau, Danil 
Osipchuk, Eiichiro Ito, Noury Bouraqadi, Oleksandr Zaytsev, Jason Riggs, Alain 
Plantec, Kasper Osterbye, Leonardo Cecchi, Chi Huynh, Santiago Bragagnolo, 
Antonio Pierro, Pablo Tesone, Tim Mackinnon, Wesley Duerksen, Wilfred Hughes, 
John Brant, Evelyn Cusi Lopez, Manuel Leuenberger, Thomas Dupriez, Norbert 
Hartl, Torsten Bergmann, Gabriel Omar Cotelli, Carlo Teixeira, Guille Polito, 
Torsten Bergman, Damien Pollet, Holger Hans Peter Freyther, Julio Ripoll, 
Carolina Hernandez Phillips, Julien Delplanque, Hugo Lasnier, James Foster, 
Will Hensel, Erik Stel, Sven Van Caekenberghe, Martín Dias, Tomohiro Oda, 
Konrad Hinsen, Sébastien Roccaserra, Stéphane Ducasse, Denis Kudriashov, Ellis 
Harris, Steven Costiou
(If you contributed with Pharo 8.0 development in any way and we missed your 
name, please send us a mail and we will add you).
Enjoy!
The Pharo Team
Try Pharo: http://pharo.org/download <https://pharo.org/download>
Learn Pharo: http://pharo.org/documentation <https://pharo.org/documentation>

If you cannot see this, follow this link: 
http://pharo.org/news/pharo8.0-released

[Pharo-dev] Starting release, some files will be not sync some minutes

[Esteban Lorenzano]

Hi, 

I’m starting to do the release. 
Some files will be out-of-sync during the process.

Esteban

[Pharo-dev] [Mm10s] 2020-01-20

[Esteban Lorenzano]

### Last week:

- [Spec2] fix a problem with SpDemoActionBarPresenter: we shouldn't use inform 
from morphic in a gtk application.
- [Spec2] make work the cmd+s and escape in dialogs
- [Spec2] add a fadeout timer to GtkInfoBar to auto hide the bars. This is to 
simulate how growl works now (WIP).
- [Spec2] fixed toggle checkbox on tables on gtk (it was not implemented)
- [Voyage] unqlite: fixed a test that was crashing (a callback was passing 0 
instead NULL)
- [Release] modify website
- [Release] prepare zeroconf
- [Release] work on fixing the load of packages problem (the fix was actually 
done by Pablo)
- [Release] merge new PR to integrate Spec2 0.2.0

### This week

- [Release] <— This.
- [VM] Check a problem with large installations on AIO/Threaded VM.
- Prepare work to make Pharo usable on big images

### Pipeline

- [VM] debug AIO and worker thread VMs on linux and windows.
- Speed up calypso?

[Pharo-dev] [Mm10s] 2010-01-13

[Esteban Lorenzano]

### Last week:

- [release] Start Pharo9.0 branch
- [release] Fix some issues for Pharo8.0
- [release] Spent a lot of time trying to verify a problem on zerocont (and 
smalltalkCI) that turned out to be corrected already (but nobody knew it) ;)
- [voyage] Fix a cyclic problem on voyage-unqlite.
- [Spec2] Fix “center” and “centerRelativeTo:” properties for Dialogs.

### This week (starting 2019-12-16):

- [Release] Organise issues that will enter in P8.
- [Release] Prepare release notes
- [VM] Check a problem with large installations on AIO/Threaded VM.

### Pipeline

- [Release] Pharo 8 Release.
- [VM] debug AIO and worker thread VMs on linux and windows.

Re: [Pharo-dev] Pharo key features (document)

[Esteban Lorenzano]

> On 5 Jan 2020, at 11:59, serge.stinckw...@gmail.com wrote:
> 
> Impressive list !!!
> 
> Would be nice to have an html version at the end with high-resolution screen 
> shots and put it on the pharo.org website with nice transition animations 
> like the one you found on Apple website for example.

+1

> 
> Sent from my iPhone
> 
>> On 5 Jan 2020, at 11:02, Pavel Krivanek  wrote:
>> 
>> 
>> Hi, I have created a list of the key Pharo features with some images and 
>> animations that should help to explain to public what is cool on Pharo. It 
>> is based on a list formerly created for a Wikipedia article.
>> 
>> https://github.com/pavel-krivanek/pharoMaterials/blob/master/features/PharoKeyFeatures.md
>>  
>> 
>> 
>> Please look at it to check if something is worth to add or change before we 
>> will try to use it somewhere for real.
>> 
>> Cheers,
>> -- Pavel

[Pharo-dev] Happy new year!

[Esteban Lorenzano]

Hi, 

Just that, happy new year to everybody! :)
For 2020, let’s make a great Pharo 8 release and an even better Pharo 9.

Cheers!
Esteban

[Pharo-dev] [ANN] TechTalk TODAY “Working with Spec2 and GTK" BUT TIME CHANGE TO 16h France

[Esteban Lorenzano]

Hi, 

I will give a techtalk today around the work with Spec2 and GTK. 
But because of personal reasons, I cannot give the talk 17-18h EU, instead, it 
will be one our earlier.

So, this is the appointment: 

Pharo TechTalk
19 Dec 2019
 
4:00 PM - 5:00 PM (UTC+01:00)

A regular chat about Pharo. Happens on Discord.

The Tech talks are open to both members and non-members! 

Topic:  “Working with Spec2 and GTK”

Here is the event link: 

https://association.pharo.org/event-3419547

And here is the place where the transmission will be made: 

https://www.youtube.com/c/EstebanLorenzano/live

I’m sorry for the mess but fatherhood has this issues ;)

See you there!
Esteban

Re: [Pharo-dev] [Mm10s] 2019-12-16

[Esteban Lorenzano]

> On 17 Dec 2019, at 23:15, Ben Coman  wrote:
> 
> 
> 
> On Tue, 17 Dec 2019 at 16:22, teso...@gmail.com  
> mailto:teso...@gmail.com>> wrote:
> My report, some are the same than Esteban, as we work a lot together :D
> 
> ### Last week:
> 
> - (Pair Programming with Esteban) Modifying the TFFI callbacks to
> include information about the Smalltalk block in the plugin data
> structure. This improves the debugging experience and the detection of
> errors when a Callback in the image side is garbage collected.
> 
> - (Pair Programming with Esteban) Compiling the Queue based
> ThreaddedFFI plugin to use the latest libffi version. This is required
> to build in Catalina.
> 
> - (Pair Programming with Esteban) Adding synchronization code to
> correctly interrupt the AIO waiting idle loop. This is still work in
> progress as we have to test more scenarios. This modification allows
> us to extend enormously the idle time of the relinquish processor
> primitive without losing events nor delays.
> 
> This is super cool.   I'm interested in seeing what the changes were.  Are 
> there a few commits/PRs you could point to?

We are preparing the PR to headless :P

https://github.com/tesonep/opensmalltalk-vm/tree/merge-headless-worker-thread 


Esteban

> 
> cheers -ben

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

[Esteban Lorenzano]

> On 17 Dec 2019, at 15:38, Torsten Bergmann  wrote:
> 
> Santiago wrote:
>> What if we have links to all the groups in Pharo-project (pharo-misc,
>> pharo-processing, pharo-robotics, pharo-web) ? I can do the firsts steps if
>> we agree in here.
> 
> Hi Santiago,
> 
> yes - we should link the groups from the main "pharo-project" so they are 
> easier to find. Here are the ones I know:
> 
> 1. https://github.com/pharo-project
> 2. https://github.com/pharo-contributions (general community managed 
> contributions)
> 3. https://github.com/pharo-rdbms (relational database support)
> 4. https://github.com/pharo-nosql (NoSQL database support)
> 5. https://github.com/pharo-sql (points to https://github.com/pharo-rdbms)  
> 6. https://github.com/pharo-robotics (Robotics related)
> 7. https://github.com/pharo-brand (Brand Assets to do some marketing)
> 
> 
> 8. https://github.com/pharo-db (looks like offical DB stuff, but created by 
> Todd Blanchard to assemble some database projects)
> 
> 
> Not existing (yet), dont know why you need/mentioned them
> 
> https://github.com/pharo-misc  
> https://github.com/pharo-processing 
> https://github.com/pharo-we
> 
> For TaskIt maybe you start in "pharo-contributions" and if Pharo has more 
> projects in similar directions an own separate group
> could be created. 

+1

> 
> I'm not sure if an own mailinglist other than "Pharo-users" makes sense but 
> https://lists.pharo.org now also meanwhile got 
> an additional "Pharo-iot" and "Workflow-engine" mailinglist. 
> 
> Thanks
> T. 
> 

[Pharo-dev] [Mm10s] 2019-12-16

[Esteban Lorenzano]

### Last week:

- [Release] Open Pharo 9.0 branch to start sending PRs not included in P8 there.
- [Release] Organise issues that will enter in P8 (WIP).
- [Release] Move GT-EventRecorder legacy to a branch, so is easier to reload it.
- [Spec2] Better search feature for Lists/Trees/Tables
- [Spec2] Add bold/italic properties to styles
- [Spec2] Add “activation” property to ComponentList
- [TFFI] Add better information when registering callbacks to facilitate 
debugging.
- [TFFI] Make latest version to compile on macOS (libffi compilation was wrong)
- [VM] Work with Pablo on AIO Interrupt VM (still fixing glitches, still WIP).
- [GTK] Enhance Form to GtkPixbuf conversion, avoiding double conversions 
(resulting image is a lot more precise)
- [GTK] Fix a bug on number input fields and ranges.

### This week (starting 2019-12-16):

- [Release] Organise issues that will enter in P8.
- [Release] Prepare release notes.
- [Spec2] Fix radio buttons.
- [Spec2] TechTalk Thursday

### Pipeline

- [Release] Pharo 8 Release.
- [VM] debug AIO and worker thread VMs on linux and windows.

[Pharo-dev] [ANN] EventRecorder legacy put online

[Esteban Lorenzano]

Hi,

For those who need the deprecated (and removed) GT-EventRecorder, I have put 
the original packages in pharo-contributions/EventRecorder (legacy branch).

To load it, you just need to execute: 

Metacello new 
  repository: 'github://pharo-contributions/EventRecorder:legacy';
  baseline: 'EventRecorder'; 
  load.

This way you may continue loading Roassal2 (or others) until they fix the 
baseline :)

(Btw, installation will still fail because Matrix has been removed… but this 
one was indeed deprecated in P7 (is replaced by Array2D), a problem you can 
overcome by executing 

Array2D subclass: #Matrix

Previous to load Roassal2.

I hope this solves the problems causes lasts weeks.

Cheers,
Esteban

Re: [Pharo-dev] Are people using the Pharo VM builds from BinTray?

[Esteban Lorenzano]

Hi,

> On 12 Dec 2019, at 23:20, David T. Lewis  wrote:
> 
> Hi,
> 
> There is an automated CI build for opensmalltalk VMs with artifacts for
> Pharo, Squeak, and Newspeak at https://bintray.com/opensmalltalk/vm/cog/.
> I suspect that the Pharo builds may be redundant with the official PharoVM
> distributions.

Those VMs are also copied into our file sever and we take them from there. 

> Is anyone using the Pharo VMs from BinTray? Otherwise if it's not a problem
> for any Pharo users, I think the CI proprietors would like to turn off
> some of their unnecessary builds to save resources. My understanding is
> that the builds can easily be turned back on as needed in the future.

I do not think we use the bintray, but we still use the osvm builds as our 
standard distribution.

> 
> Fabio asked Marcel who asked me, so I am asking you :-)

So I’m answering you so you can answer Marcel who can tell Fabio ;)

Esteban

> 
> Thanks,
> Dave
> 
> 

Re: [Pharo-dev] [ANN] Roadmap progress report November 2019

[Esteban Lorenzano]

Hi,

> On 9 Dec 2019, at 13:51, Alexandre Bergel  wrote:
> 
>> Hello,
>> 
>> I am sorry for the delay, last week was very chaotic :) 
> 
> No problem! This is super cool!
> 
> Your report is amazing! Keep going!
> 
>> 
>> 
>> VM
>> ---
>> - Work on Worker VM (allow VM to run in a worker thread). 
>>  - Merged with headless trunk
>>  - Merged with AIO interrupt
>>  - Now can be tested (but still some interruptions missing)
> 
> Just wondering. A worker VM will have its own image right? Can it be 
> otherwise? I am just curious whether two VMs can run on the same image. Maybe 
> this is a stupid question, but I am wondering :-)

Worker VM just describes the capability of the VM to run in a worker thread 
(which means we can keep the main thread to other stuff, like running the event 
loop).
Now, while I know there is some work/experiments to revive something like the 
hydra (running several images in one VM, or several copies of same image), I do 
not know the opposite :)

And this Worker VM (we call it “ogre”, because it has two heads :P) will work 
with the regular image, nothing changed there. 

Esteban

> 
> Cheers,
> Alexandre
>