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

[Vincent Blondeau via Pharo-dev]

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



--- End Message ---

Re: [Pharo-dev] PR without Tests

[Vincent Blondeau via Pharo-dev]

--- Begin Message ---
Great news!

I was wondering if they were also something planned to get some coverage 
information report to help to add more tests on parts of the system that are 
not tested?

Cheers,
Vincent


-Original Message-
From: Pharo-dev On Behalf Of teso...@gmail.com
Sent: Thursday, 6 February 2020 10:30
To: Pharo-dev ; r...@inria.fr list 
Subject: [Pharo-dev] PR without Tests

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



--- End Message ---

Re: [Pharo-dev] [P9] Large images tag

[Vincent Blondeau via Pharo-dev]

--- Begin Message ---
Hi Stef,

Great idea! Here are some that could be added to the list:
https://github.com/pharo-project/pharo/issues/5478
https://github.com/pharo-project/pharo/issues/5260 
https://github.com/pharo-project/pharo/issues/5191 
https://github.com/pharo-project/pharo/issues/5188 
https://github.com/pharo-project/pharo/issues/5187 
https://github.com/pharo-project/pharo/issues/4896 

Cheers,
Vincent

Ps: only members of the Pharo git repo can tag issues.


-Original Message-
From: Pharo-dev On Behalf Of ducasse
Sent: Tuesday, 21 January 2020 20:34
To: Pharo Development List 
Subject: [Pharo-dev] [P9] Large images tag

Hi all

We are starting an effort to review and improve the behavior of pharo in 
presence of super large images. 
I created a special tag to highlight the issues. 
So if you have concerns and found annoying behavior related to slugginess in 
large image, please use this tag. 

We are also looking for misuse of operations fully scanning the memory or kind 
of like allInstances of and others. 

S. 




--- End Message ---

Re: [Pharo-dev] code loading performance

[Vincent Blondeau via Pharo-dev]

--- Begin Message ---
Hi Georges,

There have been quite some improvements those last weeks on the performance of 
loading classes and methods. But we are still waiting for the 
https://github.com/pharo-project/pharo/pull/5292 to be integrated.

And you have to encapsulate the loading code into: SourceFiles 
deferFlushDuring: [...] and use the latest pharo 8.0 image.

You can give a try with this and tell us how it goes!

Cheers,
Vincent

-Original Message-
From: Pharo-dev On Behalf Of George Ganea
Sent: Friday, 6 December 2019 17:08
To: pharo-dev@lists.pharo.org
Cc: Chis Vasile Andrei 
Subject: [Pharo-dev] code loading performance

Hi all,

Currently loading GToolkit takes quite some time (arount 18 minutes at the best 
of times) we were wondering if there’s been any attempts at improving code 
loading times in Metacello/Monticello. Or mabye there are some ideas on how one 
might start doing something like this?

Cheers,
George


--- End Message ---

[Pharo-dev] About package deprecation

[Vincent Blondeau via Pharo-dev]

--- Begin Message ---
Hi all,

 

As everyone knows, the BlueInk and GTRecorder packages have been removed
from Pharo8.0 quite rapidly
https://github.com/pharo-project/pharo/issues/5217.

And it breaks the loading of other projects on Pharo8.0, like Roassal2.

 

Some claims that those packages will not be deprecated because they are
loadable as it from another repository. Why not? So, I tried.

 

For BlueInk, no repository containing the sources has been indicated. And
not repository exists on github.

 

For the GTRecorder, the sources are there:
https://github.com/pharo-contributions/EventRecorder, according to
https://github.com/pharo-project/pharo/issues/5232.

The problem is that the EventRecorder project does not contain exactly the
same classes, the prefix has been changed from GT to ER. So, any reference
to one of the classes of this project has to be changed… 

In particular, we had to make this change to make it load correctly:
https://github.com/lifeware-sa/Roassal2/commit/78ce17bba98b89cb21a996cf8acaf
4e053ae082b (and we just have tried to load it so far).

 

 

I think that not only Roassal is using those dependencies (see there
https://github.com/search?o=desc

=GTEventCollector=indexed=Code and they are just public repos) and
migrating them to the latest version of Pharo will be more painful since we
need to fix the issue it immediately, or, wait that the maintainer of each
project provide a fix to bypass the issues.

 

 

Therefore, as we have a nice deprecation mechanism in our system, I suggest
we use it so we can focus on stuff more important than writing tons of
emails. 

I am then pushing in favor of the integration of this PR:
https://github.com/pharo-project/pharo/pull/5257 so that we can have some
time to solve the bugs.

And I expect that those packages will be removed in Pharo 9.0.

 

 

Now that everything is exposed, could the maintainers of the Pharo project
take a clear decision concerning this topic? Also, we are expecting some
justification on the undertaken action.

 

 

Thanks,

Vincent

www.lifeware.ch  

 

 

<>--- End Message ---

Re: [Pharo-dev] [Launcher][Win]Cannot download the VM from Pharo

[Vincent BLONDEAU]

This issue is still there..

 

At work, I can download the zip properly with Firefox, but not with Chrome,
IE, Pharo, and VisualWorks.

When I use another connection than the one behind the company firewall, it
works.

I tried on the laptop of one of my colleagues: same issue.

 

By analyzing the HTTP packets with Wireshark, a Reset of the connection is
send by the server, I don't know why.

