Re: [Pharo-dev] Easy way to browse Hermes packages?

[teso...@gmail.com]

Hello,
   having the Hermes files and any Pharo7 image it is easy to inspect the
Hermes package.
It only had to be read from the fileSystem.

You can execute:

reader := HEBinaryReader new
stream: ('AST-Core.hermes' asFileReference) binaryReadStream;
yourself.


package := HEPackage readFrom: reader.


If you inspect the package you will see all the content in the Hermes file
(the format allows us to have different root elements in the file, but we
are exporting a package per file).
If it is useful we can include it as an inspector.

Cheers,
Pablo

On Fri, May 11, 2018 at 10:55 PM, Alistair Grant 
wrote:

> Hi Everyone,
>
> Is there an easy way to browse the contents of .hermes files (from the
> Pharo 7 bootstrap process)?  Or at least list the packages, classes
> and methods defined within?
>
> Thanks!
> Alistair
>
>


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

Re: [Pharo-dev] Minimal kernel

[teso...@gmail.com]

You can execute the bootstrap process.
However, maybe that is not required, as the bootstrapped images for Pharo7
are stored.


These are the latest (always):

Compiler:
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/lastSuccessfulBuild/artifact/bootstrap-cache/Pharo-compiler-7.0.0-alpha.build.1037.sha.7fc6bdf.arch.32bit.zip
Compiler + Traits:
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/lastSuccessfulBuild/artifact/bootstrap-cache/Pharo-core-7.0.0-alpha.build.1037.sha.7fc6bdf.arch.32bit.zip

These are the first images that are usable, the first one has a compiler
and the second adds the traits implementation.
As Esteban said, you can modify the process to bootstrap whatever you want.
However, having an image that does not have compiler it is more difficult
to use.

If you define better what do you call a minimal image we can help you more.

Cheers,
Pablo


On Mon, Jun 11, 2018 at 10:30 AM, Guido Chari  wrote:

> Hi,
>
> Is there any way to build a minimal (kernel) pharo image or at least some
> kind of small image without the whole default packages?
>
> Best regards,
> Guido.
>



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

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] [rmod] About the infinite debugger

[teso...@gmail.com]

;> years back, so *could* be involved 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] [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
>>>

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

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

[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

[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

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

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 pr

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

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]

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

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

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,
   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] 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] 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.
>
>
>
>

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

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] [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] [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] FOSDEM rooms are available

[teso...@gmail.com]

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

[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*)(&v))[index];
}

#include 

int main(){

long i;
int x;

scanf("%ld", &i);
scanf("%d", &x);

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 = &v + _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 = &v + _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*)(&v))[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] 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*)(&v))[index];
>> }
>>
>> #include 
>>
>> int main(){
>>
>> long i;
>> int x;
>>
>> scanf("%ld", &i);
>> scanf("%d", &x);
>>
>> 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 = &v + _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);
>

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*)(&v))[index];
>>> >> }
>>> >>
>>> >> #include 
>>> >>
>>> >> int main(){
>>> >>
>>> >> long i;
>>> >> int x;
>>> >>
>>> >> scanf("%ld", &i);
>>> >> scanf("%d", &x);
>>> >>
>>> >> printf("%ld",myFunc(i,x));
>>> >> }
>>> >>
>>> >> Basically, with -02, it generates the following code:
>>> >>
>>> >> myFunc:
>>> >>  movslq %esi, %rsi
>>> >>  movslq -8(%rsp,%rsi,4), %ra

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

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

