Re: [Pharo-dev] About Magritte Seaside

Hi Stephan, Le 7 oct. 2015 à 10:22, Stephan Eggermont a écrit : > On 07/10/15 08:47, Christophe Demarey wrote: >> If you have any question or remark, do not hesitate to ask or to give >> feedback. > > How do you express the migration of functionality from one package to > another? How does

[Pharo-dev] 50378 broke source

I found it in 50379, but it was introduced in 50378. 50377 looks ok. The FTSearch is fixed in 50380 RubFloatingEditorBuilder>>whenReturnEntered: anAnnouncement RubFloatingEditorBuilder class>>exampleCommandLauncher RubFloatingEditorBuilder class>>exampleEditableStringMorph Stephan

Re: [Pharo-dev] Yet another Athens font thread

No, they are needed. Because glyphs must be calculated (getGlyphs:of:) after(!) setting font size. Otherwise there are huge gaps between characters. When font problem appears, some characters are of size 14 even if font size 10. So glyphs of big characters have larger extent as it should be. In

Re: [Pharo-dev] [pharo-project/pharo-core] b4f208: 50379

This one is broken I tried opening the RubFloatingEditorBuilder example. That doesn't work. Trying to navigate methods in Nautilus gives MesasageNotUnderstaood: FTSearchFunction>>reset on arrowDown Stephan

[Pharo-dev] [pharo-project/pharo-core] b4f208: 50379

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: b4f208cfec7fbd345db65441ca353f9b34e5eebd https://github.com/pharo-project/pharo-core/commit/b4f208cfec7fbd345db65441ca353f9b34e5eebd Author: Jenkins Build Server Date:

[Pharo-dev] [pharo-project/pharo-core]

Branch: refs/tags/50379 Home: https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] 69dd1e: 50377

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 69dd1e1e6eaee21c310ee63270084529e307a6bb https://github.com/pharo-project/pharo-core/commit/69dd1e1e6eaee21c310ee63270084529e307a6bb Author: Jenkins Build Server Date:

[Pharo-dev] [pharo-project/pharo-core]

Branch: refs/tags/50377 Home: https://github.com/pharo-project/pharo-core

[Pharo-dev] [Reflectivity] Object invalidate now works

Hi, The mechanism that is behind the MetaLinks is now working for Object 50378: Object methods do: #createTwin. Object methods do: #invalidate. This means we are very close on having that working on the whole image. Next steps: -> invalidate the whole kernel. -> then: check/fix putting links

Re: [Pharo-dev] hash and Collections

> On 09 Oct 2015, at 16:21, Gabriel Cotelli wrote: > > If the collection implements = using the objects it holds then you need to > consider at least some of them in the hash calculation. I can't conceive a > hash calculation for this case independent of the contents

[Pharo-dev] [pharo-project/pharo-core] e8c312: 50378

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: e8c3124786d102764ca2c3b692090553f0b677ea https://github.com/pharo-project/pharo-core/commit/e8c3124786d102764ca2c3b692090553f0b677ea Author: Jenkins Build Server Date:

[Pharo-dev] [pharo-project/pharo-core]

Branch: refs/tags/50378 Home: https://github.com/pharo-project/pharo-core

Re: [Pharo-dev] [pharo-project/pharo-core] b4f208: 50379

On 09-10-15 15:38, Andrei Chis wrote: Strange. This version just merged a few deprecated calls and typos. Nothing related to rubric or nautilus. Are you sure these errors are from this version? You're right, they might be from a few versions earlier Stephan

Re: [Pharo-dev] hash and Collections

but that’s an error, I think. a collection has to have always same hash… no matter its size (because is not an array) and no matter his elements. > On 09 Oct 2015, at 15:21, Levente Uzonyi wrote: > > You simply don't modify _objects_ which are used as keys in hashed >

Re: [Pharo-dev] hash and Collections