I really don't know how to solve or reproduce this issue. Has someone an
idea?

 

Thanks, 

 

 

Vincent

 

 

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of
vincent.blond...@lamresearch.com
Sent: mercredi 24 janvier 2018 09:11
To: pharo-dev@lists.pharo.org
Subject: Re: [Pharo-dev] [Launcher][Win]Cannot download the VM from Pharo

 

Hi,

 

I think that is not related. I have this problem since last week and it is
still there today.

 

Vincent

 

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of
Marcus Denker
Sent: Wednesday, January 24, 2018 0:01
To: Pharo Development List  >
Subject: Re: [Pharo-dev] [Launcher][Win]Cannot download the VM from Pharo

 

Hi,

 

My watchdog detected problems connecting to files.pharo.org
  this night (local time).

 

It seems to not happen anymore. It might have been related (that is, there
might have been problems

on the OVH side this night).

 

Marcus

 

On 24 Jan 2018, at 00:09,  >

> wrote:

 

Hi,

With the Pharo launcher, the VM are automatically downloaded from the
files.pharo.org
  server.
However, it seems that the download of some VMs doesn't work at least under
Windows 10.
For the P7 image, the download stops at 38% (~2.5Mo) with the error
"ConnectionClosed: Cannot Read Data", and, I obtain the same error with this
cmd:

ZnEasy get: 'http://files.pharo.org/get-files/70/pharo-win-stable.zip
 '.

However, I can fully download the image through the Internet Browser. The
download with Pharo is working: ZnEasy get: 'https://files.pharo.org/
 '. give me a 200 OK response.

Thanks in advance for your help,

Cheers,
Vincent




 

Re: [Pharo-dev] FFI without the Pharo sources

[Vincent BLONDEAU]

Thanks Marcus!
It seems that the tests are OK now:
https://github.com/pharo-project/pharo/pull/750

Vincent

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of
Marcus Denker
Sent: mardi 30 janvier 2018 23:40
To: Pharo Development List
Subject: Re: [Pharo-dev] FFI without the Pharo sources

I wil merge the PR after the test ran a last time.

> On 31 Jan 2018, at 08:30, Vincent BLONDEAU
<vincent.blond...@polytech-lille.net> wrote:
> 
> Now, yes it is. See FFICompilerPlugin :)
> 
> Vincent
> 
> -Original Message-
> From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf 
> Of Stephane Ducasse
> Sent: mardi 30 janvier 2018 23:15
> To: Pharo Development List
> Subject: Re: [Pharo-dev] FFI without the Pharo sources
> 
> Thanks vincent.
> is it the comment of some classes?
> 
> Stef
> 
> On Wed, Jan 31, 2018 at 3:12 AM,  <vincent.blond...@lamresearch.com>
wrote:
>> Hi,
>> 
>> So, I suggest this solution: 
>> https://github.com/pharo-project/pharo/pull/750
>> 
>> It is a plugin for the OpalCompiler that can be activated with the
command "FFICompilerPlugin install."
>> The plugin is pragma-based to detect the methods where the arguments
names should be remembered.
>> The pragma should be added in the FFI API methods, i.e., the methods that
are called by the FFI methods where the arguments have to be remembered.
>> Example:
>> 
>> This FFI method should remember the name of the argument named "config":
>> 
>> repository_config: config
>>^ self
>>call: #(#LGitReturnCodeEnum #git_repository_config
#(#LGitConfig #* #config #, #self))
>>options: #()
>> 
>> So, the FFI function should wear the pragma :
>> 
>> call: fnSpec options: options
>>
>>^ (self safeFFICalloutIn: thisContext sender)
>>cdecl;
>>options: options;
>>function: fnSpec module: self ffiLibraryName
>> 
>> To remove to be able to remove the sources (.changes and .sources), you
only have to activate the plugin, no recompilation is necessary. You can
even import new FFI methods or change the FFI API.
>> 
>> N.B: Users that redefine the FFI API (like TLGitCalloutTrait >>
call:options:) also have to wear the pragma.
>> 
>> Cheers,
>> Vincent
>> 
>> -Original Message-
>> From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf 
>> Of Stephane Ducasse
>> Sent: Wednesday, January 24, 2018 9:21
>> To: Pharo Development List <pharo-dev@lists.pharo.org>
>> Subject: Re: [Pharo-dev] FFI without the Pharo sources
>> 
>> So if you implement a cool solution we will integrate it immediately
>> :)
>> 
>> On Wed, Jan 24, 2018 at 6:20 PM, Stephane Ducasse
<stepharo.s...@gmail.com> wrote:
>>> Thanks Vincent we are interested to make the independence on source 
>>> much simpler.
>>> 
>>> Stef
>>> 
>>> 
>>> On Wed, Jan 24, 2018 at 5:09 PM, Eliot Miranda <eliot.mira...@gmail.com>
wrote:
>>>> Hi Vincent,
>>>> 
>>>>> On Jan 23, 2018, at 4:54 PM, <vincent.blond...@lamresearch.com>
<vincent.blond...@lamresearch.com> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I am working to be able to create some standalone apps in Pharo. And
for this, I would like to remove of the .sources and .changes. But, by
removing them, the args names are reset to arg1, arg2, arg3, ... and the FFI
cannot be used anymore.
>>>>> 
>>>>> Does someone (Esteban?) have a solution that I could implement to fix
this issue?
>>>> 
>>>> One avenue that should be easy to implement would be to modify the
compiler to save the temporary names as a property of the method.
>>>> 
>>>> 
>>>>> 
>>>>> Thanks!
>>>>> 
>>>>> Vincent
>>>> 
>>>> _,,,^..^,,,_ (phone)
>> 
> 
> 
> 

