[Pharo-dev] Re: Question about MethodDictionary in TraitedClass (methodDict/localMethodDict)

[Andrei Chis]

On Thu, May 12, 2022 at 3:19 PM Marcus Denker 
wrote:

>
>
> > On 12 May 2022, at 11:27, Andrei Chis 
> wrote:
> >
> > Hi,
> >
> > We were profiling the loading of code that uses many Traits. We saw
> something like this (this is a tally for
> `TraitedMetaclass>>#addAndClassifySelector:withMethod:inProtocol:`):
> > 
> >
> > From what we saw in
> `TraitedMetaclass>>#addAndClassifySelector:withMethod:inProtocol:` a method
> is first added to `localMethodDict` and then it calls the super method that
> adds the selector to the `methodDict` of the actual class in
> `Behaviour>>addSelectorSilently:withMethod: `. Because of this we basically
> get an overhead as a method is added to two method dictionaries and adding
> a method to a MethodDictionary is slower, as it does operations like
> `flushCache` and `cachePragmas`.
> >
> > Should the `localMethodDict` also be an instance of MethodDictionary or
> could it be a simple dictionary?
> >
>
> I think it can be normal Dictionary: MethodDictionary we just meed where
> there VM executes code (for flushCache) and for lookup.
>

Ok. I can experiment with replacing it with a Dictionary and see how it
goes.


>
> The only downside is that it then uses a little bit more memory
> (MethodDictionary does not use associations), but that should be no problem.
>

Indeed that's an interesting aspect. Maybe more important for the Pharo
image is memory rather than loading speed.

Cheers,
Andrei


>
> Marcus
>

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

[Andrei Chis]

Hi Jimmie,

I was scanning through this thread and saw that the Python call uses
the sum function. If I remember correctly, in Python the built-in sum
function is directly implemented in C [1] (unless Python is compiled
with SLOW_SUM set to true). In that case on large arrays the function
can easily be several times faster than just iterating over the
individual objects as the Pharo code does. The benchmark seems to
compare summing numbers in C with summing numbers in Pharo. Would be
interesting to modify the Python code to use a similar loop as in
Pharo for doing the sum.

Cheers,
Andrei

[1] 
https://github.com/python/cpython/blob/135cabd328504e1648d17242b42b675cdbd0193b/Python/bltinmodule.c#L2461

On Mon, Jan 10, 2022 at 9:06 PM Jimmie Houchin  wrote:
>
> Some experiments and discoveries.
>
> I am running my full language test every time. It is the only way I can 
> compare results. It is also what fully stresses the language.
>
> The reason I wrote the test as I did is because I wanted to know a couple of 
> things. Is the language sufficiently performant on basic maths. I am not 
> doing any high PolyMath level math. Simple things like moving averages over 
> portions of arrays.
>
> The other is efficiency of array iteration and access. This why #sum is the 
> best test of this attribute. #sum iterates and accesses every element of the 
> array. It will reveal if there are any problems.
>
> The default test  Julia 1m15s, Python 24.5 minutes, Pharo 2hour 4minutes.
>
> When I comment out the #sum and #average calls, Pharo completes the test in 
> 3.5 seconds. So almost all the time is spent in those two calls.
>
> So most of this conversation has focused on why #sum is as slow as it is or 
> how to improve the performance of #sum with other implementations.
>
>
>
> So I decided to breakdown the #sum and try some things.
>
> Starting with the initial implementation and SequenceableCollection's default 
> #sum  time of 02:04:03
>
>
> "This implementation does no work. Only iterates through the array.
> It completed in 00:10:08"
> sum
> | sum |
>  sum := 1.
> 1 to: self size do: [ :each | ].
> ^ sum
>
>
> "This implementation does no work, but adds to iteration, accessing the value 
> of the array.
> It completed in 00:32:32.
> Quite a bit of time for simply iterating and accessing."
> sum
> | sum |
> sum := 1.
> 1 to: self size do: [ :each | self at: each ].
> ^ sum
>
>
> "This implementation I had in my initial email as an experiment and also 
> several other did the same in theirs.
> A naive simple implementation.
> It completed in 01:00:53.  Half the time of the original."
> sum
>| sum |
> sum := 0.
> 1 to: self size do: [ :each |
> sum := sum + (self at: each) ].
> ^ sum
>
>
>
> "This implementation I also had in my initial email as an experiment I had 
> done.
> It completed in 00:50:18.
> It reduces the iterations and increases the accesses per iteration.
> It is the fastest implementation so far."
> sum
> | sum |
> sum := 0.
> 1 to: ((self size quo: 10) * 10) by: 10 do: [ :i |
> sum := sum + (self at: i) + (self at: (i + 1)) + (self at: (i + 2)) + 
> (self at: (i + 3)) + (self at: (i + 4))  + (self at: (i + 5)) + 
> (self at: (i + 6)) + (self at: (i + 7)) + (self at: (i + 8)) + (self at: (i + 
> 9))].
>
> ((self size quo: 10) * 10 + 1) to: self size do: [ :i |
> sum := sum + (self at: i)].
>   ^ sum
>
> Summary
>
> For whatever reason iterating and accessing on an Array is expensive. That 
> alone took longer than Python to complete the entire test.
>
> I had allowed this knowledge of how much slower Pharo was to stop me from 
> using Pharo. Encouraged me to explore other options.
>
> I have the option to use any language I want. I like Pharo. I do not like 
> Python at all. Julia is unexciting to me. I don't like their anti-OO approach.
>
> At one point I had a fairly complete Pharo implementation, which is where I 
> got frustrated with backtesting taking days.
>
> That implementation is gone. I had not switched to Iceberg. I had a problem 
> with my hard drive. So I am starting over.
>
> I am not a computer scientist, language expert, vm expert or anyone with the 
> skills to discover and optimize arrays. So I will end my tilting at windmills 
> here.
>
> I value all the other things that Pharo brings, that I miss when I am using 
> Julia or Python or Crystal, etc. Those languages do not have the vision to do 
> what Pharo (or any Smalltalk) does.
>
> Pharo may not optimize my app as much as x,y or z. But Pharo optimized me.
>
> That said, I have made the decision to go all in with Pharo. Set aside all 
> else.
> In that regard I went ahead and put my money in with my decision and joined 
> the Pharo Association last week.
>
> Thanks for all of your help in exploring the problem.
>
>
> Jimmie Houchin

Re: [Pharo-dev] Bugs still open on traits

[Andrei Chis]

Hey!

They are:
 https://github.com/pharo-project/pharo/issues/3158
 https://github.com/pharo-project/pharo/issues/4565

Cheers,
Andrei

On Sat, Nov 23, 2019 at 12:39 PM ducasse  wrote:

> Hi andrei
>
> can you tell us the bug that you mentioned to me on traits and that
> skipped our radar?
>
> Stef
>
>
>
>

Re: [Pharo-dev] What is a GlobalIdentifier

[Andrei Chis]

Hi,

I think we mostly added it for the GTEventCollector, as a way to
detect if events coming from different images were from the same
machine.

Cheers,
Andrei

On Fri, Oct 4, 2019 at 9:27 PM Stéphane Ducasse
 wrote:
>
> Hi
>
> We have a package SystemIdentification and I would like to know if this is 
> still in use.
>
>
> Here is the comment of the class.
>
> I keep global IDs that are used for tracking user activity, e.g. computer id. 
> By default, you should access me by calling #uniqueInstance.
>
> Responsibility:
> The IDs that are important to store onto disk (and shared by all images) 
> should be placed in persistedInformation instance variable. On other hand, if 
> you do not want to store it onto disk, create a new instance variable. I can 
> #loadPreferences and #savePreferences onto a disk.
>
> I know computer ID and secret ID. Computer ID is a global UUID that is share 
> among all the images. It is stored on a local disk. Secret ID is use for 
> encrypting information, e.g., class names, method names. You can use 
> #hashForText: method.
>
> Collaborators: I do not collaborate with other classes. I only offer the 
> basic IDs for other frameworks.
>
> Public API and Key Messages
>
> - computerUUID
> - ensureComputerUUID
> - hashForText:
> - loadPreferences
> - savePreferences.
>
> Before using #computerUUID, you should call #ensureComputerUUID. It will 
> update UUID from the disk or stores existing one if it is not stored yet. I 
> behave like this as automatic storing data to disk on image start-up leads to 
> errors.
>
>
> It looks like it is used by the GTEventCollector and I wonder if it is used 
> and useful anymore.
>
> Stef
>
>
>
> 
> 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] how implement isAbstract?

[Andrei Chis]

I ended up being surprised today that classes that have abstract
methods (send #subclassResponsibility) were returning false to
`isAbstract` and true to `hasAbstractMethods`.
I see that the behavior for isAbstract changed over the years: when it
was added [1] it was checking for abstract methods. Then it was
changed to always return false and allow overrides [2].

Is there an explicit need to have/keep `isAbstract` at the class
level? Users can still instantiate those classes, send message to them
and get SubclassResponsibility errors. Tools could implement specific
solutions for handling this.

Cheers,
Andrei

[1] https://github.com/pharo-project/pharo/pull/541/files
[2] https://github.com/pharo-project/pharo/pull/1090/files

On Mon, Apr 1, 2019 at 3:02 PM Tim Mackinnon  wrote:
>
> On 1 Apr 2019, at 09:54, Henrik Sperre Johansen 
>  wrote:
>
>
> Or, if the class has subclasses, one could get a suggestion/action to
> implement the missing method as
> missingMethod
> ^self subclassResponsibility
>
> Which also has the benefit of working nicely with the "expected (or was that
> "missing"?) protocol" functionality.
> Unless you meant something else?
>
>
>
> I don’t know if we are all talking about the same thing. In my image, I have 
> a class where I haven’t got the isAbstract defined, and so Calypso shows a 
> red message - as it thinks I’m supposed to implement #execute (if it knows my 
> intent that my class is abstract, then it doesn’t show the red warning). I 
> think this is Denis’ question?
>
> Sure, if I choose to use the abstract class, then its my choice, but as a 
> lint checker -having useful warnings is helpful. But it is a nuisance 
> defining isAbstract - and I’d almost prefer it assumes its abstract in this 
> case (the normal expectations?) unless I tag it as concrete and signal to 
> users that they might consider using my class (its probably a design smell 
> these days though)
>

[Pharo-dev] iceberg: merging branches just at the git level without changing code in the image

[Andrei Chis]

Hi,

Currently in Iceberg to merge a branch into another, we need to checkout
the branch into which we want to merge and then do the merge.
Checking out a branch also updates the code in the image, which when
needing to perform automatic releases on a branch can cause issues.

Is there already a way in Iceberg to switch to a branch (for example
`release`) and then merge another branch (for example `master`) into it
without updating any code in the image?
The use-case is that the user is on the `master` branch and needs to merge
`master` into `release` without changing any code in the image.

I found LGitRepository>>#merge:, but it seems not to be used anywhere in
the image.

Another way would be to implement something like the method below. This:
  - calculates what changes need to be merged
  - always takes what is on the left branch (in this case what is on master
overrides what is on release)
  - does not call loadChangesInWorkingCopy: to update the working copy as
the code is already in the image
  - refreshes the dirty packages in case there are changes between what is
on the image and what is on disk

```
IceMerge>>#executeWithAcceptingLeftOnConflictAndWithoutImageUpdate
| commitToAdvance |
mergeCommit validateCanMerge.
self isAlreadyMerged ifTrue: [ ^ self ].

self calculateChanges.
self conflictsDo: [ :operation |
operation selectLeft.
].
commitToAdvance := self updateHead.
"Do not update the working copy"
"repository workingCopy loadChangesInWorkingCopy: self
changesToWorkingCopyTree."
repository workingCopy refreshDirtyPackages.
^ commitToAdvance
```

Could something like the above solution work? Or are there other issues to
take into account?

Cheers,
Andrei

Re: [Pharo-dev] Is metacello aware of MC branches???

[Andrei Chis]

Hi,

Would something like this work:

 spec for: #'pharo6.0.x' do: [
spec package: 'Smallapack-StdLib' with: [
  spec
 file:  'Smallapack-StdLib.UFFI-nice.1']
]

Or maybe in the baseline you can have:

 spec package: 'Smallapack-StdLib' with: [
  spec
 file:  'Smallapack-StdLib.UFFI-nice']
]


Cheers,
Andrei


On Fri, Jan 11, 2019 at 12:19 PM Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com> wrote:

> Hi all,
> I'm trying to resolve a dialect compatibility problem like this:
>
> I want to load the Squeak and Pharo3 to 5 version depending on FFI
> Smallapack-StdLib-nice.1
>
> For Pharo6, I made a different branch depending on UFFI
> Smallapack-StdLib.UFFI-nice.1
>
> In the base line, i tell
> spec for: #'common' do: [
> spec blessing: #'baseline'.
> spec repository: 'http://www.squeaksource.com/Smallapack'.
> spec package: 'Smallapack-StdLib']
> and in the version I tell
>
> spec for: #squeak do: [
> spec package: 'Smallapack-StdLib' with:
> 'Smallapack-StdLib-nice.1'].
> spec for: #'pharo5.0.x' do: [
> spec package: 'Smallapack-StdLib' with:
> 'Smallapack-StdLib-nice.1'].
> spec for: #'pharo6.0.x' do: [
> spec package: 'Smallapack-StdLib' with:
> 'Smallapack-StdLib.UFFI-nice.1'].
>
> but the configuration loads Smallapack-StdLib-nice.1 instead of
> Smallapack-StdLib.UFFI-nice.1
>
> I would like to avoid using two different package names because it
> complexifies the baseline for nothing.
> It the same package, just a different branch.
> Isn't it possible?
> Why?
> Can we fix it?
>

[Pharo-dev] Iceberg - Merging when there are changes in the working copy

[Andrei Chis]

Hi,

IceCommitish>>#validateCanMerge has the warning: ''Experimental Feature:
merge when there is a dirty working copy. Could cause a loss of your local
changes. Please commit before merge.''. Are there some known situations
when code can be lost?

I'm asking because in releaser (
https://github.com/feenkcom/gtoolkit-releaser) we want to switch (not
checkout) from the `master` branch to the `release` branch and then merge
`master` into `release` running into the above warning.
Switching to `release` branch, does a checkout at the git level, leaving
the image code the same. Hence, the packages that have changed will be
marked as dirty.  So there aren't manual changes just changes caused by
switching to a different branch.

Cheers,
Andrei

Re: [Pharo-dev] [Moose-dev] Re: Migrate PetitParser (1) on GitHub under moosetechnology organisation?

[Andrei Chis]

Super. I can also help if you need so.

On Mon, Dec 3, 2018 at 3:59 PM Julien  wrote:

> Sure, I will keep the history.
>
> I will see how much time it takes to migrate PetitParser.
>
> If it does not take too much time, maybe I will do it for the two others
> repository.
>
> Julien
>
> ---
> Julien Delplanque
> Doctorant à l’Université de Lille
> http://juliendelplanque.be/phd.html
> Equipe Rmod, Inria
> Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq
> Numéro de téléphone: +333 59 35 86 40
>
> Le 3 déc. 2018 à 15:55, Andrei Chis  a écrit :
>
> Hi,
>
> That's definitely a good idea.
>
> Just would also be very nice to use Peter's migration tool to also capture
> the history+authors.
> (I can provide you with a lis of authors that for the migration tool that
> should cover most authors from PetitParser).
>
> If you're at this, could also help to migrate the PetitSQLite and
> PetitJava projects.
>
> Cheers,
> Andrei
>
>
> On Mon, Dec 3, 2018 at 3:41 PM Julien  wrote:
>
>> Hello,
>>
>> I’d like to migrate PetitParser (1) on GitHub under moosetechnology
>> organisation.
>>
>> I have a project depending on it and there are some stuff I’d like to fix
>> on PetitParser 1 ConfigurationOf (which will become a baseline on GitHub).
>>
>> Is it ok to migrate it?
>>
>> Cheers,
>>
>> Julien
>>
>> ---
>> Julien Delplanque
>> Doctorant à l’Université de Lille
>> http://juliendelplanque.be/phd.html
>> Equipe Rmod, Inria
>> Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq
>> Numéro de téléphone: +333 59 35 86 40
>>
>> ___
>> Moose-dev mailing list
>> moose-...@list.inf.unibe.ch
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
>
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>

Re: [Pharo-dev] [Moose-dev] Migrate PetitParser (1) on GitHub under moosetechnology organisation?

[Andrei Chis]

Hi,

That's definitely a good idea.

Just would also be very nice to use Peter's migration tool to also capture
the history+authors.
(I can provide you with a lis of authors that for the migration tool that
should cover most authors from PetitParser).

If you're at this, could also help to migrate the PetitSQLite and PetitJava
projects.

Cheers,
Andrei


On Mon, Dec 3, 2018 at 3:41 PM Julien  wrote:

> Hello,
>
> I’d like to migrate PetitParser (1) on GitHub under moosetechnology
> organisation.
>
> I have a project depending on it and there are some stuff I’d like to fix
> on PetitParser 1 ConfigurationOf (which will become a baseline on GitHub).
>
> Is it ok to migrate it?
>
> Cheers,
>
> Julien
>
> ---
> Julien Delplanque
> Doctorant à l’Université de Lille
> http://juliendelplanque.be/phd.html
> Equipe Rmod, Inria
> Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq
> Numéro de téléphone: +333 59 35 86 40
>
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>

Re: [Pharo-dev] InterruptedContext vs suspendedContext

[Andrei Chis]

Hi,

>From what I remember they are not always redundant, but I'm not 100% sure
they are both needed.

`suspendedContext` from Process is always the top context of a process.
After execution actions like Step Into, Step Over, Step Through it will be
the same as interruptedContext in the debugger.

They will be different when opening the debugger as a result of an
exception.
Exception>>#debug triggers the workflow for opening a debugger. This uses
`self signalerContext` as the context that is being debugged. This is the
context where the exception was raised and this will be put in the
interruptedContext. As this point the execution of the current process is
not over and it will continue up to
`MorphicUIManager>>#debugProcess:context:label:fullView:notification: `
where the current process is suspended. At that point the two will be
different, as suspendedContext will be the context of the method
MorphicUIManager>>#debugProcess:context:label:fullView:notification: and
the interruptedContext the context that triggered the exception.

But it might be that they are not both needed. One  possible option might
be to force the process to step to the context that raised the exception
when the debugger is created. For example in DebugSession>>process:context:.
Apart from when opening the debugger I do not know if there is another
situation where those two can diverge.

Cheers,
Andrei

On Fri, Nov 30, 2018 at 11:54 AM Thomas Dupriez <
tdupr...@ens-paris-saclay.fr> wrote:

> Hello,
>
>
> Instances of DebugSession have an "interruptedContext" and an
> "interruptedProcess" instance variable.
>
> Instances of Process have a "suspendedContext" instance variable.
>
> Does someone know if there is a relation between the interruptedContext of
> a DebugSession and the suspendedContext of its interruptedProcess? At first
> glance it seems like these two variables are redundant and store the same
> Context.
>
> Thomas Dupriez
>

Re: [Pharo-dev] Slowness when loading code in Pharo 7?

[Andrei Chis]

Hi,

In my case I get:

pharo 61
* disabled:
0:00:09:39.43
* enabled:
0:00:10:25.173"

pharo 70
* disabled:
0:00:12:44.701
* enabled:
0:00:21:21.285

Each time in a clean folder with a new image. All tests are with the
current stable vm on High Sierra.

Cheers,
Andrei

On Thu, Oct 4, 2018 at 8:23 AM  wrote:

> On Wed, 2018-10-03 at 20:08 +0200, Peter Uhnak wrote:
> >
> >
> > On Wed, Oct 3, 2018 at 7:31 PM Juraj Kubelka via Pharo-dev  > @lists.pharo.org> wrote:
> > > Hi!
> > >
> > > I did the same measurement for Pharo 6.1. To summarize it I have
> > > those results:
> > >
> > > By executing:
> > >
> > > -=-=-=-
> > > EpMonitor current disable.
> > > [ Metacello new
> > >   baseline: 'GToolkit';
> > >   repository: 'github://feenkcom/gtoolkit/src';
> > >   load.
> > > ] timeToRun
> > > -=-=-=-
> > >
> > > Pharo 6.1 64bit macOS: 6 minutes
> > > Pharo 7.0 64bit macOS: 8 minutes
> > >
> > > With EpMonitor current enabled it is:
> > >
> > > Pharo 6.1 64bit macOS: 7 minutes
> > > Pharo 7.0 64bit macOS: 15 minutes
> > >
> >
> > So nice... I was just trying to install GToolkit in P6.1 on Windows
> > (but with updated Iceberg)... it took over 1.5 hours (SmaCC was
> > probably 30 minutes by itself), and then the image crashed... really
> > looking forward to pre-made images :)
> >
> > Peter
>
> I ran the attached script on my debian 64 bits (disk: slow HDD w/ext4,
> cpu: i5 ram: 12gb). Here, the slowdown from 61 to 70 is not as evident
> as in your cases.
>
> It's only me? It can help if others can run the script and report your
> results in other computers and OSs.
>
> Two output examples:
> ---
>
> pharo 61
> * disabled:
> 0:00:07:30.783
> * enabled:
> 0:00:08:27.931
>
> pharo 70
> * disabled:
> 0:00:08:24.403
> * enabled:
> 0:00:09:12.858
>
> ---
>
> pharo 61
> * disabled:
> 0:00:08:16.036
> * enabled:
> 0:00:09:21.368
>
> pharo 70
> * disabled:
> 0:00:08:06.57
> * enabled:
> 0:00:10:05.194
>
> ---
>
> pharo 61
> * disabled:
> 0:00:07:39.538
> * enabled:
> 0:00:08:33.778
>
> pharo 70
> * disabled:
> 0:00:07:23.528
> * enabled:
> 0:00:09:11.453
>
> ---
> Note: the script removes pharo-local/ before loading the code to
> download again everything (and I don't have configured a central repo
> in personal settings or something like that). It should be more fair to
> compare to have locally cached as much as possible. I tried once and it
> was reducing a couple of minutes, but the conclusion was the same.
>
> Additionally: In both 61 and 70, I browsed the resulting ombu file
> (>110 mb), it was not thaat bad...
> ~5 seconds when I clicked on the file, and then almost no delay on
> scroll and when clicking on a particular change.
>
> But: The problem was when I clicked on a filter and it started to parse
> each change... I waited like 10 minutes and then closed it. No visual
> feedback, and looks too inefficient.
>
>
> Martín

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

