[Pharo-dev] Re: The results of the Pharo Browser usage survey are available

[teso...@gmail.com]

That is a really cool survey, thanks for the work!!!

On Tue, Sep 5, 2023 at 10:11 PM Koen De Hondt <
k...@all-objects-all-the-time.st> wrote:

> Dear Pharo users and developers,
>
> Last week at ESUG’23 I presented the results of the survey on the usage of
> the Pharo Browser. Half an hour was not enough to show and discuss all
> questions and answers. You find all results on my blog:
> https://all-objects-all-the-time.st/#/blog/posts/3. If you have
> questions, comments, or suggestions, please do not hesitate to send me a
> message.
>
> Best regards,
> Koen
>


-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] Pharo VM Release - v10.0.5

[teso...@gmail.com]

Hello,
  we have released a new version of the Pharo VM for Pharo 11. This VM is
accessible right now from Zero-Conf, updating it in the Pharo Launcher or
using the usual downloads (as described in pharo.org/download). Also, OBS
packages are ready to be updated using your distribution package manager.

This is the new VM that will be stable for Pharo 11 release and Pharo 12
alpha, it is also compatible with Pharo 10 images but it is not the default
for Pharo 10.

Changelog

* Testing scavenger tenuring by @PalumboN in
https://github.com/pharo-project/pharo-vm/pull/588
* Deleting Pharo image from the VM repo by @jordanmontt in
https://github.com/pharo-project/pharo-vm/pull/591
* Cleaning Up Third Party Libraries by @tesonep in
https://github.com/pharo-project/pharo-vm/pull/581

**Full Changelog**:
https://github.com/pharo-project/pharo-vm/compare/v10.0.4...v10.0.5

Thanks a lot, and any doubt please let us know.
Cheers,

Pablo on behalf of the whole Pharo team.
--
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] Pharo VM Release - v10.0.0

[teso...@gmail.com]

Hello,
  we have released a new version of the Pharo VM for Pharo 11. This VM is
accessible right now from Zero-Conf, updating it in the Pharo Launcher or
using the usual downloads (as described in pharo.org/download). OBS
packages are still in work and will come later.

This is the new VM that will be stable for Pharo 11 release, it is also
compatible with Pharo 10 images but it is not the default for Pharo 10.

It has a lot of changes and improvements, as it is the result of more than
a year and a half of improvements, clean-ups, and bug fixes.

Changelog v10.0.0

- Slang (Smalltalk to C Translator)
- Introducing a C AST to ease the generation of C Code
- Having a Pretty Printer for C AST
- Translation Tests
- Fixing Translation Issues
- Clear separation between Slang and VM code
- Improving Cast generation

- Clean Up:
- Remove Old Bytecode Set
- Remove Old Block Implementation
- Simplification of the Primitives
- Removing Unused / Old Code / Dead Code
- Cleanup / Removal of Old Unused primitives
- Removing Old FFI Implementation
- Removing MT Experiment from the code base (Kept in own branch)
- Fixing Compilation Warnings
- Improving Type annotations to fix bugs in the translation / compilation
- Removing Conditional Code on Old Configurations / Features
- Renaming Concepts to be inline with Common terminology
- Remove Newspeak, Multiple Bytecode and Old Memory Managers
- Removing Unused Plugins

- Tests
- GNUification Tests
- Tests for Math primitives including overflow and conversion testing.
- Tests for comparison primitives (Equals / Not Equals / Less than / Less
or Equals / Greater Than / Greater or Equals)
- Testing Primitives for objects Pinned in Memory
- Testing Math Primitives for Immediate Classes (SmallFloats /
SmallIntegers)
- Improving Simulation Infrastructure
- Using Sista Bytecode in all Tests
- Updating Unicorn version
- Improving Machine Code emulation
- Testing Image Read / Image Write
- Using the same memory map in Tests and Execution
- Testing Ephemerons
- Become Primitives

- Ephemeron
- Fix for large ammounts
- Make it available
- Testing Signal Finalizations

- Fixing Become Errors.

- Fixing XRay Primitive

- Single-Instruction Multiple-Data (SIMD) initial Support:
- Initialization of new objects using SIMD (ARM64)
- Adding Bytecode Extensions to support SIMD instructions
- Adding Vector Registers
- Vector Register bytecodes

- Auto Localization of Interpreter loop variables and edge detection
simplifying development and minimizing code

- ImageReader / ImageWriter reification needed for Permanent Space.

- Improving the Memory Map of the VM (Using constant positions)

- Dependencies Improvements

Thanks a lot, and any doubt please let us know.
Cheers,

Pablo on behalf of the whole Pharo team

--
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] Pharo VM Release - v9.0.21

[teso...@gmail.com]

Hello,
  I have released a new version of the Pharo VM for Pharo 9, Pharo 10 and
Pharo 11. This VM is accessible right now from Zero-Conf, updating it in
the Pharo Launcher or using the usual downloads (as described in
pharo.org/download).

This version includes a series of bug fixes and upgrades on the third-party
libraries.

Changelog:

- Implementing High resolution clock for ARM64 (Used during profiling)
- Updating third party libraries for all the graphic layer.
- Fixing a performance regression on the allocation of opcodes and fix-ups.
Cleaning only the ones that are going to be used.
Like this, this version has the same speed than before when
allocating in the stack.
- Correctly handling the encoding of the command line arguments of the VM
(Windows)
- Allocating the opcodes and fixup structs only once and reusing them
(Reducing risk of C Stack Overflow)

Thanks a lot, and any doubt please let me know.
Cheers,

Pablo on behalf of the whole Pharo team.

-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] Pharo VM Release - v9.0.13

[teso...@gmail.com]

Hello,
  I have released a new version of the Pharo VM for Pharo 9 and Pharo 10.
This VM is accessible right now from Zero-Conf, updating it in the Pharo
Launcher or using the usual downloads (as described in pharo.org/download).

This version includes a series of bug fixes.

Changelog:

- Correct handling OOB (Out of Band Data) in Window
- Blocking signals while signalling semaphores to avoid deadlocks caused by
signal handlers
- Make MAXHOSTNAMELEN at least 256: improving resolution of names in Linux
- Improving VM Simulator Machine debugger
- Integrating Processor Simulator for RISCV
- Using a new SDL2 version built for OSX Mojave compatibility

Thanks a lot, and any doubt please let me know.
Cheers,

Pablo on behalf of the whole Pharo team.


-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] Pharo VM Release - v9.0.11

[teso...@gmail.com]

Hello,
  I have released a new version of the Pharo VM for Pharo 9 and Pharo 10.
This VM is accessible right now from Zero-Conf, updating it in the Pharo
Launcher or using the usual downloads (as described in pharo.org/download).

This version includes a series of minor bug fixes.

Changelog:

- Include FloatArrayPlugin in the build
- Updating SDL2 to 2.0.18 for OSX X86_64
- Using Pharo 10 image as VMMaker image
- Fixing issue in message counting on non-JIT VM

Thanks a lot, and any doubt please let me know.
Cheers,

Pablo on behalf of the whole Pharo team.

-- 
Pablo Tesone.
teso...@gmail.com

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

[teso...@gmail.com]

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

>
>
> On 12 Jan 2022, at 17:38, Henrik Sperre Johansen <
> 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: [Zdc]SocketStream>>#openConnectionToHostNamed:port: no longer signals am exception on macOS

[teso...@gmail.com]

I changed the event handling in osx and windows, Linux uses the same old
code, but I don't discard there is a bug there or elsewhere 

I have been following this issue, I have it in my list. I have just started
with the easier ones.

On Wed, Jul 21, 2021, 13:37 Sven Van Caekenberghe  wrote:

> Hi Pablo,
>
> Thank you, I will test this soon.
>
> Is there any chance that there were also network changes in the Linux VM ?
> Perhaps also related to "detecting exceptions and out-of-band data".
>
> We keep on struggling with
> https://github.com/pharo-project/pharo/issues/9565 where it seems that
> the same code runs fine on Pharo 7 and 8, while it seems to fail on Pharo 9.
>
> Sven
>
> > On 21 Jul 2021, at 13:06, teso...@gmail.com wrote:
> >
> > I have done a new release with the fix for the socket connection.
> > It was an issue in the kqueue code in OSX.
> > It was wrongly detecting exceptions and out-of-band data.
> > Please if you can update the VM and test it should be working.
> >
> > Cheers
> > Pablo
> >
> > On Mon, Jul 19, 2021 at 1:13 PM Torsten Bergmann  wrote:
> > Hi Pablo,
> >
> > yes - Sven is right on that it could be improved. Thanks for taking
> > care of this important topic.
> >
> > Cheers,
> > Torsten
> >
> >
> > Gesendet: Montag, 19. Juli 2021 um 11:46 Uhr
> > Von: "teso...@gmail.com" 
> > An: "Pharo Development List" 
> > Betreff: [Pharo-dev] Re:
> [Zdc]SocketStream>>#openConnectionToHostNamed:port: no longer signals am
> exception on macOS
> > Thanks, yes it is true, the version name is a mess.
> > We need to improve the version display.
> > I will take note of that and I will fix it.
> >
> > Cheers,
> > Pablo
> >
> > On Mon, Jul 19, 2021 at 11:08 AM Sven Van Caekenberghe 
> wrote:
> > Hi Pablo,
> >
> > prometheus:2021-07-16 sven$ ./pharo --version
> > Pharo 9.0.0 built on Jul  6 2021 10:36:56 Compiler: 4.2.1 Compatible
> Apple LLVM 11.0.3 (clang-1103.0.32.29)
> > Built from: ea8a3bfc - Commit: ea8a3bfc - Date: 2021-07-06 10:23:13 +0200
> > prometheus:2021-07-16 sven$ ./pharo Pharo.image printVersion
> > [version] 'Pharo9.0.0'
> 'Pharo-9.0.0+build.1532.sha.e58ef49051bf06cad56a2dda174b8e091a45d5df (64
> Bit)'
> > prometheus:2021-07-16 sven$ ./pharo Pharo.image eval "(ZdcSocketStream
> openConnectionToHostNamed: 'localhost' port: 12335) nextPut: 0; close. #foo"
> >
> > I have said this before, but the VM version is incomprehensible for
> normal people, why can't it just be something like 10.1 like the rest of
> the world ?
> >
> > Also, for mere mortals it is impossible to find out if something changed
> about the VM, let alone what, and how that all relates to specific versions.
> >
> > I know that you guys have a lot of work, and we are very grateful for
> it, but this is how it looks from the outside.
> >
> > Thx,
> >
> > Sven
> >
> > > On 19 Jul 2021, at 10:56, teso...@gmail.com wrote:
> > >
> > > Hi,
> > >with the new VM I could not reproduce it. I think it was related
> with the issue of the NetNameResolver.
> > > Which VM version are you using?
> > >
> > > Thanks
> > >
> > > On Sun, Jul 18, 2021 at 3:51 PM Sven Van Caekenberghe 
> wrote:
> > > Hi,
> > >
> > > It seems that the following consistently crashes a recent/latest Pharo
> 9 image/vm on macOS:
> > >
> > >   (ZdcSocketStream openConnectionToHostNamed: 'localhost' port: 12335)
> nextPut: 0; close.
> > >
> > > Command line, you can try it as follows:
> > >
> > >  $ ./pharo Pharo.image eval "(ZdcSocketStream
> openConnectionToHostNamed: 'localhost' port: 12335) nextPut: 0; close. #foo"
> > >
> > > You can replace ZdcSocketStream by SocketStream, same result.
> > >
> > > Before, trying to connect to a non-existing host:port resulted in a
> ConnectionTimedOut: Cannot connect to 127.0.0.1:12335.
> > >
> > > Now, the code just returns and the bad stream is then used as if it is
> OK, which results in a hard crash.
> > >
> > > Furthermore, there is no backtrace nor log.
> > >
> > > Sven
> > >
> > >
> > > --
> > > Pablo Tesone.
> > > teso...@gmail.com
> >
> >
> > --
> > Pablo Tesone.
> > teso...@gmail.com
> >
> >
> > --
> > Pablo Tesone.
> > teso...@gmail.com
>

[Pharo-dev] Re: [Zdc]SocketStream>>#openConnectionToHostNamed:port: no longer signals am exception on macOS

[teso...@gmail.com]

I have done a new release with the fix for the socket connection.
It was an issue in the kqueue code in OSX.
It was wrongly detecting exceptions and out-of-band data.
Please if you can update the VM and test it should be working.

Cheers
Pablo

On Mon, Jul 19, 2021 at 1:13 PM Torsten Bergmann  wrote:

> Hi Pablo,
>
> yes - Sven is right on that it could be improved. Thanks for taking
> care of this important topic.
>
> Cheers,
> Torsten
>
>
> *Gesendet:* Montag, 19. Juli 2021 um 11:46 Uhr
> *Von:* "teso...@gmail.com" 
> *An:* "Pharo Development List" 
> *Betreff:* [Pharo-dev] Re:
> [Zdc]SocketStream>>#openConnectionToHostNamed:port: no longer signals am
> exception on macOS
> Thanks, yes it is true, the version name is a mess.
> We need to improve the version display.
> I will take note of that and I will fix it.
>
> Cheers,
> Pablo
>
> On Mon, Jul 19, 2021 at 11:08 AM Sven Van Caekenberghe 
> wrote:
>
>> Hi Pablo,
>>
>> prometheus:2021-07-16 sven$ ./pharo --version
>> Pharo 9.0.0 built on Jul  6 2021 10:36:56 Compiler: 4.2.1 Compatible
>> Apple LLVM 11.0.3 (clang-1103.0.32.29)
>> Built from: ea8a3bfc - Commit: ea8a3bfc - Date: 2021-07-06 10:23:13 +0200
>> prometheus:2021-07-16 sven$ ./pharo Pharo.image printVersion
>> [version] 'Pharo9.0.0'
>> 'Pharo-9.0.0+build.1532.sha.e58ef49051bf06cad56a2dda174b8e091a45d5df (64
>> Bit)'
>> prometheus:2021-07-16 sven$ ./pharo Pharo.image eval "(ZdcSocketStream
>> openConnectionToHostNamed: 'localhost' port: 12335) nextPut: 0; close. #foo"
>>
>> I have said this before, but the VM version is incomprehensible for
>> normal people, why can't it just be something like 10.1 like the rest of
>> the world ?
>>
>> Also, for mere mortals it is impossible to find out if something changed
>> about the VM, let alone what, and how that all relates to specific versions.
>>
>> I know that you guys have a lot of work, and we are very grateful for it,
>> but this is how it looks from the outside.
>>
>> Thx,
>>
>> Sven
>>
>> > On 19 Jul 2021, at 10:56, teso...@gmail.com wrote:
>> >
>> > Hi,
>> >with the new VM I could not reproduce it. I think it was related
>> with the issue of the NetNameResolver.
>> > Which VM version are you using?
>> >
>> > Thanks
>> >
>> > On Sun, Jul 18, 2021 at 3:51 PM Sven Van Caekenberghe 
>> wrote:
>> > Hi,
>> >
>> > It seems that the following consistently crashes a recent/latest Pharo
>> 9 image/vm on macOS:
>> >
>> >   (ZdcSocketStream openConnectionToHostNamed: 'localhost' port: 12335)
>> nextPut: 0; close.
>> >
>> > Command line, you can try it as follows:
>> >
>> >  $ ./pharo Pharo.image eval "(ZdcSocketStream
>> openConnectionToHostNamed: 'localhost' port: 12335) nextPut: 0; close. #foo"
>> >
>> > You can replace ZdcSocketStream by SocketStream, same result.
>> >
>> > Before, trying to connect to a non-existing host:port resulted in a
>> ConnectionTimedOut: Cannot connect to 127.0.0.1:12335.
>> >
>> > Now, the code just returns and the bad stream is then used as if it is
>> OK, which results in a hard crash.
>> >
>> > Furthermore, there is no backtrace nor log.
>> >
>> > Sven
>> >
>> >
>> > --
>> > Pablo Tesone.
>> > teso...@gmail.com
>
>
>
> --
> Pablo Tesone.
> teso...@gmail.com
>


-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] Re: [Zdc]SocketStream>>#openConnectionToHostNamed:port: no longer signals am exception on macOS

[teso...@gmail.com]

Thanks, yes it is true, the version name is a mess.
We need to improve the version display.
I will take note of that and I will fix it.

Cheers,
Pablo

On Mon, Jul 19, 2021 at 11:08 AM Sven Van Caekenberghe  wrote:

> Hi Pablo,
>
> prometheus:2021-07-16 sven$ ./pharo --version
> Pharo 9.0.0 built on Jul  6 2021 10:36:56 Compiler: 4.2.1 Compatible Apple
> LLVM 11.0.3 (clang-1103.0.32.29)
> Built from: ea8a3bfc - Commit: ea8a3bfc - Date: 2021-07-06 10:23:13 +0200
> prometheus:2021-07-16 sven$ ./pharo Pharo.image printVersion
> [version] 'Pharo9.0.0'
> 'Pharo-9.0.0+build.1532.sha.e58ef49051bf06cad56a2dda174b8e091a45d5df (64
> Bit)'
> prometheus:2021-07-16 sven$ ./pharo Pharo.image eval "(ZdcSocketStream
> openConnectionToHostNamed: 'localhost' port: 12335) nextPut: 0; close. #foo"
>
> I have said this before, but the VM version is incomprehensible for normal
> people, why can't it just be something like 10.1 like the rest of the world
> ?
>
> Also, for mere mortals it is impossible to find out if something changed
> about the VM, let alone what, and how that all relates to specific versions.
>
> I know that you guys have a lot of work, and we are very grateful for it,
> but this is how it looks from the outside.
>
> Thx,
>
> Sven
>
> > On 19 Jul 2021, at 10:56, teso...@gmail.com wrote:
> >
> > Hi,
> >with the new VM I could not reproduce it. I think it was related with
> the issue of the NetNameResolver.
> > Which VM version are you using?
> >
> > Thanks
> >
> > On Sun, Jul 18, 2021 at 3:51 PM Sven Van Caekenberghe 
> wrote:
> > Hi,
> >
> > It seems that the following consistently crashes a recent/latest Pharo 9
> image/vm on macOS:
> >
> >   (ZdcSocketStream openConnectionToHostNamed: 'localhost' port: 12335)
> nextPut: 0; close.
> >
> > Command line, you can try it as follows:
> >
> >  $ ./pharo Pharo.image eval "(ZdcSocketStream openConnectionToHostNamed:
> 'localhost' port: 12335) nextPut: 0; close. #foo"
> >
> > You can replace ZdcSocketStream by SocketStream, same result.
> >
> > Before, trying to connect to a non-existing host:port resulted in a
> ConnectionTimedOut: Cannot connect to 127.0.0.1:12335.
> >
> > Now, the code just returns and the bad stream is then used as if it is
> OK, which results in a hard crash.
> >
> > Furthermore, there is no backtrace nor log.
> >
> > Sven
> >
> >
> > --
> > Pablo Tesone.
> > teso...@gmail.com
>


-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] Re: [Zdc]SocketStream>>#openConnectionToHostNamed:port: no longer signals am exception on macOS

[teso...@gmail.com]

Hi,
   with the new VM I could not reproduce it. I think it was related with
the issue of the NetNameResolver.
Which VM version are you using?

Thanks

On Sun, Jul 18, 2021 at 3:51 PM Sven Van Caekenberghe  wrote:

> Hi,
>
> It seems that the following consistently crashes a recent/latest Pharo 9
> image/vm on macOS:
>
>   (ZdcSocketStream openConnectionToHostNamed: 'localhost' port: 12335)
> nextPut: 0; close.
>
> Command line, you can try it as follows:
>
>  $ ./pharo Pharo.image eval "(ZdcSocketStream openConnectionToHostNamed:
> 'localhost' port: 12335) nextPut: 0; close. #foo"
>
> You can replace ZdcSocketStream by SocketStream, same result.
>
> Before, trying to connect to a non-existing host:port resulted in a
> ConnectionTimedOut: Cannot connect to 127.0.0.1:12335.
>
> Now, the code just returns and the bad stream is then used as if it is OK,
> which results in a hard crash.
>
> Furthermore, there is no backtrace nor log.
>
> Sven
>


-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] Re: Serious NetNameResolver regression

[teso...@gmail.com]

I have updated the VMs, the issue should be resolved now.

On Fri, Jul 16, 2021 at 12:10 PM Guillermo Polito 
wrote:

> Hi all,
>
> it seems we need a new VM release.
> The issue seems fixed since ~6 months ago
>
>
> https://github.com/pharo-project/opensmalltalk-vm/commit/bff77946691617acce104d8f38d60242fa1cc2bb
>
> Pablo is updating the stable VMs just in this moment.
>
> G
>
> > El 16 jul 2021, a las 12:07, Sven Van Caekenberghe 
> escribió:
> >
> > Anyway, for now, I added guards:
> >
> >
> https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05deb8
> >
> https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440b2c64
> >
> > but the core problem remains.
> >
> >> On 15 Jul 2021, at 21:35, Gabriel Cotelli  wrote:
> >>
> >> You're right Sven. The code in the image looks exactly the same betwen
> Pharo 8 and 9 but the behavior is different.
> >>
> >> On Thu, Jul 15, 2021 at 3:40 PM Sven Van Caekenberghe 
> wrote:
> >>
> >>
> >>> On 15 Jul 2021, at 16:42, Gabriel Cotelli  wrote:
> >>>
> >>> Just doing
> >>> NetNameResolver primStartLookupOfName:'unknown-stfx.eu
> ';primNameLookupResult
> >>> produces the bogus result. And both methods only call primitives in
> the SocketPlugin. So I think that no image code is responsible for the
> behavior change.
> >>
> >> I don't know, but your example is not good. You have to wait else the
> result is always 0.0.0.0
> >>
> >> Pharo 7
> >>
> >> NetNameResolver primStartLookupOfName:'unknown-stfx.eu';
> waitForCompletionUntil: 5
> >>
> >> false (signal exception)
> >>
> >> Pharo 9
> >>
> >> NetNameResolver primStartLookupOfName:'unknown-stfx.eu';
> waitForCompletionUntil: 5
> >>
> >> true (bogus 0.0.0.0 result)
> >>
> >>> On Thu, Jul 15, 2021 at 11:36 AM Sven Van Caekenberghe 
> wrote:
> >>> Hi,
> >>>
> >>> It seems that we have a serious NetNameResolver regression: instead of
> signalling an exception, a bogus value is returned.
> >>>
> >>> Pharo 7:
> >>>
> >>> [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on:
> NameLookupFailure do: [ :exception | exception ].
> >>>
> >>> "NameLookupFailure: cannot resolve 'unknown-stfx.eu'"
> >>>
> >>> Pharo 9:
> >>>
> >>> [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on:
> NameLookupFailure do: [ :exception | exception ].
> >>>
> >>> "0.0.0.0"
> >>>
> >>> This is bad. What is even worse is that the following kills your image
> without leaving any trace (on macOS):
> >>>
> >>> ZnClient new get: 'http://unknown-stfx.eu'.
> >>>
> >>> Because it tries to connect to 0.0.0.0
> >>>
> >>> On linux, at least there is a backtrace:
> >>>
> >>> sven@stfx-1:~/pharo$ rlwrap ./pharo reddit.image NeoConsole repl
> >>> NeoConsole
> Pharo-9.0.0+build.1528.sha.29269ecfac2cbf6a56dfee232b7d3355e5cb77bd (64 Bit)
> >>> pharo> NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10.
> >>>
> >>> 0.0.0.0
> >>> pharo> ZnClient new get: 'http://unknown-stfx.eu'.
> >>>
> >>> ConnectionTimedOut: Cannot connect to 0.0.0.0:80
> >>> [ConnectionTimedOut signal: 'Cannot connect to '
> >>>, (NetNameResolver
> stringFromAddress: hostAddress) , ':' , port asString] in
> Socket>>connectTo:port:waitForConnectionFor:
> >>>Receiver: a Socket[unconnected]
> >>>Arguments and temporary variables:
> >>>hostAddress:0.0.0.0
> >>>port:   80
> >>>timeout:30
> >>>Receiver's instance variables:
> >>>semaphore:  a Semaphore()
> >>>socketHandle:   #[198 113 243 96 0 0 0 0 240 65 61 2 0
> 0 0 0]
> >>>readSemaphore:  a Semaphore()
> >>>writeSemaphore: a Semaphore()
> >>>
> >>> Socket>>waitForConnectionFor:ifTimedOut:
> >>> Socket>>connectTo:port:waitForConnectionFor:
> >>> ZdcSocketStream(ZdcAbstractSocketStream)>>socketConnectTo:port:
> >>> ZdcSocketStream(ZdcSimpleSocketStream)>>connectTo:port:
> >>> ZdcSocketStream class(ZdcSimpleSocketStream
> class)>>openConnectionToHost:port:timeout:
> >>> ZnNetworkingUtils>>socketStreamToUrlDirectly:
> >>> ZnNetworkingUtils>>socketStreamToUrl:
> >>> ZnNetworkingUtils class>>socketStreamToUrl:
> >>>
> >>> I had a quick look at changes to Network-Kernel but had no luck yet.
> >>>
> >>> Because of this running Zinc HTTP Components tests on macOS Pharo 9
> also kills the image (ZnClientTest>>#testIfFailNonExistingHost).
> >>>
> >>> Of course, NetNameResolverTest does not do enough.
> >>>
> >>> Sven
>


-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] Re: Broken window alert

[teso...@gmail.com]

Thanks, it looks cool

On Wed, Apr 7, 2021 at 12:12 PM Sven Van Caekenberghe  wrote:

> And here is the PR, I hope it is OK:
>
> https://github.com/pharo-project/pharo/pull/8977
>
> > On 7 Apr 2021, at 11:53, Sven Van Caekenberghe  wrote:
> >
> > Hi Pablo, Guille,
> >
> > Thanks for the links.
> >
> > You can consider the Zn/Zdc failures fixed. Something changed recently
> with the Google query service so that it now includes a redirect. The full
> ZnClient follows those without any problems, but these tests are much more
> primitive and can't handle a redirect. I now use DuckDuckGo for the test at
> this level.
> >
> > Here is the first change
> >
> >
> https://github.com/svenvc/zinc/commit/75710f9832e6ddad8a477d061978149b1d08c6b8
> >
> > and the second
> >
> >
> https://github.com/svenvc/zodiac/commit/cd4c4ee7e7cc8eb3624b4c7b4f8af861481cd37e
> >
> > my own tests for Pharo 7, 8 and 9 are green
> >
> >  https://github.com/svenvc/zinc/actions/runs/725549812
> >
> > I will now try to make a PR on a current Pharo 9 image.
> >
> > Sven
> >
> >> On 6 Apr 2021, at 22:58, Guillermo Polito 
> wrote:
> >>
> >>
> >>
> >>> El 6 abr 2021, a las 22:55, Sven Van Caekenberghe 
> escribió:
> >>>
> >>> I agree, could you post a link to or a list of the broken tests ?
> >>
> >> Sure :)
> >>
> >> The CI:
> >>
> https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/
> >>
> >> Last Three Jobs:
> >>
> https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/1286/
> >>
> https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/1285/
> >>
> https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/1284/
> >>
> >>
> >>>
> >>>> On 6 Apr 2021, at 22:54, Guillermo Polito 
> wrote:
> >>>>
> >>>> Hi Guys,
> >>>>
> >>>> With Pablo we were discussing that it would be nice to stop with the
> integrations until we fix the broken tests.
> >>>> We have crossed the 20 broken tests for more than 20 builds.
> >>>> We should put some energy in fixing those, but we are afraid that if
> we continue this way, eventually it will become unmanageable.
> >>>>
> >>>> Cheers,
> >>>> Guille
> >>
> >
>


-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] Re: Broken window alert

[teso...@gmail.com]

Hi Sven,

Here there is:

https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/1286/testReport/

Thanks,
Pablo

On Tue, Apr 6, 2021 at 10:56 PM Sven Van Caekenberghe  wrote:

> I agree, could you post a link to or a list of the broken tests ?
>
> > On 6 Apr 2021, at 22:54, Guillermo Polito 
> wrote:
> >
> > Hi Guys,
> >
> > With Pablo we were discussing that it would be nice to stop with the
> integrations until we fix the broken tests.
> > We have crossed the 20 broken tests for more than 20 builds.
> > We should put some energy in fixing those, but we are afraid that if we
> continue this way, eventually it will become unmanageable.
> >
> > Cheers,
> > Guille
>


-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] Re: ARM64 VM for Manjaro/Arch

[teso...@gmail.com]

Hi Patrick,
we don't have a binary version of the VM yet. We are trying to use OBS
to generate the packaging for the different distributions and
architectures. This is working for Arch-like distributions for x86_64 but
not for ARM (v7 nor v8). I have tried today to see if it is our problem or
if it is only that OpenBuildService still does not support it.

In the meantime, I have added instructions to build the VM locally from the
sources already generated. You can check it there:

https://github.com/pharo-project/opensmalltalk-vm/wiki/Compiling-in-Manjaro-ARM64

If still, you are not able to build it, please let me know, and I can try
to pass you a binary version of it.

I want to have binary packages for most of the distributions using the
dependencies locally, but we need to manage the amount of manual work.

Cheers,
Pablo

On Mon, Feb 15, 2021 at 2:21 AM Patrick Henning 
wrote:

> Hello, I am writing to ask how I can access the beta ARM64 VM for
> Arch-type Linux (I am using Manjaro in particular).
>
> Thank you!
> Patrick
>
>

-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] Beta Testing ARM64 Linux & Windows

[teso...@gmail.com]

ory to take the current versions

sudo apt update

3) Install Pharo9 VM

sudo apt install pharo9 libgit2


4) In case of using the interactive version (with UI) check if the packages
libsdl2-2.0-0  and libcairo2 are installed (Usually they are installed, but
depends what it is installed in the system). These are not needed for the
headless execution or if it is not used by the image.


*Getting the images:*

The images can be downloaded using zero-conf, the latest image is ready to
be used. It can be done with:

wget -O - get.pharo.org/64/90 | bash


*Running Pharo*

pharo Pharo.image eval 42 factorial

Or interactive

pharo Pharo.image --interactive


*Windows Testing*
A version of the VM is ready to be tested in Windows ARM64. A zip
containing the VM is available in:

https://files.pharo.org/vm/pharo-spur64/Windows-ARM64/PharoVM-9.0.0-4df0e562a-Windows-ARM64-stockReplacement-bin.zip

As in Linux, the latest image is compatible with this version of the VM.


*Error reporting*
In case of encountering errors please report them attaching:

 - crash.dmp file and PharoDebug.log
 - Version of the image using (in case of any community project loaded, the
names of those)

 - Complete machine version (the result of executing uname -a)
 - Complete information about the Linux distribution

 - Steps for reproducing the error (if needed)

Thanks for the effort!!

-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] Re: [ANN] New Pharo VM released (v8.6.1)

[teso...@gmail.com]

Hi Martin, yes, it is true. I have to rollback the change because it
was a compatibility issue with Debian 9.11, and this version is the
one used by Jenkins docker images.
I will do a release as soon as I can fix it. I want to push OBS to the
last step to be productive. There is a lot of work on that and we need
to profit it.
The headless VM in Linux has been updated to the latest and that one
has not been rollbacked.

On Fri, Nov 27, 2020 at 5:48 AM Martin McClure  wrote:
>
> Is this new VM available for Linux? I only see Windows and Mac VMs that
> are dated 2020-11-02.
> In the launcher (launcher 2.2, still the latest AFAICT) refreshing the
> 90-x64 VM just re-downloads the one from 2020-02-11.
>
> Thanks,
> -Martin
>
> On 11/2/20 7:48 AM, teso...@gmail.com wrote:
> > Hi,
> >   this is an announcement of a new release of the Pharo VM. This
> > new version is available to be downloaded through get-pharo scripts
> > and through the Pharo Launcher. From the Pharo Launcher, remember to
> > update the VM from the VM manager window.
> >
> > This version includes a series of improvements:
> >
> > - Unification of code base with the headless VM
> > - Preparation for supporting HDPI displays.
> > - Improvements in the speed of Threaded FFI (40x times faster in
> > SameThread runner and 2x in Threaded worker).
> > - Better handling of semaphores
> > - Improvements in the loading of large images (better buffering)
> > - Better support for headless execution on non-main thread
> >
> > Please let me know if you find any issues.
> >
> > Cheers, Pablo
> >
>


-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] [ANN] New Pharo VM released (v8.6.1)

[teso...@gmail.com]

Hi,
 this is an announcement of a new release of the Pharo VM. This
new version is available to be downloaded through get-pharo scripts
and through the Pharo Launcher. From the Pharo Launcher, remember to
update the VM from the VM manager window.

This version includes a series of improvements:

- Unification of code base with the headless VM
- Preparation for supporting HDPI displays.
- Improvements in the speed of Threaded FFI (40x times faster in
SameThread runner and 2x in Threaded worker).
- Better handling of semaphores
- Improvements in the loading of large images (better buffering)
- Better support for headless execution on non-main thread

Please let me know if you find any issues.

Cheers, Pablo

-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] Re: [ANN] Libgit 1.0.0 in Pharo 9

[teso...@gmail.com]

Hi Martin,
   thanks for testing it. Can you tell me the version / flavour of
Debian are you using?
Maybe we need to ship PCRE with the VM. I am not fun of that, but we
need to do it until we can have a proper packaging for each Linux
distribution (Esteban is working on having a nice OBS configuration
for the VM extending what Holger has previously done).
It takes time and a lot of testing, but the idea is to fix (or at
least control better) the dependency nightmare between different Linux
distributions.

Cheers,
Pablo

On Tue, Oct 13, 2020 at 7:49 AM Martin McClure  wrote:
>
> Thanks, this is great news.
>
> Are there instructions on how to make P9 actually use the new version of
> libgit2? I see that the stable Linux VM for 9.0 does include
> "libgit2.1.0.0.so" but Pharo is still loading libgit2.so.0.25.1.
>
> ...this may be because Pharo's libgit2.1.0.0.so has not-found
> dependencies on libpcre.so.3 and libpcreposix.so.3.
>
> I find Debian's versioning of libpcre somewhat confusing. The package
> "libpcre3" is the *old* libraries, and new stuff is supposed to use
> "pcre2." 2 is apparently newer than 3. At any rate PCRE library naming
> is rather distro-specific, and although I have the right packages
> installed, the libraries have different filenames.
>
> But libgit2 is not supposed to have PCRE as a dependency. The source
> code for PCRE is included in the source for libgit2. Seems like it would
> be possible (and nice!) to compile the libgit2.1.0.0.so included with
> the VM to include the PCRE code internally, rather than depend on an
> external library.
>
> Thanks,
> -Martin
>
> On 10/12/20 2:26 AM, teso...@gmail.com wrote:
> > Hi, a later announcement (this have been done some months ago... but I
> > never send the mail).
> >
> > We have upgraded in Pharo 9 to use the latest stable version of Libgit.
> > It required to have some improvements in Libgit to handle the updated
> > version and also to support the previous version.
> >
> >  From the point of view of new features, it does not add new things.
> > However, this version fixes a lot of existing problems in Libgit.
> >
> > We can be sure this was a successful deployment as we don't have
> > problems with it. We are really happy that this has been done
> > transparently and keeping the working version with different
> > configurations of images and VMs. As we should support new and old
> > images, on the same VM. And also running new images in old VMs
> >
> > Thanks.
> >
>


--
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] [ANN] Libgit 1.0.0 in Pharo 9

[teso...@gmail.com]

Hi, a later announcement (this have been done some months ago... but I
never send the mail).

We have upgraded in Pharo 9 to use the latest stable version of Libgit.
It required to have some improvements in Libgit to handle the updated
version and also to support the previous version.

>From the point of view of new features, it does not add new things.
However, this version fixes a lot of existing problems in Libgit.

We can be sure this was a successful deployment as we don't have
problems with it. We are really happy that this has been done
transparently and keeping the working version with different
configurations of images and VMs. As we should support new and old
images, on the same VM. And also running new images in old VMs

Thanks.

-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] Halos Broken - P9 Headless

[teso...@gmail.com]

Cool, I will check it out. It seams like a problem with SDL event
conversion in the images. As they are appearing with the click on the
middle button but not with the combination Cmd + LeftClick

On Tue, Aug 4, 2020 at 5:21 AM Sean P. DeNigris  wrote:
>
> Sean P. DeNigris wrote
> > Morphic halos don't seem to be working with the Pharo 9 headless VM. They
> > seem fine with headful.
>
> Still a bug as of Build information:
> Pharo-9.0.0+build.572.sha.308d3ba56ee06f02c3d3f916da5636d04ceca15b (64 Bit)
>
> https://github.com/pharo-project/opensmalltalk-vm/issues/100
>
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>


-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] [rmod] [Mm10s] 2020-06-15

[teso...@gmail.com]

On Mon, Jun 15, 2020 at 7:00 AM  wrote:
>
> Monday morning, time for the weekly mail meeting in 10 seconds!
> (just reply, inserting bullet points)
>
> ### Last week:

- Propagating changes in many images
- Working with Nicolas
- Pharo Meeting
- JIT Bytecode Testing
- Stabilizing Idle VM
- Releasing Pharo Idle VM
- OBS
- Bootstrap Paper
- Build for ARM64 (Ubuntu Server)

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

- Propagating changes in many images
- Running tests in many images.
- JIT Bytecode Testing
- PThreaded FFI
- Fixing FFI problems in ARM 32/64


-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] Need info about pharo C++ file compilation

[teso...@gmail.com]

Hi,
   UFFI is prepared to call C functions, all the handling of the
functions is intended to call libraries exposing a C API. C++ presents
a series of complexities, the main two are the mangling of the names
(as C++ allows to have parameter overloading in the functions, the
name of the real functions in the generated binary have codified the
type of the return value and the parameters), and the templating of
types when performing calls with complex types. Both elements (and
others) are implementation dependant, each compiler is free to
implement in a different way. So, there is no single ABI (Application
Binary Interface), there is an attempt to have a single ABI since
C++11 but that is not 100% compatible. These behavior can be
implemented in Pharo, for UFFI, but there is nothing done in that
sense.

That is why many libraries and API exposes a C API to use it.

Cheers,
Pablo

On Fri, Jun 12, 2020 at 10:55 AM shawon58  wrote:
>
> Hello There
> i am new to Pharo, so as i learn UFFI can handle c code, but i want to know
> that, is there any way to compile/run a c++ file using pharo, because i made
> a file for creating a box in FreeCAD using C++ code, so if i can compile
> that file using pharo than one part of my work will be done than i can start
> other part.
>
> 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
>


-- 
Pablo Tesone.
teso...@gmail.com

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

[teso...@gmail.com]

### Last week:

- Monday Holiday
- Multiple images test runners
- [VM] Writing tests for JIT generation
- Idle VM with Esteban: Gtk
- Missing parts in the Image to have Sista + FullBlockClosure.
- Reviewing PR & Issues

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

- Releasing VM with LibGit 1.0.0
- Multiple images test runners
- [VM] Writing tests for JIT generation
- Idle VM with Esteban: Gtk

On Mon, Jun 8, 2020 at 10:03 AM Esteban Lorenzano  wrote:
>
>
> ### 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
>
>
>


-- 
Pablo Tesone.
teso...@gmail.com

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

[teso...@gmail.com]

 ### Last week:

- Large Images Updating Baseline
- Pharo Sync Meeting
- LiveTyping in Pharo: Recovering the build, fixing some problems
- JIT Documentation / Test
- Benchmarks with the Lowcode variant
- Meeting with Esteban
- Activate setting to run build in Sista w/FullBlockClosures
- Implementing the Decompiler for FullBlockClosures
- Fixing RecompileAll / recompile: with traits (it looks like it was
never working), discovered thank to the tests - and activating
FullBlockClosures
- Working in PICs with Guille & Stef
- Idle VM stabilization

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

- Missing parts in the Image to have Sista + FullBlockClosure
- Running multiple testing images
- Propagating changes in many images
- [VM] Configuring Defaults from the build process.
- Pharo Bootstrap in 64 bits
- Large Images: Checking Remaining issues
- Reviewing PR & Issues

On Mon, May 18, 2020 at 10:00 AM Esteban Lorenzano  wrote:
>
> 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
>


-- 
Pablo Tesone.
teso...@gmail.com

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

[teso...@gmail.com]

### Last week:

- Caro Sync & VM Journal Club
- Friday holiday!
- [VM] Fixing the Idle VM in Windows
- [VM] Fixing some crashes in the headless VM: errors during memory
allocation & segment allocations
- Techtalk
- Pharo Consortium Meeting
- Checking Matteo GC tuning problem
- [TFFI] problems with bad ordered callbacks
- [TFFI] Checking performance of Callbacks
- [TFFI] Customize how the callbacks are run per Library: New process
per callback / same process for all callbacks.
- [LargeImages] Fixing Taskit problem with large images.
- [VM/LargeImages] Read / Write images in chunks of 128KB, add hints
to the OS about file access.
- [VM] Configuring Defaults from the build process. [WIP]

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

- Large Images: Checking Remaining issues
- Activate setting to run build in Sista w/FullBlockClosures
- Running multiple testing images
- Propagating changes in many images
- Reviewing PR & Issues
- [VM] Writing tests for JIT generation

On Mon, May 11, 2020 at 10:14 AM Esteban Lorenzano  wrote:
>
> 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
>


-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] Fwd: [Vm-dev] why GT forked the VM and how to kill our fork

[teso...@gmail.com]