Re: [Pharo-dev] FFI without the Pharo sources

[Vincent BLONDEAU]

Now, yes it is. See FFICompilerPlugin :)

Vincent

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of 
Stephane Ducasse
Sent: mardi 30 janvier 2018 23:15
To: Pharo Development List
Subject: Re: [Pharo-dev] FFI without the Pharo sources

Thanks vincent.
is it the comment of some classes?

Stef

On Wed, Jan 31, 2018 at 3:12 AM,   wrote:
> Hi,
>
> So, I suggest this solution: 
> https://github.com/pharo-project/pharo/pull/750
>
> It is a plugin for the OpalCompiler that can be activated with the command 
> "FFICompilerPlugin install."
> The plugin is pragma-based to detect the methods where the arguments names 
> should be remembered.
> The pragma should be added in the FFI API methods, i.e., the methods that are 
> called by the FFI methods where the arguments have to be remembered.
> Example:
>
> This FFI method should remember the name of the argument named "config":
>
> repository_config: config
> ^ self
> call: #(#LGitReturnCodeEnum #git_repository_config 
> #(#LGitConfig #* #config #, #self))
> options: #()
>
> So, the FFI function should wear the pragma :
>
> call: fnSpec options: options
> 
> ^ (self safeFFICalloutIn: thisContext sender)
> cdecl;
> options: options;
> function: fnSpec module: self ffiLibraryName
>
> To remove to be able to remove the sources (.changes and .sources), you only 
> have to activate the plugin, no recompilation is necessary. You can even 
> import new FFI methods or change the FFI API.
>
> N.B: Users that redefine the FFI API (like TLGitCalloutTrait >> 
> call:options:) also have to wear the pragma.
>
> Cheers,
> Vincent
>
> -Original Message-
> From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf 
> Of Stephane Ducasse
> Sent: Wednesday, January 24, 2018 9:21
> To: Pharo Development List 
> Subject: Re: [Pharo-dev] FFI without the Pharo sources
>
> So if you implement a cool solution we will integrate it immediately 
> :)
>
> On Wed, Jan 24, 2018 at 6:20 PM, Stephane Ducasse  
> wrote:
>> Thanks Vincent we are interested to make the independence on source 
>> much simpler.
>>
>> Stef
>>
>>
>> On Wed, Jan 24, 2018 at 5:09 PM, Eliot Miranda  
>> wrote:
>>> Hi Vincent,
>>>
 On Jan 23, 2018, at 4:54 PM,  
  wrote:

 Hi,

 I am working to be able to create some standalone apps in Pharo. And for 
 this, I would like to remove of the .sources and .changes. But, by 
 removing them, the args names are reset to arg1, arg2, arg3, ... and the 
 FFI cannot be used anymore.

 Does someone (Esteban?) have a solution that I could implement to fix this 
 issue?
>>>
>>> One avenue that should be easy to implement would be to modify the compiler 
>>> to save the temporary names as a property of the method.
>>>
>>>

 Thanks!

 Vincent
>>>
>>> _,,,^..^,,,_ (phone)
>

Re: [Pharo-dev] Iceberg Loading issue

[Vincent BLONDEAU]

Hi Max,

 

Yes, I tried that too: pulling the branch outside Pharo, set it to the 21124 
branch head, then launch Pharo and run the pull of incoming commits from Pharo.

Also, loading one commit at the time works, but you cannot do it for a lot of 
commits, the list of commits is very slow to refresh (at least under Windows).

 

Cheers,

Vincent 

 

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Max 
Leske
Sent: jeudi 25 janvier 2018 22:15
To: Pharo Development List
Subject: Re: [Pharo-dev] Iceberg Loading issue

 

Hi Vincent,

 

Possibly a problem with updating FETCH_HEAD. Does it work when you perform only 
the pull operation from Pharo (i.e., check out the branch on the command line)?

 

 

Cheers,

Max

 

 

 

On 26 January 2018 at 00:43:40, vincent.blond...@lamresearch.com 
  (vincent.blond...@lamresearch.com 
 ) wrote:

Hi, 

I am encountering some problems with Iceberg on the latest version. 

I want to load the commits I just made on a branch on my Pharo fork, let's say 
"21124". I set the local repo to the current version of my Pharo image, i.e. 
the development branch (commit 0dbf86). 
Thanks to the iceberg interface, I change the current branch to "21124", there 
are 12 commits that are incoming. 
Then, I then do "Pull incoming commit" to load them. 
But after a few moment, instead of loading only the delta between the 
development branch and the "21124" one, iceberg goes further in the commit 
history and wants to load 174 commits... Including one that does not load. 

By debugging, it seems that there is a problem with 
LGitRepository>>fastForward:, the result of "self lookup: 'FETCH_HEAD'" gives 
not the good commit i.e. the one of the development branch (commit 0dbf86), but 
instead the one of "I do not what". 