[Andrei Chis]

Done:
https://pharo.fogbugz.com/f/cases/22547/Creating-a-new-class-using-Class-new-superclass-blocks-the-image-in-Pharo-7

Cheers,
Andrei

On Fri, Oct 5, 2018 at 8:15 PM teso...@gmail.com  wrote:

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

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

[Andrei Chis]

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] Creating a new class using `Class new superclass:` blocks the image in Pharo 7

[Andrei Chis]

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] Slowness when loading code in Pharo 7?

[Andrei Chis]

Hi,

Are there any know slowdowns when loading code in Pharo 7? Usually on my
machine (Mac - HighSierra) loading GToolkit in a Pharo 6.1 images takes
around 9 minutes. In the latest Pharo 7 it takes 20 minutes. On two other
newer laptops running Mac results are similar (15 minutes on Pharo 7 64it,
and 7 minutes on Pharo 6.1 64bit).

We have the impression that most of the times, the regression happens
because of reading sources file. And the sources files are read because of
checking Epicea method changes. We have not done a deep research on it,
just whenever we do CMD+. it stops in that stage.

Cheers,
Andrei

Re: [Pharo-dev] loading from github changes lgit classes?

[Andrei Chis]

I think this was added because on windows if we did not rebuild accessors,
some offsets were nil in external structures. Can that still be an issue?

Cheers,
Andrei

On Tue, Dec 12, 2017 at 7:39 AM, Esteban Lorenzano 
wrote:

>
>
> On 12 Dec 2017, at 04:29, Martin Dias  wrote:
>
> Should the rebuild changes be logged?
> Maybe we can have EpMonitor suspendDuring: […]
>
>
> no they not.
> what should be suspended is field regeneration on bloc config ;)
>
> Esteban
>
>
> Martín
>
> On Mon, Dec 11, 2017 at 6:42 PM, Nicolai Hess 
> wrote:
>
>> :) This looks interesting:
>>
>> So, postload of bloc and some classes (MozEnum, SpartaCairoEnum) doing a
>> rebuild with this author.
>>
>> 2017-12-11 22:27 GMT+01:00 Esteban Lorenzano :
>>
>>> honestly, this should not be happening.
>>> Now, I have no idea why it is happening at all ;)
>>>
>>> I mean, there is no automatic process that would have a UFFI name there
>>> (the only place where this can happen is on #rebuildFieldAccessors and that
>>> will use an UFFIGenerator author, not just UFFI.
>>> And also that method needs to be executed by hand…
>>>
>>> weird… can you search for UFFI in system?
>>>
>>> Esteban
>>>
>>> On 11 Dec 2017, at 22:00, Nicolai Hess  wrote:
>>>
>>> It happens not only from lgit-classes but from other FFI-Subclasses too,
>>> for example AthensCairoMatrix.
>>>
>>> And some methods have a strange version history (see screenshot).
>>> The timestamp of all of the UFFI changes are during loading gtoolkit.
>>> Maybe during loading we have multiple reinitializations that will
>>> recreate autogenerated methods, again and again ?
>>>
>>> 2017-12-11 21:49 GMT+01:00 Nicolai Hess :
>>>
 But these aren't method changes.
 The class definition is changed. (see screenshot)
 It looks like it adds new class variables, even though they were
 alreday in the original fresh image.


 2017-12-11 13:49 GMT+01:00 Max Leske :

> Without taking a closer look, those are probably auto generated
> methods.
>
> Max
>
>
>
> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaih...@gmail.com)
> wrote:
>
> How come, loading a github project writes strange code change entries
> for classes
> like
> LGitFetchOptions
> LGitRemoteCallbacks
> ...
>
> For example, in a Pharo 6.1 image I load bloc like this:
>
> Metacello new
> baseline: 'Bloc';
> repository: 'github://pharo-graphics/Bloc:pharo6.1/src';
> load: #core
>
> In my Epicea code change window I see this entries (see screenshot).
> And the final "new" version of this classes, (class definitions) just
> look like the
> original class definition in a fresh image.
>
>
>

>>> 
>>>
>>>
>>>
>>
>
>

[Pharo-dev] Pharo 6.1 32bit/64bit on CentOS 7 with Iceberg

[Andrei Chis]

Hi,

Does anybody use Pharo 6.1 (32 or 64 bit) on CentOS 7?
I am getting randomly the following crash when trying to clone a repository
from github. While this might suggest some kind of of out memory error
there should be enough memory.