morous Toolkit to the Applications folder on macOS would then 
> experience incorrect application behaviour.
>
>
> To create end-user applications we also need to fully customize the 
> executable name (what the user sees in the Task Runner/Activity monitor), 
> icons, native menus. Part of this work is already integrated in the 
> pharo-project/opensmalltalk-vm - headless branch (Customizing the OS X icons, 
> Brand the VM executable and package).
>
>
> Since last year Github offers Github Actions similar to Travis. We found it 
> much easier to use than Travis for external libraries and the vm. Also we get 
> to manage the code and the builds in the same place. This work is already 
> integrated in the pharo-project/opensmalltalk-vm - headless branch (Build the 
> VM under GitHub actions: 
> https://github.com/pharo-project/opensmalltalk-vm/pull/56).
>
>
> The issues related to running Iceberg is a bit more technical. By moving to 
> the headless vm we are running the entire image computation inside a callback 
> from Glutin (https://github.com/rust-windowing/glutin/). When using Iceberg 
> we get nested callbacks which we could not get to work using Alien. Instead 
> we are using the ThreadedFFI Plugin and running all callback from Iceberg and 
> Glutin using the Threaded FFI plugin 
> (https://github.com/pharo-project/threadedFFI-Plugin). Currently we have a 
> small fork of this plugin (feenkcom/threadedFFI-Plugin) and we also ship a 
> custom plugin with the VM to fix a race condition due to having two copies of 
> the callback stack (a pull request is here: 
> https://github.com/pharo-project/threadedFFI-Plugin/pull/17).
>
>
> One detail here is that Alien provides the callback machinery used alongside 
> ThreadedFFIPlugin.  The Alien call-out machinery is an old hack used only by 
> Newspeak, that could be eliminated in non-Newspeak builds.  But AFAIA Alien’s 
> callback machinery is *the* callback machinery everywhere for the 
> OpenSmalltalk vm.
>
> While not specific to our environment, openssl1.0 is no longer supported, and 
> we are seeing users who are unable to run Pharo due to version conflicts, as 
> reported in https://github.com/pharo-project/opensmalltalk-vm/issues/62.
>
>
>
> To sum up, a fork was the easiest way to get all this running. Now some 
> changes are already in the pharo-project/opensmalltalk-vm - headless branch. 
> What we are still missing are the changes that get the VM to work nicely with 
> Mac OS and a bug fix in ThreadedFFI.
>
>
> We would also love it to have all these changes integrated in 
> OpenSmalltalk/opensmalltalk-vm in the headless vm. This requires additional 
> coordination as the required changes are somewhat deeper.
>
>
> Can it be done with pull requests?  Should we try and firm a team of 
> volunteers, eg one from feenk and one from OpenSmalltalk to try and merge in 
> the feenk code?
>
> I would volunteer but I am way too busy getting the Terf system working.  
> TFir e able, the ARMv8 JIT has been working for months but I’ve had no time 
> to release it because of Terf and other payed work (got to pay the bills).
>
> Please let us know you would prefer to coordinate.
>
>
> Any volunteers?
>
> Cheers,
>
> Tudor, on behalf of the feenk team
>
>
> --
>
> feenk.com
>
>
> "The coherence of a trip is given by the clearness of the goal."
>
>
>
>
>
>
>
>


-- 
Pablo Tesone.
teso...@gmail.com

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

[teso...@gmail.com]

Hi, a little resume of my tasks last week.

- Monday Holiday
- VM tasks documentation
- Reviewing PRs
- Lowcode Sync
- Read Lowcode Code
- JIT Testing
- Idle VM: FIxing problems with semaphores and Threads (they had a
lock-free implementation but it was not robust enough).
- Idle VM: Fixing AIO interrupt error (The AIO poll has to be aware of
external semaphores to signal)
- Idle VM: Adding SDL support to run in the main thread (Fully
implementing the SDL binding in UFFI, so we can configure it).
- Idle VM: Fixing callbacks problems [W/Esteban] (The callback queue
was using a WeakSet that was concurrently accessed and modified, also
it is growing and shrinking all the time).
- Idle VM: Errors debugging in callbacks [W/Esteban] [WIP]
- Task-it Problem [WIP]: Some contexts are kept for debugging, producing leaks.
- Idle VM: Adding an AIO implementation using KQueue for OSX. Select
is not a good player with FIFO and Pipes in OSX, in Linux goes well.

 This week (starting 2020-04-20), just the tip of the iceberg.

- Large Images: Checking Remaining issues
- Task-it Problem
- Pharo Status presentation
- Pharo Status Techtalk.
- [VM] Fixing Tests in Idle.
- Reviewing PR & Issues
- [VM] Writing tests for JIT generation

-- 
Pablo Tesone.
teso...@gmail.com

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

[teso...@gmail.com]

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

### Last week:

- Reviewing Iceberg PR
- Pharo-COM problem with BSTR
- VM Printing Errors & Messages
- [PharoCOM] Pharo 7 errors
- Testing LLVM capabilities as Testable JIT: Impossible to extract the
machine code without reading the object format.
- Fixing problem with WorldMorph install
- Consortium Meeting
- Journal Club: Pretenuring - Multiples Edens & Application Servers
optimizations
- Async Files / Async Streams (WIP)
- [VM] Writing tests for JIT generation with Guille (WIP)
- Checking large image problems.
- Improving crash reports of the VM in endless loops.


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

- [Port to Pharo 8] Traits in class side fix
- New iceberg release: Issue 1356
- [VM] Fix symbolic links in Pharo8 VM
- Fixing Package List / Categories in Calypso
- [VM] Fixing Tests in Idle.
- Adding a label to a PR when it has no test errors.
- [Pharo9] Propose a PR for Fuel to support Sista
- [Doc] Pass on VM booklet: Callback chapter / Preface
- [VM] Documenting GC, participating in the GC code dojo.
- [VM] SDL Plugin for Idle.
- [VM] Improving Speed of TFFI.
- [VM] REPL example  / Interacting with an image from outside (?)
- [PharoCOM] Making it run with TFFI.
- [VM] Writing tests for JIT generation
- [OSSubprocess] Integrate Pavel + Christophe windows version.
- [VM/Image] New version of Async Streams and use them with StdOut and StdErr

-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] Not seeing hidden character is confusing :)

[teso...@gmail.com]

Yes... We need to show something. At least in the code editor, when it is
clear we don't want them.

On Mon, Apr 13, 2020, 20:44 Stéphane Ducasse 
wrote:

> Hi
>
> I have the impression that we can introduce hidden characters
> while typing code and this is a problem to me because we do not see them :)
> I got for example selhiddenf and it can lead to strange situations.
>
> I will try to chase the key combinations that produce them and see how we
> can control and avoid this situation.
> If you find the key combination please let me know.
>
> S.
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr / http://www.pharo.org
> 03 59 35 87 52
> Assistant: Julie Jonas
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley,
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
>
>

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

[teso...@gmail.com]

### Last Week

- Fixing PRs to be integrated (Tonel / Spotter integration)
- Making space in Jenkins servers
- Reviewing PRs
- Crash when executing a Metacello from github in the minimal image
with the headless vm
- Adding tests to https://github.com/pharo-project/pharo/pull/6057
- Checking Moose generator error with Traits
- When everything integrated in the image, release of LargeImageSupport
- Fixing issue https://github.com/pharo-vcs/iceberg/issues/1356
- Fixing Spotter issue and removing the hiding of errors below the carpet.
- [VM] Improve the usage of Stdout and Stderr, in a correct way
- [VM] Writing tests for JIT generation
- Fixing flaky tests
- Writing documentation: Posts


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

- [PharoCOM] Pharo 7 errors.
- Port to Pharo 8: Traits in class side fix
- New iceberg release: Issue 1356
- [VM] Fix symbolic links in Pharo8 VM
- Improving the crash report of the VM
- Fixing Package List / Categories in Calypso
- [VM] Fixing Tests in Idle.
- Adding a label to a PR when it has no test errors.
- [VM] Check the crash dumps in an endless loop-

On Mon, Apr 6, 2020 at 9:59 AM Esteban Lorenzano  wrote:
>
> 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
>


-- 
Pablo Tesone.
teso...@gmail.com

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

[teso...@gmail.com]

### Last week:

- [IdleVM] Fixing the debugging of callbacks and non callbacks (with Esteban)
- [LargeImages] Improving Aleph indexes generation time
- [LargeImages] Documentation of Aleph, Spotter and the Large image
support baseline
- Reading and validating PRs
- [LargeImages] Working on improving the speed and responsiveness of
large images.
- [LargeImages] Creating Large Image baseline
- [LargeImages] Integrating new Spotter in the image
- [LargeImages] Integrating HeuristicCompletion in the image
- [LargeImages] Adding GCConfiguration to improve the generation of indexes.
- Consortium Organization Meeting
- VM Journal Club
- Fixing class side traits saving in Tonel
- Adding tests to Tonel
- Adding tests to Iceberg
- Fixing the issue
- Fixing problems in MCTraitDefinition and MCClassTraitDefinition
- New versions of Iceberg & Tonel
- PR to the image

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

- When everything integrated in the image, release of LargeImageSupport
- Improving crash report of the VM
- [VM] Check the crash dumps in an endless loop
- Crash when executing a Metacello from github in the minimal image
with the headless vm
- Fixing Package List / Categories in Calypso
- [VM] Fixing Tests in Idle.
- Adding a label to a PR when it has no test errors.
- [Pharo9] Propose a PR for Fuel to support Sista
- [VM] Fix symbolic links in Pharo8 VM

### The rest of my pipeline

- [Doc] Pass on VM booklet: Callback chapter / Preface
- [VM] Documenting GC, participating in the GC code dojo.
- [VM] SDL Plugin for Idle.
- [VM] Improving Speed of TFFI.
- [VM] REPL example  / Interacting with an image from outside (?)
- [PharoCOM] Making it run with TFFI.
- [VM] Writing tests for JIT generation
- [OSSubprocess] Integrate Pavel + Christophe windows version.
- [VM] Improve the usage of Stdout and Stderr, in a correct way


On Mon, Mar 30, 2020 at 10:28 AM Esteban Lorenzano  wrote:
>
> ### 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



-- 
Pablo Tesone.
teso...@gmail.com

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

[teso...@gmail.com]

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.

Cheers,
Pablo

On Mon, Mar 23, 2020 at 10:10 AM Vincent Blondeau via Pharo-dev
 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] (no subject)

[teso...@gmail.com]

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] (no subject)

[teso...@gmail.com]

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

Re: [Pharo-dev] Importing tonel files

[teso...@gmail.com]

Hi Javier,

You can use the URL with spec 'tonel://' to create a new Monticello
repository that uses Tonel.

For example:

   MCRepository fromUrl: 'tonel://path/to/my/directory'.
and then use it as a regular Monticello repository.
For example you can do:

((MCRepository fromUrl: 'tonel://path/to/my/directory')
versionFromFileNamed: 'PackageName')
 snapshot definitions

And will return all the definitions for the package.
Also, you can use it through the UI of Monticello.

Cheers,
Pablo

On Sun, Mar 22, 2020 at 5:05 AM Javier Pimás  wrote:
>
> Hi! Does anybody have at hand a one liner to load into Pharo a set of files 
> in tonel format? I have them in a directory without any git repo.
>
> Cheers,
> Javier



-- 
Pablo Tesone.
teso...@gmail.com

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

[teso...@gmail.com]

> Monday morning, time for the weekly mail meeting in 10 seconds!
> (just reply, inserting bullet points)
>
> ### Last week:

- Fixing Generator to correctly handle dead contexts.
- [LargeImages] Adding a name cache to RPackageOrganizer.
- 5840-FT2Error-reading-new-face-from-file
- [LargeImages] Integrating Spotter and Aleph indexes
- [LargeImages] Adding OptimizedTrie indexes to aleph
- Fixing MC with complex trait compositions in:
- Pharo 9
- Backport for Pharo 8
- Checking the work of Ronie
- [LargeImages] Improving Spotter
- Fixing Font lookup directories in Windows
- Exploring the performance issues of PharoCOM

>
>
> ### This week (starting 2020-03-16):
>
Something from here:

- Fixing Package List / Categories in Calypso
- Fixing Embedded Fonts Issue
- Adding a label to a PR when it has no test errors.
- [LargeImages] Implementing a better Spotter: Integrating indexes.
- [LargeImages] Implementing indexes in a reusable way.
- [Pharo9] Propose a PR for Fuel to support Sista
- [VM] Fixing Tests in Idle
- [Doc] Pass on VM booklet: Callback chapter / Preface
- [VM] Documenting GC, participating in the GC code dojo.
- [LargeImages] Working on improving the speed and responsiveness of
large images.
- [VM] SDL Plugin for Idle
- [VM] Improving Speed of TFFI
- [VM] REPL example  / Interacting with an image from outside (?)
- [PharoCOM] Making it run with TFFI
- [VM] Writing tests for JIT generation

On Mon, Mar 16, 2020 at 10:28 AM Esteban Lorenzano  wrote:
>
> ### 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).
>
>


-- 
Pablo Tesone.
teso...@gmail.com

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

[teso...@gmail.com]

### Last week:

- [Iceberg] Fixing after deprecations on Pharo 9
- [Iceberg] New release of Iceberg and inclusion in Pharo 9
- Fixing events in old Spec TextField
- Fixing Random test failures in Pharo9
- Fixing Categorization of tearDown in a test
- Fixing 5791-AbstractEnvironmentTestCase-logic-is-bogus
- Adding all the default processors to Spotter
- Adding Settings to Spotter
- Adding tests to Spotter
- Shout: make configurable the format Incomplete Identifiers, and tests
- Fix PR 5438-Finder-glitches
- Fix PR 5808: adding includingWith: , matching: and startingWith:
methodes. fixes #5437
- Adding an action to the Github API to add a label to a PR (WIP)
- Fixing problems with complex traits when saved with Tonel and Iceberg:
- Fix in Tonel
- Fix in Pharo
- New version of Tonel
- New version of Iceberg
- PR in Pharo

### This week (starting 2020-03-09), or the endless pipeline of stuff to fix:

- Fixing Embedded Fonts Issue
- Adding a label to a PR when it has no test errors.
- [LargeImages] Implementing a better Spotter: Integrating indexes.
- [LargeImages] Implementing indexes in a reusable way.
- [Pharo9] Propose a PR for Fuel to support Sista
- [VM] Fixing Tests in Idle
- [Doc] Pass on VM booklet: Callback chapter / Preface
- [VM] Documenting GC, participating in the GC code dojo.
- [LargeImages] Working on improving the speed and responsiveness of
large images.
- [VM] SDL Plugin for Idle
- [VM] Improving Speed of TFFI
- [VM] REPL example  / Interacting with an image from outside (?)
- [PharoCOM] Making it run with TFFI
- [VM] Writing tests for JIT generation

On Mon, Mar 9, 2020 at 10:43 AM Esteban Lorenzano  wrote:
>
> ### 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”
>
>


-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] Mystery solved: Pharo and Unsupported 16 bit application on Windows

[teso...@gmail.com]

Thanks for the analysis. It was a really complicated issue.

Maybe we need to add validation of the unzip files or a correct detection
of the unzip to use.

Thanks again.

On Wed, Mar 4, 2020, 19:52 Torsten Bergmann  wrote:

> Hi,
>
> just wanted to share this story of a Windows problem + possible cause so
> others could be aware:
>
>
> As Pablo announced a new VM version this week I used the VMManager within
> PharoLauncher to update the VM executables.
> Unfortunately afterwards several things got broken:
>
> When I started a fresh Pharo 9 image from Launcher the underlying Windows
> OS lamented about Pharo.exe being an "Unsupported 16 Bit application ..."
> leaving me with a big question mark.
>
>
> So I thought there is trouble within the new VM executable. But things got
> even more crazy when I deleted and redownloaded even fresh Pharo 8 and
> Pharo 7
> VMs and images using the Launcher. Same issue here - but I was totally
> sure that it worked before without any problem.
>
> I was not able to start ANY Pharo.exe version on this Windows machine
> anymore (except Launcher itself) - which was really mysterious. Even after
> reinstalling Pharo Launcher the problem did not go away.
>
> What I found strange was that on another second Windows machine it was
> working perfect - same combination of Launcher and any other.
> So I digged deeper in finding out.
>
>
> Meanwhile I know the difference:
>
>  - on the machine where it was not working I recently installed CYGWIN
> toolset to be able to compile the Pharo VM
>that means in the PATH environment I have an "unzip.exe" in
> d:\cygwin64\bin\unzip.exe
>
>  - I also activated the Unix subsystem for Windows (maybe that also gives
> a unzip.exe)
>
> As PharoLauncher typically checks if an unzip.exe is available and (if
> found) it is really using it to speed things up.
> Just evaluate
>
> PhLVirtualMachineManager canUseSytemZip
>
> in an PharoLauncher image. If it is not found it is using the regular
> "ZipArchive" class to extract - which is slower.
>
> So it looks like when the external "unzip.exe" from Cygwin (or possibly
> also others) are found and used then the CI built ZIPs of
> VM executables are not properly extracted and this leads to such effects
> of having a non-proper executable on Windows. The OS loader
> then thinks it is an old unsupported 16 bit application.
>
> Checking the version on command line for unzip exe tells me:
>
>UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.
>
> When I rename that executable I found another one telling me
>
>GNU which v2.20, Copyright (C) 1999 - 2008 Carlo Wood.
>
> A simple workaround is to enable developer mode in PharoLauncher and
> switching #canUseSytemZip to return false.
> Slower - but the Pharo code is more reliable here.
>
> Just wanted to let you know in case this problem (of which I heard several
> times already) is still on other peoples machine
> still unsolved or reappearing.
>
> Side note:
> =
> It is a little bit similar to what was found in
> https://github.com/pharo-project/pharo-launcher/issues/349
> but a side effect of having Cygwin and other providers of unzip.exe on
> your machine in combination with Pharo(Launcher).
>
>
> Have fun
> T.
>
>
>
>

Re: [Pharo-dev] New VM promoted to Stable for Pharo 8

[teso...@gmail.com]

It is the one of Feb 12th. My error in the mail.

On Tue, Mar 3, 2020, 19:08 tbrunz  wrote:

> Pablo, does this only affect Macs?  I just tried this on a Linux machine,
> updating/launching a Pharo 8 64-bit image.
>
> It still showed the older VM.  I tried restarting the VM Manager,
> restarting
> Pharo Launcher (1.9.2), and then re-installing Pharo Launcher, then
> creating
> a new image, each time trying everything again.
>
> But the version of the VM only ever says "2020-02-12", not "2020-02-20".
> When I tried the same thing for a 32-bit Pharo 8 image, it uses a VM dated
> "2020-02-06".
>
> What am I doing wrong?
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

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

[teso...@gmail.com]

A small resume of the tasks of the last week.

- [LargeImages] Improving the implementation of Trie in Containers:
- Splitting the node and collection objects
- Adding comments
- Improving tests
- [LargeImages] Adding an optimized version of Trie: having only nodes
if we have a split in the branches. It improves space usage, but it is a
little slower in the insertions.
- [LargeImages] Adding a suffix tree implementation using the
optimized Trie. It provides full-text search.
- [LargeImages] Implementing an index for Spotter using the suffix
tree and the composition algebra.
- [LargeImages] Working with Esteban in the Indexes generation and a
common way of generating the indexes required for Large images.
- Pharo Sprint:
 - Fixing issues on tests
 - Extracting Pharo8 deprecated methods from Pharo9


 The pipeline a.k.a the infinite list from we choose what to
do (starting 2020-03-02):

- [LargeImages] Implementing a better Spotter: Integrating indexes.
- [LargeImages] Implementing indexes in a reusable way.
- [Pharo9] Propose a PR for Fuel to support Sista
- [VM] Fixing Tests in Idle
- [Doc] Pass on VM booklet: Callback chapter / Preface
- [VM] Documenting GC, participating in the GC code dojo.
- [LargeImages] Working on improving the speed and responsiveness of
large images.
- [VM] SDL Plugin for Idle
- [VM] Improving Speed of TFFI
- [VM] REPL example  / Interacting with an image from outside (?)
- [PharoCOM] Making it run with TFFI
- [VM] Writing tests for JIT generation

-- 
Pablo Tesone.
teso...@gmail.com

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

[teso...@gmail.com]

A small resume of the tasks of the last week.

- [LargeImages] Implementing a better Spotter:
  - Adding a backend using generators and a combination of generators
  - Adding a query reification to handle more complex queries
  - Adding a visual loading indication
  - Measuring the impact of the changes
  - Adding a help bar with tips
  - Adding tests.
  - Analyzing possible indexes
  - Reading about Non-Blocking queues.
- [VM] Documenting GC, participating in the GC code dojo.

 ### The pipeline a.k.a the infinite list from we choose what to
do (starting 2020-02-24):

- Checking speed issues in Rubric.
- [LargeImages] Implementing a better Spotter
- [Pharo9] Propose a PR for Fuel to support Sista
- [VM] Fixing Tests in Idle
- [Doc] Pass on VM booklet: Callback chapter / Preface
- [VM] Documenting GC, participating in the GC code dojo.
- [LargeImages] Working on improving the speed and responsiveness of
large images.
- [VM] SDL Plugin for Idle
- [VM] Improving Speed of TFFI
- [VM] REPL example  / Interacting with an image from outside (?)
- [PharoCOM] Making it run with TFFI
- [VM] Writing tests for JIT generation

-- 
Pablo Tesone.
teso...@gmail.com

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

[teso...@gmail.com]

### Last week:

- [VM Idle] Fixing a deadlock when using sockets with the main thread worker
- [Doc] Pass on FFI booklet: Callback chapter / Preface
- [LargeImage] Remove Pragma from the menu of SystemWindows
- [LargeImage] Remove Pragma from the menus of ProcessBrowser
- [VM] Fix Travis build for Pharo-Project
- [VM] Promote to stable a new VM for Pharo 9: Including GC fix / Float fix
- Matteo presentation.
- [LargeImages] Reimplementing a faster Spotter backend (classes /
implementors / packages)
- [LargeImages] Removing useless Processors

### This week (starting 2020-02-17) (a.k.a. pipeline)

- [Pharo9] Propose a PR for Fuel to support Sista
- [VM] Fixing Tests in Idle
- [Doc] Pass on VM booklet: Callback chapter / Preface
- [VM] Documenting GC, participating in the GC code dojo.
- [LargeImages] Working on improving the speed and responsiveness of
large images.
- [VM] SDL Plugin for Idle
- [VM] Improving Speed of TFFI
- [VM] REPL example  / Interacting with an image from outside (?)
- [PharoCOM] Making it run with TFFI
- [VM] Writing tests for JIT generation

-- 
Pablo Tesone.
teso...@gmail.com

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

[teso...@gmail.com]

It's under construction, but here it is
https://github.com/pharo-project/opensmalltalk-vm/wiki

On Mon, Feb 10, 2020 at 10:46 AM Alistair Grant  wrote:
>
> Hi Pablo,
>
>
> On Mon, 10 Feb 2020 at 10:31, teso...@gmail.com  wrote:
> >
> >  Monday morning, time for the weekly mail meeting in 10 seconds!
> >  (just reply, inserting bullet points)
> >
> >  ### Last week:
> >
> > - PharoVM wiki
>
> Is this publicly accessible?  Can we have a link?
>
> Thanks!
> Alistair
>


-- 
Pablo Tesone.
teso...@gmail.com

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

[teso...@gmail.com]

 Monday morning, time for the weekly mail meeting in 10 seconds!
 (just reply, inserting bullet points)

 ### Last week:

- PharoVM wiki
- [Idle VM] Fix Allocation problem in Linux with MMAP
- [TFFI] Fixing the build for use a given VM, so we can have different versions
- [TFFI] Adding another development branch
- [Pharo9] Retaking the Sista bytecode recompilation PR
- [Idle VM] Make the idle VM uses the Pthread plugin supporting the
main thread scheduling.
- [PharoCOM] Making it work in 32 / 64 bits Pharo 8
- [PharoCOM] Making extensions for using Access API
- Compiling VM for Linux in Ubuntu 18.03
- [Doc] Pass on VM booklet: Callback chapter
- [LargeImages] Working on image generation
- [LargeImages] Improving Speed of senders and implementors.

### This week (starting 2020-02-10), a.k.a the pipeline:

- [Pharo9] Propose a PR for Fuel to support Sista
- [VM] Fixing Tests in Idle
- [Doc] Pass on VM booklet: Callback chapter / Preface
- [VM] Documenting GC, participating in the GC code dojo.
- [LargeImages] Working on improving the speed and responsiveness of
large images.
- [VM] SDL Plugin for Idle
- [VM] Improving Speed of TFFI
- [VM] REPL example  / Interacting with an image from outside (?)
- [PharoCOM] Fixing Pharo COM for Pharo8’s UFFI
- [PharoCOM] Making it run with TFFI
- [VM] Writing tests for JIT generation
- [VM] Promote VM a Stable

-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] methods not registered in packages?

[teso...@gmail.com]

Hi Doru,
  thanks for checking this behavior. Those methods are not correctly
packaged because those are methods added from a trait.  Nowadays,
#methods returns all the methods in the class (the ones defined in the
class and the ones defined in the used traits) and #localMethods
returns the methods defined only in the class.

I think it is a good issue to open so we can discuss which is the best
API for it. Maybe the existing one is not good. To me, #methods should
not return all the methods from the method dictionary or we have to
encourage to use the #localMethods where #methods is used.
I am not sure about what is the answer, so the issue to discuss will be perfect.

Cheers,
Pablo

On Sun, Feb 9, 2020 at 8:16 AM Tudor Girba  wrote:
>
> Hi,
>
> While trying to measure the size of code, I stumbled across an interesting 
> problem: it seems that some methods have a package, but the package does not 
> list.
>
> packagedMethods := RPackageOrganizer default packages flatCollect: #methods.
> methods := ProtoObject withAllSubclasses flatCollect: #methods.
> diff := methods \ packagedMethods.
> diff size.
> “7249"
>
> Looking at bit closer, it looks like the methods do have a package and that 
> they point to the package that is in the package organizer, so that is good:
>
> diff select: [ :each | each package isNil ]
> "an OrderedCollection()".
>
> diff select: [ :each | (RPackageOrganizer default packages includes: each 
> package) not ].
> "an OrderedCollection()”
>
> However, when we ask the package, it does not know about the method:
>
> diff select: [ :each | each package methods includes: each ]
> "an OrderedCollection()”
>
>
> Is this a known problem or should I open an issue (I did not find a bug 
> report for it)?
>
>
> Cheers,
> Doru
>
>
> --
> feenk.com
>
> "Presenting is storytelling."
>
>


-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] PR without Tests

[teso...@gmail.com]

Of course, the already open PR are there, and it is ok, we can handle them.

On Thu, Feb 6, 2020 at 10:29 AM teso...@gmail.com  wrote:
>
> Hello,
>Pharo is not Smalltalk / Smalltalk is not Pharo / Pharo is Smalltalk.
> Now that I have your attention because it seems the only read mail has
> to have this.
>
> We have to continue improving the quality of Pharo. One of the biggest
> assets that we have in Pharo are the tons of tests. So, we need to
> reject any PR that does not have tests or it is not already tested.
>
> To ease this quality measure, please add some comments on the PR about
> how your new code or modified code is tested or benchmarked.
>
> Cheers.
>
> --
> Pablo Tesone.
> teso...@gmail.com