Does this issue is known? And how can I bypass it or solve it? 

Thanks, 

Vincent 

Re: [Pharo-dev] Spur Garbage collection takes 4 times more when loading MSE (WAS: mse loading looks slower :()

[Vincent BLONDEAU]

Yes, and we have to do several passes to construct the model with references
(so we store a mapping table).
Maybe a collection or two are GCed.

Vincent


-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of
stepharo
Sent: dimanche 24 janvier 2016 13:40
To: Pharo Development List
Subject: Re: [Pharo-dev] Spur Garbage collection takes 4 times more when
loading MSE (WAS: mse loading looks slower :()

Thanks for this analysis. This is really interesting.
I wonder what is the type of the garbage collected object.
In MSE we have mainly strings.

Stef

Le 24/1/16 12:43, Vincent BLONDEAU a écrit :
> Hi,
>
> I made the benchmarks with the files you provided. I have more or less 
> the same magnitude:
> Version 504: 0:00:01:09.021
> Version 1175: 0:00:02:37.507
>
> However, by launching it in the time profiler (MooseModel new
> importFromMSEStream: (StandardFileStream readOnlyFileNamed:
> 'd:/ArgoUML-0-34.mse')), it takes
> 504: 1 min 55
> 1175: 4 min 25
> Well there is a delta...
>
> After investigation, the standard process has almost the same duration 
> (120 secs for prespur and 140 secs for spur).
> But, there is a large difference in GC time:
>
> 504: not spur
> **Memory**
>   old +144,822,000 bytes
>   young   -8,293,660 bytes
>   used+136,528,340 bytes
>   free-104,186,788 bytes
>
> **GCs**
>   full1 totalling 965ms (1.0% uptime), avg 965.0ms
>   incr3264 totalling 42,279ms (33.0% uptime), avg 13.0ms
>   tenures 2,497 (avg 1 GCs/tenure)
>   root table  0 overflows
>
> 1175: spur
> **Memory**
>   old +0 bytes
>   young   +340,048 bytes
>   used+340,048 bytes
>   free-340,048 bytes
> **GCs**
>   full7 totalling 145,003ms (66.0% uptime), avg
> 20715.0ms
>   incr3288 totalling 30,912ms (14.0% uptime), avg 9.0ms
>   tenures 7,146,505 (avg 0 GCs/tenure)
>   root table  0 overflows
>
> Total GC time
> 504: 43 secs
> 1175: 176 secs
>
> See the performance reports attached.
>
> I let VM people take care of the issue ;)
>
> Cheers,
> Vincent
>
> -Original Message-
> From: moose-dev-boun...@list.inf.unibe.ch
> [mailto:moose-dev-boun...@list.inf.unibe.ch] On Behalf Of Tudor Girba
> Sent: dimanche 24 janvier 2016 09:08
> To: Moose-related development
> Subject: [Moose-dev] Re: mse loading looks slower :(
>
> Hi,
>
> I am talking about the difference between Moose 6 images:
> - October 7:
> https://ci.inria.fr/moose/job/moose-6.0/504/artifact/moose-6.0.zip
>
> - yesterday:
> https://ci.inria.fr/moose/job/moose-6.0/1175/artifact/moose-6.0.zip
>
> Multiple things did change, but not in Moose. In the end, I would like 
> to understand where the slowness comes. Maybe it comes from Spur 
> itself, but maybe it comes from somewhere else.
>
> Cheers,
> Doru
>
>
>
>> On Jan 24, 2016, at 1:41 AM, Mariano Martinez Peck 
>> <marianop...@gmail.com>
> wrote:
>> Doru...just to be sure it is not a Pharo (image change), when you 
>> said
> before and after Spur, do you mean a Pharo 5.0 exactly (just before 
> Spur) and a Pharo JUST after it?  Otherwise, the slowness may come 
> from the difference between the 2 Pharos you are running.
>> Cheers,
>>
>> On Sat, Jan 23, 2016 at 5:55 PM, Tudor Girba <tu...@tudorgirba.com>
wrote:
>> Hi,
>>
>> I am doing some performance testing of Moose with the Spur VM on Mac.
>>
>> I tried to load an MSE file with ArgoUML 0.34 and on my machine it 
>> loads
> twice as slow with Spur than before:
>> - PreSpur: 0:00:01:07.272
>> - Spur: 0:00:02:10.508
>>
>> Here is the reference file:
>> https://dl.dropboxusercontent.com/u/18323746/Tmp/ArgoUML-0-34.mse.zip
>>
>> And here is the script:
>> [
>>  MooseModel new
>>  importFromMSEStream: (StandardFileStream
> readOnlyFileNamed:
>>  (FileSystem workingDirectory / 'src' /
> 'ArgoUML-0-34' / 'ArgoUML-0-34.mse') fullName).
>>  ] timeToRun
>>
>> Do you get the same?
>>
>> Cheers,
>> Doru
>>
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Problem solving should be focused on describing the problem in a way 
>> that makes the solution obvious."
>>
>>
>>
>>
>>
>> ___
>> Moose-dev mailing list
>> moose-...@list.inf.unibe.ch
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>> ___
>> Moose-dev mailing list
>> moose-...@list.inf.unibe.ch
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
> --
> www.tudorgirba.com
> www.feenk.com
>
> "What is more important: To be happy, or to make happy?"
>
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev

Re: [Pharo-dev] Get an image from monkey job

[Vincent BLONDEAU]

Hi,

With the current configuration, it is not possible: the workspace is deleted
after the execution (so the image generated too...).
Maybe it should be nice to delete the workspace only before the job, in this
way, one can be able to retrieve the generated image and debug it?
Can a Pharo CI admin change this configuration?

Cheers,
Vincent

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of
Yuriy Tymchuk
Sent: samedi 23 janvier 2016 11:52
To: Pharo Development List
Subject: [Pharo-dev] Get an image from monkey job

Hi,

sometimes some strange tests fail while money is checking the
slice/configuration. And while the failures are not related to the
contribution sometimes I want to know what happened and maybe fix it. Is it
possible to get the resulting image to investigate it?

Cheers.
Uko

Re: [Pharo-dev] [Moose-dev] Equivalent class for Pharo

[Vincent BLONDEAU]

Hi Milton, 

 

You should ask to the Pharo mailing list (in copy).

 

But what is the purpose of the BinaryStorageBytes class?

 

Cheers,

Vincent

 

De : moose-dev-boun...@iam.unibe.ch [mailto:moose-dev-boun...@iam.unibe.ch] De 
la part de milton mamani
Envoyé : vendredi 4 septembre 2015 23:23
À : Moose-related development; Vwnc (v...@cs.uiuc.edu)
Objet : [Moose-dev] Equivalent class for Pharo

 

Hi to all

 

Can someone please tell me the equivalent class for BinaryStorageBytes(a VW 
class) for Pharo

 

Cheers,

Milton

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

[Vincent BLONDEAU]

Now that the Moose 6.0 job is working, the last build of Pharo is used and the 
problem appears in the CI...

Vincent

-Message d'origine-
De : Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] De la part de 
Alexandre Bergel
Envoyé : mercredi 26 août 2015 01:02
À : Any question about pharo is welcome
Objet : Re: [Pharo-users] [ann] brick on top of bloc - preview

Wow…

Alexandre


 On Aug 25, 2015, at 6:41 PM, Vincent BLONDEAU 
 vincent.blond...@polytech-lille.net wrote:
 
 That is because GToolkit is based on last successful Moose 6.0 build where 
 everything works fine (it is Pharo50248). 
 But less than a week ago, a featured bug was integrated in Pharo and it is 
 not possible to load Moose anymore… That is due to some encoding problems 
 during Monticello loading between 50256 and 50257 Pharo versions (integration 
 of Slice 16283).
  
 As I can’t load brick on the 50256 pharo image, I think that the bug you 
 encounter has been introduced before, i.e. between 50248 and 50256. So it is 
 not related to the Moose one.
 Bernardo’s bug is related to traits loading, I have the same bug for one of 
 my project but I didn’t investigate it yet.
  
 Cheers,
 Vincent
  
 De : Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] De la 
 part de Tudor Girba Envoyé : mardi 25 août 2015 23:08 À : Any question 
 about pharo is welcome Objet : Re: [Pharo-users] [ann] brick on top of 
 bloc - preview
  
 Hmm. Thanks for the report. Indeed, I get the same, but the CI job works 
 well. We will have to investigate this.
  
 In the meantime, you can use the image from:
 https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifact/g
 toolkit5.zip
  
 Cheers,
 Doru
  
  
  
 On Tue, Aug 25, 2015 at 10:51 PM, Bernardo Ezequiel Contreras 
 vonbecm...@gmail.com wrote:
  i forgot to mention that it was while
  
 Loading Bloc-Core-AliakseiSyrel.636
  
 thanks
  
  
  
 On Tue, Aug 25, 2015 at 5:43 PM, Bernardo Ezequiel Contreras 
 vonbecm...@gmail.com wrote:
 Sorry, but after evaluating
  
 Gofer new
 smalltalkhubUser: 'Pharo' project: 'Brick'; configuration; 
 loadDevelopment
  
 in Pharo5.0#50270, i got an Error: Unrecognized class definition
  
 The screenshots look really cool.
  
 thanks
  
  
 On Tue, Aug 25, 2015 at 5:13 PM, Tudor Girba tu...@tudorgirba.com wrote:
 Hi,
  
 We are happy to announce the first preview version of Brick, a new widget 
 set created from scratch on top of Bloc.
  
 Brick is being developed primarily by Alex Syrel (together with Alain 
 Plantec, Andrei Chis and myself), and the work is sponsored by ESUG. Brick 
 is part of the Glamorous Toolkit effort and will provide the basis for the 
 new versions of the development tools.
  
 Brick's goal is to provide a beautiful looking widget set, and the default 
 look is based on material design. The widgets are theme-able.
  
 Right now, there exists:
 - Label
 - Simple button
 - Toggle button
 - Checkbox
 - Radio button
 - Window with or without an active title bar that can include 
 various visual actions and info
 - Menu
 - Beautiful scrollbars that are thin by default and enlarge when 
 the mouse hovers over it
 - Scalable list for huge amounts of items with various heights (The 
 list also allows one for embedding text widgets with in place 
 editing)
  
 The next immediate target is the creation of a new Pager widget (the 
 widget that is behind the current GTInspector).
  
 You can see some screenshots on the official site:
 http://gt.moosetechnology.org/brick
  
 To play with it, you can download a ready-made image:
 https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifac
 t/gtoolkit5.zip
  
 and, in a Bloc space, you can browse the examples:
 BrExampleBrowser exampleOpen
  
 We would be happy to hear your feedback.
  
 Cheers,
 Doru
  
 --
 www.tudorgirba.com
  
 Every thing has its own flow
 
 
  
 --
 Bernardo E.C.
  
 Sent from a cheap desktop computer in South America.
 
 
  
 --
 Bernardo E.C.
  
 Sent from a cheap desktop computer in South America.
 
 
  
 --
 www.tudorgirba.com
  
 Every thing has its own flow

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