[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

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

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

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

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

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

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

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

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

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

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

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

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

[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

[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

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

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

[Pharo-dev] Become Identity Forward

[teso...@gmail.com]

Hello,
   I'm trying to become forward some objects, these objects are stored
in IdentitySets so I need to copy the identityHash of the older objects to
the new ones. So that the IdentitySets are still well constructed.

I have read the comments in Array >> elementsForwardIdentityTo: copyHash: ,
and Array >> elementsForwardIdentityTo:, so I realise that the operation I
want to use is the first with copyHash in true or the later (that should be
doing the same, from the comments).

But after trying it, it is not working as expected.

If I try with:

x := Object new.
y := Object new.
z := Object new.

set := IdentitySet new.
set add: x.
set add: y.

hash := x identityHash.
bhash := x basicIdentityHash.

self assert:(set isHealthy).

z becomeForward: x copyHash: true.

set isHealthy "false"

z basicIdentityHash  = bhash. "false"
z identityHash = hash "false"

It is not working, but if I changed the copyHash parameter to false, it
works.

Something is not right (the comment or the implementation), because the
comment says:

"If copyHash is true, the identityHashes remain with the pointers rather
than with the
objects so that the objects in the receiver should still be properly
indexed in any
existing hashed structures after the mutation.  If copyHash is false, then
the hashes
of the objects in otherArray remain unchanged."

Do I have understanded everything wrong or there is something that is not
working (or at least the comment is not clear)

Is somebody using these operations?  How do you expect to work?

Maybe If you can  help me to understand the situation I can fix the
comments.

Thanks in advance.

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

[Pharo-dev] Failure in Tests Cases

[teso...@gmail.com]

Hi to all,
  I have tried to fix the CI process to show the failures and errors in
the tests in a more descriptive way, not only showing the failed test case,
but also the error and the stack trace of it.

After checking the problem, I have seen that the failures (and also errors)
are not registered with the Error that has produce the failure.

Of course, then I remembered that is why the TestRunner reruns the tests to
allow the debugging of the error.

What do you think of adding the produced exception to the TestResult?

Do you think it can have any other consequences? If it has, what if only
adding to the CI process?
Or perhaps storing a reduced version of the error (perhaps a String
representation, or something a lighter than the Error)

Thanks for all.


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

[Pharo-dev] Fixing a problem with FastTable Context Menus

[teso...@gmail.com]

Hello,
I have fixed a problem in the FastTable's context menus, but I don't
have access to the Moose/Glamour repository in SmalltalkHub. The package I
have modified is (Glamour-FastTable)

How I can proceed, can I get access to the repository (my user is
pabloTesone)? or how I should publish the change?

Thanks a lot.

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

Re: [Pharo-dev] Fixing a problem with FastTable Context Menus

[teso...@gmail.com]

Thanks!

On Tue, Oct 11, 2016 at 11:37 AM, Esteban Lorenzano 
wrote:

> now you have rights :)
>
> On 11 Oct 2016, at 11:13, teso...@gmail.com wrote:
>
> Hello,
> I have fixed a problem in the FastTable's context menus, but I don't
> have access to the Moose/Glamour repository in SmalltalkHub. The package I
> have modified is (Glamour-FastTable)
>
> How I can proceed, can I get access to the repository (my user is
> pabloTesone)? or how I should publish the change?
>
> Thanks a lot.
>
> --
> Pablo Tesone.
> teso...@gmail.com
>
>
>


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

Re: [Pharo-dev] [IMPORTANT] Following changes in the bootstrapping process

[teso...@gmail.com]

methods required for system navigation to the
>>> Ring-Navigation
>>> > package
>>> > - Remove usages of #translated in the kernel
>>> > - Refactored the bootstrapping classes to remove duplications
>>> > - Cleaning up dependencies in CompiledMethod>>printOn:
>>> > - fix path printing
>>> >
>>> > We need to merge these changes at once and of course it can cause some
>>> > conflicts with the existing pull requests or external code. Anyway, we
>>> need
>>> > to merge it as soon as possible.
>>> >
>>> > So please, try to look at the PR and test the resultant image [1] to
>>> avoid
>>> > some major problems.
>>> >
>>> > [1]
>>> > https://ci.inria.fr/pharo/view/7.0/job/70-PR-Check-Load/last
>>> SuccessfulBuild/artifact/bootstrap-cache/Pharo7.0-32bit-9c0691d.zip
>>> >
>>> > Cheers,
>>> > -- Pavel
>>> >
>>>
>>>
> --
>
>
>
> Guille Polito
>
>
> Research Engineer
>
> 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 <+33%206%2052%2070%2066%2013>
>
>


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

Re: [Pharo-dev] [IMPORTANT] Following changes in the bootstrapping process

[teso...@gmail.com]

Hi again,
   thanks for the clarification, I haven't understood the question
initially, but now I think I can answer it.

Hermes is only exporting the classes, not objects. so it does not have to
handle complex graphs of objects. Basically it serializes the definition of
the classes, traits and methods. Then they are loaded in sequence. The only
caring during the generation is to serialize first the superclasses, and
then the subclasses. There is no way of serializing objects outside the
classes, methods, traits and literals in a method.

So the answer is that is not using Parcels or Fuel architecture because
they are intended for different uses. Also the format itself has no special
design or considerations to be fast to generate or fast to read (as It
happens with Fuel)

Cheers,
Pablo

On Tue, Aug 1, 2017 at 9:16 PM, Eliot Miranda 
wrote:

> Hi Pablo,
>
> I understand that Hermes has its own format.  My question was about
> architecture. The Parcels/Fuel architecture is, AFAIA, the best
> architecture for binary storage because it is virtual, is fast to load and
> cleanly separates loading from initialization.  What do I mean?
>
> - concrete formats like ImageSegment are tied to internal representations
> in the VM and do are difficult to read in forever FB systems and very hard
> to write in foreign systems.  So a virtual format (like BOSS, Fuel,
> Parcels, etc) is better but unless done well can be slow
>
> - a first generation system like BOSS is a flattening of a graph traversal
> using a simple grammar.  Each phrase is either an object reference (object
> id) or an object definition (object is followed by type info and contents,
> contents being a sequence of phrases.  This is slow to parse (because each
> phrase must be decoded), and has invalid intermediate states (e.g. a Set
> whose contents are not all present, hence whose external hash may change
> during loading, etc).  A second generation system like Parcels and Fuel
> separates objects from references (nodes from arcs) and batches object
> creation, grouping all instances of a given class for bulk, and hence fast,
> instantiation.  Following my the objects are the references.  So loading
> has three phases:
> - instantiate the objects
> - connect the graph by filling in object references
> - initialize the objects that require it (e.g. rehash sets)
>
> Consequently the writer must be two pass, the first pass to collect the
> objects in the graph and sort them by class, the second to write the nodes
> followed by the references
>
> So let me ask again, does Hermes use the Parcels/Fuel architecture?
>
> _,,,^..^,,,_ (phone)
>
> On Aug 1, 2017, at 11:52 AM, "teso...@gmail.com" 
> wrote:
>
> Hi Eliot,
>
> The last version of Hermes, that I have generated today and have to be
> tested for real yet, is able to load and save from and to 32 and 64 bits,
> handling the conversion. Because the Hermes representation (if we can call
> it like that, because is really simple, does not care about the
> architecture).
>
> Hermes is using a custom format completely separated from Fuel or any
> other tool.
>
> This is a consequence of the design of Hermes. Hermes has been designed to
> only work as light way of loading code during the bootstrap. So that, it is
> heavily coupled with Pharo (it can be changed, for example implementing
> another loader / installer) and uses only really core classes.
>
> Of course it can be extended and used in another Smalltalk dialects, but I
> am not sure if the tool can be useful for them, or even for the Pharo
> community outside the Pharo bootstrap process.
>
> Today to be useful outside the bootstrap process, some work has to be done
> (perhaps a lot), but mainly new use cases have to be thinked. Once the
> Compiler, Monticello or Metacello is available, there is no need for
> Hermes.  It is only used to generate some binary loadable packages for the
> compiler from the source code.
>
> Again, it was only thinked as a tool to improve the speed during the
> bootstrap. However, if somebody has ideas to use it or want to collaborate
> are  of course welcomed.
>
> Hermes is actually in Github, because to me is more comfortable to have it
> there,  but if somebody is really wanting to use it we can manage to
> have an export process to Smalltalkhub.
>
> I hope I have clarified a little the idea behind Hermes.
>
> Maybe you have better ideas of what can we do with it.
>
>
> On Tue, Aug 1, 2017 at 7:59 PM, Eliot Miranda 
> wrote:
>
>> Hi Guille,
>>
>> On Aug 1, 2017, at 4:29 AM, Guillermo Polito 
>> wrote:
>>
>>
>>
>> On Tue, Aug 1, 2017 at 12:57 PM, philippe.b...@highoctane.be <
>> philippe.b...@gmail.com> wro

Re: [Pharo-dev] [IMPORTANT] Following changes in the bootstrapping process

[teso...@gmail.com]

Hi,
Yes for sure there are objects, and that is very powerful, but
comparing the algorithm of serialization of Hermes with Fuel (I don't
really know Parcels) is not possible. It is like comparing Filetree with
Fuel, The problems they have to take care are completely different.

Maybe I am not seeing the point.

Cheers.

On Tue, Aug 1, 2017 at 10:25 PM, Eliot Miranda 
wrote:

> Hi Pablo,
>
> On Tue, Aug 1, 2017 at 12:36 PM, teso...@gmail.com 
> wrote:
>
>> Hi again,
>>thanks for the clarification, I haven't understood the question
>> initially, but now I think I can answer it.
>>
>> Hermes is only exporting the classes, not objects. so it does not have to
>> handle complex graphs of objects. Basically it serializes the definition of
>> the classes, traits and methods. Then they are loaded in sequence. The only
>> caring during the generation is to serialize first the superclasses, and
>> then the subclasses. There is no way of serializing objects outside the
>> classes, methods, traits and literals in a method.
>>
>
> Classes, traits, methods, literals *are* a graph of objects :-). The
> Parcel architecture, from which Fuel derived its architecture, was designed
> for loading code in VisualWorks.  In fact, last time I looked Parcels were
> used only to store code and not as a general purpose (de)serializer.
>
> So the answer is that is not using Parcels or Fuel architecture because
>> they are intended for different uses.
>>
>
> Well, I don't think that's the reason ;-), but fine.  I understand that it
> doesn't use this architecture.  Thanks.
>
>
>> Also the format itself has no special design or considerations to be fast
>> to generate or fast to read (as It happens with Fuel)
>>
>> Cheers,
>> Pablo
>>
>> On Tue, Aug 1, 2017 at 9:16 PM, Eliot Miranda 
>> wrote:
>>
>>> Hi Pablo,
>>>
>>> I understand that Hermes has its own format.  My question was about
>>> architecture. The Parcels/Fuel architecture is, AFAIA, the best
>>> architecture for binary storage because it is virtual, is fast to load and
>>> cleanly separates loading from initialization.  What do I mean?
>>>
>>> - concrete formats like ImageSegment are tied to internal
>>> representations in the VM and do are difficult to read in forever FB
>>> systems and very hard to write in foreign systems.  So a virtual format
>>> (like BOSS, Fuel, Parcels, etc) is better but unless done well can be slow
>>>
>>> - a first generation system like BOSS is a flattening of a graph
>>> traversal using a simple grammar.  Each phrase is either an object
>>> reference (object id) or an object definition (object is followed by type
>>> info and contents, contents being a sequence of phrases.  This is slow to
>>> parse (because each phrase must be decoded), and has invalid intermediate
>>> states (e.g. a Set whose contents are not all present, hence whose external
>>> hash may change during loading, etc).  A second generation system like
>>> Parcels and Fuel separates objects from references (nodes from arcs) and
>>> batches object creation, grouping all instances of a given class for bulk,
>>> and hence fast, instantiation.  Following my the objects are the
>>> references.  So loading has three phases:
>>> - instantiate the objects
>>> - connect the graph by filling in object references
>>> - initialize the objects that require it (e.g. rehash sets)
>>>
>>> Consequently the writer must be two pass, the first pass to collect the
>>> objects in the graph and sort them by class, the second to write the nodes
>>> followed by the references
>>>
>>> So let me ask again, does Hermes use the Parcels/Fuel architecture?
>>>
>>> _,,,^..^,,,_ (phone)
>>>
>>> On Aug 1, 2017, at 11:52 AM, "teso...@gmail.com" 
>>> wrote:
>>>
>>> Hi Eliot,
>>>
>>> The last version of Hermes, that I have generated today and have to be
>>> tested for real yet, is able to load and save from and to 32 and 64 bits,
>>> handling the conversion. Because the Hermes representation (if we can call
>>> it like that, because is really simple, does not care about the
>>> architecture).
>>>
>>> Hermes is using a custom format completely separated from Fuel or any
>>> other tool.
>>>
>>> This is a consequence of the design of Hermes. Hermes has been designed
>>> to only work as light way of loading code during the bootstrap. So that, it

Re: [Pharo-dev] [IMPORTANT] Following changes in the bootstrapping process

[teso...@gmail.com]

Hi Mariano,
The definition is not serialized. What is serialized is all the
information to regenerate the class (eg: superclass name, instance variable
names, class variables names, share pool names, category, layout class, and
so on). This information is later used to regenerate the class as it is
created initially by the class builder and installer. The same happens with
the methods, they are built up from scratch without using the compiler. The
bytecode is stored, the literals are serialized and the information in the
header is serialized, as it has to be rebuilt when install.

The same is applicable to the traits and extension methods.

Basically it can be seen as a class builder / installer, that get all the
information from the serialized version and not from the text
representation of the class or the methods.

That's why I said Hermes is so couple with Pharo.

Thanks for clarifying, I am starting to understand where yours doubts came
from.

Cheers,
Pablo

On Tue, Aug 1, 2017 at 10:52 PM, Mariano Martinez Peck <
marianop...@gmail.com> wrote:

>
>
> On Tue, Aug 1, 2017 at 5:31 PM, teso...@gmail.com 
> wrote:
>
>> Hi,
>> Yes for sure there are objects, and that is very powerful, but
>> comparing the algorithm of serialization of Hermes with Fuel (I don't
>> really know Parcels) is not possible. It is like comparing Filetree with
>> Fuel, The problems they have to take care are completely different.
>>
>> Maybe I am not seeing the point.
>>
>>
> Let me add one sentence that may explain Eliot questions... if you
> serialize the class definition, then it means you would need the compiler.
> I guess Eliot may be interested in NOT having the compiler at all and
> instead bring classes directly from binary format (like Fuel / Tanker )
>
>
>
>
>> Cheers.
>>
>> On Tue, Aug 1, 2017 at 10:25 PM, Eliot Miranda 
>> wrote:
>>
>>> Hi Pablo,
>>>
>>> On Tue, Aug 1, 2017 at 12:36 PM, teso...@gmail.com 
>>> wrote:
>>>
>>>> Hi again,
>>>>thanks for the clarification, I haven't understood the question
>>>> initially, but now I think I can answer it.
>>>>
>>>> Hermes is only exporting the classes, not objects. so it does not have
>>>> to handle complex graphs of objects. Basically it serializes the definition
>>>> of the classes, traits and methods. Then they are loaded in sequence. The
>>>> only caring during the generation is to serialize first the superclasses,
>>>> and then the subclasses. There is no way of serializing objects outside the
>>>> classes, methods, traits and literals in a method.
>>>>
>>>
>>> Classes, traits, methods, literals *are* a graph of objects :-). The
>>> Parcel architecture, from which Fuel derived its architecture, was designed
>>> for loading code in VisualWorks.  In fact, last time I looked Parcels were
>>> used only to store code and not as a general purpose (de)serializer.
>>>
>>> So the answer is that is not using Parcels or Fuel architecture because
>>>> they are intended for different uses.
>>>>
>>>
>>> Well, I don't think that's the reason ;-), but fine.  I understand that
>>> it doesn't use this architecture.  Thanks.
>>>
>>>
>>>> Also the format itself has no special design or considerations to be
>>>> fast to generate or fast to read (as It happens with Fuel)
>>>>
>>>> Cheers,
>>>> Pablo
>>>>
>>>> On Tue, Aug 1, 2017 at 9:16 PM, Eliot Miranda 
>>>> wrote:
>>>>
>>>>> Hi Pablo,
>>>>>
>>>>> I understand that Hermes has its own format.  My question was
>>>>> about architecture. The Parcels/Fuel architecture is, AFAIA, the best
>>>>> architecture for binary storage because it is virtual, is fast to load and
>>>>> cleanly separates loading from initialization.  What do I mean?
>>>>>
>>>>> - concrete formats like ImageSegment are tied to internal
>>>>> representations in the VM and do are difficult to read in forever FB
>>>>> systems and very hard to write in foreign systems.  So a virtual format
>>>>> (like BOSS, Fuel, Parcels, etc) is better but unless done well can be slow
>>>>>
>>>>> - a first generation system like BOSS is a flattening of a graph
>>>>> traversal using a simple grammar.  Each phrase is either an object
>>>>> reference (object id) or an object definition (object is f

Re: [Pharo-dev] About cr and lf

[teso...@gmail.com]

To me it is clear that cr and lf should be in streams. But they should put
the 'cr' or 'lf' character only. And of course the platform independent
newline should be also.

The first (cr, lf) should be used by the code wanting to have absolute
control of what is in the stream. The later (newline) when you just want a
new line.

The two have completely different behaviour, ones are really low level, the
other is higher level.

On 4 Aug 2017 14:20, "Esteban Lorenzano"  wrote:

>
> > On 4 Aug 2017, at 14:06, Stephane Ducasse 
> wrote:
> >
> > Well. This is not implemented like that in Pharo.
> >
> > cr is bad because it does not mean that it is independent of the
> platform.
> > So cr can be redefined as newLine and keep but not used inside the
> system.
>
> sometimes you actually want to write a cr (or a lf). So it needs to remain
> in the system, of course.
> now, including #newLine can be cool (most of the times you want the
> “platform compatible” new line). Also I would consider including #nl,
> abbreviated… just for convenience :P
>
> Esteban
>
> >
> > Stef
> >
> > On Fri, Aug 4, 2017 at 12:50 PM, Jan Vrany 
> wrote:
> >> On Fri, 2017-08-04 at 12:03 +0200, Stephane Ducasse wrote:
> >>> Hi guys
> >>>
> >>> While writing pillar code, I ended up using "stream cr" and it
> >>> worries
> >>> me to still expand usage
> >>> of a pattern I would like to remove.
> >>>
> >>> Let us imagine that we would like to prepare the migration from cr.
> >>> I was thinking that we could replace cr invocation by newLine so that
> >>> after newLine
> >>> could be redefined as
> >>>
> >>> Stream >> newLine
> >>>   self nextPutAll: OSPlatform current lineEnding
> >>>
> >>>
> >>> what do you think about this approach?
> >>
> >> Why not? But please keep #cr.
> >>
> >> Section 5.9.4.1 of ANSI reads:
> >>
> >> Message: cr
> >>
> >> Synopsis
> >> Writes an end-of-line sequence to the receiver.
> >>
> >> Definition: 
> >> A sequence of character objects that constitute the implementation-
> >> defined end-of-line sequence is added to the receiver in the same
> >> manner as if the message  #nextPutAll: was sent to the receiver with
> >> an argument string whose elements are the sequence of characters.
> >>
> >> Return Value
> >> UNSPECIFIED
> >> Errors
> >> It is erroneous if any element of the end-of-line sequence is an
> >> object that does not conform to the receiver's sequence value type .
> >>
> >> my 2c,
> >>
> >> Jan
> >>
> >>>
> >>> Stef
> >>>
> >>
> >
>
>
>