-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] PR without Tests

[teso...@gmail.com]

Hello,
   Pharo is not Smalltalk / Smalltalk is not Pharo / Pharo is Smalltalk.
Now that I have your attention because it seems the only read mail has
to have this.

We have to continue improving the quality of Pharo. One of the biggest
assets that we have in Pharo are the tons of tests. So, we need to
reject any PR that does not have tests or it is not already tested.

To ease this quality measure, please add some comments on the PR about
how your new code or modified code is tested or benchmarked.

Cheers.

-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] [ANN] New Headless VM (Still Alpha, but getting better)

[teso...@gmail.com]

Yes... it is basically the same version... maybe I should change the
version to 9

On Mon, Feb 3, 2020 at 4:06 PM Damien Pollet  wrote:
>
> just tried it (from get.pharo.org/64/vmHeadlessLatest90), but the VM I get 
> says this:
> ./pharo --version
> Pharo 8.2.0 built on Dec 25 2019 …
>
> On Tue, 28 Jan 2020 at 10:35, teso...@gmail.com  wrote:
>>
>> A new version of the headless VM is available.
>>
>> It can be downloaded from:
>>
>> https://files.pharo.org/vm/pharo-spur64-headless/win/PharoVM-8.3.0-b612fd5f-win64-bin.zip
>> https://files.pharo.org/vm/pharo-spur64-headless/linux/PharoVM-8.3.0-b612fd5-linux64-bin.zip
>> https://files.pharo.org/vm/pharo-spur64-headless/mac/PharoVM-8.3.0-b612fd5-mac64-bin.zip
>>
>> Or more easily using ZeroConf:
>>
>> With the image
>> $ wget -O - get.pharo.org/64/90+vmHeadlessLatest | bash
>>
>> Without
>> $ wget -O - get.pharo.org/64/vmHeadlessLatest90 | bash
>>
>> This new version has a series of bugfixes and the following features:
>>
>> - Update TFFI to v1.2.0: Allowing better marshaling and callbacks from
>> outside threads.
>> - Update README.md
>> - Add instructions on how to create a vmmaker image.
>> - Fixing UnixOSProcessPlugin
>> - Redefinition of squeakFileOffset
>> - Generating include files as an artifact
>> - Adding a configurable strategy for reading / writing the image
>> - Building using Musl Libc
>> - A cleaner implementation of the print to stdout and file.
>> - OSX File Dialog
>> - OSX icon customization
>> - OSX customization for apps.
>> - Adding build on GitHub actions
>>
>> I will like to thank all the contributors specially Guille, Esteban,
>> Ronnie. And also, Feenk and Schmidt that they are using it, reporting
>> issues and contributing.
>>
>> Just a friendly reminder, if you want to contribute, you are always welcome!!
>>
>> https://github.com/pharo-project/opensmalltalk-vm
>>
>> Cheers,
>> Pablo
>>
>> --
>> Pablo Tesone.
>> teso...@gmail.com
>>
>
>
> --
> Damien Pollet
> type less, do more [ | ] http://people.untyped.org/damien.pollet



-- 
Pablo Tesone.
teso...@gmail.com

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

[teso...@gmail.com]

### Last week:

- [Callbacks] Fixing Deadlock when a callback is executed from a
different thread.
- [TFFI] Release of a new version
- [Headless] Release of a new version.
- [LargeImages] Image Generator packaging and publication.
- [DOC] PharoVM wiki
- [FOSDEM] Bootstrap Presentation for FOSDEM
- Pharo Sprint
- [VM] Documenting GC, participating in the GC code dojo.
- [TFFI] Adding Callback info to the Callbacks to improve debugging in
ThreadedFFI
- [FOSDEM] Preparation of Material to distribute & things to carry
- [FOSDEM] Presentations and stand exposition.
- [VM] Talking about OpenBuildServices (https://openbuildservice.org/)

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

- [VM] Fixing Tests in Idle
- [Doc] Pass on VM booklet: Callback chapter / Preface
- [VM] Documenting GC, participating in the GC code dojo.
- [LargeImages] Working on improving the speed and responsiveness of
large images.
- [VM] SDL Plugin for Idle
- [VM] Improving Speed of TFFI
- [VM] REPL example  / Interacting with an image from outside (?)
- [PharoCOM] Fixing Pharo COM for Pharo8’s UFFI
- [PharoCOM] Making it run with TFFI
- [VM] Writing tests for JIT generation
- [Diffusion] FOSDEM preparation: material, trip organization, presentations
- [VM] Promote VM a Stable

-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] New Latest VM - Please Test

[teso...@gmail.com]

Hi Alistair,
thank you for testing it, I will try to generate a version for
older glibc as soon it does not produce a problem with newer versions.

This is an interesting subject to discuss and see what is better for
our community.
Nowadays, we are centering in producing executable versions for Debian
based distributions (especially Ubuntu).
We have to decide which are the platforms we are going to support
directly generating binaries distributions and what only through
support in source code.

Having more and more versions and different building environments
requires also to have matching testing scenarios and the effort to
maintain them.

As usual, we have limited resources and we have to decide where to put
the efforts. If there are special interests in a given platform it
will be nice to know that (and also if you use it and can, please
think about how to collaborate with the efforts done by the
consortium).

Also, I will like to discuss this subject as choosing Debian / Ubuntu
is just a casualty and we need to have a thought decision.

Cheers

On Sat, Feb 1, 2020 at 8:33 AM Alistair Grant  wrote:
>
> Hi Pablo,
>
> This VM looks like it will only run with Ubuntu 19.04 or later:
>
> $ ./pharo --version
> /dev/shm/p8/pharo-vm/lib/pharo/5.0-/pharo:
> /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found
> (required by /dev/shm/p8/pharo-vm/lib/pharo/5.0-/pharo)
>
> GLIBC 2.29 is delivered with Ubuntu 19.04.
>
> Ubuntu 18.04 is the current LTS (GLIBC 2.27), and Ubuntu 16.04 is
> still supported (GLIBC 2.23), so I'd expect that the VM is linked
> against 2.23, or at least 2.27.
>
> Cheers,
> Alistair
>
>
> > > Am 19.01.2020 um 19:10 schrieb teso...@gmail.com:
> > >
> > > You are right Norbert, sorry I miss the data.
> > > This is available through zeroConf.
> > > Doing for example:
> > >
> > > wget -O - get.pharo.org/64/70+vmLatest | bash
> > > wget -O - get.pharo.org/64/80+vmLatest | bash
> > >
> > > Cheers,
> > > Pablo
>


-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] [ANN] New Headless VM (Still Alpha, but getting better)

[teso...@gmail.com]

A new version of the headless VM is available.

It can be downloaded from:

https://files.pharo.org/vm/pharo-spur64-headless/win/PharoVM-8.3.0-b612fd5f-win64-bin.zip
https://files.pharo.org/vm/pharo-spur64-headless/linux/PharoVM-8.3.0-b612fd5-linux64-bin.zip
https://files.pharo.org/vm/pharo-spur64-headless/mac/PharoVM-8.3.0-b612fd5-mac64-bin.zip

Or more easily using ZeroConf:

With the image
$ wget -O - get.pharo.org/64/90+vmHeadlessLatest | bash

Without
$ wget -O - get.pharo.org/64/vmHeadlessLatest90 | bash

This new version has a series of bugfixes and the following features:

- Update TFFI to v1.2.0: Allowing better marshaling and callbacks from
outside threads.
- Update README.md
- Add instructions on how to create a vmmaker image.
- Fixing UnixOSProcessPlugin
- Redefinition of squeakFileOffset
- Generating include files as an artifact
- Adding a configurable strategy for reading / writing the image
- Building using Musl Libc
- A cleaner implementation of the print to stdout and file.
- OSX File Dialog
- OSX icon customization
- OSX customization for apps.
- Adding build on GitHub actions

I will like to thank all the contributors specially Guille, Esteban,
Ronnie. And also, Feenk and Schmidt that they are using it, reporting
issues and contributing.

Just a friendly reminder, if you want to contribute, you are always welcome!!

https://github.com/pharo-project/opensmalltalk-vm

Cheers,
Pablo

-- 
Pablo Tesone.
teso...@gmail.com

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

[teso...@gmail.com]

### Last week:

- [Diffussion] Preparing Material for FOSDEM
- [Doc] Adding type Table to uFFI booklet
- [Pharo9] Running Bootstrap and tests in 64 bits
- [Spotter] Add a setting to limit the number of results in Spotter
- [Doc] Techtalk Iceberg
- [VM] Documenting GC, participating in the GC code dojo.
- [Large Images] Making Battle Plan with Esteban
- [Large Images]
5562-Executing-All-Instances-in-the-startup-affects-loading-times
- [Callbacks] Helping Schmidt to use TFFI Callbacks
- [Callbacks] Detection of a deadlock when calling callbacks from a
different thread while the VM is running.
- [Pharo9] Fixing #5571 - Color settings should have default values


### This week (starting 2020-01-27):

- [VM] Fixing Tests in Idle
- [VM] Documenting GC, participating in the GC code dojo.
- [VM] SDL Plugin for Idle
- [VM] Improving Speed of TFFI
- [VM] REPL example (?)
- [VM] Writing tests for JIT generation
- [Diffusion] FOSDEM preparation: material, trip organization, presentations
- [Callbacks] Fixing Deadlock when a callback is executed from a
different thread.
- [Doc] Pass on VM booklet: Callback chapter / Preface
- [LargeImages] Working on improving the speed and responsiveness of
large images.

-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] [TechTalk] Contributing to External Projects with Iceberg

[teso...@gmail.com]

Hi,
I am sending the link of the video of today techtalk, maybe can be
useful for someone.

https://youtu.be/-jenQJp5m2U

Cheers,
Pablo

-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] Fwd: [GitHub] Deprecation Notice

[teso...@gmail.com]

Yes, it is the PR creation API. I have started to add support to
tokens in a nice way. I can push it to the next version.

On Wed, Jan 22, 2020 at 9:55 AM ducasse  wrote:
>
>
>
> > On 22 Jan 2020, at 09:48, Guillermo Polito  
> > wrote:
> >
> > Did you re-clone your repository? I don’t think so…
>
> no
>
> > Did you create a PR using Pharo’s github integration?
>
> Yes I did this.
>
> > Those are the only points we use Github’s API :/
> Ok we found it :)
>
>
> >
> >> El 22 ene 2020, a las 9:13, ducasse  escribió:
> >>
> >> I was just committing to my pharo fork “….using Zinc HTTP Components 1.0 
> >> (Pharo/9.0) ...”
> >> so I do not get fully get it.
> >> If I’m the only one to receive this mail then this is ok
> >>
> >> Guille apparently I used password else it would have failed? Can it be 
> >> that my password is not well set?
> >>
> >> I have hte impression that they mean something else.
> >>
> >>  "We will deprecate basic authentication using password”
> >>
> >> S
> >>
> >>> On 22 Jan 2020, at 07:47, Guillermo Polito  
> >>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I believe that when cloning a repository using the Github tab from 
> >>> iceberg, iceberg makes a request to ask github for that project’s 
> >>> meta-data.
> >>> This query identifies if the cloned repository is a fork of another 
> >>> repository or not, and in case it is a fork, correctly pre-configure the 
> >>> repository remotes to simplify further operations (such as fetching from 
> >>> upstream, or creating pull requests in-image).
> >>>
> >>> If user credentials are not available, such request is anonymous.
> >>> However, if user credentials **are** available, they are used => this is 
> >>> required for private projects to work.
> >>>
> >>> One possible solution would be to add a new kind of credentials 
> >>> Token-based, to existing ones (passwords also used for https, ssh key 
> >>> pairs).
> >>>
> >>>> El 22 ene 2020, a las 7:34, Sven Van Caekenberghe  
> >>>> escribió:
> >>>>
> >>>> We probably have to change something.
> >>>>
> >>>> Do you know which operation (GitHub API access from Pharo code) is 
> >>>> responsible for this ?
> >>>>
> >>>>> On 21 Jan 2020, at 21:05, ducasse  wrote:
> >>>>>
> >>>>> what will be the implication?
> >>>>>
> >>>>>
> >>>>>> Begin forwarded message:
> >>>>>>
> >>>>>> From: GitHub 
> >>>>>> Subject: [GitHub] Deprecation Notice
> >>>>>> Date: 21 January 2020 at 21:03:28 CET
> >>>>>> To: StéphaneDucasse 
> >>>>>>
> >>>>>> Hi @Ducasse,
> >>>>>>
> >>>>>> You recently used a password to access an endpoint through the GitHub 
> >>>>>> API using Zinc HTTP Components 1.0 (Pharo/9.0). We will deprecate 
> >>>>>> basic authentication using password to this endpoint soon:
> >>>>>>
> >>>>>> https://api.github.com/repositories/169849137
> >>>>>>
> >>>>>> We recommend using a personal access token (PAT) with the appropriate 
> >>>>>> scope to access this endpoint instead. Visit 
> >>>>>> https://github.com/settings/tokens for more information.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> The GitHub Team
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >
> >
>
>
>


-- 
Pablo Tesone.
teso...@gmail.com

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

[teso...@gmail.com]

### Last week:

- Fix Issue #5434: Settings
- Fix Issue #5474: Logging messages with Metacello
- Fix Issue #5481: Metacello-logs-now-prints-lots-of-new-lines
- [VM] Example of branding VM and signed image in OSX / Win32
- [VM] Improving the Documentation of the PharoVM repository.
- [Doc] Pass on the uFFI booklet (Chapters 1 & 2)
- Traits Paper
- Deadlock in Idle (Windows)
- [Pharo8] Buffer error in Sources. Check a problem with large
installations and the changes files
- [VM] Documenting GC, participating in the GC code dojo.
- [VM] Deadlock in Idle (Unix) (MMap location)
- [VM] Uploading Latest VM for Pharo 7/8/9
- [Pharo8] Fixing broken tests in Enlumineur
- [Pharo8] Integrating a preview of Enlumineur (not available by default)
- [Iceberg] New release of Iceberg (v1.6.5):
- Speed improvements for loading bigger packages
- Local directory relative repositories
- Fixes in the Edit project dialog
- Adding default values to system settings.
- Adding Generic git repository in Metacello.
- [Release] Prepare release notes
- [Release] Prepare release mail
- [Release] Organise issues that will enter in P8.
- [FFI] Check FFI changes by Guille
- Add Pharo9 to SmalltalkCI

### This week (idea):

- [VM] Fixing Tests in Idle
- [Doc] Adding type Table to uFFI booklet
- [Doc] Pass on VM booklet
- [VM] SDL Plugin for Idle
- [VM] Documenting GC, participating in the GC code dojo.
- [VM] Improving Speed of TFFI
- [VM] Writing tests for JIT generation
- [Doc] Techtalk Iceberg
- FOSDEM preparation


-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] New Latest VM - Please Test

[teso...@gmail.com]

You are right Norbert, sorry I miss the data.
This is available through zeroConf.
Doing for example:

wget -O - get.pharo.org/64/70+vmLatest | bash
wget -O - get.pharo.org/64/80+vmLatest | bash

Cheers,
Pablo

On Sat, Jan 18, 2020 at 7:53 AM Norbert Hartl  wrote:
>
> Just a short remark. If you announce something it is good to say how to get 
> it. What seems obvious to you is not necessarily obvious for others.
>
> Norbert
>
> > Am 17.01.2020 um 10:49 schrieb "teso...@gmail.com" :
> >
> > Hello,
> >  I have just uploaded a new version of the VM as the latest. This
> > version is the one to be intended for Pharo 8 release. Please feel
> > free to test it.
> >
> > Changes:
> >
> > - Fix in the GC corruption error
> >
> > Thanks.
> >
> > --
> > Pablo Tesone.
> > teso...@gmail.com
> >
>
>


-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] New Latest VM - Please Test

[teso...@gmail.com]

Hi Pierce,
   it has been built from the branch dev-7 of
https://github.com/pharo-project/opensmalltalk-vm.git
We have integrated the changes in the GC and some other bug fixing.
But we started from the latest stable Pharo 7 version, as we need to
keep compatibility with OSX pre-metal.

Cheers,
Pablo

On Fri, Jan 17, 2020 at 2:17 PM Pierce Ng  wrote:
>
> On Fri, Jan 17, 2020 at 10:48:02AM +0100, teso...@gmail.com wrote:
> >   I have just uploaded a new version of the VM as the latest. This
> > version is the one to be intended for Pharo 8 release. Please feel
> > free to test it.
>
> Hi Pablo,
>
> Is this VM built from https://github.com/pharo-project/opensmalltalk-vm.git
> or upstream?
>
> Pierce
>
>


-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] New Latest VM - Please Test

[teso...@gmail.com]

Hello,
  I have just uploaded a new version of the VM as the latest. This
version is the one to be intended for Pharo 8 release. Please feel
free to test it.

Changes:

- Fix in the GC corruption error

Thanks.

-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] [ANN] Embedding Image Example (Win)

[teso...@gmail.com]

Hi,
   I have produced an example of using the headless VM to have an
embedded image in Windows. The example is hosted in Github
(https://github.com/tesonep/pharo-vm-embedded-example)

The example is a CMake project to generate a new small executable that
uses the VM as a library. Also, it shows how to perform the branding
of applications (I have used the same Pharo icon, but we can use
anything else).

In the example, I am opening one of the SDL2 examples, it opens a
window where we can draw in an Athens Canvas.

It requires a Cygwin environment, but if you are able to build the
headless VM you already have it!.

I will do other examples of the use case we are thinking for the headless VM!

Cheers,
Pablo

-- 
Pablo Tesone.
teso...@gmail.com

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

[teso...@gmail.com]

### Last week:

- [Release] Fixing issues with the system settings and how they are stored.
- Consortium Meeting
- [VM] Example of Embedding images using the headless VM in Win32
(https://github.com/tesonep/pharo-vm-embedded-example)
- [VM] Preparing VM Release
- [VM] Documenting GC, participating in the GC code dojo.
- [VM] Writing tests for JIT generation
- [VM] Fixing deadlocks in Idle VM

### This Week

- [VM] Example of branding VM and signed image in OSX / Win32
- [Release] Organise issues that will enter in P8.
- [Release] Prepare release notes
- [Release] Check a problem with large installations and the changes files
- [VM] Documenting GC, participating in the GC code dojo.
- [VM] Writing tests for JIT generation
- [VM] Continue improving Idle VM




-- 
Pablo Tesone.
teso...@gmail.com

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

[teso...@gmail.com]

Hello, last week was a short one but some things have been done:

- [VM] Porting the GC fix to Pharo 7 / 8 VM
- [VM] Building for the different Platforms
- [VM] Signing for OSX
- [VM] The versions will be available today to start testing it before
promoting them to stable.
- [Pharo8] Fixing Issues before the release
- [VM Dev] Starting to work in improving tests in JIT and GC.

-- 
Pablo Tesone.
teso...@gmail.com

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

[teso...@gmail.com]

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.

- (Pair Programming with Esteban) Fixing a glitch in GTK with the
keyboard input and event handling when the GTK windows opened by Spec2
is the topmost of the application

- Detection and fix of the GCC 8.3+ optimization glitch that prevented
the built of the VM in newer Linux distributions.

- Another iteration on the FreeTypeFont glitch issue.

- Detecting all the requirements to use the Sista bytecode in the
default image. This modification requires some changes in Fuel. There
is a need for more changes in the debugger if we want to integrate
full block closures.

- Fixing small issues and reviewing PR for Pharo8

- Supporting Students in their modifications of the VM and experiments
they are doing (Theo & Pierre here in Lille, and Federico in Buenos
Aires): if you have problems just call :D.

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

- Pushing Pharo 8 release (Release Notes / PR / fixes)

- Adding tests to the interruptable AIO and main thread worker of the
headless VM.

- Clean-up of code of the VM to allow to compile with MUSL and
different libc implementations. This will allow us to run in Alpine
Linux, improving the experience of Pharo running in containers. For
doing so the correct way is to extend the debugging functions to allow
different streams and outputs (today it is done through a hack, so we
have to keep the behavior but implemented in a way that does not break
the encapsulation of libc).

- Working on GC tests with Guille.

On Mon, Dec 16, 2019 at 11:00 AM Esteban Lorenzano  wrote:
>
> ### 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.
>


-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] Debugging GCC code generation

[teso...@gmail.com]

Hi Nicolas,
  thanks for the comment, you are right the problem is the bad
original code. But my opinion is that it just is not reporting the
situation correctly, generating a warning or non-optimizing the code
looks more like a expected behavior. Because as I have said, using a
constant as index in the last statement generates a meaningful warning
and the non-optimizated version of the function.

And again as you said, the only thing to learn about all this is that
we should not write crappy code.

On Wed, Dec 11, 2019 at 7:11 PM Nicolas Cellier
 wrote:
>
> Of course, when I say "your" code, it's the code you have shown, and probably 
> "our" (VMMaker) code ;)
>
> Le mer. 11 déc. 2019 à 19:05, Nicolas Cellier 
>  a écrit :
>>
>> Hi Pablo (again),
>> no, not a bug.
>>
>> The problem is in the source code. The compiler has the right to presume 
>> that your code is exempt of UB, because you cannot depend on UB (obviously).
>> So it can eliminate all code which corresponds to UB.
>>
>> The compiler has the right to assume that a pointer to an int cannot point 
>> to a long (UB).
>> So modifying a long cannot have any sort of impact on the content of the int 
>> pointer.
>> So the compiler can decouple both path return int content and assign long.
>> But assigning the long has no effect, so the code can be suppressed 
>> altogether.
>>
>> Le mer. 11 déc. 2019 à 18:54, teso...@gmail.com  a écrit :
>>>
>>> Hi Aliaksei,
>>>   to me it looks like a bug of GCC optimization. Basically, it is
>>> assuming that the x variable is used but never read or its value is
>>> never used. Also it assumes the same of the i variable, as we are only
>>> accessing indirectly to the memory where it locates (the code is even
>>> assuming that the variable exists, but it can be optimize out as in
>>> this scenario). Even though, the original C code is valid C code, we
>>> are not helping the compiler writing code like that. So I have
>>> rewritten the code in a way that does not use indirect memory access
>>> to the stack space.
>>>
>>> One thing more that makes me think is a bug, if you use an int
>>> constant as the index and not a parameter, the error does not occur
>>> (the code is not badly optimized) and there is a warning about the
>>> not-so-great access to the stack.
>>>
>>> On Wed, Dec 11, 2019 at 6:01 PM Aliaksei Syrel  wrote:
>>> >
>>> > Hi Pablo,
>>> >
>>> > Wow! Thank you for the detective story :)
>>> >
>>> > Do I understand correctly that the original code causes undefined 
>>> > behavior and therefore can be changed (or even removed) by the compiler?
>>> > (because it returns something that is referencing memory on the stack)
>>> >
>>> > Please keep posting similar things in future! It is very educative :)
>>> >
>>> > Cheers,
>>> > Alex
>>> >
>>> >
>>> > On Wed, 11 Dec 2019 at 17:35, teso...@gmail.com  wrote:
>>> >>
>>> >> Hi,
>>> >> this mail is related to Pharo because it is knowledge I found
>>> >> debugging the build of the VM, but the rest is to document it and
>>> >> perhaps someone will found it interesting (also I couldn't find it
>>> >> easily using Google). Sorry for the long mail!
>>> >>
>>> >> The problem
>>> >> ==
>>> >>
>>> >> The following code does not produce good code in 8.3 when using 
>>> >> optimizations:
>>> >>
>>> >> long __attribute__ ((noinline)) myFunc(long i, int index){
>>> >>long v;
>>> >>long x = i >> 3;
>>> >>
>>> >>v = x;
>>> >>return ((int*)())[index];
>>> >> }
>>> >>
>>> >> #include 
>>> >>
>>> >> int main(){
>>> >>
>>> >> long i;
>>> >> int x;
>>> >>
>>> >> scanf("%ld", );
>>> >> scanf("%d", );
>>> >>
>>> >> printf("%ld",myFunc(i,x));
>>> >> }
>>> >>
>>> >> Basically, with -02, it generates the following code:
>>> >>
>>> >> myFunc:
>>> >>  movslq %esi, %rsi
>>> >>  movslq -8(%rsp,%rsi,4), %rax
>>> >>  ret
>