Re: [Pharo-dev] WAV support in Pharo

[Vincent BLONDEAU]

Thanks! It is working better now!

Nice tool!
Do you plan to add Mp3? (because it is the current format now ;)).

Vincent

-Message d'origine-
De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de Merwan 
Ouddane
Envoyé : dimanche 23 août 2015 17:43
À : Pharo Development List
Objet : Re: [Pharo-dev] WAV support in Pharo

Yes you have to download OpenAL for the openAL binding to work :p

The name of the dll is OpenAL32.dll


On 23/08/2015 17:25, Vincent BLONDEAU wrote:
 Hi,

 It does not work under windows.. Should I download a specific .dll ?

 Cheers,
 Vincent

 -Message d'origine-
 De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part 
 de Merwan Ouddane Envoyé : dimanche 23 août 2015 16:02 À : Pharo 
 Development List Objet : [Pharo-dev] WAV support in Pharo

 Hi,

 I made a WAV parser, so now we can play music in Pharo :)

 I made an example using OpenAL's binding from Ronnie.

 You can try it with this piece of code :

 Gofer new
   smalltalkhubUser: 'MerwanOuddane' project: 'WAVParser';
   package: 'ConfigurationOfWAVParser';
   load.
 (Smalltalk at: #ConfigurationOfWAVParser) loadBleedingEdge.
 (Smalltalk at: #ALExamplesWAV) exampleBirdChirping

 Merwan

Re: [Pharo-dev] WAV support in Pharo

[Vincent BLONDEAU]

Hi,

It does not work under windows.. Should I download a specific .dll ?

Cheers, 
Vincent

-Message d'origine-
De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de Merwan 
Ouddane
Envoyé : dimanche 23 août 2015 16:02
À : Pharo Development List
Objet : [Pharo-dev] WAV support in Pharo

Hi,

I made a WAV parser, so now we can play music in Pharo :)

I made an example using OpenAL's binding from Ronnie.

You can try it with this piece of code :

Gofer new
 smalltalkhubUser: 'MerwanOuddane' project: 'WAVParser';
 package: 'ConfigurationOfWAVParser';
 load.
(Smalltalk at: #ConfigurationOfWAVParser) loadBleedingEdge.
(Smalltalk at: #ALExamplesWAV) exampleBirdChirping

Merwan

Re: [Pharo-dev] [Moose-dev] Re: Object new foo

[Vincent BLONDEAU]

Hi, 

 

On last Moose image, I debugged the VM and executed “Exception signal”. 

I paused the VM and saw that 2 methods are looping together in gcc3x-cointerp.c:

static sqInt findMethodWithPrimitiveFromContextUpToContext(sqInt primitive, 
sqInt senderContext, sqInt homeContext); 

static sqInt findMethodWithPrimitiveFromFPUpToContext(sqInt primitive, char 
*startFP, sqInt homeContext);

 

The image is looping only when the debugger is launch on Error (not by 
launching it by the script below).

 

Maybe someone on the Pharo mailing list knows what is happening?

 

Thanks in advance,

 

Cheers, 

Vincent

 

De : moose-dev-boun...@iam.unibe.ch [mailto:moose-dev-boun...@iam.unibe.ch] De 
la part de Andrei Chis
Envoyé : mardi 18 août 2015 10:53
À : Moose-related development
Objet : [Moose-dev] Re: Object new foo

 

Hi Vincent,

 

You example will also kill the Pharo debugger :)

The issue is that you pass 'Processor activeProcess' which gets terminated when 
you close the debugger.

When you open the debugger you need to make sure the process

on which it is opened is suspended and can get terminated with no problem.

 

A different way to redo the example would be:

 

context := Context

sender: nil

receiver: {1 . 2 . 2}

method: (OrderedCollection#add:)

arguments: #(10).

process := Process 

forContext: context

priority: Processor userInterruptPriority.

GTGenericStackDebugger openOn: (DebugSession process: process context: context).

 

There is a basic test for opening the debugger in 
GTGenericStackDebuggerSmokeTest but more could help.

 

Cheers,

Andrei

 

 

On Mon, Aug 17, 2015 at 11:53 PM, Vincent BLONDEAU 
vincent.blond...@polytech-lille.net 
mailto:vincent.blond...@polytech-lille.net  wrote:

Indeed. Maybe some tests has to be added..

 

But for now, it seems that the debugger is crashing the image… Not just by 
launching it:

GTGenericStackDebugger openOn: (DebugSession process: Processor activeProcess 
context:  (Context 

   sender: nil

   receiver: {1 . 2 . 2}

   method: (OrderedCollection#add: )

   arguments: #(10)))

 

But when an exception is thrown, its seems that we fall into an infinite loop 
around the primitive 199. Maybe the context is not well set?

 

Cheers, 

Vincent

 

 

 

De : moose-dev-boun...@iam.unibe.ch mailto:moose-dev-boun...@iam.unibe.ch  
[mailto:moose-dev-boun...@iam.unibe.ch mailto:moose-dev-boun...@iam.unibe.ch 
] De la part de Alexandre Bergel
Envoyé : lundi 17 août 2015 13:26
À : Moose-related development
Objet : [Moose-dev] Re: Object new foo

 

This is weird that such bug can be introduced and no alarm is raised

 

Alexandre 


Le 17 août 2015 à 08:03, Jan Kurš k...@iam.unibe.ch mailto:k...@iam.unibe.ch 
 a écrit :

Yep I had this problem (falled back to previous version), I suspected debugger 
being the reason. 

Cheers Jan 

 

On Sun, 16 Aug 2015 03:05 Alexandre Bergel alexandre.ber...@me.com 
mailto:alexandre.ber...@me.com  wrote:

in Moose 6.0 simply freezes.
Anyone else sees this?

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



___
Moose-dev mailing list
moose-...@iam.unibe.ch mailto:moose-...@iam.unibe.ch 
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

___
Moose-dev mailing list
moose-...@iam.unibe.ch mailto:moose-...@iam.unibe.ch 
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


___
Moose-dev mailing list
moose-...@iam.unibe.ch mailto:moose-...@iam.unibe.ch 
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 

Re: [Pharo-dev] [Moose-dev] Getting some tag in an HTML file

[Vincent Blondeau]

 Hi, 

Look at the class side, there is the method parse: namespace: validation: . 
call this method instead of parse: with false in the two last arguments. It 
should work.

Anyway, you should use the sax parser. It is faster and memory less consuming. 
It is very simple to get only one tag.

Cheers
Vincent

Le 14 août 2015 01:31, Alexandre Bergel alexandre.ber...@me.com a écrit :

 Hi!

 Together with Nicolas we are trying to get all the script … … /script 
 from html files.
 We have tried to use XMLDOMParser, but many webpages are actually not well 
 formed, therefore the parser is complaining.

 Anyone has tried to get some particular tags from HTML files? This looks like 
 a classical thing to do. Maybe some of you have done it.
 Is there a way to configure the parser to accept a broken XML/HTML content?

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


 ___
 Moose-dev mailing list
 moose-...@iam.unibe.ch
 https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Re: [Pharo-dev] Fix needed: 15947 Right and left click exchanged for world menu

[Vincent BLONDEAU]

It is. 
I commited a fix. 

Vincent Blondeau

-Message d'origine-
De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de
Marcus Denker
Envoyé : samedi 11 juillet 2015 09:35
À : Pharo Development List
Objet : [Pharo-dev] Fix needed: 15947 Right and left click exchanged for
world menu

15947 Right and left click exchanged for world menu
https://pharo.fogbugz.com/f/cases/15947

Seems to be a side effect of case 14676:

https://pharo.fogbugz.com/f/cases/14676/

Re: [Pharo-dev] Usage of stream

[Vincent BLONDEAU]

Hi,

You can do it by using on a subclass of WriteStream peek and nextPut: 
methods. Or you can transform the stream into a Collection by using contents 
and do almost everything you want. 

Cheers,
Vincent 

-Message d'origine-
De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de valmy 
roi
Envoyé : samedi 16 mai 2015 07:48
À : pharo-dev@lists.pharo.org
Objet : [Pharo-dev] Usage of stream

Hi everyone,
I have a stream (read from a file) and i want to iterate through it in order to 
replace every occurences of a special character by another one. how can i do it 
?

--
Kenfack Valmy-Roi
 Ingénieur des travaux en Informatique de Gestion/ Analyste Programmeur Elève 
ingénieur de conception en génie logiciel Institut Supérieur du Sahel Email : 
roykenva...@gmail.com
Tel: +237 22 11 01 87/ +237 676 94 23 01 / +237 699 04 0612

Re: [Pharo-dev] font folder on win7

[Vincent BLONDEAU]

The best is to use environment variables :

Under W7 it is :

%SYSTEMROOT%\Fonts

 

But you can get it under Pharo:

PlatformResolver forCurrentPlatform directoryFromEnvVariableNamed:
'SYSTEMROOT'

 

Vincent

 

De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de
Chris Cunningham
Envoyé : vendredi 4 avril 2014 19:09
À : Pharo Development List
Objet : Re: [Pharo-dev] font folder on win7

 

It is located in \Windows\Fonts (and window is case-agnostic, so
\windows\fonts works as well)

 

-cbc

 

On Fri, Apr 4, 2014 at 9:48 AM, Pharo4Stef pharo4s...@free.fr wrote:

Hi guys


I’m trying to understand why people get problems with fonts on windows.
The logic in the font manager is

 'cdefghijklmnopqrstuvwxyz'
et pour chaque disc dans  '\windows\fonts' '\winnt\fonts


but I wonder if the location of font on windows 7 is correct.
Can anybody with a window 7 report where the fonts are located?

stef

 

Re: [Pharo-dev] FileSystem-Git status update

[Vincent Blondeau]

Le 14/03/2014 11:11, Max Leske a écrit :

Hi everyone

I promised to keep you posted about the progress, so here goes:

- Esteban and I worked together yesterday and we got callbacks working
- I will now do some cleanup so that its actually possible to work on libgit2 
(some bindings have changed between versions 0.18 and 0.20 and I need to find 
out which)
- Esteban and I will sit together again on Monday and prepare work for others / 
implement the object model on top of libgit2. I hope that we can separate tasks 
so that multiple people can work in parallel

In my opinion we should be able to create local repositories, perform commits, 
switch branches and do checkouts by tuesday next week. Optimistically, fetch 
and push should also work by the end of the week.
But that’s really just conjecture and I’ll keep you all posted.

Just a reminder: at the moment we are working to get Git running with NativeBoost *at 
all*. Plans for abstraction, Monticello - Git, Github etc. should certainly 
be discussed, but don’t expect those things to be there at the end of next week.

Max



That's seems cool !

As you will use NativeBoost, do you plan to do it works under Windows 7 ?

Vincent

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

[Vincent Blondeau]

  
  
Hi Pharoers,

We are encounter a problem with text displaying under Roassal.
Roassal is a Moose tool to make
  some graphics visualisations, principally graphs.
  Some visualisations are displaying some text, like :
  
  - ROMondrianExample new centeredText
  - ROMondrianExample new temporaryEdges
  - ROMondrianExample new labeledRectangle
  
  They use AthensCanvas to render.
  
  Since the beginning of February, we experiment very strange
  problems with font displaying. See by yourself :
  
  What we expect :
  
  What we have :
  
  You can see that the letters in each word are not of the same
  size.
  (To reproduce do : "ROMondrianExample new labeledRectangle" in a
  fresh Moose image :
https://ci.inria.fr/moose/job/moose-5.0/lastSuccessfulBuild/artifact/moose-5.0.zip)
  
  We thought it was a font problem. So
  we updated the fonts to use this one :
  LogicalFont familyName: StandardFonts defaultFont familyName
  pointSize: aSize
  which is the default system font. (The fonts are located in
  ROFontOrganizerAthens).
  
  But the problem was not solved.
  
  After some searches, we saw that Roassal (via the ROAthensCanvas)
  uses AthensCairoCanvas and this class has been changed begin
  February to use native boost. 
  The closed issue related is :
  
  12765 Athens font rendering missing letters and missizing others
   https://pharo.fogbugz.com/f/cases/12765
  
  That should resolve the problem instead of created one ;)
  
  
  So if we load the older packages of Athens-Core and Athens-Cairo
  (before the issue resolution):
  
  Name: Athens-Core-MarcusDenker.34
  Author: MarcusDenker
  Time: 5 July 2013, 10:59:47.206954 am
  UUID: e844b2d4-b091-42a4-9be0-17101dcdbd30
  Ancestors: Athens-Core-MarcusDenker.33,
  Athens-Core-ErwanDouaille.33
  
  Name: Athens-Cairo-MarcusDenker.51
  Author: MarcusDenker
  Time: 26 August 2013, 4:03:06.190096 pm
  UUID: 9e1bfddb-67f7-4a36-864d-11060b8b6881
  Ancestors: Athens-Cairo-SebastianTleye.50
  
  we have no problem of font displaying !
  
  The question is :
  What we should adapt in Roassal to support this new implementation
  of Athens ? Or is Athens (by the native boost primitives) broken ?
  
  Thanks in advance !
  
      
      Vincent BLONDEAU
  
  


  

___
Moose-dev mailing list
moose-...@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

[Pharo-dev] Cant Load NeoJson

[Vincent Blondeau]

Hi,

I use NeoJson in my project and it accesses the http://mc.stfx.eu/Neo 
website.


This site return :

 GET /Neo HTTP/1.1
 User-Agent: curl/7.29.0
 Host: mc.stfx.eu
 Accept: */*

 HTTP/1.1 500 Internal Server Error
 Date: Thu, 18 Jul 2013 11:10:43 GMT
 Server: Zinc HTTP Components 1.0
 Content-Type: text/plain;charset=utf-8
 Content-Length: 48
 Vary: Accept-Encoding
 Connection: close

MessageNotUnderstood: receiver of now is nil

What is not I expected...

Cheers,
Vincent

Re: [Pharo-dev] Cant Load NeoJson

[Vincent Blondeau]

Le 18/07/2013 15:12, Sven Van Caekenberghe a écrit :

On 18 Jul 2013, at 13:27, Sven Van Caekenberghe s...@stfx.eu wrote:


I'll have a look at the server ASAP.

http://mc.stfx.eu is OK again.

Sorry for the inconvenience.

Sven


--
Sven Van Caekenberghe
http://stfx.eu
Smalltalk is the Red Pill




Thanks Sven !

[Pharo-dev] Notification extends Exception...

[Vincent Blondeau]

Hi,

For Moose on web, I have to implement the loading of a Moose Model by a 
HTML post request.

This request send a file which have to been parsed to create a model.

The parsing launch a Job (by an UIManager) and the Job throws a 
JobStartNotification at his beginning.

JobStartNotification is a subclass of Exception.
I use a Zinc Server. So when I do the request, Zinc catch the Exception 
and send an error as response.


Has a Notification to be considered like an Exception and not like a 
catchable object, because it's just some information... ?


Cheers,
Vincent