PrimitiveFailed: primitive #allocateExecutablePage in FFICallbackThunk
class failed
FFICallbackThunk class(Object)>>primitiveFailed:
FFICallbackThunk class(Object)>>primitiveFailed
FFICallbackThunk class>>allocateExecutablePage
[ ExecutablePages add: self allocateExecutablePage ] in FFICallbackThunk
class>>unusedBlockInExecutablePage in Block: [ ExecutablePages add: self
allocateExecutablePage...etc...
[ caught := true.
self wait.
blockValue := mutuallyExcludedBlock value ] in Semaphore>>critical: in
Block: [ caught := true
BlockClosure>>ensure:
Semaphore>>critical:
FFICallbackThunk class>>unusedBlockInExecutablePage
FFICallbackThunk class>>privateFinalizingNew
FFICallbackThunk class>>newCCall
CallbackForIA32(Callback)>>callbackEvaluator:
Callback class>>forCallbackEvaluator:
LGitTransportCertificateCheckCallback(FFICallback)>>signature:block:
LGitTransportCertificateCheckCallback class(FFICallback
class)>>signature:block:
LGitTransportCertificateCheckCallback class(LGitCallback class)>>on:
LGitRemoteCallbacks class>>newCertificateCheckCallback
LGitRemoteCallbacks class>>defaults
LGitRemoteCallbacks class>>withProvider:
LGitCloneOptions class>>withCredentialsProvider:
[ | repo cloneOptions |
repo := LGitRepository on: self location.
cloneOptions := LGitCloneOptions
withCredentialsProvider: IceCredentialsProvider default.
repo clone: url options: cloneOptions.
aBranchName ifNotNil: [ repo checkout: aBranchName ].
(LGitRemote of: repo named: 'origin')
lookup;
setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch:
in Block: [ | repo cloneOptions |...
[ self checkInitialized.
aBlock value ] in LGitGlobal class>>runSequence: in Block: [ self
checkInitialized
[ activeProcess psValueAt: index put: anObject.
aBlock value ] in LGitActionSequence(DynamicVariable)>>value:during: in
Block: [ activeProcess psValueAt: index put: anObject
BlockClosure>>ensure:
LGitActionSequence(DynamicVariable)>>value:during:
LGitActionSequence class(DynamicVariable class)>>value:during:
LGitGlobal class>>runSequence:
IceLibgitLocalRepository>>cloneRepositoryFrom:branch:
IceRepositoryCreator>>createRepository
[ (IceRepositoryCreator new
url: remoteUrl;
subdirectory: repoPath;
branchName: self projectVersion;
createRepository) register ] in
MCGitHubRepository>>getOrCreateIcebergRepository
in Block: [ (IceRepositoryCreator new...
OrderedCollection(Collection)>>detect:ifFound:ifNone:

Cheers,
Andrei

Re: [Pharo-dev] GTInspector auto refresh hooks?

[Andrei Chis]

On Wed, Aug 9, 2017 at 3:32 PM, Denis Kudriashov 
wrote:

> Actually I found trick:
>
> composite fastTable
>
> title: 'Devices';
> display: [ devices ];
> wantsAutomaticRefresh: true;
>
>  *when: GLMPresentationRefreshRequest do: [myModel update].*
>
>
> Event handler can be executed after actual view update because announcer
> do not ensure delivering order. But in that case new value will be shown at
> next refresh which should be fine.
> What you thing?
>

Interesting trick :). But I think it should work. Like you said in the
worst case the user will see the new data at the next refresh.

Cheers,
Andrei


>
> 2017-08-09 13:47 GMT+02:00 Andrei Chis :
>
>> Hi Denis,
>>
>> The current update mechanism in the inspector is very light, in the sense
>> that it only updates the visual representation of elements and does not
>> recompute them, nor offers any hooks into the update process.
>> Indeed having a way to also recompute the display elements could be
>> useful. We could change the update mechanism to add different kind of
>> update strategies.
>>
>> Cheers,
>> Andrei
>>
>> On Wed, Aug 9, 2017 at 10:58 AM, Denis Kudriashov 
>> wrote:
>>
>>> Hi.
>>>
>>> Is there a way in GTInspector presentation to call some special updating
>>> block before each of auto refresh operation?
>>>
>>> I want something like:
>>>
>>> composite fastTable
>>> title: 'Devices';
>>> display: [ devices ];
>>> wantsAutomaticRefresh: true;
>>>
>>> * beforeUpdateDo: ["rows updating code"]*
>>>
>>> Imaging my presentation shows database table and I want query updated
>>> rows.
>>>
>>> (I activate updating by  GTInspector setEnabledStepRefreshStatus: true).
>>>
>>> Best regards,
>>> Denis
>>>
>>
>>
>

Re: [Pharo-dev] GTInspector auto refresh hooks?

[Andrei Chis]

Hi Denis,

The current update mechanism in the inspector is very light, in the sense
that it only updates the visual representation of elements and does not
recompute them, nor offers any hooks into the update process.
Indeed having a way to also recompute the display elements could be useful.
We could change the update mechanism to add different kind of update
strategies.

Cheers,
Andrei

On Wed, Aug 9, 2017 at 10:58 AM, Denis Kudriashov 
wrote:

> Hi.
>
> Is there a way in GTInspector presentation to call some special updating
> block before each of auto refresh operation?
>
> I want something like:
>
> composite fastTable
> title: 'Devices';
> display: [ devices ];
> wantsAutomaticRefresh: true;
>
> * beforeUpdateDo: ["rows updating code"]*
>
> Imaging my presentation shows database table and I want query updated rows.
>
> (I activate updating by  GTInspector setEnabledStepRefreshStatus: true).
>
> Best regards,
> Denis
>

[Pharo-dev] Epicea applying multiple changes

[Andrei Chis]

Hi,

Is there some known bug in Epicea when applying multiple changes at once in
Pharo 6?

I had a few crashes lately and each time when recovering the changes by
selecting multiple changes at once some changes are skipped. If I apply
manually each change it works.

Cheers,
Andrei

Re: [Pharo-dev] debug vm windows?

[Andrei Chis]

On Mon, Jun 19, 2017 at 1:20 PM, Peter Uhnak  wrote:

> Hi,
>
> the instructions are not merged yet and I am not sure whether something
> has changed since I wrote it (April 8), but I wrote down instructions and
> created scripts for building the VM on Windows (7+)
>
> https://github.com/pharo-project/pharo-vm/pull/128
> https://github.com/peteruhnak/pharo-vm/blob/windows-build/README-Win32.md
> https://github.com/peteruhnak/pharo-vm/tree/windows-build/scripts/windows
>

By the way, thanks for publishing these scripts.
I found them a while back and they were quite useful in figuring out how to
configure cygwin.

Cheers,
Andrei


in particular the Manual Compilation at the end; iirc `mvm -a` creates
> asserting VM, `mvm -d` debug, `mvm -f` regular, and `mvm -A` all of them.
>
> Peter
>
>
> On Tue, Jun 13, 2017 at 10:57:45PM +0200, p...@highoctane.be wrote:
> > Not at the moment.
> >
> > On Tue, Jun 13, 2017 at 10:08 PM, Andrei Chis <
> chisvasileand...@gmail.com>
> > wrote:
> >
> > > Thanks! Any chance you can redo the build to get also a debug vm for
> > > the latest version?
> > >
> > > Cheers,
> > > Andrei
> > >
> > > On Tue, Jun 13, 2017 at 8:02 PM, p...@highoctane.be <
> p...@highoctane.be>
> > > wrote:
> > > > I have an older build here.
> > > >
> > > > https://ci.appveyor.com/project/philippeback/pharo-vm
> > > >
> > > > https://bintray.com/pharophile/pharo-vm/build/
> > > view/files?sort=name&order=asc#files/
> > > >
> > > > There is an normal, assert and debug vm in there.
> > > >
> > > > Phil
> > > >
> > > > On Tue, Jun 13, 2017 at 7:14 PM, Andrei Chis <
> chisvasileand...@gmail.com
> > > >
> > > > wrote:
> > > >>
> > > >> Hi,
> > > >>
> > > >> Is there a Pharo debug vm for windows already build and available
> > > >> somewhere?
> > > >>
> > > >> Cheers,
> > > >> Andrei
> > > >>
> > > >
> > >
> > >
>
>

[Pharo-dev] Windows 10 crash - LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location.

[Andrei Chis]

Hi,

On Windows 10 with the Pharo 6 release and the latest vm [1] I get the
following crash when attempting to save the image after doing some more
intensive computations:

--
# Debug console
# To close: F2 -> 'debug options' -> 'show output console'
# To disable: F2 -> 'debug options' -> 'show console on errors'
LoadLibrary(SurfacePlugin) (998: Invalid access to memory location.

)
LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location.

)
LoadLibrary(c:\pharo6\SurfacePlugin) (998: Invalid access to memory
location.

)
LoadLibrary(c:\pharo6\SurfacePlugin.dll) (998: Invalid access to memory
location.

)
LoadLibrary(SurfacePlugin) (998: Invalid access to memory location.

)
LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location.

)
LoadLibrary(c:\pharo6\SurfacePlugin) (998: Invalid access to memory
location.

)
LoadLibrary(c:\pharo6\SurfacePlugin.dll) (998: Invalid access to memory
location.

)
LoadLibrary(SurfacePlugin) (998: Invalid access to memory location.

)
LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location.

)
LoadLibrary(c:\pharo6\SurfacePlugin) (998: Invalid access to memory
location.

)
LoadLibrary(c:\pharo6\SurfacePlugin.dll) (998: Invalid access to memory
location.

)
--

The image take around 600MB before the crash but that is expected.
I've seen that this error was appearing before in the past.
Any suggestions of how to debug it?

Cheers,
Andrei

[1]
http://files.pharo.org/vm/pharo-spur32/win/pharo-win-i386-201706211817-f54456f.zip

Re: [Pharo-dev] debug vm windows?

[Andrei Chis]

Thanks! Any chance you can redo the build to get also a debug vm for
the latest version?

Cheers,
Andrei

On Tue, Jun 13, 2017 at 8:02 PM, p...@highoctane.be  wrote:
> I have an older build here.
>
> https://ci.appveyor.com/project/philippeback/pharo-vm
>
> https://bintray.com/pharophile/pharo-vm/build/view/files?sort=name&order=asc#files/
>
> There is an normal, assert and debug vm in there.
>
> Phil
>
> On Tue, Jun 13, 2017 at 7:14 PM, Andrei Chis 
> wrote:
>>
>> Hi,
>>
>> Is there a Pharo debug vm for windows already build and available
>> somewhere?
>>
>> Cheers,
>> Andrei
>>
>

Re: [Pharo-dev] Extending the debugger inspector with a new presentation

[Andrei Chis]

Hi,

Currently extending the UI of the debugger is not as easy as extending the
inspector. (It cannot just be done using annotations)
We should work on improving this for Pharo 7.
The actual presentations at the bottom are created
in GTDebuggerVariablesBrowser>>#compose.
To change it in a debugger you need to create a subclass of
both GTGenericStackDebugger and GTDebuggerVariablesBrowser and then
override the class side method #variablesBrowserClass in the debugger.

I see now that GTDebuggerVariablesBrowser >>#compose doesn't really have a
hook for adding new tabs so you'll need to completely override it. We
should add one.

The pragma  is used for presentations that
should only be displayed when inspecting objects in the debugger.

Cheers,
Andrei



On Mon, May 15, 2017 at 9:51 AM, Guillermo Polito  wrote:

> Yeah, in any case, it is not clear what we should do:
>
>  - can't we extend the default debugger presentation?
>  - or should we create a new presentation?
>  - maybe we can do both, but then we have the question: is there a
> criteria to say "if X, extend the default presentation, if Y, create a new
> one"?
>  - How to do it? We can just copy paste an existing class... but...
>  - Also, what happens if we want to add a tab to **EVERY** debugger
> presentation next to the evaluate?
>
> On Mon, May 15, 2017 at 8:22 AM,  wrote:
>
>> I've looked at it, but I can't get to reproduce it. I have trouble
>> finding an entry point to start understanding.
>>
>> Quoting Denis Kudriashov :
>>
>> Hi.
>>>
>>> One possibility is to follow BytecodeDebugger approach. Try to look how
>>> it
>>> is implemented
>>>
>>> 2017-05-12 9:53 GMT+02:00 :
>>>
>>> Hello,

 I would like to extend the debugger with some context-dependent
 information.
 I am playing with metalinks and I would like to show, in the debugger,
 some information if my metalinks are in the selected method.
 This means that:
 - I need to add a new presentation in the debugger next to the
 "variable"
 and "evaluator" ones.
 - I need to filter that presentation to show it depending on which
 method
 is selected.

 I tried to extend ProtoObject with a method like:

 gtDebuggerExpressionMachinViewIn: composite
 

 composite text
 title: 'My machin';
 display: [ :browser :debugger | debugger asString]

 However, this did not add a presentation in the debugger. It only show
 up
 when selecting an object in the debugger inspector (see screenshot).

 How can I extend the debugger as I want?

 Thanks
 Thomas and Guille


>>>
>>
>>
>>
>>
>
>
> --
>
>
>
> Guille Polito
>
>
> Research Engineer
>
> French National Center for Scientific Research - *http://www.cnrs.fr*
> 
>
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>

Re: [Pharo-dev] ./pharo --help returns exit code 1 on ubuntu

[Andrei Chis]

On Fri, May 5, 2017 at 10:13 AM, K K Subbu  wrote:

> On Friday 05 May 2017 03:01 AM, Andrei Chis wrote:
>
>> Any thoughts or places where I can look? This problem is still in the
>> latest vm.
>>
>> Cheers,
>> Andrei
>>
>> On Thu, Mar 30, 2017 at 9:37 AM, Andrei Chis > <mailto:chisvasileand...@gmail.com>> wrote:
>>
>> Hi,
>>
>> In an ubuntu installation with the latest vm and Pharo 6 image when
>> executing `./pharo --help` I get an error code of 1.
>> ...
>> On mac the error code is 0. Also when executing './pharo' or
>> './pharo Pharo.image --help' or './pharo --version' the error code
>> is 0 on both mac and linux.
>>
>
> That is strange. The source code returns 1 for both unix and Mac:


> -platforms/Mac OS/vm/sqMacUnixCommandLineInterface.c 
>   if  (!strcmp(argv[0], "-help"))   {
> usage();
> return 1; }
> -platform/unix/vm/sqUnixMain.c
> if  (!strcmp(argv[0], VMOPTION("help"))){ usage();
>   return 1; }
> ---
>
> BTW, the option is "-help" with a single dash. Two dashes will print the
> same because the option is not recognized. You may as well type "--hep"
> ;-).
>

Thanks for the info!
It's actually a bit stranger. The option should be specified using '--'

./pharo -help
unknown option: -help
Common s:
  --help print this help message, then exit

Then `./pharo -help` returns an exit code of 1 on mac/linux while `./pharo
--help` returns a exit code of 0 on mac and 1 on linux.

I think this behaviour comes from [1] and [2]:

platforms/unix/vm/sqUnixMain.c
if (!strcmp(argv[0], VMOPTION("help"))) { usage(); return 1; }


platforms/iOS/vm/OSX/sqSqueakOSXApplication.m
if ([argData isEqualToString: VMOPTIONOBJ("help")]) {
  [self usage];
  exit(0);
  return 1; }

It's still not clear why running the vm to print the help of the version
should exit with an error code.

Cheers,
Andrei

[1]
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/b076561abada1884750d75a7b144f1450acb949e/platforms/iOS/vm/OSX/sqSqueakOSXApplication.m
[2]
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/995e7aedc3b5aeb76904f92abbd8a7a1bcf8138f/platforms/unix/vm/sqUnixMain.c


>
> Regards .. Subbu
>
>

Re: [Pharo-dev] ./pharo --help returns exit code 1 on ubuntu

[Andrei Chis]

Any thoughts or places where I can look? This problem is still in the
latest vm.

Cheers,
Andrei

On Thu, Mar 30, 2017 at 9:37 AM, Andrei Chis 
wrote:

> Hi,
>
> In an ubuntu installation with the latest vm and Pharo 6 image when
> executing `./pharo --help` I get an error code of 1.
>
> wget -O- get.pharo.org/vmLatest60 | bash
> wget -O- get.pharo.org/60 | bash
> ./pharo --help
> echo $?   --> returns 1
>
> On mac the error code is 0. Also when executing './pharo' or './pharo
> Pharo.image --help' or './pharo --version' the error code is 0 on both mac
> and linux.
> So it seems there is some issues with --help. Actually, it gives a usage
> warning, but still I'd expect to not return an error code.
>
> Usage: Pharo.app/Contents/MacOS/Pharo [...] [
> [...]]
>   Pharo.app/Contents/MacOS/Pharo [...] -- [...]
>
> Cheers,
> Andrei
>

Re: [Pharo-dev] resizing the windows sometimes blocks the image

[Andrei Chis]

Hi,

On Wed, May 3, 2017 at 10:43 AM, Clément Bera 
wrote:

> Hi
>
> Try resizing the window and clicking inside it a couple times. It usually
> refreshes the surface correctly and avoids the need to force quit.
>

I tried to click a few time but nothing happened.
Next time I'll  try more :)


>
> I think it happens to other people too, it seems it's exclusive to Mac OS
> X.
>

Most likely. I didn't had this problem on windows.

Cheers,
Andrei


> Best,
>
> On Wed, May 3, 2017 at 10:23 AM, Andrei Chis 
> wrote:
>
>> Hi,
>>
>> With the latest moose image based on Pharo 6 and vm (32 bit) sometimes
>> when I resize the main window or enter full screen mode on MacOS the window
>> becomes totally white and does not recover:[image: Inline image 1]
>> I need to force quit the image.  Also this happens not that often and
>> quite randomly.
>>
>> Does this happen to anybody else or it's just me?
>>
>> Cheers,
>> Andrei
>>
>
>

[Pharo-dev] resizing the windows sometimes blocks the image

[Andrei Chis]

Hi,

With the latest moose image based on Pharo 6 and vm (32 bit) sometimes when
I resize the main window or enter full screen mode on MacOS the window
becomes totally white and does not recover:[image: Inline image 1]
I need to force quit the image.  Also this happens not that often and quite
randomly.

Does this happen to anybody else or it's just me?

Cheers,
Andrei

Re: [Pharo-dev] saving an image on windows and opening it on mac problems

[Andrei Chis]

Actually if I just execute before saving on Windows the following code I
get no error when opening the image on Mac:

OmSessionStore allInstancesDo: [ :each |
SystemAnnouncer uniqueInstance unsubscribe: each ].



On Thu, Apr 27, 2017 at 9:48 PM, Andrei Chis 
wrote:

> Loaded slice 19990 and the issues is still there with the latest image+vm.
>
> On Thu, Apr 27, 2017 at 9:07 PM, Denis Kudriashov 
> wrote:
>
>> Hi.
>>
>> 2017-04-26 15:06 GMT+02:00 Andrei Chis :
>>
>>>
>>> I saw that there are a few issues about images saved on an operating
>>> system not working when opened on other operating systems:
>>> - https://pharo.fogbugz.com/f/cases/19852/Unable-to-open-ima
>>> ge-in-OSX-after-it-has-been-updated-in-Windows
>>> - https://pharo.fogbugz.com/f/cases/19869/Infinite-loop-on-m
>>> ac-when-opening-an-image-saved-on-windows
>>> - https://pharo.fogbugz.com/f/cases/19272/Image-freezes-on-L
>>> inux-if-it-was-previously-saved-on-Windows
>>> - http://forum.world.st/Image-freezes-on-Linux-if-it-was-pre
>>> viously-saved-on-Windows-td4903258.html
>>>
>>
>> Also this can be related:
>> https://pharo.fogbugz.com/f/cases/19990/UFFI-not-reset-metho
>> d-cache-at-image-startup
>>
>> Can you reproduce original problems with this slice loaded? (it is not
>> integrated yet)
>>
>
>

Re: [Pharo-dev] saving an image on windows and opening it on mac problems

[Andrei Chis]

Loaded slice 19990 and the issues is still there with the latest image+vm.

On Thu, Apr 27, 2017 at 9:07 PM, Denis Kudriashov 
wrote:

> Hi.
>
> 2017-04-26 15:06 GMT+02:00 Andrei Chis :
>
>>
>> I saw that there are a few issues about images saved on an operating
>> system not working when opened on other operating systems:
>> - https://pharo.fogbugz.com/f/cases/19852/Unable-to-open-ima
>> ge-in-OSX-after-it-has-been-updated-in-Windows
>> - https://pharo.fogbugz.com/f/cases/19869/Infinite-loop-on-m
>> ac-when-opening-an-image-saved-on-windows
>> - https://pharo.fogbugz.com/f/cases/19272/Image-freezes-on-L
>> inux-if-it-was-previously-saved-on-Windows
>> - http://forum.world.st/Image-freezes-on-Linux-if-it-was-pre
>> viously-saved-on-Windows-td4903258.html
>>
>
> Also this can be related:
> https://pharo.fogbugz.com/f/cases/19990/UFFI-not-reset-
> method-cache-at-image-startup
>
> Can you reproduce original problems with this slice loaded? (it is not
> integrated yet)
>

Re: [Pharo-dev] saving an image on windows and opening it on mac problems

[Andrei Chis]

Hi Martin,

On Thu, Apr 27, 2017 at 6:14 AM, Martin Dias  wrote:

> Hi Andrei,
>
> Could you tell me what's your "EpMonitor current sessionStore baseLocator"
> ?
>

It's 'a FileLocator {localDirectory}\ombu-sessions'


>
> By default it's a FileLocator, but maybe you personalized it and setted a
> FileReference. FileLocators don't have a WindowsStore but FileReference
> do.
>

I started another thread 'OmSessionStore and SnapshotDone event' where I
described the error better.


>
> The OmSessionStore is part of Epicea, and has a startUp: that executes the
> #ensureCreateDirectory. Well, maybe it shouldn't be done on start up but
> when a change happens... I should try this.
>

The issue is that #ensureCreateDirectory is called before the file system
is initialized. Even if a FileLocator is used for #baseLocator,
#ensureCreateDirectory will need to resolve the file and access the file
system.

Cheers,
Andrei


>
> Martín
>
> On Wed, Apr 26, 2017 at 3:40 PM, H. Hirzel 
> wrote:
>
>> What about loading some TTF fonts into the image?
>>
>> --Hannes
>>
>> On 4/26/17, p...@highoctane.be  wrote:
>> > I'd say that one should clear all fonts being loaded, refresh the list
>> of
>> > available fonts because they are on another location (and this should
>> > happen even moving from windows to windows), and switch back to a
>> default
>> > font that is sure to be available.
>> >
>> > I got an issue with the "hack" font because the new version changed the
>> > file names of the fonts and the system died.
>> >
>> > That should already solve some problems.
>> >
>> > Phil
>> >
>> > On Wed, Apr 26, 2017 at 5:10 PM, Andrei Chis <
>> chisvasileand...@gmail.com>
>> > wrote:
>> >
>> >> Any hints about how to handle Freetype fonts?
>> >> Right now I'm getting also some segmentation faults when opening on mac
>> >> an
>> >> image saved on windows, that seem related to Freetype fonts.
>> >>
>> >> On Wed, Apr 26, 2017 at 5:04 PM, p...@highoctane.be <
>> p...@highoctane.be>
>> >> wrote:
>> >>
>> >>> You will also face serious fun with Freetype fonts.
>> >>>
>> >>> Phil
>> >>>
>> >>> On Wed, Apr 26, 2017 at 3:06 PM, Andrei Chis
>> >>> 
>> >>> wrote:
>> >>>
>> >>>> Hi all,
>> >>>>
>> >>>> I saw that there are a few issues about images saved on an operating
>> >>>> system not working when opened on other operating systems:
>> >>>> - https://pharo.fogbugz.com/f/cases/19852/Unable-to-open-ima
>> >>>> ge-in-OSX-after-it-has-been-updated-in-Windows
>> >>>> - https://pharo.fogbugz.com/f/cases/19869/Infinite-loop-on-m
>> >>>> ac-when-opening-an-image-saved-on-windows
>> >>>> - https://pharo.fogbugz.com/f/cases/19272/Image-freezes-on-L
>> >>>> inux-if-it-was-previously-saved-on-Windows
>> >>>> - http://forum.world.st/Image-freezes-on-Linux-if-it-was-pre
>> >>>> viously-saved-on-Windows-td4903258.html
>> >>>>
>> >>>> I gave the fix in case 19869 a try and with it I can save an image on
>> >>>> windows and open it on mac, however, there are some side effects.
>> >>>> First several folders having the following name are created in the
>> >>>> image
>> >>>> folder:
>> >>>>
>> >>>> '\Users\andrei\test-image'
>> >>>> '\Users\andrei\test-image\pharo-local\'
>> >>>> '\Users\andrei\test-image\pharo-local\ombu-sessions'
>> >>>>
>> >>>> Second, I can only open the image on man once. The second time I get
>> >>>> the
>> >>>> following stack:
>> >>>>
>> >>>> [31mPrimitiveFailed: primitive #createDirectory: in WindowsStore
>> failed
>> >>>> [0mWindowsStore(Object)>>primitiveFailed:
>> >>>> WindowsStore(Object)>>primitiveFailed
>> >>>> WindowsStore(DiskStore)>>createDirectory:
>> >>>> WindowsStore(FileSystemStore)>>ensureCreateDirectory:
>> >>>> WindowsStore(FileSystemStore)>>ensureCreateDirectory:
>> >>>> WindowsStore(FileSystemStore)>>

[Pharo-dev] OmSessionStore and SnapshotDone event (was: saving an image on windows and opening it on mac problems)

[Andrei Chis]

Hi,

OmSessionStore registers an action (OmSessionStore>>#store) when the
event SnapshotDone is triggered.
However this event is triggered immediately when an image is opened after
being saved, before the file system was reset.
This means that OmSessionStore>>#store is called before the file system is
reset.
Hence, if you save an image on windows and open it on mac you run into
issues as OmSessionStore>>#store performs file operations that will work
with a WindowsStore instead of a MacStore.

Does OmSessionStore need to register to SnapshotDone events?
When the image is opened OmSessionStore>>#store will be called anyway as
OmSessionStore registers a start-up action.

Cheers,
Andrei

Re: [Pharo-dev] saving an image on windows and opening it on mac problems

[Andrei Chis]

Any hints about how to handle Freetype fonts?
Right now I'm getting also some segmentation faults when opening on mac an
image saved on windows, that seem related to Freetype fonts.

On Wed, Apr 26, 2017 at 5:04 PM, p...@highoctane.be 
wrote:

> You will also face serious fun with Freetype fonts.
>
> Phil
>
> On Wed, Apr 26, 2017 at 3:06 PM, Andrei Chis 
> wrote:
>
>> Hi all,
>>
>> I saw that there are a few issues about images saved on an operating
>> system not working when opened on other operating systems:
>> - https://pharo.fogbugz.com/f/cases/19852/Unable-to-open-ima
>> ge-in-OSX-after-it-has-been-updated-in-Windows
>> - https://pharo.fogbugz.com/f/cases/19869/Infinite-loop-on-m
>> ac-when-opening-an-image-saved-on-windows
>> - https://pharo.fogbugz.com/f/cases/19272/Image-freezes-on-L
>> inux-if-it-was-previously-saved-on-Windows
>> - http://forum.world.st/Image-freezes-on-Linux-if-it-was-pre
>> viously-saved-on-Windows-td4903258.html
>>
>> I gave the fix in case 19869 a try and with it I can save an image on
>> windows and open it on mac, however, there are some side effects.
>> First several folders having the following name are created in the image
>> folder:
>>
>> '\Users\andrei\test-image'
>> '\Users\andrei\test-image\pharo-local\'
>> '\Users\andrei\test-image\pharo-local\ombu-sessions'
>>
>> Second, I can only open the image on man once. The second time I get the
>> following stack:
>>
>> [31mPrimitiveFailed: primitive #createDirectory: in WindowsStore failed
>> [0mWindowsStore(Object)>>primitiveFailed:
>> WindowsStore(Object)>>primitiveFailed
>> WindowsStore(DiskStore)>>createDirectory:
>> WindowsStore(FileSystemStore)>>ensureCreateDirectory:
>> WindowsStore(FileSystemStore)>>ensureCreateDirectory:
>> WindowsStore(FileSystemStore)>>ensureCreateDirectory:
>> WindowsStore(FileSystemStore)>>ensureCreateDirectory:
>> WindowsStore(FileSystemStore)>>ensureCreateDirectory:
>> WindowsStore(FileSystemStore)>>ensureCreateDirectory:
>> FileSystem>>ensureCreateDirectory:
>> FileReference>>ensureCreateDirectory
>> OmSessionStore>>resetWithStoreNamed:
>> OmSessionStore>>resetWithNextStoreName
>> OmSessionStore>>store
>> WeakMessageSend>>value
>> WeakMessageSend>>cull:
>> WeakMessageSend>>cull:cull:
>> [ action cull: arg1 cull: announcer ] in LegacyWeakSubscription(WeakAnn
>> ouncementSubscription)>>deliver: in Block: [ action cull: arg1 cull:
>> announcer ]
>> BlockClosure>>on:do:
>> BlockClosure>>on:fork:
>> LegacyWeakSubscription(WeakAnnouncementSubscription)>>deliver:
>> [ tmp4 deliver: arg1 ] in SubscriptionRegistry>>deliver:to:startingAt:
>> in Block: [ tmp4 deliver: arg1 ]
>> BlockClosure>>ifCurtailed:
>> SubscriptionRegistry>>deliver:to:startingAt:
>> SubscriptionRegistry>>deliver:to:
>> SubscriptionRegistry>>deliver:
>> SystemAnnouncer(Announcer)>>announce:
>> SystemAnnouncer>>announce:
>> SystemAnnouncer>>snapshotDone:
>> SessionManager>>snapshot:andQuit:
>> [0m
>>
>> So it seems that OmSessionStore is not reset and holds a reference to a
>> the windows path which it tries to create.
>>
>> Cheers,
>> Andrei
>>
>>
>>
>>
>>
>


crash.dmp
Description: Binary data

[Pharo-dev] saving an image on windows and opening it on mac problems

[Andrei Chis]

Hi all,

I saw that there are a few issues about images saved on an operating system
not working when opened on other operating systems:
-
https://pharo.fogbugz.com/f/cases/19852/Unable-to-open-image-in-OSX-after-it-has-been-updated-in-Windows
-
https://pharo.fogbugz.com/f/cases/19869/Infinite-loop-on-mac-when-opening-an-image-saved-on-windows
-
https://pharo.fogbugz.com/f/cases/19272/Image-freezes-on-Linux-if-it-was-previously-saved-on-Windows
-
http://forum.world.st/Image-freezes-on-Linux-if-it-was-previously-saved-on-Windows-td4903258.html

I gave the fix in case 19869 a try and with it I can save an image on
windows and open it on mac, however, there are some side effects.
First several folders having the following name are created in the image
folder:

'\Users\andrei\test-image'
'\Users\andrei\test-image\pharo-local\'
'\Users\andrei\test-image\pharo-local\ombu-sessions'

Second, I can only open the image on man once. The second time I get the
following stack:

[31mPrimitiveFailed: primitive #createDirectory: in WindowsStore failed
[0mWindowsStore(Object)>>primitiveFailed:
WindowsStore(Object)>>primitiveFailed
WindowsStore(DiskStore)>>createDirectory:
WindowsStore(FileSystemStore)>>ensureCreateDirectory:
WindowsStore(FileSystemStore)>>ensureCreateDirectory:
WindowsStore(FileSystemStore)>>ensureCreateDirectory:
WindowsStore(FileSystemStore)>>ensureCreateDirectory:
WindowsStore(FileSystemStore)>>ensureCreateDirectory:
WindowsStore(FileSystemStore)>>ensureCreateDirectory:
FileSystem>>ensureCreateDirectory:
FileReference>>ensureCreateDirectory
OmSessionStore>>resetWithStoreNamed:
OmSessionStore>>resetWithNextStoreName
OmSessionStore>>store
WeakMessageSend>>value
WeakMessageSend>>cull:
WeakMessageSend>>cull:cull:
[ action cull: arg1 cull: announcer ] in
LegacyWeakSubscription(WeakAnnouncementSubscription)>>deliver: in Block: [
action cull: arg1 cull: announcer ]
BlockClosure>>on:do:
BlockClosure>>on:fork:
LegacyWeakSubscription(WeakAnnouncementSubscription)>>deliver:
[ tmp4 deliver: arg1 ] in SubscriptionRegistry>>deliver:to:startingAt: in
Block: [ tmp4 deliver: arg1 ]
BlockClosure>>ifCurtailed:
SubscriptionRegistry>>deliver:to:startingAt:
SubscriptionRegistry>>deliver:to:
SubscriptionRegistry>>deliver:
SystemAnnouncer(Announcer)>>announce:
SystemAnnouncer>>announce:
SystemAnnouncer>>snapshotDone:
SessionManager>>snapshot:andQuit:
[0m

So it seems that OmSessionStore is not reset and holds a reference to a the
windows path which it tries to create.

Cheers,
Andrei

Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

[Andrei Chis]

On Apr 14, 2017 14:13, "Pavel Krivanek"  wrote:



2017-04-14 12:52 GMT+02:00 Andrei Chis :

> Isn't it a bit too late for such a change? Might break projects that
> expect configurations to be present.
>

I do not think so. We do not have configurations for the system itself
(well, we have them in an external repository but they are not update since
switch to baselines). They are used only for the actively maintained
semi-external projects like GT, QA, Epicea, Zinc etc. However even in that
case they are sometimes out-of-sync with the upstream.

Most users of such configurations are using the upstream configurations. If
some one is using wrongly the versions in Pharo, he uses reference to the
Pharo repository where the configurations will still be present.


For the record, I still think it's not the best idea to do this now :)

Cheers,
Andrei


Cheers,
-- Pavel


>
> Cheers,
> Andrei
>
> On Fri, Apr 14, 2017 at 1:07 PM, Pavel Krivanek 
> wrote:
>
>> Hi,
>>
>> in Pharo 7 all configurations will be removed and replaced with the
>> baselines. The bootstrapped image itself does not load the configurations
>> at all. Most of them is now outdated and old versions of configurations in
>> the standard Pharo image can cause problems for users of newer versions
>> semi-internal packages (like Moose-Algos).
>>
>> So we, me and Cyril think that we should remove all current
>> Configurations from the image just before the Pharo 6 release. Do you see
>> any disadvantages of this step?
>>
>> Cheers,
>> -- Pavel
>>
>
>

Re: [Pharo-dev] changing default theme to DarkTheme

[Andrei Chis]

On Apr 14, 2017 14:11, "Denis Kudriashov"  wrote:

Maybe I am alone who do not like the dark theme.


I'm also a fan of the white team. Can't really use the dark one.

Cheers,
Andrei


But to me it is too late for such change. I am sure there are UI
widgets/projects which looks horrible in dark. And people probably test
them in pharo 6 before this change. So they will be very surprised.

Also I am really wondering that this decision was not publicly discussed.
We should vote for such kind of changes.

Anyway settings are recovered at image startup. So I can live with it.

2017-04-14 9:09 GMT+02:00 Esteban Lorenzano :

> Hello guys,
>
> I wanted to let you know that we talked at the board and we want to make
> the DarkTheme a default for Pharo 6.0.
> This is just because we want to have a visual immediate reference of
> changing things (yeah, marketing ;) )
>
> Those which still do not like it can still execute
>
> Pharo3Theme beCurrent.
>
> (in their startup actions, if you want)
>
> And everything will be as before.
>
> Esteban
>

Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

[Andrei Chis]

On Apr 14, 2017 13:55, "Cyril Ferlicot D."  wrote:

On 14/04/2017 12:52, Andrei Chis wrote:
> Isn't it a bit too late for such a change? Might break projects that
> expect configurations to be present.
>

Is there such projects?


I know some that use the GT related ones.


For me it seems really bad to get a project depending on his configuration.


I definetly agree. Just doing it so early to the release will most likely
lead to side effects.

Cheers,
Andrei


> Cheers,
> Andrei
>


--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

[Andrei Chis]

Isn't it a bit too late for such a change? Might break projects that expect
configurations to be present.

Cheers,
Andrei

On Fri, Apr 14, 2017 at 1:07 PM, Pavel Krivanek 
wrote:

> Hi,
>
> in Pharo 7 all configurations will be removed and replaced with the
> baselines. The bootstrapped image itself does not load the configurations
> at all. Most of them is now outdated and old versions of configurations in
> the standard Pharo image can cause problems for users of newer versions
> semi-internal packages (like Moose-Algos).
>
> So we, me and Cyril think that we should remove all current Configurations
> from the image just before the Pharo 6 release. Do you see any
> disadvantages of this step?
>
> Cheers,
> -- Pavel
>

Re: [Pharo-dev] Glamour Fast List selection bug or incorrect usage?

[Andrei Chis]

Hi,

On Tue, Apr 4, 2017 at 5:01 PM, Juraj Kubelka 
wrote:

> Hi,
>
> yes, it is better, but it does not work intuitively. Try the following:
>
> 1. execute your script,
> 2. click on 4 (selection),
> 3. click on 8 (selection),
> 4. click on 4 (deselection),
> 5. click on 4 (selection)
>
> You can see that the third list still keeps the number 8. It is necessary
> to deselect 8 in order to see 4.
>

Indeed, this is not what you'd expect.


>
> This part explains to me how the transmit works:
>
> ```
> tabulator transmit
> from: #one; to: #three;
> from: #two; to: #three;
> transformed: [ :x :y | y ifNil: [ x ] ifNotNil: [ y ] ];
> andShow: [ :a |
> a fastList display: [ :x | Array with: x ] ].
> ```
>
> By using #transformed: I can decide what to use (#one or #two). It is nice
> feature!
>
> I think what I need is having to possibility to change the third list also
> according to what list is active (#one or #two).
> In the first screenshot, the first list is active (blue border). In the
> second screenshot, the second list is active.
> So I would like to update the third list according to the active one.
> Is it possible?
>

Unfortunately this doesn't work out of the box.
We'll need to implement something that can generate evens/populates a port
when a presentation gets the focus.

Cheers,
Andrei


>
>
> Thanks!
> Juraj
>
> On Apr 3, 2017, at 18:53, Andrei Chis  wrote:
>
> Hi,
>
> That's actually the default behavior, but I see there is also a bug.
> Normally if you want to allow deselection in a presentation you should use
> allowDeselection. Just I see there is a bug in the fast table renderer
> because if I add #allowDeselection to the first presentation when clicking
> again on the selected element the selection port is not cleared. If you use
> #list instead of #fastList it works.
>
> I think you can get the desired behaviur using this code:
>
> -
> tabulator := GLMTabulator new.
>
> tabulator column: #one; column: #two; column: #three.
>
> tabulator transmit to: #one; andShow: [ :composite |
> composite list
> allowDeselection;
> display: [ :x | Array with: x ] ].
> tabulator transmit to: #two; andShow: [ :composite |
> composite list
> allowDeselection;
> display: [ :x | Array with: 2 * x ] ].
>
> tabulator transmit
> from: #one; to: #three;
> from: #two; to: #three;
> transformed: [ :x :y | y ifNil: [ x ] ifNotNil: [ y ] ];
> andShow: [ :a |
> a fastList display: [ :x | Array with: x ] ].
>
> tabulator openOn: 4.
> -
>
>
> Cheers,
> Andrei
>
> On Mon, Apr 3, 2017 at 9:35 PM, Juraj Kubelka 
> wrote:
>
>> Hi!
>>
>> If you create the following Glamour browser:
>>
>> ```
>> tabulator := GLMTabulator new.
>>
>> tabulator column: #one; column: #two; column: #three.
>>
>> tabulator transmit to: #one; andShow: [ :composite |
>> composite fastList display: [ :x | Array with: x ] ].
>> tabulator transmit to: #two; andShow: [ :composite |
>> composite fastList display: [ :x | Array with: 2 * x ] ].
>>
>> tabulator transmit from: #one; to: #three; andShow: [ :a |
>> a fastList display: [ :x | Array with: x ] ].
>> tabulator transmit from: #two; to: #three; andShow: [ :a |
>> a fastList display: [ :x | Array with: x ] ].
>>
>> tabulator openOn: 4.
>> ```
>>
>> You will get the following browser:
>>
>> 
>>
>> if you then select 4, the third list appears. If you then select 8, the
>> value is changed:
>>
>> 
>>
>> But since then, the third list does not change. It stays with 8 value
>> forever.
>>
>> Do I miss something? Should I define it differently?
>> Or if it is a bug: Can you give me insights how to fix it?
>>
>> Tested in the latest Pharo 6.
>>
>> Thanks!
>> Juraj
>>
>>
>
>

Re: [Pharo-dev] Glamour Fast List selection bug or incorrect usage?

[Andrei Chis]

Hi,

That's actually the default behavior, but I see there is also a bug.
Normally if you want to allow deselection in a presentation you should use
allowDeselection. Just I see there is a bug in the fast table renderer
because if I add #allowDeselection to the first presentation when clicking
again on the selected element the selection port is not cleared. If you use
#list instead of #fastList it works.

I think you can get the desired behaviur using this code:

-
tabulator := GLMTabulator new.

tabulator column: #one; column: #two; column: #three.

tabulator transmit to: #one; andShow: [ :composite |
composite list
allowDeselection;
display: [ :x | Array with: x ] ].
tabulator transmit to: #two; andShow: [ :composite |
composite list
allowDeselection;
display: [ :x | Array with: 2 * x ] ].

tabulator transmit
from: #one; to: #three;
from: #two; to: #three;
transformed: [ :x :y | y ifNil: [ x ] ifNotNil: [ y ] ];
andShow: [ :a |
a fastList display: [ :x | Array with: x ] ].

tabulator openOn: 4.
-


Cheers,
Andrei

On Mon, Apr 3, 2017 at 9:35 PM, Juraj Kubelka 
wrote:

> Hi!
>
> If you create the following Glamour browser:
>
> ```
> tabulator := GLMTabulator new.
>
> tabulator column: #one; column: #two; column: #three.
>
> tabulator transmit to: #one; andShow: [ :composite |
> composite fastList display: [ :x | Array with: x ] ].
> tabulator transmit to: #two; andShow: [ :composite |
> composite fastList display: [ :x | Array with: 2 * x ] ].
>
> tabulator transmit from: #one; to: #three; andShow: [ :a |
> a fastList display: [ :x | Array with: x ] ].
> tabulator transmit from: #two; to: #three; andShow: [ :a |
> a fastList display: [ :x | Array with: x ] ].
>
> tabulator openOn: 4.
> ```
>
> You will get the following browser:
>
>
> if you then select 4, the third list appears. If you then select 8, the
> value is changed:
>
>
> But since then, the third list does not change. It stays with 8 value
> forever.
>
> Do I miss something? Should I define it differently?
> Or if it is a bug: Can you give me insights how to fix it?
>
> Tested in the latest Pharo 6.
>
> Thanks!
> Juraj
>
>

Re: [Pharo-dev] debugger inspector pane different than inspect pane?

[Andrei Chis]

Hi Stef,

Thanks for sharing the image.
Found and fixed the bug: https://pharo.fogbugz.com/f/cases/19897

Cheers,
Andrei

On Wed, Mar 29, 2017 at 7:53 PM, Andrei Chis 
wrote:

>
>
> On Wed, Mar 29, 2017 at 6:10 PM, Stephane Ducasse  > wrote:
>
>> Yes doru this is when I get a node resulting from Smacc
>> Andrei I can share my image
>>
>
> Please do.
>
> Cheers,
> Andrei
>
>
>>
>> Stef
>>
>> On Wed, Mar 29, 2017 at 1:53 PM, Tudor Girba 
>> wrote:
>>
>>> Hi Stef,
>>>
>>> Does the issue relate to the SmaCC tree presentation of an AST node?
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> > On Mar 29, 2017, at 10:59 AM, Andrei Chis 
>>> wrote:
>>> >
>>> >  Not aware of this bug. I tried to debug a few other objects that have
>>> custom tree presentations and they seem to work. I'll need a way to
>>> reproduce this. Can you paste the code of the custom presentation that is
>>> problematic.
>>> >
>>> > Cheers,
>>> > Andrei
>>> >
>>> > On Wed, Mar 29, 2017 at 9:11 AM, Stephane Ducasse <
>>> stepharo.s...@gmail.com> wrote:
>>> > Hi andrei
>>> >
>>> > I'm debugger a node of a tree and in the debugger
>>> > the tree pane is empty. Now when I click on the node and inspect
>>> > it I get a tree representation.
>>> >
>>> > I do not know if you are aware of this behavior.
>>> >
>>> > Stef
>>> >
>>>
>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>>
>>> "Every now and then stop and ask yourself if the war you're fighting is
>>> the right one."
>>>
>>>
>>>
>>>
>>>
>>>
>>
>

[Pharo-dev] ./pharo --help returns exit code 1 on ubuntu

[Andrei Chis]

Hi,

In an ubuntu installation with the latest vm and Pharo 6 image when
executing `./pharo --help` I get an error code of 1.

wget -O- get.pharo.org/vmLatest60 | bash
wget -O- get.pharo.org/60 | bash
./pharo --help
echo $?   --> returns 1

On mac the error code is 0. Also when executing './pharo' or './pharo
Pharo.image --help' or './pharo --version' the error code is 0 on both mac
and linux.
So it seems there is some issues with --help. Actually, it gives a usage
warning, but still I'd expect to not return an error code.

Usage: Pharo.app/Contents/MacOS/Pharo [...] [
[...]]
  Pharo.app/Contents/MacOS/Pharo [...] -- [...]

Cheers,
Andrei

[Pharo-dev] Fwd: [Vm-dev] Saving a vm from command lines opens it with a small size

[Andrei Chis]

-- Forwarded message --
From: Andrei Chis 
Date: Wed, Mar 29, 2017 at 9:10 PM
Subject: Re: [Vm-dev] [Pharo-dev] Saving a vm from command lines opens it
with a small size
To: Squeak Virtual Machine Development Discussion <
vm-...@lists.squeakfoundation.org>
Cc: Pharo Development List 


Hi Eliot,

I tried the script but I get an error. Below is what I did and the error:

Andreis-MacBook-Pro-3:pharobug andrei$ ./pharo Pharo.image eval "Smalltalk
snapshot: true andQuit: true"
Andreis-MacBook-Pro-3:pharobug andrei$ ./resizesqueakwindow Pharo.image 840
640
0+1 records in
4+0 records out
1 truncated record
4 bytes transferred in 0.000708 secs (5651 bytes/sec)
Andreis-MacBook-Pro-3:pharobug andrei$ ./pharo-ui Pharo.image
2017-03-29 21:07:38.977 Pharo[53599:3054457] Error (1000) creating
CGSWindow on line 281
2017-03-29 21:07:38.979 Pharo[53599:3054457] (
0   CoreFoundation  0x96699c63 __raiseError +
195
1   libobjc.A.dylib 0x9018da2a
objc_exception_throw + 276
2   CoreFoundation  0x96699b7d +[NSException
raise:format:] + 141
3   AppKit  0x9ad410a5
_NSCreateWindowWithOpaqueShape2
+ 1728
4   AppKit  0x9ad3f06d -[NSWindow
_commonAwake] + 2227
5   AppKit  0x9adcef30 -[NSWindow
_makeKeyRegardlessOfVisibility]
+ 104
6   AppKit  0x9adcee86 -[NSWindow
makeKeyAndOrderFront:] + 35
7   Pharo   0x000b07b0
-[sqSqueakOSXOpenGLView drawThelayers] + 212
8   Pharo   0x000b718b
-[sqSqueakScreenAndWindow ioForceDisplayUpdate] + 196
9   Pharo   0x000b6e60
ioForceDisplayUpdate + 61
10  Pharo   0x0007a66d
primitiveShowDisplayRect + 212
11  Pharo   0x0003c1cd interpret + 25816
12  Pharo   0x000452e2
enterSmalltalkExecutiveImplementation + 135
13  Pharo   0x00035f7b interpret + 646
14  Pharo   0x000b68d0
-[sqSqueakMainApplication runSqueak] + 476
15  Foundation  0x988ea0ae
__NSFirePerformWithOrder + 416
16  CoreFoundation  0x965a481e
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 30
17  CoreFoundation  0x965a4760
__CFRunLoopDoObservers + 400
18  CoreFoundation  0x965960c2 __CFRunLoopRun +
946
19  CoreFoundation  0x96595aa6
CFRunLoopRunSpecific + 390
20  CoreFoundation  0x9659590b
CFRunLoopRunInMode + 123
21  HIToolbox   0x993a38f8
RunCurrentEventLoopInMode + 262
22  HIToolbox   0x993a3503
ReceiveNextEventCommon + 192
23  HIToolbox   0x993a342c _
BlockUntilNextEventMatchingListInModeWithFilter + 99
24  AppKit  0x9ad2cb41 _DPSNextEvent +
742
25  AppKit  0x9ad2c1e5 -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] + 350
26  AppKit  0x9ad20b9c -[NSApplication
run] + 907
27  AppKit  0x9ac95fa0
NSApplicationMain + 2082
28  libdyld.dylib   0x9a6a66d9 start + 1
29  ??? 0x0002 0x0 + 2
)
^C

On Wed, Mar 29, 2017 at 8:20 PM, Eliot Miranda 
wrote:

>
> Hi Andrei,
>
> On Wed, Mar 29, 2017 at 10:40 AM, Andrei Chis 
> wrote:
>
>> Hi,
>>
>> I have the following script that I run on mac:
>>
>> wget -O- get.pharo.org/vmLatest60 | bash
>> wget -O- get.pharo.org/60 | bash
>> ./pharo Pharo.image eval "Smalltalk snapshot: true andQuit: true"
>> ./pharo-ui Pharo.image
>>
>> Initially I thought that it doesn't work but then I saw that it opens a
>> very very small window with just a tiny scrollbar. Screenshot here:
>> https://dl.dropboxusercontent.com/u/74244847/Data/Screen%20S
>> hot%202017-03-29%20at%207.38.48%20PM.png.
>>
>
> Find attached a script for unix/mac os that sets the size of the screen in
> the image file.
>
> Arguably the VM should use a window extent of 0@0 as a "start me
> headless" flag.  What do people think?  It would complicate things.  The
> image would have to be located before any VM command line argument flags
> are processed, and probably opened twice.  Seems like a lot of effort for
> little gain.
>
>
> Cheers,
>> Andrei
>>
>
> _,,,^..^,,,_
> best, Eliot
>
>

Re: [Pharo-dev] debugger inspector pane different than inspect pane?

[Andrei Chis]

On Wed, Mar 29, 2017 at 6:10 PM, Stephane Ducasse 
wrote:

> Yes doru this is when I get a node resulting from Smacc
> Andrei I can share my image
>

Please do.

Cheers,
Andrei


>
> Stef
>
> On Wed, Mar 29, 2017 at 1:53 PM, Tudor Girba  wrote:
>
>> Hi Stef,
>>
>> Does the issue relate to the SmaCC tree presentation of an AST node?
>>
>> Cheers,
>> Doru
>>
>>
>> > On Mar 29, 2017, at 10:59 AM, Andrei Chis 
>> wrote:
>> >
>> >  Not aware of this bug. I tried to debug a few other objects that have
>> custom tree presentations and they seem to work. I'll need a way to
>> reproduce this. Can you paste the code of the custom presentation that is
>> problematic.
>> >
>> > Cheers,
>> > Andrei
>> >
>> > On Wed, Mar 29, 2017 at 9:11 AM, Stephane Ducasse <
>> stepharo.s...@gmail.com> wrote:
>> > Hi andrei
>> >
>> > I'm debugger a node of a tree and in the debugger
>> > the tree pane is empty. Now when I click on the node and inspect
>> > it I get a tree representation.
>> >
>> > I do not know if you are aware of this behavior.
>> >
>> > Stef
>> >
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Every now and then stop and ask yourself if the war you're fighting is
>> the right one."
>>
>>
>>
>>
>>
>>
>

[Pharo-dev] Saving a vm from command lines opens it with a small size

[Andrei Chis]

Hi,

I have the following script that I run on mac:

wget -O- get.pharo.org/vmLatest60 | bash
wget -O- get.pharo.org/60 | bash
./pharo Pharo.image eval "Smalltalk snapshot: true andQuit: true"
./pharo-ui Pharo.image

Initially I thought that it doesn't work but then I saw that it opens a
very very small window with just a tiny scrollbar. Screenshot here:
https://dl.dropboxusercontent.com/u/74244847/Data/Screen%20Shot%202017-03-29%20at%207.38.48%20PM.png
.

Cheers,
Andrei

Re: [Pharo-dev] Rubric on 64 bit VM

[Andrei Chis]

Added a bug report:
https://pharo.fogbugz.com/f/cases/19884/Rubric-should-not-use-SmallInteger-maxVal

Indeed changing this in Rubric is the best option. #maxVal is used in more
places in Rubric,

On Wed, Mar 29, 2017 at 5:10 PM, Esteban Lorenzano 
wrote:

>
> On 29 Mar 2017, at 17:01, Andrei Chis  wrote:
>
>
>
> On Wed, Mar 29, 2017 at 2:12 PM, Esteban Lorenzano 
> wrote:
>
>> why does rubric checks for maxVal at first instance?
>>
>
> This is the problematic code for Spotter:
>
> RubAbstractTextArea>>#drawingBounds
> ^ (self scrollPane isNil or: [ self wrapped ])
> ifTrue: [self innerBounds]
> ifFalse: [ self innerBounds topLeft extent: SmallInteger maxVal @
> SmallInteger maxVal ]
>
>
> looks like he’s trying to get an incredible huge drawing area.
> I would just extract that to a RubAbstractTextArea class>>#maxExtent class
> method, and with constant numbers, as Eliot suggested.
>
> Esteban
>
>
>
>>
>> > On 29 Mar 2017, at 14:07, Andrei Chis 
>> wrote:
>> >
>> > Hi,
>> >
>> > Right now rubric relies on 'SmallInteger maxVal' to set the drawing
>> bounds when a size is not set for the editor. This has some side-effects,
>> like the text in Spotter not appearing on 64 bit given that some drawing
>> methods from the graphical backend seem to expect 32 bit ranges. We can fix
>> this by introducing #maxVal32 or maybe there could be some range checks in
>> the canvas. Comments?
>> >
>> > Cheers,
>> > Andrei
>>
>>
>>
>
>

Re: [Pharo-dev] [Gsoc] [FastTable improvements] [Features request]

[Andrei Chis]

Hi Elhamer,

A few other things that could possible be done:

- Horizontal scrollbars
- Better integration between Glamour and FastTable (there are quite a few
issues on the bug tracker about this)
- Better support for lazy DataSources especially in the tree widget.
- Support to automatically resize columns to fix the content

Cheers,
Andrei

On Wed, Mar 29, 2017 at 5:39 PM, Elhamer Oussama AbdelKHalek <
abdelkhalek...@gmail.com> wrote:

> Dear Pharo community,
>
>
> I am planning in working on FastTables improvements during Gsoc as
> suggested by Mr. Stephan Eggermont.
>
> I’ve managed to collect some important features and ideas suggested by
> some of you (thanks to @stephan, @cyrilferlicot, @thierrygoubier,
> @estebanlm, @jfabry) in the following repo (as issues):
>
>
> https://github.com/SamTheDev/Pharo-FastTable-improvements/issues
>
>
> You might come across some FT limitations or issues while working with
> Pharo as a user or as a contributor, I would appreciate hearing your
> thoughts on this, please feel free to share your reviews/ideas/requests …
> on the repo.
>
>
> Thank you for your contribution,
>
> Elhamer.
>

Re: [Pharo-dev] Rubric on 64 bit VM

[Andrei Chis]

On Wed, Mar 29, 2017 at 2:12 PM, Esteban Lorenzano 
wrote:

> why does rubric checks for maxVal at first instance?
>

This is the problematic code for Spotter:

RubAbstractTextArea>>#drawingBounds
^ (self scrollPane isNil or: [ self wrapped ])
ifTrue: [self innerBounds]
ifFalse: [ self innerBounds topLeft extent: SmallInteger maxVal @
SmallInteger maxVal ]


>
> > On 29 Mar 2017, at 14:07, Andrei Chis 
> wrote:
> >
> > Hi,
> >
> > Right now rubric relies on 'SmallInteger maxVal' to set the drawing
> bounds when a size is not set for the editor. This has some side-effects,
> like the text in Spotter not appearing on 64 bit given that some drawing
> methods from the graphical backend seem to expect 32 bit ranges. We can fix
> this by introducing #maxVal32 or maybe there could be some range checks in
> the canvas. Comments?
> >
> > Cheers,
> > Andrei
>
>
>

[Pharo-dev] Rubric on 64 bit VM

[Andrei Chis]

Hi,

Right now rubric relies on 'SmallInteger maxVal' to set the drawing bounds
when a size is not set for the editor. This has some side-effects, like the
text in Spotter not appearing on 64 bit given that some drawing methods
from the graphical backend seem to expect 32 bit ranges. We can fix this by
introducing #maxVal32 or maybe there could be some range checks in the
canvas. Comments?

Cheers,
Andrei

Re: [Pharo-dev] debugger inspector pane different than inspect pane?

[Andrei Chis]

 Not aware of this bug. I tried to debug a few other objects that have
custom tree presentations and they seem to work. I'll need a way to
reproduce this. Can you paste the code of the custom presentation that is
problematic.

Cheers,
Andrei

On Wed, Mar 29, 2017 at 9:11 AM, Stephane Ducasse 
wrote:

> Hi andrei
>
> I'm debugger a node of a tree and in the debugger
> the tree pane is empty. Now when I click on the node and inspect
> it I get a tree representation.
>
> I do not know if you are aware of this behavior.
>
> Stef
>

Re: [Pharo-dev] inspector performance improvement

[Andrei Chis]

Hi Henry,

On Thu, Mar 23, 2017 at 10:49 PM, Henrik Johansen <
henrik.s.johan...@veloxit.no> wrote:

> I guess I'm late to the party, downloaded the latest Moose image today,
> compared to Pharo5/6, it's night and day!
> Browsing large collections is quicker than I can ever remember, if emails
> had emoticons, there'd be a :partyhat: right here, great job!
>
> You're probably aware already, but there's an issue with the indexes for
> the items tab when collections contain the same object multiple times, say
>

Yes we know this issue. It's actually fixed in Pharo, but it seems that I
forgot to port the slice also to the repo of the inspector. Will do that
tomorrow.


>
> o := Object new.
> oc := OrderedCollection new: 2.
> 1 to: 2 do: [:i | oc add: o].
> oc inspect
>
> or
>
> ba := (ByteArray new: 2) inspect.
> 0 to: 1 do: [:i | ba at: i + 1 put: i \\ 255 + 1].
> ba inspect.
>
> Finding a solution that avoids doing indexOf: lookups, but pass along the
> index instead when needed would be nice ;)
>

That's actually how the view for SequenceableCollection objects works; this
problem is related to caching.


>
> The second example also highlight that there seems to be a (legacy?)
> restriction of 10k entries in the raw view;  the list jumps from index 5000
> -> 15001, this shouldn't be necessary anymore, right?.
>

In Pharo 5 the limit was 42 :). We increased it in Pharo 6 to 10k as we
thought it is good enough. The 'Items' presentation however always displays
the entire number of elements.


>
> *EDIT* After some digging, and testing with a large collection where the
> limit is raised, I can see why it's there...
> Find attached some improvements to FT that should (at least act as a PoC
> that it's possible to) improve performance enough with large trees to
> possibly remove indexableDisplayLimit entirely.
> Tested by inspecting a 2M ByteArray, while opening the tab took ~5 secs,
> navigation/scrolling afterwards was smooth sailing
>

It's definitely possible to eliminate the indexableDisplayLimit. One
solution is to use a lazy model that only computes visible items for all
collection presentations.  I see that your solution plays with
#visibleChildren. That's definitely a way to improve the tree widget. We'll
look at this more for Pharo 7.

If you made it so far you can also give the automatic refresh of the Raw
view a try :) (GTInspector enableStepRefresh).

Cheers,
Andrei


> Cheers,
> Henry
>
>
> > On 13 Feb 2017, at 11:56 , Andrei Chis 
> wrote:
> >
> > On Sun, Feb 12, 2017 at 5:07 PM, p...@highoctane.be 
> wrote:
> >> Any chance for this to run on a 5.0?
> >
> > There are two main changes: moved inspector to fast table and some
> > fixes in the glamour renderer.
> > Moving the changes for the glamour renderer should be straightforward.
> > I can point you to the list of relevant commits if you want to make a
> > slice (We'll just need afterwards to also update
> > ConfigurationOfGlamourCore to still work for Pharo 5)
> >
> > The FastTable changes could require more work but that should also be
> > doable. However, now we still have some issues to fix there so that's
> > not done for the moment.
> >
> >
> > Cheers,
> > Andrei
> >
> >
> >>
> >> Phil
> >>
> >> On Sun, Feb 12, 2017 at 3:13 PM, stepharong  wrote:
> >>>
> >>> Great job
> >>> It feels lot snappier :)
> >>> Now it is a real pleasure to navigate objects.
> >>> This is nice to see that you are paying attention because the engine is
> >>> getting faster and this is important
> >>> that the tools do not eat all the power by accident.
> >>> Tx a lot
> >>>
> >>>
> >>> On Sat, 11 Feb 2017 21:31:56 +0100, Tudor Girba 
> >>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> Andrei and Alex did a great job at improving the performance and
> >>>> scalability of the inspector.
> >>>>
> >>>> There are a couple of main improvements:
> >>>> - Added FastTable support for the Raw presentation for all objects.
> This
> >>>> implied completing the support for the tree presentation binding to
> fast
> >>>> table.
> >>>> - Moved the Items presentation for collections to FastTable.
> >>>> - Improved the rendering of Glamour to no longer rely on the default
> >>>> Morph>>#adoptPaneColor. It turns out that using adoptPaneColor
> triggers a

Re: [Pharo-dev] Did we lose edit-in-place in GT Inspector in Pharo 6?

[Andrei Chis]

On Sun, Mar 12, 2017 at 5:07 PM, Sean P. DeNigris 
wrote:

> Tudor Girba-2 wrote
> > this feature is temporarily not available due to the move to FastTable
>
> :(
>
>
> Tudor Girba-2 wrote
> > but we are working on adding it back.
>
> :)
>
> I use this all the time to e.g. nil out an inst var to
> re-lazily-initialize.
> I noticed it was missing (after trying to press the mouse button harder for
> a few minutes... sigh) within minutes of testing out Pharo 6. There was no
> setter, so I ended up doing an ugly, and time-consumiung,
> `#instVarNamed:put:`. Will it be re-added in 6 before the release? I'd say
> a
> lost key feature is a bug, no?
>

This feature was lost because of the inspector move to FastTable and the
adding of automatic refresh.
But we hope to add it back for Pharo 6. Just it will be enabled on
Shift+Click and not double click.

Cheers,
Andrei


>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/Did-we-
> lose-edit-in-place-in-GT-Inspector-in-Pharo-6-tp4938264p4938297.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] Seamless integration with GTInspector

[Andrei Chis]

Hi Denis,

Thanks for the clarification. Then it's good as Seamless will not be
impacted by this.
Let me if/when you start looking making GTInspector in Seamless use
FastTable.

I think I'll still add a tiny cache so that the string representation is
not recomputed every time.

Cheers,
Andrei

On Sat, Mar 4, 2017 at 6:07 PM, Denis Kudriashov 
wrote:

> Hi Andrei
>
> I already adopted Seamless to changes in GTInspector. So everything works
> well.
> For now I do not follow your fast table solution. Remote and local
> presentations are implemented with old approach. I just copied few methods
> from old GT version to make it work.
> So it works same way as before and compatible with Pharo 5.
> In future I will reuse new fast table approach.
>
> Thank's for thinking about it :)
>
>
> 2017-03-04 17:48 GMT+01:00 Andrei Chis :
>
>> Hi Denis,
>>
>> Can you try Seamless with GTInspector in the latest version of Pharo or
>> Moose and let me know if you see any slowness. Not sure how Seamless uses
>> GTInspector to inspect proxy objects but now as the inspector uses
>> FastTable by default there is no cache whatsoever.  What this means is that
>> the string representation shown in a FastTable presentation is recomputed
>> every time fast table needs to display an element in a row or column. For
>> example, this is the case when you scroll or when you resize the window
>> (all visible elements are recomputed).
>>
>> In a local context the inspector is still very fast as it is. Just we
>> should double check that it's also the case for Seamless. If not there are
>> some caches that could be put into place relatively easy, either at the
>> level of the inspector or fast table. Just before doing this I'd like to
>> know if this is actually a problem.
>>
>> Cheers,
>> Andrei
>>
>
>

[Pharo-dev] Seamless integration with GTInspector

[Andrei Chis]

Hi Denis,

Can you try Seamless with GTInspector in the latest version of Pharo or
Moose and let me know if you see any slowness. Not sure how Seamless uses
GTInspector to inspect proxy objects but now as the inspector uses
FastTable by default there is no cache whatsoever.  What this means is that
the string representation shown in a FastTable presentation is recomputed
every time fast table needs to display an element in a row or column. For
example, this is the case when you scroll or when you resize the window
(all visible elements are recomputed).

In a local context the inspector is still very fast as it is. Just we
should double check that it's also the case for Seamless. If not there are
some caches that could be put into place relatively easy, either at the
level of the inspector or fast table. Just before doing this I'd like to
know if this is actually a problem.

Cheers,
Andrei

Re: [Pharo-dev] Importing icons

[Andrei Chis]

Hi,

On Fri, Mar 3, 2017 at 2:17 PM, Alexandre Bergel 
wrote:

> Hi!
>
> During the sprint, we wanted to fix issue https://pharo.fogbugz.com/f/
> cases/19668/importIcons-fromFolder-inClass-category-
> sends-unimplemented-methods
>
> The issues is that some implementors of the method:
>  importIcons: icons fromFolder: aString inClass: aClass category: aCategory
>
> uses some methods that are not defined: Behavior>>methodStart: and
> Behavior>>methodEnd
>
> Are the methods #importIcons:fromFolder:inClass:category: really used?
> Is there a different standard way to import icons in Pharo?  (I know the
> one of Peter, but is this meant to replace those importIcons methods?)
>

I remember we were using that long time ago to import icons for glamour.
But we did not do it in a while, so I'm not sure if now there is a better
way to do it.

Cheers,
Andrei


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

Re: [Pharo-dev] Raw pane on byteStrings

[Andrei Chis]

Hi Thierry,

On Mon, Feb 27, 2017 at 12:15 AM, Thierry Goubier  wrote:

> Hi Andrei,
>
> Le 26/02/2017 à 23:48, Andrei Chis a écrit :
>
>> Hi Thierry,
>>
>> Thanks for the measurements. Things are more clear now :)
>>
>> On Fri, Feb 24, 2017 at 11:52 PM, Thierry Goubier
>> mailto:thierry.goub...@gmail.com>> wrote:
>>
>> Hi Andrei,
>>
>> Le 24/02/2017 à 17:02, Andrei Chis a écrit :
>>
>> Hi Thierry,
>>
>> Strangely enough I'm getting different times on my machine
>> Just to start from the same baseline in a fresh Pharo 60411
>> image with
>> no changes to any of the inspectors over a series of runs I get:
>>
>> array := (1 to: 100) asArray.
>> [array inspect] timeToRun.   "0:00:00:00.145"
>> [GTInspector inspect: array] timeToRun. "0:00:00:00.031"
>>
>>
>> Yes, this is expected. I'm not comparing to the standard
>> EyeInspector, but with my experiments with a FastTable-derived
>> widget and the EyeInspector model. GTInspector is a lot faster than
>> the normal EyeInspector.
>>
>> As default (the only one displaying 100k elements is the AltInspector)
>>
>> | array |
>> array := (1 to: 100) asArray.
>> [AltInspector inspect: array ] timeToRun. "0:00:00:00.096"
>> [EyeInspector inspect: array] timeToRun.  "0:00:00:00.364"
>> [GTInspector inspect: array] timeToRun. "0:00:00:00.065"
>>
>>
>> Indeed this is what I expected.
>>
>>
>>
>>
>> If I change indexableDisplayLimit to 5 and remove the Items
>> view
>> then I get:
>>
>> [GTInspector inspect: array] timeToRun.  "0:00:00:00.124"
>>
>>
>> [GTInspector inspect: array] timeToRun. "0:00:00:00.256"
>>
>> So this time is to be compared to the "0:00:00:00.096".
>>
>>
>> Can you just also try to remove the Items view and set
>> indexableDisplayLimit to 50.
>>
>
> In the previous times, the Item view was removed. If indexableDisplayLimit
> is set at 50, then the time become:
>
> [GTInspector inspect: array] timeToRun. "0:00:00:00.156"
>
> Which is interesting in itself: multiplying the limit by 1000 (from 50 to
> 50k) increase the time by a factor of ~1.6.


You're right, the performance of the datasource it's actually quite good.


>
>
> I think there is some small performance degradation in the current tree
>> data source used by Glamour but I'm not 100% sure.
>>
>
> It looks pretty efficient to me. There isn't much increase in times.
>
> I looked at the scaling in my experiment: the lower bound in opening the
> inspector is reached for a 100k elements array. Anything smaller
> has the same time (~80ms). The 1000k array increase that by ~15/20ms.


I still think ~150ms to just open the Raw view is a bit too much, but for
the moment it should be fine.


>
>
> I'm really interested in seeing what makes GTInspector slower on
>> your
>> machine. Did you do other optimizations to SpecInspector?
>>
>>
>> The optimisations are:
>> - remove Spec (revert to a pure morphic application),
>> - use a FastTable-derived widget for a tree view (with a 100k
>> element limit),
>> - have the GT views as subitems in the widget.
>>
>>
>> Nice. Would be also interesting to see if in the future we can merge
>> more the models used by GTInspector and EyeInspector.
>>
>
> Could be. I just used them out of convenience, and I needed an inspector
> with the ability to view large trees.
>
> For now, for the Raw view I set the limit to 5000 elements. This seems
>> fast/large enough and it allows to add the automatic refresh back to the
>> Raw view.
>>
>
> I wonder if it wouldn't be possible to tune the automatic refresh.
> Increase the time interval if it takes to long (for example when refreshing
> a set with 1M elements). But 5000 elements is already a good limit.
>

Tuning the refresh rate could definitely be a possibility. For now I set it
to 1.5 seconds.

Cheers,
Andrei


>
> Regards,
>
> Thierry
>
> Cheers,
>> Andrei
>>
>>
>>
>>
>> I'm using a MacBook Pro Retina - 2.8 GHz Intel Core i7
>>
>>
>> Back on a Acer Chromebook C720p 1.4GHz Intel Celeron, with vmLatest.
>>
>> 5.0-201702231204  T

Re: [Pharo-dev] Raw pane on byteStrings

[Andrei Chis]

Hi Thierry,

On Fri, Feb 24, 2017 at 3:49 PM, Thierry Goubier 
wrote:

>
>
> 2017-02-24 15:43 GMT+01:00 Andrei Chis :
>
>>
>>
>> On Fri, Feb 24, 2017 at 3:28 PM, Denis Kudriashov 
>> wrote:
>>
>>>
>>> 2017-02-24 14:29 GMT+01:00 Andrei Chis :
>>>
>>>> There should be no hidden costs in GTInspectorIndexedNodes.
>>>> I made some experiments in the latest Pharo version and opening the Raw
>>>> view on an array with one million numbers takes around 120ms when 100k
>>>> elements are computed.
>>>> I'll be curious how much it takes on your machine. To test update
>>>> indexableDisplayLimit to 5 in Object>>#gtInspectorVariableNodesIn:
>>>> and remove the annotation from Collection>>#gtInspectorItemsIn: (so
>>>> that the Items presentation is not loaded)
>>>>
>>>> arrayLarge := (1 to: 100) asArray.
>>>>
>>>
>>> I really wondering why anybody want instantiate wrapper objects for all
>>> array items? Fast table approach is to not do that. Only visible part of
>>> items should be recreated
>>>
>>
>> This is how the inspector works for the Items view for Array objects. It
>> also does not use any wrappers and only computes visible part.
>>
>>
> As I said, it brings in a lazy data source adapted to arrays in a case
> where it may well be not needed. My experiments show that there is no need
> for this optimisation, at least for arrays ~ 100k.
>

For this particular case there is no special lazy data source. It's just
the default table data source from Glamour. In works in this particular
case because for a SequenceableCollection we currently have no wrapping of
elements, so we can just extract them directly.

Will be worth looking for a lazy data source for a remote inspector but not
for Pharo 6.

Cheers,
Andrei


>
> Thierry
>
>
>
>
>

Re: [Pharo-dev] Raw pane on byteStrings

[Andrei Chis]

Hi Thierry,

Thanks for the measurements. Things are more clear now :)