Re: [Pharo-dev] Debugging GCC code generation

[teso...@gmail.com]

Hi Aliaksei,
  to me it looks like a bug of GCC optimization. Basically, it is
assuming that the x variable is used but never read or its value is
never used. Also it assumes the same of the i variable, as we are only
accessing indirectly to the memory where it locates (the code is even
assuming that the variable exists, but it can be optimize out as in
this scenario). Even though, the original C code is valid C code, we
are not helping the compiler writing code like that. So I have
rewritten the code in a way that does not use indirect memory access
to the stack space.

One thing more that makes me think is a bug, if you use an int
constant as the index and not a parameter, the error does not occur
(the code is not badly optimized) and there is a warning about the
not-so-great access to the stack.

On Wed, Dec 11, 2019 at 6:01 PM Aliaksei Syrel  wrote:
>
> Hi Pablo,
>
> Wow! Thank you for the detective story :)
>
> Do I understand correctly that the original code causes undefined behavior 
> and therefore can be changed (or even removed) by the compiler?
> (because it returns something that is referencing memory on the stack)
>
> Please keep posting similar things in future! It is very educative :)
>
> Cheers,
> Alex
>
>
> On Wed, 11 Dec 2019 at 17:35, teso...@gmail.com  wrote:
>>
>> Hi,
>> this mail is related to Pharo because it is knowledge I found
>> debugging the build of the VM, but the rest is to document it and
>> perhaps someone will found it interesting (also I couldn't find it
>> easily using Google). Sorry for the long mail!
>>
>> The problem
>> ==
>>
>> The following code does not produce good code in 8.3 when using 
>> optimizations:
>>
>> long __attribute__ ((noinline)) myFunc(long i, int index){
>>long v;
>>long x = i >> 3;
>>
>>v = x;
>>return ((int*)())[index];
>> }
>>
>> #include 
>>
>> int main(){
>>
>> long i;
>> int x;
>>
>> scanf("%ld", );
>> scanf("%d", );
>>
>> printf("%ld",myFunc(i,x));
>> }
>>
>> Basically, with -02, it generates the following code:
>>
>> myFunc:
>>  movslq %esi, %rsi
>>  movslq -8(%rsp,%rsi,4), %rax
>>  ret
>>
>> And with -01 it generates the following code:
>>
>> myFunc:
>>  sarq $3, %rdi
>>  movq %rdi, -8(%rsp)
>>  movslq %esi, %rsi
>>  movslq -8(%rsp,%rsi,4), %rax
>>  ret
>>
>> As you can see, the more optimized version is losing the bit shift (or
>> any other operation).
>> To detect the problem it was not easy, basically, I have used the
>> Pharo Tests to detect the failing function and then to understand the
>> generation of code in GCC, we need to debug its generation.
>>
>> The first snippet is generated using:
>>
>> gcc -O2 prb.c -S -o prb.s -Wall
>>
>> and the second using:
>>
>> gcc -O1 prb.c -S -o prb.s -Wall
>>
>> The GCC pipeline has different steps, I have centered my self in the
>> tree optimizations.
>> GCC dumps each of the intermediate states of the compilation, working
>> with C like trees. For example to get the optimized version of the
>> program, before generating the Assembler we have to do:
>>
>> gcc -O2 prb.c -S -o prb.s -Wall -fdump-tree-optimized=/dev/stdout
>>
>> This will generate:
>>
>> __attribute__((noinline))
>> myFunc (long int i, int index)
>> {
>>   long int v;
>>   long unsigned int _1;
>>   long unsigned int _2;
>>   int * _3;
>>   int _4;
>>   long int _8;
>>
>>[local count: 1073741825]:
>>   _1 = (long unsigned int) index_7(D);
>>   _2 = _1 * 4;
>>   _3 =  + _2;
>>   _4 = *_3;
>>   _8 = (long int) _4;
>>   v ={v} {CLOBBER};
>>   return _8;
>>
>> }
>>
>> This is the optimized SSA (static single assign) version of the
>> function (https://gcc.gnu.org/onlinedocs/gccint/SSA.html)
>> As you can see in this version the code is already optimized, and our
>> operations not correctly generated. We expect to see something like:
>>
>> __attribute__((noinline))
>> myFunc (long int i, int index)
>> {
>>   long int x;
>>   long int v;
>>   long unsigned int _1;
>>   long unsigned int _2;
>>   int * _3;
>>   int _4;
>>   long int _10;
>>
>>[local count: 1073741825]:
>>   x_6 = i_5(D) >> 3;
>>   v = x_6;
>>   _1 = (long unsigned int) index_9(D);
>>   _2 = _1 * 4;
>>  

[Pharo-dev] Debugging GCC code generation

[teso...@gmail.com]

Hi,
this mail is related to Pharo because it is knowledge I found
debugging the build of the VM, but the rest is to document it and
perhaps someone will found it interesting (also I couldn't find it
easily using Google). Sorry for the long mail!

The problem
==

The following code does not produce good code in 8.3 when using optimizations:

long __attribute__ ((noinline)) myFunc(long i, int index){
   long v;
   long x = i >> 3;

   v = x;
   return ((int*)())[index];
}

#include 

int main(){

long i;
int x;

scanf("%ld", );
scanf("%d", );

printf("%ld",myFunc(i,x));
}

Basically, with -02, it generates the following code:

myFunc:
 movslq %esi, %rsi
 movslq -8(%rsp,%rsi,4), %rax
 ret

And with -01 it generates the following code:

myFunc:
 sarq $3, %rdi
 movq %rdi, -8(%rsp)
 movslq %esi, %rsi
 movslq -8(%rsp,%rsi,4), %rax
 ret

As you can see, the more optimized version is losing the bit shift (or
any other operation).
To detect the problem it was not easy, basically, I have used the
Pharo Tests to detect the failing function and then to understand the
generation of code in GCC, we need to debug its generation.

The first snippet is generated using:

gcc -O2 prb.c -S -o prb.s -Wall

and the second using:

gcc -O1 prb.c -S -o prb.s -Wall

The GCC pipeline has different steps, I have centered my self in the
tree optimizations.
GCC dumps each of the intermediate states of the compilation, working
with C like trees. For example to get the optimized version of the
program, before generating the Assembler we have to do:

gcc -O2 prb.c -S -o prb.s -Wall -fdump-tree-optimized=/dev/stdout

This will generate:

__attribute__((noinline))
myFunc (long int i, int index)
{
  long int v;
  long unsigned int _1;
  long unsigned int _2;
  int * _3;
  int _4;
  long int _8;

   [local count: 1073741825]:
  _1 = (long unsigned int) index_7(D);
  _2 = _1 * 4;
  _3 =  + _2;
  _4 = *_3;
  _8 = (long int) _4;
  v ={v} {CLOBBER};
  return _8;

}

This is the optimized SSA (static single assign) version of the
function (https://gcc.gnu.org/onlinedocs/gccint/SSA.html)
As you can see in this version the code is already optimized, and our
operations not correctly generated. We expect to see something like:

__attribute__((noinline))
myFunc (long int i, int index)
{
  long int x;
  long int v;
  long unsigned int _1;
  long unsigned int _2;
  int * _3;
  int _4;
  long int _10;

   [local count: 1073741825]:
  x_6 = i_5(D) >> 3;
  v = x_6;
  _1 = (long unsigned int) index_9(D);
  _2 = _1 * 4;
  _3 =  + _2;
  _4 = *_3;
  _10 = (long int) _4;
  v ={v} {CLOBBER};
  return _10;

}

In the first SSA version, we are lacking the shift operation:

  x_6 = i_5(D) >> 3;
  v = x_6;

So, we need to see in which of the optimizations and transformations
our code is lost:
To see all the steps we should execute:

gcc -O2 prb.c -S -o prb.s -Wall -fdump-tree-all

This will generate a lot, really a lot, of files in the same directory.
They have the name: prb.c.xxx.
Where xxx is the number of the step, and  is the name of the step.
Each of the files contains the result of applying the changes, so what
I have done is looking in binary search where my code was lost.

I have found that the problem was in the first dead code elimination
step (prb.c.041t.cddce1)
GCC does not like the crap code that we are writing, as we are copying
a stack variable and then accessing directly to the memory:

v = x;
return ((int*)())[index];

So, basically, it was assuming that we were only using v and not x, so
all the code modifying x is described (this optimization is called
"dead store code deletion"). Basically tries to remove all the code
that is affecting stack (temporary) variables that are never used.

I am not sure if this is a bug in GCC, so I will report it. But I have
fixed the problem writing the code in a proper way.

Sorry again for the long mail, I wanted to store the knowledge and
propagate it before I eventually will flush it. I like these things,
but I am not debugging the GCC optimization pipeline all the days.

--
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] FOSDEM rooms are available

[teso...@gmail.com]

could be really cool. Maybe Julien's SQL or 
>>> Benoit's translations should be really good for catching potential students 
>>> and specially some investment capital for the team :).
>>>
>>> Sadly me i don't have much to show :(.
>>> But if we have the stand i plan to be there.
>>>
>>>
>>> TaskIt?
>>> I could do a presentation of Pharo in the minimalist…. and carolina a talk 
>>> showing how to bootstrap.
>>>
>>>
>>>
>>>
>>>
>>> El lun., 28 oct. 2019 a las 16:41, ducasse () 
>>> escribió:
>>>>
>>>>
>>>> https://fosdem.org/2020/news/2019-10-01-accepted-developer-rooms/
>>>> I do not know in which one we want to participate
>>>>
>>>> Debugging Tools
>>>> Minimalistic, Experimental and Emerging Languages
>>>> Open Research Tools and Technologies
>>>>
>>>> How do we coordinate?
>>>>
>>>> S.
>>>
>>>


-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] [Pharo-users] Pharo TechTalk Oct 24

[teso...@gmail.com]

Hi,
   I am putting the recorded version.

https://youtu.be/6iAzRYybY_M

Cheers,
Pablo

On Thu, Oct 24, 2019 at 11:18 AM teso...@gmail.com  wrote:
>
> Friendly reminder:
>
> Today at 17:00 (GMT+2, Paris Time) we have the techtalk about the headless VM
>
> Calendar entry: https://association.pharo.org/event-3419545
>
> On Thu, Oct 17, 2019 at 1:02 PM Marcus Denker  wrote:
> >
> > Hi,
> >
> > Next techtalk will be *next* week (Oct 24):
> >
> > Topic:  Headless VM
> >
> > Calendar entry: https://association.pharo.org/event-3419545
> >
> >
> > (it was originally dated to today, we will try to be better in pre-planning 
> > from the next one on)
>
>
>
> --
> Pablo Tesone.
> teso...@gmail.com



-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] [Pharo-users] Pharo TechTalk Oct 24

[teso...@gmail.com]

Friendly reminder:

Today at 17:00 (GMT+2, Paris Time) we have the techtalk about the headless VM

Calendar entry: https://association.pharo.org/event-3419545

On Thu, Oct 17, 2019 at 1:02 PM Marcus Denker  wrote:
>
> Hi,
>
> Next techtalk will be *next* week (Oct 24):
>
> Topic:  Headless VM
>
> Calendar entry: https://association.pharo.org/event-3419545
>
>
> (it was originally dated to today, we will try to be better in pre-planning 
> from the next one on)



-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] The Lands Platform at SLE 2019: Pharo magic inside

[teso...@gmail.com]

Really nice!!!

On Thu, Oct 24, 2019 at 8:44 AM Santiago Bragagnolo
 wrote:
>
> I loved it. great job nick!
>
> El mié., 23 oct. 2019 a las 9:16, Nick Papoylias () 
> escribió:
>>
>> The Lands Platform: Lan.guages and D.omain S.yntax,
>> @sleconf 2019, co-located with @splashcon
>>
>> https://youtu.be/HMgJK8mVPYw
>>
>> Showcasing live magic tricks powered by the @pharoproject
>>
>> Best,
>>
>> Nick



-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] [ANN] New Windows VM - Fixes 1903 error

[teso...@gmail.com]

A little information I was missing, the fixed VM is for both Pharo 7 and
Pharo 8

Thanks Guille!

Cheers,

On Fri, Sep 20, 2019 at 12:06 PM teso...@gmail.com 
wrote:

> Hello,
> a new stable VM has been deployed. This VM uses a new version of
> libSSH allowing us to work in the latest Windows version.
>
> It can be directly updated using Pharo Launcher or downloaded using
> ZeroConf scripts.
>
> To update from Pharo Launcher you have to access to the VM Manager window.
> Just click on the marked button and then in "Update"
> [image: updateVM.png]
>
> Thanks!!!
>
> Cheers,
> Pablo
>
> --
> Pablo Tesone.
> teso...@gmail.com
>


-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] [ANN] New Windows VM - Fixes 1903 error

[teso...@gmail.com]

Hello,
a new stable VM has been deployed. This VM uses a new version of libSSH
allowing us to work in the latest Windows version.

It can be directly updated using Pharo Launcher or downloaded using
ZeroConf scripts.

To update from Pharo Launcher you have to access to the VM Manager window.
Just click on the marked button and then in "Update"
[image: updateVM.png]

Thanks!!!

Cheers,
Pablo

-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] Slot definition API?

[teso...@gmail.com]

Hi, I really like the idea of returning a node object for the
initialization.
>From seeing the class definition, I think we should assume that:

- the receiver of the slot instantiation message is a Slot.
- the parameters to the slot instatiation message are literals or
literal-only expressions.

Do you think that these assumptions / constraints are cool / enough?

Cheers.

On Sun, 8 Sep 2019, 09:41 ducasse,  wrote:

> Hi
>
> I’m fixing the class definition parser and I have a question.
>
> I’m stabilizing the API of CDSlotNode
>
>
> 1 ‘first' =>  LazyClassVariable default: 5.
> 2 ’second' => InstanceVariableSlot.
> 3 ‘instVar3’
>
> Here is a proposal
>
> slotdefinition(3) name ?  variable name
> >>> ’instVar3'
>
> slotDefinition(2) slotClass?
> >>> InstanceVariableSlot
>
> slotDefinition(1) initializationMessage
> >>> 'default: 5’
> or better
> >>> Node(default: 5) if it exist
>
> S.
>
>
>
>

Re: [Pharo-dev] possible Windows Update "1903" Iceberg problem

[teso...@gmail.com]

Hi all,
 with Guille we have been working in this issue since Monday, it
was a complicated issue to solve as we require to compile and test
different versions of the libgit2 library and its dependencies
(openssl and libssh2).
We have a workaround for using ssh in windows.
We have produced a new set of libraries with the correct versions.
These libraries are available in
https://drive.google.com/open?id=1fwAVyrEEXkGOAuyAh1wASRRSv3SjZ3R1
The idea is to start testing them while we are working on a new
release of the VM.

Cheers,
Pablo

On Wed, Sep 4, 2019 at 10:05 AM Guillermo Polito
 wrote:
>
> Hi all,
>
> Sorry for not communicating better :).
> We know this is an important issue and we did move it to top priority even 
> prior to this email ;).
> Doru, to answer you, what people can do for the moment is to test what we are 
> going to propose in a couple of hours in your windows machines.
> With Pablo we have tested in several Windows 10 machines pre- and post- 
> update 1903. Still we would like people testing on their setups and other 
> windows versions
>
> We have been working the last couple of days debugging openssh and libgit, 
> and building a version with a more up-to-date version of openssh.
> We will come back later this morning / early afternoon with
>  - a new vm setup using up to date versions of openssh
>  - a description of workarounds for those tied to old versions of the VM
> So people can test.
>
> Cheers,
> Guille and Pablo
>
> > El 4 sept 2019, a las 8:38, ducasse  escribió:
> >
> > I saw everybody super busy and I imagine that they will reply soon.
> > I’m travelling to give Pharo lectures.
> >
> >> On 3 Sep 2019, at 19:23, Tudor Girba  wrote:
> >>
> >> Hi,
> >>
> >> Is there a way to speed the work on this one?
> >>
> >> At this moment, people cannot load any code in Pharo on Windows 10.
> >>
> >> Cheers,
> >> Doru
> >>
> >> --
> >> www.feenk.com
> >> "Every thing has its own flow."
> >>
> >>> On 28 Aug 2019, at 16:20, ducasse  wrote:
> >>>
> >>> tx doru
> >>>
> >>> Stef
> >>>
> >>>> On 28 Aug 2019, at 16:01, Tudor Girba  wrote:
> >>>>
> >>>> Hi
> >>>>
> >>>> I opened an issue: https://github.com/pharo-project/pharo/issues/4437
> >>>>
> >>>> I believe this should be treated as critical given that we cannot load 
> >>>> code in Pharo 7 (or 8) which makes it almost useless for users.
> >>>>
> >>>> Cheers,
> >>>> Doru
> >>>>
> >>>>
> >>>>> On Aug 27, 2019, at 10:54 AM, Tudor Girba  wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> We just encountered this on two different machines. We got this after 
> >>>>> the update to Windows 1903. For us it’s a critical issue at this point. 
> >>>>> What can we do to help with this?
> >>>>>
> >>>>> Cheers,
> >>>>> Doru
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On Aug 17, 2019, at 12:50 PM, Ben Coman  wrote:
> >>>>>>
> >>>>>> hi Stef,
> >>>>>> I feel you missed my point. Probably I wasn't clear this has already 
> >>>>>> been tested with latest Pharo 8 launched by PharoLauncher.
> >>>>>> The problem occurs with Pharo 7.0.3(64 bit) and with 
> >>>>>> Pharo8.0-SNAPSHOT-build.635(64 bit)
> >>>>>> after Microsoft Windows Update 1903...
> >>>>>> https://www.computerworld.com/article/3409621/microsoft-starts-windows-10s-1803-to-1903-forced-upgrade.html
> >>>>>>
> >>>>>> If indeed 1903 is the cause, with this update now being *forced* down 
> >>>>>> on people, this will potentially soon impact more and more Windows 
> >>>>>> users.
> >>>>>> But my guess that 1903 is the culprit needs to be confirmed.
> >>>>>> So I am requesting someone with access to multiple Windows machines 
> >>>>>> directly compare a 1903 machine with a pre-1903 machine.
> >>>>>>
> >>>>>> cheers -ben
> >>>>>>
> >>>>>> On Sat, 17 Aug 2019 at 12:58, ducasse  wrote:
> >>>>>> Hi ben
> >>>>>>
> >>>>>> in the pharo launcher if you click on P8.0 (development version) you 
> >>>>>> get access to all the builds.
> >>>>>>
> >>>>>> Stef
> >>>>>>
> >>>>>>> On 16 Aug 2019, at 16:02, Ben Coman  wrote:
> >>>>>>>
> >>>>>>> IThis morning the May 2019 Windows Update "1903" forced itself onto 
> >>>>>>> my computer and now 64-bits Pharo seems to have a problem with 
> >>>>>>> git_remote_fetch() FFI callout.  I no longer have a non-1903 machine 
> >>>>>>> to directly compare behaviour before "1903".  Can someone familiar 
> >>>>>>> with this area with both "pre-1903" and "1903" machines triage 
> >>>>>>> whether "1903" is indeed the cause?
> >>>>>>>
> >>>>>>> A few other recent reports are noted here...
> >>>>>>> https://github.com/pharo-project/pharo/issues/3418
> >>>>>>>
> >>>>>>> cheers -ben
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> feenk.com
> >>>>>
> >>>>> "Not knowing how to do something is not an argument for how it cannot 
> >>>>> be done."
> >>>>>
> >>>>
> >>>> --
> >>>> feenk.com
> >>>>
> >>>> “Live like you mean it."
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
>
>


-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] [ANN] Pharo Headless - Beta (Actually what is between Alpha and Beta)

[teso...@gmail.com]

Hi,
   the repos is https://github.com/pharo-project/opensmalltalk-vm in
the headless branch

Cheers,
Pablo