Re: [Pharo-dev] Pharo7 and full block closures

[teso...@gmail.com]

Hi Clément,
   If you need help with the CI, I can also help you. We can create it as a
another parallel stage in the PR validation. So once it is stable we can
detect asap changes that break it.

Cheers,

On 22 Sep 2017 18:45, "Clément Bera"  wrote:

Well we need to use them but the integration process is difficult to deal
with: we need to change the bootstrap to cross compile to the other
bytecode set. I need to have some time to focus on it amd I need the help
of someone understanding the bootstrap like Guille

On Sep 22, 2017 18:31, "Stephane Ducasse"  wrote:

> Hi clement
>
> let us know how we can help because he all want the new closures.
>
> Stef
>
> On Fri, Sep 22, 2017 at 11:11 AM, Clément Bera 
> wrote:
> > I totally agree with you on this.
> >
> > For a while I had a CI job that was trying to execute Sista on the latest
> > version of Pharo and VM, and sent me a mail when something had gone
> wrong. I
> > disabled it when there was problems on the CI, I will make it work again.
> > This way I am notified and I can update the Sista code as Pharo 7 is
> > developed. That helps a lot.
> >
> > On the Pharo CI the time to run tests matters hence I will try to find
> > another solution to test full block and the other bytecode set. I did
> not do
> > that because I hope I can change Pharo to use full block by default soon,
> > but since they're broken...
> >
> > Regards
> >
> >
> >
> > On Fri, Sep 22, 2017 at 10:58 AM, Holger Freyther 
> > wrote:
> >>
> >>
> >> > On 22. Sep 2017, at 13:33, Clément Bera 
> wrote:
> >>
> >>
> >> Hi Clement,
> >>
> >>
> >> > Sista will work for the release of Pharo 7 as it did for Pharo 6 and
> 6.1
> >> > but it won't work every day during the alpha of Pharo 7 and no sane
> >> > framework developer can guarantee that. Sista does not work currently
> in
> >> > Pharo 7 due to some changes breaking the full block closures, I am
> going to
> >> > fix it but even then in the incoming months there is a high chance
> that
> >> > another change in Pharo 7 breaks it again, so I would never recommend
> to use
> >> > it with the alpha.
> >>
> >>
> >> thank you for your response. I didn't expect it to work (after all you
> >> label it "Alpha" and I ran into issues already) but my intention for the
> >> mail was a bit different. Let me try to briefly explain my motivation.
> In my
> >> experience:
> >>
> >> (1) Software not executed stops to work (or never "worked")
> >> (2) The earlier breakage is detected the less expensive it is to fix.
> >>
> >> My assumption is that Opal is part of Pharo and that we look at a
> >> regression of the Opal compiler and/or how it interacts with the rest
> of the
> >> image. As it might be easier to understand/fix it now than later I
> brought
> >> it up. From my point of view I wonder if we want to add ~50s to the CI
> >> process to execute:
> >>
> >> CompilationContext bytecodeBackend: OpalEncoderForSistaV1.
> >> CompilationContext usesFullBlockClosure: true.
> >> OpalCompiler recompileAll.
> >>
> >>
> >> Is there any value in doing so?
> >>
> >>
> >> cheers
> >>
> >> holger
> >>
> >>
> >> PS
> >>
> >> (2) The intuitive explanation is that the cost of analysis is a lot
> lower
> >> the earlier the problem is detected. There are fewer potential changes
> that
> >> lead to the breakage and the people involved will remember what/why
> they did
> >> reducing the cost of fixing. Ideally things are found to be broken and
> fixed
> >> before integration.
> >>
> >> Maybe an analogy is old-school aviation navigation.. the earlier a
> mistake
> >> is found in navigation the closer to the original course...
> >
> >
>
>