On Fri, Feb 24, 2017 at 11:52 PM, Thierry Goubier  wrote:

> Hi Andrei,
>
> Le 24/02/2017 à 17:02, Andrei Chis a écrit :
>
>> Hi Thierry,
>>
>> Strangely enough I'm getting different times on my machine
>> Just to start from the same baseline in a fresh Pharo 60411 image with
>> no changes to any of the inspectors over a series of runs I get:
>>
>> array := (1 to: 100) asArray.
>> [array inspect] timeToRun.   "0:00:00:00.145"
>> [GTInspector inspect: array] timeToRun. "0:00:00:00.031"
>>
>
> Yes, this is expected. I'm not comparing to the standard EyeInspector, but
> with my experiments with a FastTable-derived widget and the EyeInspector
> model. GTInspector is a lot faster than the normal EyeInspector.
>
> As default (the only one displaying 100k elements is the AltInspector)
>
> | array |
> array := (1 to: 100) asArray.
> [AltInspector inspect: array ] timeToRun. "0:00:00:00.096"
> [EyeInspector inspect: array] timeToRun.  "0:00:00:00.364"
> [GTInspector inspect: array] timeToRun. "0:00:00:00.065"


Indeed this is what I expected.


>
>
> If I change indexableDisplayLimit to 5 and remove the Items view
>> then I get:
>>
>> [GTInspector inspect: array] timeToRun.  "0:00:00:00.124"
>>
>
> [GTInspector inspect: array] timeToRun. "0:00:00:00.256"
>
> So this time is to be compared to the "0:00:00:00.096".