On Mon, Aug 12, 2019 at 11:07 AM Tudor Girba  wrote:
>
> Hi,
>
> Thanks for the answers!
>
> Could you point me to where the platforms for minheadless are (which 
> repository should we look at)? Also, to the build scripts that are used to 
> build it?
>
> Cheers,
> Doru
>
>
> > On Aug 12, 2019, at 10:56 AM, teso...@gmail.com wrote:
> >
> > Hi,
> >The executables are not the same.
> >We have 2 different now: the Stock VM (that is downloaded by the
> > launcher, and it is the default download in Zero-conf), and the
> > headless VM (this is downloaded by zero-conf when using
> > vmLatestHeadless).
> >
> >Those platforms are not representative we currently have: OSX,
> > Windows, and Linux all 64bits. We are working in ARM 32bits.
> >In the near future, I will work on validating different flavors of
> > Unix, but again It depends on the roadmap, and they are not there now.
> >
> >If someone requires some other platform we can talk to see how it
> > can fit in the roadmap.
> >
> > Cheers,
> > Pablo
> >
> > On Mon, Aug 12, 2019 at 10:03 AM Tudor Girba  wrote:
> >>
> >> Hi,
> >>
> >> Yes. We will be testing these days and we will come back with more details.
> >>
> >> Two more questions:
> >> - Is minheadlessVM now integrated in the regular VM binary or are the two 
> >> different artifacts?
> >> - Also are the platforms from 
> >> https://github.com/pharo-project/opensmalltalk-vm/tree/pharo/platforms 
> >> representative for minheadlessVM?
> >>
> >> Cheers,
> >> Doru
> >>
> >>
> >>
> >>> On Aug 12, 2019, at 9:11 AM, teso...@gmail.com wrote:
> >>>
> >>> Hi Doru,
> >>>   can you give us more insight of the errors? Because there should
> >>> not be changes in the behavior of the VM. Maybe there are issues, we
> >>> have used the Pharo tests as a guarantee and we are laking some tests.
> >>>
> >>> Cheers,
> >>> Pablo.
> >>>
> >>> On Sun, Aug 11, 2019 at 9:04 PM Tudor Girba  wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>>
> >>>>
> >>>>> On Aug 11, 2019, at 5:29 PM, ducasse  wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On 11 Aug 2019, at 13:19, Tudor Girba  wrote:
> >>>>>>
> >>>>>> Excellent news!
> >>>>>>
> >>>>>> I should say that for GT we are currently using the minheadlessVM 
> >>>>>> (Ronie’s work) out of the opensmalltalk-vm repo 
> >>>>>> (https://bintray.com/opensmalltalk/vm/cog) and it works remarkably 
> >>>>>> well.
> >>>>>>
> >>>>>> We started to play with your minheadlessVM. So far it looks like there 
> >>>>>> are differences, although I am sure they are not large.
> >>>>>
> >>>>> like what?
> >>>>
> >>>> I do not know yet, but running GT in headless opens the window with the 
> >>>> one from opensmalltalk-vm, but not with the new one. We did not yet look 
> >>>> into details, but we will.
> >>>>
> >>>> Cheers,
> >>>> Doru
> >>>>
> >>>>
> >>>>>> So, what is the difference between the minheadlessVM built by you 
> >>>>>> versus the one from opensmalltalk-vm?
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Doru
> >>>>>>
> >>>>>>
> >>>>>>> On Aug 8, 2019, at 9:53 AM, teso...@gmail.com wrote:
> >>>>>>>
> >>>>>>> TL;DR;
> >>>>>>> ==
> >>>>>>>
> >>>>>>> For the anxious, you can get real headless vm and image from 
> >>>>>>> zero-conf.
> >>>>>>>
> >>>>>>> $ wget get.pharo.org/64/80+vmHeadlessLatest | bash
> >>>>>>>
> >>>>>>> Zero conf scripts remain unchanged for users.
> >>>>>>>
> >>>>>>> However, if you are launching the VM by hand from the executable
> >>&g

Re: [Pharo-dev] [ANN] Pharo Headless - Beta (Actually what is between Alpha and Beta)

[teso...@gmail.com]

Hi,
The executables are not the same.
We have 2 different now: the Stock VM (that is downloaded by the
launcher, and it is the default download in Zero-conf), and the
headless VM (this is downloaded by zero-conf when using
vmLatestHeadless).

Those platforms are not representative we currently have: OSX,
Windows, and Linux all 64bits. We are working in ARM 32bits.
In the near future, I will work on validating different flavors of
Unix, but again It depends on the roadmap, and they are not there now.

If someone requires some other platform we can talk to see how it
can fit in the roadmap.

Cheers,
Pablo

On Mon, Aug 12, 2019 at 10:03 AM Tudor Girba  wrote:
>
> Hi,
>
> Yes. We will be testing these days and we will come back with more details.
>
> Two more questions:
> - Is minheadlessVM now integrated in the regular VM binary or are the two 
> different artifacts?
> - Also are the platforms from 
> https://github.com/pharo-project/opensmalltalk-vm/tree/pharo/platforms 
> representative for minheadlessVM?
>
> Cheers,
> Doru
>
>
>
> > On Aug 12, 2019, at 9:11 AM, teso...@gmail.com wrote:
> >
> > Hi Doru,
> >can you give us more insight of the errors? Because there should
> > not be changes in the behavior of the VM. Maybe there are issues, we
> > have used the Pharo tests as a guarantee and we are laking some tests.
> >
> > Cheers,
> > Pablo.
> >
> > On Sun, Aug 11, 2019 at 9:04 PM Tudor Girba  wrote:
> >>
> >> Hi,
> >>
> >>
> >>
> >>> On Aug 11, 2019, at 5:29 PM, ducasse  wrote:
> >>>
> >>>
> >>>
> >>>> On 11 Aug 2019, at 13:19, Tudor Girba  wrote:
> >>>>
> >>>> Excellent news!
> >>>>
> >>>> I should say that for GT we are currently using the minheadlessVM 
> >>>> (Ronie’s work) out of the opensmalltalk-vm repo 
> >>>> (https://bintray.com/opensmalltalk/vm/cog) and it works remarkably well.
> >>>>
> >>>> We started to play with your minheadlessVM. So far it looks like there 
> >>>> are differences, although I am sure they are not large.
> >>>
> >>> like what?
> >>
> >> I do not know yet, but running GT in headless opens the window with the 
> >> one from opensmalltalk-vm, but not with the new one. We did not yet look 
> >> into details, but we will.
> >>
> >> Cheers,
> >> Doru
> >>
> >>
> >>>> So, what is the difference between the minheadlessVM built by you versus 
> >>>> the one from opensmalltalk-vm?
> >>>>
> >>>> Cheers,
> >>>> Doru
> >>>>
> >>>>
> >>>>> On Aug 8, 2019, at 9:53 AM, teso...@gmail.com wrote:
> >>>>>
> >>>>> TL;DR;
> >>>>> ==
> >>>>>
> >>>>> For the anxious, you can get real headless vm and image from zero-conf.
> >>>>>
> >>>>> $ wget get.pharo.org/64/80+vmHeadlessLatest | bash
> >>>>>
> >>>>> Zero conf scripts remain unchanged for users.
> >>>>>
> >>>>> However, if you are launching the VM by hand from the executable
> >>>>> instead of the launcher scripts (pharo and pharo-ui) as in
> >>>>>
> >>>>> $ ./pharoexecutable Pharo.image
> >>>>>
> >>>>> the image will launch in headless mode and will not open a window.
> >>>>> To launch it in headfull, you can use the --interactive argument after
> >>>>> the image, which will make the image open a window using SDL2.
> >>>>>
> >>>>> $ ./pharoexecutable Pharo.image --interactive
> >>>>>
> >>>>> Long version
> >>>>> 
> >>>>>
> >>>>> Hi, this mail is the happy intermediate result of the work that us,
> >>>>> the Pharo Consortium Team, has been doing in the last couple of
> >>>>> months.
> >>>>> Our main objective is to have a real headless implementation of Pharo
> >>>>> where all the responsibility to open or not a World window (or other)
> >>>>> is handled by the image.
> >>>>> For doing so we have done a series of modifications in the image and
> >>>>> the VM side.
> >>>>> We consider this is the path that Pharo 8 and following versions
> >

Re: [Pharo-dev] [ANN] Pharo Headless - Beta (Actually what is between Alpha and Beta)

[teso...@gmail.com]

Hi Doru,
can you give us more insight of the errors? Because there should
not be changes in the behavior of the VM. Maybe there are issues, we
have used the Pharo tests as a guarantee and we are laking some tests.

Cheers,
Pablo.

On Sun, Aug 11, 2019 at 9:04 PM Tudor Girba  wrote:
>
> Hi,
>
>
>
> > On Aug 11, 2019, at 5:29 PM, ducasse  wrote:
> >
> >
> >
> >> On 11 Aug 2019, at 13:19, Tudor Girba  wrote:
> >>
> >> Excellent news!
> >>
> >> I should say that for GT we are currently using the minheadlessVM (Ronie’s 
> >> work) out of the opensmalltalk-vm repo 
> >> (https://bintray.com/opensmalltalk/vm/cog) and it works remarkably well.
> >>
> >> We started to play with your minheadlessVM. So far it looks like there are 
> >> differences, although I am sure they are not large.
> >
> > like what?
>
> I do not know yet, but running GT in headless opens the window with the one 
> from opensmalltalk-vm, but not with the new one. We did not yet look into 
> details, but we will.
>
> Cheers,
> Doru
>
>
> >> So, what is the difference between the minheadlessVM built by you versus 
> >> the one from opensmalltalk-vm?
> >>
> >> Cheers,
> >> Doru
> >>
> >>
> >>> On Aug 8, 2019, at 9:53 AM, teso...@gmail.com wrote:
> >>>
> >>> TL;DR;
> >>> ==
> >>>
> >>> For the anxious, you can get real headless vm and image from zero-conf.
> >>>
> >>> $ wget get.pharo.org/64/80+vmHeadlessLatest | bash
> >>>
> >>> Zero conf scripts remain unchanged for users.
> >>>
> >>> However, if you are launching the VM by hand from the executable
> >>> instead of the launcher scripts (pharo and pharo-ui) as in
> >>>
> >>> $ ./pharoexecutable Pharo.image
> >>>
> >>> the image will launch in headless mode and will not open a window.
> >>> To launch it in headfull, you can use the --interactive argument after
> >>> the image, which will make the image open a window using SDL2.
> >>>
> >>> $ ./pharoexecutable Pharo.image --interactive
> >>>
> >>> Long version
> >>> 
> >>>
> >>> Hi, this mail is the happy intermediate result of the work that us,
> >>> the Pharo Consortium Team, has been doing in the last couple of
> >>> months.
> >>> Our main objective is to have a real headless implementation of Pharo
> >>> where all the responsibility to open or not a World window (or other)
> >>> is handled by the image.
> >>> For doing so we have done a series of modifications in the image and
> >>> the VM side.
> >>> We consider this is the path that Pharo 8 and following versions
> >>> should follow, as it will severely improve server-side and command
> >>> line Pharo and in building custom desktop applications.
> >>>
> >>> These modifications are available only in 64-bits machines (Windows,
> >>> OSX, and Linux).
> >>> ARM32 and 64bits headless is in the roadmap, but it is delayed because
> >>> we have prioritized our three major platforms for this first couple of
> >>> months.
> >>>
> >>> All this work is based in Opensmalltalk-VM and Ronnie's initial work
> >>> on headless.
> >>> We are really grateful to all the contributors in the history of this
> >>> nice product.
> >>> To achieve a real headless VM we have brought modifications in the
> >>> source tree because most of the platform code to open and manipulate
> >>> windows is not required anymore.
> >>> Instead, we use the SDL2 library that implements a nice layer on top
> >>> of the OS and allows us to manage on the image side through FFI.
> >>>
> >>> So this mail is now an open call for (beta?)testing.
> >>> The sources of the current VM we are building are in the headless branch 
> >>> in
> >>> https://github.com/pharo-project/opensmalltalk-vm
> >>> And we have set up a CI that is both building and testing the VM in
> >>> https://ci.inria.fr/pharo-ci-jenkins2/job/pharo-vm/job/headless/
> >>>
> >>> For the future we have a lot of ideas, that will wait for another long
> >>> email or a beer-talk @ESUG.
> >>> We want to hear your ideas!!
> >>>
> >>> Image-Side Improvements
> &g

[Pharo-dev] [ANN] Pharo Headless - Beta (Actually what is between Alpha and Beta)

[teso...@gmail.com]

TL;DR;
==

For the anxious, you can get real headless vm and image from zero-conf.

$ wget get.pharo.org/64/80+vmHeadlessLatest | bash

Zero conf scripts remain unchanged for users.

However, if you are launching the VM by hand from the executable
instead of the launcher scripts (pharo and pharo-ui) as in

$ ./pharoexecutable Pharo.image

the image will launch in headless mode and will not open a window.
To launch it in headfull, you can use the --interactive argument after
the image, which will make the image open a window using SDL2.

$ ./pharoexecutable Pharo.image --interactive

Long version


Hi, this mail is the happy intermediate result of the work that us,
the Pharo Consortium Team, has been doing in the last couple of
months.
Our main objective is to have a real headless implementation of Pharo
where all the responsibility to open or not a World window (or other)
is handled by the image.
For doing so we have done a series of modifications in the image and
the VM side.
We consider this is the path that Pharo 8 and following versions
should follow, as it will severely improve server-side and command
line Pharo and in building custom desktop applications.

These modifications are available only in 64-bits machines (Windows,
OSX, and Linux).
ARM32 and 64bits headless is in the roadmap, but it is delayed because
we have prioritized our three major platforms for this first couple of
months.

All this work is based in Opensmalltalk-VM and Ronnie's initial work
on headless.
We are really grateful to all the contributors in the history of this
nice product.
To achieve a real headless VM we have brought modifications in the
source tree because most of the platform code to open and manipulate
windows is not required anymore.
Instead, we use the SDL2 library that implements a nice layer on top
of the OS and allows us to manage on the image side through FFI.

So this mail is now an open call for (beta?)testing.
The sources of the current VM we are building are in the headless branch in
  https://github.com/pharo-project/opensmalltalk-vm
And we have set up a CI that is both building and testing the VM in
  https://ci.inria.fr/pharo-ci-jenkins2/job/pharo-vm/job/headless/

For the future we have a lot of ideas, that will wait for another long
email or a beer-talk @ESUG.
We want to hear your ideas!!

Image-Side Improvements
===

- The image handles the creation or not of the main world window.
- We incorporated the idea of World renderer, where different backends
are used to render the world.
- We have 3 backends: VM support (compatibility with non-headless
VMs), and OSWindow with two backends: SDL and GTK3+.
- The modifications in the image are fully backward compatible with
the non-headless VM and are pushed since weeks in the latest 8.0
image.
- We move the handling of events to the image side when using SDL and
GTK3+, opening the door to a richer set of events and finer-grained
control over them.
- SDL and GTK versions are implemented using FFI calls.

VM-Side Improvements


- VMMaker code migrated to Tonel thanks to Feenk and included in the
repository of the VM.
- Making VMMaker execute in Pharo 7 and 8.
- Removing GPL code from the VM repository (GDB).

- Slowly adding new tests for the JIT / Slang and VMGeneration.
- Restructuring of the source code.
- A new simpler CMake build.
- Generate VM code from Slang on each build.
- A CI process to validate (including the run of the tests in Pharo
and the ones adding to the VM).
- Simplification of the codebase.

- Maximize the reuse of code between the platforms (preferring the
standard versions over the platform-specific).
- Cleaning up duplicated code.
- All the plugins are now external plugins.
- The VM is now a dynamic library. This is a first step towards
embedding Pharo into other applications.
- The main executable is a thin frontend (you can change it or
implement your own).

- Removing unused plugins.
- Improved crash dump. Especially the crash dump works now in Windows 64bits.
- Dummy implementation of Security plugin (it is going away eventually).
- Cleanup of SSL, UUID, and Socket plugin.

- Cleanup of conditional code (Still to improve).
- Improving the types used in the functions (we have to be neat to be
multiplatform/multi-arch).
- Improving the lookup of modules
- Improving the logging of the VM
- Improving the handling of VM arguments


Thanks a lot for reading so long!!
We hope you enjoy the VM and please tell us all the problems you find!!

Pablo, Guille, and Esteban

Re: [Pharo-dev] P8 + aTalent - aKind

[teso...@gmail.com]

Hi Norbert, I share the point of improving the implementation to reuse the
anonymous classes.
I will check that and propose a solution, of course if any one else want to
propose something is welcomed.

Thinking about the reflective messages I don't have a stablished opinion. I
think the behaviour should be the most similar to the one of traits, and
avoiding custom messages. So, what I am saying that I am tempted to review
all the api (classes, traits, talents... What ever somebody invents). I
would love to get more opinions

On Tue, 23 Jul 2019, 16:51 Sean P. DeNigris,  wrote:

> NorbertHartl wrote
> > I’m playing again with Talents and I want that in Pharo8 to appear so it
> > can mature.
>
> I'm very interested in this. Adding behavior at runtime only when an object
> takes on a role seems to have many possibilities e.g. expressiveness and
> code simplification.
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

Re: [Pharo-dev] [ANN] OSWinSubprocess a library to spawn Windows System processes

[teso...@gmail.com]

Thanks Christophe!

This thread opens a lot of interesting questions, and as most of them
are all subjective and I will only add my opinion that is so wrong (or
right) as all the other opinions.

First, I consider that having options to do the same tasks with
different considerations is good for the community, as it enlarges the
options when using Pharo professionally. I always consider that a good
engineer takes all the options and decide the best one depending on
the existent requirement and restrictions.
Sometimes we require to have tools that only fit for a single scenario
and others that are general but mostly fit for all scenarios.

I also consider good that Christophe, that fixes something for the
Pharo Launcher (but it could have been any other project) and releases
to the community so anyone else can fix the same problem.

I ask everybody else before taking opinions to read the motivations
behind the library / framework / couple of classes of Christophe. He
required to have something that was working with correctly with UTF8
paths and it is polymorphic with OSSubprocess (as it is used in the
other 2 platforms). I don't see any other solution that fulfills these
requirements, so he has done an ad-hoc solution. Thankfully he has
released it and now whoever cames later can have another option to use
or even to copy and spawn a completely new solution.

Finally, I share the good point of Torsten that we require to have a
better way of publishing all the tools / libraries / pieces of code
that we share, so the newcomers can find them easily. But even with
the perfect documenting-sharing tool, it will be nice to have
different solutions with different constraints and different
improvements.

Also, it will be nice to have more communication and focussing on
pushing to the same targets. But how we can do that without cutting
down the innovation, the reception of new ideas and the enjoy of
implementing new things.

One interesting case we have to accept as an open community is the
reimplementation of something because is funny. I know this is not the
case with Christophe, because I have seen him. This is also important
and should not be cut down.

It is not good to reinvent the wheel every time, but if we don't do it
when it is required we will not have anything.

I will really like to see more contributions of any kind, I invite to
reimplement any of the things I did / do with new approaches and
vision so everyone can grow.

And one that will be really nice to have is a replacement for the
catalog, so we can compare all the solutions that we have for a single
problem!!!

Thanks for reading me!!

On Mon, Jul 8, 2019 at 12:13 PM Christophe Demarey
 wrote:
>
> Hi,
>
> Pharo Launcher had stability problems to spawn new processes (launch Pharo 
> images) on Windows as well as limitations (paths could only contain ASCII 
> characters).
> To solve this problem, we developed a new library: OSWinSubprocess 
> (https://github.com/pharo-contributions/OSWinSubprocess) and decided to make 
> it a standalone library so that people can use it if they need to.
> We tried to use the same API as OSSubprocess when possible. This library uses 
> the Windows API to create process from both 32-bit and 64-bit Pharo images. 
> It also supports Unicode characters.
>
> Here are some examples on how to use it:
>
> process := OSWSWinProcess new
> command: 'C:\Windows\notepad.exe';
> run.
> ...
> process terminate.
>
>
> OSWSWinProcess new
> command: 'C:\Windows\notepad.exe';
> arguments: #('notepad.exe' 'C:\foo.txt');
> runAndWait.
>
> Important note: As of now, this library does not yet support standard streams 
> (stdin, stdout and stderr). It could be done by setting the appropriate 
> information in the STARTUPINFO structutre.
>
> You can check the README for more information.
>
> Regards,
> Christophe.



-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] [ANN] Pharo 7.0.3

[teso...@gmail.com]

I am afraid we will need to give more love to it.
We need a proper solution, hacking it is not working. We will have to
refactor implementation and modify the users.
It is not that we are lazy (that we are) but also it is ugly and full of
magic numbers.

But we will win, we must win!

Thanks again for the report!

On Mon, Apr 15, 2019 at 9:10 AM teso...@gmail.com  wrote:

> Thanks a lot, founding the issue is important.
> For sure I missed some other users of freetype doing the same!!
>
> On Mon, Apr 15, 2019 at 1:14 AM Tim Mackinnon  wrote:
>
>> I hate to be the bearer of bad news - but 7.0.3 on OSX still has the font
>> glyph issue (see how my menus have started to go) - saving my image has
>> fixed it (for now). I do have Mirage loaded in my image ( the latest
>> version, and I was showing you guys how that seems to stress it a bit more).
>>
>> Tim
>>
>>
>>
>>
>>
>> On 14 Apr 2019, at 15:16, teso...@gmail.com wrote:
>>
>> Like in the Oscars, I was thanking everybody. ;)
>>
>> On Fri, 12 Apr 2019, 21:40 Stéphane Ducasse > wrote:
>>
>>> what is the academy?
>>> :)
>>>
>>> stef
>>>
>>>
>>>
>>> On 12 Apr 2019, at 17:26, teso...@gmail.com wrote:
>>>
>>> Pharo 7.0.3 contains several bugfixes, notably a fix for the annoying
>>> font corruption font.
>>>
>>> 
>>>
>>> Changes Log
>>>
>>>
>>>- #2781 <https://github.com/pharo-project/pharo/pull/2781> Fix
>>>comment on OSWindow >> startTextInput
>>>- #3160 <https://github.com/pharo-project/pharo/pull/3160>
>>> 2975-Problem-when-you-read-an-mcz-pharo7
>>>- #3130 <https://github.com/pharo-project/pharo/pull/3130> Improving
>>>the performance of SourceFileArray
>>>- #3164 <https://github.com/pharo-project/pharo/pull/3164> MailMessage
>>>can not send mails with attachment in Pharo7
>>>- #3149 <https://github.com/pharo-project/pharo/pull/3149>
>>> 
>>> 3148-backport-2395-to-Pharo-70--Non-ASCII-class-and-author-names-break-SourceFileArraygetPreambleFromat
>>>- #3178 <https://github.com/pharo-project/pharo/pull/3178> Fix for
>>>corrupted fonts in Pharo7
>>>
>>> Detailed Diff: v7.0.2...pharo-project:v7.0.3
>>> <https://github.com/pharo-project/pharo/compare/v7.0.2...pharo-project:v7.0.3>
>>> https://github.com/pharo-project/pharo/releases/tag/v7.0.3
>>>
>>> All the images are available in ZeroConf and in the Pharo Launcher.
>>>
>>> Thanks to all the collaborators especially:
>>>
>>> - David
>>> - Guille
>>> - Pavel
>>> - Christophe
>>> - Theo
>>> - Sabine
>>> - Sven
>>>
>>> And to all the people that helped to make this release in a couple of
>>> minutes.
>>> And thanks to the academy!
>>>
>>> Pablo
>>>
>>>
>>> 
>>> Stéphane Ducasse
>>> http://stephane.ducasse.free.fr
>>> http://www.synectique.eu / http://www.pharo.org
>>> 03 59 35 87 52
>>> Assistant: Julie Jonas
>>> FAX 03 59 57 78 50
>>> TEL 03 59 35 86 16
>>> S. Ducasse - Inria
>>> 40, avenue Halley,
>>> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
>>> Villeneuve d'Ascq 59650
>>> France
>>>
>>>
>>
>
> --
> Pablo Tesone.
> teso...@gmail.com
>


-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] [ANN] Pharo 7.0.3

[teso...@gmail.com]

Thanks a lot, founding the issue is important.
For sure I missed some other users of freetype doing the same!!

On Mon, Apr 15, 2019 at 1:14 AM Tim Mackinnon  wrote:

> I hate to be the bearer of bad news - but 7.0.3 on OSX still has the font
> glyph issue (see how my menus have started to go) - saving my image has
> fixed it (for now). I do have Mirage loaded in my image ( the latest
> version, and I was showing you guys how that seems to stress it a bit more).
>
> Tim
>
>
>
>
>
> On 14 Apr 2019, at 15:16, teso...@gmail.com wrote:
>
> Like in the Oscars, I was thanking everybody. ;)
>
> On Fri, 12 Apr 2019, 21:40 Stéphane Ducasse  wrote:
>
>> what is the academy?
>> :)
>>
>> stef
>>
>>
>>
>> On 12 Apr 2019, at 17:26, teso...@gmail.com wrote:
>>
>> Pharo 7.0.3 contains several bugfixes, notably a fix for the annoying
>> font corruption font.
>>
>> 
>>
>> Changes Log
>>
>>
>>- #2781 <https://github.com/pharo-project/pharo/pull/2781> Fix
>>comment on OSWindow >> startTextInput
>>- #3160 <https://github.com/pharo-project/pharo/pull/3160>
>> 2975-Problem-when-you-read-an-mcz-pharo7
>>- #3130 <https://github.com/pharo-project/pharo/pull/3130> Improving
>>the performance of SourceFileArray
>>- #3164 <https://github.com/pharo-project/pharo/pull/3164> MailMessage
>>can not send mails with attachment in Pharo7
>>- #3149 <https://github.com/pharo-project/pharo/pull/3149>
>> 
>> 3148-backport-2395-to-Pharo-70--Non-ASCII-class-and-author-names-break-SourceFileArraygetPreambleFromat
>>- #3178 <https://github.com/pharo-project/pharo/pull/3178> Fix for
>>corrupted fonts in Pharo7
>>
>> Detailed Diff: v7.0.2...pharo-project:v7.0.3
>> <https://github.com/pharo-project/pharo/compare/v7.0.2...pharo-project:v7.0.3>
>> https://github.com/pharo-project/pharo/releases/tag/v7.0.3
>>
>> All the images are available in ZeroConf and in the Pharo Launcher.
>>
>> Thanks to all the collaborators especially:
>>
>> - David
>> - Guille
>> - Pavel
>> - Christophe
>> - Theo
>> - Sabine
>> - Sven
>>
>> And to all the people that helped to make this release in a couple of
>> minutes.
>> And thanks to the academy!
>>
>> Pablo
>>
>>
>> 
>> Stéphane Ducasse
>> http://stephane.ducasse.free.fr
>> http://www.synectique.eu / http://www.pharo.org
>> 03 59 35 87 52
>> Assistant: Julie Jonas
>> FAX 03 59 57 78 50
>> TEL 03 59 35 86 16
>> S. Ducasse - Inria
>> 40, avenue Halley,
>> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
>> Villeneuve d'Ascq 59650
>> France
>>
>>
>

-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] [ANN] Pharo 7.0.3

[teso...@gmail.com]

Like in the Oscars, I was thanking everybody. ;)

On Fri, 12 Apr 2019, 21:40 Stéphane Ducasse  what is the academy?
> :)
>
> stef
>
>
>
> On 12 Apr 2019, at 17:26, teso...@gmail.com wrote:
>
> Pharo 7.0.3 contains several bugfixes, notably a fix for the annoying font
> corruption font.
>
> 
>
> Changes Log
>
>
>- #2781 <https://github.com/pharo-project/pharo/pull/2781> Fix comment
>on OSWindow >> startTextInput
>- #3160 <https://github.com/pharo-project/pharo/pull/3160>
> 2975-Problem-when-you-read-an-mcz-pharo7
>- #3130 <https://github.com/pharo-project/pharo/pull/3130> Improving
>the performance of SourceFileArray
>- #3164 <https://github.com/pharo-project/pharo/pull/3164> MailMessage
>can not send mails with attachment in Pharo7
>- #3149 <https://github.com/pharo-project/pharo/pull/3149>
> 
> 3148-backport-2395-to-Pharo-70--Non-ASCII-class-and-author-names-break-SourceFileArraygetPreambleFromat
>- #3178 <https://github.com/pharo-project/pharo/pull/3178> Fix for
>corrupted fonts in Pharo7
>
> Detailed Diff: v7.0.2...pharo-project:v7.0.3
> <https://github.com/pharo-project/pharo/compare/v7.0.2...pharo-project:v7.0.3>
> https://github.com/pharo-project/pharo/releases/tag/v7.0.3
>
> All the images are available in ZeroConf and in the Pharo Launcher.
>
> Thanks to all the collaborators especially:
>
> - David
> - Guille
> - Pavel
> - Christophe
> - Theo
> - Sabine
> - Sven
>
> And to all the people that helped to make this release in a couple of
> minutes.
> And thanks to the academy!
>
> Pablo
>
>
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr
> http://www.synectique.eu / http://www.pharo.org
> 03 59 35 87 52
> Assistant: Julie Jonas
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley,
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
>
>

[Pharo-dev] [ANN] Pharo 7.0.3

[teso...@gmail.com]

Pharo 7.0.3 contains several bugfixes, notably a fix for the annoying font
corruption font.

[image: image.png]

Changes Log


   - #2781  Fix comment
   on OSWindow >> startTextInput
   - #3160 
2975-Problem-when-you-read-an-mcz-pharo7
   - #3130  Improving the
   performance of SourceFileArray
   - #3164  MailMessage
   can not send mails with attachment in Pharo7
   - #3149 

3148-backport-2395-to-Pharo-70--Non-ASCII-class-and-author-names-break-SourceFileArraygetPreambleFromat
   - #3178  Fix for
   corrupted fonts in Pharo7

Detailed Diff: v7.0.2...pharo-project:v7.0.3


https://github.com/pharo-project/pharo/releases/tag/v7.0.3

All the images are available in ZeroConf and in the Pharo Launcher.

Thanks to all the collaborators especially:

- David
- Guille
- Pavel
- Christophe
- Theo
- Sabine
- Sven

And to all the people that helped to make this release in a couple of
minutes.
And thanks to the academy!

Pablo

Re: [Pharo-dev] FreeType and the over amorous glyphs (overlapping)

[teso...@gmail.com]

I am not shy, the mail of Guille is perfect, I cannot do it!

Thanks a lot for all the explanations!

On Thu, Apr 11, 2019 at 3:25 PM Guillermo Polito 
wrote:

> So, this morning we have been working on validating this hypothesis and
> making a meaningful and reproducible test for it.
> I'm just the messenger here because Pablo who has done most of the job is
> shy.
>
> ## The main story
>
> Since we are working with concurrency and non-determinism, we have
> designed a test that reproduces the case with an accuracy of ~94%.
> Basically the test renders a Rubric morph in concurrent green threads on a
> big string, and then we compare that the drawn morphs should be bit
> identical.
> We have made some measurements and observed that putting three concurrent
> processes made the chance of hitting the bug to almost 94%.
> So running it more than ~5 times makes it highly reproducible.
>
> Good thing: this test inside a loop of 10 iterations (to increase the
> probability of hitting the bug to >~99%) detects the bug in the stock image
> and not in the one with our patch.
> Bad thing: this test relies on rubric, we have tried to simplify it (like
> just doing a collect on the string to fetch the glyph for each character),
> but simpler code produces a tighter loop which makes it far less
> reproducible (down from 94 to 33%).
>
> Still, there are several questions open:
>  - can we simplify the test? :)
>  - we have to think about a smart way to serialize Freetype access in the
> image (there are several users)
>  - I'll paste below our math, so if somebody would like to review it would
> be good too, our probability is a bit rusty.
>  - we have been doing benchmarks with Pablo this morning and adding a
> mutex does not seem to have any negative impact in rendering.
>
> Help is super welcome of course!!
> The patch that Pablo has done in the PR will just work for the most common
> cases (at least for the calypso tabs), but it shows that FT* needs some
> love.
> Still we would like to be able to backport something like this in Pharo7,
> but backporting a big Freetype refactor would not be so good.
> Maybe the mutex is a good enough change for Pharo7?
>
> Any more ideas? input?
>
> Cheers,
> Guille and Pablo
>
> ## The code
>
> The code of the test is the following:
>
> ```
>  | sem text canvases blocky |
> sem := Semaphore new.
> text := (String loremIpsum: 25*1024).
> FreeTypeCache current removeAll.
> canvases := OrderedCollection new.
>
> blocky := [  | canvas |
> canvas := FormCanvas extent: 1000@1000.
> canvases add: canvas.
> (RubScrolledTextMorph new)
> setText: text;
> font: StandardFonts codeFont;
> bounds: (0@0 corner: canvas form extent);
> fullDrawOn: canvas.
> sem signal ].
> blocky forkAt: 39.
> blocky forkAt: 39.
> blocky forkAt: 39.
> sem
> wait;
> wait;
> wait.
>
> self assert: (((canvases at:1) form bits = (canvases at:2) form bits) and:
> [ ((canvases at:2) form bits = (canvases at:3) form bits) ])
> ```
>
> ## The math
> p := 0.94 asScaledDecimal.
>
> hittingTheBug := 0.
> notHittingTheBug := 1 - hittingTheBug.
> 5 timesRepeat: [
> hittingTheBug := hittingTheBug + (notHittingTheBug * p).
> notHittingTheBug := 1 - hittingTheBug ].
> hittingTheBug. "after 5 iterations"
> "0.9969s8"
>
> On Wed, Apr 10, 2019 at 8:04 PM Sven Van Caekenberghe 
> wrote:
>
>> Thanks a lot for actually diving into this, this mysterious issue has
>> been bugging us for a very long time. I do hope you can finally solve this.
>> I am sure many people will be grateful.
>>
>> Sven
>>
>> > On 10 Apr 2019, at 15:38, teso...@gmail.com wrote:
>> >
>> > Hello,
>> >
>> > After checking the problem with Guille, we have the hypothesis of the
>> > source of the problem.
>> > We have seen that accessing Free Type is not thread-safe.
>> > Basically, the FTFace holds a structure that is filled up with the
>> > glyph and its information. As this structure is part of the Font Face
>> > (a font face is a font plus size and attributes), only one request to
>> > a glyph can be executed at the time. As we are sharing the same font
>> > in many places, you will be starting to see the problem.
>> >
>> > Also, we have seen that there many accesses to the glyphs outside the
>> > UI process.
>> > This problem started to appear as we starting to use Calypso (but it
>> > is not limited to it), as Calypso uses lazy tabs. The creation of
>> > these tabs is done outside the UI process

Re: [Pharo-dev] FreeType and the over amorous glyphs (overlapping)

[teso...@gmail.com]

Ohhh, my fault, it is trying to look up for the commit of the merge.

That will never work... Because the commit is only in the CI.

On Wed, Apr 10, 2019 at 4:16 PM ducasse  wrote:
>
> Pablo I tried the file you sent and I imported it in the PharoLauncher and I 
> could not handle file.
> I got a File class bad argument and after I could not use iceberg.
>
> Stef
>
> > On 10 Apr 2019, at 15:38, teso...@gmail.com wrote:
> >
> > Hello,
> >
> > After checking the problem with Guille, we have the hypothesis of the
> > source of the problem.
> > We have seen that accessing Free Type is not thread-safe.
> > Basically, the FTFace holds a structure that is filled up with the
> > glyph and its information. As this structure is part of the Font Face
> > (a font face is a font plus size and attributes), only one request to
> > a glyph can be executed at the time. As we are sharing the same font
> > in many places, you will be starting to see the problem.
> >
> > Also, we have seen that there many accesses to the glyphs outside the
> > UI process.
> > This problem started to appear as we starting to use Calypso (but it
> > is not limited to it), as Calypso uses lazy tabs. The creation of
> > these tabs is done outside the UI process.
> >
> > This is only a hack to test our hypothesis.
> > To fix it correctly we will have to rewrite the drawing of the glyphs
> > and synchronize the access to the glyph data information. Also, we
> > want to do it in a way that does not penalize the processing in the UI
> > process.
> >
> > I have only patched the code that is used by the rendering of morphic,
> > other renderings like Athens or any other user using FT should be
> > correctly rewritten.
> >
> > Once we are sure that synchronizing the access to FT fixes the
> > problem, we will do a real fix not a dirty hack like this.
> >
> > I will be testing this new Image to see if there is an improvement.
> >
> > I will really love you try to use this image and tell me if you still
> > find the problem.
> >
> > There is a PR generating a Pharo8 image (it is called wrong, but... it
> > is a Pharo8)
> >
> > 32 bits
> > =
> >
> > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/PR-3157/2/artifact/bootstrap-cache/Pharo7.0-PR-32bit-f8c6957.zip
> >
> > 64 bits
> > =
> >
> > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/PR-3157/2/artifact/bootstrap-cache/Pharo7.0-PR-64bit-f8c6957.zip
> >
> > If somebody is willing to use it in Pharo 7, I can create a PR against
> > Pharo7 to generate patched P7 images.
> >
> > Thanks!
> >
> > --
> > Pablo Tesone.
> > teso...@gmail.com
> >
>
>
>


-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] FreeType and the over amorous glyphs (overlapping)

[teso...@gmail.com]

Hello,

After checking the problem with Guille, we have the hypothesis of the
source of the problem.
We have seen that accessing Free Type is not thread-safe.
Basically, the FTFace holds a structure that is filled up with the
glyph and its information. As this structure is part of the Font Face
(a font face is a font plus size and attributes), only one request to
a glyph can be executed at the time. As we are sharing the same font
in many places, you will be starting to see the problem.

Also, we have seen that there many accesses to the glyphs outside the
UI process.
This problem started to appear as we starting to use Calypso (but it
is not limited to it), as Calypso uses lazy tabs. The creation of
these tabs is done outside the UI process.

This is only a hack to test our hypothesis.
To fix it correctly we will have to rewrite the drawing of the glyphs
and synchronize the access to the glyph data information. Also, we
want to do it in a way that does not penalize the processing in the UI
process.

I have only patched the code that is used by the rendering of morphic,
other renderings like Athens or any other user using FT should be
correctly rewritten.

Once we are sure that synchronizing the access to FT fixes the
problem, we will do a real fix not a dirty hack like this.

I will be testing this new Image to see if there is an improvement.

I will really love you try to use this image and tell me if you still
find the problem.

There is a PR generating a Pharo8 image (it is called wrong, but... it
is a Pharo8)

32 bits
=

https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/PR-3157/2/artifact/bootstrap-cache/Pharo7.0-PR-32bit-f8c6957.zip

64 bits
=

https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/PR-3157/2/artifact/bootstrap-cache/Pharo7.0-PR-64bit-f8c6957.zip

If somebody is willing to use it in Pharo 7, I can create a PR against
Pharo7 to generate patched P7 images.

Thanks!

-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] Performance Issues

[teso...@gmail.com]

Hi, this will be a long mail. I have organized it in different sections.

Resume:
==

- There are performance issues in Pharo 7.
- I have made benchmarks.
- With Guille we made an improvement in saving source code in methods.
- More improvements to come.
- Automation and CI in the future.


Background
=

Since the release of Pharo 7 (and before it), it was notorious that
there exists a performance regression in the normal execution of the
image. By checking the usual operations, we have seen ( and many have
also detected) that there was an issue with the loading, compilation,
and unloading of code. Also with the creation of classes, traits and
the use of slots.

Benchmarks
=

Although we were sure that there is a performance regression, we have
to show it in a way we can test it and measure it. If we cannot
measure it or repeat its execution it is worthless.
For doing so, I have created an initial set of micro-benchmarks to
cover normal operations of the image.

The set of benchmarks is available here:
https://github.com/tesonep/pharo-benchmarks

These benchmarks are developed on top of SMark, only adding a command
line tool and the ability to generate a CSV file.

The idea is to run the benchmarks in different versions of Pharo an
assert that we are not breaking anything.

The first results were basically a nightmare, some operations take
almost 20 times more in Pharo 7. Especially, the ones that are
compiling methods.

In the attached document, there is the detail of all the benchmarks,
the different results and the analysis of the improvements and
regressions (Positive percentages are regressions (more time),
negative are improvements (less time)).

I have checked the results in OSX with 64 bits images. But as the
problem is in pure Smalltalk implementations the problems are (and the
solutions) cross platforms.

First Improvement
==

Having the benchmarks, it was easy to start looking for the problems.
Thanks to the help of Guille we have detected some problems in the
implementation of SourceFile. Objects of this class have the
responsibility to handle the save of the source code when a method is
modified.

Improving this implementation we have gotten to results similar to
Pharo 6 in the compilation of methods.

Comparing a stock Pharo8 image with the one with the fix, we have the
following improvements:

AddingAnInstanceVariableToAClassWithASubclass -3.96%
AddingAnInstanceVariableToAClassWithoutASubclassAndInstances -15.91%
AddingAnInstanceVariableToAClassWithoutSubclasses -28.50%
ClassAndSubclassCreation -25.67%
ClassUsingATrait -90.05%
SimpleClassCreation -26.55%
TraitCreation -92.95%
TraitCreationUsingOtherTrait -91.68%
CompileAMethodAndModifyIt -32.92%
CompileAMethodInAClassUsingATrait -83.28%
CompileAMethodInATraitNotUsed -85.12%
CompileAMethodInATraitUsed -88.16%
CompileANewMethod -40.73%
CompileANewMethodUsingInstanceVariable -33.93%
MethodAccessingAGlobal -47.57%

Again there are more details in the attached file.

Also, we have ported this fix to Pharo 7.

Next Steps


- Making it a part of the CI infrastructure: making it run in each PR
and build to detect regressions in the changes.

- Adding more micro and macro benchmarks. I have a list of things to
test, but I am open to more:

# Micro

- Slot Implementation
- Process handling
- Refactorings
- Files (open / write / read)

# Macro

- Loading:  Moose  / Seaside
- Recompile All
- Condense Sources
- Startup
- Shutdown

We also know that there are platform related issues (especially
Windows), so the idea it will be the same, build a benchmark, measure
it, improve it.

The idea is to have a more robust way of detecting and handling the
performance of Pharo.

Of course, I am open to all your comments.

Cheers,
Pablo


Report.xls
Description: MS-Excel spreadsheet

Re: [Pharo-dev] Creating a new class using `Class new superclass:` blocks the image in Pharo 7

[teso...@gmail.com]

Thanks a lot, I will check it in this days.

On Fri, 5 Oct 2018, 20:28 Andrei Chis,  wrote:

> Done:
> https://pharo.fogbugz.com/f/cases/22547/Creating-a-new-class-using-Class-new-superclass-blocks-the-image-in-Pharo-7
>
> Cheers,
> Andrei
>
> On Fri, Oct 5, 2018 at 8:15 PM teso...@gmail.com 
> wrote:
>
>> Hi Andrei, would you mind opening an issue for this, making a comment in
>> a merged PR does not help to see it.
>>
>> Thanks
>>
>> On Fri, 5 Oct 2018, 20:09 Andrei Chis, 
>> wrote:
>>
>>> Now I found the comment from
>>> https://github.com/pharo-project/pharo/pull/1618.
>>> Will add a comment there.
>>>
>>> On Fri, Oct 5, 2018 at 7:48 PM Andrei Chis 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Executed in the latest Pharo 7 image
>>>> (Pharo-7.0.0+alpha.build.1310.sha.a454977bb3d55bc4fcca3a57ac2fafcf137c0f30
>>>> (64 Bit)) the code below blocks the image (both with latest and stable vm
>>>> on MacOs HighSierra). The vm does not crash but gets into a "Not
>>>> Responding" state and does not get out:
>>>>
>>>> Class new
>>>>  superclass: GLMTransmission;
>>>>  setFormat: GLMTransmission format;
>>>>  classLayout: GLMTransmission classLayout copy;
>>>>  yourself
>>>>
>>>> Code like this is used in Moose in some tests and in SmaCC in the
>>>> rewrite engine:
>>>>
>>>> Class new
>>>> superclass: SmaCCRewriteMatchContext;
>>>> setFormat: SmaCCRewriteMatchContext format;
>>>> classLayout: SmaCCRewriteMatchContext classLayout copy;
>>>> yourself.
>>>>
>>>> This worked in Pharo 6. Bug or here should be a different way to do
>>>> this?
>>>>
>>>> Cheers,
>>>> Andrei
>>>>
>>>

Re: [Pharo-dev] Creating a new class using `Class new superclass:` blocks the image in Pharo 7

[teso...@gmail.com]

Hi Andrei, would you mind opening an issue for this, making a comment in a
merged PR does not help to see it.

Thanks

On Fri, 5 Oct 2018, 20:09 Andrei Chis,  wrote:

> Now I found the comment from
> https://github.com/pharo-project/pharo/pull/1618.
> Will add a comment there.
>
> On Fri, Oct 5, 2018 at 7:48 PM Andrei Chis 
> wrote:
>
>> Hi,
>>
>> Executed in the latest Pharo 7 image
>> (Pharo-7.0.0+alpha.build.1310.sha.a454977bb3d55bc4fcca3a57ac2fafcf137c0f30
>> (64 Bit)) the code below blocks the image (both with latest and stable vm
>> on MacOs HighSierra). The vm does not crash but gets into a "Not
>> Responding" state and does not get out:
>>
>> Class new
>>  superclass: GLMTransmission;
>>  setFormat: GLMTransmission format;
>>  classLayout: GLMTransmission classLayout copy;
>>  yourself
>>
>> Code like this is used in Moose in some tests and in SmaCC in the rewrite
>> engine:
>>
>> Class new
>> superclass: SmaCCRewriteMatchContext;
>> setFormat: SmaCCRewriteMatchContext format;
>> classLayout: SmaCCRewriteMatchContext classLayout copy;
>> yourself.
>>
>> This worked in Pharo 6. Bug or here should be a different way to do this?
>>
>> Cheers,
>> Andrei
>>
>

Re: [Pharo-dev] IndexedSlots in combination with StatefulTraits

[teso...@gmail.com]

Hi, I have created the PR.

Cheers

On Fri, Aug 31, 2018 at 11:15 AM teso...@gmail.com 
wrote:

> Sorry, I have missed them. That is why it is better to create a PR.
> I will check it.
>
> Cheers,
>
> On Thu, Aug 30, 2018 at 10:38 AM Torsten Bergmann  wrote:
>
>> Hi Pablo,
>>
>> were you able to have a look at my changeset with the fix provided in
>> July already:
>>
>>
>> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-July/272614.html
>>
>> I would like to get
>> https://pharo.fogbugz.com/f/cases/22271/Fix-IndexedSlots-in-combination-with-StatefulTraits
>> fixed.
>>
>> Thanks
>> T.
>>
>> *Gesendet:* Dienstag, 17. Juli 2018 um 12:51 Uhr
>> *Von:* "Torsten Bergmann" 
>> *An:* pharo-dev@lists.pharo.org
>> *Cc:* Pharo-dev 
>> *Betreff:* Re: [Pharo-dev] IndexedSlots in combination with
>> StatefulTraits
>> Hi Pablo,
>>
>> thanks for the quick answer. The attached CS would fix it ... can you
>> have a review so we can open a bug and do a PR?
>>
>> Then at least this could be integrated independent from when the tools
>> and traits are cleaned up.
>>
>> Thanks
>> T.
>>
>
>
> --
> Pablo Tesone.
> teso...@gmail.com
>