The identityHash should stay the same for any number of changes to the array.. | c1 c2 | c1 := { #a . #b } asOrderedCollection. c2 := { #a . #b } asOrderedCollection. { c1 hash. c1 identityHash. c2 hash. c2 identityHash . (c2 add: #c; yourself)

Re: [Pharo-dev] hash and Collections

If the collection implements = using the objects it holds then you need to consider at least some of them in the hash calculation. I can't conceive a hash calculation for this case independent of the contents (well, just hardcode a number but this will lead to always collide if used as a key in a

Re: [Pharo-dev] [Moose-dev] Re: Roassal3D is moving...

No, the control the interaction that moves you around the object when you drag mouse instead of "rotating your head” as in fps game. Uko > On 09 Oct 2015, at 19:11, Alexandre Bergel wrote: > > By flyover you mean having a text tooltip? > > Alexandre > -- >

Re: [Pharo-dev] [Moose-dev] Roassal3D is moving...

Ah sorry. Teseo has written the class OrbitController. I think you should be able to reuse it for Roassal3d Old. But why not trying to migrate to Woden instead? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu

Re: [Pharo-dev] [pharo-project/pharo-core] b4f208: 50379

On 09-10-15 14:56, Stephan Eggermont wrote: This one is broken I tried opening the RubFloatingEditorBuilder example. That doesn't work. Ah, it's just the ridiculously large window. Stephan

Re: [Pharo-dev] hash and Collections

You simply don't modify _objects_ which are used as keys in hashed collections. Or if you do so, you'll have to deal with the consequences yourself. Levente On Fri, 9 Oct 2015, Esteban Lorenzano wrote: Hi, Can anyone explain me how this is correct? Collection>>#hash "Answer an

Re: [Pharo-dev] [pharo-project/pharo-core] b4f208: 50379

Strange. This version just merged a few deprecated calls and typos. Nothing related to rubric or nautilus. Are you sure these errors are from this version? On Fri, Oct 9, 2015 at 3:16 PM, Stephan Eggermont wrote: > On 09-10-15 15:10, Stephan Eggermont wrote: > >> On 09-10-15

[Pharo-dev] hash and Collections

Hi, Can anyone explain me how this is correct? Collection>>#hash "Answer an integer hash value for the receiver such that, -- the hash value of an unchanged object is constant over time, and -- two equal objects have equal hash values" | hash | hash

Re: [Pharo-dev] [pharo-project/pharo-core] b4f208: 50379

On 09-10-15 15:10, Stephan Eggermont wrote: On 09-10-15 14:56, Stephan Eggermont wrote: This one is broken I tried opening the RubFloatingEditorBuilder example. That doesn't work. Ah, it's just the ridiculously large window. and something wrong with sources

Re: [Pharo-dev] [Moose-dev] Re: Roassal3D is moving...

2 reasons: 1) something is always incompatible (I’ve tried 2 times already) 2) I have too many things hardcoded in Roassal3D subclasses. I have to move it into a proper model, and this will take time. I’ll take a look at the Orbiter. Although as far as I remember Roassal3D and Woden have

Re: [Pharo-dev] [Moose-dev] Roassal3D is moving...

Well, the example has been made in Roassal3d, built on top of Woden. Woden is low level. It may be suitable for game building, however for data visualization it is not the best. Let us know how it goes! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel

[Pharo-dev] [pharo-project/pharo-core] a785f4: 50380

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: a785f41a9f3da00652dfdb5ec943a39a65ca492a https://github.com/pharo-project/pharo-core/commit/a785f41a9f3da00652dfdb5ec943a39a65ca492a Author: Jenkins Build Server Date:

Re: [Pharo-dev] hash and Collections

> On 09 Oct 2015, at 4:33 , Esteban Lorenzano wrote: > > >> On 09 Oct 2015, at 16:21, Gabriel Cotelli > > wrote: >> >> If the collection implements = using the objects it holds then you need to >> consider at least some

[Pharo-dev] [pharo-project/pharo-core]

Branch: refs/tags/50380 Home: https://github.com/pharo-project/pharo-core

Re: [Pharo-dev] hash and Collections

Hi Esteban, I understand your surprise, but it has to be like that. Two objects that are equals have to have the same hash value. This is part of the contract. And to comply with this rule with collections, the hash value has to reflect the content of the collection. Java has the same

Re: [Pharo-dev] [Moose-dev] Roassal3D is moving...

Wow, this is amazing. Can I have this king of interaction in the old Roassal3D? Or a slave that will move ViDI to Woden? :) No, honestly I’d really appreciate if someone can help me to add this flyover interaction to ViDI, so we can run some kind of controlled experiment on it (and for now

[Pharo-dev] Roassal3D is moving...

Hi All! We are (secretly :-) working on Roassal3D. Teseo, from the University of Lugano, is quite enthusiast :-) https://vimeo.com/141916068 Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu

Re: [Pharo-dev] hash and Collections

> On Oct 9, 2015, at 7:51 AM, Henrik Johansen > wrote: > > >>> On 09 Oct 2015, at 4:33 , Esteban Lorenzano wrote: >>> >>> >>> On 09 Oct 2015, at 16:21, Gabriel Cotelli wrote: >>> >>> If the collection implements =