Can you just also try to remove the Items view and set
indexableDisplayLimit to 50.
I think there is some small performance degradation in the current tree
data source used by Glamour but I'm not 100% sure.


>
> I'm really interested in seeing what makes GTInspector slower on your
>> machine. Did you do other optimizations to SpecInspector?
>>
>
> The optimisations are:
> - remove Spec (revert to a pure morphic application),
> - use a FastTable-derived widget for a tree view (with a 100k element
> limit),
> - have the GT views as subitems in the widget.


Nice. Would be also interesting to see if in the future we can merge more
the models used by GTInspector and EyeInspector.

For now, for the Raw view I set the limit to 5000 elements. This seems
fast/large enough and it allows to add the automatic refresh back to the
Raw view.

Cheers,
Andrei


>
>
> I'm using a MacBook Pro Retina - 2.8 GHz Intel Core i7
>>
>
> Back on a Acer Chromebook C720p 1.4GHz Intel Celeron, with vmLatest.
>
> 5.0-201702231204  Thu Feb 23 12:36:20 UTC 2017 gcc 4.6.3 [Production Spur
> ITHB VM]
> CoInterpreter * VMMaker.oscog-EstebanLorenzano.2136 uuid:
> 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 23 2017
> StackToRegisterMappingCogit * VMMaker.oscog-EstebanLorenzano.2136 uuid:
> 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 23 2017
> VM: 201702231204 https://github.com/pharo-project/pharo-vm.git $ Date:
> Thu Feb 23 13:04:59 2017 +0100 $
> Plugins: 201702231204 https://github.com/pharo-project/pharo-vm.git $
> Linux testing-docker-b6b0368d-4817-4638-86be-f022b8a58580
> 4.8.12-040812-generic #201612020431 SMP Fri Dec 2 09:33:31 UTC 2016 i686
> i686 i386 GNU/Linux
>
>
> Pharo VM version:
>> CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid:
>> 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016
>> StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880
>> uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016
>> g...@github.com:pharo-project/pharo-vm.git Commit:
>> 06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 08:40:43 +0200
>> By: GitHub mailto:nore...@github.com>>
>>
>> Cheers,
>> Andrei
>>
>>
>> On Fri, Feb 24, 2017 at 3:24 PM, Thierry Goubier
>> mailto:thierry.goub...@gmail.com>> wrote:
>>
>>
>>
>> 2017-02-24 14:29 GMT+01:00 Andrei Chis > <mailto:chisvasileand...@gmail.com>>:
>>
>>
>>
>> On Fri, Feb 24, 2017 at 12:16 PM, Thierry Goubier
>> mailto:thierry.goub...@gmail.com>>
>> wrote:
>>
>> Hi Andrei,
>>
>> 2017-02-24 11:31 GMT+01:00 Andrei Chis
>> > <mailto:chisvasileand...@gmail.com>>:
>>
>>
>> Hi Thierry,
>>
>> Indeed that's the simplest option now that we are using
>> fast table.
>>
>> Just now in the case of the Raw view an
>> OrderedCollection is used to store all displayed elements.
>&

[Pharo-dev] refresh in EyeInspector disabled?

[Andrei Chis]

Hi,

In latest Pharo 6 version (60411) I see that EyeInspector does not do
automatic refresh.
Doing 'Morph new basicInspect' selecting the 'color' attribute and then
executing in the code pane 'self color: Color red' has no effect.

Was this disabled explicitly or is it an error?

Cheers,
Andrei

Re: [Pharo-dev] [Moose-dev] GTInspector duplicates overriden extensions

[Andrei Chis]

Hi,

Usually when we want to specialize a view in a subclass we override the
method and do not add the gtInspectorPresentationOrder: annotation. But
also removing duplicationd would make sense.

Cheers,
Andrei


On Feb 25, 2017 4:36 PM, "Peter Uhnak"  wrote:

Hi,

when I override a method with a GTInspector (because I need to change it),
then inspector contains the extension twice.

It seems Inspector scans the whole hierarchy of the inspected object for
methods, but doesn't deduplicate them.

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

Re: [Pharo-dev] Raw pane on byteStrings

[Andrei Chis]

Hi Thierry,

Strangely enough I'm getting different times on my machine
Just to start from the same baseline in a fresh Pharo 60411 image with no
changes to any of the inspectors over a series of runs I get:

array := (1 to: 100) asArray.
[array inspect] timeToRun.   "0:00:00:00.145"
[GTInspector inspect: array] timeToRun. "0:00:00:00.031"

If I change indexableDisplayLimit to 5 and remove the Items view then I
get:

[GTInspector inspect: array] timeToRun.  "0:00:00:00.124"

I'm really interested in seeing what makes GTInspector slower on your
machine. Did you do other optimizations to SpecInspector?
I'm using a MacBook Pro Retina - 2.8 GHz Intel Core i7

Pharo VM version:
CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid:
16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016
StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880
uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016
g...@github.com:pharo-project/pharo-vm.git Commit:
06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 08:40:43 +0200
By: GitHub 

Cheers,
Andrei


On Fri, Feb 24, 2017 at 3:24 PM, Thierry Goubier 
wrote:

>
>
> 2017-02-24 14:29 GMT+01:00 Andrei Chis :
>
>>
>>
>> On Fri, Feb 24, 2017 at 12:16 PM, Thierry Goubier <
>> thierry.goub...@gmail.com> wrote:
>>
>>> Hi Andrei,
>>>
>>> 2017-02-24 11:31 GMT+01:00 Andrei Chis :
>>>
>>>> Hi Thierry,
>>>>
>>>> Indeed that's the simplest option now that we are using fast table.
>>>>
>>>> Just now in the case of the Raw view an OrderedCollection is used to
>>>> store all displayed elements.
>>>> If you display large collections every time you open the Raw view it
>>>> will instantiate a collection of size 100k and instantiate 100k
>>>> objects of type GTInspectorIndexedNode. With FastTable we can lazily load
>>>> elements so we should be able to remove this behaviour and the limit. Just
>>>> we need to make sure it will play nicely with automatic refresh. There is
>>>> also the issue that when expanding an element in the tree if it's a
>>>> collection you don't want to expand all elements.
>>>>
>>>
>>> I'm not sure you need to worry too much about that one; in practical
>>> experiments, creating that 100k collection for viewing (and the associated
>>> nodes instances) isn't too costly (unless creating the
>>> GTInspectorIndexedNodes has hidden costs: I've only experimented with the
>>> EyeInspector framework).
>>>
>>
>> There should be no hidden costs in GTInspectorIndexedNodes.
>> I made some experiments in the latest Pharo version and opening the Raw
>> view on an array with one million numbers takes around 120ms when 100k
>> elements are computed.
>> I'll be curious how much it takes on your machine. To test update
>> indexableDisplayLimit to 5 in Object>>#gtInspectorVariableNodesIn:
>> and remove the annotation from Collection>>#gtInspectorItemsIn: (so that
>> the Items presentation is not loaded)
>>
>> arrayLarge := (1 to: 100) asArray.
>> arrayLarge inspect.
>>
>
> This is the values I get on my work laptop (core i3-2350M 2.30 Ghz); both
> inspectors displays 100k elements.
>
> (1 to: 100) asArray in: [ :s |  [s inspect] timeToRun] 0:00:00:00.064
> (1 to: 100) asArray in: [:s | [GTInspector inspect: s] timeToRun]
> 0:00:00:00.381
>
> Pharo 6 60411
>
>
>>
>>
>>>
>>> Opening the tree with all elements works fine in my experiments. Tuning
>>> scrolling as done in Bloc is necessary, however.
>>>
>>>
>>>>
>>>> I'm looking now on a lazy data source for FastTable that plays nicely
>>>> with GTInspector. Let's see how it will go. Help is always welcomed :)
>>>>
>>>
>>> As I said: do not overoptimize that part... just remove that limitation
>>> on the raw view and measure.
>>>
>>
>> If I measure the Items view on the previous array it takes around 35ms.
>> What I'd like to have is the same opening time for the Items view on
>> large Sets and Dictionaries.
>>
>
> On my machine, the experiment is that displaying the set is fast, but the
> system becomes totally unresponsive... which may be an issue with the self
> refresh of the inspector. Yes, it was the culprit.
>
> (1 to: 100) asSet in: [ :s |  [s inspect] timeToRun] 0:00:00:00.034
> (1 to: 100) asSet in: [:s | [GTInspector inspect: s] timeToRun]
&