-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] IndexedSlots in combination with StatefulTraits

[teso...@gmail.com]

Sorry, I have missed them. That is why it is better to create a PR.
I will check it.

Cheers,

On Thu, Aug 30, 2018 at 10:38 AM Torsten Bergmann  wrote:

> Hi Pablo,
>
> were you able to have a look at my changeset with the fix provided in July
> already:
>
>
> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-July/272614.html
>
> I would like to get
> https://pharo.fogbugz.com/f/cases/22271/Fix-IndexedSlots-in-combination-with-StatefulTraits
> fixed.
>
> Thanks
> T.
>
> *Gesendet:* Dienstag, 17. Juli 2018 um 12:51 Uhr
> *Von:* "Torsten Bergmann" 
> *An:* pharo-dev@lists.pharo.org
> *Cc:* Pharo-dev 
> *Betreff:* Re: [Pharo-dev] IndexedSlots in combination with StatefulTraits
> Hi Pablo,
>
> thanks for the quick answer. The attached CS would fix it ... can you have
> a review so we can open a bug and do a PR?
>
> Then at least this could be integrated independent from when the tools and
> traits are cleaned up.
>
> Thanks
> T.
>


-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] Is Jenkins OK?

[teso...@gmail.com]

I am disabling the testing on OS X until the slave come back from the
grave!!

So we can continue working!

Cheers.

On Tue, Aug 14, 2018 at 10:03 AM Alistair Grant 
wrote:

> On Tue, 14 Aug 2018 at 09:59, Guillermo Polito
>  wrote:
> >
> > Nope, the osx slave is down since yesterday.
> > https://ci.inria.fr/pharo-ci-jenkins2/computer/pharo-ci-jenkins2-osx/
> >
> > I've been trying to restart it but no luck so far...
> > I'll keep you updated.
>
>
> Thanks, Guille!
>
> Cheers,
> Alistair
>
>
> >
> >
> > On Tue, Aug 14, 2018 at 7:49 AM Alistair Grant 
> wrote:
> >>
> >> I have a PR that has been running for over 13 hours...
> >>
> >>
> https://ci.inria.fr/pharo-ci-jenkins2/blue/organizations/jenkins/Test%20pending%20pull%20request%20and%20branch%20Pipeline/detail/PR-1684/1/pipeline
> >>
> >> (if there's something I can do about this myself instead of annoying
> >> the list, please let me know)
> >>
> >> Thanks,
> >> Alistair
> >>
> >
> >
> > --
> >
> >
> >
> > Guille Polito
> >
> > Research Engineer
> >
> > Centre de Recherche en Informatique, Signal et Automatique de Lille
> >
> > CRIStAL - UMR 9189
> >
> > French National Center for Scientific Research - http://www.cnrs.fr
> >
> >
> > Web: http://guillep.github.io
> >
> > Phone: +33 06 52 70 66 13
>
>

-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] About the infinite debugger

[teso...@gmail.com]

Yes, we have to check all the scenarios.

The problems with the UI process is not resolved at all.

On Tue, Aug 7, 2018 at 11:11 PM Denis Kudriashov 
wrote:

> I have more special cases where debugger hangs:
> 19662
> <https://pharo.fogbugz.com/f/cases/19662/Debugger-step-through-mustBeBoolean-case-hangs>
> , 19928
> <https://pharo.fogbugz.com/f/cases/19928/Debugger-step-over-through-last-doIt-context-hangs-image>
> , 20274
> <https://pharo.fogbugz.com/f/cases/20274/Debugger-infinite-recursion-when-terminating-delay-which-waits-inside-ensure-block>
> .
> They are still relevant
>
> 2018-08-07 22:01 GMT+01:00 Denis Kudriashov :
>
>> Hi.
>>
>> Good job guys. I just checked my case 19848
>> <https://pharo.fogbugz.com/f/cases/19848/Step-over-or-though-expression-with-DNU-hangs-image-when-happen-during-test-debugging>.
>> And it is now fixed.
>>
>> Thanks
>>
>>
>>
>> 2018-06-29 15:48 GMT+01:00 Guillermo Polito :
>>
>>> Hi all,
>>>
>>> during today's sprint we have been working with lots of people on the
>>> infinite debugger problem (https://pharo.fogbugz.com/f/cases/22085/).
>>> We have checked the emails sent in the latest month. Then, together with
>>> Quentin, Pablo, Pavel, Yoan we have been discussing and testing hypothesis
>>> all day. We have been also comparing the debuggers code between pharo 3/4
>>> (where the bug was is present) and pharo 7, but this was not necessarily
>>> straight forward as the code is not the same and there is no easy diff...
>>>
>>> ND, we have found that the problem may come from a wrong pragma
>>> marker. Just removing that pragma gives us back the same behaviour as in
>>> Pharo 3/4. :D
>>>
>>> https://github.com/pharo-project/pharo/pull/1621
>>>
>>> I know that the exception handling/debugging has been modified several
>>> times in the latest years (some refactorings, hiding contexts...), we
>>> unfortunately don't have tests for it, so I'd like some more pair of eyes
>>> on it. Ben, Martin could you take a look?
>>>
>>> Thanks all for the fish,
>>> Guille
>>>
>>
>>
>

-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] New Iceberg Version 1.2.1

[teso...@gmail.com]

Only adding a small detail, the Metacello expression is used to generate
the project that is offered.

Also I see it as the Detached head status for projects that are loaded
using Metacello. Maybe we should display the dirtiness in other way, but I
think that is not a problem.
It is normal that a project is marked dirty while used.

Cheers

On Tue, Aug 7, 2018 at 4:01 PM Guillermo Polito 
wrote:

> Hi,
>
> I'll write down some of the reasons of the project's design, like that I
> can afterwards copy paste it in the wiki :).
>
> First, this design did not came up from an egg. We worked on it for about
> two months. And it is thought to be backwards compatible and manage lots of
> metacello particularities. It may have things that are perfectible, sure,
> so let's discuss it.
>
> One of the main problems we saw in metacello, and that Iceberg inherited,
> was the "source subdirectory" thing. This source directory had to be
> specified in the CLIENT, meaning that every time we clone a repository we
> should know by heart the directory chose by its developer. Moreover, we
> lack a standard way to do it, so everybody does as he feels (root
> directory, src, source, repository, mc).
>
> This has some bad consequences:
>  - once a repository is referenced by some other project, it is more
> complicated to change its source directory. Imagine that tomorrow we set as
> standard that all git repos should have the code in src. Then voyage should
> change. And all its clients too.
>  - Making a typo in the code subdirectory means sometimes super ugly
> errors from metacello that are difficult to debug and understand (e.g.,
> "Cannot resolve BaselineOfMetacello WTF")
>
> Moreover, there was another problem that people started stumbling on: the
> fact that iceberg got confused sometimes thinking that an empty project was
> in filetree (to keep backwards compatibility with projects without a
> .properties).
>
> So we decided that for this release we wanted to revert a bit that
> situation. Think object: let's put the meta-data used to interpret a
> project's structure inside the project itself.
> The idea is that:
>
>  - each project should contain both a .project and a .properties file. The
> first can contain arbitrary project meta-data (such as the source
> directory). The second contains the cypress properties, which are needed to
> correctly interpret the code inside the source directory.
>  - a project without a .project file is an old project and cannot be
> interpreted, because we don't know the source directory
>  - a project without a .properties file is an old project and is by
> default transformed in a project with a #filetree properties file
>  - an old project cloned from iceberg detects the missing .project file
> and gives the user the opportunity to declare it (and then commit it
> explicitly)
>  - an old project cloned and loaded from a Metacello expression defining a
> source directory will honnor the source directory defined in the Metacello
> expression (for backwards compatibility, and we have ~500 tests about this).
>
> # About defaults values / forcing the user to define a project
>
> First, notice that even when the repositories you load are just marked as
> "dirty".
> This is because in memory we add a project to your repository.
> But you're not forced to commit it.
> Actually, you can still load packages and baselines from that repository
> without committing.
>
> This is in line with Iceberg's "explicitness". We try to not do any
> destructive operation without asking the user first (that's why we have
> several preview windows for pushing, pulling, checkout, merge..., and why
> contrastingly with monticello we show the committed changes on the commit
> window...). So, instead of transparently "adding the file" we have decided
> to modify the project in memory and let the user the responsibility to
> commit that file.
>
> If there's a drawback, is that the repository is marked as dirty. Which is
> a bit noisy, yes, but still I think it's not so bad compared with the
> previous drawbacks.
> To solve this, we could have some default values, yes, and only mark it as
> dirty if the project does not follow the default value.
> This could work, but right now all projects use different names for their
> source directories.
> So the question is, what would be a good default? I'd like to use 'src'
> since this is short, well known and less alien (all these in the sense that
> we do not lose anything and we have a lot to gain by using it).
> However, not much repositories use 'src' so it will still produce a lot of
> "noise"...
>
> But still! Committing that file is a one-time operation. Once people fix
> their repositories adding the project meta-data, you will not see them
> dirty anymore. So we can see this as a transition noise too...
>
> Of course, new ideas are welcome. I'll let Pablo and Esteban add their
> points of view on this too.
> Guille
>


-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] New Iceberg Version 1.2.1

[teso...@gmail.com]

New Iceberg Version 1.2.1 [
https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.0 +
https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.1]
Thanks to all brave users, issue reporters, and contributors :).

This version includes the implementation of projects.
Projects are a way of defining basic metadata of the repository.
Now, this metadata just includes the source directory.

This means that people do not need anymore to provide ALL THE TIME the
source directory.
Instead, every repository includes a project file that provides it.
Iceberg will guide people to create the given file. This file is managed by
Iceberg and people should not touch it from the outside or accept the
consequences :).

This version is integrated in the latest Pharo 7 images.

#New Features

 - #866 Introduce first version of Projects

#Infrastructure

 - #870 Improving tests of Metacello Integration
 - #903 Split basic tests from metacello tests in CI
 - #914 Sync Wiki with documentation directory automatically
 - #934 Manually check metacello integration dialogs
 - #935 Try to refrite the metacello integration tests.
 - #940 Installation in new Pharo should also bootstrap pharo repository

#Enhancements

 - #675 The History of a Method in Calypso should show a progress bar.
 - #788 Show progress during network operations (fetch,push, ...) Libgit.
 - #875 Tonel plugin does not delete .filetree Migration
 - #897 Update to OSSubprocess 1.0.1
 - #911 Repair Checkout branch should appear in "no project found"
 - #933 Fix Edit repository dialog
 - #939 IceInteractiveErrorVisitor duplicates IceTipInteractiveErrorVisitor
 - #944 Extract pharo repository bootstrap code into iceberg

#Bug Fixes

 - #828 Convert sources to tonel raises an Exception
 - #839 Infinite loop in IceGitLocalRepositoryType if the path is wrong
 - #849 VM crash while saving credentials Credential Manager
 - #851 .properties file is not create if project is imported and not
cloned.
 - #869 Error msg after an http timeout is unreadable
 - #873 Error with credential provider Credential Manager
 - #874 The integration with Metacello does not work when there is a src
directory, but not project file.
 - #880 Putting "." in project src field gives dnu
 - #884 Edit Project Dialog tries to select 'src' folder as default, but
does not handle if it does not exists
 - #886 Edit Project Dialog does not allow to select the root of the
repository as source directory
 - #888 Could not locate repository does not have subdirectory anymore.
 - #889 Loading an unborn project through metacello does not work
 - #894 GitHubAPI fails when the API responds with a 204 No Content
 - #901 I get a DNU projectName
 - #902 Edit project metadata does not detect default format
 - #918 Cloning pharo from a sync'ed repository does not correctly show
dirty packages
 - #928 Pull request cancel
 - #930 Changed ivar/slot name in stateful trait not recognized as a change
 - #931 DNU when trying to unload an Iceberg pkg where underlying Pharo pkg
has been removed
 - #932 Pharo repository forgets packages
 - #938 Do not catch assertion failures
 - #941 Iceberg pre-installed repository has wrong repair action
 - #946 Fixing Metacello Integration Tests
 - #948 Cloning from github creates an invalid remote
 - #950 Iceberg v1.2.0 breaks projects Metacello Integration bug
 - #951 New project window should be coherent on the vocabulary UI
enhancement
 - #953 Make remote request anonymous enhancement
 - #952 Cannot Clone Pharo Repository Pharo plugin bug
 - #955 Repair actions for repositories with fetch required are wrong UI bug

-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] [rmod] About the infinite debugger

[teso...@gmail.com]

Also, we have found that once the problem starts the image will present bad
behavior from that on.
Sometimes it can be fixed by restarting the UIProcess, but it is a brute
force process. You have to do it many times.

It is true that we cannot assert that the bug is not in other places.

On Tue, Aug 7, 2018 at 11:14 AM Tim Mackinnon  wrote:

> This is a good writeup - however I get infinite debuggers when not running
> tests too? So I’m wondering if there are multiple problems - or if this
> hints at a wider issue?
>
> Its not all of the time - but when you get it it, it seems to happen over
> and over again. Its possible its when using step-over though - so I will
> keep an eye on that.
>
> Tim
>
> On 7 Aug 2018, at 10:51, teso...@gmail.com wrote:
>
> Hello,
>   We have implemented a "patch" for Pharo 7, that is already integrated. I
> have created a slice to backport the "patch" to Pharo6.
>
> Basically, the previous situation is the following:
>
> - In the normal execution everything works, the problem is during the
> execution of over.
> - To implement over the debugger uses Context >> runUntilErrorOrReturnFrom:
> - This method adds a new context to handle exceptions in the stack trace.
> It takes the receiver and replaces the sender of the context with a new
> context handling the exceptions.
> - This error handling (using on:do:) handles UnhandledError and Halt.
> - When the MNU error gots to the nil context a UnhandledError is signal
> from the last signalling context of the MNU error.
> - This solution works correctly when it is not debugged when running a
> test.
>
> When we are running a tests there is a slight difference:
>
> - There is one more on:do: context that catches all the Errors. This on:do
> just do something and pass the exception.
> - As the UnhandledError is signal from the last signalling context (the
> one with the pass) it is not passing in the context inserted by
> runUntilErrorOrReturnFrom:, generating an infinite debugger as the
> exception is never catch.
> - This only happens with the MNU, as it retries to send the same message
> every time.
>
> I think the solution is to signal the UnhandledError always from the
> original signalling context. However, I am not sure to perform that change
> as it modifies the behaviour of exceptions and there are not proper tests
> to guarantee the expected behavior.
>
> I hope the problem is well explained, if it is not please ask me to
> clarify any point.
>
> Cheers,
>
> On Mon, Aug 6, 2018 at 9:59 AM Guillermo Polito 
> wrote:
>
>> Hi Steven,
>>
>> The thing about your fix was mainly that it only worked for the case of
>> running tests. We could however reproduce this bug from a playground too.
>>
>> At first, replacing #pass to #debug looked like a hack to me :) Just
>> looking at the code of  runCaseForDebug:, I felt the correct thing to do
>> there was to use #pass (and let any potential caller handle the exception
>> if he wants).
>> Otherwise, we should be able to understand:
>>  - can #pass be used? is it buggy?
>>  - does it work on any case or it should be avoided in some cases?
>>  - and how can we fix it (or at least document it?)?
>>
>> But still, I think you were in the right direction too, because your fix
>> shows a good intuition too: both #pass and #debug will do different
>> things with the exception.
>> -  #pass will **resignal** it from the current context,
>> -  #debug will just open a debugger on it.
>>
>> So that means that probably there was a problem when the exception was
>> handled in a calling context.
>>
>>
>>
>> On Mon, Aug 6, 2018 at 12:29 AM Steven Costiou 
>> wrote:
>>
>>> Hi,
>>>
>>> i had no answer to my comments on fogbuz (one of the first) so i assumed
>>> it was not a good idea.
>>>
>>> In the usecases i used to reproduce the bug, replacing "ex pass" by "ex
>>> debug" in runCaseForDebug:solved the problem. See the analysis on
>>> fogbuz.
>>>
>>> Did not have any side effect, but i do not know enough about the system
>>> and maybe it does. I think i already asked about that somewhere (here or on
>>> discord) but no answers.
>>>
>>> But maybe it is wrong to do that? I'd be happy to have feedback on that.
>>>
>>> Steven.
>>>
>>> Le 2018-08-05 22:27, Tim Mackinnon a écrit :
>>>
>>> Guys - this really needs attention - I've spend hours now trying to
>>> debug some code and most of it is in closing infinite debuggers. It makes a
>>> mockery 

Re: [Pharo-dev] [rmod] About the infinite debugger

[teso...@gmail.com]

olved in this. I'd hate to see regression
>> in the exception handling in an attempt to fix this bug.
>>
>>
>> After a look at at the pull request, I'm quite sure that removing the
>> prim 199 marker is the wrong thing to do. Thanks, Pablo, for restoring
>> it! The start of execution of exception handlers must be marked in order
>> for #findNextHandlerContext to work correctly. If these contexts are not
>> marked, exceptions signaled from inside an exception handler can find
>> the wrong handler. See the code and comment in #findNextHandlerContext.
>>
>> I'm afraid that I cannot immediately help with the debugger problem,
>> since I don't know the debugger nearly as well as I do the exception
>> handling code, and I'm going on vacation for a week in 20 minutes. :-)
>> Perhaps when I get back I can take a look at it if it is still a problem
>> by then.
>>
>> Regards,
>> -Martin
>>
>>
>>
>>
>
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> French National Center for Scientific Research - *http://www.cnrs.fr
> <http://www.cnrs.fr>*
>
>
> *Web:* *http://guillep.github.io* <http://guillep.github.io>
>
> *Phone: *+33 06 52 70 66 13
>


-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] IndexedSlots in combination with StatefulTraits

[teso...@gmail.com]

Hi Torsten,
   the problem is defining the behavior expected from the set of messages:

Today we have 3 (yes 3 awful) they are to keep compatibility with the
tools, we have to continue improving them.

- allSlots: returns all the slots defined in the hierarchy, in the same
class and in all the traits used in the hierarchy.
- localSlots: returns the slots that are defined in the own class without
the ones in the traits.
- slots: returns the slots that are defined in the class and not in the
superclasses.

The last message is the one that is disturbing, it is kept for
compatibility with the old behavior. In my opinion, localSlots should be
removed, and slots behave like localSlots.
It requires to change the tools.

If we need to know where the slots are defined we can ask the slots, the
slots know which is the class using the slot and where it is defined.

So, I will like to improve in any way.
About the implementation I like the one in #localSlots.
But it requires some work or letting the stuff broken until we fix them.

Cheers,
Pablo

On Tue, Jul 17, 2018 at 10:19 AM Torsten Bergmann  wrote:

> I guess I found a bug in accessing Slots using #slots in combination with
> IndexedSlots and traits.
> To reproduce use latest Pharo 7 (Build 1126)
>
> First create a class with a slot, note that the slot needs to be :
>
> Object subclass: #ClassA
> slots: { IndexedSlot named: #upper }
> classVariables: { }
> package: 'Slot-Bugs'
>
> As it is the first slot it internally receives an index 1 as you can check
> with "ClassA slots first".
>
> Now define a stateful trait with another indexed slot:
>
> Trait named: #StatefulTrait
> uses: {}
> slots: { IndexedSlot named: #slotFromTrait }
> category: 'Slot-Bugs'
>
> And create a new subclass using the new Trait
>
> ClassA subclass: #ClassB
> uses: StatefulTrait
> instanceVariableNames: ''
> classVariableNames: ''
> package: 'Slot-Bugs'
>
>
> 1. when you evaluate "ClassA slots"  it returns {#FirstSlot => Slot} which
> is correct
> 2. when you evaluate "StatefulTrait slots"  it returns {#slotFromTrait =>
> Slot} which is correct
> 3. when you evaluate "ClassB allSlots"  returns  "an
> OrderedCollection(#upper => InstanceVariableSlot #slotFromTrait =>
> InstanceVariableSlot)" which is OK
>
> but
>
> 4. when you evaluate "ClassB slots" it returns  {#slotFromTrait =>
> InstanceVariableSlot} which is NOT correct as class B does not define the
> slot, it is defined in the trait
>
>
> So I think 4. is wrong and reasons is the implementation of #slot:
>
>   slots
> "I remove the slots comming from a traitComposition"
> ^ super slots reject:[ :e  | self traitComposition slots
> includes:e ]
>
> If you debug you will notice that
>
>super slots   returns our #slotFromTrait with an index
> of 2 while
>self traitComposition slots   returns our #slotFromTrait with an index
> of 1 while
>
> which is the same #slotFromTrait but a different index - therefore it does
> not get removed.
>
>
> Dont know what is the best way to fix this without any side effects.
> Commenst and help appreciated.
>
> Thanks
> T.
>
>

-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] Pharo Bootstrap

[teso...@gmail.com]

Hi Guido,

The instructions in Guillep's repository have the instructions to create
the image to bootstrap (the host).
Usually it is not needed, in the productive process we are using an already
built image:

23.7 MB *bootstrapImage.zip*
<https://github.com/guillep/PharoBootstrap/releases/download/v1.4.1/bootstrapImage.zip>

To bootstrap Pharo, you need to clone the Pharo repository.

https://github.com/pharo-project/pharo


Usually on the pharo repository, you can run

BUILD_NUMBER=42 BOOTSTRAP_ARCH=32 sh ./bootstrap/scripts/bootstrap.sh


This script execute the scripts that are in ./bootstrap/scripts, they are
named 1-*, 2-*, 3-*, 4-*

The products are generated in the bootstrap-cache directory.

It will produce first a bootstrap.image that is the minimal image, you
cannot do much on it. But It will later load packages on top of it.
Usually the first useful image is the one with the compiler.

Cheers,
Pablo





On Mon, Jun 25, 2018 at 2:05 PM Guido Chari  wrote:

> I followed the instructions for building the image in
> https://github.com/guillep/PharoBootstrap and I get:
>
> ...RETRY->BaselineOfPharoBootstrapProcess
>
> ...RETRY->BaselineOfPharoBootstrapProcess
>
> ...FAILED->BaselineOfPharoBootstrapProcessCould not resolve:
> BaselineOfPharoBootstrapProcess [BaselineOfPharoBootstrapProcess] in
> /Users/guidochari/Documents/Projects/Research/Nopsys/CogNOS/image/pharo-local/package-cache
> filetree:///Users/guidochari/Documents/Projects/Research/Nopsys/PharoBootstrap
>
> I then resort to just execute the command that travis executes (
> ./scripts/install-packages.sh) and it works. But when I open the image I
> can not find PBBootstrapSpur3250, needed for running the bootstrapping.
>
> Best,
> Guido
>
>
>

-- 
Pablo Tesone.
teso...@gmail.com