Re: [Pharo-dev] Why 2017 sizeInMemory = 0?

[teso...@gmail.com]

Because it is an immediate value.

On 26 Oct 2017 10:06, "Denis Kudriashov"  wrote:

Hi.

Question from discord, why:

2017 sizeInMemory = 0

?

Looks like a bug, but maybe there is some reason for this.

[Pharo-dev] New Version of Zinc is using a deprecated method and breaking all the users

[teso...@gmail.com]

Hello,
   Zinc-Http is using a method that has been deprecated long time ago
and is affecting all the users of Zinc.

I have created the issue (
https://pharo.fogbugz.com/f/cases/20596/Zinc-should-not-use-asBytesDescription-as-it-is-deprecated)
and a PR to fix it in Pharo (https://github.com/pharo-project/pharo/pull/401
).

However, this fix should be pushed to the Zinc repository.

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

Re: [Pharo-dev] [Pharo 7.0-dev] Build #250: 20616-Convert-file-format-to-tonel

[teso...@gmail.com]

This is a problem in the network, Guille is going to restart the nodes.

On Thu, Nov 2, 2017 at 3:08 PM,  wrote:

> There is a new Pharo build available!
>
> The status of the build #250 was: FAILURE.
>
> The Pull Request #423 was integrated: "20616-Convert-file-format-to-tonel"
> Pull request url: https://github.com/pharo-project/pharo/pull/423
>
> Issue Url: https://pharo.fogbugz.com/f/cases/20616
> Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%
> 20pull%20request%20and%20branch%20Pipeline/job/development/250/
>



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

Re: [Pharo-dev] Reviewing Changes ?

[teso...@gmail.com]

Hello Sven,
the easy way I found to review an image of the change in a PR is to use
the image from the CI server.

In
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/view/change-requests/
you can see all the jobs of the PR (every PR is run in the CI as soon as it
is created or updated).

There you can find the PR by its number, for example:

https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/view/change-requests/job/PR-797/

And then later you can check the results of the tests or downloading an
image with the changes in Last Successful Artifacts:

https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/view/change-requests/job/PR-797/

The images are inside the folder "bootstrap-cache" and you should take the
Pharo-32bits-.zip or Pharo-64bits-.zip.

Cheers.

On Mon, Feb 5, 2018 at 1:54 PM, Sven Van Caekenberghe  wrote:

> Hi,
>
> With pull requests, it is relatively easy to see what changed in GitHub.
>
> Eg. Marcus' latest fix:
>
>   https://github.com/pharo-project/pharo/pull/797
>
> shows 6 files/classes changed, reasonably readable diff.
>
> How does one review such a PR in an image, to test it out ?
> Has someone written a guide on how to do this best/most-easily ?
> How is/can this be related to contributing ?
>
> Sven
>
>


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

Re: [Pharo-dev] Do we remove TClass?

[teso...@gmail.com]

Hi Stef,
in the new implementation of Traits I have moved that traits to a
package, they are not used at all in the image but they are used by other
projects. For example, they are used by Ficus.

Cheers,
Pablo

On Sun, Feb 11, 2018 at 6:01 PM, Stephane Ducasse 
wrote:

> Then I do not get it what it this
>
> Trait >> private_subclass: t instanceVariableNames: f
> classVariableNames: d poolDictionaries: s package: cat
>"Compatibility purposes"
>^self error: 'Traits cannot have subclasses'.
>
> How raising an error would make something compatible
> To be this is stupid code.
>
> Stef
>
>
>
> On Sun, Feb 11, 2018 at 5:51 PM, Stephane Ducasse
>  wrote:
> > Hi Happy core developers
> >
> > do we remove TClass? Because it is duplicated code, no?
> >
> > Stef
>
>


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

Re: [Pharo-dev] [Pharo 7.0-dev] Build #553: 20941-deprecate-theMetaclass-and-the-theNonMeta

[teso...@gmail.com]

Hi, I have already checked this error.

The error is random in the development branch, although in my branch is
happening always.
I have detected that the problem is that the GC is corrupting the the
objects when it has to enlarge the Eden.

This problem also was detected some months ago by Pavel when he tried to
load a big baseline (Seaside in that moment).
I have solved it in a similar way, increasing the Eden size before loading
BaselineOfIDE.

Since this "hack" my branch is running normally (well... it has other
problems with some tests... but that is expected).
Maybe Clement can through more light to the matter.

Cheers,


On Fri, Feb 16, 2018 at 12:50 PM, Marcus Denker 
wrote:

>
>
> On 16 Feb 2018, at 12:22, ci-pharo-ci-jenki...@inria.fr wrote:
>
> There is a new Pharo build available!
>
> The status of the build #553 was: FAILURE.
>
> The Pull Request #888 was integrated: "20941-deprecate-theMetaclass-
> and-the-theNonMeta"
> Pull request url: https://github.com/pharo-project/pharo/pull/888
>
> Issue Url: https://pharo.fogbugz.com/f/cases/20941
> Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%
> 20pull%20request%20and%20branch%20Pipeline/job/development/553/
>
>
> FAILURE due to VM crash:
>
> [32] replaceFrom:to:with:startingAt:
> [32] replaceFrom:to:with:startingAt:
> [32] replaceFrom:to:with:startingAt:
> [32] basicIdentityHash
> [32] replaceFrom:to:with:startingAt:
> [32] replaceFrom:to:with:startingAt:
> [32] new:
> [32] new:
> [32]
> [32] stack page bytes 4096 available headroom 2788 minimum unused headroom 156
> [32]
> [32]  (Segmentation fault)
> [32] ./vm/pharo: line 11: 13443 Aborted 
> "$DIR"/"pharo-vm/pharo" --nodisplay "$@"
>
>
>


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

Re: [Pharo-dev] [Pharo 7.0-dev] Build #553: 20941-deprecate-theMetaclass-and-the-theNonMeta

[teso...@gmail.com]

Hi Cyril,

The problem in the bootstrap is happening in Linux 32bits.
I cannot say nothing about problems in 64bits.
Try creating a bigger Eden, you should run

Smalltalk vm parameterAt: 45 put: (Smalltalk vm parameterAt: 44) * 4

The changes are only effected in the next loading of the image, so you
should do something like:

./pharo "Pharo.image" eval --save "Smalltalk vm parameterAt: 45 put:
(Smalltalk vm parameterAt: 44) * 4"

And then try to load the configuration.

Marcus,
  I am opening an issue for that.

Cheers,


On Fri, Feb 16, 2018 at 3:57 PM, Cyril Ferlicot 
wrote:

> On Fri, Feb 16, 2018 at 2:07 PM, teso...@gmail.com 
> wrote:
> > Hi, I have already checked this error.
> >
> > The error is random in the development branch, although in my branch is
> > happening always.
> > I have detected that the problem is that the GC is corrupting the the
> > objects when it has to enlarge the Eden.
> >
> > This problem also was detected some months ago by Pavel when he tried to
> > load a big baseline (Seaside in that moment).
> > I have solved it in a similar way, increasing the Eden size before
> loading
> > BaselineOfIDE.
> >
> > Since this "hack" my branch is running normally (well... it has other
> > problems with some tests... but that is expected).
> > Maybe Clement can through more light to the matter.
> >
>
> Hi,
>
> On what VM is this happening?
>
> For linux 64bits vm I get a lot a random crash during configuration
> loading. But these crash vanish when using the latest Pharo 70 vm for
> linux 64bits.
>
> > Cheers,
> >
> >
> >
> > --
> > Pablo Tesone.
> > teso...@gmail.com
>
>
>
> --
> Cyril Ferlicot
> https://ferlicot.fr
>
> http://www.synectique.eu
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
>
>


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

Re: [Pharo-dev] [Request for comment] Hermes package

[teso...@gmail.com]

Hi,
Sorry I have missed the comments. I will add them as soon as possible.
You are right we should improve the quality, thanks for checking it and
remembering everybody.

Cheers,

On Wed, Feb 28, 2018 at 10:42 AM, Torsten Bergmann  wrote:

> ... to all participating authors of the Hermes package:
>
> PLEASE COMMENT YOUR CLASSES SO WE CAN CLEAN UP AND PREPARE A
> POLISHED PHARO 7 RELEASE
>
> So many uncommented classes in there today...
>
> We can do better and we should. I dont ask for detailed documentation
> but a single comment why the class is there or what it should care
> about is often already enough.
>
> If you have time to write code then you also have the time to write
> a simple class comment!
>
> So please do you homework (which is a general request to authors
> of other packages as well)
>
> Bye
> T.
>
>


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

Re: [Pharo-dev] [Request for comment] Hermes package

[teso...@gmail.com]

Nice Idea, I have added comments to the packages, classes and methods. This
will be in the new version that will be integrated with the new Traits
implementation.
I am still cleaning some comments that Denis and Pavel have done and we can
integrate it.

Then we change the name, I liked BootstrapCodeLoader, I think I can find a
non conflicting prefix.

Cheers.

On Thu, Mar 1, 2018 at 4:29 PM, Stephane Ducasse 
wrote:

> +1
>
> On Thu, Mar 1, 2018 at 2:42 PM, Denis Kudriashov 
> wrote:
> > While it is very bootstrap oriented library it would be better to rename
> it
> > to BootstapCodeLoader.
> > Or PharoBootstrap-CodeLoader because we already use this prefix
> >
> > 2018-03-01 13:20 GMT+01:00 Stephane Ducasse :
> >>
> >> Hermes is a private binary format that is used to load compiled code
> >> when there is no compiler during the bootstrap.
> >> So basically hermes is loading the compiler to be able to compile
> >> other packages.
> >>
> >> Stef
> >>
> >> On Wed, Feb 28, 2018 at 4:55 PM, Alexandre Bergel
> >>  wrote:
> >> > Side question: What is Hermes?
> >> >
> >> > Alexandre
> >> >
> >> >> On Feb 28, 2018, at 1:42 AM, Torsten Bergmann 
> wrote:
> >> >>
> >> >> ... to all participating authors of the Hermes package:
> >> >>
> >> >> PLEASE COMMENT YOUR CLASSES SO WE CAN CLEAN UP AND PREPARE A
> >> >> POLISHED PHARO 7 RELEASE
> >> >>
> >> >> So many uncommented classes in there today...
> >> >>
> >> >> We can do better and we should. I dont ask for detailed documentation
> >> >> but a single comment why the class is there or what it should care
> >> >> about is often already enough.
> >> >>
> >> >> If you have time to write code then you also have the time to write
> >> >> a simple class comment!
> >> >>
> >> >> So please do you homework (which is a general request to authors
> >> >> of other packages as well)
> >> >>
> >> >> Bye
> >> >> T.
> >> >>
> >> >
> >> >
> >>
> >
>
>


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

[Pharo-dev] Released versions in Pharo Bootstrap

[teso...@gmail.com]

Hello,
 i have seen in the latest version of Pharo baselines pointing to
"floating" versions. A version that is not fixed. I want to know why this
is like that?

To me this is basically wrong, because basically this goes against the idea
of having repeatable builds. Also using semantic versions with tags in Git
is wrong, as tags should be immutable (that is why you have to use --force
to update them, in Guille's words "If you have to force it, it is not
good").

Cheers,

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

Re: [Pharo-dev] Released versions in Pharo Bootstrap

[teso...@gmail.com]

Yes, I understand for the developer version, you should have a developer
branch and use that. The problem is for the Pharo image only.

On Mon, Mar 5, 2018 at 3:39 PM, Pavel Krivanek 
wrote:

> Hi,
>
> it is an issue of Calypso dependencies. I discussed it with Denis
> before Calypso integration and he would like to change it but, for
> now, it would make the development for him much harder because he
> needs a way how to load the latest bleeding edge versions of the
> packages and no one was able to tell him the proper way how to support
> both scenarios (loading of a specific release and loading of the
> development versions) with baselines without needing of duplicate
> them.
>
> Anyway, I agree that the current state must be fixed as soon as possible.
>
> Cheers,
> -- Pavel
>
> 2018-03-05 15:30 GMT+01:00 teso...@gmail.com :
> > Hello,
> >  i have seen in the latest version of Pharo baselines pointing to
> > "floating" versions. A version that is not fixed. I want to know why
> this is
> > like that?
> >
> > To me this is basically wrong, because basically this goes against the
> idea
> > of having repeatable builds. Also using semantic versions with tags in
> Git
> > is wrong, as tags should be immutable (that is why you have to use
> --force
> > to update them, in Guille's words "If you have to force it, it is not
> > good").
> >
> > Cheers,
> >
> > --
> > Pablo Tesone.
> > teso...@gmail.com
>
>


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

Re: [Pharo-dev] pharo bootstrap is in inconsistent state

[teso...@gmail.com]

Hi,
 sorry my mistake when updating the scripts. As the bootstrap.sh is not
executed during the Jenkins process it has not been validated (locally I'm
not using that script, because is trying to download each time the VM and
the bootstraping process image)
The correct line is the one from the JenkinsFile, it should be something
like:

./pharo ./Pharo.image bootstrap/scripts/bootstrap.st --ARCH=${architecture}
--BUILD_NUMBER=${env.BUILD_ID} --quit

I will submit a PR to fix it, as soon as the CI infrastructure is less on
fire.
Until the fix, if you are building the image locally you can change the
error line with:

./pharo ./Pharo.image bootstrap/scripts/bootstrap.st --quit

And it will work.

The idea is to migrate more parts of the process to pure Pharo code,
everything is implemented in a project PharoBootstrapProcess, which is
located in bootstrap/src in the same Pharo repository.
The best way to check what is there is to do the same as the process.

1) Take an image with VMMaker, Espell and Ficus (we have them already made
in
https://github.com/guillep/PharoBootstrap/releases/download/v1.4/bootstrapImage.zip
).
2) Execute bootstrap/scripts/prepare_image.st

That is the same image used to bootstrap Pharo.
I will do another pass on this first part of the process and generate some
documentation about the changes and how to modify the whole process.
We decided to migrate the process by parts to be able to review it easily
than waiting to have a whole migration of the process.

The next step is to do the same with the build.sh file, as you can see it,
is a little complex and have lots of steps.
The idea is again convert them into Pharo code.

Again sorry if the partial change made some problems in your local
execution of the bootstrap.

Cheers.


On Fri, Mar 16, 2018 at 2:02 PM, Alistair Grant 
wrote:

> Hi Pablo & Everyone,
>
> The bootstrap process seems to be in an inconsistent state at the
> moment as the scripts in:
>
> - Jenkinsfile   and
> - bootstrap/scripts/bootstrap.sh
>
> don't match.
>
> bootstrap/scripts/bootstrap.sh has an error in it:
>
> ./pharo Pharo.image eval "PBBootstrap fromCommandLine bootstrap" --quit
>
> fails because the "--quit" option is valid for the st handler
> (executing a smalltalk file), but isn't recognised by the eval
> handler.
>
> Can someone, Pablo?, confirm what the status is, what it should be and
> what the next steps are? :-)
>
> Thanks,
> Alistair
>
>


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