Re: [Pharo-dev] Raw pane on byteStrings

[Andrei Chis]

On Fri, Feb 24, 2017 at 3:28 PM, Denis Kudriashov 
wrote:

>
> 2017-02-24 14:29 GMT+01:00 Andrei Chis :
>
>> There should be no hidden costs in GTInspectorIndexedNodes.
>> I made some experiments in the latest Pharo version and opening the Raw
>> view on an array with one million numbers takes around 120ms when 100k
>> elements are computed.
>> I'll be curious how much it takes on your machine. To test update
>> indexableDisplayLimit to 5 in Object>>#gtInspectorVariableNodesIn:
>> and remove the annotation from Collection>>#gtInspectorItemsIn: (so that
>> the Items presentation is not loaded)
>>
>> arrayLarge := (1 to: 100) asArray.
>>
>
> I really wondering why anybody want instantiate wrapper objects for all
> array items? Fast table approach is to not do that. Only visible part of
> items should be recreated
>

This is how the inspector works for the Items view for Array objects. It
also does not use any wrappers and only computes visible part.

Re: [Pharo-dev] Raw pane on byteStrings

[Andrei Chis]

On Fri, Feb 24, 2017 at 12:16 PM, Thierry Goubier  wrote:

> Hi Andrei,
>
> 2017-02-24 11:31 GMT+01:00 Andrei Chis :
>
>> Hi Thierry,
>>
>> Indeed that's the simplest option now that we are using fast table.
>>
>> Just now in the case of the Raw view an OrderedCollection is used to
>> store all displayed elements.
>> If you display large collections every time you open the Raw view it will
>> instantiate a collection of size 100k and instantiate 100k objects of
>> type GTInspectorIndexedNode. With FastTable we can lazily load elements so
>> we should be able to remove this behaviour and the limit. Just we need to
>> make sure it will play nicely with automatic refresh. There is also the
>> issue that when expanding an element in the tree if it's a collection you
>> don't want to expand all elements.
>>
>
> I'm not sure you need to worry too much about that one; in practical
> experiments, creating that 100k collection for viewing (and the associated
> nodes instances) isn't too costly (unless creating the
> GTInspectorIndexedNodes has hidden costs: I've only experimented with the
> EyeInspector framework).
>

There should be no hidden costs in GTInspectorIndexedNodes.
I made some experiments in the latest Pharo version and opening the Raw
view on an array with one million numbers takes around 120ms when 100k
elements are computed.
I'll be curious how much it takes on your machine. To test update
indexableDisplayLimit to 5 in Object>>#gtInspectorVariableNodesIn: and
remove the annotation from Collection>>#gtInspectorItemsIn: (so that the
Items presentation is not loaded)

arrayLarge := (1 to: 100) asArray.
arrayLarge inspect.


>
> Opening the tree with all elements works fine in my experiments. Tuning
> scrolling as done in Bloc is necessary, however.
>
>
>>
>> I'm looking now on a lazy data source for FastTable that plays nicely
>> with GTInspector. Let's see how it will go. Help is always welcomed :)
>>
>
> As I said: do not overoptimize that part... just remove that limitation on
> the raw view and measure.
>

If I measure the Items view on the previous array it takes around 35ms.
What I'd like to have is the same opening time for the Items view on large
Sets and Dictionaries.


>
>
>>
>> I think I used the word paginator in the wrong way. If you have a very
>> large collection (millions of elements) I do not want to scroll through
>> elements but most likely jump to a certain element or view just a subset of
>> all elements. Not really add a paginator like in web pages.
>>
>
> Ok, millions of elements is a bit out of my scope... I'll look for
> filtering then.
>

Yes, definitely filtering is the way to go there :)

Cheers,
Andrei


>
> Regards,
>
> Thierry
>
>
>>
>> Cheers,
>> Andrei
>>
>> On Fri, Feb 24, 2017 at 10:37 AM, Thierry Goubier <
>> thierry.goub...@gmail.com> wrote:
>>
>>> Hi Andrei,
>>>
>>> if you're using fasttable for the Raw view, you should be able to reach
>>> one 100k elements without issues. I did some experiments and it handles the
>>> load very well.
>>>
>>> Avoid the paginator at any cost. This thing is really user-unfriendly.
>>>
>>> Regards,
>>>
>>> Thierry
>>>
>>> 2017-02-23 20:19 GMT+01:00 Andrei Chis :
>>>
>>>> Hi Stef,
>>>>
>>>> Currently that's the default behaviour of the Raw view: it displays for
>>>> collections only the first and the last 21 elements. The Items view however
>>>> always should display all the elements of a collection.
>>>>
>>>> The main problem with the Raw view in Pharo 5 is the speed. In Pharo 6
>>>> now the speed of the Raw view is greately improved so we could increase
>>>> those limits. Still for now there should still be some limit for the Raw
>>>> view. Ideally we should add a small widget, something like a paginator, for
>>>> navigating through large and very large collections.
>>>>
>>>> Cheers,
>>>> Andrei
>>>>
>>>> On Feb 23, 2017 19:35, "stepharong"  wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> I'm trying to debug citezen generation and I have to compare strings.
>>>>> Now I think that the raw views (in Pharo 50) is not good because we
>>>>> cannot see all the items in raw format.
>>>>> See the attachements. It jumps from 21 to 174 ...
>>>>> and what I want to see is of course in the middle.
>>>>>
>>>>> Is it me or there is something wrong there.
>>>>> Stef
>>>>
>>>>
>>>
>>
>

Re: [Pharo-dev] Raw pane on byteStrings

[Andrei Chis]

Hi Thierry,

Indeed that's the simplest option now that we are using fast table.

Just now in the case of the Raw view an OrderedCollection is used to store
all displayed elements.
If you display large collections every time you open the Raw view it will
instantiate a collection of size 100k and instantiate 100k objects of
type GTInspectorIndexedNode. With FastTable we can lazily load elements so
we should be able to remove this behaviour and the limit. Just we need to
make sure it will play nicely with automatic refresh. There is also the
issue that when expanding an element in the tree if it's a collection you
don't want to expand all elements.

I'm looking now on a lazy data source for FastTable that plays nicely with
GTInspector. Let's see how it will go. Help is always welcomed :)

I think I used the word paginator in the wrong way. If you have a very
large collection (millions of elements) I do not want to scroll through
elements but most likely jump to a certain element or view just a subset of
all elements. Not really add a paginator like in web pages.

Cheers,
Andrei

On Fri, Feb 24, 2017 at 10:37 AM, Thierry Goubier  wrote:

> Hi Andrei,
>
> if you're using fasttable for the Raw view, you should be able to reach
> one 100k elements without issues. I did some experiments and it handles the
> load very well.
>
> Avoid the paginator at any cost. This thing is really user-unfriendly.
>
> Regards,
>
> Thierry
>
> 2017-02-23 20:19 GMT+01:00 Andrei Chis :
>
>> Hi Stef,
>>
>> Currently that's the default behaviour of the Raw view: it displays for
>> collections only the first and the last 21 elements. The Items view however
>> always should display all the elements of a collection.
>>
>> The main problem with the Raw view in Pharo 5 is the speed. In Pharo 6
>> now the speed of the Raw view is greately improved so we could increase
>> those limits. Still for now there should still be some limit for the Raw
>> view. Ideally we should add a small widget, something like a paginator, for
>> navigating through large and very large collections.
>>
>> Cheers,
>> Andrei
>>
>> On Feb 23, 2017 19:35, "stepharong"  wrote:
>>
>>> Hi
>>>
>>> I'm trying to debug citezen generation and I have to compare strings.
>>> Now I think that the raw views (in Pharo 50) is not good because we
>>> cannot see all the items in raw format.
>>> See the attachements. It jumps from 21 to 174 ...
>>> and what I want to see is of course in the middle.
>>>
>>> Is it me or there is something wrong there.
>>> Stef
>>
>>
>

Re: [Pharo-dev] Pharo 60 : 60410 DNU on commit and no idea how to copy the stack :((((((((((((((((((((((((((((((((((((((((((((((

[Andrei Chis]

On Fri, Feb 24, 2017 at 8:44 AM, stepharong  wrote:

> On Fri, 24 Feb 2017 00:05:10 +0100, Andrei Chis <
> chisvasileand...@gmail.com> wrote:
>
>
>>
>> - How do we get the old textual stack description?
>>
>
> In the toolbar menu of the stack you find 'Fuel out stack' and 'Copy to
> clipboard'.
> 'Copy to clipboard' copies a textual description of the stack that can
> then be pasted in an email.
> Is this the "old textual description" or are you referring to something
> else?
>
>
> Ok this is what I was looking for.
> It looks like a generic copy past entry so I did not tried it.
> Can you rename it into  copy textual stack?
>

Indeed the name is confusing (even if it's always been like that).
I renamed it yesterday to 'Copy Stack to Clipboard'. Is that better? (It
fits also with 'Fuel out Stack')

Cheers,
Andrei


>
> Then I do not get why we could not get action about the current context
> and action about the complete stack together.
> Because these are not method that we see but contexts.
>
>
>
>
>> Now I wanted to report it and share with you the stack. oh
>> boy!
>> I thought it was file out but no it just save one method
>> definition (So great)
>>
>
> What action did you use to file our the textual description?
>
>
> fileout in the main menu when you clik on the stack element.
> I never ever used it since 2006.
>
>
> Cheers,
> Andrei
>
>
>
>>
>> I got Fuelout the stack in the menu but this is not what I want.
>> :(((
>
>
>> - Finally
>> BTW I clicked on report and I have no idea what it does not mean.
>> The fly by help is empty :(
>
>
>
> do you have an idea about what is this Send a report: it looks totally
> obscure and useless.
>
>
>>
>>
>> So like an idiot I did a screen capture.
>> This broke totally my feel. In less than 10 min I left like either the
>> system became less good or I'm totally stupid.
>>
>> Stef
>
>
>
>
>
> --
> Using Opera's mail client: http://www.opera.com/mail/
>

Re: [Pharo-dev] Pharo 60 : 60410 DNU on commit and no idea how to copy the stack :((((((((((((((((((((((((((((((((((((((((((((((

[Andrei Chis]

On Thu, Feb 23, 2017 at 10:55 PM, stepharong  wrote:

> Pharo 6.0
> Latest update: #60410
>
> Hi
>
> Several points that we MUST improve
>
> - I often get an error when I save code.
> SubscriptOutOfBounds: 0
>
>
> extent
> ^ self actualWidth
> ifNil: [ self minimumExtent ]
> ifNotNil: [
> (self actualWidth + self margins left + self
> margins right)
> @ (self lines last bottom - self lines
> first top + self margins top + self margins bottom) ]
> In RubParagraph
> apparentl self lines last...
> tries to access the 0 indexed element :(
>
>
> - How do we get the old textual stack description?
>

In the toolbar menu of the stack you find 'Fuel out stack' and 'Copy to
clipboard'.
'Copy to clipboard' copies a textual description of the stack that can then
be pasted in an email.
Is this the "old textual description" or are you referring to something
else?


>
> Now I wanted to report it and share with you the stack. oh boy!
> I thought it was file out but no it just save one method
> definition (So great)
>

What action did you use to file our the textual description?

Cheers,
Andrei



>
> I got Fuelout the stack in the menu but this is not what I want.
> :(((


> - Finally
> BTW I clicked on report and I have no idea what it does not mean.
> The fly by help is empty :(
>
>
> So like an idiot I did a screen capture.
> This broke totally my feel. In less than 10 min I left like either the
> system became less good or I'm totally stupid.
>
> Stef

Re: [Pharo-dev] Raw pane on byteStrings

[Andrei Chis]

Hi Stef,

Currently that's the default behaviour of the Raw view: it displays for
collections only the first and the last 21 elements. The Items view however
always should display all the elements of a collection.

The main problem with the Raw view in Pharo 5 is the speed. In Pharo 6 now
the speed of the Raw view is greately improved so we could increase those
limits. Still for now there should still be some limit for the Raw view.
Ideally we should add a small widget, something like a paginator, for
navigating through large and very large collections.

Cheers,
Andrei

On Feb 23, 2017 19:35, "stepharong"  wrote:

> Hi
>
> I'm trying to debug citezen generation and I have to compare strings.
> Now I think that the raw views (in Pharo 50) is not good because we cannot
> see all the items in raw format.
> See the attachements. It jumps from 21 to 174 ...
> and what I want to see is of course in the middle.
>
> Is it me or there is something wrong there.
> Stef

Re: [Pharo-dev] [pharo-project/pharo-core] 986ba2: 60402

[Andrei Chis]

Ping me in the evening when you have time. I might have some time but I'm
not 100% sure.

Cheers,
Andrei

On Tue, Feb 21, 2017 at 7:47 AM, p...@highoctane.be 
wrote:

> There are quite a few Themers + hard coded colors in GT.
>
> Maybe someone from the GT team can pair for an hour or two with me so that
> we can get this done.
>
> I can do this in the evening CET as I am pretty busy this week (managed to
> have Pharo a large part of my daily work now).
>
> Phil
>
> On Mon, Feb 20, 2017 at 6:54 PM, Sven Van Caekenberghe 
> wrote:
>
>> Thanks.
>>
>> Not that it is a big deal, but the default background does not really
>> match, but that might be taste as well.
>>
>> > On 20 Feb 2017, at 17:41, p...@highoctane.be wrote:
>> >
>> > I have fixed the spotter styling but need to get a 6.0 and move it
>> there.
>> >
>> > 
>> >
>> > On Mon, Feb 20, 2017 at 5:25 PM, Sven Van Caekenberghe 
>> wrote:
>> >
>> >> On 20 Feb 2017, at 16:45, GitHub  wrote:
>> >>
>> >> 19728 Integrate Sublimish theme
>> >>  https://pharo.fogbugz.com/f/cases/19728
>> >
>> > Very nice !
>> >
>> > But does it also not need Spotter styling ? This looks odd:
>> >
>> > 
>> >
>>
>>
>>
>

Re: [Pharo-dev] GLMAction and PharoShortcut

[Andrei Chis]

Hi,

Good catch. Indeed GLMAction>>#shortcutAsString should go to the keymap object.

Apart from the inconsistencies that you mention, there is in my view
another one. For example, in the debugger in the context menu of the
stack modifiers are displayed using special characters (at least on
mac). In tooltips they are display using Shift, Meta, Ctrl, etc.
Right now the logic for printing shortcuts that way is in
ToggleMenuItemShortcut>>#owner:keyText: and it's a bit complicated to
reuse. See GTSpotterCategoryTitleBrick>>#setShortcutBrickTextFor: for
an example.

Cheers,
Andrei

On Sun, Feb 12, 2017 at 11:32 AM, Hilaire  wrote:
> Hi,
>
> While writing these tooltips for the debugger, it seems to me some
> refactoring is needed in the use of Pharo shortcut:
> https://pharo.fogbugz.com/f/cases/19684/GLMAction-and-PharoShortcut-need-refactoring
>
> because the current situation to have Glamour tk rendering short cut as
> 'Ctrl-A' then Spec as 'Meta-A'
>
> Any opinion on the topic.
>
> Hilaire
>
> --
> Dr. Geo
> http://drgeo.eu
>
>

Re: [Pharo-dev] FastTableModel switched from default single-select to multi

[Andrei Chis]

Is this in the Glamour model or in the Spec one?
If it's the glamour one I made some changes to the Glamour one but I don't
remember changing the default to multiple selection. Maybe it's a bug :)

Cheers,
Andrei

On Mon, Feb 13, 2017 at 12:38 AM, Stephan Eggermont 
wrote:
> Breaking all code that expects selectedItem to be not-nil.
> Is that wanted behaviour? I noticed it broke SpecGenerator.
> I have no strong opinion on this, and welcome all Spec progress.
>
> Stephan
>
>

Re: [Pharo-dev] inspector performance improvement

[Andrei Chis]

On Sun, Feb 12, 2017 at 5:07 PM, p...@highoctane.be  wrote:
> Any chance for this to run on a 5.0?

There are two main changes: moved inspector to fast table and some
fixes in the glamour renderer.
Moving the changes for the glamour renderer should be straightforward.
I can point you to the list of relevant commits if you want to make a
slice (We'll just need afterwards to also update
ConfigurationOfGlamourCore to still work for Pharo 5)

The FastTable changes could require more work but that should also be
doable. However, now we still have some issues to fix there so that's
not done for the moment.


Cheers,
Andrei


>
> Phil
>
> On Sun, Feb 12, 2017 at 3:13 PM, stepharong  wrote:
>>
>> Great job
>> It feels lot snappier :)
>> Now it is a real pleasure to navigate objects.
>> This is nice to see that you are paying attention because the engine is
>> getting faster and this is important
>> that the tools do not eat all the power by accident.
>> Tx a lot
>>
>>
>> On Sat, 11 Feb 2017 21:31:56 +0100, Tudor Girba 
>> wrote:
>>
>>> Hi,
>>>
>>> Andrei and Alex did a great job at improving the performance and
>>> scalability of the inspector.
>>>
>>> There are a couple of main improvements:
>>> - Added FastTable support for the Raw presentation for all objects. This
>>> implied completing the support for the tree presentation binding to fast
>>> table.
>>> - Moved the Items presentation for collections to FastTable.
>>> - Improved the rendering of Glamour to no longer rely on the default
>>> Morph>>#adoptPaneColor. It turns out that using adoptPaneColor triggers a
>>> relayout of the morph, even if it is not visible. We extended PanelMorph in
>>> the context of Glamour with a less needy logic.
>>>
>>> I will not tell you how fast it is. I would rather want you to play with
>>> it :).
>>>
>>> The change is already in the Moose image. It is not yet in Pharo, but it
>>> will be soon. In the meantime you can be load it in Pharo 6 like this:
>>>
>>> Gofer new
>>> smalltalkhubUser: 'Moose' project: 'GToolkit';
>>> package: 'ConfigurationOfGToolkitCore';
>>> load.
>>> (#ConfigurationOfGToolkitCore asClass project version: #stable)
>>> load
>>>
>>> To play with it, try this with both the current version and the new one
>>> and the Spec Inspector if you want (just make sure you save the image
>>> beforehand):
>>>
>>> collection := (1 to: 1) asArray.
>>> [collection inspect] timeToRun.
>>>
>>> collection := (1 to: 1).
>>> [collection inspect] timeToRun.
>>>
>>> (for these two ones notice that Items do not appear at all in the old
>>> implementation)
>>>
>>> [World inspect] timeToRun.
>>>
>>>
>>> There are still a couple of issues open, such as the sorting of the
>>> columns. We would need your help with testing this, and report possible
>>> missing issues.
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>>
>>> "Obvious things are difficult to teach."
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Using Opera's mail client: http://www.opera.com/mail/
>>
>

Re: [Pharo-dev] [QA] Debugger buttons explained

[Andrei Chis]

On Wed, Feb 8, 2017 at 8:24 PM, Hilaire  wrote:

> Here my proposals. Please propose better alternative.
>
> Le 07/02/2017 à 21:02, Hilaire a écrit :
> > Full stack
>
> I really don't know what to write there.
>

Show the complete stack. By default the stacks shows a limited number of
stack frames.


> >
> > Run to here
>
> Execute methods up to the text cursor position and return debugger control.
>

yes.


>
>
> > Where is?
>
> Show the next method to be executed (step) by the debugger.
>

This highlights where execution is within the selected stack frame.
In case of the top context it's the method, assignment or return
instruction that will be executed next.
For the other contexts it's the method that is currently being executed.


Cheers,
Andrei


>
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>

Re: [Pharo-dev] [QA] Debugger buttons explained

[Andrei Chis]

Seems that I made a small mistake before.
DebugAction>>#asMenuRegistrationIn: is called only when creating the
context menu.
SpecDebuggerDynamicToolbar is the class that builds the toolbar with the
step buttons. Then each button will be an instance of SpecDebugActionButton.


Andrei

On Tue, Feb 7, 2017 at 8:29 PM, Hilaire  wrote:

> Changed to the SpecDebugger in the method mentionned bellow does not
> have action on newly debuggin session with SpecDebugger. This method is
> not call. Any idea?
>
> Le 06/02/2017 à 21:57, Andrei Chis a écrit :
> > For the Spec interface of the debugger you need to adapt
> > DebugAction>>#asMenuRegistrationIn:
> >
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

[Andrei Chis]

Done.

Cheers,
Andrei

On Tue, Feb 7, 2017 at 1:35 PM, Ben Coman  wrote:

> On Tue, Feb 7, 2017 at 8:00 PM, Andrei Chis 
> wrote:
> >
> >
> > On Sat, Feb 4, 2017 at 4:40 PM, Ben Coman  wrote:
> >>
> >>
> >> > On Fri, Feb 3, 2017 at 3:13 AM, Ben Coman 
> wrote:
> >> >>
> >> >> Just curious what the magic numbers here relate to...
> >> >> and can they be factored out to a meaningful method name?
> >> >>
> >> >> Context>>gtInspectorVariableValuePairs
> >> >> "This is a helper method that returns a collection of
> >> >> variable_name -> value
> >> >> for the current object.
> >> >> Subclasses can override it to specialize what appears in the
> variables
> >> >> presentation"
> >> >> | bindings |
> >> >> bindings := OrderedCollection new.
> >> >> 1 to: (self basicSize min: 21) do: [ :index |
> >> >> bindings add: (index "asString""asTwoCharacterString" -> (self
> basicAt:
> >> >> index)) ].
> >> >> ((self basicSize - 20) max: 22) to: (self basicSize) do: [ :index |
> >> >> "self
> >> >> haltIf: [ index = 99 ]."
> >> >> bindings add: (index "asString" -> (self basicAt: index)) ].
> >> >> bindings
> >> >> addAll: ((self class allSlots
> >> >> collect: [ :slot | slot name -> (slot read: self) ]) sort
> >> >> asOrderedCollection).
> >> >> ^ bindings
> >> >>
> >> >>
> >> >> cheers -ben
> >> >
> >> >
> >>
> >> On Fri, Feb 3, 2017 at 11:20 PM, Andrei Chis <
> chisvasileand...@gmail.com>
> >> wrote:
> >> > Yes these numbers should be refactored
> >> > For collections only the first and the last 21 elements are displayed
> in
> >> > the
> >> > Raw view. Don't remember why 21.
> >> >
> >> > Cheers,
> >> > Andrei
> >> >
> >>
> >> Ahhh. Nice to know.  Here I was thinking it was based on some intrinsic
> >> restriction on the number of variables or something.
> >>
> >> I'm a fan of overusing redundant variables for documenting purposes...
> >>
> >> Object>>gtInspectorVariableValuePairs
> >> | indexableDisplayLimit bottom topLimit bottomLimit bindings |
> >>
> >> indexableDisplayLimit := 21.
> >> top := 1.
> >> bottom := self basicSize.
> >> topLimit := bottom min: indexableDisplayLimit.
> >> bottomLimit := (bottom - indexableDisplayLimit) max:
> indexableDisplayLimit.
> >>
> >> bindings := OrderedCollection new.
> >> "Return top and bottom of indexable elements"
> >> top to: topLimit do: [ :index | bindings add: (index -> (self basicAt:
> >> index)) ]. bottomLimit + 1 to: bottom do: [ :index | bindings add:
> (index ->
> >> (self basicAt: index)) ].
> >>
> >> "Return named variables"
> >> bindings
> >> addAll: ((self class allSlots
> >> collect: [ :slot | slot name -> (slot read: self) ]) sort
> >> asOrderedCollection).
> >> ^ bindings
> >>
> >> If this looks reasonable I'll do up a slice.
> >
> >
> > Looks good. I'll commit this to the inspector repo and will be picked by
> the
> > next integration.
>
> Thanks Andre.
>
> Very minor thing if its not too late. Looking at it again I'd actually
> rearrange these two lines like this...
>   topLimit:= indexableDisplayLimit min: bottom.
>   bottomLimit := indexableDisplayLimit max: (bottom -
> indexableDisplayLimit) .
>
> But don't worry if you've already done the first way.
> cheers -ben
>
> >
> > Cheers,
> > Andrei
> >
> >>
> >>
> >> Perhaps defining "top" is overkill - but it does read nice below that.
> >> btw, in general I understand that some smart optimising compilers will
> >> substitute 1 for "top" directly since its assigned a literal and not
> >> reassigned before its use.  I notice from the bytecode this doesn't
> happen
> >> here.  Is there some intrinsic difficulty in our domain stopping this to
> >> happen, or its just not been a priority.  I guess while stepping
> through the
> >> debugger "top" a user might set a new value for "top" and reverting the
> >> substitution of "1" for "top" needs the sort of facility that Sista will
> >> provide??
> >>
> >>
> >> On Sat, Feb 4, 2017 at 12:08 AM, Tudor Girba 
> wrote:
> >>>
> >>> There is very little meaning behind the number.
> >>>
> >>> The previous inspector showed the first 100 and the last 10 elements.
> 100
> >>> is anyway too large for a quick inspection, so we picked another
> number. I
> >>> wanted 42 but that was still large, so we are now at 21.
> >>
> >>
> >> Well 21 top and bottom gives you 42, and I know life, the universe and
> >> everything depends on that number - so this seems reasonable.
> >>
> >>
> >> On Sat, Feb 4, 2017 at 12:39 AM, Aliaksei Syrel 
> >> wrote:
> >>>
> >>> They could be extracted to class vars for example TWENTY_ONE := 21.
> Later
> >>> if performance is still not good enough they may be changed for
> example to
> >>> TWENTY_ONE := 15.
> >>> (joke)
> >>
> >>
> >> You mean something like this...
> >> https://xkcd.com/221/
> >>
> >>
> >> cheers -ben
> >
> >
>
>

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

[Andrei Chis]

On Sat, Feb 4, 2017 at 4:40 PM, Ben Coman  wrote:

>
> > On Fri, Feb 3, 2017 at 3:13 AM, Ben Coman  wrote:
> >>
> >> Just curious what the magic numbers here relate to...
> >> and can they be factored out to a meaningful method name?
> >>
> >> Context>>gtInspectorVariableValuePairs
> >> "This is a helper method that returns a collection of
> >> variable_name -> value
> >> for the current object.
> >> Subclasses can override it to specialize what appears in the variables
> >> presentation"
> >> | bindings |
> >> bindings := OrderedCollection new.
> >> 1 to: (self basicSize min: 21) do: [ :index |
> >> bindings add: (index "asString""asTwoCharacterString" -> (self basicAt:
> >> index)) ].
> >> ((self basicSize - 20) max: 22) to: (self basicSize) do: [ :index |
> "self
> >> haltIf: [ index = 99 ]."
> >> bindings add: (index "asString" -> (self basicAt: index)) ].
> >> bindings
> >> addAll: ((self class allSlots
> >> collect: [ :slot | slot name -> (slot read: self) ]) sort
> >> asOrderedCollection).
> >> ^ bindings
> >>
> >>
> >> cheers -ben
> >
> >
>
> On Fri, Feb 3, 2017 at 11:20 PM, Andrei Chis 
> wrote:
> > Yes these numbers should be refactored
> > For collections only the first and the last 21 elements are displayed in
> the
> > Raw view. Don't remember why 21.
> >
> > Cheers,
> > Andrei
> >
>
> Ahhh. Nice to know.  Here I was thinking it was based on some intrinsic
> restriction on the number of variables or something.
>
> I'm a fan of overusing redundant variables for documenting purposes...
>
> Object>>gtInspectorVariableValuePairs
> | indexableDisplayLimit bottom topLimit bottomLimit bindings |
>
> indexableDisplayLimit := 21.
> top := 1.
> bottom := self basicSize.
> topLimit := bottom min: indexableDisplayLimit.
> bottomLimit := (bottom - indexableDisplayLimit) max: indexableDisplayLimit.
>
> bindings := OrderedCollection new.
> "Return top and bottom of indexable elements"
> top to: topLimit do: [ :index | bindings add: (index -> (self basicAt:
> index)) ]. bottomLimit + 1 to: bottom do: [ :index | bindings add: (index
> -> (self basicAt: index)) ].
>
> "Return named variables"
> bindings
> addAll: ((self class allSlots
> collect: [ :slot | slot name -> (slot read: self) ]) sort
> asOrderedCollection).
> ^ bindings
>
> If this looks reasonable I'll do up a slice.
>

Looks good. I'll commit this to the inspector repo and will be picked by
the next integration.

Cheers,
Andrei


>
> Perhaps defining "top" is overkill - but it does read nice below that.
> btw, in general I understand that some smart optimising compilers will
> substitute 1 for "top" directly since its assigned a literal and not
> reassigned before its use.  I notice from the bytecode this doesn't happen
> here.  Is there some intrinsic difficulty in our domain stopping this to
> happen, or its just not been a priority.  I guess while stepping through
> the debugger "top" a user might set a new value for "top" and reverting the
> substitution of "1" for "top" needs the sort of facility that Sista will
> provide??
>
>
> On Sat, Feb 4, 2017 at 12:08 AM, Tudor Girba  wrote:
>
>> There is very little meaning behind the number.
>>
>> The previous inspector showed the first 100 and the last 10 elements. 100
>> is anyway too large for a quick inspection, so we picked another number. I
>> wanted 42 but that was still large, so we are now at 21.
>
>
> Well 21 top and bottom gives you 42, and I know life, the universe and
> everything depends on that number - so this seems reasonable.
>
>
> On Sat, Feb 4, 2017 at 12:39 AM, Aliaksei Syrel 
> wrote:
>
>> They could be extracted to class vars for example TWENTY_ONE := 21. Later
>> if performance is still not good enough they may be changed for example to
>> TWENTY_ONE := 15.
>> (joke)
>>
>
> You mean something like this...
> https://xkcd.com/221/
>
>
> cheers -ben
>

Re: [Pharo-dev] [QA] Debugger buttons explained

[Andrei Chis]

On Mon, Feb 6, 2017 at 9:14 PM, Hilaire  wrote:

> Thanks for the updated message.
>
> Le 06/02/2017 à 19:39, Sven Van Caekenberghe a écrit :
> > That last one is not correct. It has nothing to do with specific
> iteration selectors. It means: stop when execution returns in one of the
> argument blocks. It also works for #on:error: #streamContents: or any other
> message that accepts blocks as argument - which is pretty cool.
>
> Strangely step over does not step in the bloc with #do: but does with
> #to:do:
>
> In the later case step over and through behave mostly the same, the
> stack looks a bit different though.
>
>
> Another question, I try to locate where the tooltips are set in the
> debugger. I can't find it with traditional browser tools (send, class
> use) and the finder:
>
> The finder tells me "Through" is used in SpecThroughDebugAction, but
> browser tells me there is no use case of this class. I see some pragma
> in class side method, did it...
> actionType
> 
> 
>
> No user of actionType, but I guess user or pragma, how do you guys track
> the logic from here
>

Seems that the logic for changing the tooltips is not that straightforward.
If you ping me once you decided for a the text of the tooltip I can add
them.

If you want to look at it yourself here are some details:
Each action in the debugger is modeled as a subclass of DebugAction.
The Glamour interface of the debugger uses DebugAction>>#asGlamourAction
to transform that into a Glamour action. This action is then rendered
in GLMMorphicActionRenderer>>#render:.
There the tooltip is set directly by concatenating the title and the
shortcut of the action.
Best solution would be to add a description attribute to DebugAction and
GLMAction and then
modify GLMMorphicActionRenderer>>#render: to use it.
For the Spec interface of the debugger you need to adapt
DebugAction>>#asMenuRegistrationIn:


Cheers,
Andrei



>
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

[Andrei Chis]

Yes these numbers should be refactored
For collections only the first and the last 21 elements are displayed in
the Raw view. Don't remember why 21.

Cheers,
Andrei

On Fri, Feb 3, 2017 at 3:13 AM, Ben Coman  wrote:

> Just curious what the magic numbers here relate to...
> and can they be factored out to a meaningful method name?
>
> Context>>gtInspectorVariableValuePairs
> "This is a helper method that returns a collection of
> variable_name -> value
> for the current object.
> Subclasses can override it to specialize what appears in the variables
> presentation"
> | bindings |
> bindings := OrderedCollection new.
> 1 to: (self basicSize min: 21) do: [ :index |
> bindings add: (index "asString""asTwoCharacterString" -> (self basicAt:
> index)) ].
> ((self basicSize - 20) max: 22) to: (self basicSize) do: [ :index | "self
> haltIf: [ index = 99 ]."
> bindings add: (index "asString" -> (self basicAt: index)) ].
> bindings
> addAll: ((self class allSlots
> collect: [ :slot | slot name -> (slot read: self) ]) sort
> asOrderedCollection).
> ^ bindings
>
>
> cheers -ben
>

Re: [Pharo-dev] Strange behaviour of GTInspector

[Andrei Chis]

Nice bug :)

Most likely comes from GLMTreeMorphNodeModel>>#rowMorphForColumn:
and GLMEditableLabelBrick.
Right now GLMEditableLabelBrick uses an alarm to detect if the user double
clicked on the column. Seems that the alarm is not triggered if the mouse
does not move.


Andrei

On Tue, Jan 31, 2017 at 5:05 PM, Denis Kudriashov 
wrote:

> Hi.
>
> It seams that click on cell with value of variable in GTInspector
> activates selection only when mouse moves. It feels like slow selection.
> It not happens when cell with name is clicked.
>
> Try inspect 10@30 and select 10 or 30 to see the problem.
>

Re: [Pharo-dev] inconsistent FileLocator behavior

[Andrei Chis]

Hi Henry,

On Wed, Dec 14, 2016 at 4:20 PM, Henrik Johansen <
henrik.s.johan...@veloxit.no> wrote:

>
> > On 14 Dec 2016, at 10:13 , Peter Uhnak  wrote:
> >
> > Because now I always end up doing FileLocator home asFileReference,
> which feels superfluous.
> >
> > What is the use case that you don't want to resolve it yet?
>
> To illustrate the benefit of keeping things as FileLocator instances
> rather than resolved paths until needed, you could try:
> 1) Open a playground.
> 2) Save image.
> 3) Quit, open image on different platform.
>
> In Pharo 5, your image will simply error on trying to open new
> Playgrounds, on Pharo6 you lose any custom locations selected in the
> settings for storing cache/stash.
> The amount of workaround code dealing with cache/stashDirectories being
> FileReferences instead of FileLocators is an interesting read - not to
> mention implemented in 2 different ways for cacheDirectory/stashDirectory;
> one never lets you keep a custom value (resetting to nil at startup), and
> the other discards any custom path when transitioning platforms. (is it not
> nil? does it exist? If not, reset to default)
>

This is an interesting observation. I'd love to simplify the code in that
part. Can you open a bug report with this info so it's not lost.

Cheers,
Andrei


>
> TL;DR: The use-case for FileLocators is persistently stored relative paths
> that need to work cross-platform.
>
> Cheers,
> Henry
>

Re: [Pharo-dev] feature request for GTSUnitDebugger

[Andrei Chis]

Hi,

Right now there is 'Jump to test method' in the toolbar menu of the stack
(the drop down arrow next to Through).
Could maybe make sense to make it an actual button.

Cheers,
Andrei

On Sat, Nov 26, 2016 at 8:23 PM, Denis Kudriashov 
wrote:

> Hello.
>
> I catch myself that I very often scroll stack view in debugger just to see
> test method.
> It would be nice to have test tab and "show test" button.
>
> Best regards,
> Denis
>

Re: [Pharo-dev] [how about] Exceptions as first class objects *in Debugger*

[Andrei Chis]

+1

I had a prototype working at a certain point that send the exception to the
debugger.
I'll see if I can dig it up. It just involved chancing the API methods that
open the debugger. Maybe a bit late for Pharo 6.

On Sun, Nov 6, 2016 at 11:04 PM, Bernardo Ezequiel Contreras <
vonbecm...@gmail.com> wrote:

> +1, with that information you could describe or show the cause of the
> exception
>
> On Sun, Nov 6, 2016 at 6:46 AM, Sven Van Caekenberghe 
> wrote:
>
>> Indeed this has bothered me a lot as well.
>>
>> At least an 'Inspect Exception' would be useful.
>>
>> It would also encourage people to put more useful information inside
>> exception objects.
>>
>> > On 6 Nov 2016, at 10:38, Yuriy Tymchuk  wrote:
>> >
>> > Hi,
>> >
>> > we have this supercool exception handling mechanism, but as soon as we
>> open a debugger the exception object is gone… I understand that we didn’t
>> need this in old times, but now with a moldable debugger, we could create
>> hooks to allow exceptions to define how they should be addressed (and
>> objects are really powerful).
>> >
>> > Cheers.
>> > Uko
>>
>>
>>
>
>
> --
> Bernardo E.C.
>
> Sent from a cheap desktop computer in South America.
>

Re: [Pharo-dev] Extending Pharo Debugger

[Andrei Chis]

Hi Matteo,

If you look, for example at RestartDebugAction, there is on
the class side a method #gtStackDebuggingActionFor: that
has the annotation .

To attach actions to the stack (proceed, resume, step into)
the debugger looks for subclasses of DebugAction that have
class side methods annotated with gtStackDebuggingAction.

These methods can optionally receive the debugger instance
as an argument. However you can also only have simple
methods like 'PeelToFirstDebugAction class>>#gtActionType'


Cheers,
Andrei



On Tue, Oct 4, 2016 at 4:10 PM, Matteo Marra  wrote:

> Hello,
>
> I'm working on the Pharo debugger, and I wanted to add a button with new
> functionality just besides the buttons "Proceed" "restart" ...
>
> Is there an easy way to do it? Which is the class that I have to
> Modify/Extend in order to do that?
>
> I tried to look around the methods and I found where DebugSession is
> created, but I didn't see any clear reference to the UI or to how is
> constructed in it.
>
> Thank you in advance,
> Matteo
>

Re: [Pharo-dev] Protrammatic selection in Glamour

[Andrei Chis]

The #selection: message of a presentation should update the selection.
Let me know if it doesn't work as expected for you.

Cheers,
Andrei

On Sun, Oct 2, 2016 at 9:15 PM, Martin McClure 
wrote:

> Is there a way in Glamour to programmatically select an item in a list or
> tree presentation? (That is, having the same effect as clicking on the
> item.) I'm using the Glamour in Pharo 5.
>
> Thanks,
>
> -Martin
>
>

Re: [Pharo-dev] Error When Accepting Changes in Debugger (Moose 6 on Pharo 5)

[Andrei Chis]

Doesn't look familiar.
Do you have a way to reproduce it?

Cheers,
Andrei

On Sun, Sep 4, 2016 at 11:16 PM, Sean P. DeNigris 
wrote:

> MessageNotUnderstood: Context>>messageName
>
> Is this a known bug? Should I open an issue?
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/Error-
> When-Accepting-Changes-in-Debugger-Moose-6-on-Pharo-5-tp4914109.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] why is gt playground not saving the code

[Andrei Chis]

On Wed, Aug 31, 2016 at 12:32 PM, Nicolai Hess 
wrote:

>
>
> 2016-08-31 12:00 GMT+02:00 Peter Uhnák :
>
>> At this point I’ve lost cumulatively hours and hours of work due to
>> Playground not saving the code; so every time I crash I lose.
>>
>>
>>
>> In the picture below the code was demonstrably executed and yet it’s not
>> in the history and if I would crash (which happens several times a day in
>> “stable” pharo 5) I would lose it. Not to mention that way too often I see
>> duplicate events in the history with identical code…
>>
>>
>>
>>
>>
>
> This was discussed  a couple of time and we even had some bug-entries.
> But it is working that way "by-design".
> I don't understand why, but the current content is not shown in the
> history, only if you close the current playground window *withouth*
> deleteing the content.
>

I do not remember the previous discussion in details but I think we should
consider this a bug.
I'll open a bug report and try to dig the previous discussion about this
topic.

Cheers,
Andrei


> If the content is not shown in the history, it may be still in the
> play-cache folder.
>
>
>
>> Peter
>>
>
>

Re: [Pharo-dev] problem with Epicea and #name

[Andrei Chis]

Hi Martin,

To reproduce the error execute the code below. The first part does some
cleanups needed to remove the code. The second part  attempts to remove two
packages and seems to go into a recursion. If you interrupt the execution
with cmd+. you'll see a lot of Context>>#handleSignal:. If you right click
on one and select 'Peel to first like this' it will find the original
context that triggered the error.

Don't worry there is no inconvenience :).
Thanks for looking into this.

GTExampleOrganizer instance reset.
GTExampleOrganizer instance stopThoroughly.
GTExampleOrganizer stop.
Smalltalk garbageCollect.
self assert: GTExample allSubInstances isEmpty.
self assert: GTExampleMethod allSubInstances isEmpty.

Gofer new
smalltalkhubUser: 'Moose' project: 'GToolkit';
package: 'GT-InspectorExtensions-Core';
package: 'GT-Inspector';
load.

Cheers,
Andrei

On Thu, Aug 25, 2016 at 1:00 PM, Martin Dias  wrote:

> Hi Andrei, there is an open  issue that involves #name in category removal
> whose fix is ready in bleeding edge and only waits that i release the new
> stable version. But this is about category removal, not class removal. This
> night I will take a look on the code of class removal... however, could you
> send a stack trace, please?
> I'm sorry for the inconvenience.
> Martín
>
> El 25/8/2016 7:18, "Andrei Chis"  escribió:
>
>> Hi,
>>
>> When trying to load a new version of the GTInspector in the latest Pharo
>> image I get an infinite recursion. It seems that the problem is appears
>> because a class is removed, which at a certain point calls
>> #asEpiceaRingDefinition. This does then 'self superclass name', however,
>> the superclass is nil and UndefinedObject>>#name is called, which is
>> deprecated. This should open a warning window and but it leads to an
>> infinite recursion. Know problem or should I opened an issues?
>>
>> Cheers,
>> Andrei
>>
>

[Pharo-dev] problem with Epicea and #name

[Andrei Chis]

Hi,

When trying to load a new version of the GTInspector in the latest Pharo
image I get an infinite recursion. It seems that the problem is appears
because a class is removed, which at a certain point calls
#asEpiceaRingDefinition. This does then 'self superclass name', however,
the superclass is nil and UndefinedObject>>#name is called, which is
deprecated. This should open a warning window and but it leads to an
infinite recursion. Know problem or should I opened an issues?

Cheers,
Andrei

Re: [Pharo-dev] [Moose-dev] Re: [ANN] Release of Agile Visualization

[Andrei Chis]

Looks awesome !!!

Andrei

On Sun, Aug 14, 2016 at 11:45 PM, Tudor Girba  wrote:

> Great work!
>
> Doru
>
>
> > On Aug 14, 2016, at 11:19 PM, Alexandre Bergel 
> wrote:
> >
> > Dear Colleagues and Friends,
> >
> > It is a great pleasure to announce the release of Agile Visualization.
> Agile Visualization is a book about the Roassal Visualization engine.
> >
> > Paperback, eBook (PDF), and a free HTML format chapters are available
> from http://AgileVisualization.com
> > The book has 235 pages and covers the essential aspects of Roassal.
> Copies of the book will be sold at ESUG’16.
> >
> > Screenshots and codes contained in the book were produced on Pharo.
> However, most of the covered code and topics _equally_run on VisualWorks
> (from version 7.4 (!)).
> >
> > We would like to thank all the contributors and users of Roassal who
> have deeply impacted and shaped Agile Visualization. The book is dedicated
> to the Smalltalk community at large. Big big thanks to our sponsors, Lam
> Research, Object Profile, and ESUG.
> > And thanks to you for being as you are and making Smalltalk such a great
> platform.
> >
> > Thanks
> > Alexandre
> >
> > ___
> > Moose-dev mailing list
> > moose-...@list.inf.unibe.ch
> > https://www.list.inf.unibe.ch/listinfo/moose-dev
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "One cannot do more than one can do."
>
>
>
>
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

[Andrei Chis]

+1

On Wed, Jul 6, 2016 at 8:19 PM, Sven Van Caekenberghe  wrote:

> I'll try once more to explain.
>
> You like the catalog, don't you ?  It was your idea in the first place.
> With this feature you can just type XML, CSV, JSON or whatever and it will
> suggest a couple of catalog projects that you can install with just one
> click, no need to open any tool you don't even know. This is especially
> good for new people. IT IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD
> WORK. It leverages all the work put in the catalog.
>
> Is Spotter or any other part of Pharo perfect ? No.
>
> For many people, Spotter make a huge functional difference, we use it
> every minute. If it would hang or block the image even once a day, any of
> us would complain loudly.
>
> Conclusion: it works for 99% of the people/cases.
>
> Even in the 1% where there is a problem, it is not 100% sure it is related
> to the catalog searching. In the last concrete issue reported, the guy
> tried disabling the catalog searching AND IT MADE NO DIFFERENCE !
>
> So again, why turn it off ? It is an overreaction, not engineering.
>
> The underlying problem is that in some very rare, hard to reproduce cases
> we cannot reliably detect that there is no network. That's about it.
>
> Note also that almost every application or app today will do some network
> calls, this is how the world work - we should be able to do the same with
> Pharo, not run away and kill every feature that does a network call.
>
> > On 06 Jul 2016, at 18:14, stepharo  wrote:
> >
> > Who vote to put it in?
> >
> > Seriously I think that my main concern is about getting Pharo stable in
> any occasion and not giving
> >
> > a bad impression of the system. I takes enough time to build traction
> and such glitches can spoil
> >
> > our effort in no time. "Yes Pharo froze."
> >
> > So it would be nice to care take of such aspect.
> >
> > I do not understand why super users do not manage to put a reference to
> on in the preferences.
> >
> > Sorry esteban but I do not buy your argument that something off is
> remove. No it is off.
> >
> > Stef
> >>> On 06 Jul 2016, at 09:52, GitHub  wrote:
> >>>
> >>> 18674 Turn spotter catalog off by default
> >>> https://pharo.fogbugz.com/f/cases/18674
> >> We did not agree on this, at all, there was no public discussion, no
> vote.
> >>
> >>
> >
> >
>
>
>

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

[Andrei Chis]

On Wed, Jul 6, 2016 at 12:28 PM, Esteban Lorenzano 
wrote:

> yes, I do not agree either but is true there where problems.
> but IMO this would be solved just by putting a timeout in 1-2s (and then
> run in background, and cache results)
> not turning it off.
> in for my experience, turning something off is equivalent to remove the
> feature (but then is worst, because it becomes dead code inside image).
>

This is how it's currently implemented but it doesn't solve all issues:
https://pharo.fogbugz.com/f/cases/18281/NetNameResolver-class-addressForName-sometimes-hangs-when-there-is-no-network


>
> Anyway, any taker, to solve this in a proper way?
>
> Esteban
>
> > On 06 Jul 2016, at 12:13, Marcus Denker  wrote:
> >
> >
> >> On 06 Jul 2016, at 10:12, Sven Van Caekenberghe  wrote:
> >>
> >>
> >>> On 06 Jul 2016, at 09:52, GitHub  wrote:
> >>>
> >>> 18674 Turn spotter catalog off by default
> >>> https://pharo.fogbugz.com/f/cases/18674
> >>
> >> We did not agree on this, at all, there was no public discussion, no
> vote.
> >>
> >
> > I only know that there where problems.
> >
> >   Marcus
> >
>
>
>

Re: [Pharo-dev] Privacy sendDiagnosticsAndUsageData should be ternary, not binary

[Andrei Chis]

On Wed, Jun 8, 2016 at 9:28 AM, stepharo  wrote:

>
>
> Le 7/6/16 à 12:00, Andrei Chis a écrit :
>
> Hi Peter,
>
> On Tue, Jun 7, 2016 at 12:05 AM, Peter Uhnak  wrote:
>
>> Hi,
>>
>> Privacy>>sendDiagnosticsAndUsageData should be ternary, not binary.
>>
>> Because right now if I refuse sending the data I will be asked again
>> every single time.
>>
>
> Indeed right now, at least in Spotter, the notification is shown every
> time it is opened in
> a new image, even if the setting was explicitly set. It was done like this
> as a reminder,
> especially if you have the setting set to true.
>
>
> Andrei for the shortcut reporter we put a number of show. Like that the
> user will be reminder a number
> of times and the system will get calm. May be you could do the same
>

In a new image the message to send usage data is shown only once.
Indeed we could add a counter but that would have to maintain state between
images.


>
>> So the proper behavior (imho) should be:
>>
>> ask Privacy for the setting… if the setting is not defined, then show a
>> popup.
>> If the setting is defined then respect it and do not show another popup.
>>
>
> The current behaviour with showing the notification in Spotter and
> Nautilus should be a temporary one.
> Ideally we just need a single uniform way of showing this notification
> plus the option to control
> and see the data that each tool wants to record at a fined-grained level.
>
>
>>
>> Also it would be nice to know what happens with the data.
>>
>
> We store it on a server and use it for various analyses.
>
> what can you tell us on processor use in Spotter.
>

Not right at this moment. I'm way to busy with other urgent things.
Some older results were discussed here:
http://scg.unibe.ch/scgbib?query=Kube15a&display=abstract
Just for these result to carry more value we still need more people to send
data.
Right now few do.

Cheers,
Andrei


>
> It is also publicly available: GTEventTool default download.
>
>
>> I mean my projects are open source so "sendSourceCode" shouldn't be an
>> issue… but what you can possibly learn from it?
>> Why not just analyze the content of SmalltalkHub/GitHub?
>>
>
> Because if you have the setting enabled it does not always work to map
> different actions that with the code that you are working on.
>
> Cheers,
> Andrei
>
>
>>
>> Peter
>>
>>
>
>

Re: [Pharo-dev] Story of one small fix

[Andrei Chis]

Hi Pavel,

On Wed, Jun 8, 2016 at 11:05 AM, Pavel Krivanek 
wrote:

> Hi,
>
> we had in the system circular package dependency between Catalog and
> GTools and we decided to solve it by simple moving of one method from one
> package to other one. However, these two packages are external packages
> managed by configurations. That means that we needed move the method, save
> dirty packages and fix both configurations.
>
> For the catalog we have very simple configuration because it manages only
> one package (and dependency on STON). ConfigurationOfGTInspectorCore was
> more complicated because the repository already included newer development
> version of the modified package so we needed to merge. But because we are
> not the maintainers, we cannot know if the change in this package is not
> requiring changes in other packages provided by the configuration.
> Well, the new configurations were prepared and copied into inbox. We
> needed to create next two issues for updating of the configuration in the
> system. We did it and integrated all together in one update. But that is
> not all...
> ConfigurationOfGTInspectorCore is used by three other configurations (
> ConfigurationOfGTPlaygroundCore, ConfigurationOfGToolkitCore and
> ConfgurationOfGTDebugger) that specify number of
> ConfigurationOfGTInspectorCore version. In ideal state you should create
> new versions of the configurations but that means that you need to modify
> configurations of all other configurations that use them. It is simpler
> just modify current configuration and upgrade required version number of
> GTInspectorCore. That means to create three next issues, each for one
> configuration, create new configuration versions (and check and merge the
> newer versions in the home repository if needed), copy them to the inbox,
> wait for the review and hope that during integration the Integrator will
> not create new versions of some packages. If yes, you need to update
> configurations again.
>

Just a quick comment.
Did you edited the configurations and their dependencies by hand? Since
some time I never update them by hand, only use versioner to generate a new
version for ConfigurationOfGToolkitCore and automatically also update all
dependencies to all other configurations that I need. Then I make just one
issue to integrate ConfigurationOfGToolkitCore that also loads/updates all
other configurations. I know this is still not ideal but it's significant
less work than what you described.

Chees,
Andrei


> So at the end you have at least six issues because you wanted to change
> package for one method that has still the same content and is placed in the
> same class... And it can be worse. Both of these external projects have
> public access to the repository and are managed the same way (not mixing MC
> with GIT).
>
> As you see, it is crazy and unmaintainable.
>
> It is clear that we need to change the process. We need to discuss it
> deeply and some of the results may touch maintainers of the external
> projects integrated in Pharo but please keep in mind that the current
> system is clearly bad.
>
> Cheers,
> -- Pavel
>
>
>

Re: [Pharo-dev] GT-Spotter dive in shortcut

[Andrei Chis]

We can, but I remember there were some discussions and it was decided to
use meta everywhere.

Cheers,
Andrei

On Tue, Jun 7, 2016 at 3:49 PM, Nicolai Hess  wrote:

>
>
> 2016-06-07 15:08 GMT+02:00 Andrei Chis :
>
>> During Pharo 5 most shortcuts from tools were changed to use "meta"
>> instead of cmd.
>>
>> Cheers,
>> Andrei
>>
>
> Can we change this for spotter ? cmd instead of meta
>
> ctrl left/right is often used for text components to move to next/previous
> word.
>
>
>
>>
>> On Tue, Jun 7, 2016 at 2:18 PM, Nicolai Hess 
>> wrote:
>>
>>>
>>>
>>> 2016-06-07 13:57 GMT+02:00 Nicolai Hess :
>>>
>>>>
>>>> Am 07.06.2016 1:56 nachm. schrieb "Henrik Nergaard" <
>>>> henrik.nerga...@uia.no>:
>>>> >
>>>> > IIRC the shortcut is not changed, it still is meta+right(+shift).
>>>> Only the tooltip was changed to display the system specific key instead of
>>>> “cmd” so for Windows/Linux this would be “ctrl”.
>>>>
>>>> No, it changed
>>>>
>>> In #40624, for example, it was cmd (alt-key on windows ) right/shift
>>> right
>>>
>>>
>>>> >
>>>> >
>>>> >
>>>> > Best regards,
>>>> >
>>>> > Henrik
>>>> >
>>>> >
>>>> >
>>>> > From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf
>>>> Of Nicolai Hess
>>>> > Sent: Tuesday, June 7, 2016 12:56 PM
>>>> > To: Pharo Development List 
>>>> > Subject: [Pharo-dev] GT-Spotter dive in shortcut
>>>> >
>>>> >
>>>> >
>>>> > Why did the shortcut for dive-in element/category changed from
>>>> >
>>>> > cmd+right
>>>> >
>>>> > cmd+shift+right
>>>> >
>>>> > to
>>>> >
>>>> > ctrl+right
>>>> > ctrl+shift+right
>>>> >
>>>> > I know there were some discussions about this and that the behavior
>>>> changed some
>>>> >
>>>> > time ago, but I don't know the rational behind this.
>>>> >
>>>> > thanks
>>>> >
>>>> > nicolai
>>>> >
>>>> >
>>>>
>>>
>>>
>>
>

Re: [Pharo-dev] GT-Spotter dive in shortcut

[Andrei Chis]

During Pharo 5 most shortcuts from tools were changed to use "meta" instead
of cmd.

Cheers,
Andrei

On Tue, Jun 7, 2016 at 2:18 PM, Nicolai Hess  wrote:

>
>
> 2016-06-07 13:57 GMT+02:00 Nicolai Hess :
>
>>
>> Am 07.06.2016 1:56 nachm. schrieb "Henrik Nergaard" <
>> henrik.nerga...@uia.no>:
>> >
>> > IIRC the shortcut is not changed, it still is meta+right(+shift). Only
>> the tooltip was changed to display the system specific key instead of “cmd”
>> so for Windows/Linux this would be “ctrl”.
>>
>> No, it changed
>>
> In #40624, for example, it was cmd (alt-key on windows ) right/shift right
>
>
>> >
>> >
>> >
>> > Best regards,
>> >
>> > Henrik
>> >
>> >
>> >
>> > From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf
>> Of Nicolai Hess
>> > Sent: Tuesday, June 7, 2016 12:56 PM
>> > To: Pharo Development List 
>> > Subject: [Pharo-dev] GT-Spotter dive in shortcut
>> >
>> >
>> >
>> > Why did the shortcut for dive-in element/category changed from
>> >
>> > cmd+right
>> >
>> > cmd+shift+right
>> >
>> > to
>> >
>> > ctrl+right
>> > ctrl+shift+right
>> >
>> > I know there were some discussions about this and that the behavior
>> changed some
>> >
>> > time ago, but I don't know the rational behind this.
>> >
>> > thanks
>> >
>> > nicolai
>> >
>> >
>>
>
>

Re: [Pharo-dev] Privacy sendDiagnosticsAndUsageData should be ternary, not binary

[Andrei Chis]

Hi Peter,

On Tue, Jun 7, 2016 at 12:05 AM, Peter Uhnak  wrote:

> Hi,
>
> Privacy>>sendDiagnosticsAndUsageData should be ternary, not binary.
>
> Because right now if I refuse sending the data I will be asked again every
> single time.
>

Indeed right now, at least in Spotter, the notification is shown every time
it is opened in
a new image, even if the setting was explicitly set. It was done like this
as a reminder,
especially if you have the setting set to true.


>
> So the proper behavior (imho) should be:
>
> ask Privacy for the setting… if the setting is not defined, then show a
> popup.
> If the setting is defined then respect it and do not show another popup.
>

The current behaviour with showing the notification in Spotter and Nautilus
should be a temporary one.
Ideally we just need a single uniform way of showing this notification plus
the option to control
and see the data that each tool wants to record at a fined-grained level.


>
> Also it would be nice to know what happens with the data.
>

We store it on a server and use it for various analyses.
It is also publicly available: GTEventTool default download.


> I mean my projects are open source so "sendSourceCode" shouldn't be an
> issue… but what you can possibly learn from it?
> Why not just analyze the content of SmalltalkHub/GitHub?
>

Because if you have the setting enabled it does not always work to map
different actions that with the code that you are working on.

Cheers,
Andrei


>
> Peter
>
>

Re: [Pharo-dev] moldable debugger challenge - iterator position

[Andrei Chis]

Hi Ben,

This seems like a nice idea. I think a first version of a debugger that
does
at least partially what you want is doable. Do you want to give it a try?
I can create a basic skeleton of the debugger and then we can iterate.

Cheers,
Andrei

On Sun, Jun 5, 2016 at 2:15 PM, Ben Coman  wrote:

> A bit of a pie in the sky idea, but
> I am currently tracing through code like this...
>
> XMLDOMVisitor >> visitDocument: theDocument
>   theDocument nodes do: [ :each | each accept: self ]
>
> and its hard to get a feel for where "each" is in theDocument.  I
> wonder if it would even be possible for the debugger to have a tab
> that showed a list of  "theDocument nodes" with a cursor positioned at
> "each" ?Maybe the #do: iterator is automatically identified, or
> maybe you'd need a pragma to define the tab, specifying the list
> contents and which variable is the cursor.  When the program crashes
> on an item, you could selected an item a few earlier and choose to
> break on that data value.
>
> So I guess all of it would be tough, but anyway thought I'd share that
> flash of an idea.
> cheers -ben
>
>

Re: [Pharo-dev] Do we want AST-Debugger?

[Andrei Chis]

Hi Denis,

No idea why the current debugger is not based on the AST interpreter or if
there are any plans to move it.
However, I think it will help to make the ASTDebugger compatible with the
current debugger from Pharo.
>From what I see the code from ASTDebugger is indeed very simple. One option
could be to create a subclass
of DebugSession that overrides those methods that control the execution. If
this goes easy then we could just
reuse both the Spec and the Glamour UIs.

Do you want to give it a try or sync more on this?

Cheers,
Andrei

On Wed, May 25, 2016 at 12:12 PM, Denis Kudriashov 
wrote:

> Hi.
>
> Look at AST-Interpreter project which includes AST-Debugger
> http://smalltalkhub.com/#!/~Pharo/AST-Interpreter. Code is so simple
> comparing to "bytecode simulation" approach of current debugger.
> AST debugger are independent from bytecode set. It just visit AST-nodes to
> simulate code execution.
>
> But current debugger simulates bytecode. It depends on current bytecode
> set. There are few kinds of BytecodeEncoders. To understand how current
> debugger is working you need to know many VM details.
>
> So my question is why our debuggers are not based on AST interpreter? Why
> it is bad idea? (if it is bad).
>
>
> Best regards,
> Denis
>

Re: [Pharo-dev] Debugger is not stable

[Andrei Chis]

Hi Stef,

On Sat, Jun 4, 2016 at 9:08 AM, stepharo  wrote:

> Hi andrei
>
> ThibaultDucasse/Wallet
>
> And remove the roundTo: 0.1 in the coinFor:into2: method.
>
> The while loop will iterate forever and pressing on into nearly kill you
>
> else you get killed by DNU from the debugger.
>
I loaded the code, removed  #roundTo: 0.1 in #coinFor:into2:, and
 experimented with #testCoinsForPayingWithOtherCoins which seems to trigger
the recursion but I cannot reproduce the error.

Do you use a particular Wallet object?
What image are you using?
Can you fuel out and send the stack if you get this error again?

Cheers,
Andrei

Stef
> PS: Yes I know I'm the stupider guy in the world because I criticise the
> wonderful GT tools and I should not because it is not acceptable :)
>
>
> Le 3/6/16 à 22:01, Andrei Chis a écrit :
>
> Hi Stef,
>
> Can you provide a way to load or access the entire code of your example?
>
> Cheers,
> Andrei
>
> On Fri, Jun 3, 2016 at 9:43 PM, stepharo  wrote:
>
>> Hi
>>
>> I'm debugging a simple algo for a first exercises in Pharo future book
>> and I get stepToSendOrReturn
>>
>> DNU when using the debugger. :
>>
>> You see I would really like in Pharo that we get new tools only when
>> there are better than the old
>>
>> ones. I still could not see how GTDebugger helps me debugging faster my
>> programs.
>>
>> Personally the fact that GT debugger can show bytecodes or can be
>> extended is not in the critical path.
>>
>> My critical path is that I can debug Pharo programs and now I cannot.
>>
>> I also did not see any comments on the multiple complaints about the
>> funky place for the buttons.
>>
>> So to me GTDebugger is a disappointement.
>>
>> Here is the kind of code I'm debugging so this is not that complex nor
>> implying concurrency or whatever complex.
>>
>>
>> coinsFor: aValue into2: accuWallet
>>
>> | accu |
>> self halt.
>> [
>> accu := accuWallet money.
>> accu < aValue ]
>> whileTrue: [
>> | big |
>> big := self biggest.
>> [ big > (aValue - accu) ] whileTrue: [
>>  big := self biggestBelow: big ].
>> self removeCoin: big.
>> accuWallet addCoin: big ].
>> ^ accuWallet
>>
>>
>> Stef
>>
>>
>>
>>
>
>

Re: [Pharo-dev] Debugger is not stable

[Andrei Chis]

Hi Stef,

Can you provide a way to load or access the entire code of your example?

Cheers,
Andrei

On Fri, Jun 3, 2016 at 9:43 PM, stepharo  wrote:

> Hi
>
> I'm debugging a simple algo for a first exercises in Pharo future book and
> I get stepToSendOrReturn
>
> DNU when using the debugger. :
>
> You see I would really like in Pharo that we get new tools only when there
> are better than the old
>
> ones. I still could not see how GTDebugger helps me debugging faster my
> programs.
>
> Personally the fact that GT debugger can show bytecodes or can be extended
> is not in the critical path.
>
> My critical path is that I can debug Pharo programs and now I cannot.
>
> I also did not see any comments on the multiple complaints about the funky
> place for the buttons.
>
> So to me GTDebugger is a disappointement.
>
> Here is the kind of code I'm debugging so this is not that complex nor
> implying concurrency or whatever complex.
>
>
> coinsFor: aValue into2: accuWallet
>
> | accu |
> self halt.
> [
> accu := accuWallet money.
> accu < aValue ]
> whileTrue: [
> | big |
> big := self biggest.
> [ big > (aValue - accu) ] whileTrue: [
>  big := self biggestBelow: big ].
> self removeCoin: big.
> accuWallet addCoin: big ].
> ^ accuWallet
>
>
> Stef
>
>
>
>