Re: [Pharo-dev] pharo bootstrap is in inconsistent state

[teso...@gmail.com]

On Fri, Mar 16, 2018 at 3:26 PM, Alistair Grant 
wrote:

> Hi Pablo,
>
> Thanks for your quick reply.
>
> On 16 March 2018 at 14:38, teso...@gmail.com  wrote:
> > Hi,
> >  sorry my mistake when updating the scripts. As the bootstrap.sh is
> not
> > executed during the Jenkins process it has not been validated (locally
> I'm
> > not using that script, because is trying to download each time the VM and
> > the bootstraping process image)
>
> Right.  Can we make one of the goals of the refactoring to avoid any
> code duplication?
>
> e.g. at the moment (ignoring changes proposed below), Jenkins should
> be calling bootstrap.sh.
>
>
Yes that is part of the plan.


>
> > The correct line is the one from the JenkinsFile, it should be something
> > like:
> >
> > ./pharo ./Pharo.image bootstrap/scripts/bootstrap.st
> --ARCH=${architecture}
> > --BUILD_NUMBER=${env.BUILD_ID} --quit
> >
> > I will submit a PR to fix it, as soon as the CI infrastructure is less on
> > fire.
> > Until the fix, if you are building the image locally you can change the
> > error line with:
> >
> > ./pharo ./Pharo.image bootstrap/scripts/bootstrap.st --quit
> >
> > And it will work.
>
> Shall do.
>
>
> > The idea is to migrate more parts of the process to pure Pharo code,
>
> +1
>
>
> > everything is implemented in a project PharoBootstrapProcess, which is
> > located in bootstrap/src in the same Pharo repository.
> > The best way to check what is there is to do the same as the process.
> > 1) Take an image with VMMaker, Espell and Ficus (we have them already
> made
> > in
> > https://github.com/guillep/PharoBootstrap/releases/
> download/v1.4/bootstrapImage.zip).
> > 2) Execute bootstrap/scripts/prepare_image.st
> >
> > That is the same image used to bootstrap Pharo.
> > I will do another pass on this first part of the process and generate
> some
> > documentation about the changes and how to modify the whole process.
> > We decided to migrate the process by parts to be able to review it easily
> > than waiting to have a whole migration of the process.
> >
> > The next step is to do the same with the build.sh file, as you can see
> it,
> > is a little complex and have lots of steps.
> > The idea is again convert them into Pharo code.
>
> Can we also re-order the bootstrap and break it into several distinct
> phases.
>
> 1. Clean up (this ensures a clean environment for Jenkins)
> 2. Download all pre-requisites.
> The main change here is moving the call to download_vm.sh out of
> build.sh.
> This would allow a particular VM to be installed by hand for step
> 4, see below.
> 3. Initial preparation, i.e. all the execution prior to build.sh, e.g.
> prepare_image.st.
>Currently this is done with the Pharo 6 VM and image, which makes sense
> as it
>provides stability.
> 4. Main image bootstrap.  Which is done with the Pharo 7 VM (currently
> what is in build.sh).
>
> That will allow the first three steps to be run once and then skipped
> when doing personal development / testing.
>
> I want to be able to manually load the VM to be used in step 4 as part
> of some stability testing so we can promote a new Pharo 7 VM to
> stable.
>
> Are you open to me submitting some PRs that do this restructure to the
> phases listed above and removing duplicate code from Jenkinsfile?
>
> Yes of course. Thanks

>
> > Again sorry if the partial change made some problems in your local
> execution
> > of the bootstrap.
>
> No problem.
>
> Thanks,
> Alistair
>
>
>
> > Cheers.
> >
> >
> > On Fri, Mar 16, 2018 at 2:02 PM, Alistair Grant 
> > wrote:
> >>
> >> Hi Pablo & Everyone,
> >>
> >> The bootstrap process seems to be in an inconsistent state at the
> >> moment as the scripts in:
> >>
> >> - Jenkinsfile   and
> >> - bootstrap/scripts/bootstrap.sh
> >>
> >> don't match.
> >>
> >> bootstrap/scripts/bootstrap.sh has an error in it:
> >>
> >> ./pharo Pharo.image eval "PBBootstrap fromCommandLine bootstrap" --quit
> >>
> >> fails because the "--quit" option is valid for the st handler
> >> (executing a smalltalk file), but isn't recognised by the eval
> >> handler.
> >>
> >> Can someone, Pablo?, confirm what the status is, what it should be and
> >> what the next steps are? :-)
> >>
> >> Thanks,
> >> Alistair
> >>
> >
> >
> >
> > --
> > Pablo Tesone.
> > teso...@gmail.com
>
>


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